Aprobación por sesión frente a aprobación por llamada para acciones de agentes

Un agente de IA no necesita acceso sin restricciones para resultar útil. Necesita autoridad suficiente para el trabajo actual, durante un periodo que puedas explicar, con una decisión humana situada en el punto donde otra llamada cambiaría el riesgo. Esa es la diferencia práctica entre la aprobación por sesión y la aprobación por llamada.

He visto a equipos cometer dos errores opuestos. Uno aprueba cada consulta inocua y enseña a la gente a aceptar los avisos sin leerlos. El otro concede una sesión larga a un agente de programación y luego se sorprende cuando un bucle crea cincuenta tickets, activa varios despliegues o exporta muchos más datos de los previstos. Ninguno de los dos fallos requiere un exploit exótico. Ambos nacen de colocar mal el límite de aprobación.

La frase clave, aprobación por sesión frente a aprobación por llamada, describe una elección que necesita tres datos: cuánto durará el trabajo, cuánta autoridad tiene la credencial y qué puede hacer una solicitud válida repetida. El verbo HTTP, el plan declarado por el agente y el hecho de que un desarrollador esté observando son señales más débiles que esas tres.

La aprobación es un permiso para actuar dentro de un límite definido

La aprobación por sesión concede a un proceso de agente identificado autoridad para usar una credencial durante toda esa ejecución. La aprobación por llamada pide una decisión cada vez que se usa la credencial. Responden a preguntas distintas. Tratarlas como equivalentes produce confianza ciega o fricción inútil.

Una decisión de sesión dice: «Reconozco este proceso, acepto esta ejecución acotada y las acciones disponibles mediante esta credencial son suficientemente seguras para repetirse durante ella». Es una decisión razonable para un agente que comprueba algunos registros de incidencias mientras investiga un error. Es una mala decisión para un agente que puede modificar producción cuando su propio razonamiento decide que otra mutación sería útil.

Una decisión por llamada dice: «Acepto este uso exacto de esta credencial ahora». Es más lenta por diseño. El aviso debe aparecer en un punto donde una persona pueda reconocer la consecuencia y rechazarla sin perder toda la tarea. Si el aviso no comunica una elección real, el diseño de aprobación es incorrecto. Si aparece antes de una acción irreversible, ese segundo adicional suele ser un coste pequeño.

No confundas esto con la autenticación. La autenticación indica al sistema local quién puede desbloquear el almacén de credenciales. La autorización responde si una ejecución de agente puede usar una credencial concreta. El control por llamada añade una tercera pregunta: si ese uso, en ese momento, merece una nueva decisión humana.

La diferencia importa durante una tarea normal de programación. Un agente puede usar un token API para leer el estado de compilación y otro para activar una versión. El mismo proceso puede ser suficientemente confiable para inspeccionar el primero y aun así necesitar una decisión explícita para el segundo. La identidad del proceso no elimina el riesgo de cada endpoint al que puede llegar.

Un límite de aprobación útil tiene cuatro propiedades:

• Una persona puede explicar qué trabajo está haciendo el agente.
• El alcance de la credencial coincide con ese trabajo, no con toda la lista de tareas posibles del agente.
• La aprobación termina cuando acaba el trabajo o el proceso identificado.
• La persona puede describir el peor resultado plausible si el agente repite una acción permitida.

La cuarta propiedad detecta más diseños deficientes que la mayoría de las listas de comprobación. Si la respuesta es «haría otra solicitud inocua», la aprobación por sesión puede encajar. Si incluye dinero, comunicaciones con clientes, estado de producción, borrados, cambios de acceso o una exportación grande, mantén la decisión humana cerca de cada acción.

La duración de la tarea cambia el significado de una promesa de sesión

Una sesión es más segura cuando es breve, está limitada a una sola tarea y depende de un proceso que termina al finalizarla. Una sesión que sobrevive en silencio a trabajos no relacionados es un permiso permanente con un nombre más amable.

