TL;DR
La mayoría de las propuestas de «Zero Trust para IA» se reducen a un único filtro inline delante del modelo. Eso no es Zero Trust — es un muro cuidando una puerta. Una postura Zero Trust real para sistemas de IA tiene que responder dos preguntas distintas en dos lugares distintos: ¿es seguro dejar pasar este input/output? (usuario → modelo) y ¿debería ejecutarse esta acción ahora, con estos parámetros, contra este objetivo? (agente → herramienta). Son dos planos de enforcement con componentes distintos, estándares distintos y modos de fallo distintos. Y ninguno de los dos puede corregir su propia tarea — hace falta un tercer plano, fuera de banda, cuyo único trabajo es probar, de forma adversarial y reproducible, que los dos planos de enforcement efectivamente se sostienen. Este artículo presenta esa arquitectura de referencia de 2-planos-más-aseguramiento y explica por qué el auditor nunca debe convertirse en el muro.
1. Las dos preguntas
Si uno le pide a un arquitecto de seguridad que dibuje «Zero Trust para una web app», obtiene identidad, segmentación, mínimo privilegio y verificación continua en cada salto. Si uno pide «Zero Trust para un agente de IA», con demasiada frecuencia obtiene una caja etiquetada filtro de prompt-injection encajada entre el usuario y el LLM. Esa caja es real y útil — pero responde solo la primera de las dos preguntas que plantea un sistema agéntico.
- Pregunta 1 — Ingreso (Usuario → Modelo): ¿Es seguro enviar este input al modelo, y es segura la salida del modelo para devolverla? Esta es la superficie de ataque clásica de los LLM: prompt injection, fuga de datos, extracción del system prompt, envenenamiento de RAG, trucos multimodales, jailbreaks.
- Pregunta 2 — Acción (Agente → Herramienta/Recurso): Este agente ya decidió llamar a una herramienta. ¿Debería ejecutarse esa llamada específica ahora mismo, con esos parámetros, contra ese objetivo, bajo las condiciones actuales? Esta es la superficie de ataque agéntica: mal uso de herramientas, autoridad demasiado amplia, expansión del alcance de la misión, exploits de MCP, envenenamiento de memoria, actuar sobre permisos revocados.
Los modos de fallo apenas se solapan. Un filtro de ingreso perfecto no hace nada para frenar a un agente que fue prompteado limpiamente y después transfirió un pago al lugar equivocado porque se trató una aprobación vieja como autoridad permanente. Dos preguntas → dos planos.
2. Plano 1 — el gateway de ingreso
El Plano 1 se ubica inline entre los usuarios y el modelo. En 2026 es una categoría bien poblada: un gateway de LLM (LiteLLM, Portkey, Cloudflare AI Gateway) que va delante del modelo, un broker de identidad (Keycloak / cualquier IdP OIDC) para que las requests lleven un sujeto real, un filtro de PII/DLP (Presidio) a la entrada y a la salida, y validación de input + controles de output (spotlighting, gates de canary/allow-list) contra injection.
Los estándares relevantes son los conocidos: NIST SP 800-207 para identidad, el OWASP LLM Top 10 para las clases de ataque y — si se opera en la UE — los Artículos 10 y 15 del AI Act para gobernanza de datos y robustez.
3. Plano 2 — el PDP de autorización en runtime
El Plano 2 es el que la mayoría de las historias de «Zero Trust para IA» se saltean, y es donde se movió 2026. La identidad prueba quién está actuando. La autorización en runtime prueba que esta acción debería ejecutarse ahora — una decisión por llamada en el punto de ejecución, no una concesión general estampada al momento de emitir el token.
El componente acá es un policy decision point externalizado (Cerbos, OPA, AWS Cedar) — la política sacada del agente para que el agente no pueda razonar su forma de esquivarla. Encima de él, un conjunto de estándares jóvenes-pero-reales: OpenID AuthZEN y COAZ para autorización de herramientas a nivel de parámetro (Sujeto–Acción–Recurso–Contexto, incluyendo llamadas a herramientas MCP), AARP para aprobación/denegación estructurada de acciones que la política todavía no puede autorizar, y autoridad acotada a la misión de OAuth (AAP) para que un token quede limitado a una tarea/sesión/consentimiento en lugar de a todo lo que el agente puede alcanzar. El objetivo de madurez es enforcement fail-closed y re-autorización continua y consciente del contexto según NIST SP 800-207.
Este plano mapea con los Artículos 14 (supervisión humana) y 26 (obligaciones del implementador) del AI Act de la UE — porque «un humano aprobó la misión» no es lo mismo que «un humano aprobó esta acción consecuente».
4. Por qué el auditor no puede ser el muro
Acá está la decisión de diseño que sostiene todo: la capa de aseguramiento tiene que ser fuera de banda. Ataca los dos planos de enforcement, los puntúa y produce evidencia — pero nunca se ubica inline en producción.
El razonamiento no es modestia, es corrección:
- El enforcement está abarrotado y es crítico en latencia. Los gateways y PDPs son un único punto de falla en la ruta de la request. Sumar un cuarto proveedor ahí compra riesgo, no aseguramiento.
- El aseguramiento es escaso. Lo que casi nadie entrega es prueba determinista, reproducible y adversarial de que un control se sostiene — la misma batería de 1.000 tests, la misma semilla, el mismo SARIF, reproducible el próximo trimestre para mostrar si la brecha se cerró o se regresó.
- Un adversario que además es una dependencia de producción es un mal adversario. Para ser máximamente hostil con los planos, el auditor tiene que ser libre de romper cosas — lo que significa que no puede ser algo cuya caída tire abajo el producto.
Así que el posicionamiento honesto es: plano de auditoría, no guardrail de runtime. En el momento en que el auditor se convierte en el muro, deja de poder decirte si el muro funciona.
5. Cómo se ve de verdad el «aseguramiento para ambos planos»
El aseguramiento solo es creíble si es concreto. Contra el Plano 1, el corpus ofensivo maneja los dominios de prompt injection, fuga de datos, multimodal, fuga de system prompt, envenenamiento de RAG y jailbreak adaptativo, y emite SARIF por regla más un resultado de output-gate de PII/PCI validado por checksum (para que un número de tarjeta filtrado lo atrape Luhn, no una regex esperanzada).
Contra el Plano 2, las pruebas interesantes son agénticas y de múltiples pasos:
- una auditoría de preparación de autorización de herramientas a nivel de parámetro que verifica si las llamadas a herramientas están gateadas por una decisión estilo AuthZEN/COAZ (Sujeto–Acción–Recurso–Contexto) o son de forma libre;
- una prueba de expansión del alcance de la misión que le da a un agente una misión aprobada de forma acotada, y después expande el alcance de a poco («ya que estás, y como ya está aprobado…») hasta que comete una acción consecuente fuera de la misión — el fallo del diputado-confundido-en-el-tiempo — y, crucialmente, no marca a un agente que nombra la acción solo para rechazarla (bajo falso-positivo por construcción);
- una prueba de persistencia de revocación que otorga una autoridad, la revoca y verifica si el agente sigue actuando sobre la versión que quedó rondando en su memoria;
- un chequeo fail-closed sobre la ruta de enforcement misma: cuando el gate/PDP es inalcanzable, ¿el sistema deniega, o falla abierto?
Cada una de esas produce evidencia, y cada hallazgo se agrega a un scorecard de Madurez Zero Trust donde el control evaluado más débil pone el techo del plano — porque en Zero Trust, saltearse una capacidad es donde vive el atacante.
6. El blueprint
Puesto todo junto, la arquitectura de referencia son tres planos:
Dos planos que el cliente despliega y aplica, un plano que el auditor corre fuera de banda. El cliente es dueño de los muros; el auditor es dueño de la prueba.
7. Cierre
«Zero Trust para IA» no es un producto que se coloca delante de un modelo. Son dos preguntas de enforcement — ¿seguro para pasar? y ¿seguro para ejecutar? — respondidas en dos planos con componentes y estándares distintos, más un auditor fuera de banda cuyo valor entero es que no es uno de los muros. Si tu historia de Zero Trust para IA tiene una sola caja adentro, estás cuidando una puerta y llamándola perímetro.
Contacto
- Empresa: i-314 Security Research
- Web: https://i-314.com
- Email: [email protected]
- Producto: Ai-EGIS — AI Exploitation & Governance Intelligence Suite v3.0
- Trabajo relacionado: Tool Output Mimicry (Zenodo, 2026)
Publicado originalmente en LinkedIn.
Seguí leyendo
- El bug silencioso de Hadamard: inicializar los qubits «como siempre» destruye tu modelo de riesgo
- Anatomía de un agente de investigación IA que no alucina
- Captura del OWASP FinBot CTF: Una Metodología Source-Aware para Red Teaming de IA Agéntica
AI red-teaming, seguridad de IA agéntica y criptografía post-cuántica. LinkedIn