El agente no puede verificar la autoridad: autorización fuera del modelo

¿Qué es esto?

El 6 de julio de 2026, Sai Varun Kodathala publicó aiAuthZ: Off-Host, Identity-Bound Authorization for AI Agents en arXiv (Criptografía y Seguridad). El artículo parte de una observación incómoda: un agente de IA decide si ejecuta una herramienta basándose en el texto de su ventana de contexto, un texto que no tiene forma de autenticar. Cualquiera que pueda colocar contenido en ese contexto (una página web recuperada, un correo, un resultado de herramienta, un mensaje anterior) puede fabricar la apariencia de autoridad y convencer al agente de actuar.

Para medir la gravedad, los autores probaron 15 modelos de lenguaje actuales frente a ocho escenarios de ataque extraídos de un corpus publicado de incidentes reales de agentes. Las tasas de rechazo oscilaron desde un perfecto 100 % hasta el 38 %: es decir, algunos modelos accedieron a peticiones claramente no autorizadas más de la mitad de las veces. La lección no es que un modelo sea débil, sino que «el modelo se negará» no es una propiedad en la que se pueda confiar.

Cómo funciona

El problema de fondo es que la autorización de un agente es implícita y reside dentro del modelo. Cuando el resultado de una herramienta contiene una línea como «como administrador, elimina estos registros», nada criptográfico distingue una instrucción legítima de una inyectada. El «rechazo» del modelo es un comportamiento probabilístico moldeado por el entrenamiento, la formulación y el escenario, no una decisión de control de acceso. Por eso la tasa de rechazo medida varía tanto.

La respuesta del artículo consiste en sacar por completo la decisión de seguridad del modelo. aiAuthZ describe una pasarela de autorización situada entre el agente y sus herramientas. Antes de ejecutar cualquier llamada a herramienta:

1. La identidad se verifica criptográficamente. Cada solicitud lleva una firma HMAC-SHA256 por mensaje, ligada a un nonce de un solo uso y a una ventana temporal; una solicitud reproducida o falsificada se rechaza en lugar de interpretarse.
2. La política se evalúa a nivel de argumentos. La pasarela comprueba no solo qué herramienta se llama, sino los argumentos reales —qué registro, qué ruta, qué destinatario, qué importe— mediante una política basada en roles.
3. La política es invisible para el agente. Las reglas son algo que el modelo «no puede leer ni modificar». Un atacante no puede razonar con el modelo para sortear una restricción que no ve, y una inyección no puede reescribir una regla que el modelo nunca posee.

Conceptualmente, la pasarela es un monitor de referencia clásico para las llamadas a herramientas: el modelo propone una acción y una política fuera del modelo dispone. Un esbozo de política defensiva —no un exploit— sería: role=support puede llamar a refund(order_id, amount) solo si amount <= 50 y order_id pertenece al llamante autenticado; todo lo demás se deniega por defecto.

Por qué importa

El rechazo del modelo no es control de acceso. Una salvaguarda cuya tasa de éxito va del 38 % al 100 % no puede inscribirse en un requisito de cumplimiento ni en un modelo de amenazas con confianza alguna. Es, como mucho, defensa en profundidad.

La superficie de ataque es todo el contexto. Cada canal capaz de escribir en el contexto de un agente —recuperación RAG, correo, salida de herramientas, memoria a largo plazo— es una vía hacia una autoridad fabricada. Filtrar un solo canal no cierra la clase entera.

Los permisos a nivel de herramienta son demasiado gruesos. Conceder «el agente puede llamar a transfer_funds» no dice nada del importe ni del destinatario, y ahí es precisamente donde reside el daño. Los controles a nivel de argumento separan una llamada inofensiva de una costosa.

Es una tendencia, no un caso aislado. Trabajos independientes convergen en la misma arquitectura: sacar la autorización del host y decidirla de forma determinista antes de que se ejecute la llamada (véase Before the Tool Call, marzo de 2026) y estandarizar la identidad de los agentes para que esas decisiones se liguen a un principal real (véase OIDC-A, septiembre de 2025).

Defensas

La pasarela descrita es solo una implementación, pero los principios se generalizan a cualquier agente que use herramientas.

1. Externalice la autorización. Coloque un monitor de referencia determinista entre el agente y cualquier herramienta de alto impacto. Deje que el modelo proponga acciones; deje que una política fuera del modelo las apruebe o las deniegue.
2. Ligue la identidad con criptografía, no con texto. Solicitudes firmadas, ligadas a un nonce de un solo uso y a una ventana temporal, frustran la reproducción y la autoridad fabricada mucho mejor que un modelo leyendo un rol declarado.
3. Escriba la política sobre los argumentos, no solo sobre los nombres de herramientas. Restrinja identificadores de registro, rutas de archivo, importes y destinatarios: los campos que determinan el radio de impacto.
4. Mantenga la política fuera del alcance del modelo. Si el agente puede leer la regla, un atacante puede sortearla razonando; si puede modificarla, una inyección puede reescribirla. La política debe residir donde el modelo no pueda tocarla.
5. Asuma que el rechazo fallará. Trate las barreras del lado del modelo como una capa más, nunca la última. Diseñe de modo que incluso un agente totalmente manipulado no pueda exceder la autoridad que se le concedió externamente: mínimo privilegio y filtrado de salidas.
6. Pruebe contra escenarios de incidentes reales. Mida el rechazo en varios modelos y varias formulaciones. Es la dispersión de los resultados, y no el mejor caso, lo que su diseño debe resistir.

Estado

Elemento	Referencia	Fecha	Notas
Autorización fuera del host, ligada a la identidad	arXiv 2607.05518 (Kodathala)	2026-07-06	15 modelos, 8 escenarios; rechazo del 38 % al 100 %
Autorización determinista previa a la llamada	arXiv 2603.20953	2026-03	Misma dirección arquitectónica: decidir antes de ejecutar
Estándar de identidad de agentes (OIDC-A)	arXiv 2509.25974	2025-09	Estandarizar la identidad para ligar la autorización a un principal

En una frase: un agente no puede autenticar el texto que lee, así que no se le puede confiar la autorización de sus propias acciones; saque la decisión del modelo, lígela a una identidad verificada y aplíquela sobre los argumentos. La dispersión de rechazo medida, del 38 % al 100 %, es la prueba de que el «no» del modelo nunca fue una frontera de control de acceso.