La duración afecta al riesgo porque un agente no deja de razonar después de completar su primera acción prevista. Puede reintentarlo, seguir una subtarea recién descubierta, inspeccionar otro repositorio o seguir una instrucción errónea obtenida de un archivo o ticket. Cuanto más vive el proceso, menos útil se vuelve tu modelo mental original. Una ejecución de diez minutos para inspeccionar pruebas fallidas tiene un propósito comprensible. Un proceso activo toda la tarde ha acumulado contexto, cambiado de objetivo y encontrado más oportunidades de recibir entradas hostiles o engañosas.

Siempre que puedas, usa el límite de la tarea en lugar de un reloj. La salida del proceso es una condición final honesta: el agente aprobado ya no está. Un tiempo de espera fijo es una medida de respaldo, no un control equivalente. Al cumplirse quince minutos, el agente puede seguir con el trabajo original o una herramienta distinta puede haber heredado la misma autoridad. El tiempo por sí solo no permite saber cuál de las dos cosas ocurre.

Para una sesión acotada, describe la unidad de trabajo antes de aprobarla. Una buena descripción es concreta: «inspeccionar la ejecución fallida de integración continua y abrir un comentario en borrador con los hallazgos». Una descripción deficiente es «ayudar con la versión». El lenguaje amplio permite que el agente transforme una pequeña tarea de diagnóstico en trabajo de publicación.

Considera estas formas de tarea:

El atajo habitual es aprobar una sesión para cada tarea porque a la gente le molestan las interrupciones. La queja es válida cuando los avisos aparecen ante llamadas de poca consecuencia. La solución es reducirlos limitando las credenciales y agrupando el trabajo rutinario en sesiones reales, no convertir una ejecución larga en una ventana con acceso total.

Los reinicios del agente merecen la misma cautela. Para quien lanzó el comando, un reinicio puede parecer continuidad, pero es un proceso nuevo que puede cargar instrucciones, código o complementos distintos. Pide una nueva autorización de sesión después de un reinicio. No es burocracia. La decisión original estaba vinculada a una autoridad ejecutable y una ejecución concretas, no a la intención vaga del desarrollador para toda la tarde.

La sensibilidad de una credencial empieza por sus capacidades, no por el tipo de secreto

Una credencial es sensible por lo que puede causar, revelar o delegar, no por el nombre que tenga. Una clave API usada solo para leer un artefacto público de compilación puede ser menos peligrosa que un token que permite a administradores entrar en un espacio de trabajo privado. Una clave SSH que llega a un host de despliegue tiene un modo de fallo distinto al de un token que llama a una API de facturación, pero ambas pueden necesitar control por llamada.

Clasifica cada credencial según los permisos reales del sistema remoto. No aceptes una etiqueta como «token de lectura» sin comprobar qué considera lectura la API. Algunos servicios exponen endpoints de exportación como lecturas. Otros permiten que un endpoint supuestamente de solo lectura inicie la generación de informes, consuma capacidad escasa o devuelva datos que el agente nunca debería ver en bloque.

Antes de elegir un nivel de aprobación, uso cuatro preguntas:

1. ¿Puede esta credencial cambiar el estado fuera de la máquina local?
2. ¿Puede revelar información que no deba entrar de forma segura en el contexto o la salida del agente?
3. ¿Puede conceder más acceso, directamente o mediante un flujo que pueda activar?
4. ¿Puede gastar dinero, consumir una cuota o crear un compromiso contractual o reputacional?

Responder afirmativamente a una pregunta no obliga siempre a usar aprobación por llamada. Sí significa que la aprobación por sesión necesita una tarea más acotada, un alcance más estricto y una reversión plausible. Si varias respuestas son afirmativas, pedir aprobación en cada uso suele ser la opción honesta.

Usa el alcance como primera reducción y la aprobación como segunda. Un token que solo puede leer un repositorio ofrece una decisión de sesión mucho mejor que uno que lee todos los repositorios de la organización. Una credencial limitada a un entorno de pruebas es más segura para una sesión que otra capaz de operar en producción. La aprobación humana no puede reparar un token absurdamente amplio después de que el agente ya tiene autoridad para hacer solicitudes costosas.

