Zero Trust para agentes de IA: deja de fiarte de tu agente

Anthropic publicó en mayo de 2026 un framework de seguridad para agentes autónomos, y lo mejor que trae es una sola pregunta que puedes hacerle a cualquier control: ¿este control hace el ataque imposible, o solo tedioso? Contra un humano, la fricción funciona. Un rate limit, un MFA por SMS, un puerto no estándar, un salto de login extra: cada capa desanima a alguien que se cansa. Contra un atacante que corre un agente de IA en bucle, con paciencia infinita y coste por intento casi nulo, la fricción no desanima a nadie. Solo alarga el log.

Este post es una lectura de ingeniero del documento “Zero Trust for AI Agents”^[1]: qué dice, qué de eso es afirmación de marca y qué es criterio útil, y qué significa para la arquitectura de un agente que ya corres en producción.

¿Qué cambió? La línea temporal del ataque se ha desplomado

La tesis del documento es que los modelos frontera están comprimiendo el tiempo entre una vulnerabilidad y su exploit funcional de meses a horas, a un coste marginal medido en dólares^[1]. Conviene ser preciso con esto: es una afirmación de Anthropic dentro de su propio framework, sin benchmark ni cita externa. No es un dato medido que puedas replicar. Es la premisa desde la que argumentan todo lo demás.

Y como premisa, importa. Si aceptas que descubrir y armar un exploit deja de ser un cuello de botella, toda la seguridad basada en “esto es demasiado trabajo para que alguien lo intente” se cae. La fricción era una apuesta sobre la economía del atacante: tú subes el coste, él se rinde. Un atacante automatizado rompe esa apuesta. Prueba miles de variantes de un prompt mientras duermes, y cada intento fallido no le cuesta ni frustración ni tiempo.

De ahí sale la heurística central, y es la que deberías grabarte: ante la duda, prefiere un control que elimina una capacidad frente a uno que la limita. Un token que caduca en cinco minutos es una capacidad eliminada. Un rate limit de mil peticiones por hora es una capacidad limitada. La diferencia decide si sobrevives a alguien con paciencia infinita.

Por qué tu propio agente es superficie de ataque

Un agente en producción ejecuta acciones con tus credenciales sobre datos que a veces no controlas. Eso lo convierte en superficie de ataque de cuatro formas que un servicio web tradicional no tiene, y todas dependen de una debilidad de raíz: los LLM no distinguen de forma fiable entre contexto informativo e instrucciones accionables.

La primera es la inyección de prompt indirecta. La directa la conoces: alguien escribe “ignora tus instrucciones” en el input. La indirecta es peor porque no pasa por el input. El agente lee una web o un ticket de soporte, y dentro de ese contenido hay instrucciones ocultas que el modelo obedece como si vinieran de ti. Si tu agente resume la bandeja de entrada, cualquiera que le escriba un correo puede intentar darle órdenes. El mecanismo completo lo desgrané en prompt injection: cómo los hackers secuestran agentes.

La segunda es la herramienta maliciosa, y en septiembre de 2025 dejó de ser teórica. El paquete npm postmark-mcp era una réplica casi exacta del servidor MCP oficial de Postmark. Durante quince versiones se comportó igual que el original y ganó adopción. En la versión 1.0.16 el autor añadió una sola línea al código de envío: un BCC oculto a un dominio externo en cada correo que el agente mandaba^[3]. El primer servidor MCP malicioso encontrado in-the-wild no explotaba un bug del modelo, ni escondía instrucciones en la descripción de la herramienta (eso es el tool poisoning clásico, el texto que el modelo lee al decidir qué usar). Troyanizaba la implementación: un ataque de cadena de suministro sobre la capa en la que el agente confía por diseño. La cadena de suministro de skills y MCP la traté aparte en seguridad de skills y MCP.

