El error del día 0: darle al agente la cuenta de Marta
Casi todos los agentes que hemos visto entrar en producción empezaron igual: alguien necesitaba que la cosa leyera el correo y escribiera en el CRM, y la vía rápida era usar las credenciales de la persona que ya tenía acceso. Marta, de operaciones. Funciona el primer día. El problema aparece el segundo, y no es técnico: es que a partir de ese momento nadie de la empresa puede contestar dos preguntas elementales. Quién hizo este cambio, Marta o el agente. Y qué puede tocar exactamente esta cosa.
La respuesta a la segunda es siempre la misma y siempre incómoda: todo lo que puede tocar Marta. Diez años de antigüedad, tres cambios de departamento y los permisos acumulados de cada uno. El agente no heredó una tarea; heredó una carrera profesional entera. Y a diferencia de Marta, no tiene criterio para saber que la carpeta de nóminas no se abre aunque algo en el contexto se lo pida con mucha educación.
OWASP le puso nombre a esto en diciembre de 2025, cuando publicó su Top 10 para aplicaciones agénticas. La categoría ASI03 se llama Identity & Privilege Abuse, y la describe exactamente así: credenciales heredadas o filtradas que dejan al agente operar muy por encima de su alcance previsto. No es una hipótesis de laboratorio — la lista se construyó sobre incidentes reales de la primera generación de adoptantes.
La matriz de cuatro columnas que se rellena antes de conectar nada
El diseño de permisos de un agente cabe en una tabla que se rellena en una reunión de cuarenta minutos, y que hay que rellenar antes de crear la primera credencial. No después, porque después ya hay algo funcionando y nadie quiere ser quien lo rompa. Cuatro columnas de permiso, un sistema por fila.
| Sistema | Qué LEE | Qué ESCRIBE | Qué EJECUTA | Qué no toca jamás |
|---|---|---|---|---|
| CRM | Oportunidades abiertas de su cartera | Notas y siguiente paso | Nada | Importe, etapa de cierre, borrado de registros |
| Correo | Bandeja de un alias propio | Borradores en carpeta de revisión | Nada | Enviar sin revisión, reenviar fuera del dominio |
| ERP / facturación | Estado de pedidos | Nada | Nada | Todo lo demás |
| Almacenamiento | Carpeta del proyecto | Subcarpeta de salidas | Nada | Nóminas, legal, carpetas de dirección |
La columna que más discute todo el mundo es la tercera, ejecutar, y es la que más importa. Leer es reversible. Escribir suele serlo con un histórico decente. Ejecutar —lanzar un pago, mandar un correo a un cliente, cerrar un ticket, borrar— casi nunca lo es. La regla práctica: una acción entra en la columna de ejecutar solo si alguien puede describir en una frase cómo se deshace. Si la frase no existe, la acción se queda en «propone y espera».
Y la cuarta columna, la de lo que no toca jamás, no es decorativa. Es la única que se escribe en positivo desde el principio y sobrevive a los cambios de alcance: dentro de seis meses, cuando alguien quiera «ampliarle un poco los permisos para que también haga esto», esa columna es lo que obliga a tener la conversación en vez de despacharla con un clic en la consola.
Identidad propia: el agente no es un plugin de alguien
Una credencial de servicio no es burocracia de seguridad. Es lo que hace que las tres cosas siguientes sean posibles, y sin ella ninguna lo es.
- Auditoría. El log dice «agente-ventas-01» y no «marta.g». Cuando algo sale raro, la investigación dura diez minutos en vez de una tarde de preguntar a la gente si fue ella.
- Revocación limpia. Se corta el acceso del agente sin dejar a una persona sin trabajar, y se deja sin trabajar a una persona sin cortar el agente. Suena obvio hasta que compartes credencial y descubres que no puedes hacer ni una cosa ni la otra.
- Alcance real. Solo puedes darle menos permisos que a un humano si tiene una cuenta distinta de la del humano. Con credencial compartida, «mínimo privilegio» es una intención, no una configuración.
La objeción habitual es el coste: en muchas herramientas SaaS una cuenta más son treinta o cincuenta euros al mes. Es una objeción legítima y tiene respuesta buena en casi todas: cuentas de servicio, de integración o de API que no se facturan como asiento de usuario. La respuesta mala —la que se toma por defecto cuando nadie pregunta— es compartir la cuenta de Marta para ahorrar cuarenta euros y quedarse sin auditoría, sin revocación y sin alcance. Cuando conectas un agente a un CRM concreto la conversación se vuelve muy específica: cómo conectar un agente IA con tu CRM baja al detalle de objetos, campos y sincronización.
Alcance por tarea, no por persona
El modelo mental que traemos de IAM es el rol: «comercial», «soporte», «administración». Funciona con humanos porque un humano hace muchas cosas y su criterio rellena los huecos. Con un agente el rol es demasiado grande, porque el agente hace una cosa y no tiene criterio para rellenar nada.
Así que el permiso se recorta a la tarea. No «acceso a soporte», sino «leer los tickets abiertos de la cola de facturación y escribir una respuesta en borrador». Todo lo que sobra de esa frase, sobra de la credencial. Es más trabajo de configuración inicial, y a cambio la pregunta «¿qué puede hacer esto?» tiene respuesta escrita en vez de una investigación.
Hay un efecto secundario que compensa el trabajo: cuando el alcance es una tarea y no un rol, ampliar el agente obliga a un cambio explícito de permisos, y ese cambio deja rastro. El agente que crece sin que nadie lo note es el que empezó con un rol amplio. Y cuando ya tienes varios agentes creciendo por su cuenta, el problema deja de ser de diseño y pasa a ser de rescate: eso se trata en poner freno a los agentes IA descontrolados.
Contra la inyección de prompts, el permiso que no diste
La inyección de prompts es la vía por la que un contenido que el agente lee —una página, un correo, un documento, un ticket— le cuela instrucciones que no vienen de ti. Y el estado del arte, dicho por quien construye los modelos, es que no está resuelta. Anthropic publicó en noviembre de 2025 sus resultados de robustez en navegación con Claude Opus 4.5 y los acompañó de una frase que conviene leer despacio: una tasa de éxito del 1 % frente a un atacante adaptativo sigue siendo riesgo real, ningún agente de navegador es inmune, y los datos se publican para demostrar progreso, no para dar el problema por cerrado.
De ahí sale la única conclusión práctica que aguanta: no puedes evitar que manipulen al agente; puedes decidir qué es capaz de hacer un agente manipulado. La defensa no vive en el prompt del sistema, que es exactamente lo que el atacante está peleando. Vive en la credencial, que el atacante no puede tocar desde el contenido.
Traducido a la matriz de arriba: cada permiso de la columna «ejecuta» es una capacidad que un atacante hereda si consigue colar una instrucción. Un agente que solo lee y propone, inyectado, produce una propuesta rara que alguien descarta. El mismo agente con permiso de envío produce un correo que ya salió. La diferencia no la marcó el modelo. La marcó una casilla que alguien decidió no marcar.
El botón de revocación que hay que probar ANTES de arrancar
Todo el mundo asume que puede cortar el acceso de su agente. Muy poca gente lo ha comprobado. Y el momento de comprobarlo no es cuando el agente está haciendo algo raro un viernes por la tarde: es antes de la primera ejecución real, en frío, con tiempo y sin nervios.
La prueba es corta. Se ejecuta una tarea normal, se revoca la credencial mientras corre, y se miran tres cosas: cuánto tarda de verdad en dejar de tener efecto —los tokens en curso y las sesiones abiertas no siempre mueren con el botón—, en qué estado se queda el trabajo a medias, y si alguien se entera de que ha pasado. Luego se vuelve a conceder y se comprueba que arranca. Media hora.
- Quién puede pulsarlo. Al menos dos personas, y una de ellas no puede ser quien construyó el agente. Si el botón depende de una sola persona, no hay botón: hay una llamada de teléfono.
- Dónde está. Escrito, con el enlace exacto a la consola y el nombre exacto de la credencial. Buscarlo en caliente es la mitad del tiempo de reacción.
- Qué pasa después. Con qué se sustituye el trabajo del agente mientras está cortado. Si la respuesta es «nada», el corte tiene un coste que alguien va a dudar en pagar, y esa duda es lo que alarga los incidentes.
Este mismo aparato —quién responde, dónde está escrito, con qué se sustituye— es el que sostiene cualquier automatización en producción, no solo los agentes; está desarrollado en quién responde cuando se cae una automatización. Y si lo que quieres es el mapa completo de riesgos antes de decidir nada, el catálogo está en los riesgos de los agentes IA que no se ven en la demo.
Qué haces esta semana
- Rellena la matriz de cuatro columnas para el agente que tengas más cerca de producción. Un sistema por fila. Cuarenta minutos con quien conoce el proceso, no con quien conoce la herramienta.
- Crea la credencial propia del agente antes de conectarlo a nada. Si tu herramienta cobra por asiento, pregunta por cuenta de servicio o de API antes de resignarte a compartir.
- Recorta el alcance de rol a tarea: lee la descripción del agente en voz alta y quita de la credencial todo lo que no aparezca en esa frase.
- Aplica el test de la casilla a cada permiso de escritura y de ejecución. Lo que te incomode, baja a «propone y un humano confirma».
- Prueba la revocación en frío, con dos personas que sepan pulsarla, y deja escrito dónde está el botón y con qué se sustituye el trabajo.
Ninguno de los cinco pasos requiere elegir plataforma, modelo ni proveedor. Se hacen antes, y se hacen una vez. Lo que decides aquí es lo que va a limitar el daño de todo lo que venga después — y lo que va a permitirte decir que sí, más adelante, a cosas que ahora te darían vértigo. Porque los permisos definen lo que el agente puede tocar; cuánta libertad tiene para usarlos es la decisión siguiente, y esa no se concede de golpe: se sube por los cinco peldaños de autonomía con la evidencia en la mano — casos vistos, tasa de corrección humana y reversibilidad de la acción.
Nosotros montamos la parte que nadie quiere montar: identidades de servicio, alcances por tarea, revocación probada y el registro de quién hizo qué. Es la infraestructura de IA empresarial sobre la que luego se apoya cualquier agente que trabaje de verdad. No vendemos el permiso. Cobramos por que el permiso sea el correcto.