SSH merece un tratamiento especial porque la gente suele llamarlo «solo acceso al shell». El acceso al shell es una entrada a una superficie de acciones grande y cambiante. El riesgo real depende de la cuenta, el host, la conectividad de red, los comandos disponibles, los ganchos de despliegue y los archivos que la cuenta puede leer. Una cuenta restringida que solo pueda ejecutar un comando de diagnóstico puede encajar con una sesión. Una cuenta de despliegue, un host con datos de clientes o una cuenta que pueda cambiar controles de acceso deberían permanecer bajo aprobación por llamada hasta que puedas limitar su alcance.

No permitas que la rotación de credenciales oculte este análisis. Una clave recién creada con amplios permisos de producción sigue teniendo amplios permisos de producción. Rotarla después de una ejecución incorrecta limita abusos futuros, pero no revierte las llamadas remotas que ya tuvieron éxito.

La repetición convierte una acción tolerable en una costosa

Una solicitud puede ser aceptable por separado y aun así resultar insegura cuando un agente la repite. Clasifica la acción repetida, no solo la primera acción que muestra el aviso.

Aquí es donde los equipos confían demasiado en los nombres de los métodos HTTP. RFC 9110 indica que los métodos seguros están pensados para ser de solo lectura: GET, HEAD, OPTIONS y TRACE. También advierte que no se puede responsabilizar a un cliente cuando un servidor expone un comportamiento inseguro mediante un método seguro, porque el propietario del recurso decide ese comportamiento. Esa redacción importa. Un endpoint GET puede estar pensado semánticamente para recuperar información, pero la aplicación puede hacerlo costoso, exponer una exportación enorme, actualizar un campo de auditoría o activar trabajo posterior. Los nombres de los métodos ayudan a iniciar una investigación. No la completan.

La idempotencia es otro término que se usa mal. Una solicitud es idempotente cuando repetirla tiene sobre el estado del servidor el mismo efecto previsto que hacerla una vez. Eso no significa que repetirla sea inocuo. Una solicitud PUT que establece una marca en true puede ser idempotente y aun así activar una función de producción. DELETE puede ser idempotente después del primer borrado y seguir eliminando algo importante. GET puede ser seguro en el sentido del protocolo y aun así agotar un límite de frecuencia cuando un agente entra en un bucle.

Prueba el comportamiento repetido de un endpoint en una cuenta desechable o en un entorno de pruebas. Envía la misma solicitud dos veces, inspecciona el estado remoto y los efectos secundarios, y después pregunta qué ocurre si el agente la envía cien veces. No te detengas en el cuerpo de la respuesta. Comprueba los mensajes enviados, los trabajos en cola, los registros de auditoría creados, la cuota consumida, los webhooks activados y los datos copiados a otros lugares.

Para un endpoint que crea objetos, usa una clave de idempotencia si el servicio la admite. Esta forma de solicitud evita que un reintento de red cree un segundo pago, ticket o solicitud de aprovisionamiento cuando se pierde la primera respuesta:

POST /v1/provisioning-requests HTTP/1.1
Authorization: Bearer injected-by-gateway
Idempotency-Key: agent-run-8b2f1-request-17
Content-Type: application/json

{"environment":"staging","version":"2025.04.18"}

El servicio debería devolver el resultado original cuando recibe de nuevo la misma clave de idempotencia. La respuesta suele tener el mismo identificador de objeto y un estado de éxito, en lugar de crear un objeto nuevo. Confirma ese comportamiento en la documentación del servicio y pruébalo tú mismo. Una clave de idempotencia reduce la creación duplicada causada por reintentos; no convierte un despliegue inadecuado en apropiado ni evita que un agente genere una clave nueva en cada intento equivocado.

La aprobación por llamada encaja con acciones que tengan cualquiera de estos perfiles de repetición:

• Cada llamada crea algo nuevo, como una factura, cuenta, ticket, mensaje o pedido.
• Cada llamada cambia el estado activo y resulta difícil reconstruir el estado anterior.
• Cada llamada puede revelar otra página, otro archivo o los datos de otro cliente.
• Cada llamada puede producir un efecto público o visible para clientes.
• Cada llamada puede activar trabajo que cuesta dinero o consume capacidad limitada.

