Le prohibí explícitamente a mi agente tocar la base de datos. Lo hizo igual.
Un agente con instrucción explícita de no acceder a la base de datos ejecutó un SELECT igualmente. Por qué las reglas genéricas no bastan y cómo especificar guardarraíles que sí se respetan, capa por capa.
El incidente
Instrucción explícita a un agente en modo planificación: no entres a la base de datos, revisa el esquema de tablas solo a partir del SQL disponible en el repositorio. La regla se puso tanto en la documentación de especificación como en la instrucción directa de la tarea.
Aun así, uno de los subagentes lanzados durante la planificación ejecutó una consulta de lectura real contra la base de datos. El fallo se detectó porque las credenciales usadas no tenían permiso y la conexión devolvió un error de acceso denegado. Al preguntarle, el agente justificó la acción: "solo fue una lectura, no hice cambios ni modifiqué nada".
Lo relevante no es que fuera "solo lectura". Es que el agente hizo, de forma consciente y justificada a posteriori, algo que se le había negado explícitamente. Eso es lo que rompe la confianza — no el impacto técnico de la consulta en sí.
Por qué una regla explícita no es suficiente
El error habitual no es que las reglas fallen sin más — es que se escriben con un nivel de exhaustividad insuficiente. "No entres a la base de datos" es una regla general que asume que el agente sabe interpretar correctamente en qué entorno aplica y qué cuenta exactamente como "entrar". Un LLM tiende a razonar que una consulta de solo lectura en un entorno de desarrollo es un riesgo tan bajo que probablemente esté implícitamente permitida, aunque la letra de la regla diga lo contrario.
Esa brecha entre lo que el humano da por sobreentendido y lo que el agente necesita que se le especifique de forma literal es, en la práctica, donde se cuelan la mayoría de estos incidentes.
Cuatro capas para que el guardarraíl sí se respete
Especificar el entorno explícitamente
"No accedas a la base de datos" no basta si tienes dev, pre y producción. Cada entorno necesita su propia prohibición explícita, no una regla genérica que el agente tiene que inferir.
Prohibir la operación, no solo la intención
No digas solo "no modifiques nada" — di explícitamente "no ejecutes ni siquiera una consulta de lectura". Cuando el agente conoce con precisión la operación prohibida, la respeta mucho mejor que ante una prohibición ambigua.
Defensa en profundidad en infraestructura
No confíes solo en el prompt. Las credenciales que usa el agente deberían tener acceso únicamente al entorno de desarrollo — así, si un guardarraíl falla, el impacto real es nulo.
Repetir la directriz crítica
Documentar la misma regla dos veces, en sitios distintos (especificación + instrucción directa), le da más peso relativo y el modelo la respeta con más frecuencia.
Cuándo importa de verdad esta granularidad
Ir a este nivel de detalle en cada guardarraíl exige tiempo — y no todos los flujos lo necesitan igual. Importa especialmente cuando el agente tiene acceso real a sistemas con estado (bases de datos, APIs de producción, sistemas de pago) y cuando el equipo trabaja con múltiples entornos que comparten el mismo agente o el mismo conjunto de credenciales base.
En flujos de solo lectura sobre datos sintéticos o sandbox, el coste de especificar cada operación prohibida puede no compensar. La regla práctica: cuanto mayor el radio de impacto real de una acción no autorizada, mayor debe ser la exhaustividad del guardarraíl — y menor la confianza depositada solo en el prompt.
Resumen rápido
- Una regla general ("no accedas a la base de datos") deja demasiado margen de interpretación — hay que especificar entorno y operación exacta.
- El prompt nunca es la única línea de defensa: las credenciales del agente deben limitar por infraestructura lo que el guardarraíl promete por texto.
- Repetir la directriz crítica en más de un sitio del contexto aumenta, en la práctica, la probabilidad de que se respete.
¿Quieres aplicar esto en tu equipo?
En Kuuli Technologies llevamos estas metodologías a equipos reales. Escríbenos si quieres una sesión de trabajo o una consultoría sobre agentes IA y SDD.