¿Una sesión de agente reanudada debe conservar su aprobación anterior?

Una conversación de agente reanudada nunca debería heredar autoridad solo porque heredó texto. El modelo puede conservar el mismo plan, el mismo historial de herramientas y el mismo tono seguro. Nada de eso indica si el proceso que solicita acceso es el mismo que aprobaste, si la bóveda de credenciales está disponible o si el gateway aún conserva un registro fiable de la aprobación.

Trata la reanudación como una afirmación de continuidad que debe comprobarse, no como un derecho que el cliente puede declarar. Si cambió la identidad del proceso, el estado de la bóveda o el estado del gateway, la decisión anterior ha terminado. Vuelve a preguntar antes de la siguiente acción protegida.

Esto parece estricto hasta que observas cómo ocurren los reinicios en el trabajo real. Un agente de programación se actualiza. Un editor vuelve a iniciar su asistente después de un fallo. Un usuario mata un proceso bloqueado y lo inicia de nuevo. Un portátil entra en reposo mientras la bóveda se bloquea. Una aplicación de la barra de menús se reinicia después de una actualización. La conversación suele reconectarse con tanta suavidad que el usuario ve un único hilo sin interrupciones. El código de seguridad que trata ese hilo como autoridad unirá silenciosamente ejecuciones distintas bajo una sola aprobación.

Una conversación reanudada no lleva autoridad

Una conversación aporta contexto, mientras que la autorización es una decisión sobre un actor presente que intenta realizar una acción presente. Ambas cosas deben mantenerse separadas.

Los sistemas de agentes suelen guardar un identificador de conversación de larga duración, una transcripción y quizá un historial de llamadas a herramientas. Sirven para recuperar el trabajo después de una desconexión. Indican al agente qué intentaba hacer, qué archivos modificó y qué solicitud de API falló a mitad de camino. No identifican el proceso del sistema operativo que está conectado actualmente a las herramientas.

Piensa en una secuencia habitual. Un agente prepara una solicitud de despliegue y recibe aprobación de sesión. El gateway se reinicia antes de enviar la solicitud. El cliente del agente se reconecta, carga la transcripción anterior y dice que continúa la misma ejecución. Si el gateway acepta esa afirmación y restaura la aprobación anterior, la aprobación pasa a cubrir un proceso que el gateway no ha inspeccionado desde que volvió a iniciarse.

El proceso nuevo puede ser inofensivo. También puede ser una compilación recién instalada, un ejecutable contenedor iniciado desde otro directorio o un segundo cliente de herramientas que encontró un token de reanudación en caché. No puedes distinguir esos casos leyendo la conversación.

Por eso «el usuario ya aprobó esta tarea» es la comprobación equivocada. El usuario aprueba una ejecución de agente identificable bajo unas condiciones concretas. La aprobación termina cuando esas condiciones dejan de cumplirse o ya no pueden demostrarse.

El Model Context Protocol hace más visible esta diferencia. Su documentación de transporte explica que, con stdio, el cliente inicia el servidor como un subproceso e intercambia mensajes JSON-RPC mediante la entrada y salida estándar. Es una relación entre procesos activos, no un permiso duradero almacenado en una transcripción. El registro de cambios de MCP también eliminó las sesiones a nivel de protocolo en el trabajo más reciente sobre Streamable HTTP y orienta a los servidores con estado hacia identificadores explícitos creados por el servidor. Ese cambio no resuelve por sí solo la autorización, pero evita fingir que un identificador de sesión de transporte es una credencial de identidad.

Mantén claros estos términos en tu diseño:

• Una conversación es un registro de aplicación que puede sobrevivir a los procesos.
• Un proceso es una instancia del sistema operativo con una duración limitada.
• Una aprobación de sesión es un permiso para un proceso identificado durante esa duración.
• El uso de una credencial es una acción que debe cumplir las condiciones actuales de la bóveda y del gateway.

Los equipos mezclan estos términos porque una demostración sencilla hace que los cuatro parezcan avanzar juntos. Los reinicios de producción los separan.

La identidad del proceso tiene más de una parte

