Presupuesto de latencia de aprobación para acciones de agentes más seguras

Las aprobaciones de agentes fallan de dos maneras opuestas. Si haces que cada acción pida la intervención de una persona, el agente pasa el día esperando detrás de una cola de revisión. Si eliminas el punto de decisión porque la espera resulta molesta, el agente recibe una autoridad que nadie puede supervisar de forma realista.

Un presupuesto de latencia de aprobación evita ambos problemas. Indica cuánto puede tardar una decisión humana para una clase concreta de acción del agente, mide en qué se va ese tiempo y obliga a rediseñar el flujo cuando el trabajo rutinario no cabe en ese límite. El presupuesto no es un objetivo para que las personas hagan clic más rápido. Es una restricción para el flujo y para la autoridad que entregas al agente.

He visto equipos tratar una solicitud de aprobación como prueba de control y descubrir después que un desarrollador aprobaba veinte solicitudes casi idénticas mientras intentaba terminar su propio trabajo. Esa persona no estaba revisando. Funcionaba como un relé lento. La solución rara vez es una mejor notificación de recordatorio. Normalmente consiste en definir mejor la autoridad, reducir las llamadas innecesarias y establecer una ruta de escalado más clara para las acciones que merecen esa fricción.

Un presupuesto de latencia de aprobación es un plazo para una decisión humana

Un presupuesto de latencia de aprobación es el tiempo máximo aceptable entre el momento en que una solicitud queda lista para revisión y la decisión final de permitirla o denegarla. Debe variar según la clase de acción, porque leer una solicitud de cambios, crear un recurso temporal de prueba y modificar un permiso de acceso en producción no tienen la misma urgencia ni las mismas consecuencias.

Trata el presupuesto como parte del contrato de la acción. Si el agente necesita una respuesta en dos minutos para mantener una tarea interactiva en marcha, el sistema debe hacer que esa acción sea fácil de evaluar en dos minutos o evitar pedirla durante el trabajo normal. Si una tarea puede esperar sin peligro hasta la mañana siguiente, no finjas que necesita una interrupción inmediata.

El presupuesto tiene tres partes:

• Espera en cola: tiempo desde la creación de la solicitud hasta que un revisor la abre.
• Tiempo de decisión: tiempo desde que se abre la solicitud hasta que se permite o deniega.
• Tiempo de ejecución: tiempo desde la decisión hasta que la acción comienza o falla.

Muchos equipos combinan estas partes en una sola cifra y la llaman tiempo de aprobación. Eso oculta la solución. Una espera de veinte minutos en cola requiere cambios de enrutamiento, responsabilidad o programación. Veinte minutos de decisión indican que a la solicitud le falta contexto, contiene demasiada autoridad o pide un juicio que nunca debería haber llegado a una persona apurada.

Define los presupuestos según los plazos del trabajo, no según un nivel de seguridad abstracto. Una tabla inicial razonable podría ser esta:

Son ejemplos, no una política universal. Un equipo de despliegue con turnos de guardia puede necesitar una ventana distinta a la de un desarrollador independiente. Lo importante es definir la expectativa antes de que se forme la cola.

No uses un acuerdo de nivel de servicio para esto si no puedes dotarlo de personal. Un presupuesto es un límite de diseño. Te indica que una tarea no puede depender de una decisión interactiva si las personas capaces de decidir están durmiendo, en reuniones o atendiendo un incidente. El agente también debe saberlo. Puede preparar la solicitud, elegir una alternativa segura o detenerse con una explicación clara. No debería seguir enviando la misma solicitud cada minuto.

Mide el ciclo de vida de la solicitud, no solo un clic

No puedes mejorar la demora de aprobación si tus marcas de tiempo comienzan cuando una notificación llega a un teléfono. Empieza cuando el sistema crea una acción revisable y registra cada cambio de estado mediante un identificador de solicitud que sobreviva a los reintentos y a las actualizaciones de la interfaz.

Usa un registro de eventos pequeño como este. Los campos son deliberadamente simples. Los registros simples se pueden ordenar, combinar y conservar durante la revisión de un incidente.

{
  "request_id": "req_7f31",
  "run_id": "run_241",
  "action_class": "bounded_write",
  "target": "issue tracker/project-amber",
  "created_at": "2025-03-08T14:02:01Z",
  "presented_at": "2025-03-08T14:02:03Z",
  "opened_at": "2025-03-08T14:09:18Z",
  "decided_at": "2025-03-08T14:10:06Z",
  "decision": "allow",
  "executed_at": "2025-03-08T14:10:07Z",
  "outcome": "success"
}

