Cómo cambia el control con aprobación local o externa

Un botón de aprobación no es una propiedad de seguridad por sí solo. Su valor depende de dónde se aplica la decisión, qué puede ver quien revisa, qué identidad registra el servicio y qué ocurre tras un tiempo de espera o una conexión rota.

Cuando un agente de IA llama a una API, la aprobación local y la aprobación externa responden preguntas distintas. Una puerta local decide si ese proceso puede usar una credencial o enviar una solicitud preparada. La puerta del proveedor decide si el sistema remoto debe aplicar el cambio a su recurso. Si la API ya pide confirmación, rara vez conviene «elegir la más estricta». Hay que colocar cada decisión donde se conoce el hecho evaluado y unir después sus pruebas.

Una pantalla clara puede ocultar un hueco de autorización. Una persona puede aprobar localmente «desplegar la versión 184», mientras el servicio recibe un token reutilizable y otro cuerpo. También puede existir una aprobación remota sin que el proveedor sepa qué proceso preparó la petición. Ambos registros pueden ser ciertos y aun así no explicar la acción.

Las puertas local y externa autorizan cosas distintas

La aprobación local autoriza el uso de una capacidad antes de que la petición salga del equipo. La aprobación externa autoriza una transición dentro del servicio dueño del recurso. Confundirlas elimina contexto del llamador o contexto del recurso.

La puerta local está junto al agente, la bóveda de credenciales, el ejecutor de comandos o la pasarela de salida. Puede comprobar el ejecutable, la firma de código, el proceso padre, la sesión, la credencial elegida, el host, el método y los argumentos. También puede conservar el secreto fuera del agente y ejecutar la llamada. Responde si ese proceso local puede ejercer esa capacidad ahora.

La puerta externa vive en el proveedor de la API o en su plano de control. Ve la versión actual, la pertenencia a la organización, el entorno protegido, las políticas, los conflictos y la identidad remota de quien aprueba. Responde si debe producirse esa transición exacta con el estado actual.

La publicación NIST SP 800-207 describe puntos de decisión y de aplicación de políticas, y recomienda acercar la aplicación al recurso para reducir la zona de confianza implícita. Eso respalda el control externo para hechos que solo conoce el dueño del recurso, pero no vuelve innecesaria la puerta local. Un servicio no conoce el proceso local si el cliente no transmite y vincula esa identidad. Una llamada con token al portador suele identificar al titular del token, no al proceso que la provocó.

OpenSSH ilustra el otro lado. El manual de ssh-add de OpenBSD indica que -c exige confirmación antes de usar una identidad cargada. Después, el servidor SSH remoto aplica su propia autorización. Una puerta decide si el cliente puede usar la clave; la otra decide si la autenticación cumple la política del servidor. Ninguna duplica a la otra.

La aprobación debe aplicarla el componente capaz de impedir la acción descrita. Una notificación local que no puede retener la credencial o la llamada es decorativa. Un comentario externo creado después del cambio es una revisión, no una autorización.

La matriz parte del hecho que se revisa

La puerta principal se elige por lo que puede conocer y aplicar, no por el número de avisos.

