Una nueva encuesta sobre seguridad agentic AI nombra cuatro patrones de ataque concretos contra agentes de operaciones basados en LLM que tienen acceso real a producción. Inyección de prompt: instrucciones maliciosas embebidas en un ticket Jira o página wiki dirigen al agente hacia una acción insegura. Envenenamiento de retrieval: runbooks e historiales de incidentes corrompidos sesgan los diagnósticos del agente hacia los objetivos del atacante. Jamming de retrieval: inundar bases de conocimiento con documentos bloqueadores dispara bucles de rechazo, estancando la respuesta a incidentes — un denial-of-service contra el ciclo de decisión del agente. Manipulación de telemetría: los atacantes influyen en métricas y logs para dirigir las decisiones de mitigación sin tocar el modelo. Hilo común: el problema confused-deputy. El agente tiene acceso API legítimo, pero los artefactos que dan forma a sus decisiones — tickets, logs, transcripts, páginas wiki, documentos recuperados — son exactamente las superficies que los atacantes pueden comprometer.
La defensa propuesta es arquitectónica en lugar de a nivel de modelo. División propuesta vs ejecución: el modelo de lenguaje razona, recupera evidencia, redacta propuestas de cambio — y no puede ejecutar escrituras. Todos los cambios de producción pasan a través de compuertas no-bypaseables que aplican verificaciones de política, verificación de invariantes, aprobación humana donde el cambio lo amerita, y rollback escalonado. El escalonamiento de riesgo al que llega la encuesta: asistencia de solo-lectura es bajo-riesgo; ejecución acotada con compuertas fuertes es defendible; auto-curación abierta sin andamiaje de verificación es la afirmación de alto-riesgo que merece escepticismo. La brecha de evaluación es la parte a la que la mayoría de builders deberían prestar atención: los benchmarks actuales pierden trazas de tool-call, tasas de violación de compuerta, comportamiento de entrada adversarial, tasas de tormenta-de-rechazo bajo jamming, completitud de rollback. Sistemas que rinden bien en incidentes limpios pueden colapsar bajo tickets Jira hostiles y la suite de eval nunca lo sabría.
Contexto del ecosistema. Este es el lado threat-model de lo que Anthropic envió esta semana con Managed Agents y MCP Tunnels. Las primitivas arquitectónicas que permiten a los agentes alcanzar sistemas de producción son también donde se abre la clase de ataque confused-deputy. El screening de acción destructiva del Modo Auto de Anthropic (anunciado en Code With Claude) es una forma de la compuerta que esta encuesta pide; la pregunta más amplia es qué conjunto de compuertas es suficiente para qué nivel de riesgo. La brecha del panorama actual de eval es estructural: SWE-bench Verified, MMLU, y los benchmarks de agente incidente-limpio miden capacidad bajo entradas cooperantes. La robustez adversarial — tasas de tormenta-de-rechazo, tasas de violación de compuerta, resistencia a inyección de prompt — está en gran parte sin medir a nivel benchmark. La narrativa Capability Curve de Anthropic (62 a 87% en SWE-bench Verified) mide un eje; el encuadre de esta encuesta muestra que el eje ortogonal es donde los agentes grado-producción realmente viven o mueren. Para los builders del ecosistema wrapper (LangGraph, AutoGen, CrewAI), el encuadre confused-deputy tiene implicaciones de diseño: las capas de gestión de estado y enrutamiento de tool-call son donde las compuertas necesitan vivir, no en el modelo mismo.
Lunes: si envías agentes con acceso de producción (runners CI, respuesta a incidentes, automatización de infraestructura, automatización de ticketing de soporte), audita tu stack contra los cuatro patrones esta semana. Acciones concretas. Primero, lista cada entrada que el agente trata como confiable — tickets, wiki, telemetría, threads de Slack, documentos recuperados — y asume que cada uno puede ser hostil; la amenaza es contenido inyectado por un atacante, no jailbreak de modelo. Segundo, implementa la división propuesta-ejecución: el agente redacta, una compuerta no-bypaseable (verificación de política, verificar invariante, aprobación humana opcional) ejecuta. La compuerta es donde se concentra la revisión de seguridad, no el prompt del modelo. Tercero, agrega evals para entradas adversariales — como mínimo, tickets con prompt-inyectado, contextos de retrieval envenenados, y escenarios de tormenta-de-rechazo. Cuarto, vigila las tasas de tormenta-de-rechazo como métrica explícita. Un agente que "no actúa bajo entradas hostiles" parece seguro en aislamiento pero estanca la respuesta a incidentes real bajo jamming — ambos modos de falla necesitan presupuestos separados. La trampa del benchmark de eval limpio es real. La robustez adversarial es el siguiente eje de eval después de la capacidad cruda, y la mayoría de despliegues de agentes de producción no la miden todavía.