Con esta estructura, calcula la espera en cola como opened_at - presented_at, el tiempo de decisión como decided_at - opened_at y el tiempo de ejecución como executed_at - decided_at. Conserva también created_at. Detecta un defecto más silencioso: un intermediario que retiene una solicitud antes de que alguien pueda verla.

Una consulta puede expresar estas mediciones sin una plataforma de análisis complicada:

SELECT
  action_class,
  percentile_cont(0.50) WITHIN GROUP (ORDER BY opened_at - presented_at) AS p50_queue_wait,
  percentile_cont(0.95) WITHIN GROUP (ORDER BY opened_at - presented_at) AS p95_queue_wait,
  percentile_cont(0.95) WITHIN GROUP (ORDER BY decided_at - opened_at) AS p95_decision_time,
  count(*) FILTER (WHERE decision = 'deny') AS denied,
  count(*) AS total
FROM approval_requests
WHERE created_at >= current_timestamp - interval '14 days'
GROUP BY action_class;

La sintaxis exacta de los percentiles cambia según la base de datos. La medición no. Informa de p50 y p95 para cada clase de acción, junto con el recuento y la tasa de denegación. Un promedio puede hacer que una experiencia de cinco segundos parezca correcta junto a unas pocas solicitudes que esperaron noventa minutos. El p95 muestra si la cola lenta rompe tareas reales.

Registra también si el agente canceló, reintentó o abandonó la tarea antes de que llegara la decisión. Una aprobación tardía que se ejecuta después de que el agente haya elegido otro camino es peor que una denegación normal. Crea una acción que ya no corresponde al trabajo que el desarrollador tiene delante.

No recompenses a los revisores solo por reducir el tiempo de decisión. Eso convierte las denegaciones razonadas en un aparente problema de rendimiento. Revisa conjuntamente la distribución de aprobaciones, denegaciones, caducidades y retiros. Una caída repentina de las denegaciones combinada con tiempos de lectura muy cortos suele indicar que las personas han aprendido que hacer clic en «permitir» despeja una molestia.

La espera y el tiempo de revisión apuntan a defectos distintos

La espera en cola y el tiempo de decisión comparten un reloj, pero tienen causas y responsables diferentes. Tratarlos como una sola métrica produce malas soluciones.

La espera en cola aumenta cuando las solicitudes llegan a la persona equivocada, demasiadas personas suponen que decidirá otra, las notificaciones llegan fuera del horario laboral o el revisor no tiene un motivo claro para interrumpir la tarea actual. Añadir más notificaciones suele empeorar el problema. Extiende la misma responsabilidad ambigua a más personas.

El tiempo de decisión aumenta cuando la tarjeta obliga al revisor a reconstruir la intención del agente. Una solicitud como «POST /v1/resources» no se puede revisar. El revisor necesita conocer el destino, la operación, la cantidad de objetos, la autoridad utilizada y la consecuencia visible. No debería tener que abrir una terminal, inspeccionar el código fuente e inferir si la solicitud crea un borrador o envía un mensaje a clientes.

Una tarjeta de aprobación útil responde cinco preguntas en lenguaje claro:

1. ¿Qué ejecución del agente creó la solicitud y qué proceso firmado inició esa ejecución?
2. ¿Qué destino externo recibirá la acción?
3. ¿Qué cambiará o qué datos saldrán del equipo?
4. ¿Qué autoridad limitada la permite?
5. ¿Qué ocurre si el revisor la deniega o no hace nada?

No confundas más detalles con mejor contexto. Una carga útil completa puede ocultar el único campo importante. Muestra primero una consecuencia concisa y permite después inspeccionar el comando, el endpoint, las cabeceras sin secretos y la carga útil cuando sea necesario. Quien aprueba un borrado necesita los nombres de los objetos afectados. Quien aprueba una lectura HTTP necesita el host, la ruta y el alcance de la consulta. Cada acción necesita pruebas que correspondan a su riesgo.

El error recurrente consiste en optimizar la espera en cola concediendo una aprobación amplia de sesión, aunque el revisor fuera lento porque la acción no estaba clara. Eso convierte un problema de contexto en un problema de autoridad. Corrige primero la descripción de la solicitud y el límite de la acción.

También aparece el error contrario: los equipos exigen una confirmación separada para cada una de cien lecturas normales porque la cola parece insegura. La cola es insegura porque genera habituación. Las solicitudes repetidas de bajo impacto entrenan al revisor para aprobar por forma y momento, no por contenido. Ese hábito permanece cuando aparece una solicitud importante.

Una cola de revisión demuestra que el flujo necesita otra forma

