Asegurando Agentes IA con Zero Trust

AI agents don’t just generate text—they execute code, call APIs, access databases, and delegate to other agents. Each autonomous action is an attack surface. Traditional perimeter security assumes everything inside the network is trusted. Agents break this assumption: they operate across trust boundaries, make decisions at machine speed, and handle untrusted data from users, documents, and external APIs. Zero Trust—never trust, always verify—maps directly to the threat model of agentic systems. Every agent action must be authenticated, authorized, and audited. No implicit permissions, no trusted contexts, no exceptions.

Los agentes IA no solo generan texto—ejecutan código, llaman APIs, acceden a bases de datos y delegan a otros agentes. Cada acción autónoma es una superficie de ataque. La seguridad perimetral tradicional asume que todo dentro de la red es confiable. Los agentes rompen este supuesto: operan a través de límites de confianza, toman decisiones a velocidad de máquina y manejan datos no confiables de usuarios, documentos y APIs externas. Zero Trust—nunca confiar, siempre verificar—se mapea directamente al modelo de amenazas de sistemas agénticos. Cada acción del agente debe ser autenticada, autorizada y auditada. Sin permisos implícitos, sin contextos confiables, sin excepciones.

The OWASP Top 10 for LLM Applications (2025) identifies prompt injection as the #1 critical vulnerability. LLMs process developer instructions, user queries, retrieved documents, and tool outputs in the same context window—there is no hardware-enforced privilege separation. Zero trust for agents means enforcing boundaries that the model itself cannot: cryptographic identity for every agent, sandboxed execution for generated code, schema validation for every tool call, and post-quantum cryptography for agent-to-agent communication.

El OWASP Top 10 para Aplicaciones LLM (2025) identifica la inyección de prompts como la vulnerabilidad crítica #1. Los LLMs procesan instrucciones del desarrollador, consultas de usuario, documentos recuperados y salidas de herramientas en la misma ventana de contexto—no hay separación de privilegios a nivel de hardware. Zero trust para agentes significa imponer límites que el modelo mismo no puede: identidad criptográfica para cada agente, ejecución en sandbox para código generado, validación de schema para cada llamada de herramienta y criptografía post-cuántica para comunicación entre agentes.

The Threat Model

El Modelo de Amenazas

Agentic systems face threats that traditional web applications don’t. Prompt injection tricks agents into executing attacker-controlled actions by embedding malicious instructions in retrieved documents, tool outputs, or user inputs. Because the model cannot distinguish between trusted system instructions and untrusted data in its context window, any data source becomes a potential attack vector.

Los sistemas agénticos enfrentan amenazas que las aplicaciones web tradicionales no. La inyección de prompts engaña a los agentes para que ejecuten acciones controladas por el atacante mediante instrucciones maliciosas embebidas en documentos recuperados, salidas de herramientas o entradas de usuario. Como el modelo no puede distinguir entre instrucciones de sistema confiables y datos no confiables en su ventana de contexto, cualquier fuente de datos se convierte en un vector de ataque potencial.

Tool poisoning replaces legitimate tool descriptions with malicious ones—advertising a get_user_data function that exfiltrates data instead of retrieving it. Confused deputy attacks exploit agents with higher privileges than the user, tricking them into performing unauthorized actions on the user’s behalf. In multi-agent architectures, lateral movement through delegation chains allows a compromised agent to escalate privileges by delegating to agents with broader access.

El envenenamiento de herramientas reemplaza descripciones de herramientas legítimas con versiones maliciosas—publicitando una función get_user_data que exfiltra datos en lugar de recuperarlos. Los ataques de deputy confundido explotan agentes con privilegios mayores que el usuario, engañándolos para que realicen acciones no autorizadas en nombre del usuario. En arquitecturas multi-agente, el movimiento lateral a través de cadenas de delegación permite a un agente comprometido escalar privilegios delegando a agentes con acceso más amplio.

