A las 9:12 de un lunes por la mañana, los clientes de un minorista ficticio empiezan a informar de pedidos fallidos.
El equipo de plataforma tiene un agente de operaciones de IA conectado a su cola de soporte y a su entorno en la nube. Un ingeniero le da una instrucción breve:
Averigua por qué falla el proceso de pago y soluciona el problema.
El agente lee el ticket del incidente, busca en los registros (logs) de la aplicación, compara los despliegues recientes y comprueba el estado del servicio de pagos. Encuentra un certificado caducado, genera uno de reemplazo, actualiza la configuración y despliega el cambio.
El proceso de pago se recupera en doce minutos. El equipo queda impresionado.
Entonces, el responsable de seguridad pregunta:
- ¿Qué identidad modificó producción?
- ¿El agente tenía permiso para investigar o también para desplegar?
- ¿De quién era la autoridad que utilizó?
- Si hubiera cambiado el certificado equivocado, ¿podría el equipo demostrar lo que ocurrió?
El registro de auditoría ofrece una sola respuesta: platform-automation-service.
Esa cuenta también la usan los pipelines de despliegue, scripts de mantenimiento y dos herramientas de automatización más antiguas. Su credencial demuestra que una cuenta aprobada hizo la llamada. No revela qué sistema eligió la acción, qué persona inició el trabajo, qué resultado se aprobó ni cuándo debería haber terminado esa autoridad.
El agente resolvió la caída del servicio. También dejó al descubierto una vieja debilidad de arquitectura: una credencial se había convertido en sustituto de la identidad, la autoridad y la rendición de cuentas.
Los agentes cambian la pregunta de seguridad
Las aplicaciones siempre han necesitado credenciales. Un servicio puede usar un token para llamar a otro servicio. Un pipeline de despliegue puede usar una cuenta de servicio para actualizar recursos en la nube (en inglés). Una tarea programada puede usar un certificado para leer de una base de datos.
Estos patrones no son inseguros de por sí. El problema empieza cuando una sola credencial de larga duración ocupa el lugar de varios actores y propósitos.
La automatización tradicional suele tener un alcance limitado. Un pipeline sigue código escrito de antemano. Una tarea de copia de seguridad ejecuta una secuencia conocida. Un agente de IA (en inglés) es menos predecible: recibe un objetivo, examina su entorno, selecciona herramientas y cambia su siguiente paso según lo que encuentra.
Puede que el modelo no sea determinista, pero sus llamadas a herramientas tienen consecuencias reales.
Ante un script convencional, solemos preguntar:
¿Puede este proceso llamar a la API?
Ante un agente, esa es solo la primera pregunta. También debemos preguntar:
¿Por qué llama a la API, de quién es la autoridad que está usando y sigue esta acción dentro de la tarea que se aprobó?
Una clave de API no puede responder por sí sola a esas preguntas.
Una credencial demuestra menos de lo que creemos
Una credencial es una prueba que se usa durante la autenticación. Puede ayudar a un servicio a demostrar qué principal está haciendo una solicitud. Por sí misma, no explica por qué la solicitud está permitida.
Hay cinco ideas que deben mantenerse separadas:
- Identidad: qué actor hace la solicitud.
- Autenticación: cómo verifica el sistema esa afirmación.
- Autorización: qué puede hacer el actor verificado.
- Delegación: qué puede hacer un actor en nombre de otro, con un propósito y durante un periodo determinados.
- Rendición de cuentas: si la organización puede reconstruir la solicitud, la decisión, la política, la acción y el resultado.
Un token válido puede demostrar que una solicitud procede de un principal autenticado. No puede demostrar que la solicitud coincida con la intención actual del usuario. Puede que un ingeniero tenga permiso para desplegar, pero eso no significa que todos los agentes que invoque deban heredar el mismo poder.
Por eso, «el agente está autenticado» no es una conclusión de seguridad completa.
Una sola acción puede implicar cuatro identidades
En el incidente del proceso de pago, una sola llamada a una API de la nube puede implicar al menos cuatro identidades.
| Identidad | Qué representa | Pregunta que responde |
|---|---|---|
| Humana | El ingeniero que solicitó o aprobó la tarea | ¿Quién pidió este trabajo? |
| Agente | El software que elige la siguiente acción | ¿Qué sistema autónomo la seleccionó? |
| Carga de trabajo | El proceso, contenedor o pod que hace la llamada | ¿Qué entorno de ejecución desplegado la envió? |
| Destino | El servicio o recurso que acepta la llamada | ¿Qué sistema la ejecutó? |
Estas identidades pueden solaparse. Un agente interno pequeño con un comportamiento fijo puede usar razonablemente una identidad de carga de trabajo existente. Pero el modelo se vuelve más difícil de gobernar cuando los agentes se crean de forma dinámica, actúan en nombre de distintos usuarios, llaman a muchas herramientas o solo existen para una tarea.
Si un pipeline y un agente de operaciones usan el mismo principal, el registro de auditoría no puede distinguir con fiabilidad la automatización fijada de antemano de una decisión dirigida por el modelo. Si veinte agentes comparten una clave, desactivar un agente comprometido puede afectar a los veinte. Si un agente usa el token de una persona, su alcance puede ampliarse en silencio a todo el acceso de esa persona.
No se trata de crear una identidad solo para darle un nombre al agente. Se trata de que su acceso sea separable, contenible y trazable.
El mercado de la nube avanza en la misma dirección
Durante el último año, varias plataformas han introducido controles que tratan a los agentes como actores visibles y no como usuarios anónimos de un secreto compartido.
Entra Agent ID, de Microsoft, separa las identidades de los agentes de las identidades humanas y de las de aplicaciones convencionales. Admite tanto el acceso asignado directamente a un agente como la autoridad delegada por un usuario, y registra la autenticación admitida como actividad del agente.
Google Cloud anunció un Agent Identity basado en SPIFFE, con políticas de IAM que reconocen a los agentes y aplicación de políticas en la pasarela (gateway). A 6 de mayo de 2026, la identidad básica en tiempo de ejecución y la compatibilidad con IAM Allow y Deny tenían disponibilidad general; varios controles relacionados de pasarela y de contexto seguían en versión preliminar o estaban previstos.
AWS tomó otro camino. Amazon Bedrock AgentCore alcanzó la disponibilidad general en octubre de 2025. AgentCore Policy llegó a la disponibilidad general en marzo de 2026 y evalúa las llamadas a herramientas de la pasarela fuera del bucle de razonamiento del agente. El AWS MCP Server gestionado también usa controles de IAM y ofrece una visibilidad separada de la actividad del servidor.
Los servicios son distintos y el estado de sus funciones cambiará. Su dirección común importa más que sus nombres comerciales:
Da al agente una identidad distinguible, limita su autoridad y aplica la política antes de que una acción propuesta se convierta en una operación real.
Estos servicios son piezas útiles. Ninguno elimina la necesidad de diseñar qué puede hacer el agente en una tarea concreta.
El problema más difícil es la deriva de la autoridad
Volvamos al incidente. El ingeniero pide al agente que investigue los fallos del proceso de pago. El agente lee los registros y descubre el certificado caducado.
A continuación, llama a una herramienta de certificados. Esa herramienta llama a un servicio de despliegue. El servicio de despliegue pide a otro agente que valide el despliegue. Cada componente puede tener una identidad válida, y cada llamada puede estar permitida por una política de acceso amplia.
Pero ¿dónde se decidió que «investigar» incluía «reemplazar un certificado de producción y desplegarlo»?
La autoridad puede desviarse a medida que el trabajo pasa por herramientas, agentes y servicios. La autenticación sigue siendo válida mientras se debilita la conexión entre la solicitud original y la consecuencia final.
Esto pone de manifiesto la diferencia entre la autorización de acceso y la autorización de acción.
La autorización de acceso pregunta:
¿Puede este agente llamar a la API de despliegue?
La autorización de acción pregunta:
¿Puede este agente realizar este despliegue, sobre este recurso, para esta tarea, con una autoridad que siga siendo válida ahora?
Una identidad de agente única mejora la visibilidad y facilita la aplicación de políticas. Por sí sola, no cierra esta brecha.
Sigue siendo un área en evolución. El NIST lanzó su AI Agent Standards Initiative en febrero de 2026 e investiga la autenticación de agentes y la infraestructura de identidad. Por separado, su National Cybersecurity Center of Excellence estudia enfoques de identidad y autorización basados en estándares para el acceso y las acciones de software y agentes de IA. En el momento de esta revisión, ese trabajo seguía en curso y no constituía un estándar de arquitectura consolidado.
Coloca la política justo antes de la consecuencia
Una instrucción como «nunca hagas un cambio peligroso sin permiso» puede influir en el comportamiento del modelo. No es un control de autorización. El modelo interpreta las instrucciones; un sistema independiente debe hacer cumplir los permisos.
El punto de control más sólido suele ser el límite inmediatamente anterior a la ejecución de una herramienta o API con consecuencias.
El flujo seguro tiene cuatro puntos de control:
- Identificar la solicitud. Registrar la persona, el agente, la carga de trabajo en ejecución, la tarea, la hora y el resultado previsto.
- Acotar la delegación. Dar al agente solo los recursos, las acciones y la duración que requiere esa tarea.
- Decidir fuera del modelo. Evaluar en un servicio de políticas externo el destino y la acción propuestos, el entorno, el riesgo y las reglas de aprobación.
- Ejecutar y demostrar. Emitir una credencial de corta duración para la operación aprobada, volver a aplicar la política en la ejecución y registrar el resultado.
El límite importante está entre la propuesta y la ejecución:
El modelo puede proponer. No debería poder aprobar su propia propuesta, emitir su propia autoridad ni eludir el punto de aplicación.
La aprobación humana debe significar algo
Añadir un botón de aprobación puede generar una falsa confianza. Las personas aprueban demasiado rápido cuando las solicitudes son frecuentes, vagas o difíciles de entender.
«Permitir que el agente continúe» no es una decisión informada. Una aprobación útil muestra la consecuencia real:
Reemplazar el certificado
payment-internalen producción, desplegar la revisióncheckout-1842, supervisar durante diez minutos y revertir si los errores de pago superan el umbral acordado.
La aprobación también debe basarse en el riesgo. Un agente de operaciones puede leer métricas de estado sin interrupciones. Puede reiniciar una carga de trabajo de desarrollo que ha fallado siguiendo un runbook aprobado. Un cambio de certificado en producción, una actualización de permisos de una base de datos o una eliminación deberían atravesar un límite más estricto.
Algunas acciones deberían seguir prohibidas incluso cuando un usuario las solicite. Un agente no debería poder concederse permisos a sí mismo, desactivar su registro de auditoría ni reescribir la política que evalúa sus propias acciones.
La participación humana es más útil cuando el sistema ya ha reducido la pregunta a una decisión concreta y comprensible.
La carga de trabajo sigue necesitando una credencial sólida
La identidad del agente no sustituye a la identidad de carga de trabajo. El agente sigue ejecutándose como proceso, contenedor o pod (en inglés), y ese entorno de ejecución necesita una forma segura de autenticarse.
Los tokens de portador (bearer tokens) funcionan como entradas: quien tenga una copia válida puede presentarla. Kubernetes está reforzando esta capa con Pod Certificates, introducidos en beta en la versión 1.35 y que pasaron a disponibilidad general en la versión 1.37. Admiten la prueba de posesión y la rotación gestionada por la plataforma, en lugar de enviar una credencial de portador completa a cada interlocutor.
No es una respuesta universal. Las aplicaciones deben usar el material rotado, y las organizaciones siguen necesitando un firmante de certificados y un modelo de confianza cuidadosamente diseñado. El principio duradero es preferir credenciales de corta duración y específicas de cada carga de trabajo a secretos estáticos copiados entre sistemas.
La identidad lógica del agente y su identidad en tiempo de ejecución deben estar conectadas en el registro de auditoría sin fundirse en la misma cuenta compartida.
No resuelvas primero el problema de moda
La autorización de agentes no debe distraer de la seguridad básica. El informe M-Trends 2026 de Mandiant, basado en sus investigaciones de 2025, afirma que los exploits siguieron siendo el vector de infección inicial más común, con un 32 %. También afirma que la gran mayoría de las intrusiones con éxito siguieron derivándose de fallos humanos y sistémicos fundamentales, aunque los atacantes usaron la IA para acelerar partes de su trabajo.
Una organización que crea identidades de agente sofisticadas mientras deja sin parchear sistemas expuestos a internet o mantiene secretos de larga duración en repositorios ha resuelto el problema nuevo antes que el urgente. Hay que seguir aplicando parches, reforzando, supervisando y probando la recuperación, y no añadir acceso autónomo mediante identidades que hagan imposible distinguir o contener las acciones.
Reconstruye el incidente en torno a una autoridad acotada
Volvamos ahora a aquel lunes por la mañana.
El ingeniero pide al agente de operaciones que investigue los fallos del proceso de pago. La plataforma registra la tarea y concede un acceso de corta duración y de solo lectura a los registros, las métricas y los datos de despliegue del proceso de pago.
El agente encuentra el certificado caducado. Como su autoridad de investigación no puede modificar producción, crea una propuesta con el destino, el despliegue, las comprobaciones de validación y la condición de reversión.
Un servicio de políticas externo comprueba el destino, la operación y el requisito de aprobación. El ingeniero aprueba el cambio exacto, y un servicio de ejecución recibe una credencial temporal restringida a esa operación y a ese recurso. La política se vuelve a comprobar justo antes de la ejecución.
El registro final conecta al ingeniero, el agente, la carga de trabajo en ejecución, la versión de la política, la acción aprobada, el recurso modificado, el resultado de la validación y la hora de caducidad.
El agente sigue resolviendo la caída del servicio con rapidez. La diferencia es que esa rapidez ya no depende de una cuenta con un poder sin explicar.
Diez preguntas antes de dar a un agente acceso a la nube
- ¿Podemos distinguir al agente de su usuario, de su entorno de ejecución y de otras automatizaciones?
- ¿Quién es el propietario y el responsable de la identidad del agente?
- ¿El agente actúa de forma independiente o usa una autoridad humana delegada?
- ¿Puede esa delegación ser más restringida que el acceso completo del usuario?
- ¿Las credenciales son de corta duración, están limitadas a recursos concretos y vinculadas a una audiencia?
- ¿Qué acciones son de solo lectura, están preaprobadas, requieren aprobación o están prohibidas?
- ¿Se aplica la política fuera del modelo y justo antes de la ejecución?
- ¿Puede otra herramienta u otro agente eludir ese mismo límite de política?
- ¿Puede el registro de auditoría conectar la solicitud, la decisión, la acción y el resultado?
- ¿Qué pone fin automáticamente a la autoridad cuando se completa la tarea?
Si las respuestas se reducen a «el agente usa nuestra cuenta de automatización», el diseño no está terminado.
El principio que hay que mantener
Los agentes de IA hacen que una vieja debilidad de la seguridad en la nube sea más difícil de ignorar. La selección autónoma de herramientas crea más formas de usar la autoridad oculta en las credenciales compartidas y en las cuentas de servicio con permisos amplios.
Una identidad única es solo el principio.
El límite completo debe conectar a la persona, el agente, la carga de trabajo en ejecución, el propósito delegado, la acción propuesta, la decisión de la política y la consecuencia final.
Antes de preguntar si un agente puede realizar una tarea, haz tres preguntas más precisas:
¿De quién es la autoridad que está usando? ¿Qué permite exactamente esa autoridad? ¿Dónde se aplica esa decisión antes de que la acción se haga real?
Esas respuestas, y no la fluidez del modelo, determinan si un agente tiene cabida en producción.
Referencias y lecturas adicionales
Estas fuentes primarias ofrecen una vía de acceso a los detalles de las plataformas, el trabajo de normalización y las pruebas de seguridad en que se basa el artículo. Conviene volver a comprobar el estado de los productos antes de la implementación.
- What are agent identities — Microsoft Entra Agent ID — Explica la identidad de agente, el acceso autónomo, el acceso delegado y la diferencia con las identidades humanas y de aplicaciones. Última actualización: 15 de junio de 2026.
- What’s new in IAM: Security, governance, and runtime defense — Google Cloud — Enumera el estado de disponibilidad en mayo de 2026 de Agent Identity, las políticas de IAM que reconocen a los agentes, la aplicación en la pasarela y los controles relacionados. Publicado el 6 de mayo de 2026.
- Introducing Amazon Bedrock AgentCore — AWS — Presenta las capacidades de entorno de ejecución, identidad y pasarela de AgentCore; actualizado con motivo de la disponibilidad general el 13 de octubre de 2025.
- AgentCore policy controls and evaluations — AWS — Describe la aplicación de políticas fuera del bucle de razonamiento del agente y antes de la ejecución de herramientas en la pasarela. Publicado el 2 de diciembre de 2025; Policy alcanzó la disponibilidad general el 3 de marzo de 2026.
- The AWS MCP Server is now generally available — AWS — Trata el acceso de agentes basado en IAM, la separación de permisos humanos y del servidor, la ejecución en entorno aislado (sandbox) y la visibilidad para auditoría. Publicado el 6 de mayo de 2026.
- Kubernetes v1.35 release — Anuncia Pod Certificates en beta, con generación nativa de claves y rotación automatizada. Publicado el 17 de diciembre de 2025.
- Kubernetes v1.37: Pod Certificates and Cluster Trust Bundles — Explica las limitaciones de los tokens de portador, las credenciales con prueba de posesión, la disponibilidad general y las salvedades de implementación. Publicado el 28 de agosto de 2026.
- NIST AI Agent Standards Initiative — Sigue el trabajo del NIST sobre estándares de agentes seguros e interoperables y sobre infraestructura de identidad. Creado el 17 de febrero de 2026; actualizado el 14 de agosto de 2026.
- Software and AI Agent Identity and Authorization — NIST NCCoE — Estudia enfoques basados en estándares para identificar a los agentes y autorizar su acceso y sus acciones. Estado revisado el 11 de septiembre de 2026.
- M-Trends 2026 — Mandiant — Aporta datos de las investigaciones de 2025 sobre la explotación de vulnerabilidades, la rapidez del traspaso entre atacantes y el papel de la IA en las intrusiones observadas. Revisado el 11 de septiembre de 2026.