Una cola no solo retrasa el trabajo. Cambia el comportamiento del agente y de la persona. El agente reintenta, divide una tarea en llamadas más pequeñas o mantiene un plan incompleto. La persona ve un montón cada vez mayor y empieza a vaciarlo por lotes. Cada respuesta hace que la cola parezca menos alarmante, hasta que una solicitud inusual queda escondida entre otras conocidas.

Considera un fallo habitual. Se pide a un agente que prepare una nota de lanzamiento a partir de datos de un gestor de incidencias. Primero lee la lista de proyectos, después obtiene cada incidencia, luego lee los comentarios de las incidencias seleccionadas y finalmente crea una nota en borrador. Un flujo que exige aprobación para cada llamada HTTP convierte una tarea moderada en docenas de solicitudes.

A las 9:30, un desarrollador aprueba cuidadosamente las primeras lecturas. A las 9:45 tiene una reunión. A las 10:30, el agente ha puesto en cola reintentos y llamadas relacionadas. El desarrollador vuelve, ve una pared de solicitudes al mismo servicio y las aprueba rápidamente. Una solicitud crea un comentario público en vez de una nota en borrador porque el endpoint y el resultado previsto estaban enterrados en el texto sin procesar. En esa cola, el desarrollador no tenía una oportunidad realista de distinguirla.

La mala decisión empezó antes del comentario público. El flujo hizo competir las lecturas rutinarias con una escritura visible. También obligó a la persona a mantener el contexto después de una interrupción larga. Es un defecto de diseño, no un fallo del revisor.

Corrígelo agrupando el trabajo según una intención significativa. Una sesión de lectura puede cubrir un servicio identificado y la duración de una tarea si su autoridad no puede modificar nada. La creación de un borrador puede pedir una decisión explícita con la ubicación del borrador y su audiencia. La publicación pública debe mantenerse separada porque sus consecuencias cambian la pregunta que debe responder el revisor.

No resuelvas esto con una instrucción general que diga que un agente puede «usar el gestor de incidencias». Esa frase oculta demasiado. No indica si el agente puede leer incidencias privadas, editar etiquetas, comentar públicamente o borrar datos. Los nombres de los alcances deben corresponder a acciones que las personas puedan reconocer después.

La misma lógica se aplica a SSH. Una solicitud para inspeccionar un registro de servicio y otra para ejecutar una migración pueden viajar por la misma conexión, pero no pertenecen a la misma clase de aprobación. La identidad de la conexión no es la identidad de la acción.

El alcance de aprobación debe seguir las consecuencias, no el transporte

Un buen límite de aprobación describe aquello con lo que una persona está de acuerdo. HTTP frente a SSH, un comando frente a una llamada de API y un proceso local frente a uno remoto son detalles de transporte. Importan para la implementación, pero no indican al revisor si la acción es reversible, externa o costosa.

Empieza por las clases de consecuencias. Las operaciones de lectura pueden revelar datos, así que «lectura» no significa automáticamente que sean inofensivas. Las escrituras también son diferentes: crear un borrador privado, cambiar una configuración de producción y enviar un mensaje modifican el estado, pero requieren niveles de revisión distintos. Sepáralas antes de decidir qué interacciones pueden compartir una aprobación.

Después limita el alcance en dimensiones que el revisor pueda comprobar:

• Destino: un host, repositorio, proyecto o entorno identificado.
• Operación: leer, crear un borrador, actualizar un campo concreto o ejecutar una familia de comandos determinada.
• Conjunto de objetos: los registros, archivos o servicios específicos implicados.
• Duración: una acción, una ejecución del agente o una ventana breve programada.
• Consecuencia: privada, reversible, visible externamente o destructiva.

Evita los alcances basados en detalles de implementación. «Permitir solicitudes POST» es una regla de transporte, no un límite de aprobación. Una solicitud POST puede crear un borrador o eliminar una cuenta. «Permitir acceso a la línea de comandos» tiene el mismo defecto. Concede un medio de acción en lugar de un resultado comprensible.

A menudo se defiende una aprobación amplia de sesión porque las solicitudes individuales interrumpen el flujo. La interrupción existe, pero la solución no sirve cuando la sesión puede mezclar operaciones sin relación. Una sesión solo es adecuada si su destino y sus consecuencias permitidas siguen siendo claros durante toda su duración. Si un agente pasa de recopilar notas de lanzamiento a cambiar permisos del repositorio, necesita una nueva decisión.

Usa una confirmación por acción cuando las consecuencias sigan siendo importantes incluso dentro de una ejecución de confianza. Publicar, borrar, rotar material de acceso, cambiar la accesibilidad de la red y enviar información fuera del equipo suelen pertenecer a esta categoría. No uses la confirmación por acción como castigo para el trabajo desconocido. Úsala cuando cada caso necesite criterio humano.

