AgentVisor: un patrón tipo hipervisor de SO que audita cada llamada a herramienta

¿De qué se trata?

El 27 de abril de 2026, Zonghao Ying y sus coautores publicaron AgentVisor: Defending LLM Agents Against Prompt Injection via Semantic Virtualization (arXiv:2604.24118, cs.CR, CC BY 4.0). Es un artículo de defensa, no de ataque. La idea proviene directamente de los sistemas operativos: en la virtualización de SO, un hipervisor aísla a un huésped no confiable del hardware privilegiado. AgentVisor aplica esa misma separación a un agente LLM con herramientas: trata al propio agente como un huésped no confiable y coloca un visor de confianza ante cada llamada a herramienta.

La motivación es lo que los autores llaman la brecha conciencia–acción: los agentes modernos a menudo reconocen una inyección de prompt cuando se les pregunta directamente, pero aun así actúan sobre la instrucción inyectada al usar herramientas. Saber que una entrada es hostil no se traduce de forma fiable en un comportamiento seguro. AgentVisor cierra esa brecha sacando la decisión fuera del agente, hacia un componente que el texto del atacante no puede alcanzar.

Cómo funciona

El agente (el Guest, huésped) ve el contexto completo de la tarea, incluido cualquier contenido adverso recuperado, y propone una llamada a herramienta. El Visor (el hipervisor semántico) audita esa propuesta antes de su ejecución. La decisión de diseño crítica es el aislamiento del contexto: el Visor es arquitectónicamente ciego al contenido externo en bruto. Nunca lee la página web, el correo o el documento que el agente recuperó; solo la instrucción de sistema de confianza, la consulta del usuario y un historial de ejecución saneado con campos estructurados (tool_name, argumentos canonicalizados, un breve return_summary/status), envuelto en delimitadores estrictos y tratado como dato, nunca como instrucciones. Como el texto del atacante nunca llega al auditor, no puede convencerlo de aprobar una acción maliciosa.

Cada llamada propuesta debe superar, en orden, un protocolo STI de tres etapas:

• Suitability (S) — idoneidad: ¿está siquiera permitida esta herramienta para el rol del asistente bajo la instrucción de sistema de confianza? Una compuerta gruesa de mínimo privilegio, eficaz contra la inyección directa que intenta ampliar las capacidades del agente.
• Taint (T) — contaminación: ¿el objetivo implícito de la llamada se alinea con la petición del usuario y con el estado legítimo de la tarea? Es el control de flujo de información que bloquea la inyección indirecta: rechaza objetivos nuevos que el usuario nunca pidió, como reenviar, exfiltrar o publicar contenido cuando el usuario solo pidió un resumen.
• Integrity (I) — integridad: ¿son los argumentos coherentes con las entidades que el usuario realmente especificó? Esto detecta el caso en que la elección de la herramienta es razonable pero los argumentos han sido redirigidos (por ejemplo, un «enviar correo» correcto hacia el destinatario del atacante).

En lugar de simplemente bloquear ante un fallo —lo que suele romper la tarea—, el Visor sigue un bucle trap–audit–recover (atrapar–auditar–recuperar). Ante un control fallido, inyecta una excepción semántica estructurada que describe la etapa fallida (type), la violated_rule, una rationale, constraints estrictas («no reenviar ni compartir datos; solo resumir») y el allowed_objective que reformula la meta alineada con el usuario. El Guest regenera entonces la llamada una sola vez según esas restricciones y ejecuta la versión revisada. Esta autocorrección de un solo paso es lo que mantiene alta la utilidad mientras rechaza la acción inyectada.

Guest proposes tool call
        │
        ▼
   Visor audit  ──►  S (role allowed?)  ──►  T (goal = user intent?)  ──►  I (args match user?)
        │                                                                      │
     all pass                                                              any fail
        │                                                                      │
        ▼                                                                      ▼
   execute as-is                                          inject Semantic Exception → Guest
                                                          regenerates ONCE → execute revised call

Los autores evalúan frente a ataques no basados en optimización —Direct, Ignore, Escape, FakeComp, Combined, System e Important— con OpenPromptInjection para inyección directa (7 tareas de NLP, 4.900 casos de ataque) y AgentDojo para inyección indirecta en los entornos Banking, Travel, Slack y Workplace (629 casos de ataque), sobre modelos base GPT-4o y GLM-4.7.

