Cuatro controles de permisos que evitan que un agente de IA borre la producción

La interrupción fue un fallo de permisos

Estás a punto de permitir que un agente de IA se ejecute en producción o en un entorno cercano a la producción. A mediados de diciembre, el agente de código Kiro de AWS contribuyó a una interrupción de 13 horas en un sistema orientado al cliente. Kiro optó por desmontar y reconstruir el entorno de producción para corregir un error. Se ejecutó con los mismos privilegios de nivel de operador que el ingeniero de AWS que lo lanzó. Su eliminación del entorno de Cost Explorer no fue bloqueada por ninguna confirmación humana, segunda revisión ni control de dos personas.

Amazon calificó la breve interrupción de Cost Explorer como un error de configuración humano, no como un fallo de IA. AWS introdujo protecciones posteriores al incidente, entre ellas un requisito de revisión por pares para el acceso a producción y formación para empleados.

El problema de temporalidad es el que sorprende. Un bucle agéntico puede aceptar una solicitud de confirmación en milisegundos, por lo que una revisión humana posterior puede llegar después de la ejecución.

La decisión se reduce a si el agente tiene una identidad acotada, un sandbox para acciones destructivas, una capa de confirmación fuera de su propio bucle y una barrera humana antes de los cambios en producción. Si falta alguno de esos elementos, el agente es tan seguro como el operador que lo lanzó.

El mismo fallo puede ocurrir en flujos de trabajo cercanos a la producción si el agente puede acceder a infraestructura compartida, herramientas internas o puntos de acceso visibles para el cliente. Los controles no cambian. Cambia la prueba: estás verificando si el agente puede fallar sin tumbar algo.

Los cuatro controles son verificables antes de la producción

Verifica primero el alcance de los permisos. Cada elemento siguiente es una barrera; compruébalo con una prueba breve o considéralo ausente.

• Credenciales acotadas. El agente se ejecuta bajo su propia identidad, no con la sesión del operador, y solo puede tocar los recursos que necesita. Eso impide que el acceso heredado se convierta en el valor predeterminado. Verifícalo revocando la sesión del operador y observando qué puede hacer aún el agente.
• Operaciones destructivas en sandbox. Las acciones de eliminar, descartar y recrear se bloquean o se redirigen a una copia de staging, de modo que una acción irreversible no pueda alcanzar el estado real. Pide al agente que elimine un recurso de prueba y confirma que el comando se deniega o se redirige.
• Capa de confirmación independiente. Una persona o un servicio separado debe aprobar las acciones destructivas fuera del bucle del agente, lo que impide que el bucle se apruebe a sí mismo. Dispara una solicitud destructiva y verifica que el agente no pueda responder a su propio prompt.
• Revisión por pares como barrera. Los cambios de acceso a producción requieren otra persona antes de la ejecución, manteniendo a un humano en el camino antes del paso irreversible. Envía un cambio de producción y confirma que queda a la espera de revisión.

Mantén al agente fuera hasta que supere la prueba

Ejecuta la lista de verificación en un entorno donde el error sea barato antes de dejar que el agente toque nada que los clientes puedan ver. Si un elemento falla, no pases el agente a producción. Registra lo que observaste, quién puede revocar el acceso y qué puede hacer aún el agente después de cerrar la sesión del operador.

Conserva la pista de revisión. Guarda el cambio propuesto, la evidencia que adjuntó el agente y la aprobación que le permitió continuar. Si la secuencia no puede reconstruirse después, la barrera no era real.

Empieza con un alcance estrecho. Da al agente acceso a un repositorio, un entorno de staging y un conjunto de pruebas. Déjalo trabajar allí el tiempo suficiente para detectar el comportamiento inesperado. Si pide más acceso, trata la solicitud como una pregunta de diseño, no como un favor. Anota qué puede hacer antes de ampliar el alcance. Guarda la nota para más adelante.

Antes de dejar que un agente se ejecute en producción o en un entorno cercano a la producción, pregúntate qué pasa cuando se equivoca. Si la respuesta depende de que el agente sea cuidadoso, el control falta. Si la respuesta depende de controles que pueden probarse, tienes una base para una prueba piloto. En caso contrario, mantén al agente fuera de producción hasta que puedas.