Un identificador de proceso por sí solo es demasiado débil para vincular una aprobación duradera, porque los sistemas operativos pueden reutilizar identificadores después de que termine un proceso. La ruta del proceso por sí sola también es insuficiente porque el archivo de esa ruta puede cambiar. La firma de código por sí sola tampoco basta porque el mismo programa firmado puede ejecutarse en varios lugares al mismo tiempo.

Construye la identidad que muestras y vinculas a partir de varios datos recopilados en el momento de la aprobación. En macOS, un punto de partida útil es el proceso en ejecución, la identidad de su ejecutable y su autoridad de firma de código. Apple documenta los requisitos designados como el requisito de código que identifica el código firmado, normalmente construido a partir de la autoridad de firma y del identificador integrado cuando la aplicación no proporciona uno explícito. Eso ofrece al usuario algo mejor que un PID sin contexto.

Aun así, no conviertas una autoridad de firma en una respuesta mágica. Dos procesos separados con el mismo requisito designado siguen siendo dos procesos separados. Un agente firmado puede iniciar un asistente sin firma. Un binario de desarrollo creado localmente puede tener una firma ad hoc. Un atacante que controle el proceso aprobado después de la aprobación no se vuelve seguro porque la firma original pareciera correcta.

Usa una vinculación del proceso con datos que tengan sentido en conjunto:

approval_subject = {
  process_id: 48192,
  process_start_time: "2026-07-22T14:18:03Z",
  executable_file_id: "volume:.../inode:...",
  executable_hash: "sha256:...",
  signing_requirement: "anchor ... and identifier ...",
  parent_process_id: 48001,
  launch_nonce: "random-128-bit-value"
}

Los campos exactos varían según la plataforma. La regla no cambia: el gateway necesita pruebas suficientes para rechazar una aprobación anterior cuando el sujeto anterior ya no existe. El nonce de inicio importa porque lo crea el gateway después de inspeccionar el proceso nuevo. Un cliente no puede restaurarlo de forma segura desde una caché local y llamar a eso continuidad.

No necesitas mostrar todos los campos al usuario. De hecho, hacerlo suele empeorar la tarjeta de aprobación. Muestra la autoridad de firma, el nombre del ejecutable y una descripción clara del canal de acción. Conserva la vinculación completa en el registro para revisarla más adelante.

Hay un límite importante que conviene expresar claramente. Si tu gateway no puede ver ni atestiguar el proceso que realiza la solicitud, no puede conceder una aprobación específica para ese proceso. Puede conceder una aprobación menor vinculada a otro sujeto fiable, pero no debería afirmar que ha verificado el proceso. Llamar «identidad» al nombre de proceso proporcionado por el cliente es la forma en que los diseños débiles adquieren etiquetas que suenan oficiales.

Un reinicio del proceso termina la aprobación de sesión

Una aprobación de sesión debería terminar cuando sale su proceso, aunque el proceso de reemplazo tenga el mismo código, argumentos e historial de conversación.

Esta regla detecta casos que parecen inofensivos hasta que causan daños. Supón que un agente se ejecuta mediante una extensión del editor. La extensión falla, su supervisor inicia un reemplazo y el reemplazo vuelve a cargar el estado de la tarea anterior. El proceso nuevo tiene el mismo directorio del proyecto y probablemente la misma cuenta de usuario. No tiene la autoridad concedida al proceso que falló.

Lo mismo ocurre cuando un agente crea procesos secundarios. Un proceso padre puede recibir aprobación y después iniciar un asistente para ejecutar comandos de shell o realizar llamadas de red. Si la aprobación solo se aplica al padre, el asistente debe actuar a través del padre mediante una delegación controlada o solicitar su propia aprobación. Pasar un token bearer por el árbol de procesos hace que la aprobación sea portátil exactamente de la forma que intentas evitar.

No intentes arreglarlo con un tiempo de expiración largo. Una aprobación de cinco minutos que cualquier proceso de reemplazo puede reanudar no es una aprobación de sesión de cinco minutos. Es una credencial bearer de cinco minutos con una etiqueta amable.

Una regla mejor es sencilla:

if current.process_id != approved.process_id:
    deny("approval belongs to a different process")

if current.process_start_time != approved.process_start_time:
    deny("process lifetime changed")

if current.launch_nonce != approved.launch_nonce:
    deny("gateway has not bound this run")

