Lo peligroso de un agente no es que escriba texto. Lo peligroso es que actúa.
En cuanto un agente puede llamar a tools —las funciones que ejecuta contra tus sistemas—, actualizar registros, mandar mensajes, crear tickets, consultar bases de datos, cambiar configuración o disparar workflows, el prompt deja de ser la superficie de control principal. Pasa a serlo el mapa de permisos.
Qué contiene un mapa de permisos
Antes de que un agente en producción llame a una tool, queremos por escrito cinco límites:
- Leer: qué datos puede inspeccionar, bajo qué identidad de usuario y con qué filtros.
- Escribir: qué registros puede redactar, preparar o proponer.
- Mutar: qué puede cambiar sin aprobación.
- Escalar: qué acciones exigen un humano, y quién es ese humano.
- Nunca tocar: sistemas, campos, clientes, decisiones o acciones fuera de su autoridad.
El mapa tiene que ser lo bastante aburrido para seguridad y lo bastante concreto para que ingeniería pueda escribirle tests. Es parte de decidir si el agente puede ir a producción.
El schema de una tool no es un modelo de permisos
Un schema JSON le dice al modelo qué argumentos acepta una tool. No le dice a la organización si el modelo tiene permiso de llamarla para este usuario, sobre este registro y en este estado.
En esa capa que falta es donde ocurren los incidentes. Una tool call puede ser perfectamente válida y aun así no estar autorizada, llegar antes de tiempo, ser irreversible o resultar comercialmente peligrosa. Es la misma capa que contiene un ataque de inyección de prompts, donde la petición está bien formada pero la autoridad que la respalda es robada.
La comprobación de permisos vive fuera del modelo. El modelo propone una acción. El sistema revisa identidad, rol, estado del objeto, estado del workflow, clase de riesgo y requisito de aprobación. Solo entonces se ejecuta la tool.
El eval tiene que incluir los efectos secundarios
Casi todos los evals de agentes miden la respuesta final e ignoran las tool calls. Un agente con tools necesita evals de efectos secundarios:
- Llamó a la tool correcta.
- Evitó las tools que no tenía permiso de llamar.
- Pasó los argumentos estructurados correctos.
- Se detuvo antes de una acción irreversible.
- Dejó el evento de auditoría que un humano va a necesitar después.
Si el eval solo lee la transcripción del chat, está ciego justo ante la parte del sistema que puede hacer daño.
El artefacto de handover
En el handover, el mapa de permisos va junto al runbook. Cuando algo falle bajo carga, el ingeniero de guardia tiene que poder distinguir si el incidente es un fallo del modelo, un fallo de la tool o un fallo del límite de permisos.
Esa distinción decide la respuesta: rollback del prompt, desactivar la tool, endurecer la política o escalar el workflow. Sin el mapa, las cuatro se ven igual: «el agente hizo algo raro».
Un agente en producción no es útil por carecer de límites. Es útil porque sus límites son lo bastante explícitos como para poder operarlo.