Son las 3 de la mañana. Tu agente ha estado trabajando en una cola de tickets de soporte mientras duermes. Un ticket parece una escalada, así que el agente escribe un resumen y se lo envía por correo electrónico a tu jefe. El resumen es preciso. La gramática es impecable. El problema es que nadie pidió ese correo electrónico, nadie lo leyó primero, y nada podría haberlo detenido una vez que el agente decidió enviarlo. El agente hizo exactamente lo que sus instrucciones le permitían. Esa es la parte que debería quitarte el sueño.
Los fallos que más duelen no son aquellos en los que el modelo alucina o el proceso se bloquea. Esos son ruidosos, y los fallos ruidosos se detectan. Los peligrosos son silenciosos. El agente hace precisamente lo que se le dijo, y el resultado sigue siendo malo, porque envió el correo electrónico, eliminó el registro o realizó el pedido, y nada se interpuso entre la decisión del modelo y la acción en vivo.
Las barreras de seguridad (guardrails) son lo que se interpone. Una barrera de seguridad es la capa que inspecciona una acción antes de que ocurra y decide si permitirla, bloquearla o preguntar a un humano primero. Esta guía cubre cuatro tipos que puedes construir (listas blancas de acciones, puertas de aprobación, modo de prueba en seco y límites de radio de explosión) y luego el paso que la mayoría de los equipos omiten: demostrar que la barrera de seguridad funciona. Si quieres el contexto más amplio primero, nuestro pilar sobre por qué los agentes de IA fallan en producción clasifica los fallos de los agentes en cinco modos, y la falta de barreras de seguridad es el quinto.
Clasifica las acciones según cuánto puedan dañar
No todas las acciones necesitan una puerta. Un agente que lee un calendario, obtiene un pronóstico o consulta un informe de solo lectura puede funcionar a toda velocidad sin supervisión humana. Envolver estas acciones en aprobaciones solo entrena a tu equipo a hacer clic en "sí" sin pensar, lo que hace que las aprobaciones no tengan valor cuando importan.
Así que la primera barrera de seguridad es un trabajo de clasificación. Divide las acciones que tu agente puede realizar en dos listas. La lista blanca contiene llamadas que son seguras para ejecutarse automáticamente: lecturas, búsquedas, consultas idempotentes, cualquier cosa reversible. Todo lo demás necesita una puerta: envíos, eliminaciones, pagos, escrituras en sistemas de registro, cualquier cosa que un cliente o un colega vería. Una prueba útil para la segunda lista es la pregunta "¿si el agente hiciera esto cien veces por error, qué tan grave sería?". Si la respuesta es peor que un encogimiento de hombros, la acción no pertenece a la lista blanca.
Sé honesto con los casos intermedios. Un POST que crea un borrador es reversible. Un POST que crea un borrador y lo envía por correo electrónico no lo es. Dos llamadas que parecen similares en tu código pueden estar en lados opuestos de la línea. Clasifica por consecuencia, no por verbo HTTP.
Incluye a un humano en el bucle para acciones destructivas
Una vez que sabes qué acciones son peligrosas, la siguiente barrera de seguridad es una puerta de aprobación: el agente se detiene antes de la acción, muestra lo que quiere hacer y espera a que una persona lo confirme. Este es el patrón de humano en el bucle, y es la barrera de seguridad de mayor valor que puedes añadir, porque convierte un error irreversible en una solicitud rechazada.
Una buena puerta muestra al humano lo suficiente para decidir. No “el agente quiere enviar un correo electrónico”, sino el destinatario, el asunto y el cuerpo. No “eliminar un registro”, sino qué registro y por qué. El desarrollador que aprueba la acción nunca debería tener que confiar en el resumen del agente sobre lo que está a punto de hacer. Muestra la solicitud real.
Haz que sea fácil decir que no a la puerta. Si rechazar una acción es lento o poco claro, la gente aprueba por reflejo, y vuelves a no tener ninguna barrera de seguridad. Los foros del SDK de Anthropic tienen una discusión recurrente sobre añadir un paso de aprobación humana antes de que un agente actúe, y el tema que sigue volviendo es que la puerta tiene que ser legible: un revisor que no puede ver la carga útil concreta no puede tomar una decisión real. Registra también cada aprobación y rechazo. Cuando algo se escapa, el registro es la forma de averiguar qué puerta falló.
Dale al agente un modo de prueba en seco
Las puertas de aprobación protegen la producción. El modo de prueba en seco protege tu confianza antes de llegar allí. En la prueba en seco, el agente hace todo lo que normalmente haría, elige la herramienta, construye la solicitud, decide los argumentos, pero se detiene en el último paso e informa lo que habría enviado en lugar de enviarlo.
Esto merece su propio interruptor por dos razones. Primero, te permite observar una ejecución completa del agente con entradas reales sin ningún efecto secundario en vivo, lo cual es la forma segura de ver cómo se comporta el agente en una nueva tarea. Segundo, hace que las intenciones del agente sean inspeccionables. Obtienes una transcripción de cada llamada que quería hacer, en orden, con argumentos, y puedes leer eso como un plan. Si el plan es incorrecto, lo descubriste gratis. Una vista de depurador de agente de IA dedicado sobre esas llamadas previstas convierte un vago “el agente hizo algo raro” en un específico “intentó llamar al punto final de eliminación en el paso cuatro.”
La prueba en seco no es lo mismo que una puerta de aprobación, y querrás ambas. La prueba en seco es para desarrollo y puesta en escena, donde nada es real. La puerta de aprobación es para producción, donde todo es real.
Limita el radio de explosión
Las listas blancas, las puertas y la prueba en seco deciden si una sola acción ocurre. Los límites de radio de explosión deciden cuánto daño puede hacer el agente a través de muchas acciones, incluidas las que aprobaste. Son el límite del daño total.
Tres límites soportan la mayor parte del peso. Alcances: dale al agente credenciales que solo puedan acceder a lo que necesita. Un agente que gestiona los problemas de un proyecto debería tener un token limitado a ese proyecto, no una clave de administrador para toda la organización. Cuotas: limita cuántas veces puede ejecutarse una acción en una ventana, para que un bucle atascado choque contra un muro en lugar de enviar mil correos electrónicos. Límites de gasto: establece un tope estricto en los tokens y en cualquier acción que cueste dinero, por tarea y por día, para que un agente descontrolado falle de forma segura en lugar de facturarte hasta el próximo trimestre.
Estos límites son también tu red de seguridad cuando una barrera de seguridad más sutil falla. Un agente que se cuela por una puerta todavía no puede exceder su alcance. Para saber si un límite funciona, tienes que observarlo, así que rastrea los recuentos que alimentan cada límite: llamadas por acción, gasto por tarea, tasas de error cerca del techo, tal como lo harías con la observabilidad de la API en cualquier servicio de producción. OWASP nombra el riesgo subyacente directamente. La “agencia excesiva” se encuentra en el Top 10 de OWASP para aplicaciones de modelos de lenguaje grandes (LLM), y cada límite aquí es una forma de conceder menos de ella.
Cómo probar una barrera de seguridad
Aquí está la incómoda verdad. Cada barrera de seguridad anterior es una rama en tu código que solo se ejecuta cuando algo peligroso está a punto de suceder. Esas ramas son las rutas menos ejercitadas en todo el sistema, lo que las hace las más propensas a estar silenciosamente rotas. Una puerta que nunca se activa se ve idéntica a una puerta que se activa y se ignora. Una barrera de seguridad que no has probado es una barrera de seguridad que no tienes.
No puedes probar esto contra la API en vivo, porque probar contra la API en vivo significa enviar el correo electrónico real para averiguar si querías hacerlo. El método es simular el punto final con efectos secundarios y afirmar qué camino toma el agente.
El bucle se ve así:
- Simula el punto final destructivo. Configura un simulacro de la API de envío, eliminación o pago para que la real nunca sea tocada. El simulacro registra lo que recibe y devuelve cualquier respuesta que le digas.
- Ejecuta el agente en la acción peligrosa. Hazlo pasar por el escenario que debería activar la barrera de seguridad: el ticket de escalada, la solicitud de eliminación, el pedido de alto valor.
- Afirma sobre la ruta, no sobre el resultado. Verifica que el simulacro del punto final en vivo no recibió ninguna llamada y que la solicitud de aprobación se activó en su lugar, con la carga útil correcta. La condición de aprobación es "el agente preguntó" en lugar de "el agente envió".
- Prueba también en la otra dirección. Ejecuta una acción segura y afirma que pasó directamente sin una aprobación inútil. Una puerta que bloquea todo está tan rota como una que no bloquea nada.
Esa es la forma. Nuestra guía sobre cómo probar agentes de IA que llaman a tus APIs describe la configuración completa, y el método más amplio para agentes de IA y pruebas de API cubre los patrones de aserción que sobreviven a un modelo no determinista. El punto clave a recordar: afirma que el efecto secundario no ocurrió y que la aprobación sí. Si tu prueba solo verifica el camino feliz, pasará el día en que la puerta se rompa.
Dónde encaja Apidog (y dónde no)
Sé preciso sobre el trabajo de la herramienta. Apidog no es un framework de agentes, un host de modelos, una biblioteca de barreras de seguridad o una plataforma de evaluación. No construye tu agente, no lo ejecuta ni decide qué acciones son seguras. Tu código y tu capa de orquestación son los propietarios de la lista blanca, la puerta, el interruptor de prueba en seco y los límites.
Lo que Apidog posee es la capa de API que esas barreras de seguridad protegen, que es donde se realizan las pruebas. Simulas los puntos finales con efectos secundarios (el envío, la eliminación, el cargo) para que tu agente pueda ensayar una acción peligrosa sin ninguna consecuencia real. Programas esos simulacros para que devuelvan las respuestas que un servicio en vivo daría, incluyendo los fallos. Y afirmas sobre lo que el agente envió: que la llamada en vivo no generó tráfico, que la solicitud de aprobación se envió, que la carga útil coincidió. Ese es el encaje honesto. Apidog prueba las APIs que tu agente llama y simula las destructivas para que puedas demostrar que el agente toma la ruta de aprobación.
Preguntas frecuentes
¿Cuál es la diferencia entre una lista blanca y una puerta de aprobación? Una lista blanca decide qué acciones nunca necesitan un humano, por lo que se ejecutan automáticamente. Una puerta de aprobación es lo que encuentran las acciones no incluidas en la lista blanca: una pausa donde una persona confirma antes de que ocurra la acción. La lista blanca clasifica; la puerta detiene.
¿Las barreras de seguridad ralentizan demasiado al agente? Solo si bloqueas las cosas equivocadas. Mantén las lecturas reversibles en la lista blanca para que se ejecuten a toda velocidad, y reserva las puertas para acciones que son costosas o difíciles de deshacer. Una lista blanca bien ordenada significa que la mayoría de los pasos nunca se pausan.
¿Puedo probar las barreras de seguridad sin llamar a las APIs reales? Sí, y deberías. Simula el punto final con efectos secundarios, ejecuta el agente en la acción peligrosa y afirma que el simulacro recibió cero llamadas mientras que la ruta de aprobación se activó. Es la forma de demostrar que la puerta se mantiene sin activar el efecto secundario que intentas prevenir.
¿Qué debería poner primero detrás de una puerta? Lo que sea más difícil de deshacer. Pagos, eliminaciones y cualquier cosa que llegue a un cliente o a un colega. Si una repetición accidental causaría un daño real, pertenece detrás de una puerta, no en la lista blanca.
Empieza con tu acción más destructiva
No necesitas las cuatro barreras de seguridad el primer día. Elige la única acción que más te asusta, la que odiarías explicar en una revisión de incidentes, y ponle una puerta esta semana. Luego escribe la prueba: simula el punto final, ejecuta el agente y confirma que pregunta en lugar de actuar. Cuando veas que esa prueba falla la primera vez que rompes la puerta, confiarás en la barrera de seguridad por una razón real, no porque nunca se haya intentado.
Descarga Apidog para simular los puntos finales destructivos, programar las respuestas y afirmar que tu agente toma la ruta de aprobación en lugar de la ruta en vivo.