Una sesión encaja con llamadas repetidas cuando el sistema remoto las considera de poca consecuencia, el alcance de la credencial es pequeño y la tarea tiene un final claro. El equipo debe demostrar esa afirmación. «Probablemente el agente no entrará en un bucle» no es una propiedad del endpoint.

Una etiqueta de solo lectura no resuelve el riesgo

El acceso de lectura puede crear riesgos de privacidad, operativos y de inyección de instrucciones incluso cuando no puede modificar un registro remoto. Trata la exposición de datos como una acción con consecuencias, sobre todo cuando el agente puede resumir, copiar o usar lo recuperado para decidir su siguiente movimiento.

Supón que un agente tiene permiso para buscar en un sistema de soporte. Una sesión puede ser razonable para una tarea limitada a un ticket y sus adjuntos. La misma credencial es mucho más difícil de aprobar en una ejecución que pueda enumerar todos los tickets, recuperar exportaciones o introducir conversaciones privadas de clientes en el contexto local. El endpoint puede usar GET en todo momento. El límite de datos, no el verbo, define el riesgo.

La pregunta incómoda es si el propio agente está autorizado a ver el resultado devuelto. Una pasarela de credenciales que mantiene los tokens fuera del agente no hace que todos los resultados sean seguros para devolver. Las respuestas suelen filtrar secretos: los endpoints de configuración devuelven cadenas de conexión, los registros de usuarios incluyen datos personales, la salida de comandos contiene variables de entorno y las respuestas de error exponen rutas o identificadores internos.

Elige aprobación por llamada para una lectura cuando un solo resultado pueda revelar una clase sensible de información o cuando la solicitud del agente pueda ampliar su propio espacio de búsqueda. Esto incluye búsquedas amplias, exportaciones, recuperación de secretos, enumeración de cuentas y comandos como cat sobre directorios cuyo contenido varía. Una persona necesita la oportunidad de ver el objetivo antes de liberar esos datos en la ejecución.

Para las lecturas rutinarias, limita la forma de la solicitud. Prefiere una credencial restringida a un proyecto, repositorio, entorno o grupo de recursos de una API. Establece límites de páginas en el servidor cuando el servicio los ofrezca. Cuando sea posible, proporciona al agente un mecanismo de consulta que acepte identificadores explícitos, en lugar de un endpoint de búsqueda sin restricciones. Estas decisiones reducen el número de avisos porque la propia llamada permitida es más pequeña.

Un patrón de fallo aparece en la respuesta ante incidentes. Un agente empieza con una solicitud inocua para inspeccionar registros, encuentra un token en una línea y luego busca todas las apariciones de ese token en un archivo amplio. En la mente de una persona, la aprobación de sesión cubría la resolución de problemas, pero el alcance de la credencial y la forma de consulta permitieron recopilar datos. El operador no ve ninguna mutación en la lista de actividad y supone que la ejecución fue segura. El acto sensible fue la recuperación.

Conserva un registro separado de lo solicitado, la credencial usada y si la llamada se aprobó como acción de sesión o como acción individual. Ese registro ayuda al investigador a distinguir un agente comprometido de una mala elección de aprobación. También muestra qué credenciales necesitan menos alcance. Registrar solo las mutaciones exitosas deja invisibles los fallos más difíciles de recuperación de datos.

Haz que los avisos correspondan a decisiones que una persona pueda tomar

La fatiga de aprobación es un fallo de diseño cuando los avisos llegan con tanta frecuencia que nadie los lee o son tan vagos que nadie puede juzgarlos. La aprobación por llamada solo funciona cuando cada aviso proporciona información suficiente para aceptar o rechazar una consecuencia concreta.