Rediseña el trabajo rutinario antes de relajar los controles

Cuando la latencia de aprobación supera su presupuesto, elimina primero las solicitudes que nunca debieron convertirse en interactivas. Eso no significa permitir acciones arbitrarias. Significa limitar el trabajo rutinario lo suficiente para que la persona pueda aprobar la ejecución o la tarea, en vez de cada subllamada mecánica.

Analiza una clase lenta en este orden:

1. Toma una muestra de las solicitudes p95 y lee la secuencia completa que rodea cada una. Cuenta los reintentos y las llamadas duplicadas por separado de las llamadas necesarias.
2. Marca la primera acción en la que cambian las consecuencias. Ese suele ser el punto correcto para una decisión explícita.
3. Consolida las lecturas deterministas bajo un alcance de tarea limitado, con un destino conocido y una caducidad al terminar la ejecución.
4. Separa la publicación externa, el borrado, los cambios de permisos y la exportación amplia de datos en solicitudes distintas.
5. Vuelve a probar la tarea con un revisor real que no haya diseñado el flujo. Si no puede describir el resultado previsto antes de aprobar, vuelve a limitar la solicitud.

Agrupar ayuda solo cuando el propio lote se puede revisar. «Crear estas cuatro incidencias en borrador en el proyecto Amber» es un lote razonable si la tarjeta nombra las cuatro incidencias y su destino. «Realizar todo el trabajo de lanzamiento restante» no es un lote. Es una delegación abierta.

No hagas que el agente decida el límite del lote basándose solo en la comodidad. Entrégale un objeto de tarea: destino, resultado solicitado, fuentes de datos permitidas y caducidad. El agente puede reunir las llamadas bajo ese objeto, pero un cambio de destino o de consecuencias debe cerrar el lote. Esto también mejora la revisión de incidentes, porque el registro refleja una unidad de trabajo real en vez de un flujo largo de solicitudes anónimas.

El trabajo programado necesita otro rediseño. Si una persona debe aprobar una tarea de mantenimiento nocturna durante la noche, el equipo ha creado un fallo previsible. Programa una ventana de revisión antes de la ejecución, asigna una persona de guardia con un presupuesto adecuado o aplaza el trabajo. No disfraces una aprobación desatendida de automatización.

La posibilidad de reintentar merece especial atención. El agente debe reutilizar el mismo identificador de solicitud pendiente cuando la acción subyacente no haya cambiado. Crear una nueva tarjeta de aprobación para cada reintento fabrica volumen en la cola y destruye la percepción que tiene el revisor de la secuencia. Si cambian el destino, la carga útil, la autoridad o la consecuencia prevista, crea una nueva solicitud e indica qué cambió.

La pantalla de aprobación debe facilitar la decisión correcta

El revisor necesita una declaración compacta de la intención, no una invitación a aplicar ingeniería inversa a una ejecución del agente. Diseña la pantalla en torno a la decisión que debe tomar ahora y ofrece pruebas más detalladas sin obligarlo a buscarlas.

Coloca primero el resultado de la acción: «Crear una nota de lanzamiento privada en borrador en el proyecto Amber» dice más que un método y una ruta. Muestra el destino junto a él. Indica si la acción lee, modifica, borra o envía datos. Si usa SSH, nombra el host y muestra el comando de forma que las redirecciones, las escrituras de archivos y los cambios de privilegios sean evidentes.

Muestra también el contexto de autoridad. El revisor debe saber si la solicitud procede de un proceso nuevo del agente o de una ejecución ya aprobada, y si esta acción requiere una confirmación especial. La identidad del proceso importa porque la aprobación de un proceso no debe autorizar silenciosamente a otro proceso que use el mismo protocolo.

Sallyport usa para esto una escala fija de decisiones: una bóveda bloqueada deniega todas las acciones, un proceso nuevo del agente recibe por defecto una autorización de sesión y una credencial puede exigir aprobación en cada uso. La primera tarjeta de sesión muestra primero la autoridad de firma de código del proceso, que es el dato correcto para poner delante de una persona que decide si esa es la ejecución que pretendía iniciar.

No conviertas la pantalla en un editor de reglas. Un revisor con un plazo encima debe poder aprobar, denegar o inspeccionar una solicitud concreta. Si un equipo pide repetidamente una excepción, rediseña el alcance de la tarea o el límite de la credencial fuera del momento de la interrupción. Poner un pequeño lenguaje de políticas en la ruta de aprobación solo pide a personas cansadas que programen decisiones de seguridad bajo presión.