<table> <thead><tr><th>Criterio</th><th>Aprobación local</th><th>Aprobación externa</th><th>Consecuencia</th></tr></thead> <tbody> <tr><td>Latencia</td><td>Una interacción local más la llamada</td><td>Red, cola, aviso y espera de la persona</td><td>Usar local para llamadas frecuentes y reversibles si basta su contexto</td></tr> <tr><td>Contexto del agente</td><td>Vincula proceso, sesión, firma, herramienta y usuario</td><td>Suele ver token, aplicación o cuenta de servicio</td><td>Mantener la puerta local si importa la procedencia del proceso</td></tr> <tr><td>Contexto del recurso</td><td>Ve estado obtenido o aportado, que puede quedar obsoleto</td><td>Evalúa versión, reglas, propiedad y conflictos actuales</td><td>Revisar fuera cuando la seguridad depende del estado remoto vivo</td></tr> <tr><td>Identidad humana</td><td>Vincula a la persona presente en el equipo</td><td>Vincula cuenta, rol o separación de funciones</td><td>Usar el dominio que asume la responsabilidad o guardar ambos</td></tr> <tr><td>Exposición de credenciales</td><td>Mantiene el secreto fuera del agente</td><td>Puede empezar cuando el cliente ya tiene la credencial</td><td>La aplicación local es obligatoria si importa la custodia</td></tr> <tr><td>Caída del servicio</td><td>Deniega y conserva una intención pendiente</td><td>No aprueba sin proveedor o plano de aprobación</td><td>Definir caducidad y cancelación sin convertir fallos en consentimiento</td></tr> <tr><td>Caída local</td><td>Bloquea llamadas en ese equipo</td><td>Puede seguir disponible desde otro cliente fiable</td><td>Decidir si ese cliente alternativo es válido o un rodeo</td></tr> <tr><td>Auditoría</td><td>Registra avisos, rechazos, salidas e intentos</td><td>Registra peticiones aceptadas y cambios definitivos</td><td>Unir registros con un identificador estable</td></tr> <tr><td>Límite de manipulación</td><td>Un host comprometido puede atacar interfaz o registro</td><td>El proveedor controla su registro</td><td>No pedir a un registro que pruebe hechos fuera de su frontera</td></tr> <tr><td>Cobertura</td><td>Envuelve muchas API de forma uniforme</td><td>Solo cubre operaciones protegidas por el proveedor</td><td>Inventariar rutas sin protección</td></tr> </tbody> </table>

No convierta la tabla en una puntuación con ganador universal. Algunas filas son vetos. Si el agente nunca debe recibir la clave de API, una confirmación externa no resuelve su exposición. Si producción exige una persona del grupo de operaciones, el Touch ID local del desarrollador que lanzó el agente no satisface la separación de funciones.

Clasifique la acción. Las lecturas de poco riesgo pueden necesitar autorización de sesión sin aviso por llamada. Las escrituras reversibles admiten puerta local, caducidad corta y clave de idempotencia. Las transiciones irreversibles o reguladas suelen necesitar revisión externa porque el servicio posee el estado final y la identidad organizativa. Si una acción combina uso de secretos y transición irreversible, pueden hacer falta ambas puertas, siempre que cada aviso explique su propia decisión.

La latencia incluye espera, caducidad y recuperación

La aprobación local suele responder antes, pero la medida útil es el tiempo hasta un resultado seguro e inequívoco. Un aviso rápido seguido de un reintento incierto no ofrece baja latencia.

Con una persona supervisando el agente en un Mac, la tarjeta local aparece mientras el contexto sigue fresco. Puede servir para abrir una solicitud de cambios rutinaria, consultar una API interna protegida o ejecutar un comando SSH conocido en una sesión atendida, siempre que la consecuencia sea visible allí.

Los flujos externos añaden colas. El servicio crea un objeto pendiente, elige revisores, envía el aviso, espera una identidad de la organización, vuelve a evaluar la política y aplica la transición. Ese tiempo merece la pena si crea separación de funciones o muestra estado autoritativo. Es desperdicio si la misma persona aprueba dos veces la misma carga sin información nueva.

La documentación de entornos de GitHub da un ejemplo útil. Un trabajo con revisores obligatorios espera antes de comenzar y no accede a los secretos del entorno hasta ser aprobado. También puede impedir la autorrevisión. La espera controla estado, secretos y una relación organizativa que una pantalla local no puede reproducir mostrando una dirección de correo.

Mida cuatro intervalos: creación a aviso, aviso a decisión humana, decisión a ejecución y ejecución a resultado definitivo. Incluya rechazos y caducidades. Una mediana que omite solicitudes abandonadas maquilla un flujo roto.

La frecuencia modifica la conducta. Cincuenta avisos para lecturas parecidas enseñan a pulsar sin leer, tanto localmente como fuera. Agrupe solo acciones con capacidad acotada, objetivos claros y vida corta. Las transiciones destructivas deben seguir separadas.

La caducidad depende de cuánto cambien los hechos. Diez minutos pueden ser demasiado para una rama en movimiento y poco para una revisión formal. No renueve en silencio. Un cambio de carga, versión, credencial o revisores exige otra decisión.

El contexto decide si se puede juzgar

