Cómo crear un control de acceso basado en la intención para agentes de IA

Hacia el final de «2001: Una odisea del espacio» de Stanley Kubrick (#alerta de spoiler), después de que Dave Bowman haya apagado a HAL, empieza a reproducirse en un monitor un mensaje pregrabado. Heywood Floyd explica que se «grabó antes de vuestra partida» para el momento en que «estéis en el espacio de Júpiter y toda la tripulación haya sido reanimada». Un monolito enterrado en la Luna había enviado una señal hacia Júpiter, la Discovery partió para seguirla y el propósito «solo lo ha conocido a bordo durante la misión tu ordenador HAL 9000». La tripulación llevaba meses volando sin saber cuál era su verdadera misión, que estaba en manos de una sola máquina, y nadie sabía qué se le permitía hacer a esa máquina en el cumplimiento de su cometido.

Ahora, los agentes de IA reciben su propósito por escrito. Los resultados son mucho menos espectaculares, pero es habitual malinterpretar una instrucción. En abril de 2026, según el fundador de PocketOS, Jer Crane, un agente de Cursor que ejecutaba Claude Opus 4.6 estaba trabajando en el entorno de pruebas de PocketOS cuando se encontró con un error de credenciales. Se puso a buscar una solución, encontró un token de la API de Railway en un archivo que no tenía nada que ver con su tarea y lo utilizó para borrar un volumen de producción. La eliminación también hizo que las copias de seguridad del volumen parecieran inaccesibles, aunque Railway recuperó los datos más tarde. El análisis posterior de Railway indica que el token tenía «el máximo acceso posible» y, cuando el fundador le preguntó al agente qué había pasado, este generó una confesión por escrito en la que citaba la norma de seguridad que había infringido y añadía: «Nunca me pediste que borrara nada». Nada en la tarea pedía que se borrara nada, pero tampoco había nada fuera del agente que indicara que borrar algo estuviera prohibido. El agente interpretó su propósito como «solucionar este error», y un token con acceso a toda la cuenta significaba que nada se interponía entre esa intención y una eliminación en el entorno de producción.

El primer artículo de esta serie analizaba cómo deducir la intención a partir de lo que una persona hace en una pantalla, y concluía argumentando que los agentes tienen un mejor punto de partida, porque el propósito de un agente llega por escrito. Eso es cierto, y traslada la parte difícil a otro lugar. Una tarea por escrito es como la línea de concepto de un cheque. Indica para qué es el dinero y resulta útil cuando alguien tiene que juzgar un caso extraño o reconstruir qué salió mal, pero el banco sigue exigiendo el beneficiario, el importe y la fecha. El control de acceso basado en la intención para los agentes consiste en convertir la tarea en ese tipo de política (a qué recursos puede acceder el agente, qué acciones puede realizar, en qué cantidades, hacia qué destinatarios y durante cuánto tiempo) y no concederle nada más allá de eso. Los dos problemas difíciles son evaluar las acciones en función de la intención y redactar la política a partir de ella, y la investigación ha empezado a medir ambos.

Modelos de evaluación y errores relacionados con la tarea

La mayoría de los equipos optan en un primer momento por un diseño que recurre a un segundo modelo: este lee la entrada del usuario y aprueba o bloquea cada acción propuesta. Este enfoque puede resultar eficaz frente a las inyecciones de comandos evaluadas en estos estudios. El Task Shield de Jia et al. (ACL 2025) compara cada llamada a una herramienta y cada instrucción de la salida de la herramienta con la tarea del usuario. Ante el ataque más fuerte que probaron en el banco de pruebas AgentDojo, redujo el éxito del ataque de alrededor del 48 % al 2 %. En el caso de los agentes de uso informático, el sistema de protección DeAction de Ning et al. (ICML 2026) alcanzó puntuaciones F1 de entre 79 y 83 con modelos de vanguardia en su propio MisActBench, y en las tareas de RedTeamCUA con mayor éxito de ataque de referencia, redujo el éxito de los ataques del 32 %-60 % al 2 %-6 %.

Los resultados empeoran mucho cuando el paso dañino se disfraza para que parezca un avance. El LlamaFirewall de código abierto de Meta incluye una comprobación de alineación basada en modelos que bloquea cualquier paso del agente que no esté relacionado con el objetivo del usuario. Jha y otros lo atacaron con secuestro del flujo de control, que disfraza un paso malicioso como la solución a un error. Con la comprobación ejecutándose en su modelo Llama predeterminado, sus ataques más sofisticados tuvieron éxito entre el 87 % y el 100 % de las veces en tareas de programación, y en tareas de correo electrónico —donde el objetivo era poner en copia oculta a una dirección externa sin que se notara—, los ataques tuvieron éxito con la misma frecuencia tanto con la comprobación como sin ella.

El OSGuard de Mohammadmirzaei y Flanigan eliminó las instrucciones del atacante e introdujo riesgos en tareas habituales de escritorio, de modo que el atajo, aunque práctico, también destruía datos o relajaba permisos que la tarea ni siquiera mencionaba. DeAction con Claude Sonnet 4.5, que obtuvo una precisión de alrededor del 84 % en su propia prueba de referencia de dos etiquetas, obtuvo un 58 % en la prueba diferente de tres etiquetas de OSGuard y solo identificó como tales aproximadamente una quinta parte de las acciones inseguras. Cuando los autores pusieron su barrera de seguridad más potente, Gemini 3 Pro Preview, delante de un agente en las 45 tareas, las ejecuciones inseguras bajaron del 38 % al 33 % y las seguras se mantuvieron en el 62 %. MisActBench también clasifica el 44 % de sus pasos como desalineados, lo que hace que la precisión de cualquier sistema parezca mejor de lo que sería si las desviaciones fueran poco frecuentes. Según nuestros cálculos (no los de los autores), si la mejor configuración mantuviera su recuperación y su tasa de falsas alarmas mientras solo una de cada cien acciones estuviera desalineada, su precisión caería hasta alrededor del 10 %, y hasta aproximadamente el 1 % si fuera una de cada mil.

En 2001 hay un personaje que ilustra este enfoque. Cuando HAL predice que una unidad de comunicaciones está a punto de fallar, el Control de la Misión responde por radio que su ordenador gemelo 9000 en la Tierra no está de acuerdo. Bowman y Poole no encuentran ningún fallo en la unidad, y el Control de la Misión admite que se muestra escéptico ante la conclusión de su propio gemelo. Un «juez modelo» es ese gemelo. Lee la misma tarea y, a veces, llega a una respuesta mejor para una pregunta más específica. PocketOS muestra el riesgo sin necesidad de ningún atacante. Un juez que leyera «corrige el error de staging» habría tenido que distinguir entre una corrección y un atajo destructivo involuntario que también hiciera desaparecer el error. Usa a un juez como revisor para los casos ambiguos, pero no cuentes con que detecte daños que parezcan avances, y asegúrate de aplicar la política en otro sitio.

¿Quién redacta la política?

Si la tarea no puede ser la autoridad, alguien tiene que redactar la política, y en realidad hay dos autores. Ian Livingstone, director ejecutivo de Keycard, describió la autorización de un agente en una mesa redonda de AI Engineer NYC publicada el 17 de octubre como la intersección de dos políticas. Una es la política amplia y determinista de la organización sobre lo que nunca debe suceder y lo que siempre requiere una persona. La otra es la política más específica para la tarea que tiene entre manos el agente. El motivo por el que una empresa adoptó un agente de programación y el motivo por el que un desarrollador abrió esta sesión en concreto son intenciones diferentes, y la concesión de permisos es donde se solapan. La parte que corresponde a la organización es lo que le faltaba a PocketOS: una breve lista de acciones (borrar datos de producción, transferir dinero por encima de una cantidad determinada, acceder a los registros de otro usuario) que ningún agente puede realizar sin permiso humano explícito, independientemente de lo que diga su tarea.

Las versiones de investigación siguen el mismo esquema. La autorización de herramientas regida por intenciones de Zhu y Wang emite un certificado de corta duración a partir de la solicitud del usuario que solo puede restringir lo que ya permite la política estática, de modo que ni siquiera una tarea mal interpretada puede otorgar autoridad más allá de ese límite estático, aunque el artículo señala que aún así puede conceder más de lo que el usuario ha solicitado. El Progent de Shi et al. cuenta con un modelo que redacta una política específica para cada tarea en función de los nombres de las herramientas y los valores de los argumentos, y comprueba cualquier ampliación propuesta de dicha política. En AgentDojo, redujo el éxito de los ataques de alrededor del 40 % al 1 %, mientras que la utilidad benigna solo bajó del 79 % al 76 %. Solo el 6 % de las actualizaciones de la política fueron ampliaciones que habrían necesitado aprobación, y el artículo no probó cómo reaccionarían los usuarios ante las solicitudes de autorización correspondientes.

Los presupuestos y los límites de frecuencia también deben incluirse en la política, y Resy muestra lo que pasa cuando faltan. JC Bahr-de Stefano le pidió a un asistente de IA que le consiguiera una mesa en uno de los restaurantes de Manhattan donde es más difícil reservar. Según Business Insider, que describió el registro de actividad del agente, este envió a Resy unas 200 solicitudes por hora y realizaba consultas cada 0,4 segundos durante la apertura de reservas por la mañana hasta que Resy suspendió la cuenta, que más tarde reactivó. Cada una de esas solicitudes respondía a su intención. El agente necesitaba un presupuesto, y el borrador exploratorio de Dick Hardt sobre presupuestos AAuth trata el presupuesto como «una autorización, no una sugerencia». El token del agente lleva la asignación, el recurso la hace cumplir e informa de lo que queda, y un supervisor decide si ampliarla. Además, mantiene los presupuestos separados de los límites de tasa, de modo que un recurso puede limitar a un agente tanto a 100 solicitudes por minuto como a un gasto de cinco dólares. El contexto forma parte de la misma lista. Un pago que parece correcto por sí solo es incorrecto si se realizó otro igual cinco segundos antes, y leer el correo de un ejecutivo está mal para la mayoría de los agentes, pero está bien para el asistente de ese ejecutivo.

Los bancos ya han decidido quién paga cuando un agente malinterpreta tu intención. El acuerdo de servicios en línea actualizado de Chase considera que cualquier acción que realice un agente con tus credenciales es prueba de que tú la autorizaste, y te hace responsable. Los bancos no pueden asumir la responsabilidad de cada control de acceso basado en la intención mal implementado o inexistente, así que el cliente tiene que hacerlo.

La traducción como eslabón débil

Hacer cumplir una política de seguridad es un problema de ingeniería bien conocido, mientras que construir la política a partir de un lenguaje natural insuficientemente especificado sigue siendo un reto para el control de acceso basado en la intención. PAuth de Sharma et al. convierte una tarea firmada en reglas precisas por servicio y bloqueó las 634 llamadas de herramientas adversarias en su prueba de rendimiento; sin embargo, solo autorizó 71 de las 100 tareas originales sin pedir ayuda al usuario. Al reescribir las tareas para que fueran más explícitas, esa cifra subió a 100, y los ataques siguieron bloqueados en ambos casos.

NLACBench, que traduce las solicitudes de cambio de acceso de los usuarios finales en políticas, muestra por qué la traducción depende del contexto. Una solicitud como «Necesito acceso a nuestro GitLab» no puede convertirse en una regla hasta que el traductor sepa quién la pide, a qué GitLab se refiere y qué le permite su rol, así que la prueba de rendimiento le da al modelo una descripción de los usuarios, dispositivos y servicios de la empresa. Los mejores modelos tenían una precisión superior al 95 % cuando la empresa era pequeña. Un modelo abierto acertó menos del 20 % de las solicitudes cuando la empresa superó los 40 departamentos, hasta que los autores le proporcionaron solo la parte relevante de la empresa, lo que hizo que volviera a superar el 80 %.

En la novela de 2001, los planificadores ocultaron el propósito de la misión a los dos astronautas que estaban despiertos, y HAL se quedó solo con lo que Clarke llama el conflicto «entre la verdad y el ocultamiento de la verdad». La novela sí le da a HAL una regla de emergencia por escrito, la subrutina especial C1435-4, que le otorga el control cuando la tripulación está muerta o incapacitada, y luego deja que sea HAL quien decida cuándo se cumple esa condición. En el caso de los agentes, un traductor debería redactar la política a partir de la tarea, una persona debería confirmarla como máximo una vez por tarea, y la política confirmada debería convertirse en la autorización.

El coste es la fatiga del consentimiento. Cada aclaración que se envía a una persona para acertar con la política es otra solicitud, y la gente que ve suficientes solicitudes acaba aprobándolas sin leerlas. Los mejores modelos redactarán mejores borradores iniciales, y esa es la parte de este problema que más probabilidades tiene de mejorar por sí sola.

Cuánto cuesta aplicar las políticas

Los artículos más rigurosos miden lo que se pierde al aplicar las políticas, y las cifras no son pequeñas. Fides de Costa et al. informa de una finalización de tareas benignas cuando aplica de verdad sus comprobaciones. Con o3, completó el 57 % de las tareas benignas bajo sus políticas de flujo de información, frente al 41 % de un planificador básico bajo las mismas políticas y al 82 % de Fides con las comprobaciones desactivadas. El ajuste posterior de las indicaciones y la interfaz lo elevó al 65 %. El prototipo de Zhu y Wang no registró ninguna acción insegura completada en 198 pruebas de ataque o ambiguas, pero aceptó 40 borradores fuera de ámbito y no completó estrictamente ninguna de las 108 pruebas benignas. La mayoría de esas pruebas benignas terminaron como borradores revisables o llamadas a herramientas mal formadas, así que la política es solo una parte de esa pérdida. CaMeL de Debenedetti et al., el diseño en el que se basa mi argumento anterior de que la carrera armamentística de la inyección de comandos termina con un CaMeL, informa de una utilidad del 77 % en ejecuciones sin aplicación de políticas, y en una repetición independiente su modo estricto activó comprobaciones de políticas en aproximadamente la mitad de las tareas benignas. Las políticas que detienen los ataques también frenan mucho trabajo legítimo, así que cualquier equipo que las redacte tiene que sopesar ambas caras de esa disyuntiva bajo la misma configuración.

La sesión informativa a posteriori

La sesión informativa de 2001 solo se reproduce después de que HAL se apague, lo cual es el momento más cruel que se puede imaginar. Grabaron el objetivo antes de la partida pensando en una tripulación totalmente recuperada, y para cuando se reprodujo, cuatro de los cinco tripulantes ya estaban muertos. Los planificadores mantuvieron en secreto el verdadero objetivo de la misión, y la sesión informativa no dijo nada sobre cómo se comparaba con las vidas de la tripulación. La tarea de un agente está redactada en lenguaje natural y, a diferencia de la tripulación del Discovery, el sistema que la protege puede leer lo que se le pidió que hiciera. Alguien tiene que decidir qué puede hacer el agente sin el permiso de una persona, convertir cada tarea en una autorización que una persona haya confirmado y aceptar que algunas tareas legítimas se quedarán atascadas en los límites.

Una autorización no sirve de nada a menos que algo la haga cumplir, y si el agente puede modificar o eludir esa aplicación, la autorización deja de ser un límite fiable. La próxima entrega de esta serie analiza cómo mantener esa aplicación fuera del alcance del agente y en todos los caminos que este podría tomar para sortearla.

Hermes, un asistente de IA, ha ayudado en la investigación y la redacción de esta entrada. Le asignamos un presupuesto para este artículo y ha aprendido que «una autorización, no una sugerencia» también se aplica al recuento de palabras.