The BSI/ANSSI joint report “Design Principles for LLM-based Systems with Zero Trust” (2025) maps these threats to NIST SP 800-207 components: Policy Decision Points (PDP) evaluate every tool call, Policy Enforcement Points (PEP) interpose between agents and resources, and Policy Information Points (PIP) provide contextual data for decisions. This is not theory—it’s architecture.

El reporte conjunto BSI/ANSSI “Principios de Diseño para Sistemas basados en LLM con Zero Trust” (2025) mapea estas amenazas a los componentes de NIST SP 800-207: los Puntos de Decisión de Política (PDP) evalúan cada llamada de herramienta, los Puntos de Aplicación de Política (PEP) se interponen entre agentes y recursos, y los Puntos de Información de Política (PIP) proporcionan datos contextuales para las decisiones. Esto no es teoría—es arquitectura.

Cryptographic Identity for Agents

Identidad Criptográfica para Agentes

Static API keys are the primary vector for exploitation in agentic systems. Replace them with SPIFFE/SPIRE—every agent receives a short-lived, cryptographically verifiable identity document (SVID) through the Workload API. Attestation binds the agent’s identity to its code payload, proving not just who the agent is but that its code hasn’t been tampered with.

Las API keys estáticas son el vector principal de explotación en sistemas agénticos. Reemplázalas con SPIFFE/SPIRE—cada agente recibe un documento de identidad criptográficamente verificable de corta duración (SVID) a través de la Workload API. La atestación vincula la identidad del agente a su payload de código, probando no solo quién es el agente sino que su código no ha sido alterado.

The configuration defines trust domains, issues X.509 or JWT SVIDs with short TTLs (minutes, not days), and propagates credentials through the orchestration layer. Dapr sidecars handle mTLS between agent services—agents never hold credentials directly. When an agent needs to call a tool or access a database, the sidecar presents its SVID, the target validates it against the trust bundle, and the connection is established with mutual authentication.

La configuración define dominios de confianza, emite SVIDs X.509 o JWT con TTLs cortos (minutos, no días) y propaga credenciales a través de la capa de orquestación. Los sidecars de Dapr manejan mTLS entre servicios de agentes—los agentes nunca mantienen credenciales directamente. Cuando un agente necesita llamar una herramienta o acceder a una base de datos, el sidecar presenta su SVID, el destino lo valida contra el bundle de confianza y la conexión se establece con autenticación mutua.

# SPIRE agent registration for an AI agent workload
spire-server entry create \
  -parentID spiffe://octagono.org/agent-node \
  -spiffeID spiffe://octagono.org/agent/researcher \
  -selector k8s:sa:researcher-agent \
  -ttl 300

This eliminates long-lived secrets. A compromised agent’s SVID expires in minutes, and the trust bundle revokes compromised identities without redeploying any service. Attribute-based access control (ABAC) combines with dynamic data masking—PII and sensitive fields are tokenized before they reach the model, reducing both leakage risk and regulatory exposure.

Esto elimina secretos de larga duración. El SVID de un agente comprometido expira en minutos, y el bundle de confianza revoca identidades comprometidas sin redeployar ningún servicio. El control de acceso basado en atributos (ABAC) se combina con enmascaramiento dinámico de datos—PII y campos sensibles son tokenizados antes de llegar al modelo, reduciendo tanto el riesgo de fuga como la exposición regulatoria.

Sandboxed Execution Boundaries

Límites de Ejecución en Sandbox

Agents that execute code—or trigger code execution through tools—need isolation at the OS level. There are three graduated approaches, each trading performance for security.

Los agentes que ejecutan código—o disparan ejecución de código a través de herramientas—necesitan aislamiento a nivel de OS. Hay tres enfoques graduados, cada uno intercambiando rendimiento por seguridad.

Firecracker MicroVMs provide the strongest isolation. Each agent runs in its own lightweight VM with a dedicated kernel—hardware-enforced boundaries prevent entire classes of kernel-based attacks. Boot time is ~125ms, memory overhead is minimal. Kata Containers orchestrates Firecracker at scale on Kubernetes. Use this for production agents executing untrusted or user-submitted code.