La denegación debe ser informativa. Devuelve una categoría de motivo sobre la que el agente pueda actuar, como caducada, destino incorrecto, necesita un alcance más limitado o requiere revisión humana. No devuelvas por defecto comentarios privados del revisor a un agente que no sea de confianza. El agente necesita información suficiente para dejar de reintentar o elegir una tarea alternativa segura, no una transcripción de las deliberaciones internas.

Define la responsabilidad y el escalado antes de que llegue una solicitud urgente

Un presupuesto de aprobación sin responsable se convierte en un deseo. Cada clase de acción necesita una persona o un turno responsable de decidir durante el periodo en que puede ejecutarse. Un equipo puede delegar la revisión, pero no puede delegar el hecho de que alguien debe tomar la decisión.

Define qué ocurre en cada límite del presupuesto. Al alcanzar la mitad del presupuesto, el sistema puede avisar una vez al revisor asignado si la solicitud sigue sin verse. Al llegar al límite, una solicitud de bajo impacto puede caducar. Una solicitud de alto impacto debe caducar y avisar a la persona responsable de la tarea o al turno de guardia, en lugar de permanecer pendiente para siempre. El momento exacto importa menos que hacer visible y finito el estado.

Usa el horario laboral con honestidad. Si un desarrollador ejecuta un agente localmente por la noche y la acción necesita la aprobación de un compañero, la tarea quizá tenga que esperar. Es aceptable. El fallo aparece cuando la interfaz promete progreso inmediato y después deja al agente reintentando contra una cola sin supervisión.

El escalado nunca debe ampliar la autoridad. Una solicitud escalada pasa a un revisor mejor situado, no a una ruta de aprobación automática. Esta distinción importa durante los incidentes, cuando la urgencia tienta a las personas a saltarse todos los controles de una vez. Pueden existir procedimientos de emergencia preaprobados, pero deben describir una acción limitada, una responsabilidad identificada y una revisión posterior. «Producción está rota» no es un alcance de aprobación.

Revisa también el coste para las personas, no solo la demora del agente. Si un desarrollador recibe casi todas las solicitudes, existe un problema de enrutamiento aunque la latencia mediana sea buena. Si cada revisor ve cada solicitud, el equipo ha construido una bandeja compartida con etiquetas de seguridad. Ambos patrones producen fatiga y una responsabilidad débil.

Audita la cola como una secuencia de decisiones

Un registro de auditoría útil permite reconstruir algo más que la acción final. Debe mostrar la ejecución del agente, la solicitud presentada al revisor, la decisión, la llamada externa real y cualquier cancelación o reintento. Sin esa secuencia, el equipo no puede saber si una aprobación tardía provocó una acción obsoleta o si el agente cambió de plan después de una denegación.

Mantén conectadas las pruebas de aprobación y las pruebas de acción mediante identificadores, pero no las confundas. La aprobación responde a quién autorizó una intención descrita. El registro de acción responde a qué se intentó realmente y qué devolvió el destino. Un investigador necesita ambas cosas cuando la solicitud de un agente falla a mitad de camino o un servicio remoto interpreta una carga útil de forma inesperada.

Sallyport proyecta un diario Sessions y un diario Activity desde un único registro de auditoría cifrado y encadenado mediante hashes. Su comando sp audit verify comprueba la cadena sin conexión sobre el texto cifrado y sin necesitar la clave de la bóveda, lo que resulta útil cuando alguien necesita probar la integridad del registro sin abrir las credenciales del agente.

Usa el registro de auditoría en una revisión semanal de las excepciones, no como un almacén de datos que nadie consulta. Extrae las solicitudes caducadas, los ejemplos p95 más lentos, las acciones denegadas y las acciones que se ejecutaron después de una espera larga. En cada caso, haz una pregunta concreta: ¿la demora se debió a la responsabilidad, a una intención poco clara, a un alcance demasiado amplio o a una tarea que debería haberse programado de otra manera?

No evalúes a las personas por la velocidad de aprobación. Evalúa el flujo por su capacidad de poner una decisión comprensible en manos de una persona responsable antes del plazo de la tarea. Si una revisión repetida solo produce aprobaciones automáticas, elimina esa repetición. Si una acción poco frecuente necesita una reflexión cuidadosa, dale el tiempo, el contexto y la responsabilidad que esa reflexión requiere.

Empieza recopilando durante una semana las marcas de tiempo de todo el ciclo de vida. Elige la clase de acción con la peor espera p95 en cola, inspecciona diez secuencias completas de solicitudes y cambia el límite que haya creado más solicitudes duplicadas. Ese trabajo te enseñará más que otro panel de control.