Tus agentes tienen logins que nadie posee

Toda conversación de seguridad sobre agentes se obsesiona con los ataques emocionantes — prompt injection, envenenamiento de herramientas, un reporte de bug falso que secuestra tu agente de código. Esos son reales. Pero el problema silencioso, aburrido y mucho más grande es este: tus agentes se loguean, y nadie posee esos logins.

La población explotó; el gobierno no

Para hacer algo útil, un agente necesita credenciales — una llave para leer la base de datos, un token para enviar el correo, un scope de API para agendar la cita. Este año las organizaciones las acuñaron por millones. Solo los usuarios de Microsoft Copilot Studio crearon más de un millón de agentes; Salesforce reportó alrededor de $440M de ingresos agénticos. Cada uno de esos agentes es, en términos de seguridad, un nuevo usuario con contraseña — solo que nadie lo dio de alta, nadie lo posee, y nunca se va.

Y los sistemas para gobernar esa población todavía no existen. Okta encontró que el 68% de las organizaciones no puede distinguir de forma fiable la actividad de un agente de IA de la de un humano. La Cloud Security Alliance lo nombró sin rodeos: el "Vacío de gobierno de la identidad no humana." Por eso la identidad para la IA agéntica dominó tanto RSAC como Identiverse este año.

Un agente que no puedes distinguir de una persona es un agente que no puedes auditar, no puedes revocar y no puedes someter a una política. Eso no es un problema de IA. Es una cuenta sin gestionar.

Por qué esto es peor que un ataque ingenioso

Un exploit de prompt injection necesita que un atacante fabrique algo. Este riesgo no necesita a nadie. Simplemente está ahí: una credencial con acceso amplio, usada por software que actúa por su cuenta, registrándose como si fuera un humano — así que cuando algo se rompe a las 3 de la mañana, no puedes responder las únicas preguntas que importan. ¿Qué agente hizo esto? ¿Quién lo desplegó? ¿A qué tenía permiso de tocar? ¿A quién apagamos? Si el agente comparte una cuenta de servicio o el token de un humano, la respuesta honesta a las cuatro es "no lo sabemos".

Trata a un agente como a un empleado, no como a una llave compartida

El arreglo no es un producto que compras; es una disciplina que ya conoces de gestionar personas:

• Su propia identidad. Cada agente recibe una identidad distinta, de primera clase — nunca una cuenta de servicio compartida, nunca el token prestado de un humano. Si no puedes nombrar al agente detrás de una acción, no puedes gobernarlo.
• Mínimo privilegio, acotado a la tarea. El agente de reservas puede tocar reservas. No la tabla de nóminas, no la API de admin. La mayoría de las brechas son solo credenciales demasiado amplias esperando un mal día.
• Un dueño y una caducidad. Cada identidad de agente tiene un dueño humano y un tiempo de vida. Los agentes que sobreviven a su propósito son las cuentas sin gestionar de la próxima auditoría.
• Auditable y revocable. Puedes ver exactamente qué hizo cada agente, y puedes matar su acceso de un solo movimiento — sin tumbar con él la cuenta de una persona.

Este es el mismo principio al que vuelvo una y otra vez por la seguridad de los agentes: mínimo privilegio y una frontera dura le ganan a cualquier promesa a nivel de prompt. La identidad es solo mínimo privilegio para el actor en lugar de para la acción.

En resumen

Este año no desplegaste una funcionalidad. Contrataste a mil empleados, les diste llaves y nunca les hiciste credenciales. La mayor exposición de la empresa agéntica no es un exploit ingenioso — es la cuenta ordinaria, sin gobernar, multiplicada por un millón.

Dale a cada agente su propia identidad acotada, un dueño y un interruptor de apagado — antes de que no puedas distinguir cuál acaba de escribir en producción.