Los MicroVMs Firecracker proporcionan el aislamiento más fuerte. Cada agente corre en su propia VM ligera con un kernel dedicado—límites impuestos por hardware previenen clases enteras de ataques basados en kernel. El tiempo de arranque es ~125ms, el overhead de memoria es mínimo. Kata Containers orquesta Firecracker a escala en Kubernetes. Usa esto para agentes de producción que ejecutan código no confiable o enviado por usuarios.

gVisor implements a user-space kernel (the Sentry) that intercepts system calls before they reach the host kernel. When a container makes a syscall, gVisor handles it in userspace—only a minimal, vetted subset reaches the kernel. This reduces the attack surface dramatically without full VM overhead. Use gVisor for compute-heavy agents where I/O is limited and nested virtualization isn’t available.

gVisor implementa un kernel en espacio de usuario (el Sentry) que intercepta llamadas de sistema antes de que lleguen al kernel del host. Cuando un contenedor hace una syscall, gVisor la maneja en espacio de usuario—solo un subconjunto mínimo y auditado llega al kernel. Esto reduce la superficie de ataque dramáticamente sin el overhead completo de una VM. Usa gVisor para agentes con carga computacional pesada donde la I/O es limitada y la virtualización anidada no está disponible.

Hardened containers with seccomp profiles, AppArmor policies, and dropped Linux capabilities work only for trusted internal automation. For anything else, they’re insufficient. The enforcement strategy follows the data: untrusted input → Firecracker, controlled compute → gVisor, reviewed code → hardened containers.

Los contenedores endurecidos con perfiles seccomp, políticas AppArmor y capacidades Linux eliminadas funcionan solo para automatización interna confiable. Para todo lo demás, son insuficientes. La estrategia de aplicación sigue los datos: entrada no confiable → Firecracker, cómputo controlado → gVisor, código revisado → contenedores endurecidos.

AST-Based Code Safety Analysis

Análisis de Seguridad de Código Basado en AST

Before any agent-generated code reaches the execution sandbox, it passes through an AST safety layer. Python’s ast module parses source code into an abstract syntax tree, which is then validated against a configurable safe grammar subset. The approach, formalized in the STELP framework (2025), transpiles unsafe code into a secured version that maintains the original logic while adding safety controls.

Antes de que cualquier código generado por un agente llegue al sandbox de ejecución, pasa a través de una capa de seguridad AST. El módulo ast de Python parsea el código fuente en un árbol de sintaxis abstracta, que luego se valida contra un subconjunto gramatical seguro configurable. El enfoque, formalizado en el framework STELP (2025), transpila código inseguro a una versión asegurada que mantiene la lógica original mientras añade controles de seguridad.

import ast

UNSAFE_NODES = (
    ast.Import, ast.ImportFrom,    # arbitrary module loading
    ast.Exec, ast.Global,           # namespace manipulation
)

UNSAFE_CALLS = {
    "eval", "exec", "compile",      # dynamic code execution
    "__import__",                    # bypass import restrictions
    "getattr", "setattr",           # reflective access
}

def validate_agent_code(source: str) -> ast.AST:
    tree = ast.parse(source)
    for node in ast.walk(tree):
        if isinstance(node, UNSAFE_NODES):
            raise SecurityViolation(f"blocked: {type(node).__name__}")
        if isinstance(node, ast.Call):
            func_name = getattr(node.func, "id", "")
            if func_name in UNSAFE_CALLS:
                raise SecurityViolation(f"blocked call: {func_name}")
    return tree

This catches dangerous operations at parse time—before the code is ever compiled or executed. Tools like PyAegis and Agent Security Scanner extend this pattern with taint analysis, tracking data flow from user input (sources) to dangerous functions (sinks) across function boundaries. Sanitizer calls break the taint chain. The result: agent-generated code that passes validation is guaranteed to be within the safe grammar subset, and anything outside it is blocked.