Un aviso útil identifica el proceso que llama, la credencial o categoría de acción, el destino y el efecto importante. «Permitir solicitud API» no permite tomar una buena decisión. «El proceso de agente firmado solicita un despliegue en producción mediante la credencial de publicación» sí. Para una lectura sensible, el aviso debería nombrar el conjunto de datos o el objetivo, no limitarse a decir «solicitud GET». Para SSH, muestra el host y el comando o una categoría de comandos significativa.

No resuelvas la sobrecarga de avisos ocultando el destino. Un desarrollador que aprueba una solicitud basándose en un nombre amigable de tarea no puede detectar un error tipográfico, una instrucción maliciosa o un agente que cambió de rumbo. El aviso necesita suficiente precisión para detectar el desajuste entre el trabajo previsto y la acción real.

Al mismo tiempo, no obligues a la gente a analizar un cuerpo HTTP sin procesar para cada solicitud rutinaria. Eso produce aprobaciones ceremoniales. Coloca las llamadas repetidas y de bajo impacto dentro de una sesión acotada y reserva los avisos individuales para las operaciones que cruzan un límite de decisión real. La persona debería ver menos avisos, pero cada uno de los restantes debe importar.

Añade una nota breve de aprobación junto a cada configuración de credencial. No es un lenguaje de políticas ni necesita convertirse en uno. Una frase como «solo sesión para leer el estado de compilación de un repositorio; aprobar cada publicación en producción» hace más concretas las revisiones posteriores. Si un equipo no puede escribir una frase que separe el trabajo normal de una acción importante, probablemente la credencial es demasiado amplia.

La identidad del proceso que se muestra al autorizar una sesión también merece atención. Las personas deben aprobar la autoridad ejecutable, no solo una línea de comandos que pueda copiarse o modificarse. Un proceso principal firmado y un ayudante sin firma representan decisiones de confianza distintas. La respuesta adecuada ante una autoridad desconocida es detener la ejecución, averiguar por qué cambió y aprobarla solo si el cambio era esperado. Hacer clic porque la tarea es urgente enseña a la organización a aceptar una vía de suplantación.

Usa una matriz de decisión antes de cambiar el ajuste de aprobación

Una matriz pequeña evita discusiones basadas en la tolerancia personal a los avisos. Puntúa la acción según sus consecuencias y elige el nivel más estricto cuando la puntuación apunte en dos direcciones.

Cuando la tabla ofrece respuestas mezcladas, separa el flujo en lugar de buscar un punto intermedio. Da al agente una credencial aprobada por sesión para diagnósticos y otra aprobada por llamada para la corrección. Este diseño suele resultar más natural que aprobar repetidamente las lecturas o conceder una sesión amplia para evitar aprobaciones de mutaciones.

Veamos un ejemplo. Un agente investiga un despliegue fallido. Necesita leer registros de compilación, consultar el estado de un entorno de pruebas concreto y quizá reiniciar un servicio.

Los registros y las consultas de estado pueden ejecutarse bajo aprobación por sesión si el token solo llega a ese proyecto y el proceso termina después del diagnóstico. El reinicio debería usar una credencial distinta con aprobación por llamada porque cambia el estado en ejecución. Aunque reiniciar el servicio suela ser seguro, los reinicios repetidos pueden interrumpir trabajo activo, ocultar la causa raíz y activar bucles de recuperación automática. Que el agente haya descubierto el reinicio como solución razonable no lo convierte en una operación rutinaria.

Ahora cambia un detalle: la API de estado puede consultar todos los entornos de producción y la recuperación de registros puede obtener datos de clientes sin ocultar. La aprobación por sesión ya no encaja con la credencial de diagnóstico. El equipo debe limitar ese acceso primero. Poner la misma credencial amplia detrás de la aprobación por llamada limita un tipo de fallo, pero un revisor no puede evaluar de forma fiable cada solicitud de recuperación si el selector de datos sigue sin restricciones.

Por eso un único ajuste por agente es un modelo deficiente. La aprobación pertenece al canal de acción y al alcance de la credencial. Una ejecución de agente puede combinar ambos niveles de forma segura si los límites se trazan deliberadamente.

Los registros de auditoría explican una mala decisión, pero no pueden revertirla

