Sistema inmunitario agéntico
Arquitectura de referencia para operar agentes de IA en la empresa sin concentrar la confianza en ninguno de ellos. Cinco capas —identidad, mínimo privilegio, contención, supervisión y recuperación— dan por supuesto que algún agente acabará equivocándose o siendo subvertido, y hacen que ese día sea sobrevivible en vez de catastrófico. La unidad de defensa es la ejecución concreta, no la flota.
Conceptos clave
- Dar por hecho el compromiso: la pregunta no es si un agente actuará mal, sino hasta dónde llega cuando lo haga.
- Identidad por ejecución: cada ejecución lleva su propia credencial efímera, nunca una cuenta de operador compartida.
- Contención antes que prevención: el radio de daño se diseña, no se espera — una ejecución subvertida afecta a una tarea, no al parque.
- La recuperación es una superficie de diseño: trazar, deshacer y parar se construyen antes, no se improvisan durante el incidente.
Definición
El sistema inmunitario agéntico es una arquitectura de ejecución por capas que permite a los agentes de IA actuar de verdad sobre los sistemas de la empresa acotando lo que una sola ejecución puede alcanzar, observar o dañar, mediante identidad por ejecución, privilegio limitado a la tarea, contención de ejecución y de salida, supervisión humana por riesgo y recuperación trazable.
Arquitectura
La arquitectura invierte la pregunta habitual. En vez de preguntar cómo impedir que un agente se equivoque —cosa que ninguna barrera consigue de forma fiable frente a un sistema que razona— pregunta hasta dónde llega el agente en el momento en que se equivoca. Cada capa es un límite de alcance, y las capas son independientes para que el fallo de una no abra las demás.
La identidad es el cimiento. Cada ejecución recibe una credencial efímera ligada a la tarea, a quien la pide y a las herramientas que declaró necesitar. Los agentes no comparten cuenta de servicio: cuando algo sale mal, la traza nombra una ejecución y no una flota, y revocar cuesta un token en vez de una rotación en todo el parque.
El privilegio se limita a la tarea y caduca con ella. El intermediario de herramientas concede el conjunto estrecho de capacidades que la ejecución declaró de antemano —leer este ticket, escribir este registro— y rechaza cualquier otra, de modo que una inyección de prompt que convenza al modelo de intentar más no encuentra nada que llamar.
La contención da por supuesto que las dos capas anteriores pueden caer. La ejecución ocurre en un entorno aislado sin credenciales ambientales; la salida a red pasa por una lista de destinos permitidos, así que la exfiltración no tiene adónde enviar; y lo que el agente produce se codifica en la frontera para que su salida no se convierta en la instrucción del siguiente sistema.
La supervisión es donde una persona asume la responsabilidad, colocada por riesgo y no por defecto: las acciones irreversibles o reguladas se detienen a esperar aprobación, y los resultados de baja confianza escalan con todo el contexto de la ejecución. Poner puerta a todo derrota la automatización y enseña a los revisores a aprobar sin leer.
La recuperación cierra el círculo. Cada ejecución se traza bajo un único identificador de correlación a través de modelos, herramientas y reintentos; las acciones se diseñan con su contrapartida compensatoria cuando el sistema de destino lo permite; y un interruptor de parada detiene una clase de ejecuciones sin tumbar la plataforma.
Flujo de petición
- 1. Petición: llega una tarea con quien la solicita y un conjunto declarado de herramientas y ámbitos de datos.
- 2. Emisión: el intermediario acuña una identidad efímera, limitada a la ejecución y ligada a esa declaración.
- 3. Admisión: la ejecución arranca en un entorno aislado, sin credenciales ambientales y con lista de salida permitida.
- 4. Acción: cada llamada a herramienta se autoriza contra el ámbito de la ejecución; lo que queda fuera se rechaza y se registra.
- 5. Puerta: las acciones irreversibles o reguladas se detienen a esperar aprobación humana con el contexto adjunto.
- 6. Emisión de salida: lo producido se codifica en la frontera para que aguas abajo no se ejecute como instrucción.
- 7. Cierre: la identidad caduca, la traza se sella bajo su identificador de correlación y las acciones compensatorias siguen disponibles.
Componentes
Escenario de referencia
- Contexto
- Una empresa ilustrativa que opera decenas de agentes en ticketing, finanzas y conocimiento interno, donde cada agente puede leer y escribir en sistemas de registro.
- Escenario
- Un paso de recuperación ingiere un documento con una instrucción inyectada que pide al agente exportar registros de clientes. El modelo obedece, pero la herramienta de exportación queda fuera del ámbito declarado de la ejecución y se rechaza; el intento queda registrado, la regla de anomalía detiene la ejecución y el identificador de correlación da a quien responde la cadena completa en una sola consulta.
- Tecnología
- Emisor de credenciales por ejecución, intermediario de herramientas con ámbitos, ejecución aislada, lista de salida permitida, codificación de frontera, puerta de aprobación por riesgo y trazado correlacionado.
- Carga
- Automatización continua de fondo con picos alrededor de los procesos de negocio; la acción rara y de alto impacto es una fracción pequeña de las llamadas y es la que carga el riesgo.
- Resultados
- Objetivo de referencia, no una medición: una ejecución subvertida queda acotada a su ámbito declarado, cada rechazo es atribuible a una ejecución, y toda acción ejecutada se puede trazar y —cuando el sistema de destino lo permite— compensar.
Beneficios
- Un agente equivocado o subvertido cuesta una tarea, no el parque entero.
- Los incidentes son atribuibles a una ejecución y no a una cuenta compartida, así que la respuesta es dirigida y revocar sale barato.
- La inyección de prompt pierde casi todo su valor: convencer al modelo no le concede una capacidad que nunca tuvo.
- El esfuerzo de supervisión se concentra en las acciones realmente irreversibles, y así la aprobación sigue significando algo.
Riesgos
- Los ámbitos declarados se separan de lo que los agentes necesitan de verdad y los equipos los ensanchan hasta que el mínimo privilegio es nominal.
- Poner puerta a demasiadas cosas enseña a los revisores a aprobar sin leer, que es peor que no poner puerta.
- El aislamiento y los intermediarios añaden latencia y superficie operativa que un despliegue pequeño quizá no justifique.
- Hay efectos externos que no admiten compensación: un correo enviado o una factura pagada no se deshacen.
KPIs
- Ejecuciones con identidad propia y efímera
- El control que sostiene el peso. Cualquier cifra por debajo del 100 % significa que algún camino sigue usando una credencial compartida.
- Intentos de herramienta fuera de ámbito, rechazados
- Contados por ejecución. Que suban dice algo del entorno, no necesariamente que el diseño falle.
- Radio de daño por ejecución
- Cuántos sistemas y registros podría alcanzar una sola ejecución completamente subvertida. Es el número que la arquitectura existe para encoger.
- Tasa de acciones con puerta y latencia de aprobación
- Importan las dos: una tasa alta derrota la automatización y una latencia alta hace que los equipos desactiven la puerta.
- Completitud de la traza
- Proporción de ejecuciones reconstruibles de principio a fin bajo un identificador de correlación, reintentos y cambios de modelo incluidos.
- Tiempo hasta revocar
- Desde la detección hasta que la capacidad de una ejecución ya no existe. Con credenciales efímeras debería parecerse a su caducidad, no a una rotación.
Coste y escalabilidad
- Los intermediarios de identidad y de herramientas están en el camino caliente de cada llamada, así que marcan el techo; son sin estado y escalan en horizontal, pero su latencia se paga en cada uso de herramienta.
- El arranque del entorno aislado domina el coste de las ejecuciones cortas; mantener entornos calientes en pool cambia profundidad de aislamiento por latencia y debe ser una decisión explícita.
- La aprobación humana no escala de forma lineal y es la restricción real: el conjunto con puerta tiene que seguir siendo pequeño según crece la flota, o la cola se convierte en la caída.
- El almacenamiento de trazas crece con ejecuciones por llamadas a herramienta; muestrear vale para observabilidad pero no para auditoría, así que las dos políticas de retención deben ir separadas.
Modos de fallo observados
- Una credencial de servicio compartida sobrevive en algún punto de la pila y derrota en silencio la identidad por ejecución.
- La lista de salida se sortea a través de un destino permitido que a su vez reenvía los datos.
- Las trazas se rompen en un reintento o en un cambio de modelo, y la cadena del incidente ya no se puede reconstruir.
- La cola de aprobación se atasca y la puerta se desactiva «temporalmente» para vaciarla.
- La salida de una herramienta se trata como entrada de confianza en el paso siguiente, y la contención pasa a ser una sola frontera con fugas.
Lecciones aprendidas
- Diseña el radio de daño antes que la capacidad: hasta dónde puede llegar un agente es una pregunta más difícil que qué puede hacer, y contestarla primero hace tratable el resto.
- La identidad por ejecución es la capa que sostiene el peso; sin ella, cualquier otro control se aplica contra un sujeto que no sabes nombrar.
- Una puerta que salta con todo es una puerta que no salta con nada: reserva la aprobación humana para lo irreversible.
- Da por hecho que al modelo lo convencerán, y diseña para que convencer no sea autorizar.
- La recuperación hay que construirla con el sistema en calma; nadie diseña una acción compensatoria durante un incidente.
Tecnologías
Ejemplos
- Una instrucción inyectada en un documento recuperado pide una exportación de datos; la herramienta queda fuera del ámbito de la ejecución y la llamada se rechaza y se registra.
- Un agente de finanzas prepara un pago y una persona lo aprueba antes de ejecutarlo, con la traza de la ejecución adjunta a la aprobación.
- Una clase de agente que se comporta mal se detiene con el interruptor de parada mientras el resto de la flota sigue funcionando.
- Un incidente se reconstruye desde un único identificador de correlación que abarca tres modelos, nueve llamadas a herramienta y dos reintentos.
FAQs
- ¿Por qué un sistema inmunitario y no un cortafuegos?
- Un cortafuegos supone una frontera entre dentro y fuera. Una empresa que opera agentes no tiene esa frontera: el agente ya está dentro, actuando con credenciales reales. Un sistema inmunitario da por normal la intrusión e invierte en reconocimiento, contención y reparación en vez de en un perímetro.
- ¿No es mínimo privilegio con pasos de más?
- El mínimo privilegio es una de las cinco capas y la más conocida. Lo que sostiene la arquitectura es que por sí sola no basta: sin identidad por ejecución no puedes limitar el privilegio a un sujeto, y sin contención ni recuperación una ejecución bien acotada que aun así sale mal no tiene ni límite ni marcha atrás.
- ¿Esto detiene la inyección de prompt?
- No, y tratar cualquier control como si la detuviera es justo el error. Lo que hace es abaratar sobrevivirla: convencer al modelo de intentar una acción no es lo mismo que esa acción esté autorizada, y el intento rechazado es en sí mismo una señal.
- ¿Cuál es la versión mínima viable?
- Identidad por ejecución y acceso a herramientas limitado a la tarea. Esas dos dan atribución y un límite. La contención, la puerta y las acciones compensatorias pesan más cuanto más irreversibles se vuelven las acciones.
- ¿Qué relación tiene con los marcos de gobernanza?
- Es su expresión en tiempo de ejecución. NIST AI RMF e ISO 42001 piden responsabilidad y trazabilidad; OWASP LLM Top 10 y MITRE ATLAS describen los ataques. Esta arquitectura es donde esas obligaciones se convierten en identidades, ámbitos, entornos aislados y trazas.