Esto captura operaciones peligrosas en tiempo de parseo—antes de que el código sea compilado o ejecutado. Herramientas como PyAegis y Agent Security Scanner extienden este patrón con análisis de taint, rastreando el flujo de datos desde entrada de usuario (fuentes) hasta funciones peligrosas (sumideros) a través de límites de funciones. Las llamadas a sanitizadores rompen la cadena de taint. El resultado: el código generado por el agente que pasa la validación está garantizado dentro del subconjunto gramatical seguro, y cualquier cosa fuera de él es bloqueada.

Tool Schema Validation and Access Control

Validación de Schemas de Herramientas y Control de Acceso

Every tool call is evaluated against an explicit policy before execution—not after. The policy engine operates on a deny-by-default model: if there is no ALLOW rule, the call is blocked. Tools are defined with Pydantic schemas that validate inputs at the type level, and a policy layer adds contextual authorization.

Cada llamada de herramienta se evalúa contra una política explícita antes de la ejecución—no después. El motor de políticas opera en un modelo de denegación por defecto: si no hay una regla ALLOW, la llamada se bloquea. Las herramientas se definen con schemas Pydantic que validan entradas a nivel de tipo, y una capa de políticas añade autorización contextual.

from pydantic import BaseModel, Field

class SearchQuery(BaseModel):
    query: str = Field(max_length=500)
    max_results: int = Field(default=10, le=50)

TOOL_POLICY = {
    "search_web": {
        "allow_roles": ["researcher", "writer"],
        "rate_limit": "30/minute",
        "require_approval": False,
    },
    "delete_record": {
        "allow_roles": ["admin"],
        "rate_limit": "5/minute",
        "require_approval": True,  # human-in-the-loop
    },
}

Tool shadowing is a critical threat: a malicious MCP server may advertise a tool with a legitimate name but compromised logic. Zero trust requires strict schema validation and server provenance verification—every tool’s signature is checked against a registry of known-good schemas before the agent is allowed to call it.

El tool shadowing es una amenaza crítica: un servidor MCP malicioso puede publicitar una herramienta con un nombre legítimo pero lógica comprometida. Zero trust requiere validación estricta de schemas y verificación de proveniencia del servidor—la firma de cada herramienta se verifica contra un registro de schemas conocidos como buenos antes de que el agente pueda llamarla.

Agent-as-Tool Composition Security

Seguridad de Composición Agente-como-Herramienta

In hierarchical agent architectures, one agent delegates to another by calling it as a tool. This creates delegation chains where trust must narrow, not widen. A compromised agent in the chain cannot escalate its authority through delegation—each child agent receives strictly less privilege than its parent.

En arquitecturas jerárquicas de agentes, un agente delega a otro llamándolo como herramienta. Esto crea cadenas de delegación donde la confianza debe estrecharse, no ampliarse. Un agente comprometido en la cadena no puede escalar su autoridad a través de la delegación—cada agente hijo recibe estrictamente menos privilegios que su padre.

Dapr’s actor model provides natural isolation: each DurableAgent runs as an independent actor with its own state store and tool bindings. When agent A delegates to agent B, the delegation passes through the Dapr sidecar—which enforces the policy at the transport layer. Agent B’s identity (SPIFFE SVID) is verified independently. Its tool access is scoped to its own role, not inherited from agent A. The audit trail captures the full delegation chain: who called whom, with what authority, and what result.

El modelo de actores de Dapr proporciona aislamiento natural: cada DurableAgent corre como un actor independiente con su propio state store y bindings de herramientas. Cuando el agente A delega al agente B, la delegación pasa a través del sidecar de Dapr—que aplica la política en la capa de transporte. La identidad del agente B (SVID SPIFFE) se verifica independientemente. Su acceso a herramientas está scopeado a su propio rol, no heredado del agente A. La pista de auditoría captura la cadena de delegación completa: quién llamó a quién, con qué autoridad y con qué resultado.

Post-Quantum Cryptography for Agent Communication

Criptografía Post-Cuántica para Comunicación entre Agentes