Un aviso útil contiene el conjunto mínimo y completo de hechos. Las dos ubicaciones ven mitades distintas, así que copiar una pantalla rara vez funciona.

La parte local debe mostrar identidad del ejecutable, autoridad de firma, sesión padre, herramienta, alias de credencial, destino, operación y resumen legible. Debe separar datos observados por la pasarela de texto aportado por el agente. «Limpieza segura» es una afirmación, no una prueba.

La parte externa debe mostrar objeto y transición definitivos: repositorio, entorno, cuenta, región, versión, diferencia, controles, iniciador y revisores habilitados. No debe fingir conocer la procedencia local si solo recibió un token.

Vincule intención y ejecución con un resumen de campos canónicos. action_id une sistemas y el resumen evita que una carga posterior use una aprobación anterior.

{
  "action_id": "act_01JQ7M6F4R2K",
  "session_id": "ses_01JQ7KZ9J1AA",
  "caller": {
    "executable": "/usr/local/bin/agent",
    "signing_authority": "Developer ID Application: Example Team"
  },
  "target": {
    "service": "deploy-api",
    "resource": "production/payments",
    "version": "184"
  },
  "request": {
    "method": "POST",
    "operation": "promote",
    "body_sha256": "98b0...e42c"
  },
  "approval": {
    "scope": "single_action",
    "expires_at": "2026-07-24T14:05:00Z"
  }
}

El ejecutor recalcula body_sha256, compara recurso y versión, comprueba la caducidad y consume una vez la aprobación. Un argumento cambiado debe cerrar el paso. Cuando el proveedor lo admita, la petición lleva action_id en metadatos o correlación sin alterar campos de negocio.

Una captura no vincula bytes. Ayuda a comprender, pero el código debe relacionar lo aprobado con lo enviado. He visto interfaces resumir un objeto y ejecutar otro montado después. Hay que revisar la serialización, no solo la tarjeta.

La identidad tiene tres actores

Una acción tiene al menos el proceso proponente, el principal de credencial que ejecuta y la persona que aprueba. Meterlos en un único campo actor crea un registro atractivo que responde mal.

La identidad del proceso incluye ruta, hash, firma, padre, sesión de protocolo y usuario local. Nada de eso se convierte automáticamente en identidad remota. La API suele ver un cliente OAuth, cuenta de servicio, clave de despliegue, sesión de rol o token de usuario.

La persona aprobadora pertenece a otro dominio. Una confirmación biométrica local puede probar presencia según el sistema operativo, pero no su rol actual en la organización. Una cuenta externa prueba membresía y separación, pero quizá ignore qué binario local pidió la acción.

<table> <thead><tr><th>Identidad</th><th>Prueba</th><th>Pregunta</th></tr></thead> <tbody> <tr><td>Proponente</td><td>Firma, hash y sesión</td><td>¿Qué código pidió la acción?</td></tr> <tr><td>Ejecutor</td><td>Principal API, huella SSH o sesión de rol</td><td>¿Qué autoridad hizo la llamada?</td></tr> <tr><td>Aprobador</td><td>Presencia local o cuenta organizativa</td><td>¿Quién aceptó el riesgo?</td></tr> </tbody> </table>

Si cinco procesos comparten un token al portador, el registro externo nombra bien al principal pero no distingue procesos. La pasarela local aporta esa procedencia si sus registros resisten cambios casuales y se correlacionan con el evento remoto.

No llame aprobador al agente cuando pulsó una persona, ni llamador API a la persona cuando ejecutó una cuenta de servicio. Registre la delegación: P propuso A, H autorizó S y E aplicó R.

La separación de funciones favorece al proveedor cuando posee los grupos y evita autorrevisión. La presencia y procedencia favorecen al control local. Si se exigen ambas, pida pruebas distintas, no dos clics de la misma persona.

Una caída debe dejar un estado duradero

Los sistemas fallan cuando tratan errores de red como problemas visuales. La acción necesita una máquina de estados persistente que sobreviva a procesos terminados, respuestas perdidas y recuperación del servicio.

Use estados explícitos: created, locally_approved, submitted, upstream_pending, executing, succeeded, denied, expired y unknown. Los estados finales no retroceden. Cada transición guarda resumen y hora. Tras reiniciar se puede observar una solicitud pendiente, pero no crear otra mutación salvo que las reglas permitan reintentar.