El gateway debería ejecutar esta comprobación antes de decidir si una solicitud puede acogerse a la aprobación de sesión. No la compruebes únicamente cuando el agente se reconecte. Un proceso puede cambiar dentro de una arquitectura de cliente que multiplexa el trabajo, y un objeto de aprobación obsoleto puede sobrevivir más de lo previsto en memoria.

Un usuario puede quejarse de que el reemplazo es evidentemente el mismo agente. Normalmente eso es una petición de una tarjeta de aprobación más fluida, no una razón para borrar el límite. Explica que el agente se reinició y muestra la nueva firma. Un clic deliberado cuesta menos que investigar una llamada de producción no deseada originada por un proceso no inspeccionado.

Un cambio en el estado de la bóveda elimina el derecho a actuar

El estado de la bóveda no es un detalle secundario. Cuando una bóveda se bloquea, cualquier decisión anterior que dependiera de su disponibilidad debe dejar de conceder permisos para acciones que usan credenciales.

Hay dos fallos que debes evitar. El primero es evidente: un gateway sigue usando una credencial descifrada después de que se bloquee la bóveda. El segundo es más silencioso: el gateway pone en cola una acción con credenciales mientras está bloqueado y la ejecuta automáticamente cuando la bóveda se desbloquea porque todavía existe una aprobación de sesión anterior. El segundo fallo convierte un desbloqueo humano posterior en la aprobación accidental de una solicitud anterior.

La documentación de Apple sobre Keychain marca claramente el límite. El control de acceso puede exigir la presencia del usuario cuando una aplicación intenta recuperar un elemento, y Apple recomienda elegir la configuración de accesibilidad más restrictiva que encaje con la aplicación. Secure Enclave puede controlar operaciones criptográficas sin exponer los datos biométricos subyacentes al software del espacio de usuario. Estos mecanismos son útiles, pero no deciden la semántica de tu gateway. Tu aplicación debe decidir qué ocurre con las ejecuciones de agentes ya aprobadas cuando ese control se cierra.

La respuesta más segura es mantener una época de la bóveda. Increméntala cada vez que la bóveda se bloquee, se desbloquee, se restablezca o pierda su sesión protegida. Vincula la época a cada registro de aprobación. Una discrepancia significa que el registro no puede autorizar una acción con credenciales.

approved_vault_epoch = 17
current_vault_epoch = 18

if approved_vault_epoch != current_vault_epoch:
    require_new_session_approval()

Esto no significa que cada desbloqueo deba convertirse en un trámite molesto. Si el agente no tiene una sesión activa, no ocurre nada. Si una solicitud necesita una credencial después del desbloqueo, el gateway puede mostrar una nueva tarjeta de aprobación que explique el motivo: el estado de la bóveda cambió después de la aprobación anterior. Para las credenciales marcadas para aprobación en cada uso, conserva también la comprobación por llamada. La aprobación de sesión y la aprobación por llamada responden a preguntas distintas.

La aprobación de sesión pregunta si este proceso identificado puede usar este canal durante su ejecución actual. La aprobación por llamada pregunta si la persona quiere permitir este uso concreto ahora. Tratar la aprobación de sesión como sustituto de una decisión por llamada elimina el sentido de marcar una credencial de esa manera.

Un reinicio del gateway borra su memoria del permiso

Un reinicio del gateway debería invalidar las aprobaciones de sesión almacenadas en memoria porque el gateway reiniciado no puede demostrar que su antiguo registro de aprobación conserva una vinculación completa y sin manipular con el mundo activo.

Algunos equipos conservan los tokens de aprobación y los vuelven a cargar después de un reinicio. La motivación es comprensible: el usuario hizo clic una vez, el agente sigue trabajando y un reinicio no debería hacer fallar el flujo. Pero un token persistente suele convertirse en una credencial reutilizable. El cliente lo envía después de reconectarse, el gateway lo reconoce y el permiso antiguo vuelve sin una nueva inspección del proceso.

Ese diseño también hace ambigua la recuperación. ¿El gateway falló antes de enviar la acción? ¿La envió y falló antes de registrar la respuesta? ¿El servicio remoto recibió dos veces la solicitud después de un reintento? Restaurar la autorización y reintentar la solicitud como una sola operación mezcla la recuperación de identidad con la recuperación de entrega. Necesitan controles distintos.