Agent-to-agent communication today is encrypted with RSA or ECC—algorithms that a sufficiently large quantum computer running Shor’s algorithm will break. The “harvest now, decrypt later” threat is real: encrypted agent traffic captured today can be stored and decrypted when quantum hardware arrives. NIST has standardized post-quantum algorithms: ML-KEM (formerly CRYSTALS-Kyber, FIPS 203) for key encapsulation and ML-DSA (formerly CRYSTALS-Dilithium, FIPS 204) for digital signatures.

La comunicación agente-a-agente hoy está encriptada con RSA o ECC—algoritmos que una computadora cuántica suficientemente grande ejecutando el algoritmo de Shor romperá. La amenaza “cosechar ahora, descifrar después” es real: el tráfico de agentes encriptado capturado hoy puede almacenarse y descifrarse cuando llegue el hardware cuántico. NIST ha estandarizado algoritmos post-cuánticos: ML-KEM (anteriormente CRYSTALS-Kyber, FIPS 203) para encapsulación de claves y ML-DSA (anteriormente CRYSTALS-Dilithium, FIPS 204) para firmas digitales.

The implementation uses a hybrid approach: wrap existing ECC in a PQC layer (“double-bagging”). Every agent-to-tool tunnel uses ML-KEM-768 for key exchange (~1184 bytes public key) and ML-DSA for signing every tool request. A sidecar proxy handles the lattice math—the agent code itself never touches cryptographic primitives. This provides crypto-agility: when better algorithms emerge, swap them at the proxy layer without touching agent logic.

La implementación usa un enfoque híbrido: envolver el ECC existente en una capa PQC (“doble encapsulamiento”). Cada túnel agente-a-herramienta usa ML-KEM-768 para intercambio de claves (~1184 bytes de clave pública) y ML-DSA para firmar cada solicitud de herramienta. Un proxy sidecar maneja la matemática de retículos—el código del agente nunca toca primitivos criptográficos. Esto proporciona agilidad criptográfica: cuando surjan mejores algoritmos, se intercambian en la capa del proxy sin tocar la lógica del agente.

SPIRE has a post-quantum proof-of-concept that issues hybrid PQ X.509 SVIDs—agents retrieve both classical and PQ credentials from the Workload API. For edge-deployed agents (IoT, sensors), the PQuAKE protocol reduces computational overhead while maintaining forward secrecy. The goal: every agent action is signed with a quantum-resistant key, creating a tamper-proof audit trail that remains verifiable for decades.

SPIRE tiene un proof-of-concept post-cuántico que emite SVIDs X.509 híbridas PQ—los agentes recuperan credenciales tanto clásicas como PQ de la Workload API. Para agentes desplegados en edge (IoT, sensores), el protocolo PQuAKE reduce el overhead computacional mientras mantiene secrecía forward. El objetivo: cada acción del agente está firmada con una clave resistente a cuántica, creando una pista de auditoría a prueba de manipulaciones que permanece verificable por décadas.

Observability and Audit Trails

Observabilidad y Pistas de Auditoría

Standard logging (success/fail) is insufficient for agents that reason. You need a cognitive lineage—a flight recorder that captures every decision, its reasoning, the tool calls it considered, the ones it executed, and the authority under which each action was taken. OpenTelemetry provides the framework: distributed traces across agent boundaries, with security-specific span attributes.

El logging estándar (éxito/fallo) es insuficiente para agentes que razonan. Necesitas un linaje cognitivo—una caja negra que captura cada decisión, su razonamiento, las llamadas de herramientas que consideró, las que ejecutó y la autoridad bajo la cual se tomó cada acción. OpenTelemetry proporciona el framework: trazas distribuidas a través de límites de agentes, con atributos de span específicos de seguridad.

from opentelemetry import trace

tracer = trace.get_tracer("agent-security")