La tercera es el tool chaining. Cada herramienta que usa el agente es legítima y corre con credenciales válidas. El daño está en la secuencia. Leer un registro del CRM interno es legítimo. Enviar un email externo es legítimo. Encadenar las dos es exfiltración, y tu monitorización por host no ve nada raro porque cada llamada, por separado, está autorizada.

La cuarta es el envenenamiento de memoria. Una instrucción implantada en la memoria persistente del agente sobrevive entre sesiones. No hay un momento “malicioso” que un revisor pueda señalar: es deriva lenta, donde ningún cambio individual parece un ataque hasta que el conjunto ya lo es.

Simon Willison le puso nombre a la combinación que hace esto letal: la lethal trifecta, acceso a datos privados más exposición a contenido no confiable más capacidad de exfiltrar^[4]. Junta las tres en un agente y tienes un problema, no un riesgo. El documento de Anthropic no usa el término, pero describe exactamente el mismo mecanismo cuando explica por qué un resumidor de emails con permiso de envío es una bomba.

Y hay una capa por debajo de todas estas: el modelo puede llegarte ya envenenado desde el entrenamiento. Un estudio de Anthropic con el UK AI Security Institute y el Alan Turing Institute encontró que bastan 250 documentos maliciosos para introducir un backdoor en modelos de 600M a 13B de parámetros, y que ese backdoor persiste tras el fine-tuning de seguridad^[2]. No es un porcentaje del corpus que puedas diluir metiendo más datos limpios: es un recuento absoluto, y por eso escala tan mal. Si el agente que despliegas hereda un modelo comprometido en la cadena de suministro, ninguno de los controles de ejecución que vienen abajo lo detecta.

Zero Trust, pero para un agente autónomo

Zero Trust no es nuevo. Viene de la seguridad de redes, está estandarizado en el NIST SP 800-207, y se apoya en unos pocos principios: no confíes en nada por su posición en la red y verifica siempre, asume que ya estás comprometido, y concede el mínimo privilegio necesario. Nada de esto nació para agentes. La aportación del framework es traducirlo a un actor que se comporta distinto a un usuario o un microservicio.

Un agente es distinto en varias cosas a la vez. Actúa en múltiples pasos sin aprobación humana en cada uno, así que un desvío temprano se propaga. Tiene acceso a herramientas reales, no solo a datos: APIs, bases de datos, ficheros, servidores MCP. Interpreta instrucciones con ambigüedad, y algo benigno para un humano puede volverse peligroso en su ejecución. Arrastra memoria y contexto entre sesiones, con lo que un envenenamiento persiste. Y cuando coordinas varios agentes, creas relaciones de confianza que un atacante puede pivotar.

Ese último punto es el que la mayoría subestima. En cuanto un agente gestor delega en un worker, has creado una frontera de confianza interna. Si el gestor le pasa su privilegio entero al worker, acabas de construir un confused deputy: el worker actúa con una autoridad que nunca debió tener, y el sistema lo ve como legítimo.

Los controles que sobreviven al test

Aquí es donde el framework se pone concreto, y donde el test “imposible o tedioso” deja claro qué control aguanta y cuál es decorado.

Trata las API keys estáticas como ya comprometidas. Rotarlas cada noventa días no basta si se pueden grepear de un fichero de config, un log o la memoria de un proceso. El baseline nuevo son tokens de vida corta, alcance estrecho, emitidos por un proveedor de identidad, con expiración medida en minutos. La diferencia no es incremental:

# Antes: la llave vive para siempre y basta con leerla una vez
agent_credential:
  type: static_api_key
  value: "sk-live-9f3a...b21"   # en config, en el proceso, grepeable
  rotation: 90d                  # ventana de exposición: 90 días

Frente a eso, el baseline Zero Trust emite una llave que caduca antes de que sirva de nada:

# Baseline Zero Trust
agent_credential:
  type: short_lived_token
  issued_by: identity_provider   # emitido just-in-time
  scope: ["crm:read"]            # solo lo que esta tarea necesita
  ttl: 5m                         # ventana de exposición: 5 minutos