Asigna a cada ciclo de vida del gateway un identificador de arranque que exista solo en su memoria actual. Añádelo a cada registro de aprobación. Después de un reinicio, el identificador actual será diferente, así que ningún registro de sesión anterior podrá coincidir.

approval = {
  gateway_boot_id: "b7f9...",
  process_binding: "...",
  vault_epoch: 17,
  approved_at: "2026-07-22T14:20:11Z"
}

if approval.gateway_boot_id != gateway.current_boot_id:
    require_new_session_approval()

El gateway puede conservar un evento de auditoría que indique que hubo una aprobación. No debería volver a cargar ese evento como un permiso activo. El historial de auditoría explica lo ocurrido; no recrea una relación de autoridad activa.

Sallyport sigue esta estructura al mantener la bóveda en la aplicación firmada de la barra de menús y rechazar acciones mientras la bóveda está bloqueada. Su autorización por sesión está vinculada a un proceso de agente nuevo y el usuario puede revocar de inmediato una ejecución registrada. Estos límites solo son útiles si un reinicio o un bloqueo no pueden volver a conectar silenciosamente una ejecución antigua con una decisión nueva.

Vincula la aprobación a pruebas que el cliente no pueda reproducir

El registro de aprobación necesita pruebas actuales creadas por el servidor. Un token de reanudación proporcionado por el cliente puede ayudar al gateway a encontrar una conversación o mostrar una etiqueta útil, pero no puede ser la prueba de que la autorización sigue siendo válida.

El patrón práctico más pequeño usa cuatro valores cambiantes:

1. El gateway crea un identificador de arranque aleatorio al iniciarse.
2. El gateway crea un nonce de ejecución aleatorio después de identificar un proceso recién conectado.
3. La bóveda mantiene una época que cambia cada vez que cambia la disponibilidad protegida.
4. El gateway crea un identificador de aprobación solo después de que el usuario aprueba la ejecución identificada.

Después, el gateway evalúa cada acción frente a todos los valores que controla. El cliente puede solicitar una acción, pero no puede fabricar una aprobación que coincida con un identificador de arranque nuevo o un nonce de ejecución nuevo.

Este es un modelo de estado compacto que los equipos pueden adaptar. Guarda deliberadamente la referencia de conversación como contexto de presentación, nunca como campo de autorización.

{
  "run": {
    "conversation_ref": "worktree-cleanup-42",
    "process": {
      "pid": 48192,
      "started_at": "2026-07-22T14:18:03Z",
      "signing_requirement": "recorded-at-approval",
      "launch_nonce": "gateway-generated"
    }
  },
  "approval": {
    "id": "gateway-generated",
    "gateway_boot_id": "gateway-generated",
    "vault_epoch": 17,
    "expires_when_process_exits": true
  }
}

Observa lo que falta: no hay una marca reutilizable resume_authorized ni una fecha de expiración que pueda convertir un proceso muerto en un sujeto activo. Puedes conservar un tiempo de espera breve como límite adicional, pero el tiempo de espera no es identidad.

Cuando el agente se reconecte, haz que repita la inicialización y el registro del proceso. El gateway debería devolver entonces uno de estos resultados:

REAUTH_REQUIRED process_changed
REAUTH_REQUIRED gateway_restarted
REAUTH_REQUIRED vault_state_changed
RETRY_SAFE previous_action_not_started
STATUS_UNKNOWN inspect_activity_journal

La diferencia entre RETRY_SAFE y STATUS_UNKNOWN importa. Un gateway solo puede decir que una acción no comenzó si tiene pruebas duraderas de que no comenzó. Si perdió la alimentación después de entregar una solicitud HTTP a la pila de red, la respuesta honesta puede ser desconocida. El agente debería inspeccionar el destino o el registro antes de intentar una acción duplicada.

Reintentar una acción es distinto de restaurar la aprobación

Un protocolo de reconexión debería restaurar primero la comunicación, establecer después una autoridad nueva y decidir en tercer lugar si debe reintentar. Combinar esos pasos produce solicitudes duplicadas y aprobaciones heredadas.