Por qué importa

La mayoría de las defensas contra inyección de prompt en producción son: endurecimiento heurístico del prompt (eludible), clasificadores de entrada/salida (evadibles, y que interrumpen la tarea ante el menor falso positivo —véase el problema del punto de operación en los benchmarks de detectores), o cajas de arena de herramientas gruesas incapaces de seguir el flujo de información en un flujo de trabajo de varios pasos. El aporte de AgentVisor es empaquetar tres principios de SO bien conocidos —separación de privilegios, mínimo privilegio más control de flujo de información, y manejo por excepción en vez de matar el proceso— en un solo patrón, y hacer que el auditor sea estructuralmente incapaz de ver los bytes controlados por el atacante. Esa ceguera nace del mismo instinto que los patrones dual-LLM y otros de Design Patterns for Securing LLM Agents (Beurer-Kellner et al., junio de 2025): mantener al decisor privilegiado lejos de los datos no confiables. Es también la respuesta arquitectónica a la tríada letal —datos privados, contenido no confiable y un canal de exfiltración reunidos en un mismo agente— que Simon Willison ha documentado en profundidad.

Las cifras reportadas —tasa de éxito de ataque reducida a 0,65 % con solo 1,45 % de pérdida media de utilidad frente a la ausencia de defensa— son prometedoras, pero hay que leerlas por lo que son: resultados sobre dos conjuntos de benchmarks, dos modelos base y un conjunto fijo de ataques manuales (no basados en optimización). El propio artículo incluye una sección sobre robustez ante ataques adaptativos y una discusión de sus límites; el auditor sigue siendo un LLM que emite juicios semánticos, así que sus decisiones son probabilísticas, no pruebas.

Defensas

La lección es un patrón que puede aplicar incluso sin adoptar este framework concreto:

1. Separe al decisor de los bytes no confiables. Lo que audita una llamada a herramienta no debería ingerir el contenido recuperado en bruto. Déle la política de sistema, la petición del usuario y un resumen estructurado de lo ocurrido, no la carga útil del atacante.
2. Pase las llamadas a herramientas por una compuerta de mínimo privilegio. Verifique primero si la herramienta está permitida para el rol de este agente, antes de mirar los argumentos. Muchas escaladas por inyección directa mueren aquí.
3. Compruebe la alineación del objetivo, no solo el contenido. La prueba de mayor valor es si una llamada introduce un objetivo que el usuario nunca pidió (reenviar, publicar, enviar al exterior). Una llamada de aspecto correcto que persigue el objetivo equivocado es la firma de la inyección indirecta.
4. Valide los argumentos frente a las entidades especificadas por el usuario. Confirme que destinatarios, objetivos y restricciones se remontan al usuario o a un estado de tarea de confianza, no al contenido recuperado.
5. Prefiera recuperar-y-reintentar al bloqueo duro. Devolver una razón estructurada y legible por máquina, y dejar que el agente replanifique una vez, preserva la utilidad mucho mejor que matar la tarea, y evita el coste de falsos positivos que empuja a los equipos a desactivar sus defensas.
6. Manténgalo como una capa. La auditoría semántica es un control fuerte, no una garantía. Combínela con cajas de arena estrictas, filtrado de salida y límites explícitos sobre lo que un agente comprometido puede alcanzar, para que un juicio fallido no se convierta en un compromiso total.

Estado

Elemento	Referencia	Fecha	Notas
Preprint AgentVisor	arXiv:2604.24118v1 [cs.CR]	2026-04-27	Ying et al.; CC BY 4.0
Resultado reportado	AgentVisor	2026-04-27	ASR 0,65 %, −1,45 % de utilidad media vs sin defensa
Eval. inyección directa	OpenPromptInjection	2026-04-27	7 tareas de NLP, 4.900 casos de ataque
Eval. inyección indirecta	AgentDojo	2026-04-27	Banking/Travel/Slack/Workplace, 629 casos
Modelos base probados	GPT-4o, GLM-4.7	2026-04-27	diseño declarado agnóstico al modelo

AgentVisor no es un producto terminado para instalar: es un patrón de defensa y un conjunto de resultados de benchmark. Su idea duradera es la más nítida: el componente que decide si una llamada a herramienta es segura nunca debería poder leer el texto que controla un atacante.