Solo el 37% de las empresas puede recuperar la clave de un agente de IA. El riesgo no está en el modelo.

La causa no es el modelo. En seguridad, tampoco

En agosto, Vicente Conde abrió una edición de su newsletter con una cifra difícil de olvidar: US$ 4,3 millones, que él presenta como el costo medio de un incidente grave causado por un agente de IA dentro de una empresa. Su tesis es que la próxima crisis de IA corporativa nacerá de las palabras, no de la tecnología. El mismo término definido de una forma en cada sistema, y un agente actuando sobre eso sin nadie que lo revise.

Estoy de acuerdo. Solo creo que, cuando se trata de seguridad, se puede dar un paso más. El problema rara vez está en el modelo. Está en la clave que le entregaron.

"Agente" se convirtió en una palabra paraguas, así que aclaro de qué hablo. No es el chatbot que responde dudas en el sitio web. Es un programa que recibe una tarea y la ejecuta: lee correos, consulta bases de datos, abre tickets, mueve archivos, llama a otros sistemas. Para hacer cualquiera de esas cosas necesita una credencial. Y la credencial, en seguridad, tiene otro nombre. Identidad.

Ciento nueve a uno

CyberArk, que hoy forma parte de Palo Alto Networks, encuestó a 2.930 responsables de seguridad para el "2026 Identity Security Landscape", publicado en mayo. La cifra de portada: las identidades de máquina (cuentas de servicio, robots y agentes de IA, todo junto) ya suman 109 por cada identidad humana. Un año antes eran 82.

Lo que de verdad me inquietó estaba en el material sobre agentes. De los agentes en uso, el 40% ya accede a datos de la organización. Solo el 37% de las empresas puede revocar la credencial de un agente de IA. Y apenas el 30% guarda registros de auditoría que nadie puede alterar.

Traducido al lenguaje de una reunión de directorio: la mayoría entregó la clave y no sabe cómo recuperarla. Si algo sale mal, siete de cada diez investigarán sin la garantía de que el registro de lo ocurrido esté íntegro.

El agente que obedece la nota equivocada

Piense en un empleado muy eficiente, con la llave maestra del edificio, que cumple cualquier nota que le dejen en el escritorio. Si la nota es del jefe, perfecto. Si la dejó un desconocido que pasaba por el pasillo, la cumple igual.

Eso es, más o menos, la inyección de prompt. El agente lee un correo, una página o un documento con instrucciones ocultas y las ejecuta como si fueran una orden legítima. OWASP, la fundación cuyas listas de riesgos el mercado usa como referencia, sitúa la inyección de prompt en primer lugar entre los riesgos de las aplicaciones con modelos de lenguaje. En diciembre de 2025 publicó una lista dedicada a las aplicaciones con agentes y destacó, entre los riesgos centrales, el abuso de identidad y de privilegios.

La analogía falla en un punto, y ese punto pesa en contra del agente: el empleado a veces desconfía de la letra de la nota. El agente, en muchos casos, ni siquiera tiene cómo separar lo que es dato de lo que es orden.

Esto ya dejó de ser teoría. En junio de 2025 se publicó la CVE-2025-32711, una falla en Microsoft 365 Copilot que la base de vulnerabilidades del NIST describe como inyección de comandos de IA, capaz de permitir a un atacante no autorizado obtener información a través de la red. La propia Microsoft le asignó una puntuación de 9,3 sobre 10.

Ocho de cada diez ya vieron al agente hacer lo que no debía

En mayo de 2025, SailPoint y Dimensional Research encuestaron a 353 profesionales de TI y seguridad en cinco continentes para el estudio "AI agents: The new attack surface". El ochenta por ciento dijo que sus agentes ya habían hecho algo que nadie les pidió. Entre esas acciones no previstas, el 39% implicó acceso a sistemas no autorizados y el 32%, la descarga de contenido sensible. Y el 23% contó que sus agentes fueron engañados hasta el punto de entregar credenciales de acceso.

¿Una política para proteger esos agentes? Solo el 44% la tenía.

El ataque no pasó por el modelo. Pasó por la puerta de al lado

Si tuviera que elegir un único dato para llevarle a un CISO, o a un CTO que acaba de aprobar un proyecto de agentes, sería este. En el "Cost of a Data Breach 2026", que IBM publicó en julio junto con el Ponemon Institute, más del 20% de las 602 organizaciones estudiadas reportaron filtraciones dirigidas a modelos o aplicaciones de IA. Las causas más comunes no tenían nada que ver con el modelo en sí: API, aplicaciones o plug-ins comprometidos (27%) y configuración errónea de la nube en cargas de IA (27%).

La recomendación de la propia IBM, en el informe, es ejecutar los agentes con permisos restringidos y aplicados de forma continua en el momento de la ejecución, con atribución a un humano y pista de auditoría. Fíjese en que es una recomendación de identidad.

En Brasil, la edición de 2025 del mismo estudio ya mostraba el tamaño del agujero: el 87% de las organizaciones sin política de gobernanza de IA y el 61% sin control de acceso a la IA. El costo medio de una filtración en el país fue de R$ 7,19 millones.

Lo que Gartner espera que ocurra

Gartner tiene dos proyecciones en la misma dirección. Son proyecciones, no mediciones, pero ayudan a ver hacia dónde van las cosas. En 2024, la consultora previó que para 2028 una cuarta parte (25%) de las filtraciones en empresas tendrá su origen en el abuso de agentes de IA, por parte de actores externos o internos. En mayo de 2026 fue más específica: para 2027, el 40% de las empresas degradará o apagará agentes autónomos por fallas de gobernanza que solo aparecieron después de un incidente en producción.

En ese mismo análisis hay una frase que me habría gustado escribir. Según Gartner, el fracaso es más probable cuando la empresa no separa lo que el agente es capaz de hacer del alcance de acceso que recibe. Es la tesis de este texto, dicha por un analista.

Tres decisiones antes de encender el próximo agente

1. Cada agente es una identidad, y toda identidad tiene dueño. Nada de agentes funcionando con la cuenta de servicio genérica del equipo o, peor, con la credencial personal de quien los configuró. Identidad propia y un humano responsable de ella, con nombre y apellido.

2. Lo que el agente sabe hacer no es lo que puede acceder. El agente que resume contratos no necesita permiso para borrar la carpeta donde están guardados. Mínimo privilegio, aplicado en el momento de la acción, y no solo en el documento de política. El caso de Replit, en julio de 2025, lo muestra bien: el agente borró una base de datos de producción en plena congelación de código, y antes de ser un problema de IA fue un problema de permisos. Tenía acceso de escritura donde no debía.

3. Tiene que ser posible recuperar la clave, y ver qué se hizo con ella. La revocación rápida y el log inmutable parecen detalles técnicos hasta el día del incidente, cuando se convierten en la diferencia entre contener el daño e investigar a ciegas. Yo añadiría algo: observar el comportamiento. Los agentes tienen patrones de uso, igual que las personas, y cuando uno se sale del patrón, eso ya es una señal.

La pregunta para la próxima demostración

La próxima vez que alguien le muestre un agente que resuelve en minutos lo que antes tomaba días, sea un proveedor o su propio equipo, haga una sola pregunta: si necesito cortar el acceso de este agente a las tres de la mañana, ¿quién lo hace, en cuántos minutos y dónde veo todo lo que hizo antes?

Según las cifras de CyberArk, solo el 37% de las empresas tiene esa respuesta. El resto confía en que el agente nunca lea la nota equivocada.