Reglas seguras:

1. Sin puerta local, ninguna acción controlada sale del equipo.
2. Sin plano externo, lo que lo requiere queda pendiente o caduca.
3. Con aprobación pero resultado desconocido, se consulta por acción o idempotencia antes de reintentar.
4. Si cambia el recurso durante la espera, se invalida o reevalúa la decisión.
5. Ante rechazo o revocación, se cancela lo pendiente y se registra si la cancelación llegó.

Abrir el paso por fallo no es recuperación. Un acceso de emergencia puede ser legítimo, pero es otra operación privilegiada: persona identificada, alcance estrecho, duración corta y registro propio. Ocultarlo como «reintentar sin aprobación» elimina el control durante el incidente.

Las caídas no son simétricas. La puerta local puede registrar un intento que nunca llegó al proveedor. El proveedor puede terminar después de que muera el proceso y dejar el registro local en submitted. La conciliación debe aceptar conocimiento incompleto.

Diseñe la cancelación: si se retira una acción aprobada en cola, si caduca mientras se ejecuta y qué ocurre en una carrera entre rechazo y finalización. El estado remoto dice qué pasó; el registro de aprobación dice si estaba autorizado.

Un reintento no puede gastar dos veces la aprobación

Aprobación y ejecución son operaciones separadas. El mayor riesgo aparece cuando se aprueba una mutación, se envía, se pierde la respuesta y se envía otra vez.

RFC 9110 define idempotencia por el efecto esperado de repetir una solicitud idéntica. Desaconseja reintentar automáticamente una petición no idempotente salvo que se conozca su semántica o que la primera no se aplicó. La aprobación no cambia esa regla. Consentir un pago, despliegue o borrado no autoriza intentos ilimitados.

Genere la clave de idempotencia al crear la intención inmutable, vincúlela al resumen y consérvela en reintentos seguros. El proveedor debe devolver el resultado anterior o permitir consultarlo. Si no ofrece ninguna opción, mueva mutaciones ambiguas a unknown y concilie.

Separe identificador de aprobación e idempotencia. El primero puede permitir un intento, reintentos idénticos acotados o una capacidad de sesión. El segundo dice al servicio que la mutación debe tener un solo efecto. Un token con ambos significados complica caducidad, revocación e investigación.

Prueba reproducible:

1. Cree una acción aprobada con action_id, resumen y clave fijos.
2. Envíela y corte la conexión después de salir el cuerpo.
3. Reinicie el agente y recupere el estado guardado.
4. Compruebe que consulta al proveedor antes de reintentar.
5. Confirme una sola transición y una cadena enlazada de intentos.

Repita con aprobación pendiente y con aprobación caducada durante el corte. Si el reinicio crea otro aviso e identificador, rompió la cadena.

En una API con prepare y confirm, confirme que el segundo consume una vez un objeto inmutable o usa idempotencia. Si confirm vuelve a aceptar campos del cliente, puede ser otra mutación con un nombre tranquilizador.

La auditoría completa une intención, decisión, intento y resultado

Un registro único solo es completo si observa intención, decisión, intento, aceptación y estado final. Normalmente la integridad procede de unir registros de varias fronteras.

El registro local incluye rechazos y caducidades que nunca llegan fuera, identidad de proceso y sesión, versión del resumen mostrado, hash de carga, alias de credencial, decisión, intento, código y dudas. El externo guarda principal definitivo, objeto de aprobación, revisor, política, versión, ejecución y resultado.

Use action_id estable y añada identificadores del proveedor. No una solo por hora: desfase, lotes y concurrencia acabarán produciendo coincidencias falsas.

{
  "event_id": "evt_01JQ7N2AZ8S4",
  "action_id": "act_01JQ7M6F4R2K",
  "phase": "upstream_result",
  "observed_by": "local_gateway",
  "principal": "service-account:deploy-agent",
  "approver": "org-user:release-reviewer",
  "payload_sha256": "98b0...e42c",
  "provider_event_id": "dep_91358",
  "outcome": "succeeded",
  "recorded_at": "2026-07-24T14:02:18Z"
}

