La brecha de seguridad agente-humano: lo que la producción despliega, lo que la investigación estudia
Un paper de UCLA del 23 de mayo de 2026 audita 59 estudios académicos, 21 sistemas de agentes en producción y 26 plugins de seguridad, y constata que las defensas que prefieren los investigadores no tienen ningún despliegue en producción.
¿De qué se trata?
El 23 de mayo de 2026, tres investigadores de UCLA — Peiran Wang, Ying Li y Yuan Tian — publicaron Reframing LLM Agent Security as an Agent–Human Interaction Problem (arXiv:2605.24309). El paper no propone un ataque nuevo ni una defensa nueva. Es una auditoría sistemática de cómo se defiende a los agentes en la práctica en 2026: mapea 59 papers académicos, 21 sistemas de agentes en producción y 26 plugins de seguridad, con corte a abril de 2026. El resultado es una de las fotografías más nítidas publicadas este año sobre la distancia entre la investigación en seguridad de agentes y los sistemas que efectivamente se entregan.
Cómo funciona
Wang et al. parten de la constatación de que casi todos los agentes en producción — Claude Code, Cursor, Copilot, Gemini CLI, ChatGPT Agent, Microsoft 365 Copilot, asistentes basados en MCP — colocan a un humano en algún punto del bucle. El paper clasifica estos mecanismos de Agent-Human Interaction (AHI) en cinco categorías:
- Especificación de política — el usuario escribe reglas por adelantado («nunca empujes a main», «sin salida de red»). Adoptada por al menos 14 de los 21 sistemas en producción.
- Aprobación en tiempo de ejecución — el agente pregunta «¿puedo ejecutar este comando / enviar este correo / llamar a esta herramienta?» antes de cada acción sensible. También adoptada por 14+ sistemas de 21.
- Configuración de alcance — el usuario escoge listas blancas de archivos, herramientas, hosts o dominios que el agente puede tocar. Igualmente dominante.
- Anclaje de intención — el sistema intenta vincular cada acción a una intención de usuario verificable antes de ejecutarla. Muy estudiada en la academia, cero despliegues en producción según la auditoría.
- Etiquetado de confianza — celosías de confianza o etiquetas de procedencia sobre cada token que entra al contexto, al estilo del control de flujo de información. También muy estudiada, también cero despliegues en producción.
La asimetría es brutal: las tres categorías que los profesionales realmente despliegan reciben escasa atención académica, mientras que las dos categorías preferidas por los investigadores no han llegado a un solo producto entregado. El paper lo atribuye a la carga cognitiva. El etiquetado de confianza, en particular, exige a los usuarios razonar sobre la procedencia de los datos a una granularidad que no encaja con sus modelos mentales — cada token etiquetado, cada flujo rastreado. La especificación de política y la configuración de alcance, aunque más gruesas, se alinean con la forma en que los operadores ya piensan.
Los autores formalizan a continuación el modo de falla del enfoque dominante. La aprobación en tiempo de ejecución, escalada a sesiones largas de agente, produce fatiga de aprobación: un agente de programación de 2026 puede disparar decenas de llamadas a herramientas por tarea, y los usuarios terminan o bien validando mecánicamente cada diálogo, o bien desactivándolo por completo. Los autores citan este fenómeno como causa raíz de varios incidentes de inyección indirecta en 2025-2026, donde el agente pedía debidamente confirmación y el humano hacía clic debidamente en «sí» sobre una solicitud cuyo contexto ya había sido envenenado.
Por qué importa
El replanteamiento tiene dos consecuencias prácticas para quien despliega un agente.
Primero, reubica el problema de diseño. La pregunta ya no es ¿se puede confiar en que el LLM decida? sino ¿en qué punto del flujo de alineación de intención del humano puede el LLM aportar más palanca al menor riesgo? Es una pregunta de UX con dientes de seguridad, y se alinea con lo que la Agents Rule of Two de Meta y la lethal trifecta de Simon Willison ya implicaban: la defensa es arquitectónica, no conductual.
Segundo, esto explica por qué tantas defensas limpias sobre papel fallan en auditoría. El anclaje de intención presupone que los usuarios articularán su intención de forma estructurada. El etiquetado de confianza presupone que razonarán sobre etiquetas. Ninguno de los dos supuestos resiste una sesión real de agente de programación. Un SoK de diciembre de 2025 sobre Trust-Authorization Mismatch in LLM Agent Interactions (arXiv:2512.06914) llega a una conclusión similar desde otro ángulo: el modelo de autorización que el usuario cree estar aplicando y el que el agente aplica realmente divergen de forma sistemática.
Defensas
El paper es descriptivo, no prescriptivo, pero la auditoría sugiere una lista concreta para los equipos que despliegan agentes a mediados de 2026:
- Priorizar la configuración de alcance, no la aprobación en tiempo de ejecución. Un agente correctamente acotado reduce la cantidad de diálogos de aprobación, único modo de combatir la fatiga.
- Tratar la especificación de política como un artefacto de primer nivel. Versiónela, sométala a code-review, entréguela junto con el agente — del mismo modo que una política IAM.
- Reservar la aprobación en tiempo de ejecución para acciones irreversibles. Escrituras a base de datos, movimientos de dinero, merges de código, envíos externos. Todo lo demás debería decidirse por política por adelantado.
- No apoyarse únicamente en el anclaje de intención o el etiquetado de confianza. Son direcciones de investigación útiles pero, según la auditoría, no están productizadas. Apílelos sobre los tres mecanismos dominantes, no en su lugar.
- Medir la fatiga de aprobación. Registre el número de aprobaciones por sesión y la tasa de clics. Un 95 % de validación mecánica es una señal de seguridad más elocuente que cualquier salida de clasificador.
Estado
| Elemento | Fecha | Estado |
|---|---|---|
| Paper publicado (arXiv:2605.24309) | 23 mayo 2026 | Preprint público |
| Sistemas en producción auditados | Abril 2026 | 21 sistemas, 26 plugins |
| Corpus académico | 2022-2026 | 59 papers |
| SoK relacionada (Trust-Authorization Mismatch) | Dic. 2025 | arXiv:2512.06914 |
| Adopción industrial del marco AHI | Pendiente | En fase de discusión |
El paper es un preprint y no ha sido revisado por pares al momento de esta publicación. Su contribución empírica — la auditoría de 21 sistemas en producción — es la parte más directamente útil para los defensores hoy, y la menos susceptible de cambiar en una revisión.