Usa esta secuencia para una acción protegida que pierde la conexión:

1. El agente se reconecta e inicializa una relación nueva con el gateway.
2. El gateway identifica el proceso actual y lo compara con cualquier registro de ejecución vigente.
3. El gateway comprueba su identificador de arranque y la época actual de la bóveda.
4. Si cambió algún dato de autoridad, el gateway solicita una nueva aprobación de sesión antes de usar credenciales.
5. El gateway informa si sabe que la acción anterior no comenzó, terminó o tiene un estado desconocido.

El orden importa. No pidas al agente que reenvíe la solicitud original antes de establecer la autorización actual. Eso da al cliente que se reconecta la oportunidad de presionar con una solicitud antigua: «Ya tenía aprobación, solo termínala». Una persona suele ver las mismas palabras y suponer que la solicitud es una continuación inofensiva. El gateway debe hacer visible la condición modificada antes de presentar la acción.

Para las APIs HTTP, usa una clave de idempotencia cuando el destino la admita. Genera la clave para la acción empresarial lógica, regístrala de forma duradera antes de enviar y reutilízala solo cuando hayas restablecido la autorización para el reintento. Una clave de idempotencia ayuda al servicio remoto a detectar una entrega duplicada. No autoriza el reintento.

Con SSH, los reintentos requieren más cuidado porque un comando remoto puede haber modificado parcialmente una máquina antes de que se interrumpiera la conexión. Prefiere operaciones que escriban una marca explícita o consulten el estado existente antes de modificarlo de nuevo. Un comando como mkdir puede hacerse más seguro comprobando que el directorio esperado exista. Un comando que rote una credencial o reinicie un servicio normalmente debería informar de un estado desconocido después de un fallo de transporte, hasta que el agente lea el estado remoto.

No ocultes esta incertidumbre con un lenguaje optimista. Un agente que dice «el despliegue se completó» después de perder la respuesta está inventando seguridad. El registro debería indicar que no se observó el resultado de la acción y el agente debería investigar.

Los fallos desagradables revelan el límite correcto

La prueba más reveladora no es una reconexión limpia. Es un reinicio en mitad de una acción, seguido de un agente que intenta continuar por todos los medios.

Imagina un agente con aprobación de sesión para actualizar un sistema de seguimiento de incidencias mediante una API HTTP. Prepara una solicitud, recibe aprobación y llama al gateway. El gateway inyecta la credencial y empieza a enviar la solicitud. En ese momento, la aplicación del gateway se reinicia. El agente se reconecta con su referencia de conversación anterior y un estado local de herramientas almacenado en caché.

Un diseño débil acepta la referencia anterior, restaura la aprobación y reintenta la solicitud. La incidencia puede recibir dos comentarios. Peor aún, la aprobación se aplica al proceso que ahora proporciona el estado almacenado en caché.

Un diseño cuidadoso produce un resultado menos atractivo. El gateway reiniciado crea un identificador de arranque nuevo. Rechaza el permiso de sesión anterior. Solicita aprobación para el proceso conectado en ese momento. Comprueba el registro de actividad. Si el registro muestra que la solicitud terminó, devuelve el resultado. Si muestra que ninguna solicitud salió del gateway, permite un reintento nuevo y aprobado. Si la acción cruzó el límite de entrega pero se perdió el resultado, informa de un estado desconocido. El agente lee la incidencia antes de decidir si necesita otra escritura.

Eso requiere más trabajo que confiar en el token de reanudación. También marca la diferencia entre un sistema de acciones trazable y otro que oculta la ambigüedad hasta que el usuario encuentra cambios duplicados.

Prueba al menos estos casos antes de considerar seguro el comportamiento de reanudación:

• Mata el agente después de la aprobación y después inicia un reemplazo que presente la misma referencia de conversación.
• Reinicia el gateway mientras un agente aprobado sigue activo e intenta otra llamada con credenciales.
• Bloquea y desbloquea la bóveda mientras un agente aprobado espera para reintentar.
• Inicia dos procesos de agente idénticos y firmados, y comprueba que la aprobación de uno no cubra al otro.
• Pierde la respuesta de red después de que el gateway inicie una solicitud externa y verifica que la ruta de reintento informe de la incertidumbre de entrega.