Una cadena hash o almacén anexable detecta cambios posteriores, pero no prueba que ocurrió un evento omitido. Las pruebas comparan fases esperadas según la clase. Una lectura necesita intención, decisión local, intento y respuesta. Un despliegue protegido añade espera, decisión externa, ejecución y versión final.

La documentación de AWS CloudTrail muestra la identidad del proveedor: eventos de IAM Identity Center distinguen usuario, rol, usuario federado u otro servicio, y algunos llevan identificadores de Identity Center. Es prueba definitiva del lado remoto, pero no revela qué proceso local formó la petición si no se propaga correlación.

Audite también rutas de escape: credencial directa, perfiles CLI alternativos, endpoints sin protección, bypass administrativo y repetición de objetos aprobados. La declaración de cobertura debe enumerar canales controlados, no afirmar sin inventario que todo se aprueba.

Dos puertas solo sirven si son independientes

Combine ambas cuando controlen hechos o personas diferentes. Quite una cuando repita la misma decisión y cree fatiga.

En un buen despliegue, la puerta local verifica el proceso y autoriza la capacidad para un candidato inmutable sin entregar credenciales. El entorno remoto pide después a operaciones que revise comprobaciones y estado actual. El registro une dos decisiones, una acción y una versión.

En uno malo, «¿desplegar producción?» aparece dos veces a la misma persona. No hay hash ni versión, las aprobaciones no caducan y el agente conserva el token. El segundo clic solo añade demora.

«Aprobar siempre cerca del recurso» es una recomendación incompleta. La aplicación cercana es correcta para la verdad del recurso, pero no resuelve custodia ni identidad del proceso. Conserve la puerta local si debe decidir qué proceso usa una capacidad o impedirle ver el secreto.

Sallyport cumple esa función local para HTTP y SSH: el agente conecta por su adaptador MCP, los secretos siguen en la bóveda cifrada y la aplicación ejecuta la acción. Su autorización por sesión y la aprobación opcional por uso no sustituyen al entorno protegido ni al revisor de la API; aportan prueba local del proceso y del uso de credenciales.

Escriba para cada puerta: «impide X porque solo ella observa Y y aplica Z». Si ambas frases contienen los mismos elementos, consolide. Si un componente no puede detener la acción descrita, arregle antes el punto de aplicación.

Un despliegue revela las uniones que faltan

Imagine que un agente promueve la versión 184 a producción y la API ya exige revisión. La intención debe conservarse durante aprobación local, espera externa, ejecución y conciliación.

El agente propone entorno, versión, versión actual esperada e idempotencia. La pasarela asigna action_id, registra sesión y hash, y decide si pide aprobación. Esta solo autoriza ese resumen por poco tiempo. La pasarela inyecta la credencial y envía la petición.

El proveedor crea un despliegue pendiente. El revisor ve controles actuales, entorno, versión e identidad organizativa. La aprobación consume ese objeto. Si producción cambió, se rechaza o reabre la revisión en vez de aplicar consentimiento obsoleto.

Corte ahora la conexión tras la aprobación. El lado local no devuelve éxito ni vuelve a promover. Guarda unknown, consulta por ID o idempotencia y registra el resultado definitivo. Si hubo éxito, cierra la acción existente. Si no hay registro, puede reintentar bajo el contrato original mientras siga válida la aprobación.

La prueba descubre preguntas ocultas: si el agente cambia la versión tras el clic, si otro cliente confirma, si el rechazo externo revoca lo local, si el bypass aparece unido y si se puede identificar el proceso sin confiar en su etiqueta.

Use solo aprobación local cuando todo el riesgo sea el uso de la capacidad y la operación remota sea rutinaria, acotada y recuperable. Use solo la externa cuando clientes fiables ya tengan credenciales y la decisión dependa del estado o rol remoto. Use ambas cuando importen custodia o procedencia local y revisión autoritativa remota.

Dos aprobaciones no garantizan seguridad. Hacen visibles dos decisiones. La seguridad exige vincularlas a intención inmutable, aplicarlas donde se conoce el hecho, tratar la incertidumbre sin duplicar efectos y conservar pruebas suficientes para reconstruir el resultado.