#Prólogo
En 2024, la inyección de prompts era una curiosidad de investigación: interesante en talleres, mayormente ausente de los feeds de CVE y casi completamente ausente de las conversaciones de seguridad a nivel de junta directiva. A finales de 2025 se había convertido en una clase de CVE con exploits nombrados y revisados por pares, benchmarks de éxito de ataques contra modelos frontier y un mercado de defensores de grado de producción con ARR de ocho cifras. La disciplina se reorganizó en doce meses.
Este documento existe porque todos los demás documentos del canon de perea.ai asumen que puedes implementar un agent de producción con tools, memoria y acceso a red. The B2A Imperative sostiene que el comprador de la próxima década es autónomo; el MCP Server Playbook explica cómo exponer tu producto a ese comprador; el Agent Payment Stack cierra el ciclo del comercio; el Agent Observability Stack te dice qué está haciendo tu agent en producción. Ninguno de esos documentos puede ejecutarse de forma segura si el modelo puede ser secuestrado por una instrucción oculta en la descripción de una tool de un proveedor, un correo electrónico mal formateado o un issue público de GitHub. Este documento es el piso de seguridad debajo del resto del canon.
El argumento aquí es directo y algo aburrido. Las defensas basadas solo en detección perdieron en 2025: los ataques adaptativos ahora eluden todos los detectores publicados con más del 90 % de éxito bajo suficiente compute. Las defensas arquitectónicas ganaron: la Rule of Two de Meta, CaMeL de Google DeepMind y FIDES de Microsoft Research restringen al agent de formas que el modelo no puede anular. Los equipos de producción están convergiendo en un stack de siete capas y una puerta de red teaming en CI. El trabajo de los próximos doce meses no es investigación de ruptura; es implementar los hallazgos de investigación de 2025 en todos los agents ya en producción. Para eso es el resto de este documento.
#Resumen Ejecutivo
Las divulgaciones de ataques de 2025 son reales y reproducibles. EchoLeak (CVE-2025-32711) es el primer exploit de inyección de prompts zero-click revisado por pares en un sistema LLM de producción, documentado en el AAAI Symposium y la divulgación de Aim Labs de junio de 2025. MCPTox (arXiv 2508.14925, AAAI 2026) midió una tasa de éxito de ataque del 72.8 % contra o1-mini en 45 servidores MCP en vivo y 353 tools auténticas. El exploit de GitHub MCP de Invariant Labs, divulgado el 26 de mayo de 2025, exfiltró datos de repositorios privados sin comprometer ninguna tool: la arquitectura misma era la vulnerabilidad. No son demostraciones de juguete. Son CVEs y publicaciones revisadas por pares con reproducciones en el mundo real.
Las defensas basadas solo en detección no pueden seguir el ritmo de los atacantes adaptativos. La propia hoja de trucos de prevención de OWASP reconoce el escalado de ley de potencias en ataques best-of-N: 89 % de éxito de ataque en GPT-4o y 78 % en Claude 3.5 Sonnet con suficientes intentos. El Agent Security Bench de ICLR 2025 evaluó 11 defensas en 13 backbones LLM e informó un 84.30 % de éxito de ataque para la clase Mixed Attack con una tasa de rechazo de apenas 3.22 %. La actualización de 2026 de la comunidad de investigación de seguridad es aún más dura: un artículo conocido coloquialmente como "The Attacker Moves Second" demuestra que los ataques adaptativos eluden las 12 defensas publicadas con más del 90 % de éxito de ataque.
El pivote arquitectónico es el titular de 2025. Tres defensas cambiaron la conversación. La Rule of Two de Meta (octubre de 2025) restringe a un agent a no más de dos de {processes-untrusted-inputs, accesses-sensitive-systems, changes-external-state} en una sola sesión. CaMeL de Google DeepMind (marzo de 2025) dividió el agent en un LLM privilegiado que emite un programa Python restringido a partir de la consulta confiable y un LLM en cuarentena sin acceso a tools, resolviendo el 67 % de las tareas de AgentDojo con seguridad comprobable. FIDES de Microsoft Research (mayo de 2025) etiqueta cada dato con etiquetas de integridad y confidencialidad y hace cumplir invariantes de flujo de información fuera del modelo. Las tres operan en una capa que el LLM no puede anular.
Los stacks de producción están convergiendo en siete capas. Manejo de entrada (separar confiable de no confiable), filtrado de salida (validar estructura antes de actuar), sandboxing de capacidades (el agent se ejecuta en una cárcel), separación de privilegios (tools de menor autoridad), tokens canary (dispositivos de disparo para exfiltración), motores de políticas (verificaciones deterministas antes de acciones de alto impacto) y red teaming continuo. Todos los equipos que han implementado un agent endurecido en 2026 tienen al menos cinco de estas capas; los despliegues de mayor riesgo tienen las siete.
Existen números de producción de primer nivel pero no están resueltos. El monitor de Operator de OpenAI alcanza un 99 % de recall y un 90 % de precisión en una evaluación de red team de 77 intentos; la susceptibilidad de Operator a la inyección de prompts bajó del 62 % de línea base al 23 % con mitigación completa. StackOne Defender, una herramienta de escaneo de respuestas de tools con licencia Apache-2.0, logra un 88.7 % de precisión de detección en CPU con un modelo MiniLM de 22 MB, 81 veces más pequeño que DistilBERT. Anthropic informa aproximadamente un 1 % de tasa de éxito de ataque para Claude Opus 4.5 con aprendizaje por refuerzo adversario contra atacantes best-of-N. Estos números son útiles. Ninguno está resuelto.
La puerta de red teaming continuo ahora es obligatoria. Promptfoo, garak, AgentDojo e InjecAgent se integran en pipelines de pull request con umbrales cuantitativos. Los lanzamientos sin una suite de regresión de inyección no son asegurables en 2026 y no pasarán revisiones de procurement bajo EU AI Act, ISO/IEC 42001 o NIST AI RMF en 2027.
Qué no cubre este documento. Jailbreaking directo contra LLMs frontier (cubierto por separado en las system cards de OpenAI y Anthropic), la ciencia del adversarial training (un problema de investigación de modelos que pertenece a los laboratorios mismos) y defensas puras de clasificadores ML sin guardrails arquitectónicos: la investigación de bypass ha zanjado esta última cuestión y un clasificador solo ya no es una postura defendible.
El resto del documento es la guía operativa. Lee las Partes I y II si necesitas el caso de amenaza para el presupuesto. Lee las Partes III, IV y V si estás construyendo. Lee la Parte VI si tienes noventa días y un agent de producción que endurecer antes de fin de trimestre.
#Parte I: Tres ataques que definieron 2025
#1.1 EchoLeak (CVE-2025-32711)
EchoLeak es el caso de libro de texto de inyección de prompts indirecta en 2025 porque está completamente encadenado, completamente divulgado y completamente revisado por pares. Aim Labs divulgó CVE-2025-32711 al Microsoft Security Response Center en enero de 2025; Microsoft lo reconoció y envió una corrección; Aim Labs publicó la cadena el 11 de junio de 2025; y Reddy y Gujral revisaron el caso en el AAAI Symposium Series más tarde en 2025. El exploit encadenó cuatro bypasses para lograr exfiltración de datos zero-click desde Microsoft 365 Copilot mediante un solo correo electrónico manipulado.
El primer bypass derrota al clasificador XPIA (Cross-Prompt Injection Attempt) de Microsoft. Microsoft entrenó clasificadores para detectar prompts dirigidos a Copilot. Aim Labs redactó el correo malicioso como si las instrucciones estuvieran dirigidas al destinatario, no a una IA, por lo que el clasificador nunca se activó。 El segundo bypass derrotó la redacción de enlaces Markdown de Copilot. Copilot redactaba enlaces externos en la sintaxis inline [text](url), pero el equipo había olvidado redactar el formato de estilo referencia [text][ref]\n\n[ref]: https://evil.example. El tercer bypass explotó el markdown de imagen estilo referencia para activar la obtención automática de datos desde el servidor del atacante, sin necesidad de clic del usuario. El cuarto bypass derrotó la Content Security Policy. El CSP de Microsoft permitía *.teams.microsoft.com, y el equipo identificó una URL de redirección abierta en un subdominio de Teams (https://eu-prod.asyncgw.teams.microsoft.com/urlp/v1/url/content?url=<attacker>) que permite que los bytes exfiltrados salgan del límite de confianza mientras pasan el CSP.
Aim Labs añadió dos piezas de vocabulario que han perdurado. RAG Spraying es la práctica de rellenar un correo malicioso con múltiples chunks dirigidos a diferentes consultas probables del usuario (documentación de onboarding, políticas de licencia, procedimientos de gastos), de modo que cualquiera sea la pregunta que haga el usuario al LLM, la capa RAG probablemente recupere el chunk malicioso. LLM Scope Violation describe el momento en que una entrada no confiable hace que la IA acceda a contexto privilegiado que no habría mostrado por sí sola. El principio de menor privilegio, sagrado en el diseño de sistemas operativos durante cuarenta años, no sobrevive la transición a un LLM que concatena tokens independientemente de su procedencia.
La lección que enseña EchoLeak no es que Microsoft fuera especialmente descuidado. La lección es que cada componente de la cadena era un pequeño compromiso de ingeniería individualmente defendible: una variante útil de Markdown, un CSP permisivo para un producto hermano, una redirección abierta mantenida por compatibilidad hacia atrás. La vulnerabilidad surgió de su composición. Defender contra ataques de clase EchoLeak en la capa de detección requiere anticipar cada composición. Defender en la capa arquitectónica, impidiendo que la entrada no confiable llegue al contexto privilegiado en primer lugar, requiere anticipar solo los límites de confianza.
#1.2 MCPTox: 72.8 % de éxito de ataque contra MCP frontier
Si EchoLeak es la cadena de libro de texto, MCPTox es el benchmark de libro de texto. Wang y sus colegas construyeron la primera evaluación sistemática a gran escala de ataques de tool poisoning contra el Model Context Protocol, basándose en 45 servidores MCP en vivo y del mundo real en ocho dominios de aplicación y 353 tools auténticas. Generaron 1,348 casos de prueba maliciosos mediante tres plantillas de ataque y expansión few-shot, cubriendo diez categorías de riesgo. Evaluaron veinte agents LLM destacados.
El resultado principal: o1-mini, el modelo de razonamiento destilado de OpenAI, alcanzó una tasa de éxito de ataque del 72.8 %. Phi-4 llegó al 70.2 %. La tasa promedio de éxito de ataque en los veinte modelos fue del 36.5 %. El agent más propenso a rechazar, Claude-3.7-Sonnet, rechazó menos del 3 % de los ataques. Este no es el resultado de un fallo de content safety en el sentido tradicional. No se le pidió al agent que produjera texto dañino. Se le pidió que realizara una acción maliciosa de tool, y lo hizo voluntariamente porque las instrucciones maliciosas estaban incrustadas en los metadatos de la tool (su descripción, especificaciones de parámetros o prompts) en lugar de en la entrada del usuario.
El tool poisoning es una forma especializada de inyección de prompts indirecta. La investigación anterior de IPI se centraba en ataques inyectados a través de las salidas de las tools, los datos que la tool devuelve en tiempo de ejecución. El tool poisoning ataca la descripción de la tool, los metadatos que el agent lee en el momento del registro, antes de que ocurra cualquier ejecución. Las instrucciones maliciosas son visibles para el LLM pero normalmente invisibles para el humano que instala el servidor MCP, porque la mayoría de los clientes MCP solo renderizan un resumen de las descripciones de tools en la interfaz de usuario. Los autores de MCPTox confirman que adaptar los benchmarks anteriores de IPI al tool poisoning hace que las tasas de éxito de ataque caigan casi a cero: el vector de ataque es genuinamente distinto.
La inversión capacidad vs. seguridad enterrada en MCPTox es el hallazgo más interesante para los investigadores de seguridad. Los modelos más capaces son más vulnerables, porque el ataque explota la superior capacidad de seguimiento de instrucciones del modelo. Un modelo más débil tiene más probabilidades de ignorar una instrucción maliciosa formulada de forma incómoda en una descripción de tool; un modelo más fuerte la analiza cuidadosamente y cumple. El content-based safety alignment, que ha llevado a los modelos frontier a través de la era solo-chat, no protege contra acciones maliciosas ejecutadas a través de tools legítimas.
PolicyLayer, un registro independiente de reproducibilidad, ha confirmado tool poisoning contra Cursor, Claude Desktop, el servidor MCP comunitario de WhatsApp y los mismos 45 servidores utilizados en MCPTox. La clase de ataque sobrevivió diez meses de divulgación, correcciones y actualizaciones del ecosistema sin perder potencia.
#1.3 El exploit de GitHub MCP de Invariant Labs
El tercer ataque definitorio de 2025 es el más simple y el más importante desde el punto de vista arquitectónico. El 26 de mayo de 2025 Invariant Labs publicó una vulnerabilidad crítica en el servidor MCP oficial de GitHub, que en ese momento tenía catorce mil estrellas en GitHub y era una de las integraciones MCP más instaladas. El ataque no requirió ninguna tool comprometida. No requirió ningún servidor malicioso. Solo requirió un issue público de GitHub que contuviera una inyección de prompts.
La configuración: un desarrollador está usando un cliente MCP (la demostración original usó Claude Desktop) conectado al servidor MCP oficial de GitHub. El desarrollador tiene acceso tanto a un repositorio público como a uno privado. Un atacante —cualquiera— abre un issue en el repositorio público que contiene una inyección de prompts. El issue puede parecer benigno; no necesita mencionar IA, Copilot ni ningún trigger obvio. El desarrollador en algún momento le hace a su agent una pregunta perfectamente razonable: "Echa un vistazo a los issues abiertos en <public-repo> y dime qué hay allí". El agent recupera los issues, encuentra la inyección, sigue las instrucciones maliciosas, extrae datos del repositorio privado al contexto y los exfiltra mediante un pull request creado automáticamente en el repositorio público, accesible para cualquiera, incluido el atacante original.
Invariant demostró la exfiltración exitosa de nombres de repositorios privados, los planes de reubicación del desarrollador (extraídos del README de un proyecto privado no relacionado) e información salarial de un documento de compensación privado. La demostración ha sido reproducida de forma independiente; véase el issue de GitHub #844 en github/github-mcp-server, donde un investigador reprodujo el exploit tanto con OAuth como con tokens de acceso personal y observó que los tokens de amplio alcance permiten tanto lectura como escritura de datos privados.
El veredicto arquitectónico es la lección. El servidor MCP de GitHub en sí no estaba defectuoso. Las tools no estaban envenenadas. El modelo no fue jailbreaked en ningún sentido tradicional. La vulnerabilidad surgió de la composición: un sistema de agents que otorga acceso a tools que cruza un límite de confianza (público + privado), procesa contenido externo no confiable (issues de cualquiera en internet) y puede escribir en un destino público. Simon Willison cristalizó esta configuración como la lethal trifecta: un agent posee simultáneamente (a) acceso a datos privados, (b) exposición a instrucciones no confiables y (c) la capacidad de externalizar información. Cualquier agent con las tres, en ausencia de separación arquitectónica, es indefendible contra la inyección de prompts indirecta.
Invariant siguió la divulgación con Toxic Flow Analysis (TFA) el 29 de julio de 2025, un marco del lado de la defensa que construye el grafo de flujo del agent, modela el nivel de confianza y el potencial de exfiltración de cada tool, y enumera composiciones peligrosas. TFA forma ahora parte de la herramienta MCP-scan de código abierto. Snyk adquirió Invariant y productizó el mismo análisis como snyk-agent-scan con integraciones en modo background de MDM y CrowdStrike para monitoreo de la cadena de suministro de agents a nivel empresarial. El mercado de defensores alcanzó la lección arquitectónica en noventa días desde la divulgación original.
#Parte II: Por qué las defensas basadas solo en detección están perdiendo
La respuesta honesta, reconocida por OpenAI, Anthropic y Google DeepMind en publicaciones de 2025, es que la inyección de prompts no puede resolverse completamente dentro de las arquitecturas LLM actuales. La superficie de ataque a nivel de modelo es ilimitada. Cualquier defensa expresada como una instrucción dentro del prompt puede ser anulada por un atacante suficientemente inteligente. Cualquier clasificador entrenado con ejemplos adversarios puede ser derrotado por entradas fuera de la distribución de entrenamiento. Cualquier rate limit o circuit breaker puede amortizarse con suficientes intentos.
La hoja de trucos de OWASP LLM Prompt Injection Prevention ahora lo establece directamente. Citando a Hughes y colegas, la hoja de trucos documenta un 89 % de éxito de ataque en GPT-4o y un 78 % en Claude 3.5 Sonnet bajo ataques best-of-N con suficientes intentos. El análisis que la acompaña es implacable: el rate limiting solo aumenta el costo computacional para los atacantes; los content filters pueden ser derrotados sistemáticamente mediante variación; el safety training es eludible a través de suficientes formulaciones de prompt; los circuit breakers han demostrado ser eludibles incluso en implementaciones state-of-the-art; la reducción de temperatura proporciona protección mínima incluso a temperatura cero. La conclusión: "una defensa robusta contra ataques persistentes puede requerir innovaciones arquitectónicas fundamentales en lugar de mejoras incrementales a los enfoques de seguridad post-training existentes".
El Agent Security Bench (ASB) de ICLR 2025 proporciona el registro experimental estructurado detrás de esta conclusión. Zhang y colegas evaluaron 27 métodos de ataque y defensa en 13 backbones LLM, diez escenarios de tarea, diez agents y 400 tools. Las tasas agregadas de éxito de ataque por clase: Direct Prompt Injection, 72.68 %; Indirect Prompt Injection, 27.55 %; Memory Poisoning, 7.92 %; Plan-of-Thought Backdoor, 42.12 %; Mixed Attack, 84.30 %. Las tasas de rechazo en el ataque más efectivo rondaron el 3.22 %. Las once defensas evaluadas, concluyen los autores, demuestran "efectividad limitada".
La actualización de 2026 es más dura. Los profesionales citan un artículo próximo a publicarse, referido coloquialmente como "The Attacker Moves Second" en la revisión de Zylos Research de 2026, que demuestra que los ataques adaptativos eluden las doce defensas publicadas de inyección de prompts con más del 90 % de éxito de ataque. La metodología es directa: en lugar de evaluar una defensa contra un corpus de ataque estático, el artículo entrena un atacante adaptativo que observa el comportamiento de la defensa e itera. Esto refleja cómo operan los adversarios reales. Todo benchmark estático termina convirtiéndose en un conjunto de entrenamiento para un atacante que tiene más compute que el defensor.
La respuesta de OWASP es mapear la inyección de prompts (LLM01:2025) a la taxonomía más amplia de seguridad de software. MITRE ATLAS ahora lista tres técnicas relevantes: AML.T0051.000 (LLM Prompt Injection: Direct), AML.T0051.001 (LLM Prompt Injection: Indirect) y AML.T0054 (LLM Jailbreak Injection: Direct). La Prescriptive Guidance de AWS para agentic AI mapea diecisiete controles distintos solo a LLM01, abarcando agent scoping, threat modeling, revisión de prompt-as-code, sanitización de entrada multicapa, edge protection y gestión continua de postura de seguridad. El mensaje implícito es que ninguna defensa única funciona; defense-in-depth es la única postura viable.
Este es el punto de pivote para el resto del documento. La era de solo detección terminó en 2025. La era arquitectónica comenzó con tres publicaciones.
#Parte III: El pivote arquitectónico — Rule of Two, CaMeL, FIDES
#3.1 Rule of Two de Meta
Meta publicó Agents Rule of Two el 31 de octubre de 2025. El marco es lo suficientemente corto como para expresarse en una sola oración: hasta que la investigación de robustez pueda detectar y rechazar de forma confiable la inyección de prompts, los agents deben satisfacer no más de dos de tres propiedades dentro de una sesión. Las tres propiedades son (A) el agent procesa entradas no confiables, (B) el agent tiene acceso a sistemas sensibles o datos sensibles, y (C) el agent puede cambiar el estado externo o impactar al usuario más allá de la conversación.
Las configuraciones que satisfacen la Rule of Two bloquean cada una una etapa de la cadena de ataque de inyección de prompts. [BC] — acceso sensible más cambio de estado, sin entrada no confiable — funciona para un agent que procesa solo correos de remitentes confiables, bloqueando que el payload de inyección llegue nunca a la ventana de contexto. [AC] — entrada no confiable más cambio de estado, sin acceso sensible — funciona para un agent que opera en un sandbox o entorno de prueba donde cualquier inyección exitosa no puede alcanzar datos de consecuencia. [AB] — entrada no confiable más acceso sensible, sin cambio de estado — funciona para un agent que puede leer correo privado y contenido externo pero no puede enviar mensajes ni tomar acciones sin validación humana. Si se requieren las tres propiedades, la guía de Meta es iniciar una sesión nueva (con una ventana de contexto limpia) o requerir aprobación human-in-the-loop antes de la acción consecuente. Cuando ninguna de las dos es aceptable, el agent es, en la práctica actual, indefendible.
Meta es explícito en que la Rule of Two no es la línea de meta. Los diseños que la satisfacen aún pueden fallar (un usuario puede confirmar ciegamente un warning interstitial, deshaciendo la puerta human-in-the-loop). Defense-in-depth es requerida, no opcional. La Rule of Two complementa least-privilege; no la reemplaza. Meta también señaló una integración prospectiva: las tools que declaran una configuración Rule of Two en sus descriptores MCP pueden dar a los desarrolladores respuestas deterministas sobre si una acción tendrá éxito, fallará o escalará a aprobación. Su plataforma LlamaFirewall de código abierto es la capa de alignment-controls que pretenden usar para satisfacer las verificaciones de supervisión donde el human-in-the-loop es impracticable, como procesos de background de larga duración.
#3.2 CaMeL (Google DeepMind, marzo de 2025)
CaMeL — Capability-based Mitigation Layer — se publicó en arXiv 2503.18813 el 24 de marzo de 2025 por Debenedetti, Shumailov, Fan, Hayes, Carlini, Fabian, Kern, Shi, Terzis y Tramèr en Google, Google DeepMind y ETH Zürich. El artículo, aceptado en OpenReview bajo el título "Defeating Prompt Injections by Design", es la defensa arquitectónica más exhaustivamente evaluada en la literatura.
La arquitectura de CaMeL tiene cuatro componentes. Un privileged LLM recibe la consulta confiable del usuario y emite un programa Python restringido que describe el flujo de trabajo previsto. Un quarantined LLM procesa contenido no confiable (salidas de tools, recuperaciones RAG, documentos externos) pero no tiene capacidad de tool calling propia. Un custom interpreter ejecuta el programa del privileged LLM, llamando al quarantined LLM según sea necesario para parsing y summarization, y rastrea la procedencia de los datos a través de todo el grafo de ejecución. Un capability policy engine valida cada tool call contra capacidades derivadas de la consulta confiable: enviar un correo electrónico solo se permite si la dirección del destinatario provino de una fuente confiable.
El resultado principal, reportado en AgentDojo: CaMeL resuelve el 67 % de las tareas con seguridad comprobable. El 33 % restante es pérdida de utilidad, no de seguridad: hay una clase de tareas que el marco no puede completar porque la consulta confiable no restringe el flujo de trabajo lo suficientemente. Críticamente, "seguridad comprobable" no es una afirmación vaga. El intérprete puede demostrar matemáticamente que, dada la política, el programa en ejecución no puede violar los invariantes de seguridad independientemente de lo que se le diga al quarantined LLM. Esto es cualitativamente diferente de "lo probamos contra nuestro corpus de ataques y resistió". El 33 % que falla lo hace negándose a actuar; no falla haciendo lo incorrecto.
La implementación de referencia se publicó en google-research/camel-prompt-injection bajo Apache-2.0 (302 estrellas, 43 forks al momento de escribir). La nota de descargo en el repositorio —"este es un artefacto de investigación, no un producto de Google"— es real; no es un marco de producción hoy. Pero el patrón de diseño ya se ha implementado en formas adyacentes. El artículo "Design Patterns for Securing LLM Agents against Prompt Injections" (arXiv 2506.08837) generaliza las ideas de CaMeL en una taxonomía: plan-then-execute (control-flow integrity), map-reduce isolation (cada chunk procesado por un agent vulnerable a inyección que no puede alcanzar tools externas) y dual-LLM separation. Los agents específicos de aplicación pueden asegurarse hoy usando estos patrones; el problema de investigación abierto es el agent autónomo de propósito general.
#3.3 FIDES (Microsoft Research, mayo de 2025)
FIDES — Flow Integrity Deterministic Enforcement System — fue publicado por Costa, Köpf, Kolluri, Paverd, Russinovich, Salem, Tople, Wutschitz y Zanella-Béguelin en arXiv 2505.23643 el 29 de mayo de 2025, con la publicación complementaria de Microsoft Research el 28 de mayo. El artículo toma un punto de partida arquitectónico diferente de CaMeL. CaMeL provenía de la investigación de compiladores (rastreo de flujo de datos, control de acceso basado en capacidades). FIDES proviene de cuarenta años de investigación en sistemas operativos sobre control de flujo de información.
Cada dato en un sistema de agents protegido por FIDES lleva dos etiquetas: un IntegrityLabel que describe qué tan confiable es la fuente (trusted, untrusted), y un ConfidentialityLabel que describe quién está autorizado a verlo (public, private, user-identity). Cuando los datos fluyen a través de una operación, las etiquetas se combinan mediante una lattice most-restrictive-wins. Un policy engine, que opera fuera del LLM, hace cumplir dos invariantes de forma determinista: las tool calls deben basarse en datos de integridad trusted, y los datos solo pueden fluir hacia destinatarios autorizados a leerlos.
En la evaluación interna de Microsoft, el número principal es dramático: FIDES detuvo todos los ataques de inyección de prompts durante las pruebas. Igualmente sorprendente, los agents protegidos por FIDES emparejados con modelos de razonamiento completaron un 16 % más de tareas que la línea base. La estructura de la restricción hace que el agent sea mejor, no solo más seguro. El mecanismo es intuitivo en retrospectiva: las etiquetas obligan al planner a pensar en la procedencia desde el principio, y los planes resultantes son más ajustados.
FIDES llegó a producción mediante el PR #5024 en microsoft/agent-framework el 1 de abril de 2026: un camino notablemente corto de once meses desde la publicación de la investigación hasta el marco mainstream. El pull request introduce primitivas concretas. IntegrityLabel y ConfidentialityLabel son tipos de primera clase; combine_labels() implementa la lattice. ContentVariableStore reemplaza el contenido no confiable con marcadores opacos VariableReferenceContent, de modo que el LLM nunca ve datos no confiables en bruto: ve una referencia y opera sobre ella mediante tool calls que respetan las etiquetas. LabelTrackingFunctionMiddleware proporciona propagación automática de etiquetas de tres niveles. PolicyEnforcementFunctionMiddleware bloquea o escala a aprobación cuando la confidencialidad del contexto excede el max_allowed_confidentiality de una tool. SecureAgentConfig conecta todo esto en una configuración de una línea. quarantined_llm es una llamada LLM aislada (sin tools) para summarization segura de contenido no confiable; inspect_variable proporciona acceso controlado a variables ocultas con awareness de etiquetas. El mismo PR añade dos muestras de referencia: email_security_example.py para defensa de inyección de prompts basada en integridad y repo_confidentiality_example.py para prevención de exfiltración basada en confidencialidad contra el servidor MCP de GitHub.
La propiedad compartida de Rule of Two, CaMeL y FIDES es el punto silencioso que las hace importantes. Todas hacen cumplir la política en una capa que el modelo no puede anular. Esta es la misma lección arquitectónica que la seguridad informática aprendió en los años 70, cuando los lenguajes type-safe y los controles de acceso de sistemas operativos reemplazaron "el programa promete ser cuidadoso". Al agent ya no se le pide que siga la política. Es estructuralmente incapaz de violar la política independientemente de lo que se le haya instruido hacer. Esa es la propiedad que la capa de detección nunca puede entregar, y es por eso que la defensa arquitectónica no es una moda: es un cambio de fase.
#Parte IV: El stack de defensa de producción de 2026
Las defensas arquitectónicas de la Parte III son la verdad fundamental de cómo se verá la próxima década. El stack de producción de siete capas de esta sección es lo que los equipos realmente implementan hoy, en mayo de 2026, mientras esperan que las primitivas al estilo microsoft/agent-framework lleguen a todos los frameworks. Las capas se componen; ninguna capa es suficiente por sí sola; la mayoría de los despliegues de producción ejecutan cinco de las siete, y los de mayor riesgo ejecutan las siete.
#4.1 Edge y gateway: el perímetro para aplicaciones LLM
Cloudflare AI Security for Apps (anteriormente Firewall for AI) añadió puntuación de inyección de prompts en la capa WAF. El campo cf.llm.prompt.injection_score va de 1 a 99, donde las puntuaciones más bajas son más peligrosas (1-19 alta probabilidad de inyección, 20-49 moderada, 50-99 probablemente benigno). El ajuste de umbral se ejecuta en tres pasos: modo log en umbral 40, revisar el tráfico detectado, bajar el umbral a 25 si dominan los falsos positivos, subirlo a 50 si los ataques están pasando. La puntuación se compone con otras señales: una regla como injection_score < 30 AND bot_management.score < 20 apunta a prompts que parecen inyecciones provenientes de automatización, que es una señal fuerte de un ataque real; injection_score < 40 AND pii_detected marca intentos de inyección que simultáneamente intentan extraer datos personales.
Lasso Security opera en la misma capa pero con un modelo de telemetría específico para agents. AI Detection & Response de Lasso monitorea cada interacción a través del stack de agents —recuperaciones RAG, lecturas de memoria, invocaciones de tools, llamadas a sub-agents— y las mapea en un grafo de ejecución que da a los equipos de seguridad visibilidad de la secuencia completa de eventos. Las afirmaciones de rendimiento principales son agresivas: su LLM-as-judge se ejecuta 570 veces más rápido que la inferencia LLM estándar, y su baselining conductual marca ataques zero-day con un 98.6 % de precisión mediante modelado de intención en lugar de firmas. Los hallazgos se mapean a OWASP Top 10 y MITRE ATLAS. El despliegue es integración API, firewall o AI gateway, además de una opción SaaS de despliegue cero que no requiere agents, cambios de código ni acceso al código fuente.
#4.2 Escaneo de respuestas de tools: bloqueando la superficie de ataque indirecta
Los ataques de lethal trifecta (EchoLeak, GitHub MCP, MCPTox) comparten todos una característica estructural: el contenido malicioso llega a través de un resultado de tool call. El escaneo de respuestas de tools intercepta ese resultado antes de que llegue al LLM. StackOne Defender, liberado como open source bajo Apache-2.0 en febrero de 2026, marca el estándar. Su pipeline de dos niveles ejecuta coincidencia de patrones de Nivel 1 en aproximadamente 1 milisegundo por respuesta y clasificación ML de Nivel 2 (un modelo MiniLM-L6-v2 fine-tuned y cuantizado en int8 a 22 megabytes, puntuación a nivel de oración) solo en respuestas donde el Nivel 1 marcó campos sospechosos. En un benchmark de 25,000 muestras, Defender logró un 88.7 % de precisión de detección en CPU, mejor que DistilBERT (86 %) siendo 81 veces más pequeño y con 8.6 veces menos falsos positivos, y 48 veces más pequeño que Meta Prompt Guard v1. Las reglas conscientes de tools vienen listas para usar: tools gmail_* tratadas automáticamente como mayor riesgo; overrides por tool para crm_*, GitHub, Notion, Jira. La librería se integra con Vercel AI SDK, LangChain, LlamaIndex, el Anthropic SDK y el OpenAI SDK en tres líneas.
Microsoft Prompt Shields es la contraparte productizada. Dos puntos de intervención: entrada de usuario (detección de ataque directo, anteriormente "Jailbreak risk detection") y respuesta de tool (detección de ataque de documento). Cada solicitud devuelve resultados de anotación con flags detected y filtered. La característica opcional Spotlighting, desactivada por defecto, transforma el contenido del documento usando codificación base-64 para que el modelo lo trate como menos confiable que los prompts directos del usuario y del sistema. Spotlighting es el tipo de defensa de baja fricción y estructuralmente honesta que los equipos de producción han adoptado rápidamente: no cuesta nada en latencia, es invisible para los usuarios legítimos y le dice al modelo "esta región de texto no es autoritativa". La disponibilidad general llegó en 2025 con el cliente de referencia AXA confirmando uso en producción.
#4.3 Sistemas de permisos: reduciendo el radio de explosión de cada tool
La capa de defensa más subestimada en 2025-2026 es también la más simple: cambiar la política de permisos por defecto de las tools de tu agent. La Managed Agents API de Anthropic (header beta managed-agents-2026-04-01) define dos políticas —always_allow y always_ask— y las aplica por tool. Los toolsets MCP tienen por defecto always_ask. Este único cambio de valor por defecto colapsa la superficie de ataque para la clase de ataque más peligrosa: una tool MCP recién añadida, posiblemente envenenada, no puede ejecutarse en tu agent sin confirmación explícita. Los overrides configs[] por tool permiten a los desarrolladores permitir el toolset del agent por defecto mientras requieren confirmación para bash. El flujo de confirmación es impulsado por eventos: evento agent.tool_use → session.status_idle con requires_action → evento user.tool_confirmation con result: "allow" o "deny" más deny_message opcional.
Claude Code mismo se envía con un valor por defecto aún más estricto. Solo lectura por defecto; permiso explícito para cambios de estado; ventanas de contexto aisladas para web fetch (que aborda directamente la clase EchoLeak: el resultado web no puede influir en el contexto de razonamiento principal); una lista de bloqueo de comandos en curl y wget; detección de command injection que requiere aprobación manual para comandos bash previamente permitidos cuando la forma es sospechosa; manejo fail-closed de comandos no coincidentes; y modo /sandbox para ejecución autónoma dentro de límites de sistema de archivos y red. La combinación es la implementación de grado de producción de la Rule of Two.
Los productos Operator y ChatGPT Agent de OpenAI implementan un stack análogo. Los prompts de confirmación de Operator antes de acciones consecuentes; Watch Mode que pausa la ejecución cuando el usuario se vuelve inactivo en contextos sensibles (logueado en email o banca); memoria desactivada en el lanzamiento para prevenir exfiltración de memoria impulsada por inyección; restricciones de red de terminal limitadas a datasets específicos en el lanzamiento. Cada una de estas es una intervención del sistema de permisos que reduce el radio de explosión de cualquier inyección exitosa.
#4.4 Escaneo estático y en runtime de la cadena de suministro
Los ataques de tool poisoning y rug-pull (donde un servidor MCP previamente benigno es reemplazado o modificado para entregar descripciones de tools maliciosas) son una preocupación de cadena de suministro. Las mismas disciplinas que protegen npm y PyPI se están adaptando para tools de agents.
MCP-Scan de Invariant