Robar un token que caduca en cinco minutos obliga al atacante a usarlo ya, dentro de tu ventana de detección. Eso es eliminar una capacidad, no limitarla.

Least agency. El término viene de OWASP, que formalizó la “excessive agency” como riesgo, y extiende el mínimo privilegio en la dimensión que a los agentes les faltaba. El privilegio contesta a a qué accede el agente. La agencia contesta a qué puede hacer cada herramienta, con qué frecuencia y dónde. Una herramienta de base de datos que solo lee no puede escribir aunque el agente se lo pida bajo inyección. Un resumidor de emails sin permiso de enviar ni borrar es inofensivo aunque lo secuestren:

tools:
  - name: db_query
    access: read_only          # nunca INSERT/UPDATE/DELETE
    tables: ["orders"]         # nada fuera de este scope
  - name: email_summarizer
    can_send: false            # capacidad eliminada, no vigilada
    can_delete: false
    rate: 30/min

Sandbox para toda entrada no confiable. Cualquier agente que procese webs, documentos o correos debe correr en un entorno aislado, del tipo de gVisor: un kernel de aplicación en espacio de usuario que intercepta y reimplementa las syscalls del proceso en vez de dejarlas llegar al kernel del host. El documento lo pone como requisito, no como aspiración, y tiene sentido: si asumes la brecha, el sandbox es lo que contiene el daño cuando la inyección funciona.

Alcance dinámico por tarea. Just-in-time y just-enough: concede el permiso en el momento exacto en que la tarea lo necesita y revócalo al terminar. La decisión no depende solo de la identidad, sino del recurso, la acción, el tiempo y el riesgo (ABAC). Un permiso permanente deja esa exposición abierta de forma indefinida.

El documento acompaña esto con dos defensas que sí traen número, y la diferencia entre ellas ilustra la tesis. El Spotlighting de Microsoft, que delimita el contenido no confiable para que el modelo no lo confunda con instrucciones, baja el éxito de la inyección indirecta de más del 50% a menos del 2%^[1]. Los clasificadores constitucionales de Anthropic bloquean más del 95% de los jailbreaks con pocos falsos rechazos^[1]. Pero fíjate en la segunda: un clasificador vive del lado del modelo, depende de que el modelo evalúe bien lo que entra. Ayuda, y mucho, pero no es una barrera externa dura como un token que caduca. Súbete a ella para elevar el listón, pero no apoyes el sistema entero en un clasificador.

Estos controles comparten una propiedad: no dependen de que el modelo se porte bien. Son externos y duros. Compáralos con sus versiones de fricción:

Control de fricción	Barrera dura	Por qué la fricción falla
MFA por SMS	Passkey / FIDO2	El código SMS es un secreto transferible: se intercepta (SIM-swap, SS7) o se cede en un phishing en tiempo real, sin reintentar nada
API key rotada cada 90 días	Token efímero (minutos), emitido por IdP	La llave estática es grepeable durante toda su ventana de vida
Rate limit	Eliminar la ruta o la capacidad entera	Con paciencia infinita, un límite por hora solo alarga el ataque
Mínimo privilegio	Least agency (qué puede hacer cada herramienta)	El privilegio dice a qué accede, no qué acción destructiva ejecuta
Monitorización por host	Auditoría de la secuencia de acciones del agente	El tool chaining usa herramientas legítimas con credenciales válidas

Si quieres estos controles como código de aplicación y no solo como principio, los guardarrailes son la pieza que los implementa: lo desarrollé en cómo implementar guardarrailes en agentes de IA.

Defender a la velocidad de la IA

Si el atacante automatiza, tu defensa manual pierde por velocidad. La respuesta del framework es un SOAR agéntico: pon un modelo de solo-lectura al frente de la cola de alertas para hacer triage antes de que llegue el humano. Clasifica y prepara el terreno antes de que el humano lo revise.

