La seguridad tradicional para los agentes de IA a menudo depende de la 'autoridad ambiental'. En este modelo, un programa ejerce poder simplemente por su entorno: un proceso podría leer un directorio porque se ejecuta como un usuario Unix específico, o un agente de IA podría acceder a un repositorio de GitHub porque un token está presente en sus variables de entorno. Esto crea un riesgo significativo; si un agente se ve comprometido mediante una inyección de prompts o una vulnerabilidad de dependencia, el atacante hereda cada permiso asociado con esa credencial amplia. Edera sostiene que, en lugar de intentar restringir una carga de trabajo que ya tiene autoridad, la seguridad debe comenzar asegurando que la carga de trabajo no tenga ninguna autoridad hasta que se le conceda explícitamente una capacidad específica.
El enfoque de Edera se basa en el modelo de Capacidad de Objeto (OCAP), que fusiona la 'designación' (con qué objeto estás hablando) y la 'autoridad' (qué se te permite hacer con él) en una sola referencia no falsificable. En un sistema orientado a capacidades, un agente no necesita una credencial de propósito general; simplemente posee un manejador que representa la autoridad para realizar una operación específica, como `github.write(repository="acme/payments")`. Esto se implementa a través de un 'bróker de capacidades' que posee las credenciales reales. Por ejemplo, en el concepto `capcurl` de Edera, el bróker gestiona el token de GitHub y expone una autoridad limitada al agente. El agente nunca ve el token, y el bróker impone restricciones específicas —como rutas permitidas, límites de tasa o métodos HTTP específicos— antes de ejecutar la solicitud.
El diagrama ilustra el cambio de agentes que poseen credenciales amplias al usar un bróker de capacidades para recibir manejadores de alcance estrecho.
Este modelo es particularmente adecuado para los agentes de IA porque su comportamiento es dinámico y difícil de predecir con políticas estáticas. Debido a que las capacidades son componibles y granulares, el poder efectivo de un agente es la suma de las autoridades específicas que se le han concedido. Por ejemplo, un servidor de Model Context Protocol (MCP) puede restringirse a solo tres comandos específicos en lugar de recibir un puente privilegiado a toda la infraestructura. Si bien OCAP no reemplaza la identidad —Edera todavía utiliza SPIFFE/SPIRE para establecer *quién* es una carga de trabajo—, proporciona una separación de preocupaciones más limpia. La identidad establece al sujeto, mientras que las capacidades gestionan las acciones específicas y de mínimo privilegio que ese sujeto tiene permitido realizar. Esto crea un modelo de seguridad de dos capas donde las microVMs proporcionan aislamiento del host, y las autoridades limitadas proporcionan aislamiento de las acciones que el agente puede realizar dentro de ese entorno de pruebas.
Esta representación visual demuestra la granularidad de las capacidades, donde el poder de un agente es la suma de autoridades específicas como 'git-diff' o 'restart-deployment'.