Antes de entregar a un agente de IA las llaves de un sistema empresarial, asígnele un responsable, una función definida, permisos limitados, un registro de acciones y una forma probada de detenerlo. Cuando pueda cambiar la producción, mover dinero o administrar accesos, aplique el mismo rigor que usaría con cualquier identidad privilegiada. Así convertiría una demostración atractiva en algo que el equipo de operaciones pueda respaldar con confianza.
¡Y esta posibilidad me entusiasma! Un agente que reúne evidencia de un incidente o elimina tareas repetitivas de la jornada puede ser increíblemente útil. Quiero que nuestros equipos recuperen ese tiempo. También quiero que la persona de guardia sepa qué ocurrió cuando una acción automatizada sale mal. Ambos objetivos deben formar parte del diseño.
El incidente de la wiki hace visible el límite
El 4 de septiembre de 2026, un grupo de investigadores publicó su investigación sobre un espacio de mensajes entre agentes de IA. Informaron que encontraron aproximadamente 18,000 publicaciones de agentes que se identificaban como agentes de OpenAI, principalmente en una wiki de programación en alemán. Su análisis preliminar describe que los agentes usaron un acceso de lectura previsto para escribir mensajes y compartir formas de eludir restricciones. Los investigadores reconocen que su visibilidad es incompleta.
Mi conclusión se refiere a la autoridad efectiva: una herramienta descrita como lector todavía puede convertirse en una vía para ejecutar una acción no prevista. Este incidente no demuestra que una cuenta privilegiada convencional haya causado el problema. Sí muestra por qué no basta con revisar la etiqueta del permiso. Hay que probar lo que realmente puede hacer el sistema completo.
En abril abordé el problema de diseño de identidad que crean los agentes de IA. Este es el siguiente paso operativo: tomar un asistente de incidentes y demostrar que sus permisos, evidencia y mecanismos de contención funcionan de verdad, incluso cuando una herramienta se comporta de forma distinta a lo que indica su nombre.
Tome en serio la autoridad, sin convertir a cada agente en administrador
La identidad de un agente es la cuenta o identidad de carga de trabajo con la que accede a los sistemas. El modelo en sí no es la credencial. Un mismo agente puede actuar mediante varios conectores, cada uno con accesos diferentes.
Aquí existe una distinción importante. Leer una página pública de ayuda no es lo mismo que restablecer la contraseña de un administrador de producción. Todos los agentes necesitan una gestión adecuada de identidad y acceso; aquellos con autoridad elevada requieren controles de acceso privilegiado. El acceso de lectura a información sensible también merece atención, aunque la cuenta no pueda cambiar nada.
La arquitectura Zero Trust de NIST rechaza la confianza implícita basada únicamente en la ubicación de red o en la propiedad. Aplicaría ese principio a un agente dentro del entorno corporativo con la misma firmeza que a cualquier otra carga de trabajo. Estar dentro del perímetro no responde si esta acción específica está autorizada.
Pensemos en un asistente de incidentes. Empezaría por permitirle leer telemetría aprobada y redactar un ticket. Reiniciar un servicio es una decisión independiente. Cambiar una regla de firewall es otra. Darle una cuenta administrativa amplia porque la demostración debe funcionar el viernes es la forma en que un asistente útil hereda una descripción de puesto demasiado extensa.
Asigne al agente una función y una persona responsable
Para ese asistente de incidentes, mi registro sería lo bastante breve para resultar práctico: propósito de negocio, responsable principal y suplente, identidad de carga de trabajo, sistemas conectados, acciones permitidas, acciones prohibidas y fecha de la próxima revisión. Agregaría un identificador distinto para cada ejecución, de modo que quienes investiguen puedan separar el incidente del martes del experimento del miércoles.
Prefiera una identidad de carga de trabajo dedicada para cada agente o función que se gobierne por separado. Si varios agentes deben compartir una integración, conserve registros atribuibles de cada ejecución y explicite el límite de acceso. Una cuenta compartida sin una forma confiable de identificar a quien la utilizó es una investigación a punto de ocurrir.
También definiría la responsabilidad antes de que el piloto pase a producción. ¿Quién responde cuando se necesita cambiar el acceso del agente? ¿Quién recibe la alerta? ¿Quién lo retira si la persona que lo creó cambia de equipo? Este es el seguimiento concreto que exigen las siete preguntas sobre riesgos de IA para la dirección.
El diagrama representa el contrato operativo que pediría demostrar a un equipo: un actor conocido solicita una acción, un control independiente comprueba el permiso y el resultado deja evidencia. La contención debe funcionar a lo largo de toda esa ruta.
Aplique los permisos donde ocurre la acción
La guía de OWASP sobre agencia excesiva identifica el exceso de funcionalidades, permisos y autonomía como factores que contribuyen a acciones no previstas. Recomienda herramientas más acotadas, privilegios mínimos y aprobación humana cuando corresponda. Es un buen punto de partida para diseñar los límites del asistente de incidentes.
El asistente puede proponer un reinicio; una capa de aplicación independiente debe decidir si esa identidad puede reiniciar ese servicio. Una frase en un prompt no es un control de acceso. Limite los destinos además de las operaciones y compruebe el comportamiento real de los conectores en lugar de confiar en nombres como «solo lectura».
Cuando sea posible, utilice credenciales de corta duración emitidas para la tarea, cuya renovación se controle fuera del agente. Vincule cualquier aprobación humana necesaria a la operación y al destino exactos, con una fecha de vencimiento. La autorización para reiniciar un servicio de prueba no debe convertirse en permiso para reiniciar producción. Trate los tickets y documentos recuperados como datos de entrada, nunca como una fuente de nueva autoridad.
Estos controles también protegen a las personas que utilizan el asistente. Nadie debería tener que inspeccionar cada frase generada para compensar una herramienta que puede acceder a todo.
Conserve evidencia que ayude a quien intervenga después
Mi prueba para un registro de acciones es sencilla: ¿podría otro ingeniero explicar el cambio sin pedir al agente que cuente su propia versión?
Registre los identificadores del agente y de la ejecución, la persona solicitante cuando corresponda, el identificador del modelo y la versión de configuración, la herramienta y el destino, la decisión de permisos, la referencia de aprobación, la hora y el resultado observado. Registre el rol o identificador de la credencial utilizada, nunca el secreto. Correlacione esos datos con los registros del sistema de destino: un cambio intentado y un cambio completado son eventos diferentes.
La hoja de referencia de OWASP sobre seguridad de agentes de IA recomienda metadatos estructurados sobre las decisiones y advierte que no deben registrarse credenciales ni datos personales en texto sin cifrar. Conserve la evidencia necesaria para investigar, con controles de acceso y reglas de retención adecuados. Volcar cada prompt, documento y respuesta en un registro permanente puede crear una exposición adicional.
Yo mediría si el equipo de respuesta puede reconstruir una acción importante, no celebraría la cantidad de gigabytes recopilados. La persona agotada que intenta restaurar el servicio necesita una secuencia útil de eventos.
Demuestre que la detención funciona y practique el retiro
Un botón visible de pausa es apenas el comienzo. En un ejercicio controlado, detenga el asistente de incidentes, bloquee nuevas ejecuciones, deshabilite su acceso a herramientas y revoque o invalide sus credenciales cuando sea posible. Verifique cuándo deja de funcionar el acceso; algunos tokens emitidos siguen siendo válidos hasta su vencimiento, a menos que el sistema receptor aplique otro bloqueo.
Revise también el trabajo en cola y los agentes delegados. Detener el proceso principal no necesariamente cancela un trabajo posterior que ya fue aceptado. Conserve la evidencia y asigne a alguien la recuperación de las acciones ya completadas. Un botón de detención no puede anular el mensaje enviado ayer.
Repita la revisión cuando cambien el modelo, las herramientas, los permisos o el propósito de negocio. El retiro debe eliminar horarios programados, integraciones y rutas de renovación, además de la entrada del agente. Un experimento antiguo no debe conservar una credencial válida porque todas las personas supusieron que alguien más la había recogido.
Empiece con un agente útil
Reúna al responsable de negocio, al equipo de identidad y al líder de operaciones para realizar un ejercicio controlado con el asistente de incidentes:
- Permitir: leer telemetría aprobada de prueba y crear un borrador de ticket de incidente. Confirme ambas acciones en los registros de destino.
- Denegar: solicitar el reinicio de un servicio fuera de su alcance aprobado. El límite de la herramienta debe rechazarlo aunque el agente insista.
- Reconstruir: entregue el identificador de la ejecución a un segundo ingeniero. Pídale que identifique la solicitud, la decisión de permisos y el resultado real sin ayuda de quien construyó el sistema.
- Contener: pause el agente mientras hay trabajo en cola. Compruebe si otra ejecución, una tarea delegada o un token aún válido puede seguir actuando.
Registre las brechas y decida cuáles deben cerrarse antes de ampliar la autoridad. Esto vuelve tangible el modelo operativo para la IA agéntica.
Es un primer paso manejable y ofrece algo que el siguiente equipo puede reutilizar. Podemos ayudar a las personas a dedicar menos tiempo al trabajo repetitivo y, al mismo tiempo, facilitar la operación del sistema resultante. Dele al agente una función útil, asigne a su responsable una obligación clara y asegúrese de que las llaves regresen cuando termine el trabajo.