El error tentador es automatizar la cola entera de golpe. El framework recomienda lo contrario: empieza por una regla ruidosa, la que más falsos positivos te genera, y mídela dos semanas contra un revisor humano antes de darle más cuerda. Si el modelo coincide con el humano, amplías. Si no, aprendes barato.

La línea que resume la postura correcta es esta: la respuesta correcta no aparta al humano del bucle, lo saca del papeleo y lo pone en las decisiones. Automatiza el registro, la recolección de artefactos, el borrador del postmortem. Deja que el humano decida la contención, la divulgación y qué le cuentas al cliente. El mismo reparto de responsabilidad que defiendo en la arquitectura de un agente empresarial: el humano donde su criterio vale, la máquina en lo repetitivo.

Lo que este framework NO resuelve

Aquí es donde el post se vuelve honesto, porque el propio espacio tiene una crítica que el documento minimiza. Chris Hughes, de Resilient Cyber y miembro del proyecto de seguridad agéntica de OWASP, la formula bien: la mayoría de las empresas no ha conseguido Zero Trust ni para sus humanos, que son entidades deterministas con roles estables^[5]. Un LLM es probabilístico. Puede comportarse de forma imprevisible incluso para quien lo entrenó.

Eso rompe una suposición de fondo. Zero Trust verifica identidades y políticas que se comportan igual cada vez. Un agente no. Un system prompt es, como mucho, una sugerencia a un sistema probabilístico que la obedece a su criterio. Puedes escribirle “en esta fase solo lee, nunca escribas” y lo obedecerá casi siempre, hasta la vez que decida que escribir era necesario para completar el objetivo. Su frase se queda contigo: no puedes poner un firewall al razonamiento de un agente.

Y esa es exactamente la razón por la que los controles que valen son los externos. No confías en que el modelo respete el prompt. Le quitas la capacidad de hacer daño en la capa de abajo, donde su probabilismo no llega: el token que caduca, la herramienta que solo lee, el sandbox que contiene. El framework es coherente en el mecanismo aunque se venda con optimismo. Si te quedas con una idea, que sea que un guardarrail vale por ser externo al modelo, no por lo bien escrito que esté el prompt. La distinción entre control y sugerencia la explico en qué es un guardarrail en IA.

Sobre el spin de marca, una nota: el documento intercala consejos que presentan Claude Code como implementación de referencia, con permisos deny-by-default, ejecución en sandbox, OAuth para MCP y hooks para validar parámetros antes de ejecutar. Es una implementación posible y razonable de estos principios. No es la única, y el valor del framework está en el principio, que es neutral respecto al proveedor.

Qué hacer el lunes

Nada de esto sirve como teoría. Traducido a acciones que puedes empezar esta semana:

• Inventaría cada herramienta que tus agentes pueden invocar y clasifícala por lo que puede hacer, no solo por a qué accede
• Sustituye toda API key estática de un agente por un token de vida corta emitido por tu IdP, con alcance por tarea
• Marca los agentes que leen entradas no confiables (web, email, PDFs, tickets de soporte) y muévelos a un sandbox aislado antes de darles más permisos
• Recorta la agencia de cada herramienta al mínimo: lecturas sin escritura, sin envío ni borrado salvo donde sea imprescindible
• Revisa las delegaciones gestor→worker para que ningún worker herede el privilegio completo del gestor
• Añade auditoría sobre la secuencia de acciones del agente, no solo sobre cada llamada por host
• Elige una regla ruidosa de tu cola de alertas y mide dos semanas un triage automático contra un humano antes de ampliar

El baseline no lo alcanzas de golpe. Pero cada uno de estos puntos elimina una capacidad en lugar de vigilarla, y esa es la única métrica que le importa a un atacante con paciencia infinita.

Si quieres practicar estos patrones de agente (mínimo privilegio, diseño de herramientas, supervisión humana) con ejercicios en vez de con un PDF de 36 páginas, están en el curso interactivo Patrones de Diseño para Agentes de IA en Learn.

Fuentes