with tracer.start_as_current_span("agent.tool_call") as span:
    span.set_attribute("agent.id", agent_svid)
    span.set_attribute("tool.name", tool_name)
    span.set_attribute("security.policy_result", "ALLOW")
    span.set_attribute("security.authority", "researcher-role")
    span.set_attribute("security.delegation_chain", "orchestrator->researcher")
    result = execute_tool(tool_name, validated_input)
    span.set_attribute("tool.result_hash", sha256(result))

Every tool call, delegation, and data access becomes a traceable event. Tamper-proof audit logs (signed with ML-DSA) create an immutable record. Anomaly detection monitors behavioral patterns: if an agent that normally makes 5 tool calls per minute suddenly makes 50, or accesses a resource it’s never touched before, the system flags it for review or automatically restricts its scope.

Cada llamada de herramienta, delegación y acceso a datos se convierte en un evento rastreable. Las pistas de auditoría a prueba de manipulaciones (firmadas con ML-DSA) crean un registro inmutable. La detección de anomalías monitorea patrones de comportamiento: si un agente que normalmente hace 5 llamadas de herramientas por minuto de repente hace 50, o accede a un recurso que nunca ha tocado antes, el sistema lo marca para revisión o restringe automáticamente su scope.

The Four-Phase Implementation

La Implementación en Cuatro Fases

Deploying zero trust for agents is not a single sprint—it’s a phased program. The Cloud Security Alliance recommends four phases executed over 6-12 months.

Desplegar zero trust para agentes no es un sprint único—es un programa por fases. La Cloud Security Alliance recomienda cuatro fases ejecutadas en 6-12 meses.

Phase 0 — Discovery: Inventory every deployed agent, every tool binding, every data flow. Identify shadow AI—agents running without governance. Map transaction flows between agents, tools, and data stores. This is the foundation: you cannot secure what you cannot see.

Fase 0 — Descubrimiento: Inventa cada agente desplegado, cada binding de herramienta, cada flujo de datos. Identifica IA sombra—agentes corriendo sin gobernanza. Mapea los flujos de transacciones entre agentes, herramientas y almacenes de datos. Esta es la base: no puedes asegurar lo que no puedes ver.

Phase 1 — Foundation: Deploy cryptographic identity for all agents via SPIFFE/SPIRE. Replace standing credentials with JIT provisioning. Move agents into sandboxed execution environments (Firecracker for untrusted, gVisor for controlled). These two steps address the most critical vulnerabilities and establish the foundation for everything else.

Fase 1 — Fundación: Despliega identidad criptográfica para todos los agentes vía SPIFFE/SPIRE. Reemplaza credenciales permanentes con aprovisionamiento JIT. Mueve agentes a entornos de ejecución en sandbox (Firecracker para no confiables, gVisor para controlados). Estos dos pasos abordan las vulnerabilidades más críticas y establecen la base para todo lo demás.

Phase 2 — Enforcement: Implement the deny-by-default policy engine. Every tool call evaluated against explicit ALLOW rules. Schema validation for all tool inputs. Human-in-the-loop approval for high-impact actions. OpenTelemetry instrumentation for full behavioral observability.

Fase 2 — Aplicación: Implementa el motor de políticas de denegación por defecto. Cada llamada de herramienta evaluada contra reglas ALLOW explícitas. Validación de schema para todas las entradas de herramientas. Aprobación human-in-the-loop para acciones de alto impacto. Instrumentación OpenTelemetry para observabilidad conductual completa.

Phase 3 — Hardening: Deploy hybrid PQC for agent communication. Formal verification of critical security policies (Lean 4). Continuous red-teaming against the OWASP Agentic Top 10. Behavioral anomaly detection with automated scope restriction. This phase never ends—security is a continuous process, not a destination.

Fase 3 — Endurecimiento: Despliega PQC híbrido para comunicación entre agentes. Verificación formal de políticas de seguridad críticas (Lean 4). Red-teaming continuo contra el OWASP Agentic Top 10. Detección de anomalías conductuales con restricción automática de scope. Esta fase nunca termina—la seguridad es un proceso continuo, no un destino.

---

References

Referencias