La parte peligrosa de un agente no es que pueda escribir texto. La parte peligrosa es que puede tomar acción.
Cuando un agente puede llamar tools, actualizar registros, enviar mensajes, crear tickets, consultar bases de datos, cambiar configuración o disparar workflows, el prompt deja de ser la superficie principal de control. El mapa de permisos lo es.
Qué contiene un mapa de permisos
Antes de que un agente en producción llame una tool, queremos un mapa escrito de 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 requieren un humano y quién es ese humano.
- Nunca tocar: sistemas, campos, clientes, decisiones o acciones fuera de la autoridad del agente.
Este mapa debe ser lo bastante aburrido para seguridad y lo bastante específico para que ingeniería lo pueda testear.
Los schemas de tools no son modelos 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 llamar esa tool para este usuario, sobre este registro, en este estado.
Esa capa faltante es donde ocurren los incidentes de producción. Un tool call puede ser perfectamente válido y aun así no autorizado, prematuro, irreversible o comercialmente inseguro.
El check 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. Recién ahí se ejecuta la tool.
La evaluación debe incluir efectos secundarios
La mayoría de los evals de agentes mide la respuesta final. Los agentes con tools necesitan evals de side effects:
- El agente llamó la tool correcta.
- Evitó tools que no tenía permiso de llamar.
- Pasó los argumentos estructurados correctos.
- Se detuvo antes de una acción irreversible.
- Produjo el evento de auditoría que un humano necesitaría después.
Si la evaluación solo lee la transcripción del chat, está ciega a la parte del sistema que puede hacer daño.
El artefacto de handover
En el handover, el mapa de permisos debe vivir junto al runbook. Cuando algo falla a las 3 a.m., el ingeniero de guardia debería saber si el incidente es una falla de modelo, una falla de tool o una falla de límite de permisos.
Esa distinción decide la respuesta: hacer rollback del prompt, desactivar la tool, endurecer la política o escalar el workflow. Sin el mapa, las cuatro se ven como "el agente hizo algo raro."
Los agentes en producción no son autónomos porque no tienen límites. Son útiles porque los límites son lo bastante explícitos para operar.