Solución · AI Operations
Tu agente de IA no necesita equivocarse para hacer daño. Basta con que alguien de fuera le hable.
El gobierno de agentes decide qué tiene permitido hacer el tuyo. La seguridad decide qué puede conseguir que haga alguien que no trabaja aquí: una instrucción escondida en un correo que el agente lee, una herramienta que no auditó nadie, un secreto que viaja en el contexto. Montamos esa capa —aislamiento, identidad, filtrado y traza— y la operamos.
El problema
Un agente con permisos es una superficie de ataque nueva. No la cubre tu proveedor de seguridad ni la cubre tu capa de gobierno.
- Tu agente lee correos, tickets, documentos o páginas web. Todo eso es texto que escribió alguien de fuera, y el modelo no distingue entre lo que tú le pediste y lo que le llega dentro del contenido.
- Las credenciales del agente no son suyas: son las de un usuario técnico con más permisos de los que tiene ninguna persona del equipo, y viven en una variable de entorno que nadie ha rotado desde que se montó.
- Cada herramienta que le conectas amplía lo que puede hacer y, en la misma medida, lo que le pueden hacer hacer. Nadie revisa quién publicó ese conector, qué pide en cada llamada ni qué cambió en su última versión.
- El contexto arrastra datos de un caso al siguiente porque la sesión no se limpia, o porque el índice del que recupera información no filtra por los permisos de quien está preguntando.
- Si mañana alguien pregunta qué hizo el agente, con qué datos y bajo qué versión, la respuesta está repartida entre los registros de tres sistemas que no comparten identificador.
Coste de seguir igual
La lista de referencia del sector ya no deja sitio a la duda: en el OWASP Top 10 for LLM Applications, edición 2025, la inyección de instrucciones ocupa el primer puesto por segunda edición consecutiva, la exposición de información sensible el segundo, la cadena de suministro el tercero y la agencia excesiva —dar al agente más capacidad de la que su tarea necesita— el sexto. No es un riesgo futuro: es exactamente el guion con el que va a mirarte cualquiera que audite tu sistema, sea tu cliente grande, tu aseguradora o tu regulador. Y el coste de no tener respuesta no se paga en incidencias abiertas: se paga en un dato que salió, una acción que se ejecutó y una explicación que no puedes dar porque no hay traza.
La solución
Montamos la capa de seguridad del agente —aislamiento, identidad, filtrado y traza forense— y la operamos como función continua
- 1Modelamos la amenaza agente por agente, que es lo que casi nadie hace: de dónde viene el texto que lee, qué datos alcanza, qué acciones puede ejecutar y qué pasaría si un tercero controlara cada una de esas tres cosas. De ahí sale la lista de lo que hay que blindar, en orden, y no al revés.
- 2Separamos instrucción de dato. Lo que llega de fuera entra como contenido, nunca como orden: plantillas que el contenido no puede reescribir, filtrado de entrada, y validación de la salida antes de que toque un sistema real. Que el modelo se deje convencer es asumible; que su salida ejecute sin revisar, no.
- 3Damos identidad propia a cada agente en vez de una llave maestra compartida: credenciales de vida corta, permiso mínimo por herramienta y por dato, y una acción sensible respaldada por una autorización acotada, no por un token eterno en un fichero de entorno.
- 4Aislamos la ejecución de herramientas: entorno acotado, lista blanca de destinos y dominios, y revisión real de cada conector que se instala —quién lo publica, qué permisos pide, qué cambia en cada versión—. La cadena de suministro es el tercer riesgo de la lista y también el más fácil de colar.
- 5Cortamos la fuga por contexto: la recuperación de información filtra por los permisos de quien pregunta, la sesión se limpia entre casos, y los secretos y datos personales se enmascaran antes de salir hacia cualquier modelo externo.
- 6Cerramos con traza forense y respuesta: un identificador de caso que atraviesa modelo, herramientas y sistemas, retención pensada para poder investigar, freno por agente y un procedimiento de respuesta escrito. Y lo operamos: pruebas adversarias periódicas contra los agentes vivos, no una auditoría de una sola vez que envejece en tres meses.
Lo que cambia
Lo que dejas de perder
La inyección de instrucciones deja de ser una posibilidad teórica: se prueba contra tus agentes vivos, con casos reales de tu negocio, antes de que la pruebe alguien de fuera.
Mecanismo
El agente deja de compartir la llave maestra: cada uno tiene identidad propia, permiso mínimo y credencial de vida corta, así que un agente comprometido no abre toda la casa.
Mecanismo
La fuga por contexto deja de depender de que nadie pregunte lo que no debe: se filtra por los permisos de quien pregunta y se limpia entre casos, por diseño y no por confianza.
Mecanismo
Qué medimos: cobertura de agentes con modelo de amenaza vivo, % de acciones sensibles cubiertas por credencial acotada o autorización, hallazgos de pruebas adversarias abiertos y cerrados, y tiempo que se tarda en reconstruir un caso completo de punta a punta.
Qué medimos
Ficha técnica
- Trabajo que elimina
- descubrir a posteriori que un agente se dejó engañar, que arrastraba permisos de más o que su contexto filtró datos —y reconstruir el caso a mano entre registros que no encajan
- Implementación habitual
- 3–6 semanas
- Entrada
- los agentes que ya tienes en producción, sus herramientas conectadas, sus credenciales y las fuentes de texto que leen
- Salida
- cada agente con modelo de amenaza, identidad propia y permiso mínimo, herramientas aisladas y en lista blanca, contexto filtrado por permisos y una traza de punta a punta que permite investigar
- Compatible con
- OpenAIAnthropicAzure OpenAILangChainLlamaIndexn8nServidores MCP
- Puede conectarse con
- Tu gestor de secretos y tu proveedor de identidadTu SIEM o tu stack de observabilidadTu capa de gobierno de agentes, si ya la tienes montada
- Qué medimos
- cobertura de agentes con modelo de amenaza vivo% de acciones sensibles con credencial acotada o autorizaciónhallazgos de pruebas adversarias abiertos y cerradostiempo hasta reconstruir un caso completo
- Adecuado para
- empresas con agentes ya en producción que leen texto de terceros o actúan sobre sistemas reales, y que tienen que responder ante un cliente, una auditoría o un regulador
- No adecuado para
- quien todavía está en la prueba de concepto sin datos reales ni permisos de escritura: ahí lo que toca es diseñarlo bien, no blindarlo
Preguntas frecuentes
En quién es el adversario. Gobernar responde a «qué tiene permitido hacer mi agente y quién responde si se equivoca»: políticas, aprobaciones, auditoría, cumplimiento. Es la capa que evita el error propio y la tienes desarrollada en gobernar los agentes de IA de tu empresa. Seguridad responde a otra pregunta: «qué puede conseguir que haga mi agente alguien que no trabaja aquí». Ahí no hay política que valga, porque el atacante no lee tus políticas: hay que separar instrucción de dato, aislar herramientas, acotar identidades y dejar traza para investigar. Se complementan y el orden importa poco; lo que no funciona es tener una y creer que tienes las dos.
Para el perímetro, los accesos y los equipos, sí, y no lo tocamos. Donde se queda corto es en la superficie nueva: un agente que ejecuta acciones a partir de texto que escribió un tercero no se parece a nada que cubra un cortafuegos. La inyección de instrucciones no es un exploit de red, es que el modelo obedezca a quien no debe. El aislamiento de herramientas no es segmentar la red, es decidir qué puede invocar un proceso que decide en tiempo de ejecución. Y la revisión de un conector no es un análisis de vulnerabilidades, es leer qué permisos pide y quién lo publicó. Esa capa está en tierra de nadie entre tu proveedor de seguridad y tu consultora de IA: por eso la montamos nosotros, y por eso el servicio detrás es seguridad completa, clásica y de IA.
No, y desconfía de quien te diga que sí. Mientras el modelo procese instrucciones y datos por el mismo canal, siempre habrá texto capaz de convencerlo; por eso ese riesgo lleva dos ediciones seguidas en el primer puesto de la lista de OWASP. Lo que sí se puede hacer —y es lo que cambia el resultado— es que dejarse convencer no baste para causar daño: permiso mínimo para que la acción peligrosa no esté disponible, validación de la salida antes de que toque un sistema, autorización humana en lo que cuesta dinero o toca a personas, y traza para detectarlo pronto. La defensa no es un muro: son capas que hacen que un fallo del modelo no se convierta en un incidente del negocio.
¿Lo montamos en tu negocio?
Tú tienes el problema localizado. Nosotros lo dejamos funcionando y medido.