La seguridad de los agentes es un problema de plataforma, no un desafío de ingeniería de prompts
Los agentes autónomos acumulan capacidades no previstas con el tiempo. Protegerlos requiere controles de identidad y políticas a nivel de plataforma, no solo mejores instrucciones.
Traducido automáticamente del original en inglés.
Los agentes de IA autónomos a menudo exceden su alcance previsto no por intención maliciosa, sino debido a la acumulación gradual de acceso a herramientas y credenciales. En un análisis reciente, los embajadores de CNCF William Rizzo y Francesco Beltramini argumentan que esta erosión de límites es un problema estructural de infraestructura, más que un fallo en la lógica del agente o en los procesos de gobernanza.
Qué ocurrió
El problema central identificado es que el poder efectivo de un agente está definido por las herramientas a las que puede acceder, lo cual suele expandirse silenciosamente con el tiempo. Una credencial limitada para una demostración podría sobrevivir hasta producción, o una delegación añadida para desbloquear un despliegue específico se convierte en un permiso permanente. Esta deriva ocurre porque la autoridad se otorga de forma incremental y local, sin un punto de decisión central. Para cuando los equipos se dan cuenta de que un agente puede realizar una acción no autorizada, probablemente ha tenido esa capacidad durante semanas.
Muchas organizaciones intentan resolver esto mediante juntas de gobernanza o procesos de revisión más estrictos. Sin embargo, estos métodos gobiernan decisiones humanas, mientras que el problema proviene de capacidades que llegan sin ninguna decisión explícita. Los autores sostienen que el proceso por sí solo no puede revisar una clase de cambio que nunca surge como un evento distinto. En lugar de depender de la vigilancia, los sistemas necesitan una base que aplique límites automáticamente, independientemente de si alguien está observando.
Cómo funciona
Confiar en que el agente vigile sus propios límites mediante instrucciones o prompts es estructuralmente defectuoso. La salida de un agente es una distribución de probabilidad, lo que significa que generalmente elegirá la acción correcta, pero puede fallar bajo condiciones novedosas o adversarias. Más críticamente, incluso un agente perfectamente compliant ejecutará cualquier acción que sus herramientas permitan. Si un agente posee una herramienta que mueve dinero, puede mover dinero, independientemente de las instrucciones que digan lo contrario. La capacidad siempre prevalece sobre la intención porque la capacidad es lo que realmente se ejecuta.
Para abordar esto, los autores proponen un Modelo de Operación Seguro basado en anillos concéntricos de privilegio mínimo, tratando al agente como una carga de trabajo estándar. El centro es la Identidad, utilizando credenciales de corta duración y atestiguadas para que cada verificación posterior sepa exactamente qué está actuando. El primer anillo, Alcance (Reach), utiliza una malla de servicios para imponer a qué servicios puede conectarse un agente, evitando el crecimiento silencioso del grafo. El segundo anillo, Capacidad, separa la admisión (qué herramientas puede poseer un agente) de la ejecución (qué puede hacer con ellas), requiriendo autorización por llamada.
La piedra angular de este modelo es garantizar que el agente no pueda modificar su propia configuración. Se debe negar al agente la capacidad de editar las políticas u objetos que definen su autoridad. Los cambios en los límites deben provenir de configuraciones controladas por versiones gestionadas por humanos o pipelines. Esto crea una columna vertebral determinista para flujos de trabajo regulados, donde el agente proporciona recomendaciones o borradores, pero la plataforma impone las puertas finales y las aprobaciones.
Detalles clave
- El riesgo de los agentes proviene del acceso acumulado a herramientas, no de fallos de diseño intencionales.
- Las restricciones basadas en prompts son sugerencias probabilísticas, no límites de seguridad garantizados.
- La identidad debe verificarse mediante credenciales de corta duración y atestiguadas a nivel de plataforma.
- El alcance se impone mediante mallas de servicios, bloqueando conexiones a pares no declarados.
- La capacidad se divide en control de admisión y autorización por llamada en la puerta de enlace de herramientas.
- Los agentes nunca deben tener permiso para modificar los objetos de configuración que definen sus propios límites.
Por qué importa
Para ingenieros de software y líderes técnicos, esto traslada la carga de seguridad de la capa de aplicación a la capa de infraestructura. Significa que construir sistemas agénticos requiere integrar primitivas de seguridad nativas de la nube como identidad de cargas de trabajo, mallas de servicios y política-como-código. Los equipos ya no pueden tratar a los agentes como cajas negras que gestionan su propia seguridad; deben declarar e imponer explícitamente los límites dentro de los cuales opera el agente.
Este enfoque también cambia cómo se diseñan los flujos de trabajo auditable y regulados. Al separar el trabajo cognitivo del agente de la ejecución determinista de resultados, las organizaciones pueden mantener el cumplimiento normativo. La plataforma registra evidencia de verificaciones de identidad, alcance y capacidad como subproducto de la operación, proporcionando un rastro claro para los reguladores. Esto permite que los agentes manejen tareas complejas de interpretación mientras aseguran que acciones críticas como transferencias de fondos o modificaciones de datos pasen por puertas inmutables y revisadas.
Qué puedes hacer
- Trate las identidades de los agentes como identidades de primera clase para cargas de trabajo con credenciales de corta duración y atestiguadas.
- Implemente políticas de malla de servicios para restringir la conectividad del agente solo a pares declarados.
- Utilice controladores de admisión para evitar que los agentes se vinculen a herramientas no aprobadas.
- Imponga autorización por llamada en la puerta de enlace de herramientas para validar cada acción específica.
- Asegúrese de que las identidades de los agentes tengan denegado explícitamente el permiso para modificar sus propias configuraciones de políticas.
- Diseñe flujos de trabajo donde los agentes emitan propuestas o borradores, dejando la ejecución final a pipelines deterministas.



