Nik Kale, especialista en plataformas empresariales de inteligencia artificial y seguridad, sostiene que muchas organizaciones comienzan por la puerta de enlace de ejecución de agentes como principal punto de control, aunque estas puertas de enlace dependen de capas de identidad y atribución que no siempre existen o no tienen la madurez suficiente. Como resultado, la puerta de enlace puede verificar la validez del token y de la solicitud de la interfaz de programación de aplicaciones, pero no siempre sabe qué agente ejecutó la solicitud, quién lo autorizó, qué tarea estaba realizando o si la solicitud formaba parte de una cadena de herramientas iniciada por un componente no confiable.
Este problema adquiere importancia práctica a medida que se amplía el despliegue de agentes. En junio, la Agencia de Seguridad de Infraestructura y Ciberseguridad de Estados Unidos (CISA) añadió una vulnerabilidad de LiteLLM a su catálogo de vulnerabilidades explotadas conocidas, después de detectar su uso indebido en la práctica. La vulnerabilidad permitía ejecutar comandos en el host a través de la propia puerta de enlace y, al combinarla con una segunda vulnerabilidad, también podía explotarse sin credenciales. La fuente señala que la puerta de enlace registró la divulgación de siete vulnerabilidades y exposiciones comunes (CVEs) en un solo mes.
La seguridad aquí es una cadena de confianza, no un único punto de control
Kale propone lo que denomina «despliegue gobernado por la confianza»: ninguna capa posterior debe considerarse operativamente completa antes de superar las pruebas requeridas para las capas anteriores. Los controles pueden desarrollarse en paralelo, pero su activación en producción debe seguir un orden claro:
- Inventario de agentes y propiedad responsable: cada agente de producción debe tener un propietario conocido, un propósito definido, herramientas aprobadas y un estado dentro de su ciclo de vida.
- Identidad independiente y contexto de autorización: el sistema debe conocer al agente, a su propietario y al usuario o entidad en cuyo nombre el agente ejecuta el trabajo.
- Credenciales de corta duración y específicas de la tarea: un agente comprometido no debe poder acceder a recursos que no estén relacionados con la tarea que se le asignó.
- Medición atribuible: debe ser posible reconstruir la tarea desde el momento en que comienza hasta su impacto final en otros sistemas.
- Aplicación de procedimientos en tiempo de ejecución: las decisiones de política deben basarse en la identidad del agente, la entidad autorizadora, la tarea y la acción, no únicamente en la validez del token.
- Línea base de comportamiento y mecanismo de apagado transversal a los sistemas: los equipos de seguridad deben poder detener la autoridad efectiva del agente en todos los lugares a los que accede.
Comience por lo que puede definirse y atribuirse
El primer paso, según el marco propuesto, es inventariar los agentes de producción existentes dentro de marcos de trabajo de código abierto, servicios en la nube, productos de software como servicio y herramientas para desarrolladores. El registro incluye al propietario del agente, su responsabilidad, la etapa de su ciclo de vida, las herramientas permitidas, los ámbitos de datos y las fuentes de credenciales. La ausencia de este inventario no es solo un problema documental; puede consumir parte del tiempo de respuesta a incidentes intentando identificar el activo que la organización debería conocer de antemano.
El autor subraya que la identidad del agente no debe quedar oculta dentro de código desarrollado por un programador, una cuenta de servicio compartida o una sesión de usuario. Saber que el interlocutor es un «agente» no basta. También deben registrarse quién autorizó el trabajo, la tarea específica y los recursos que el agente necesita utilizar. La identidad determina quién actúa, mientras que la autorización aclara bajo qué autoridad opera el agente y por qué se le concedió dicha autoridad.
Reduzca los permisos antes de analizar el comportamiento
Después de identificar la identidad del agente, sus capacidades deben restringirse según el tiempo, la tarea, las herramientas y los recursos necesarios para ella. La fuente señala que pueden aprovecharse funciones existentes en los sistemas de gestión de identidades y accesos (IAM), como la identidad de cargas de trabajo, el intercambio de tokens, el acceso condicional y los derechos de duración limitada.
Kale cita un estudio de Teleport de 2026 que incluyó a 205 responsables de seguridad; las organizaciones que utilizaban inteligencia artificial con permisos excesivos informaron de una tasa de incidentes del 76%, frente al 17% de las organizaciones que aplicaban el principio de mínimo privilegio. Según su análisis, esto indica que el alcance del acceso puede ser un factor más temprano en la cadena de confianza que la aplicación de políticas de tiempo de ejecución conscientes del contexto.
El principio que plantea el autor es la «delegación monótona»: cada transferencia de responsabilidad debe conservar la autoridad o reducirla, y nunca aumentarla. En el ejemplo de un agente de liquidaciones financieras, esto significa concederle permiso para consultar un libro mayor específico, en lugar de heredar todos los sistemas a los que puede acceder el empleado que realizó la solicitud.
¿Cuándo resulta realmente útil la puerta de enlace?
La puerta de enlace de ejecución no adquiere todo su valor hasta que existen una identidad registrada del agente, un contexto de autorización explícito, credenciales específicas y registros atribuibles. Entonces puede evaluar si el agente está autorizado a ejecutar una acción determinada, en beneficio de una entidad concreta, dentro de una tarea específica y sobre un recurso particular. El token del usuario puede ser válido para conceder al agente de liquidaciones permiso de escritura, pero el contexto completo puede mostrar que la acción queda fuera del alcance de la tarea.
Los controles más estrictos deben dirigirse a los límites cuyos efectos son difíciles de revertir, como los pagos, los cambios en las políticas de acceso, la eliminación, las modificaciones del entorno de producción y la exportación de datos. Las líneas base de comportamiento llegan después, cuando las actividades del agente pueden distinguirse y atribuirse; entonces es posible detectar un uso inusual de las herramientas, un acceso inesperado entre ámbitos de datos o una desviación de la tarea.
El mecanismo de apagado no se limita a desactivar un único objeto en el directorio de identidades. El apagado completo, tal como lo describe la fuente, requiere desactivar la identidad del agente, revocar las credenciales activas y derivadas, impedir la ejecución de herramientas, finalizar las tareas en curso y aislar la carga de trabajo que contiene al agente.
Plan de pruebas en 30 días
El autor no propone sustituir el programa de gestión de identidades existente. Si el proveedor de identidad no trata a los agentes como tipos nativos, puede comenzarse con un registro confiable vinculado a las identidades de cargas de trabajo existentes, añadir después identificadores del agente y de la tarea como contextos de ejecución confiables, utilizar credenciales de corta duración e incluir esos identificadores en los registros de invocación de herramientas.
En la práctica, propone comenzar con diez agentes de producción y documentar el propietario, el propósito, las herramientas y las credenciales de cada uno. Después debe comprobarse si los sistemas de gestión de identidades y de registro distinguen al agente del humano o servicio que autorizó la tarea, y luego reconstruir una tarea completa de principio a fin, incluidos sus efectos posteriores. El punto en el que se interrumpe la cadena revela la brecha que debe abordarse antes de añadir una nueva aplicación operativa.
Lectura editorial: el valor de este marco no reside en proponer una nueva puerta de enlace, sino en reordenar el punto de partida. Los hechos mencionados sobre LiteLLM, junto con las cifras de Teleport y Okta, respaldan la importancia de reducir los permisos y establecer la atribución, pero por sí solos no demuestran que el orden de capas propuesto sea la única solución o que sea adecuado para todas las arquitecturas empresariales. Además, el material es un análisis del autor y no un estándar oficial; por ello, su aplicación requiere revisar los detalles de los sistemas de identidad y registro y de los mecanismos de apagado existentes en cada organización.