1. Zero Trust for AI Agents (Anthropic): el framework de mayo 2026, con la tesis de la línea temporal comprimida, el test de diseño, least agency, tokens efímeros, sandbox, JIT/ABAC, SOAR agéntico y las cifras de Spotlighting (de más del 50% a menos del 2%) y clasificadores constitucionales (más del 95% de jailbreaks bloqueados) citadas dentro del documento.
2. Small samples can poison LLMs (Anthropic, UK AI Security Institute y The Alan Turing Institute): estudio de octubre de 2025 en el que 250 documentos maliciosos bastan para introducir un backdoor en modelos de 600M a 13B de parámetros, como recuento absoluto y no como porcentaje del corpus.
3. First malicious MCP server found stealing emails (The Hacker News): el caso postmark-mcp (septiembre 2025), donde la versión 1.0.16 añadió un BCC oculto a un dominio externo en cada correo enviado.
4. The lethal trifecta (Simon Willison): datos privados, contenido no confiable y capacidad de exfiltrar como la combinación que hace explotable a un agente.
5. Zero Trust was built for a different threat model (Chris Hughes, Resilient Cyber): la crítica de que Zero Trust asume entidades deterministas mientras que un LLM es probabilístico, y de que un system prompt es una sugerencia, no un control.

Preguntas Frecuentes

¿Zero Trust no era una cosa de redes?

Lo era, y sigue siéndolo. Nació en seguridad de redes y está estandarizado en el NIST SP 800-207: no confíes por posición en la red, verifica siempre, asume la brecha y concede el mínimo privilegio. El framework de Anthropic lo reaplica a un actor nuevo, el agente autónomo, que actúa en varios pasos, usa herramientas reales y arrastra memoria entre sesiones. Los principios son los mismos; lo que cambia es a quién se los aplicas.

¿Cuál es la diferencia entre mínimo privilegio y least agency?

El mínimo privilegio limita a qué recursos accede el agente. Least agency, término de OWASP, limita qué puede hacer cada herramienta, con qué frecuencia y dónde. Puedes dar a un agente acceso de lectura a una base de datos (privilegio) y a la vez impedir que esa herramienta ejecute cualquier escritura (agencia). La agencia es la capa que te salva cuando una inyección de prompt convence al agente de intentar algo destructivo: la herramienta simplemente no tiene esa capacidad.

¿Un system prompt cuenta como control de seguridad?

No. Es una sugerencia a un sistema probabilístico que puede saltársela de forma impredecible si cree que ayuda a completar el objetivo. Los controles que cuentan son externos: tokens que caducan, herramientas sin permiso de escritura, sandbox que contiene el daño. No puedes poner un firewall al razonamiento de un agente.

¿Esto aplica si solo uso Claude Code o un único servidor MCP?

Sí, y el caso postmark-mcp es el ejemplo. Un solo servidor MCP comprometido basta para exfiltrar datos con credenciales válidas, porque el agente confía en la herramienta por diseño. Aunque uses una sola herramienta, aplica lo mismo: token efímero en vez de API key estática, y least agency para que ese MCP solo pueda hacer lo estrictamente necesario. Claude Code implementa varios de estos controles por defecto, pero el principio es independiente de la herramienta.

¿Qué es el tool poisoning y cómo lo detecto?

Tool poisoning es esconder instrucciones maliciosas en la descripción, el esquema o los metadatos de una herramienta (típicamente un servidor MCP): el modelo lee esa descripción al decidir qué herramienta usar y ejecuta la orden oculta creyéndola parte legítima de la herramienta. Es primo del backdoor de implementación de postmark-mcp, donde el daño estaba en el código y no en la descripción, y comparten defensa. Detectarlo es difícil porque todo corre con permisos válidos, así que la defensa es preventiva: fija versiones exactas de tus MCP, audita el código y la descripción de terceros antes de conectarlos, y ejecuta el agente en sandbox con least agency para que, esté envenenado el descriptor o la implementación, no tenga a qué acceder.