Hay una clara tendencia que se repite en las implementaciones de agentes: la puerta de enlace es la primera a la que recurren los equipos de control, pero es la que menos están preparados para ejecutar. Esto se debe a que las puertas de enlace se encuentran encima de capas de identidad y atribución que en su mayoría no existen.
La primera capa de riesgo no es hipotética. En junio, CISA agregó una falla LiteLLM a su catálogo de vulnerabilidades explotadas conocidas después de que los atacantes fueran sorprendidos abusando de él en la naturaleza. El error ejecutó comandos en el host a través de la propia puerta de enlace y, encadenado con un segundo defecto, no requería credenciales. Fue una de las siete vulnerabilidades y exposiciones (CVE) comunes reveladas en ese único portal de IA en un mes. Esta es la capa a la que muchas empresas recurren primero para proteger a sus agentes de IA.
Al considerar una arquitectura de agente segura, los controles de puerta de enlace no deben ser el primer control. Deberían ser los quintos.
La mayoría de los modelos sobre la madurez de la seguridad de los agentes describen los controles que una empresa necesitará en el futuro. Según mi experiencia, tienden a pasar por alto el problema más difícil de describir el escenario abandonado: ¿en qué orden deberían superponerse estos controles junto con un sistema de gestión de identidad y acceso que ya esté implementado?
Si el plano de control desconoce qué agente está actuando, quién delegó el trabajo, qué tarea debe realizar el agente y qué credenciales se utilizan, entonces el contexto está incompleto. Una puerta de enlace puede bloquear violaciones claras de las políticas, pero tendrá dificultades para distinguir una acción justificada de una que es técnicamente permisible pero operativamente inapropiada.
El patrón de fracaso es claro al secuenciar estos controles para los despliegues de producción de agentes: la aplicación de la ley se aplica tempranamente, mientras que la identidad y el contexto de atribución de los que depende aún no se han desarrollado. La seguridad del agente funciona como una cadena de dependencia, y cada control depende del contexto generado en sentido ascendente.
El punto de partida equivocado
Piense en enrutar el tráfico de los agentes a través de una nueva puerta de enlace en tiempo de ejecución. Un agente de conciliación financiera intenta alterar un registro en producción. La puerta de enlace autentica el token de usuario y verifica la llamada a la API. Lo que no puede observar es que la solicitud la inicia el agente, que el agente está ejecutando una función más limitada o que la solicitud es parte de una cadena de herramientas invocada por un artefacto que no es de confianza.
La credencial es válida. La llamada API está permitida. La acción contradice el propósito de la delegación. La puerta de enlace está ahí, pero su conjunto de soportes parece ausente, por lo que se aplica un costoso control a una parte muy pequeña del conjunto.
Limitar un privilegios del agente a los del principal humano es útil para que el agente no exceda a la persona a la que sirve. Sin embargo, tener un límite máximo de privilegios no crea una atribución separada. Veinte agentes pueden operar con los permisos de una sola persona y aún así necesitan identidades únicas, registros de auditoría, perfiles de comportamiento y rutas de revocación.
Implementación controlada por dependencias
A este proceso lo llamo implementación controlada por dependencias. Las pruebas de salida aguas arriba deben superarse antes de que cualquier control aguas abajo se considere operacionalmente completo. Se permite el desarrollo simultáneo de controles posteriores.
Aquí están las seis puertas y la prueba de que funcionan:
|
Puerta |
Control |
Prueba operativa de que funciona. |
|
1 |
Inventario de agentes y propiedad responsable |
Cada agente de producción tiene un propietario designado, un propósito, herramientas aprobadas y un estado de ciclo de vida. |
|
2 |
Identidad de agente distinta más contexto de delegación |
El sistema puede identificar al agente, su propietario y el principal para el que actúa. |
|
3 |
Credenciales de corta duración y con alcance de tarea |
Un agente comprometido no puede acceder a recursos no relacionados con su tarea asignada |
|
4 |
Telemetría atribuible |
Una tarea completada se puede reconstruir desde el inicio hasta el efecto posterior. |
|
5 |
Aplicación de acciones en tiempo de ejecución |
Las decisiones políticas incorporan el agente, el director, la tarea y el contexto de acción, no sólo la validez simbólica. |
|
6 |
Líneas de base de comportamiento y ruta de eliminación entre sistemas |
La autoridad efectiva del agente puede ser detenida dondequiera que llegue. |
Las seis puertas de dependencia para los controles de seguridad de los agentes. Cada control está contextualizado por las puertas que se encuentran encima. Del análisis del autor sobre la implementación de agentes de producción.
Comience con los agentes que realmente pueda nombrar
Para empezar, reconozca a los agentes de producción en marcos de código abierto, ofertas en la nube, servicios SaaS y herramientas para desarrolladores. Para cada uno, registre el propietario, la responsabilidad, la etapa del ciclo de vida, las herramientas permitidas, los dominios de datos y las fuentes de credenciales.
Si omite este paso, la organización perderá la primera hora de respuesta a incidentes mientras descubren lo que debería haber sido obvio. El inventario identifica el activo que rige cada control posterior.
Un agente necesita su propia identidad, pero no puede perder al ser humano que hay detrás.
Un agente no debe estar enterrado en un token de desarrollador, una cuenta de servicio compartido o una sesión humana. No basta con saber que la persona que llama es un agente. El plano de control requiere un contexto de delegación adicional: quién delegó el trabajo, qué tarea específica se le ordenó ejecutar al agente y a qué recursos necesita autoridad para acceder. La identidad especifica qué actor realizó la llamada. La delegación es la respuesta a la autoridad de quién actúa y por qué motivo.
Una vez que se corta esa conexión, los registros posteriores atribuyen el agente de conciliación al empleado cuyo token tomó prestado, y cada acción que realiza se atribuye a alguien que no la inició.
Reduzca la autoridad antes de inspeccionar el comportamiento
Una vez que se puede identificar a un agente, las capacidades deben ser limitadas. Las restricciones de acceso deben estar sujetas a la tarea y limitarse a las herramientas y recursos necesarios para realizar la tarea. Esto se puede implementar utilizando funciones de gestión de acceso de identidad (IAM), como identidad de carga de trabajo, intercambio de tokens, acceso condicional y derechos con plazos determinados que la organización ya posee.
Con respecto a la Estudio de teletransporte 2026 En el que participan 205 líderes de seguridad, el alcance del acceso supera la capacidad predictiva de la industria, la madurez o la confianza en sí mismo para predecir incidentes relacionados con la IA. Por ejemplo, las organizaciones con IA con privilegios excesivos informaron una tasa de incidentes del 76 %, mientras que los incidentes de IA ocurrieron en el 17 % de las organizaciones con privilegios mínimos. Esto indica que el alcance del acceso en la cadena de dependencia es más importante que la aplicación del tiempo de ejecución consciente del contexto.
El principio fundamental es la delegación monótona. Toda transferencia de responsabilidad debe preservar o disminuir la autoridad; bajo ninguna circunstancia debe aumentar la autoridad. Para el agente de conciliación, esto significa un agente que puede ver un libro mayor en lugar de uno que hereda el acceso del empleado a todos los sistemas a los que el empleado puede acceder.
Corregir la atribución antes de automatizar la aplicación de la ley
La mayoría de las pilas de auditoría pueden capturar a qué recurso se accedió y qué credencial permitió el acceso. En las implementaciones de agentes que he revisado, esta es la puerta que se pasa por alto con mayor frecuencia. Antes de utilizar una política de tiempo de ejecución adaptable, vincule cualquier invocación de herramienta relevante a la identidad del agente, el principal de inicio, la identificación de la tarea, la acción principal y el resultado. Después de hacerlo, examine la telemetría: para una tarea completada, vea si puede rastrear al iniciador, el agente que la ejecutó, la autoridad bajo la cual se tomó la acción, las herramientas utilizadas y el resultado. En entornos regulados, no se puede justificar una supervisión que no esté atribuida.
Ahora la puerta de enlace se gana el sustento
La puerta de enlace puede utilizar identidades registradas, delegación explícita, credenciales de alcance y telemetría atribuible para preguntar si este agente está autorizado a realizar esta acción, para este principal, dentro de esta tarea, que involucra este recurso. Aunque las credenciales del usuario pueden proporcionar acceso de escritura al agente de conciliación financiera, la puerta de enlace tiene un contexto situacional y, por lo tanto, determina que está fuera de alcance. Este es el punto de mayor valor del control. Los controles más estrictos deben aplicarse en límites irreversibles: pagos, cambios en las políticas de acceso, eliminaciones, modificaciones del entorno de producción y exportaciones de datos.
La detección y la ruta de eliminación son lo último
Las líneas de base de comportamiento se desarrollan en último lugar porque para establecer un estándar se debe establecer la actividad distinguible y atribuible de los agentes. Entonces, equipos de seguridad son capaces de identificar patrones anómalos en el uso de herramientas, accesos inesperados entre dominios y desviaciones de las tareas asignadas. La contención es más que simplemente deshabilitar un único objeto de directorio: una ruta de eliminación adecuada implica deshabilitar la identidad del agente, invalidar las credenciales activas y derivadas, bloquear la activación de herramientas, terminar tareas activas y aislar la carga de trabajo que contiene el agente.
Comience sin reemplazar su IAM
No es necesario diseñar un programa de identidad completamente nuevo. Si el proveedor de identidades existente no trata a los agentes como tipos de objetos nativos, comience con un registro autorizado vinculado a las identidades de carga de trabajo existentes. Después de esto, extienda los identificadores de agentes y tareas como contextos de ejecución confiables, implemente credenciales de corta duración para mitigar los privilegios heredados e incluya esos identificadores en los registros de llamadas de herramientas para la ingesta posterior de la puerta de enlace. El modelo de dependencia permanece sin cambios a medida que madura el soporte del proveedor.
Las brechas de control son mensurables. En Encuesta de Okta 2026solo el 34% de los ejecutivos dijo que su organización siempre aplica el mismo nivel de rigor de seguridad a su fuerza laboral de agentes que a su fuerza laboral humana. El último control de la cadena no se puede aplicar primero para cerrar esa brecha.
Qué hacer en los próximos 30 días
Comience con 10 agentes de producción. Para cada uno, identifique el propietario, el propósito, las herramientas aprobadas y las credenciales. A estas alturas, debería tener los inicios de un registro de agentes y quizás sus primeros conocimientos sobre gobernanza.
Atribución de prueba. Descubra si IAM y el registro pueden diferenciar a cada agente del ser humano o servicio que delegó la tarea. Si este tipo de diferenciación no fuera posible, una puerta de enlace estaría funcionando sin visibilidad alguna.
Reconstruya una tarea de agente completada dentro de una cadena de acción, de principio a fin, incluidos los efectos posteriores. Dondequiera que se rompa la cadena es donde su despliegue se queda corto.
Agregar la aplicación de medidas posteriores antes del contexto requerido rompe la seguridad del agente. Los modelos de madurez describen el destino. Una orden de construcción lo lleva allí sin interrumpir la producción en el camino.
Nik Kale es un ingeniero principal especializado en seguridad y plataformas de inteligencia artificial empresarial.
¡Bienvenido a la comunidad VentureBeat!
Nuestro programa de publicaciones invitadas es donde los expertos técnicos comparten conocimientos y brindan análisis profundos neutrales y no adquiridos sobre inteligencia artificial, infraestructura de datos, ciberseguridad y otras tecnologías de vanguardia que dan forma al futuro de las empresas.
Leer más de nuestro programa de publicaciones de invitados y consulte nuestro pautas ¡Si estás interesado en contribuir con un artículo propio!
Suscríbete y recibe las historias más importantes del día.
Al suscribirte aceptas nuestros términos y condiciones y política de privacidad.











































































