La proliferación de agentes de software, que actúan a velocidad de máquina y con una naturaleza efímera, ha expuesto limitaciones fundamentales en los modelos de control de acceso diseñados para humanos. Los sistemas de seguridad tradicionales, como BeyondCorp, se centraron en autenticar usuarios y dispositivos, asumiendo un principal legible que opera a velocidad humana y genera un flujo predecible de decisiones de acceso. Sin embargo, los agentes de software no se ajustan a este perfil: sus credenciales suelen ser duraderas, actúan a velocidad de máquina, pueden ser manipulados por prompts y componen autoridad a través de múltiples saltos.
El problema fundamental que AAM busca resolver es cómo aplicar el principio de menor privilegio (least privilege) de manera efectiva y dinámica a agentes de software en un entorno distribuido. Esto implica pasar de una autorización estática basada en la identidad del servicio a una autorización granular por acción, que se adapta al contexto y al estado acumulado de la tarea. La necesidad de este cambio es apremiante debido al riesgo inherente de exfiltración de datos y el sobre-privilegio que surge cuando los agentes acceden a sistemas de registro a alta velocidad, superando la capacidad de reacción de los controles de seguridad diseñados para humanos.
Arquitectura del Sistema
El Agent Access Model (AAM) se compone de cuatro controles activos y dos sistemas de soporte. Los controles activos son el Agent Identity Broker, el Task-Scoped Access Engine, la Mediation Layer (harness y red) y el Trust Ratchet. Los sistemas de soporte son el Agent Activity Log y el Grant Review Loop.
El Agent Identity Broker es responsable de emitir credenciales de corta duración, verificables y con ámbito de tarea (task-scoped) en el momento del despacho del agente. Estas credenciales están ligadas a una clave de prueba (proof key) en el harness (sender-constrained) para evitar la re-ejecución de tokens robados, utilizando estándares como OAuth 2.0 Token Exchange (RFC 8693) y DPoP (RFC 9449).
El Task-Scoped Access Engine extiende el concepto de Access Control Engine de BeyondCorp, haciendo de la tarea un input de primera clase para la decisión de autorización. Decide, por cada solicitud, si la identidad del agente puede realizar una acción específica contra un recurso, aplicando el principio de menor privilegio como valor predeterminado y límite superior. La "capacidad máxima" de una tarea se define en el despacho, intersectando una plantilla de tarea pre-aprobada con la autoridad del principal iniciador y el servicio del agente.
La Mediation Layer opera en dos límites: las rutas de herramientas expuestas por el harness y el tráfico saliente forzado a través del límite de red. El harness intercepta las llamadas a herramientas, las verifica contra la política de la tarea y emite eventos de cumplimiento. La capa de red controla los destinos y protocolos accesibles para el tráfico, incluyendo procesos hijos. Ambas capas aplican una política de "denegar por defecto" y deben fallar de forma independiente, compartiendo la política de la tarea y el estado del Trust Ratchet.
El Trust Ratchet introduce un estado de confianza dinámico. Su propósito principal es limitar la exfiltración de datos. Cuando ocurre un "evento protegido" (ej. lectura de datos sensibles), el Trust Ratchet elimina capacidades del grafo de ejecución de la tarea según la política predefinida. Este estado solo puede reducirse, nunca ampliarse, durante la vida de la tarea. Utiliza un mecanismo de compare-and-set o un único escritor para serializar las actualizaciones de estado, asegurando que todos los puntos de aplicación adopten el nuevo estado antes de liberar la respuesta sensible.
El Agent Activity Log es un registro inmutable y consultable de la actividad del agente, capturado por todos los puntos de aplicación (Identity Broker, Access Engine, harness, Trust Ratchet y red). Proporciona un contrato de eventos común para correlacionar acciones y decisiones de autorización, facilitando la auditoría y la respuesta a incidentes. Finalmente, el Grant Review Loop utiliza la evidencia del Agent Activity Log para revisar las plantillas de tareas, proponiendo revocaciones de permisos no utilizados (over-permissioned) o ampliaciones justificadas (under-permissioned) para futuras tareas, manteniendo la política que se ejecuta alineada con la política auditada.
Flujo de Despacho y Ejecución de Tareas de Agente
- 1 Scheduler/Humano Inicia la tarea del agente.
- 2 Access Engine Establece la capacidad máxima de la tarea (capability ceiling) intersectando ...
- 3 Identity Broker Emite una credencial de corta duración, task-scoped y sender-constrained.
- 4 Agente Ejecuta la lógica de la tarea, realizando llamadas a herramientas/red.
- 5 Mediation Layer (Harness/Red) Intercepta y autoriza cada acción contra la capacidad máxima y el estado del ...
- 6 Trust Ratchet Si ocurre un evento protegido, reduce las capacidades del agente y notifica a...
- 7 Agent Activity Log Registra todas las decisiones de autorización y eventos de cumplimiento.
- 8 Recurso Externo Acceso permitido o denegado.
Flujo de Exfiltración de Datos (Ejemplo de Denegación)
- 1 Agente Lee un informe clasificado como 'protegido'.
- 2 Harness Retiene el informe y activa la transición del Trust Ratchet.
- 3 Trust Ratchet Transiciona de 'Baseline' a 'Restricted', eliminando rutas externas y de sopo...
- 4 Puntos de Aplicación Confirman el nuevo estado; el harness libera el informe al agente.
- 5 Agente Intenta una operación de soporte (ahora denegada por el estado 'Restricted').
- 6 Harness/Red Rechaza la solicitud de forma independiente.
- 7 Agent Activity Log Registra ambas denegaciones.
| Capa | Tecnología | Justificación |
|---|---|---|
| security | OAuth 2.0 Token Exchange (RFC 8693) | Define un mecanismo para intercambiar tokens de seguridad, permitiendo la emisión de tokens con ámbito reducido (narrowed by audience, resource, or scope) para el Agent Identity Broker. |
| security | OAuth 2.0 Demonstrating Proof of Possession (DPoP) (RFC 9449) | Permite ligar un token OAuth a una clave de cliente, requiriendo prueba en cada solicitud protegida. Esto asegura que un token robado no pueda ser re-ejecutado sin la clave de prueba, implementando tokens sender-constrained. |
| security | Agent Identity Broker | Componente que emite credenciales de corta duración, task-scoped y sender-constrained para agentes, basándose en estándares OAuth. |
| security | Task-Scoped Access Engine | Extiende los motores de control de acceso tradicionales para incluir el contexto de la tarea como un input de primera clase en las decisiones de autorización, aplicando el menor privilegio por defecto. |
| security | Mediation Layer (Harness & Network) | Puntos de aplicación de políticas de seguridad. El harness intercepta llamadas a herramientas, y la capa de red controla el tráfico saliente, asegurando que las acciones del agente se adhieran a la política de la tarea y al estado del Trust Ratchet. |
| security | Trust Ratchet | Mecanismo para reducir dinámicamente las capacidades de un agente durante la ejecución de una tarea en respuesta a eventos protegidos (ej. acceso a datos sensibles), garantizando que el estado de confianza solo pueda estrecharse. |
| observability | Agent Activity Log | Sistema de registro inmutable y consultable que captura todas las decisiones de autorización y eventos de cumplimiento de los componentes de AAM, esencial para auditoría y respuesta a incidentes. vs Registros de aplicaciones genéricos (insuficientes para granularidad y atribución) Uso de OpenTelemetry y Open Cybersecurity Schema Framework (OCSF) para estandarización y correlación de eventos. |
| security | Grant Review Loop | Sistema de soporte que analiza los datos del Agent Activity Log para identificar plantillas de tareas sobre-privilegiadas o sub-privilegiadas, proponiendo cambios para futuras tareas y manteniendo el principio de menor privilegio. vs Revisión manual de permisos (ineficiente a escala) |
Trade-offs
Ganancias
- ▲ Reducción del riesgo de exfiltración de datos
- ▲ Aplicación granular del principio de menor privilegio
- ▲ Mayor visibilidad y auditabilidad de las acciones del agente
- ▲ Control de acceso dinámico y adaptable a la ejecución de la tarea
Costes
- ▲ Mayor complejidad en la infraestructura de seguridad y el control plane
- △ Posible impacto en la latencia debido a la autorización inline y las transiciones del Trust Ratchet
- △ Necesidad de un vocabulario común y contratos de eventos estandarizados entre componentes
- ▲ El problema de control de acceso multi-principal sigue sin resolverse
Fundamentos Teóricos
El Agent Access Model se basa en principios fundamentales de seguridad informática y sistemas distribuidos. La idea de "least privilege" es tan antigua como el control de acceso, formalizada por Saltzer y Schroeder en su seminal trabajo "The Protection of Information in Computer Systems" (1975). La extensión de este principio a un contexto dinámico y efímero para agentes de software es una adaptación necesaria a la era de la IA.
El modelo Zero Trust, popularizado por Google con BeyondCorp (Ward y Beyer, 2014), es un precursor directo, al eliminar la confianza implícita de la red. AAM extiende esta filosofía al grafo de ejecución de la tarea, eliminando la confianza implícita entre acciones. La gestión de credenciales de corta duración y ligadas al remitente se apoya en estándares como OAuth 2.0 Token Exchange (RFC 8693) y DPoP (RFC 9449), que son extensiones de protocolos de autenticación y autorización bien establecidos en la academia y la industria. La "Trust Ratchet" puede verse como una aplicación de conceptos de máquinas de estado y transiciones de seguridad, donde el estado de capacidad solo puede progresar hacia un conjunto más restringido, similar a los principios de seguridad de "monotonicidad" en la reducción de privilegios.