Conclusiones clave
- La gestión de identidades se diseñó para una persona frente a un navegador validando MFA y SSO — un agente autónomo con credenciales permanentes operando a velocidad de máquina rompe esa suposición de forma estructural, no como un caso extremo.
- El modelo de amenazas incluye cuentas de servicio con permisos excesivos, claves API de larga duración incrustadas en la configuración del agente, inyección de prompts que escala a una acción privilegiada, y cadenas de delegación agente a agente donde, al tercer salto, nadie puede rastrear a la persona que autorizó la acción original.
- Las identidades no humanas (agentes, cuentas de servicio, identidades de carga de trabajo) ya superan ampliamente el número de identidades humanas en la mayoría de entornos empresariales — un patrón ampliamente observado, no una cifra concreta que este artículo esté citando.
- Los controles que funcionan: credenciales de corta duración y rotativas, una identidad por agente con registro de auditoría completo, aprobación humana solo en acciones irreversibles, control de salida de red y listas explícitas de herramientas permitidas.
- Un modelo autoalojado elimina el riesgo de exfiltración a terceros y mantiene los datos internos — no corrige la inyección de prompts, credenciales con permisos excesivos ni la falta de registro de auditoría, que son los riesgos mayores.
- Ninguna jurisdicción tiene aún una ley dedicada a la identidad de la IA agéntica — hoy es principalmente un problema de ingeniería y arquitectura, no de cumplimiento normativo, aunque los despliegues en servicios financieros e infraestructura crítica en la UE enfrentan presión real por la superposición de marcos (ver Contexto legal por región).
El cambio de una IA que responde a una IA que actúa
La gestión de identidades se diseñó en torno a una coreografía concreta: una persona se sienta frente a un navegador, prueba su identidad mediante MFA o SSO, y una sesión recibe un alcance ligado a esa prueba. Un agente LLM rompe cada parte de esa coreografía a la vez — no hay una persona frente al teclado en cada acción, la "sesión" puede correr sin supervisión durante horas o días, y la credencial que posee a menudo se definió una sola vez en la configuración inicial y nunca se revisó de nuevo.
Esto no es una versión menor del mismo problema. Un chatbot que responde preguntas no tiene acceso permanente para cambiar nada. Un agente que lee un ticket, escribe un registro en una base de datos, llama a tres API internas y despliega un cambio de configuración está tomando una decisión de autorización en cada uno de esos pasos — y las herramientas de IAM diseñadas para sesiones humanas no tienen ningún concepto nativo de "esta decisión la tomó un modelo actuando sobre una instrucción de hace cinco minutos, no una persona".
La consecuencia práctica: el ritmo de revisión de accesos, la elevación de MFA en acciones sensibles y el registro de auditoría de "quién hizo esto" que los programas de IAM han tardado una década en construir para personas, mayormente todavía no existen para los agentes que un equipo de plataforma está desplegando este trimestre.
📍 En una frase
La gestión de identidades asume que una persona prueba su identidad frente a un navegador antes de cada sesión; un agente autónomo con credenciales permanentes operando a velocidad de máquina rompe esa suposición de forma estructural, no como un caso extremo.
💬 En términos simples
El IAM se construyó para responder "¿acaba de iniciar sesión la persona correcta?". Un agente de IA nunca inicia sesión como lo hace una persona — mantiene una credencial de forma continua y actúa con ella sin que nadie vuelva a comprobarlo, lo cual es un problema distinto para el que las herramientas de IAM no fueron diseñadas.
El modelo de amenazas, en concreto
Cinco modos de fallo explican la mayor parte de la exposición real una vez que un agente obtiene acceso de escritura. Se combinan entre sí — una credencial con permisos excesivos más un registro de auditoría ausente convierte un incidente contenido en uno imposible de rastrear.
💬 En términos simples
La mayoría de los incidentes de seguridad en agentes no son un único fallo dramático — son una credencial con permisos excesivos, una clave estática y un registro de auditoría ausente presentes al mismo tiempo, dejando margen para que una simple instrucción inyectada se convierta en una acción privilegiada imposible de rastrear.
- 1Cuentas de servicio con permisos excesivos.
Why it matters: Un agente creado para actualizar un solo campo en un sistema de tickets suele recibir la misma credencial de cuenta de servicio amplia que ya se usa en otro lugar, porque provisionar una más restringida supone más trabajo. El agente termina con mucho más acceso del que su tarea requiere, y cada acción que ejecuta hereda todo el radio de impacto de esa cuenta. - 2Claves API de larga duración incrustadas en la configuración del agente.
Why it matters: Una clave estática guardada en un archivo de configuración o variable de entorno no caduca, no rota — y si el framework del agente registra sus propios prompts o la clave se filtra a través de un endpoint de depuración, no hay ningún mecanismo integrado que limite la ventana de daño, como sí lo haría un token de corta duración. - 3Inyección de prompts que escala a una acción privilegiada.
Why it matters: Un agente que lee contenido externo — una página web, un correo, un ticket de soporte, un documento de una unidad compartida — como parte de su tarea puede encontrar instrucciones que un atacante ha incrustado en ese contenido. Si el agente no distingue de forma fiable "instrucción de mi operador" de "texto que se me pidió leer", una instrucción oculta en el contenido recuperado puede hacer que el agente ejecute una acción fuera de su alcance previsto — este es el mecanismo contra el que un arquitecto de seguridad debe diseñar, no una carga útil para reproducir. - 4Cadenas de delegación agente a agente sin origen rastreable.
Why it matters: El agente A llama al agente B, que llama al agente C para completar una subtarea. Al tercer salto, la credencial en uso, la tarea original y la persona que autorizó la solicitud de nivel superior a menudo ya no se propagan juntas — un registro de auditoría en el tercer salto muestra entonces una acción sin cadena reconstruible hasta quién la aprobó. - 5La superficie de llamadas a herramientas y MCP como superficie de ataque.
Why it matters: El Model Context Protocol (MCP) y las interfaces similares de llamada a herramientas amplían, con cada nueva herramienta conectada, lo que un agente puede alcanzar. Cada herramienta adicional es una capacidad nueva que ahora cubre la credencial del agente, y un nuevo lugar donde un servidor de herramientas malicioso o comprometido puede devolver contenido que el agente trate como instrucción confiable en lugar de datos no confiables.
Por qué el IAM existente no cubre esto
El SSO y la MFA están diseñados para probar que una persona está presente en el momento del acceso — un agente autónomo nunca está presente en ese sentido, así que todo el modelo de verificación no se le aplica. Un agente es una identidad no humana (NHI): una cuenta de servicio, una identidad de carga de trabajo o una credencial de API que actúa de forma continua en lugar de autenticarse una vez por sesión.
Las identidades no humanas ya superan ampliamente el número de identidades humanas en la mayoría de entornos empresariales — un patrón ampliamente reportado entre proveedores de seguridad y encuestas del sector, no una cifra concreta que este artículo esté citando, y la proporción varía según la organización. Lo que se mantiene constante en esos reportes es la dirección: el número de NHI ha crecido más rápido que la plantilla humana durante años, impulsado principalmente por cuentas de servicio y automatización, y la IA agéntica es hoy la categoría de más rápido crecimiento dentro de esa tendencia.
La mayoría de los programas de IAM empresariales aún gestionan el aprovisionamiento de NHI mediante un proceso más ligero y menos revisado que la incorporación de personas — un nuevo empleado recibe una revisión de acceso, la aprobación de un responsable y una recertificación programada; una nueva cuenta de servicio o credencial de agente a menudo no recibe ninguna de las tres. Esa brecha era tolerable cuando las NHI eran mayormente scripts estáticos de alcance limitado. Deja de serlo cuando la NHI es un agente capaz de encadenar llamadas a herramientas, interpretar instrucciones ambiguas y ejecutar acciones que quien lo aprovisionó no enumeró explícitamente de antemano.
📍 En una frase
El SSO y la MFA verifican que una persona está presente en el momento del acceso; un agente autónomo con una credencial permanente nunca está presente en ese sentido — por eso la gobernanza de identidades no humanas, y no una autenticación humana más fuerte, es el verdadero vacío.
Calculadora de radio de impacto del agente
Evalúa un despliegue de agente concreto en cinco dimensiones para obtener un nivel de radio de impacto y una recomendación de mínimo privilegio a la medida. Se ejecuta por completo en tu navegador — no se envía nada.
Agent Blast-Radius Calculator
Answer 5 questions about one agent deployment to get a blast-radius risk tier and a matched least-privilege recommendation. Nothing is sent anywhere — scoring runs entirely in your browser.
1. What is the agent's capability scope?
2. What is the credential lifetime the agent uses?
3. How reversible are the agent's actions?
4. Does a human-in-the-loop approval gate exist for high-impact actions?
5. Is there an audit trail with attribution to an authorizing human?
Controles que funcionan
Seis controles explican la mayor parte de la reducción real del radio de impacto de un agente. Ninguno basta por sí solo — se combinan igual que los modos de fallo del modelo de amenazas.
Credenciales de corta duración y rotativas
- Qué hace:
- Sustituye las claves API estáticas por identidad de carga de trabajo o tokens que caducan y rotan automáticamente.
- Por qué funciona:
- Una credencial filtrada o mal usada tiene una ventana de utilidad limitada en lugar de indefinida.
Una identidad por agente
- Qué hace:
- Da a cada agente su propia credencial en lugar de compartir una cuenta de servicio entre agentes o con personas.
- Por qué funciona:
- Un incidente se rastrea hasta las acciones de un solo agente en lugar de un conjunto indiferenciado, y el alcance puede ajustarse por agente en lugar de al mínimo común denominador.
Aprobación humana solo en acciones irreversibles
- Qué hace:
- Exige una verificación humana específicamente para acciones que no pueden deshacerse limpiamente, no para cada acción del agente.
- Por qué funciona:
- Aprobar todo anula el propósito de la automatización y entrena a los revisores a aprobar sin leer; limitarlo a acciones irreversibles mantiene la verificación con sentido.
Control de salida de red
- Qué hace:
- Limita a nivel de red qué endpoints externos puede alcanzar un proceso de agente, independientemente de lo que el agente crea que su tarea requiere.
- Por qué funciona:
- Un agente comprometido o manipulado no puede exfiltrar datos ni llamar a un servicio externo arbitrario si la propia red no permite la conexión.
Listas de herramientas permitidas
- Qué hace:
- Restringe a un agente a un conjunto explícito y enumerado de herramientas invocables en lugar de un descubrimiento abierto de herramientas.
- Por qué funciona:
- Una herramienta nueva o no revisada — incluida una alcanzada vía MCP desde un servidor comprometido — no puede invocarse si no está en la lista, sin importar lo que pida una instrucción inyectada.
Ejecución en entorno aislado
- Qué hace:
- Ejecuta las acciones del agente dentro de un entorno aislado con su propio límite de recursos y permisos, separado del sistema anfitrión.
- Por qué funciona:
- Contiene el daño de una acción que sí se ejecuta — escapar de un entorno aislado es un problema distinto y más difícil que el de que una acción tenga éxito dentro de un entorno compartido.
La atribución completa del registro de auditoría a una persona autorizante atraviesa los seis controles anteriores en lugar de ser un elemento aparte — sin ella, ninguno de estos controles produce un registro rastreable después de los hechos.
Qué corrigen los modelos locales y autoalojados — y qué no
Ejecutar el modelo de un agente en infraestructura autoalojada elimina el riesgo de exfiltración a terceros y mantiene los prompts y las salidas dentro de la red de la organización — no resuelve el problema de identidad y acceso que es el tema de este artículo. Un lector con criterio de seguridad restaría credibilidad al resto de esta guía si esa distinción se difumina, así que vale la pena decirlo con claridad.
El despliegue local no corrige la inyección de prompts. La inyección es un problema de capa de aplicación y arquitectura — cómo distingue el agente instrucciones confiables de contenido recuperado no confiable — y es idéntico tanto si el modelo subyacente corre en una API de proveedor como en hardware propio de la organización. Traer el modelo a casa no cambia en nada cómo el agente procesa una página web o un documento que se le pidió leer.
El despliegue local no corrige credenciales con permisos excesivos. Un modelo autoalojado que llama a una cuenta de servicio con permisos excesivos es exactamente tan peligroso como un modelo alojado por un proveedor que llama a la misma cuenta — el alcance de la credencial es una propiedad del diseño de acceso del agente, no de dónde corren los pesos del modelo.
El despliegue local no corrige la falta de un registro de auditoría. Que la inferencia ocurra en una API alquilada o en una GPU propia no afecta a si una acción queda registrada con atribución a la persona que la autorizó. Esa es una decisión de registro y arquitectura de identidad, tomada por separado.
Para lo que el despliegue local sí sirve genuinamente en este contexto: mantener el contenido de los prompts y las salidas de herramientas fuera de la infraestructura de un tercero, algo relevante para la residencia de datos y el riesgo de terceros. Es un elemento de una postura de seguridad para agentes, no un sustituto de los controles de identidad y acceso anteriores.
💬 En términos simples
Ejecutar tu propio modelo internamente resuelve el problema de "nuestros prompts y datos salen de nuestra infraestructura". No resuelve la inyección de prompts, credenciales con permisos excesivos ni un registro de auditoría ausente — esos son problemas de identidad y arquitectura que existen igual, corra el modelo en una API de proveedor o en tu propio hardware.
Contexto legal por región
Para una empresa que opera en la UE en servicios financieros o infraestructura crítica, tres marcos pueden superponerse en un despliegue de agentes. NIS2 exige notificación de incidentes, seguridad de la cadena de suministro y, para las entidades dentro de su alcance, responsabilidad personal de la dirección. DORA se aplica específicamente a entidades financieras y exige un registro de riesgos de terceros TIC; un agente autónomo que llama a API externas podría considerarse una dependencia TIC registrable bajo DORA, algo que la mayoría de empresas aún no ha contemplado. La AI Act añade su propia capa encima, según el nivel de riesgo del agente.
Efecto práctico: tres marcos que se superponen y pueden aplicarse simultáneamente generan, para despliegues de agentes en sectores regulados de la UE, una presión real hacia arquitecturas de alojamiento soberano o local — no como obligación legal en sí, sino porque una arquitectura local simplifica demostrar el cumplimiento bajo los tres marcos.
Que NIS2 y DORA se apliquen a una empresa concreta depende del sector y la clasificación de la entidad — esta sección es orientación general, no asesoría legal. Confirma la aplicabilidad con asesoría especializada en NIS2/DORA/AI Act antes de finalizar una arquitectura de acceso.
Preguntas frecuentes
¿Qué es la seguridad de la IA agéntica?
La seguridad de la IA agéntica es el conjunto de controles de identidad, acceso y monitoreo que rigen a un agente de IA autónomo con credenciales permanentes y capacidad de ejecutar acciones — a diferencia de un chatbot que solo responde preguntas. Se centra en tratar a cada agente como una identidad no humana con su propia credencial acotada, registro de auditoría y aprobaciones, en lugar de como una extensión de la persona que lo configuró.
¿En qué se diferencia la seguridad de la IA agéntica de la gestión de identidades y accesos tradicional?
El IAM tradicional asume que una persona prueba su identidad vía MFA o SSO antes de cada sesión. Un agente mantiene una credencial permanente y actúa de forma continua a velocidad de máquina sin reautenticación por acción, así que la suposición de presencia humana en el núcleo del SSO y la MFA no se le aplica — esa brecha hay que cerrarla con gobernanza de identidades no humanas.
¿Cuál es el mayor riesgo de seguridad al dar a un agente de IA acceso de escritura?
La combinación de una credencial con permisos excesivos y un registro de auditoría ausente es el mayor riesgo, porque convierte cualquier incidente aislado — una inyección de prompts, una llamada a herramienta mal configurada, una cadena de delegación — de un evento contenido y rastreable en uno con radio de impacto ilimitado y sin forma de reconstruir quién autorizó qué.
¿Cómo lleva la inyección de prompts a una acción privilegiada?
Un agente que lee contenido externo — una página web, un documento, un ticket de soporte — como parte de su tarea puede encontrar instrucciones que un atacante incrustó en ese contenido. Si no distingue de forma fiable "instrucción de mi operador" de "texto que se me pidió procesar", una instrucción oculta puede hacer que ejecute una acción fuera de su alcance previsto. La solución es arquitectónica — listas de herramientas permitidas, credenciales acotadas y aprobación humana en acciones irreversibles —, no solo mejores prompts.
¿Qué es una identidad no humana (NHI) y por qué importa para los agentes de IA?
Una identidad no humana es cualquier actor con credenciales que no es una persona — una cuenta de servicio, una identidad de carga de trabajo, una clave API o un agente de IA. Las NHI ya superan ampliamente el número de identidades humanas en la mayoría de entornos empresariales, un patrón ampliamente observado, y la mayoría de los programas de IAM gestionan el aprovisionamiento de NHI con un proceso más ligero que la incorporación de personas — una brecha que pesa mucho más cuando la NHI es un agente capaz de encadenar acciones por sí solo.
¿Debe cada acción de un agente requerir aprobación humana?
No. Exigir aprobación para cada acción anula el propósito de la automatización y entrena a los revisores a aprobar sin leer. El control que funciona reserva la aprobación específicamente para acciones irreversibles — las que no pueden deshacerse limpiamente —, mientras que las acciones reversibles de bajo impacto continúan sin una persona en el circuito.
¿Ejecutar un modelo local o autoalojado corrige los riesgos de seguridad de la IA agéntica?
No, no por sí solo. Un modelo autoalojado elimina el riesgo de exfiltración a terceros y mantiene los datos internos, pero no corrige la inyección de prompts, credenciales con permisos excesivos ni un registro de auditoría ausente — son problemas de identidad y arquitectura idénticos sin importar dónde corra el modelo.
¿Qué duración de credencial debería usar un agente de IA?
Credenciales de corta duración, rotadas automáticamente, o una identidad de carga de trabajo — no una clave API estática de larga duración. Una clave estática incrustada en la configuración del agente no tiene ningún mecanismo integrado para limitar la ventana de daño si se filtra; una credencial de corta duración limita esa ventana por diseño.
¿Cómo crean riesgo las cadenas de delegación agente a agente?
Cuando el agente A llama al agente B, que llama al agente C para completar una subtarea, la credencial en uso, la tarea original y la persona que autorizó la solicitud de nivel superior a menudo no se propagan juntas en cada salto. Al tercer salto, un registro de auditoría puede mostrar una acción sin cadena reconstruible hasta quién la aprobó — la solución es diseñar las cadenas de delegación para propagar explícitamente el contexto de autorización, en lugar de asumir que se transmite automáticamente.