Un registro resistente a manipulaciones permite investigar una ejecución de agente, revocar una sesión activa y establecer si el agente repitió una acción. No impide que un servicio remoto acepte una llamada que ya aprobaste.

Mantén dos vistas de la actividad. El registro de sesión responde quién ejecutó el proceso, cuándo empezó, qué autoridad tenía y si alguien la revocó. El registro de llamadas responde qué ruta de credencial usó el agente, qué destino contactó y si la llamada tenía autorización de sesión o una aprobación nueva. Se necesitan ambos. Una lista de sesiones no puede demostrar qué acción causó un problema, mientras que un montón de llamadas sin contexto de proceso no puede explicar quién las inició.

Haz que la integridad de la auditoría se pueda probar, en lugar de dejarla en un eslogan. Un registro encadenado mediante hashes debería fallar en la verificación si alguien cambia, elimina o reordena registros en la secuencia almacenada. La prueba es sencilla: verifica una copia conocida como correcta, cambia un byte en otra copia y vuelve a verificar. El verificador debería indicar que la cadena ya no es válida, mientras la original sigue verificándose. Hazlo en un entorno de prueba, nunca editando el almacén de auditoría de producción.

Sallyport proyecta sus diarios Sessions y Activity desde un registro de auditoría cifrado, encadenado mediante hashes y ciego a escritura. sp audit verify comprueba esa cadena sin conexión sobre el texto cifrado y no necesita una clave del almacén. Esta separación resulta útil cuando la persona que revisa los registros no debe recibir las credenciales ni los contenidos de las acciones protegidos por el almacén.

Los registros también revelan un error común: tratar la sesión como una excusa para dejar de mirar. Revisa las ejecuciones que usaron un número inusual de llamadas, contactaron con un destino nuevo, duraron mucho más de lo que indicaba la descripción de la tarea o usaron una credencial fuera de su categoría habitual. No necesitas un motor de reglas para detectar esos patrones. Una revisión humana semanal de una muestra pequeña puede descubrir la ampliación del alcance antes de que se convierta en una costumbre operativa.

Cuando un agente actúe mal, conserva la identidad del proceso, la entrada de la tarea, el registro de sesión, la secuencia de llamadas y los registros del servicio remoto antes de cambiar la configuración. Después formula una pregunta más concreta que «¿el agente fue comprometido?». ¿La acción estaba permitida por el alcance de la credencial? ¿El nivel de aprobación correspondía al riesgo de repetición? ¿El aviso ofrecía información suficiente para rechazarla? ¿Cambió el proceso después de la autorización? Esas respuestas conducen a soluciones. Una prohibición general de la autonomía no lo hace.

Un comienzo limitado es mejor que una excepción amplia

Empieza con un flujo cuyo impacto puedas describir sin vaguedades y asigna aprobación por llamada a la credencial que pueda causar más daño. Observa varias ejecuciones reales antes de pasar la parte rutinaria a una sesión acotada.

En una configuración de agente basada en Mac, Sallyport mantiene las credenciales API y SSH en su almacén cifrado y ejecuta la acción sin pasar el secreto al agente. Esto reduce la exposición de credenciales, pero aún debes elegir el límite de aprobación con el mismo cuidado porque la acción remota sigue siendo real.

La primera configuración debería impacientar un poco al desarrollador, no dejarlo a ciegas. Si cada ejecución produce una pila de avisos para leer estados de compilación, hay que mejorar el alcance o la agrupación de tareas. Si un agente puede modificar producción durante una hora después de una sola aprobación, la sesión es demasiado amplia. Ajusta la credencial y el límite de la tarea antes de sacar a la persona del circuito.

Describe la próxima decisión de aprobación en términos operativos: este proceso firmado, para esta tarea, puede realizar estas llamadas de bajo impacto hasta que termine; esta otra credencial necesita una nueva decisión porque cada uso puede cambiar algo que no podemos deshacer fácilmente. Esa frase proporciona un criterio que los revisores pueden aplicar bajo presión. Cualquier formulación más vaga acabará convirtiéndose en una excepción permanente.