Cuando un agente de inteligencia artificial crea una red virtual, bases de datos o un equilibrador de carga, el problema no termina cuando concluye la tarea. El recurso puede permanecer en funcionamiento, consumir presupuesto y requerir mantenimiento, mientras que la etiqueta de propiedad apunta a una identidad automatizada como deploy-agent, y no a una persona con la que se pueda contactar o a la que se pueda exigir responsabilidad por el recurso.
El artículo plantea esta cuestión como una brecha de gobernanza en la infraestructura de nube: la identidad de ejecución que creó el recurso no es necesariamente su propietario real. A medida que aumenta el número de agentes y la velocidad con la que se crean, los mecanismos tradicionales de propiedad basados en empleados dejan de ser suficientes.
Descubrir los recursos propiedad de agentes
El primer paso es inventariar los recursos que tienen una etiqueta de propietario y comparar el valor de esa etiqueta con el directorio de identidades de la organización. En AWS y Azure se puede cotejar la etiqueta con los registros de roles o entidades de servicio originales. En Google Cloud, el artículo propone comprobar que el valor del propietario exista en el directorio de empleados; si no existe, no es una identidad humana según la regla de comprobación utilizada.
La aparición de una identidad automatizada no significa que el recurso sea ilegítimo; la automatización puede estar diseñada para operar la infraestructura en nombre de la organización. Sin embargo, esta comprobación reduce el alcance de la revisión a los recursos que realmente necesitan que se les asigne un propietario humano.
¿Qué cambia en la práctica?
En lugar de aceptar automáticamente como propietario a la persona o cuenta que ejecutó el plan de despliegue, la política de aprobación debería verificar la propia etiqueta de propiedad. La regla propuesta establece que no debe aprobarse ningún despliegue si el recurso susceptible de etiquetado no tiene propietario, si el valor del propietario no tiene el formato de una dirección de correo electrónico de una persona o si coincide con una de las identidades de agentes conocidas.
El artículo recomienda mantener la lista de identidades de agentes en un archivo JSON que se transmita al motor de políticas. Si falta la lista, la política debe fallar de forma cerrada en lugar de permitir el despliegue sin comprobación. También advierte contra el uso de claves de API con permisos administrativos; propone conceder a cada agente una clave de tipo User dentro de un equipo independiente y con permisos limitados sobre el entorno en el que opera, evitando los tokens compartidos.
Establecer el fin de la vida útil de los entornos
Las políticas de despliegue no bastan para abordar los recursos antiguos que los agentes ya han creado. Por ello, el artículo propone utilizar un periodo de caducidad para el entorno, de modo que una persona cree el entorno y establezca su duración, mientras el agente ejecuta el despliegue dentro de él. De esta forma, las alertas de vencimiento llegan a una entidad humana capaz de actuar, en lugar de enviarse a una identidad automatizada que no tiene buzón de correo.
El artículo señala que env zero avisa al creador del entorno antes de destruirlo automáticamente en dos momentos: dos días y dos horas y treinta minutos. También menciona un modelo de Axiom que elimina automáticamente la cuenta si no se reclama en un plazo de 24 horas.
¿Por qué es importante esta noticia?
El artículo relaciona la expansión del problema con la multiplicación del número de agentes dentro de las organizaciones. Según una encuesta de Gravitee de 2026, el número medio de agentes empresariales se duplicó aproximadamente en cuatro meses, entre diciembre de 2025 y abril de 2026, mientras que más de un tercio de las organizaciones operaba más de 100 agentes. Las encuestas realizadas por Larridin también encontraron una media de 47 agentes en entornos empresariales sin un propietario asignado.
La investigación se vuelve más difícil cuando los agentes utilizan una cuenta de servicio compartida; el registro puede demostrar que se creó el recurso, pero no aclara qué ejecución, solicitud o decisión lo provocó. Por ello, asignar explícitamente un propietario humano no solo aborda los costes, sino que también cierra parte de la brecha de responsabilidad en los registros de auditoría.
Las limitaciones pendientes también son claras: el éxito de estos controles depende de la precisión de los directorios de identidades, de que los agentes no eludan las políticas de permisos y de que exista una definición organizativa estable sobre quién posee realmente el recurso. La fuente es además un material instructivo patrocinado por env zero, por lo que sus recomendaciones específicas sobre productos deben considerarse soluciones propuestas y no el único estándar del mercado.