Tu agente no debería usar tu contraseña: identidad, mínimo privilegio y entornos aislados
Cuando un agente opera con la credencial de una persona, la trazabilidad es ficción y la revocación es imposible. Dar identidad propia a cada agente es la decisión de seguridad más barata y menos tomada de la adopción de IA.
Hay un patrón que se repite en casi todas las organizaciones que empiezan a desplegar agentes, y es tan común que ya casi no llama la atención: el agente opera con las credenciales de la persona que lo configuró. Alguien de tecnología conecta el agente a la base de datos con su propio usuario, o crea una cuenta de servicio genérica con permisos amplios porque era lo más rápido, y el sistema funciona.
Funciona hasta que alguien tiene que responder tres preguntas: quién hizo este cambio, cómo lo revocamos sin bloquear a una persona, y qué más podía tocar este agente que no sabíamos.
Por qué la identidad compartida rompe todo lo demás
La identidad no es un detalle de implementación. Es el cimiento sobre el que se apoyan la trazabilidad, la revocación y el control de acceso. Cuando esa identidad es compartida, las tres cosas se caen a la vez.
La trazabilidad se vuelve ficción. El registro dice que la usuaria María modificó cuarenta y siete registros el martes a las tres de la mañana. María estaba durmiendo. El registro es técnicamente correcto e informativamente inútil: no distingue lo que hizo la persona de lo que hizo el agente que corre con su credencial. Cualquier auditoría que dependa de ese registro produce conclusiones falsas.
La revocación se vuelve un dilema. El agente empieza a comportarse mal y hay que cortarlo. Si comparte credencial con una persona, cortarlo significa bloquear a esa persona. Si comparte una cuenta de servicio con otros tres procesos, cortarlo significa detener los otros tres. La respuesta habitual ante ese dilema es no cortar nada y “vigilarlo un rato”, que es exactamente la peor decisión disponible.
El control de acceso pierde granularidad. Un agente que hereda los permisos de un administrador tiene acceso a todo lo que ese administrador puede tocar, incluido lo que nunca necesitó. El principio de mínimo privilegio no se puede aplicar sobre una identidad que ya está diseñada para el máximo.
Identidad propia: qué significa concretamente
Dar identidad propia a un agente significa que existe una entidad en tu sistema de gestión de identidades que representa a ese agente y solo a ese agente. Tiene nombre, tiene dueño humano designado, tiene permisos asignados explícitamente, tiene fecha de creación y puede tener fecha de expiración.
Con eso resuelto aparecen capacidades que antes no existían:
- Los registros distinguen acciones de personas de acciones de agentes.
- Se puede revocar un agente sin efecto colateral sobre nadie más.
- Se pueden asignar permisos a la medida exacta de la tarea.
- Se puede auditar qué agentes existen, quién los creó y qué pueden tocar.
- Se puede detectar un agente que dejó de usarse y sigue con acceso vivo.
Ese último punto merece énfasis. Los agentes huérfanos —creados para un piloto que terminó, con credenciales activas y sin dueño— son una de las superficies de riesgo que más rápido crece en organizaciones que están experimentando. Sin identidad propia son literalmente invisibles.
Mínimo privilegio, con lectura y escritura separadas
El segundo principio es más conocido y peor aplicado: cada agente debe tener acceso exactamente a lo que necesita para su tarea, y nada más.
La distinción que más rinde en la práctica es separar lectura de escritura. Son permisos de naturaleza completamente distinta. Un agente que puede leer el catálogo de productos y proponer una actualización de precios es un asistente. El mismo agente con permiso de escritura sobre ese catálogo es un actor con capacidad de causar daño comercial directo. La diferencia entre ambos no es de modelo ni de prompt: es de una línea de configuración de permisos que alguien tiene que tomarse el trabajo de escribir.
Hay una lista corta de decisiones que conviene tomar explícitamente para cada agente:
- Qué fuentes de datos puede leer, con qué granularidad.
- Qué sistemas puede modificar, y sobre qué subconjunto.
- Qué herramientas puede invocar, en una lista permitida explícita, no en una exclusión de las prohibidas.
- Qué acciones están bloqueadas incondicionalmente, aunque el agente tenga permiso técnico.
- Qué límite de consumo tiene por tarea y por período.
La diferencia entre lista permitida y lista prohibida no es semántica. Una lista prohibida asume que conoces todas las formas en que algo puede salir mal. Una lista permitida asume que no.
Entornos aislados: donde el error es barato
El tercer elemento es el entorno. Un agente que opera directamente sobre producción convierte cada error en un incidente. Un agente que opera sobre un entorno aislado convierte cada error en información.
El aislamiento tiene varias dimensiones que conviene no confundir. Aislamiento de datos: el agente trabaja sobre una copia o sobre un subconjunto, no sobre el registro vivo. Aislamiento de ejecución: el proceso corre en un contenedor con recursos y red acotados. Aislamiento de efectos: las acciones se acumulan en una propuesta que un humano o una validación automática aprueba antes de aplicarse.
Ese tercer tipo —el aislamiento de efectos— es el más útil y el menos implementado. Convierte una acción irreversible en una propuesta revisable, sin cambiar nada del modelo ni del agente. Es puro diseño de flujo.
El costo real de no hacerlo
La objeción habitual a todo esto es que agrega fricción a algo que la organización necesita mover rápido. Es una objeción legítima y tiene una respuesta concreta: el trabajo de dar identidad, acotar permisos y aislar entornos se hace una vez por plataforma, no una vez por agente.
Si tu organización configura esto bien para el primer agente, el segundo hereda la estructura. Si lo configura mal para el primero, el segundo hereda el desorden, y el décimo hereda un problema de seguridad que ya nadie sabe desenredar porque las credenciales están enmarañadas entre procesos, personas y pilotos abandonados.
La pregunta operativa no es si vas a hacer este trabajo. Es si lo vas a hacer ahora, con tres agentes y bajo tus propios términos, o dentro de dieciocho meses, con treinta agentes y bajo los términos de un auditor.
El ciclo de vida que casi nadie define
Dar identidad a un agente resuelve el momento inicial. Queda el resto de su vida, y ahí es donde se acumula el desorden.
Un agente pasa por etapas que conviene tratar explícitamente, porque cada transición es un punto donde los permisos deberían revisarse y casi nunca se revisan.
Creación. Se define la identidad, se asignan permisos mínimos, se registra el dueño y se establece una fecha de revisión. Ese último campo es el que más rinde: sin fecha de revisión, la revisión no ocurre.
Cambio de alcance. El agente empieza a hacer algo que no hacía. Es el momento en que los permisos crecen, normalmente por adición y sin que nadie quite lo que dejó de usarse. La práctica correcta es revisar el conjunto completo en cada ampliación, no solo agregar.
Cambio de dueño. La persona responsable cambia de rol o deja la organización. Si la transferencia de responsabilidad no es explícita, el agente queda huérfano sin que nadie lo note, porque sigue funcionando.
Suspensión. El agente se detiene temporalmente. La pregunta relevante es qué pasa con sus credenciales durante la suspensión. Lo habitual es que sigan activas, lo cual convierte una pausa operativa en una exposición sin supervisión.
Retiro. El agente deja de usarse. Aquí es donde se produce el mayor volumen de riesgo acumulado, porque la mayoría de los pilotos terminan sin ninguna acción de retiro: simplemente dejan de ejecutarse, y las credenciales quedan vivas.
Un procedimiento de retiro completo tiene cuatro pasos: revocar credenciales, eliminar la identidad del sistema de gestión de accesos, archivar las trazas según la política de retención y registrar el retiro en el inventario. Toma quince minutos y prácticamente nunca se hace, porque nadie lo tiene asignado.
La forma más simple de forzarlo es la fecha de expiración por defecto. Todo agente creado para un piloto recibe credenciales que expiran en noventa días. Si el piloto continúa, alguien renueva conscientemente. Si no, el agente se apaga solo. Esa única decisión de configuración elimina la categoría entera de agentes huérfanos, sin depender de que nadie recuerde nada.
Una prueba de dos minutos
Haz esta pregunta a quien administre tus accesos: ¿puedes darme la lista de identidades no humanas activas en nuestros sistemas, con su dueño y sus permisos?
Si la respuesta llega en minutos, tu organización tiene control. Si la respuesta es “habría que revisarlo”, tienes agentes operando y no sabes cuáles ni con qué alcance. Ese es el punto de partida real, y reconocerlo es más útil que cualquier política que se escriba encima.