La seguridad de agentes de IA (Agentic AI Security) es la disciplina encargada de proteger sistemas de inteligencia artificial autónomos frente a manipulaciones, abusos de privilegios y fugas de datos, es decir, aquellos que no solo responden preguntas, sino que planifican, actúan y toman decisiones en flujos empresariales complejos.
En Chakray, sabemos que conectar estos agentes autónomos a nuestras herramientas empresariales mediante Model Context Protocol (MCP) multiplica la superficie de ataque de forma exponencial. En este artículo, traducimos el OWASP Top 10 for Agentic Applications 2026 en controles de arquitectura secuenciados. Nuestro objetivo es claro: construir defensas robustas que sobrevivan a la rotación de integradores y a los cambios internos del equipo.
Por qué el 91% de empresas usa agentes de IA y sólo el 10% sabe gobernarlos
Según el informe AI at Work 2025 de Okta —una encuesta a 261 directivos de nivel C-suite y VP en nueve países—, el 91% de las organizaciones ya opera agentes de IA, pero apenas un 10% cuenta con una estrategia madura de gobernanza para sus identidades no humanas (NHI). Esto no es un simple descuido de configuración; es un fallo estructural del modelo operativo que acarrea costes inmensos. Desplegar agentes con credenciales estáticas de alto privilegio, sin segmentar su identidad ni establecer flujos de aprobación humana, es dejar la puerta abierta. El coste para remediar un incidente de este tipo implica pérdidas millonarias si sumamos la contención técnica, el impacto operativo y las severas multas bajo normativas como GDPR o la Ley de IA de la UE.
El reporte State of Agentic AI Security v2.01 de OWASP nos da un baño de realidad: las diez categorías de riesgo (ASI01-ASI10) ya tienen vulnerabilidades y exploits de producción documentados. Los vectores de ataque han dejado de ser escenarios de laboratorio. Por eso, no sorprende que la encuesta AI Agent Survey de PwC señale que el 88% de los ejecutivos prevé aumentar su inversión en ciberseguridad para IA en los próximos meses. Saben que la brecha entre una adopción apresurada y la madurez técnica es su mayor riesgo.
Secuestro de objetivos por inyección de prompts indirecta: el escenario real
Pensemos que un equipo de DevSecOps conecta un agente de IA a las herramientas financieras internas usando credenciales estáticas de alto privilegio a través de MCP. De un día para otro, el agente tiene acceso sin restricciones a las bases de datos de facturación, contratos y nóminas. Durante una de sus tareas rutinarias, procesa un documento aparentemente inofensivo que esconde instrucciones maliciosas. Al no contar con una defensa en profundidad (Guardrails de entrada/salida, arquitecturas Dual-LLM y validación de esquemas en el MCP Gateway) y sólida contra la inyección de prompts indirecta el sistema ni se inmuta.
En cuestión de horas, el agente sufre un Goal Hijack (ASI01) y exfiltra 150.000 registros de nóminas a un servidor externo. No hubo un circuit breaker (cortacircuitos) que frenara la extracción, ni un flujo de aprobación humana (Human-in-the-Loop), o una restricción de salida de red que impidiera alcanzar un destino externo no autorizado para un movimiento de datos tan masivo. El fallo se descubre en una auditoría manual tres días después. El problema de fondo no fue puramente técnico, sino de gobernanza: ningún proveedor dejó documentado quién debía revisar los permisos del agente ni cuándo actuar ante una anomalía.
Diagrama de secuencia de ataque Goal Hijack (ASI01)
Mapa de riesgos OWASP Top 10 for Agentic Applications 2026 traducido en controles
El marco OWASP Top 10 for Agentic Applications 2026 estructura los diez riesgos críticos de la IA autónoma (ASI01-ASI10). Si bien OWASP define los riesgos de forma neutral y agnóstica, nosotros proponemos aterrizarlos en una arquitectura ejecutable y real. Utilizando herramientas como Keycloak (identidad), API gateways como Apache APISIX o Gravitee, orquestadores como Workato, e integración mediante Apache Camel, aquí tienes cómo mapeamos cada riesgo a una capa de control concreta:
| ID | Riesgo | Capa de control |
| ASI01 | Goal Hijacking (secuestro de objetivos) | Validación de entrada + Human Approval |
| ASI02 | Tool Misuse (uso indebido de herramientas) | Policy Enforcement + Execution Limits |
| ASI03 | Identity & Privilege Abus (Abuso de identidad y privilegios) | Gobernanza NHI + OAuth 2.1 con credenciales efímeras + mTLS/SPIFFE + ABAC evaluado fuera del modelo |
| ASI04 | Agentic Supply Chain Vulnerabilities (cadena de suministro) | Inventory Governance + Audit Trail |
| ASI05 | Unexpected Code Execution (ejecución de código inesperada) | Sandboxing reforzado (gVisor/Kata) + egress denegado por defecto + circuit breaker |
| ASI06 | Memory Poisoning (contaminación de memoria) | Cryptographic Provenance, aislamiento de memoria RAG, sanitización de embeddings y TTL (Time-To-Live) en contexto de agentes |
| ASI07 | Insecure Inter-Agent Communication (comunicación insegura entre agentes) | mTLS entre agentes + firma de mensajes + validación de esquema de tarea + segmentación de dominios de confianza |
| ASI08 | Cascading Failures (fallo en cadena) | Segmentación + Execution Limits |
| ASI09 | Human-Agent Trust Exploitation (explotación de la confianza humano-agente) | Approval Workflow + Audit Trail |
| ASI10 | Rogue Agents (agentes descontrolados) | Inventario/AI SBOM + detección de anomalías plan-vs-ejecución + kill switch con revocación de credenciales |
Para tener la imagen completa, la guía de adopción segura de CISA y los Five Eyes aporta cinco dimensiones de riesgo operativo: privilegios, diseño, comportamiento, estructural y rendición de cuentas. Adicionalmente, la exhaustiva investigación de Checkmarx Zero sobre MCP detalla 11 riesgos emergentes en este protocolo, destacando la escalada de privilegios y la fuga de tokens.
Autenticación y autorización: gobernanza NHI y Zero-Trust
Debemos tratar a cada agente como un usuario corporativo de alto riesgo. La gobernanza de identidades no humanas (NHI) nos permite erradicar las credenciales compartidas. Para lograrlo, asignamos a cada agente alcances (scopes) mínimos y utilizamos patrones avanzados como OAuth 2.0 Token Exchange (RFC 8693) (por ejemplo, implementado con Keycloak), lo que permite al agente intercambiar credenciales para obtener una delegación de privilegios efímera..
Así, aplicar el principio de Least Agency significa que el agente sólo recibe los permisos estrictamente necesarios para el contexto de su tarea inmediata, evaluados en tiempo real mediante un control de acceso basado en atributos (ABAC). Además, toda comunicación debe estar blindada con mTLS. En lugar de dejar que los agentes llamen a las APIs a su antojo, implementamos un MCP Gateway (sobre API SIX o Gravitee) que actúa como punto centralizado de Zero-Trust: si la política de seguridad no aprueba la solicitud, esta simplemente no pasa.
Segmentación y límites: sandboxing, circuit breakers y contención de la inyección de prompts
Aislar a los agentes con límites de CPU, memoria y disco es solo la mitad del trabajo, y no la decisiva. Un contenedor estándar no es una frontera de seguridad frente a código no confiable: hacen falta runtimes reforzados (gVisor, Kata, Firecracker), ficheros de solo lectura y perfiles seccomp. La otra mitad es la red: egress denegado por defecto con lista de destinos permitidos, DNS controlado y bloqueo del endpoint de metadatos del cloud, que de otro modo entrega las credenciales de la instancia. Un agente comprometido que no puede abrir una conexión saliente no exfiltra nada.
También necesitamos frenos de emergencia, y conviene no confundir dos. El circuit breaker es automático, actúa sobre un flujo concreto y es reversible: corta la ejecución al superar un presupuesto predefinido (llamadas, tiempo, volumen leído, coste) y se restablece al normalizarse. El kill switch es manual y global: lo acciona una persona para detener a un agente, y debe revocar sus tokens además de parar el proceso, porque un agente detenido con credenciales vivas sigue siendo utilizable. Ambos deben existir y ambos deben probarse en simulacro.
Por último, conviene asumir una premisa incómoda: la inyección de prompts indirecta no se resuelve saneando la entrada. El modelo no distingue de forma fiable datos de instrucciones y todo filtro es evadible; las agencias del marco Five Eyes la describen como el riesgo más persistente del ecosistema agéntico. La defensa es arquitectónica: asumir que la inyección tendrá éxito y limitar lo que el agente puede hacer entonces. Es decir, Least Agency (solo las herramientas de la tarea inmediata), autorización evaluada por un PDP determinista fuera del modelo, y confirmación humana fuera de banda para toda acción irreversible.
Observabilidad, aprobación y trazabilidad continua
El registro de actividad (logging) no puede ser opcional. Debemos registrar la identidad del agente, cada solicitud, las bases de datos que tocó, la latencia y los errores. Asegurar la procedencia criptográfica (Cryptographic Provenance) del contexto garantiza que nadie manipule la cadena de razonamiento del agente.
A nivel de negocio, los flujos de aprobación humana (Human-in-the-Loop) son innegociables para acciones sensibles. Debemos definir claramente qué operaciones requieren el «OK» de un humano, quién es el responsable y en qué plazos (SLA) se debe actuar. Además, normativas como el Reglamento de IA de la UE y el GDPR exigen tener siempre a mano un inventario actualizado de estos componentes y pruebas auditables de sus decisiones.
De los controles aislados al gobierno transferible
Como vimos en el escenario inicial, cuando un agente sufre un secuestro de objetivos, el problema real es que ningún control aislado (sea sandboxing o mTLS) sobrevive sin un modelo operativo que lo respalde.
Un marco de gobernanza sólido perdura aunque cambiemos de proveedor tecnológico o rotemos a nuestro personal interno. Esto convierte un simple checklist técnico en un proceso vivo, auditable y verdaderamente resiliente.
| Dimensión | Enfoque táctico (checklist temporal) | Modelo de gobernanza operativo (largo plazo) |
| Identidad de agentes | Uso de credenciales estáticas sin un responsable claro a nivel operativo. | Segmentación NHI en Keycloak con revisión trimestral a cargo de un responsable de gobierno. |
| Aprobación de acciones | Pedir «aprobación humana» como recomendación general sin definir cómo ni cuándo. | Flujo Human-in-the-Loop documentado con SLA estrictos y trazabilidad por decisión. |
| Rotación de partners | La seguridad depende de lo que recuerde el integrador que montó el sistema. | Metodología documentada y transferible; la seguridad sobrevive independientemente de quién opere. |
| Auditoría y trazabilidad | Reportes retrospectivos sólo cuando hay una auditoría o un incidente grave. | Auditoría continua, inventario de IA en tiempo real y evidencias listas para normativas de la UE. |
| Superficie MCP | Considerado solo un «riesgo técnico» más, aislado de la infraestructura. | El MCP Gateway se gobierna como una extensión natural del gobierno de APIs corporativo. |
Implementación práctica en 6 pasos
El orden importa porque cada paso depende del anterior: sin identidad única por agente no hay política que aplicar, sin gateway no hay dónde imponer, sin aislamiento se evade llamando directamente al sistema, sin observabilidad no se sabe si funciona y sin evidencias la aprobación humana no es demostrable:
- Gobernanza NHI y OAuth 2.0: el equipo de Identidad certifica trimestralmente los scopes de cada agente en Keycloak y verifica que no existan credenciales compartidas ni secretos de larga vida. La recertificación se adelanta siempre que se dé de alta un agente, se conecte un nuevo servidor MCP o se amplíe un scope, y pasa a mensual para los agentes con acceso a datos personales, financieros o a sistemas de producción.
- MCP Gateway centralizado: arquitectura de APIs utiliza APIsix o Gravitee para validar cada llamada del agente contra las políticas de la empresa.
- Sandboxing, egress y circuit breakers: infraestructura garantiza que el agente se ejecute aislado, sin acceso a credenciales de otros agentes ni al endpoint de metadatos del cloud, y con salida de red denegada por defecto salvo lista explícita de destinos.
- Observabilidad total: operaciones de Seguridad registra y monitorea cada interacción con marca de tiempo e identidad exacta.
- Flujos de aprobación (Human-in-the-Loop): Negocio y Seguridad delimitan la lista de acciones críticas que requieren intervención humana documentada.
- Auditoría e inventario: la detección de anomalías sobre el tráfico MCP y el alta de agentes y servidores en el inventario son procesos automáticos y continuos, con alertas atendidas en el momento. El comité de Gobierno de IA revisa quincenalmente lo generado —alertas cerradas, excepciones aceptadas, altas pendientes— y consolida trimestralmente el paquete de evidencias regulatorias.
Diagrama de arquitectura de gobernanza Zero-Trust para agentes (MCP)
Cualquiera que sea el framework (LangChain/LangGraph, SDKs de agentes de los proveedores, orquestadores propios), este modelo funciona porque asigna nombres, apellidos y responsabilidades claras a cada capa de control. Los flujos de orquestación de alto nivel pueden implementarse sobre plataformas iPaaS como Workato, delegando la conexión compleja con sistemas legados a microservicios intermediarios, basados en Apache Camel.
¿Tu organización está migrando hacia arquitecturas de IA agéntica?
Minimiza los riesgos operativos y asegura el cumplimiento regulatorio desde el día uno. Para auditar tu infraestructura o implementar un marco de gobernanza Zero-Trust, te invitamos a contactar con nuestro equipo de expertos en Chakray.
FAQ
¿Cómo verificar que un agente de IA solo accede a las APIs y datos que le autorizo?
Implementando una gobernanza NHI con control basado en atributos (ABAC). Cada agente recibe una identidad única, se autentica de forma segura (mTLS) y el MCP Gateway actúa como aduana centralizada validando sus políticas y registrando cada movimiento.
¿Qué riesgos implica dar a un agente acceso directo a bases de datos corporativas?
Según el OWASP ASI, la escalada de privilegios y el secuestro de objetivos son los peligros más graves. Un simple ataque de inyección de prompts puede hacer que el agente exfiltre miles de registros en horas. El aislamiento (sandboxing) y la aprobación humana obligatoria para acciones críticas son defensas innegociables.
¿Cómo detectamos ataques de inyección de prompts contra nuestros agentes?
La detección se apoya en tres señales, porque el filtrado no es fiable. Primera, la desviación entre plan y ejecución: herramientas invocadas fuera del plan aprobado. Segunda, el egress: destinos no autorizados o volumen de salida anómalo para esa identidad de agente. Tercera, canary tokens en el contexto: si aparecen en una llamada saliente, la fuga está confirmada. Al dispararse cualquiera de ellas, el circuit breaker corta la ejecución y se revocan los tokens del agente.
¿Cómo manejamos la autenticación cuando un agente usa muchísimas herramientas?
A través de la segmentación de identidades. Usamos Keycloak (OAuth 2.0) para dar accesos específicos a cada tarea, ciframos el canal con mTLS y pasamos todas las peticiones por un MCP Gateway que verifica el inventario en tiempo real.
¿En qué se diferencia proteger el protocolo MCP de proteger nuestras APIs tradicionales?
El protocolo MCP está diseñado específicamente para conectar agentes y herramientas con un control muy granular. Las APIs tradicionales usan sistemas de identidad pensados para aplicaciones fijas o humanos, no para entidades autónomas y efímeras. El MCP Gateway entiende y controla este contexto agéntico.
¿Qué estándares deberíamos usar para nuestras auditorías?
Toma como base los riesgos del OWASP Top 10 for Agentic Applications 2026 y la guía de adopción de CISA/Five Eyes. A nivel regulatorio, el GDPR y el Reglamento de IA de la UE te exigirán evidencias de procedencia criptográfica y registros inalterables de las decisiones de tus agentes.
¿Cómo evitamos que un agente escale privilegios dentro de nuestra infraestructura?
Con tres capas. Autorización: privilegios por tarea y credenciales efímeras, para que no haya permiso permanente que escalar. Aislamiento: entorno con frontera reforzada, sin visibilidad sobre la infraestructura base, sin acceso al endpoint de metadatos del cloud ni a credenciales de otros agentes. Frenos: circuit breaker automático por presupuestos, y kill switch manual que detiene al agente y revoca sus credenciales. El kill switch no debe dispararse «ante la mínima desviación» o el equipo acabará desactivándolo.
