# Aprobador de acciones de agentes de IA: responsabilidad por turno Un **aprobador de acciones de agentes de IA** debe ser la persona responsable del sistema afectado durante el turno correspondiente. No debería ser por defecto el desarrollador que casualmente abrió la sesión de programación. A menudo son personas distintas, y tratarlas como intercambiables produce aprobaciones que parecen legítimas hasta que algo sale mal en una llamada de producción. He visto que esto falla de la forma más habitual, sin sabotajes espectaculares. Un desarrollador pide a un agente que diagnostique un problema de compilación. El agente encuentra un endpoint de producción relacionado, solicita escribir en él para ajustar una configuración y el desarrollador aprueba porque la solicitud apareció en su terminal. El responsable del servicio descubre el cambio más tarde, durante su turno de guardia, sin contexto y sin una respuesta útil a «¿quién aceptó este riesgo?». La responsabilidad debe seguir al sistema, a su estado actual y a la persona que lleva el buscapersonas. Un diseño de aprobación útil hace visible ese hecho antes de ejecutar la acción. ## Quien inicia la sesión rara vez asume las consecuencias La persona que inicia un agente es responsable de la solicitud que escribió. Eso no significa que sea automáticamente responsable de la base de datos, la cuenta del proveedor, el destino del despliegue o los datos de clientes que el agente pueda tocar. La diferencia parece puntillosa hasta que una tarea de programación cruza una frontera. Un repositorio puede contener scripts de despliegue, credenciales operativas, herramientas de migración y enlaces a sistemas mantenidos por varios equipos. Un agente puede seguir esos caminos más rápido que una persona que conoce bien el repositorio. La familiaridad de quien lo inicia con una base de código no le concede autoridad operativa sobre todos los sistemas accesibles. Separa tres funciones en tu diseño: - El solicitante pide al agente que investigue, cambie o despliegue algo. - El responsable del sistema acepta el riesgo operativo del servicio objetivo durante su turno asignado. - El ejecutor tiene la capacidad de realizar la llamada o el comando después de la autorización. En un equipo pequeño, una misma persona puede desempeñar las tres funciones. No pasa nada si queda explícito. El error consiste en fusionarlas en silencio porque el agente se ejecuta en el ordenador de un desarrollador. Esto también aclara una discusión frecuente: «El desarrollador es responsable de su agente». Es responsable de dirigirlo y del código que entrega. La persona de guardia es responsable del comportamiento del servicio, del tratamiento de datos, de las decisiones de reversión y del impacto en los clientes. La solicitud de permiso debe llegar a quien puede tomar esa segunda decisión. NIST SP 800-53 Rev. 5, control AC-2, exige designar responsables de cuentas y establecer procedimientos de gestión de cuentas. No prescribe una pantalla de aprobación para agentes, pero la disciplina subyacente encaja bien: asigna la responsabilidad del acceso en lugar de tratarlo como una propiedad ambiental de quien esté conectado en ese momento. En el caso de las acciones de agentes, el responsable de la cuenta suele ser la persona responsable actual del servicio, no el usuario del equipo de trabajo. ## La responsabilidad del servicio debe incluir el límite del turno Un registro de responsabilidad duradero indica tanto el servicio como la persona responsable en ese momento. El nombre estático de un equipo no basta a las 02:00, durante una ausencia o en mitad de un incidente. Para cada sistema que pueda afectar un agente, conserva un pequeño cuadrante con cuatro campos: el equipo responsable principal, la persona responsable del turno activo, un suplente y una vía de escalado. El cuadrante puede estar en un sistema de guardias, un repositorio o un directorio interno. Importa menos dónde está que si se mantiene actualizado y si el sistema de aprobación puede consultarlo. Usa el límite del servicio que emplean los operadores cuando reciben una alerta. «Producción de Payments API» es un objetivo útil. «Backend» no lo es. Una etiqueta de equipo demasiado amplia oculta distintas bases de datos, proveedores, clasificaciones de datos y procedimientos de reversión. Un registro mínimo puede tener este aspecto: ```yaml service: billing-api-production active_owner: billing-oncall backup_owner: payments-duty-manager escalation: incident-commander approval_rules: read_customer_records: session change_remote_configuration: per_call production_database_write: per_call create_vendor_credentials: prohibited ``` Esto no es un lenguaje de políticas que deba interpretar un agente. Es una declaración, propiedad de personas, sobre quién puede tomar decisiones y cuánta revisión necesita una acción. Evita un fallo conocido: una solicitud de aprobación llega a un canal general de ingeniería, alguien reconoce el nombre del repositorio y nadie reconoce el sistema de producción que hay detrás. Trata el cuadrante como datos operativos. Una reorganización del equipo, un nuevo servicio gestionado o un cambio en la rotación de guardias pueden dejarlo obsoleto. Si el enrutamiento de aprobaciones depende de una hoja de cálculo que solo puede editar un responsable, has creado un único punto de fallo silencioso. ## El riesgo de una acción depende del objetivo, no del verbo «Leer» y «escribir» son categorías demasiado rudimentarias para asignar derechos de aprobación. Una lectura de un endpoint público de estado es distinta de una lectura que devuelve una exportación de clientes, un secreto de despliegue o una lista completa de hosts internos. Una escritura que crea una rama temporal es distinta de otra que cambia una configuración del proveedor de pagos. Clasifica las acciones según las consecuencias de un resultado correcto. Empieza por el sistema y los datos objetivo, y después considera si la acción puede revertirse y cuál es su radio de impacto. Así, los responsables cuentan con una base útil para elegir el alcance de la aprobación. Un conjunto práctico de categorías puede ser pequeño: - Las lecturas operativas rutinarias no devuelven material sensible ni cambian el estado. - Los cambios delimitados afectan a un recurso conocido y tienen una reversión documentada. - Los cambios de alto impacto afectan a la configuración de producción, los datos de clientes, el acceso o compromisos externos. - Las acciones prohibidas nunca deben ejecutarse a través de un canal de agente autónomo. No etiquetes una acción como de bajo riesgo porque el método HTTP sea GET. He visto endpoints de diagnóstico devolver variables de entorno, enlaces firmados y detalles operativos que nunca deberían haber llegado a un agente de programación. La persona responsable que conoce el endpoint debe clasificarlo. Del mismo modo, no exijas una confirmación manual para cada comprobación de estado inofensiva. Ese diseño crea fatiga de aprobación. Con el tiempo, la gente hace clic en una solicitud rutinaria porque espera que lo sea y termina aprobando la llamada que no era rutinaria. Reserva la aprobación por llamada para las credenciales y los objetivos en los que cada ejecución merece una decisión deliberada. El texto de aprobación debe identificar el objetivo concreto. «El agente solicita acceso a la API» no dice nada a la persona responsable. «El proceso del agente solicita PATCH a la configuración de facturación en producción usando la credencial billing-admin» le da información suficiente para detenerse y plantear las preguntas correctas. ## Una sesión delimitada no es un cheque en blanco Una aprobación de sesión debe cubrir un único proceso de agente identificable durante un periodo definido, no todos los procesos futuros iniciados desde el mismo repositorio o la misma cuenta de usuario. Esta diferencia importa cuando un terminal permanece abierto durante un cambio de turno, cuando un desarrollador reinicia un agente después de cambiar sus instrucciones o cuando un proceso local malicioso imita un comando conocido. Una aprobación vinculada solo a la identidad de usuario es demasiado amplia. Una aprobación vinculada a un proceso sin una identidad clara se puede interpretar fácilmente de forma errónea. Una buena aprobación de sesión responde en lenguaje sencillo a cinco cuestiones: qué proceso la solicitó, quién firmó o proporcionó ese proceso, qué canal de acción puede usar, qué alcance de servicio se aplica y cuándo termina el permiso. La sesión debe finalizar cuando termina el proceso. Un proceso nuevo merece una decisión nueva. La autorización por sesión de Sallyport sigue este patrón: muestra la autoridad de firma de código del proceso solicitante y aprueba esa ejecución solo hasta que termina. Es un valor predeterminado mejor que confiar en una pestaña del terminal, porque una pestaña del terminal no es un límite de identidad. Mantén las credenciales de alto impacto fuera de la concesión de sesión. Una escritura en una base de datos de producción o un cambio de acceso de un proveedor debe solicitar la aprobación de la persona responsable actual en cada uso, aunque haya aprobado la sesión de diagnóstico del agente diez minutos antes. La primera aprobación dice: «Este proceso puede trabajar con este sistema». La siguiente dice: «Acepto exactamente esta acción irreversible o sensible». Son decisiones distintas. Evita las aprobaciones permanentes con etiquetas como «herramientas del desarrollador». Se convierten en depósitos invisibles de permisos. También complican la revisión de incidentes, porque nadie puede saber si la persona que aprobó esperaba que ese agente concreto utilizara esa capacidad. ## El cambio de turno debe transferir autoridad, no solo información Un mensaje de traspaso que dice «Alex está de guardia ahora» no corrige las aprobaciones de agentes si las sesiones y aprobaciones de ayer siguen funcionando bajo la responsabilidad anterior. La persona saliente debe entregar el trabajo activo de los agentes igual que entrega una alerta parcialmente mitigada. Registra la identidad del proceso, los servicios objetivo, el alcance solicitado, la caducidad y las acciones pendientes de confirmación. La persona entrante debe poder ver ese registro antes de aceptar el turno. Usa esta secuencia para el traspaso: 1. Termina o revoca las sesiones que la persona saliente ya no quiera respaldar. 2. Enumera las sesiones activas que deban continuar, con su objetivo y caducidad. 3. Transfiere el cuadrante de servicios a la persona entrante y confirma su vía de notificación. 4. Exige que la persona entrante tome decisiones nuevas para las llamadas de alto impacto. No transfieras una aprobación amplia de un turno a otro solo porque la tarea de ingeniería no haya terminado. La persona entrante puede tener un contexto distinto del incidente, otras limitaciones de mantenimiento o información sobre un problema activo con un proveedor. Su aprobación debe ser propia. El caso más incómodo es una acción que ya está en curso durante el cambio de turno. Si se puede revertir y observar, deja que termine con la autorización registrada y haz visible el resultado para la nueva persona responsable. Si es destructiva, visible externamente o está esperando una segunda llamada, detenla en el límite y vuelve a preguntar. Unos minutos de retraso cuestan menos que hacer que una persona desconocida herede un cambio de producción no revisado. ## Los incidentes necesitan una autoridad más estrecha, no una memoria más permisiva Durante un incidente, los equipos necesitan velocidad. A menudo responden concediendo a un agente un permiso amplio y prolongado para «ayudar a arreglar producción». Ese permiso sobrevivirá a la urgencia y acabará convirtiéndose en un agujero sin explicación. Asigna la aprobación al comandante del incidente o a la persona que este haya delegado formalmente para el sistema afectado. La persona responsable habitual de la guardia debería seguir involucrada cuando sea posible, pero un incidente necesita una única persona que tome decisiones cuando varios equipos trabajan con la misma dependencia. Escribe la referencia del incidente en el registro de aprobación. Limita el alcance al servicio y a la acción de corrección. Establece una caducidad breve que coincida con el trabajo y ciérrala o revócala cuando termine el incidente. Imagina un agente al que se pide mitigar una cola descontrolada. Inspecciona las métricas, propone un cambio de configuración y solicita un comando que elimine mensajes. El comandante del incidente puede aprobar un ajuste temporal de concurrencia después de revisar la reversión. No debería aprobar el borrado de mensajes solo porque sea rápido. La solicitud debe indicar claramente qué cola y qué mensajes están afectados, qué vía de recuperación existe y si los clientes perderán trabajo. La velocidad nace de vías de autoridad preparadas, responsables claros y solicitudes legibles. No nace de convertir a cada persona que responde en administrador de producción durante una tarde. ## Las solicitudes de aprobación deben obligar a tomar una decisión útil Una solicitud falla cuando una persona responsable competente no puede saber en pocos segundos qué está aprobando. También falla cuando exige un análisis de seguridad nuevo para una acción habitual. Debe mostrar los puntos de decisión que esa persona ya utiliza durante las operaciones normales. Incluye la identidad del solicitante, la identidad del proceso del agente, el canal de acción, la etiqueta de la credencial, el objetivo, la operación y el alcance. Para un comando, muestra el comando exacto y el host remoto. Para una llamada HTTP, muestra el método, el host, la ruta y una descripción segura del cuerpo. Nunca muestres el secreto como prueba de que la credencial existe. Esta es la diferencia entre una solicitud útil y una inútil: ```text Request: production configuration change Process: signed coding-agent process, session 8f3a Owner: billing-oncall Credential: billing-admin Action: PATCH https://api.internal.example/v1/routing/default Body: {"provider":"secondary"} Scope: one call Reason supplied: mitigate provider timeout during INC-482 ``` Una solicitud que solo dice «¿Permitir acceso a la herramienta?» empuja a la persona responsable a aprobar por rutina. No le dice ni cuál es el objetivo ni cuál será el efecto. Si tus herramientas no pueden ofrecer suficiente contexto para decidir, deben denegar la acción hasta que el solicitante lo proporcione. No pongas un campo de texto libre llamado «motivo» al frente de la seguridad. Los agentes pueden generar prosa persuasiva con facilidad. Trata el motivo como contexto para la persona, mientras el sistema aplica el objetivo, la credencial y el alcance de la aprobación. ## Los registros de auditoría deben responder a las preguntas incómodas Después de un cambio inesperado, la gente pregunta quién lo aprobó, qué proceso lo realizó, qué credencial utilizó, a qué objetivo llegó y si alguien modificó el registro después. Un registro de auditoría que no pueda responder a todas esas preguntas solo sirve como ayuda para depurar. Mantén separadas las decisiones de sesión de los eventos de acciones individuales, pero conéctalas. El registro de sesión establece la identidad del proceso y de la persona que aprobó. El registro de actividad establece cada llamada o comando y su resultado. Incluye las denegaciones y las revocaciones. Los intentos fallidos suelen explicar una solución posterior o revelar que un proceso estaba explorando los límites. Haz que el registro permita detectar manipulaciones. Un registro encadenado mediante hashes hace detectables las eliminaciones y modificaciones cuando alguien puede verificar la cadena de forma independiente. No convierte una mala aprobación en una buena y tampoco sustituye a los controles de acceso. Da a los investigadores una forma de comprobar si el historial sigue coincidiendo con la secuencia registrada. Sallyport proyecta los diarios de sesión y actividad desde un registro cifrado, encadenado mediante hashes y ciego a la escritura, y `sp audit verify` puede verificar la cadena sin conexión sobre el texto cifrado. Este diseño resulta útil porque la persona revisora no necesita acceder a los secretos operativos para comprobar la integridad del registro. No escondas las acciones de los agentes en registros de aplicación genéricos. Esos registros suelen omitir la decisión humana, rotar demasiado rápido y mezclar ruido sin relación con el rastro de eventos. Conserva un registro que una persona de guardia, un revisor de seguridad y un comandante de incidente puedan leer sin reconstruir una historia a partir de seis sistemas. ## Los fallos de responsabilidad suelen empezar con una excepción cómoda El patrón peligroso comienza con un atajo razonable. Un desarrollador sénior necesita terminar una migración. La persona responsable del servicio está en otra zona horaria. Alguien añade un grupo de aprobación general, concede una credencial reutilizable o mantiene una sesión abierta durante el fin de semana. La excepción funciona y se convierte en el proceso no oficial. Después el agente recibe una tarea más amplia. Puede alcanzar más objetivos de los que necesitaba la solicitud original. El desarrollador puede estar dormido, la persona responsable puede haber cambiado de turno y el grupo amplio puede suponer que otra persona revisó la solicitud. Cada decisión individual parecía defendible. En conjunto, eliminaron la responsabilidad. Corrige esto haciendo que las excepciones sean estructuradas en lugar de informales. Una excepción debe indicar un servicio, una persona aprobadora, un motivo, una hora de finalización y un punto de revisión. Debe producir un registro visible. No debe ampliar en silencio los permisos permanentes de un desarrollador. Resiste la recomendación habitual de resolverlo con un motor de reglas enorme. Las reglas resultan atractivas porque los equipos imaginan que pueden codificar cada repositorio, rama, endpoint, franja horaria y cargo. En la práctica, nadie puede explicar por qué una llamada concreta coincidió con una regla, y las reglas obsoletas se convierten en permisos que nadie pretendía conservar. Empieza con un modelo de decisión pequeño: acceso al almacén, una decisión de sesión delimitada y confirmación por llamada para las acciones que lo merezcan. Ese modelo obliga a resolver la parte difícil en lenguaje sencillo: ¿quién es responsable de este sistema ahora y qué está dispuesto exactamente a autorizar? ## Pon a prueba el modelo de responsabilidad durante un turno real Puedes encontrar la mayoría de los fallos de diseño antes de un incidente grave con un ejercicio controlado. Usa un sistema que no sea de producción pero se parezca a un servicio con una rotación de guardias real. Inicia una sesión de agente cerca de un cambio de turno planificado, solicita una lectura rutinaria y después solicita un cambio que necesite confirmación individual. Observa los puntos en los que la gente duda. ¿Puede la persona saliente ver las sesiones activas? ¿Sabe la persona entrante qué servicio controla ahora? ¿La solicitud de aprobación identifica el proceso y el objetivo? ¿Puede cualquiera de las dos revocar la sesión? ¿El registro de auditoría muestra, en orden, las acciones denegadas, aprobadas y ejecutadas? No aceptes como respuesta «lo resolveríamos en el chat». El chat sirve para coordinarse, pero no establece un límite de decisión ni conserva el registro completo de acciones. Un traspaso que depende de la memoria fallará durante la noche más intensa. Empieza escribiendo quién es el responsable activo y quién es el suplente del primer servicio de producción que puedan tocar tus agentes. Después haz que un agente solicite una acción delimitada contra ese servicio. Si no puedes identificar a la persona que debería aprobar esa llamada sin preguntar a varias personas, el agente ha llegado a producción antes que tu modelo de responsabilidad.