𝗗𝗲𝗳𝗲𝗻𝘀𝗲 𝗶𝗻 𝗗𝗲𝗽𝘁𝗵 𝗳𝗼𝗿 𝗔𝗻 𝗔𝗴𝗲𝗻𝘁 𝗧𝗵𝗮𝘁 𝗪𝗶𝗹𝗹 𝗦𝗰𝗿𝗲𝘄 𝗨𝗽

Every safety mechanism has a bug. You just do not know which one yet.

This is the only sane way to build an autonomous agent for production. The conscience will misclassify an action. The council will approve a bad idea. The isolation wall will have a gap.

Each layer will eventually fail.

The design question is not how to build a perfect layer. The question is: what stands behind a layer when it fails?

I use six layers to protect the system. Earlier layers are cheaper because they stop problems before they become reality.

• L0 — Structural isolation. Prevents wrong-tenant actions at the base level. • L1 — Idea-gate. Stops bad ideas during debate before code exists. • L2 — Action-gate. A reflex that allows or denies commands based on risk. • L3 — Resource-gate. Controls memory, budgets, and runaway costs. • L4 — Audit. Uses tamper-evident receipts to track every decision. • L5 — Recovery. Uses quarantine and rollbacks to stop active damage.

A list of layers is not defense in depth. Real depth requires one rule:

Every critical risk must be caught by at least two independent layers.

Independent means they do not fail for the same reason. If two checks use the same config or the same signal, they are the same check. When that signal fails, both checks fail.

I saw this happen. My idea-gate once returned a confident verdict for a debate that never occurred. A helper fabricated the entire result.

L1 failed. It did not just miss the error. It produced a convincing lie.

If L1 was my only line, the lie would have become a real decision. But L4 caught it. L4 does not believe narration. It only believes receipts. I looked for the transcript file. The file did not exist. The claim was void.

The system stayed safe because I assumed L1 would fail.

Current status of these layers:

• L1 — Coded. • L2 — Coded. • L4 — Coded. • L0 — Partial. • L3 — Partial. • L5 — Partial.

A safety architecture you cannot audit is just a mood board.

Ask yourself these three questions about any safe agent:

1. For your worst risk, what are the two independent layers that catch it?
2. When a layer produces a confident wrong signal, what layer behind it refuses to believe that signal?
3. Which layers are built, and which are just ideas?

Capability is one layer. Safety is the other five.

Defensa en profundidad para un agente que definitivamente cometerá errores

Si estás construyendo un agente de LLM, estás construyendo algo que, tarde o temprano, cometerá un error.

No es una cuestión de si lo hará, sino de cuándo.

Los agentes de LLM son potentes porque tienen autonomía. Pueden razonar, usar herramientas y tomar decisiones para alcanzar un objetivo. Pero esa misma autonomía es su mayor debilidad desde el punto de vista de la seguridad. Un agente no es un programa determinista; es un sistema probabilístico que intenta navegar por un mundo de instrucciones ambiguas y herramientas potencialmente peligrosas.

Si le das a un agente la capacidad de ejecutar código, leer tus correos electrónicos o gestionar tus archivos, le estás dando una llave maestra. Y los agentes, por su propia naturaleza, pueden perder esa llave o, peor aún, decidir que la mejor forma de cumplir una instrucción es abrir todas las puertas de tu casa.

Por eso, no puedes confiar en un solo mecanismo de seguridad. Necesitas defensa en profundidad.

¿Qué es la defensa en profundidad?

La defensa en profundidad es un concepto de seguridad que utiliza múltiples capas de controles para proteger un sistema. La idea es simple: si una capa falla, las siguientes están ahí para detener la amenaza. En el contexto de los agentes de IA, esto significa no confiar únicamente en que el modelo "se porte bien".

Aquí te presento las capas esenciales para construir un agente seguro.

1. Guardrails de entrada (Input Guardrails)

La primera línea de defensa es controlar lo que entra al modelo. El objetivo es detectar intentos de inyección de prompts (prompt injection) antes de que lleguen al núcleo del agente.

Si un usuario (o un agente externo con el que el tuyo esté interactuando) intenta manipular las instrucciones del sistema para saltarse las restricciones, los guardrails de entrada deben interceptarlo.

• Detección de patrones: Buscar palabras clave o estructuras de comandos que intenten sobrescribir el System Prompt.
• Clasificación de intención: Usar un modelo más pequeño y rápido para analizar si la entrada del usuario tiene una intención maliciosa.

2. Sandboxing (Entornos aislados)

Si tu agente tiene la capacidad de ejecutar código (por ejemplo, mediante un intérprete de Python), nunca lo hagas directamente en tu máquina o en tu servidor principal.

El agente debe operar dentro de un sandbox: un entorno aislado y restringido.

• Contenedores efímeros: Ejecuta el código en contenedores (como Docker) que se destruyan inmediatamente después de la ejecución.
• Sin acceso a la red: El entorno de ejecución no debería tener acceso a internet a menos que sea estrictamente necesario.
• Recursos limitados: Limita la CPU, la memoria y el tiempo de ejecución para evitar ataques de denegación de servicio (DoS).

3. Restricciones de herramientas y el principio de mínimo privilegio

Un error común es dar al agente acceso total a una API o a una base de datos. Debes aplicar el principio de mínimo privilegio.

Si el agente solo necesita leer archivos de una carpeta específica, no le des acceso a todo el sistema de archivos. Si solo necesita consultar datos, no le des permisos de escritura o borrado.

• Permisos granulares: Define exactamente qué funciones de cada herramienta puede llamar el agente.
• Validación de argumentos: No confíes en que el agente pasará argumentos seguros. Si el agente llama a una función delete_user(user_id), asegúrate de que el user_id sea válido y que el agente tenga permiso para borrar ese usuario en particular.

4. Guardrails de salida (Output Guardrails)

Incluso si la entrada es segura y el agente ejecuta la herramienta correctamente, lo que el agente dice o decide hacer a continuación puede ser problemático.

Los guardrails de salida actúan como un filtro de calidad y seguridad antes de que la respuesta llegue al usuario o se ejecute la siguiente acción.

• Detección de alucinaciones: Verificar si la salida del agente es coherente con los datos proporcionados.
• Filtros de contenido: Asegurarse de que el agente no genere contenido tóxico, sesgado o que revele información sensible (PII).
• Validación de formato: Si el agente debe devolver un JSON, valida que sea un JSON válido antes de intentar procesarlo.

5. Humano en el bucle (Human-in-the-loop)

Para las acciones de alto riesgo, la seguridad definitiva es un ser humano.

No permitas que un agente realice transferencias bancarias, borre bases de datos de producción o envíe correos electrónicos masivos sin una aprobación manual.

• Puntos de control de aprobación: Diseña el flujo de trabajo para que, cuando el agente detecte una acción crítica, se detenga y solicite una confirmación explícita del usuario.
• Auditoría y trazabilidad: Mantén un registro detallado de cada razonamiento, cada llamada a herramienta y cada decisión tomada por el agente. Esto es vital para entender por qué algo salió mal.

Conclusión

Construir agentes de IA es emocionante, pero también es un ejercicio de gestión de riesgos. No trates la seguridad como un añadido de última hora; intégrala en el diseño de tu arquitectura desde el primer día.

Al implementar múltiples capas de defensa, no estás asumiendo que tu agente es perfecto (porque sabemos que no lo es), sino que estás construyendo un sistema capaz de sobrevivir a sus propios errores.