Estas pruebas detectan un error especialmente común: los ingenieros solo comprueban si el cliente legítimo puede recuperarse. No comprueban si otro cliente puede tomar prestada la ruta de recuperación.

Los registros deben explicar por qué terminó la autoridad

Un registro de auditoría debería registrar los cambios de autoridad como eventos de primer nivel, sin obligar al investigador a deducirlos a partir de los huecos entre llamadas a herramientas.

Registra la aprobación de sesión con los datos de identidad del proceso que usaste, el identificador de arranque del gateway, la época de la bóveda y el sujeto visible para el usuario. Registra el evento de finalización con un motivo concreto: el proceso terminó, hubo una discrepancia de identidad, el gateway se reinició, la bóveda se bloqueó, hubo una revocación manual o la aprobación expiró. Registra una acción rechazada por separado de una acción ausente. Son hechos distintos.

Una secuencia de actividad útil sería esta:

14:20:11 session_approved run=R31 signer="Example Developer ID" boot=B8 vault=17
14:23:04 gateway_restarted previous_boot=B8 current_boot=C2
14:23:06 action_denied run=R31 reason=gateway_restarted
14:23:09 session_approved run=R32 signer="Example Developer ID" boot=C2 vault=17
14:23:12 http_action_started run=R32 request=Q44
14:23:13 http_action_result run=R32 request=Q44 status=201

El objetivo no es exponer valores secretos ni cuerpos completos de solicitudes en cada entrada del registro. El objetivo es conservar la cadena causal: quién solicitó la acción, qué autoridad se aplicó, qué estado cambió y si el gateway realizó realmente la acción.

La evidencia de manipulación importa porque un historial de aprobaciones solo sirve si alguien puede detectar una modificación posterior. Sallyport proyecta sus registros Sessions y Activity desde un registro de auditoría cifrado, encadenado mediante hashes y de escritura ciega, y sp audit verify puede verificar esa cadena sin conexión sobre el texto cifrado y sin una clave de bóveda. Así, una persona puede verificar la secuencia sin abrir los secretos que hicieron posibles las acciones.

No hagas que el registro de auditoría cargue con la responsabilidad de prevenir. Un registro perfecto que dice que se reutilizó una aprobación antigua es una prueba de una mala decisión, no una solución. El gateway activo debe rechazar la acción antes de inyectar credenciales cuando la vinculación ya no coincida.

La reaprobación debe ser concreta para justificar la interrupción

La reaprobación después de un cambio importante de estado está justificada, pero un aviso impreciso enseña a los usuarios a aceptarlo sin leer. La tarjeta de aprobación debería indicar qué cambió y quién solicita el acceso ahora.

Evita un mensaje genérico como «La sesión expiró. ¿Quieres aprobarla de nuevo?». Esa redacción hace que el usuario trate el evento como un simple temporizador. Muestra en su lugar la condición que rompió la continuidad: «El gateway se reinició. Aprueba este proceso recién conectado para usar la API de alojamiento de Git durante esta ejecución». Si cambió la identidad del proceso, muestra la nueva autoridad de firma o indica que el programa no está firmado. Si la bóveda se bloqueó, explica que desbloquearla no restauró la aprobación anterior del agente.

Aquí también decides si la aprobación de sesión es demasiado amplia para un canal. Si un agente reanudado quiere hacer un cambio en producción mediante SSH, la aprobación por llamada puede ser la opción sensata incluso después de una nueva decisión de sesión. Que la sesión haya superado todas las comprobaciones no hace que todos los comandos tengan el mismo nivel de seguridad.

No intentes resolver la fatiga de aprobación haciendo que las aprobaciones sean transferibles. Resuélvela reduciendo los cambios innecesarios, mostrando una identidad de proceso estable cuando exista y manteniendo comprensible el alcance de cada decisión. El usuario puede aprobar una solicitud concreta. No puede aprobar de forma segura la promesa de que cualquier proceso futuro con una transcripción antigua podrá actuar.

La regla de implementación cabe en una nota adhesiva: conserva el contexto durante la reanudación, pero reconstruye la autoridad a partir de pruebas activas. Cuando cambie el proceso, la bóveda o el gateway, la aprobación antigua pertenece a la ejecución anterior.