Hay una pregunta que hacemos en cada diagnóstico y que casi nunca tiene buena respuesta: con qué identidad actúa el agente cuando llama a una herramienta.
Las respuestas se reparten entre tres. Con el token OAuth de la persona que lo configuró, que sigue funcionando aunque esa persona ya no esté en el proyecto. Con una cuenta de servicio creada para "la integración", que tiene permisos de administrador porque así no fallaba nada durante las pruebas. O con la clave de API de la plataforma, compartida con otros tres agentes.
Las tres significan lo mismo: el agente puede hacer mucho más de lo que su tarea necesita, y cuando alguien le inyecte una instrucción a través de un correo o de un documento, el daño lo pondrá el permiso, no el modelo.
Por qué el modelo no es el control
El mínimo privilegio es el principio más antiguo de la seguridad y el que peor viaja a los agentes. La razón es que la conversación sobre agentes se centra en el modelo: qué tan bien sigue instrucciones, qué tan resistente es a la inyección, qué guardarraíles lleva.
Nada de eso es un control. El modelo decide qué herramienta invocar leyendo texto, y parte de ese texto lo escribe alguien que no eres tú. La inyección indirecta no es un fallo que se arregle en la próxima versión: es la consecuencia de que el mismo canal lleve datos e instrucciones. El OWASP Top 10 para aplicaciones agénticas la recoge en el mal uso de herramientas y en el abuso de identidad y privilegios, y las dos aparecen en su lista por la misma razón: el permiso es lo que convierte una instrucción maliciosa en una acción.
Por eso el control tiene que estar en lo que el agente puede hacer, no en lo que decide hacer. Si el agente de soporte no tiene permiso para borrar contactos, da igual cuánto lo convenzan.
Seis reglas
Estas son las reglas que aplicamos. No requieren un producto. Requieren tomarse en serio que un agente es un principal más en el sistema de identidad.
1. Identidad propia por agente
Cada agente tiene su propia identidad en el proveedor de identidad, con su nombre, su responsable y sus credenciales. No la de una persona, no una compartida. Es lo que permite atribuir cada acción, revocar sin romper a los demás y auditar por agente. Si tu plataforma no permite crear identidades para cargas de trabajo, ese es el primer problema que resolver.
2. Una lista blanca de herramientas, no una lista negra
El agente ve solo las herramientas que su tarea necesita. Todo lo demás no existe para él. Un agente de triaje de tickets necesita leer tickets, leer la base de conocimiento y escribir un comentario. No necesita cerrar tickets, no necesita enviar correos, no necesita el conector de facturación aunque esté disponible en la plataforma.
La comprobación es sencilla: la lista de herramientas en la configuración del agente frente a la lista de acciones que hace en un día normal. Si la primera es más larga, hay permisos que sobran.
3. Lectura y escritura son permisos distintos
Casi todos los conectores agrupan permisos por sistema: acceso al CRM, acceso al correo. El agente que solo necesita leer el CRM acaba con permiso para escribirlo. Cuando el conector lo permite, se separan los ámbitos. Cuando no, se pone una capa intermedia que exponga solo la operación de lectura. Es la regla que más reduce el radio de una inyección, porque la mayoría de los agentes en producción solo necesitan escribir en uno o dos sitios.
4. Restricciones a nivel de argumento
Permitir "enviar correo" no es suficiente. La pregunta es a quién. Un agente que envía correos a clientes de la empresa no debería poder enviar a un dominio externo arbitrario, y el que consulta una base de datos no debería poder ejecutar una sentencia que borre. La política tiene que mirar los argumentos de la llamada, y en particular de dónde vienen: si el destinatario del correo apareció en un documento recuperado por el RAG y no en la petición del usuario, es una señal de que alguien lo ha puesto ahí.
Es exactamente lo que el Agent Control Standard modela cuando exige que cada argumento viaje con su procedencia, y lo que un motor de políticas como Cedar permite expresar en pocas líneas:
permit (
principal == Agent::"soporte-triaje",
action == Action::"email.send",
resource
) when {
resource.to_domain in ["empresa.com", "clientes-empresa.com"] &&
resource.to_provenance == "user_request"
};
5. Lo irreversible espera a una persona
Pagos, borrados, envíos fuera de la empresa, cambios de permisos, despliegues. Para esas acciones la política no devuelve un sí o un no, devuelve un espera: la llamada queda retenida, con la regla que la ha gatillado a la vista, y no avanza hasta que alguien la apruebe. La persona no supervisa cada acción del agente, supervisa la docena al día que no tienen vuelta atrás. Es la forma práctica de cumplir la supervisión humana que pide el Reglamento sin poner a nadie a mirar una consola ocho horas.
6. Credenciales cortas y salida controlada
Los tokens del agente caducan en horas, no en meses, y se emiten para la tarea. Y el agente solo puede hablar con los destinos que su tarea necesita: si un agente interno acaba haciendo peticiones a un dominio que nadie ha autorizado, es la señal más clara de exfiltración que vas a tener. El control de salida es barato y casi nadie lo aplica a agentes.
La auditoría de una tarde
Con un agente en producción se puede comprobar todo esto en una tarde y sin herramientas nuevas:
- Abre la configuración real del agente y copia la lista de herramientas. No la documentación, la configuración.
- Para cada herramienta, apunta con qué credencial se autentica y a quién pertenece.
- Marca cuáles escriben, borran, envían fuera o mueven dinero.
- Para cada una de esas, comprueba si existe una aprobación humana antes de ejecutarla y quién la recibe.
- Pide el registro de las últimas veinticuatro horas y comprueba que cada acción se puede atribuir al agente, no a una persona.
Lo que salga de ahí es la mitad del área 3 del checklist de control de agentes, y suele ser la mitad con más noes.
Cómo lo hacemos en el lab
En DELIA, que es nuestra capa de detección y respuesta para pipelines de LLM, RAG y agentes, estas reglas se aplican desde fuera del agente y por delante de la acción: cada llamada a herramienta pasa por una política determinista en Cedar que mira la herramienta, los argumentos y su procedencia, y la cola de aprobación retiene las que la política marca como irreversibles hasta que una persona decide. La traza de cada decisión sale al SIEM en OCSF.
Pero el orden importa: las seis reglas van antes que cualquier producto, incluido el nuestro. Un agente con identidad propia, una lista blanca corta y lectura separada de escritura ya ha reducido la mayor parte del riesgo. Lo que queda es lo que merece un control en runtime, y para saber cuánto queda en tu caso, el diagnóstico de control empieza precisamente por aquí.