El ciclo de credenciales y la ejecución necesitan dueños distintos

Un gestor de secretos debe decidir qué credencial existe, cuándo caduca y cómo deja de ser válida. Una pasarela de escritorio debe decidir si este proceso puede realizar esta acción ahora, ejecutar la acción sin entregar la credencial al proceso y registrar lo ocurrido. Combinar ambas tareas parece más sencillo hasta que la primera rotación, revocación o investigación pregunta qué componente estaba realmente a cargo.

La frontera depende de quién posee la credencial en el momento de usarla, no de dónde se almacena. HashiCorp Vault o un flujo basado en 1Password puede seguir siendo la autoridad del ciclo de vida mientras una pasarela controla la ejecución, pero solo si el traspaso conserva el estado y la identidad del ciclo de vida sin convertir la pasarela en una caché sin control. Si la pasarela copia un valor, olvida su concesión y sigue usándolo, el diagrama tiene dos cajas, pero el sistema tiene dos gestores de secretos.

Este patrón merece el trabajo adicional cuando agentes autónomos pueden llegar a API de producción o destinos SSH. Esos agentes necesitan acciones limitadas y control humano. No necesitan otra forma de leer credenciales.

La frontera está antes de la acción autenticada

El sistema de ciclo de vida es responsable de crear, rotar, caducar y revocar credenciales; la pasarela de ejecución es responsable de liberar cada acción autenticada. Esa frase es la prueba de arquitectura. Cada campo, caché, reintento y entrada de registro debe tener un solo lado que responda por él.

Ser dueño del ciclo de vida implica más que guardar una cadena cifrada. Para una cuenta dinámica de base de datos, incluye el rol que crea la cuenta, el ID de concesión, el TTL, las reglas de renovación y la operación que elimina o desactiva la cuenta. Para un token API estático, incluye el emisor, la generación vigente, la hora de activación, cualquier periodo de solapamiento y la prueba de que la generación anterior dejó de funcionar. Un gestor de contraseñas puede guardar el registro autorizado, pero la API remota sigue decidiendo si acepta el token.

La responsabilidad de ejecución empieza cuando un solicitante pide un efecto como GET /billing/invoices, POST /deployments o un comando SSH en un host concreto. La pasarela autentica al solicitante, comprueba la aprobación local, resuelve la credencial autorizada, la inyecta en el protocolo de salida y devuelve solo el resultado. No debe ofrecer al agente una acción genérica read secret. Eso volvería a convertir la ejecución en distribución de secretos.

Por tanto, una interfaz limpia nombra una acción y una referencia de credencial, no un valor de credencial. También nombra la generación esperada para impedir que una solicitud retrasada cruce una rotación sin advertirlo. Un sobre de solicitud útil tiene esta forma:

{
  "action_id": "01J...",
  "credential_ref": "vault:database/creds/agent-readonly",
  "expected_generation": "lease:database/creds/agent-readonly/2f6a...",
  "purpose": "read migration status",
  "target": "db-admin.internal",
  "caller": {
    "session_id": "sess_7f2...",
    "process_authority": "signed:TEAMID.example.agent"
  }
}

La pasarela puede obtener el valor interno, porque algún componente debe colocar bytes en una cabecera Authorization o en un intercambio SSH. La condición es que lo obtenga dentro de la ruta de ejecución de confianza, lo mantenga fuera de argumentos, variables de entorno, archivos, resultados de herramientas y mensajes de error visibles para el agente, y después lo descarte según una regla de caché documentada. Que el agente no tenga secretos no significa que ningún componente procese texto sin cifrar.

La autoridad del ciclo debe crear y retirar credenciales

Usa Vault como dueño del ciclo de vida cuando su motor de secretos pueda crear y revocar la credencial en el sistema de destino. Usa un flujo basado en 1Password como dueño de una credencial estática solo cuando ese flujo también actualice al emisor, registre la nueva generación y retire la anterior. Guardar únicamente el valor más reciente es gestión de inventario, no rotación.

La documentación de concesiones de Vault de HashiCorp hace explícito el contrato. Cada secreto dinámico tiene una concesión con una duración y un indicador de renovación. Vault promete validez durante ese periodo, pero tras el vencimiento el consumidor ya no puede suponer que la credencial funciona. Revocar una concesión invalida el secreto e impide renovarlo; en los motores compatibles, Vault también ejecuta la limpieza subyacente, como borrar una credencial de nube o un usuario de base de datos generado.

Ese comportamiento convierte a Vault en el dueño natural de las credenciales dinámicas compatibles. La pasarela debe solicitar o recibir una concesión, respetar el TTL devuelto y dejar de usarla antes de que termine. Nunca debe inventar una vida local más larga. HashiCorp también advierte que el incremento solicitado para una renovación es orientativo y que los clientes deben revisar la respuesta. Una pasarela que pide otra hora y supone que la obtuvo ya ha roto la propiedad del ciclo de vida.

El motor KV de Vault es diferente. La documentación de Vault dice que KV no emite concesiones, aunque una respuesta muestre una duración. Guardar un token API en KV no lo vuelve dinámico, y borrar una versión anterior de KV no revoca necesariamente el token ante su emisor. El flujo de rotación debe llamar al proveedor, comprobar el reemplazo, actualizar el registro autorizado y desactivar el token anterior.

La misma salvedad se aplica a 1Password. Su documentación de CLI describe referencias de secretos y comandos como op run, op read y op inject. Esos mecanismos recuperan un secreto almacenado durante la ejecución. Por sí solos no rotan una clave API genérica de un tercero ante su emisor. Un equipo puede mantener en 1Password el registro autorizado, pero la automatización que lo rodea debe encargarse de actualizar el sistema remoto y retirar el valor anterior.

No asignes la propiedad del ciclo de vida por categoría de proveedor. Asígnala según el control demostrado sobre el emisor y un cambio de generación observable.

Un traspaso seguro lleva referencia y concesión

La pasarela necesita una referencia que pueda resolver, un límite de validez y una vía de revocación. Pasar solo una referencia resuelve el nombre, pero pierde el tiempo. Pasar solo una fecha de caducidad pierde la autoridad capaz de revocar. Pasar solo el valor secreto pierde ambas cosas.

Para los secretos dinámicos de Vault, el identificador natural de generación es el ID de concesión. La respuesta de vault read database/creds/my-role incluye lease_id, lease_duration, lease_renewable, username y password. La pasarela debe unir los bytes de la credencial y estos metadatos en un solo objeto. No debe guardar la contraseña en una caché y la concesión en otra que pueda desfasarse.

Para un registro estático de 1Password, crea un marcador de generación inmutable dentro del flujo de rotación. Puede ser un identificador de versión expuesto por la integración elegida o un ID de evento de rotación guardado junto a la referencia. No uses un nombre mutable como prod-api-key a modo de generación. El nombre indica dónde resolver, pero no demuestra qué valor recibió la pasarela.

El contrato de traspaso debe incluir estas propiedades:

• credential_ref identifica el origen sin contener material secreto.
• generation cambia cada vez que cambia la credencial utilizable.
• not_after da a la pasarela una hora límite local cuando existe.
• revocation_ref indica a las herramientas de respuesta qué objeto revocar o retirar.
• issued_for vincula la credencial con el rol, destino y entorno previstos.

La respuesta de la pasarela debe repetir las partes no secretas para que el solicitante y el sistema de auditoría puedan relacionar un efecto sin conocer la credencial:

{
  "action_id": "01J...",
  "status": 200,
  "credential_ref": "vault:database/creds/agent-readonly",
  "generation": "lease:database/creds/agent-readonly/2f6a...",
  "executed_at": "2026-07-27T14:03:12Z",
  "result_digest": "sha256:9b0..."
}

Este contrato también revela una verdad incómoda: una pasarela de escritorio necesita identidad de máquina propia para obtener datos del sistema de ciclo de vida. Esa credencial inicial también tiene un ciclo. Un token de Vault debe tener una política limitada y su propio TTL o comportamiento de renovación. Un token de cuenta de servicio de 1Password solo debe llegar a las bóvedas necesarias. Ocultar el token inicial en un archivo de ajustes local solo desplaza el problema original un nivel.

La caducidad debe imponerse a cachés y reintentos

La caducidad sobrevive al traspaso únicamente si cada ruta de ejecución compara la hora actual con el límite devuelto por la autoridad del ciclo de vida. La pasarela debe rechazar una acción nueva cuando el tiempo restante no alcance para resolver la referencia, aprobar, conectar, ejecutar y dejar un pequeño margen de reloj.

Supongamos que Vault emite una credencial de base de datos por diez minutos. Un agente inicia una exportación en el minuto nueve, el usuario tarda cuarenta segundos en leer una tarjeta de aprobación y la pasarela reintenta dos veces tras un corte de red. Una caché que solo comprobó el TTL al obtener la credencial puede iniciar el último reintento después del vencimiento. El destino devuelve entonces un error de autenticación, pero el registro puede clasificarlo erróneamente como fallo de red o rechazo del usuario.

Fija una vez la fecha límite utilizable a partir de los metadatos autorizados:

usable_until = min(authority_not_after, fetched_at + local_cache_cap)
latest_start = usable_until - approval_budget - connect_budget - clock_margin

Los márgenes son decisiones operativas, no ampliaciones de la vida de la credencial. Si now es posterior a latest_start, obtén una generación nueva y muestra una aprobación nueva si la acción aprobada cambiaría de forma sustancial. Nunca renueves una concesión de Vault solo para rescatar una solicitud que esperó en una cola local. La renovación es una decisión del ciclo de vida y puede ampliar el periodo de exposición.

Los reintentos necesitan la misma disciplina. Un reintento puede reutilizar una credencial solo si la generación coincide, la credencial sigue dentro de su límite útil y la operación remota se puede repetir sin riesgo. La idempotencia HTTP y la validez de la credencial son comprobaciones distintas. Un token válido no vuelve inocuo un POST duplicado.

Para credenciales estáticas sin una caducidad proporcionada por el emisor, usa un límite local de caché para reducir la vida de las copias antiguas, pero llámalo política de caché, no caducidad. El flujo del ciclo de vida aún necesita una notificación de generación o una resolución forzada tras la rotación. De lo contrario, la pasarela puede seguir usando un token anterior todavía válido durante el solapamiento y hacer que la prueba de retirada parezca exitosa hasta que el proveedor lo desactive de verdad.

La revocación es un evento de extremo a extremo

La revocación solo funciona cuando la autoridad del ciclo de vida desactiva la credencial ante el emisor y la pasarela detiene cualquier uso futuro de su generación en caché. Limpiar un solo lado no basta.

Vault ofrece a los operadores un mecanismo concreto. vault lease revoke invalida una concesión y la revocación por prefijo puede invalidar las concesiones de una ruta. La documentación de comandos de HashiCorp también distingue entre revocación normal y eliminación forzada. La eliminación forzada puede hacer que Vault olvide una concesión aunque el motor de secretos no haya podido revocarla, lo que deja a Vault desincronizado del destino. Trata esa advertencia como un incidente, no como un mensaje de limpieza correcta.

Una pasarela de escritorio debe recibir una señal de revocación cuando el sistema de ciclo de vida pueda enviarla, pero también necesita una defensa que consulte el estado actual. Antes de un uso sensible puede volver a validar la generación o resolverla de nuevo. Para concesiones cortas de Vault, un TTL estricto y una caché breve pueden bastar. Para un token API estático, el coordinador de rotación debe invalidar la caché de la pasarela durante el cambio y probar el token retirado directamente contra un endpoint inocuo.

Las acciones que ya se están ejecutando necesitan una regla explícita. La revocación puede bloquear de forma fiable las acciones que no han empezado. Puede no deshacer una solicitud ya aceptada por una API remota, una transacción confirmada o un comando SSH entregado al shell. La pasarela debe marcar el estado como authorized, dispatched, acknowledged o unknown, en lugar de afirmar que la revocación borró el efecto.

Prueba toda la ruta conservando la generación anterior en una herramienta controlada:

1. Ejecuta una lectura inocua mediante la pasarela y registra la generación.
2. Revoca la concesión o rota y desactiva la credencial estática ante el emisor.
3. Intenta la misma acción mediante una pasarela con la caché caliente.
4. Intenta usar directamente la credencial retirada desde la herramienta.
5. Confirma ambos fallos y relaciónalos con los registros de ciclo de vida y ejecución.

Si el paso tres funciona, la pasarela ignoró la revocación. Si el paso cuatro funciona, el flujo de ciclo de vida no revocó ante el emisor. Si ambos fallan pero los registros no identifican la misma generación, el equipo de respuesta sigue sin poder demostrar qué ocurrió.

La atribución necesita la identidad del emisor y del solicitante

Los registros de ciclo de vida responden quién creó, renovó, rotó o revocó una credencial. Los de la pasarela responden qué proceso local pidió qué acción, quién la aprobó, qué destino la recibió y qué resultado volvió. Ningún registro sustituye al otro.

Las credenciales dinámicas mejoran la atribución en el emisor cuando cada concesión produce una identidad remota distinta. La documentación del motor de secretos de bases de datos de HashiCorp señala que los nombres de usuario generados y únicos permiten relacionar el acceso con una instancia concreta de un servicio. Es útil, pero el usuario de base de datos identifica la identidad alquilada de la pasarela, no necesariamente el proceso del agente que solicitó la consulta.

Por eso la pasarela necesita una identidad de sesión estable y una identidad de proceso fiable. Un PID por sí solo es débil porque el sistema operativo reutiliza PID y los procesos pueden iniciar hijos. Registra la identidad del ejecutable disponible en la plataforma, su autoridad de firma cuando exista, el proceso padre, el inicio y fin de sesión y un ID de sesión impredecible. Vincula cada registro de acción con esa sesión.

El campo de unión es la generación de la credencial. Coloca el ID de concesión de Vault o el ID de evento de rotación estático tanto en el registro del ciclo de vida como en el de la acción. Registra también el ID de solicitud remota cuando la API lo devuelva. Durante un incidente, la investigación debe poder seguir esta cadena:

agent session -> gateway action -> credential generation -> issuer event -> remote request

No guardes valores secretos, cabeceras Authorization, claves privadas ni bloques de entorno resueltos en esos registros. Ocultarlos después no es fiable porque las excepciones, volcados de depuración y exportadores de trazas pueden copiarlos primero. Crea registros estructurados a partir de una lista de campos seguros.

La atribución también falla cuando todas las acciones comparten una cuenta de servicio de larga duración y no sobrevive ningún registro de la pasarela. La rotación reduce la vida de esa cuenta, pero no identifica al solicitante. A la inversa, unos registros de proceso perfectos no demuestran qué generación llegó al destino si la pasarela omite la concesión o versión. Conserva ambas dimensiones.

Inyectar el entorno cruza la frontera

Un flujo que inyecta un secreto en el entorno de un agente entrega su posesión al agente, así que la pasarela deja de controlar cada uso. Esta diferencia importa especialmente con los patrones de CLI de 1Password, porque la facilidad de recuperación puede parecer control de ejecución.

La documentación de 1Password dice que op run inicia un subproceso con secretos suministrados como variables de entorno. Puede ser una forma razonable de mantener el texto sin cifrar fuera de un archivo .env guardado en el repositorio, pero el proceso hijo puede leer la variable, imprimirla, pasarla a otro proceso o usarla en una solicitud no aprobada. op inject resuelve referencias dentro de un flujo de configuración y op read devuelve un valor resuelto al solicitante. Ninguna de esas rutas equivale a una pasarela que mantiene el secreto fuera del agente.

Para scripts manejados por personas que necesitan todas las funciones de un SDK nativo, la inyección de entorno puede ser aceptable. Para un agente autónomo cuyas acciones de red y SSH requieren control en cada uso, rompe la frontera buscada. Entrega a la pasarela la identidad limitada de recuperación y ofrece al agente herramientas con forma de acción.

La credencial inicial sigue requiriendo atención. 1Password recomienda cuentas de servicio para aplicar el mínimo privilegio y permite limitar el acceso a bóvedas concretas. Eso reduce lo que la pasarela puede recuperar. No limita lo que puede hacer tras recuperarlo, de modo que siguen siendo necesarios una superficie de acciones limitada, aprobaciones y validación de destinos de salida.

Evita una solución popular: resolver el secreto en un envoltorio, llamar a la pasarela con la credencial como parámetro y prometer que la pasarela la ocultará. El agente o el envoltorio ya tuvo el valor, el historial del shell y la inspección de procesos pueden revelarlo, y la pasarela no puede demostrar que no hubo un segundo uso. Pasa la referencia por la frontera y resuélvela dentro del componente que ejecuta.

La aprobación es independiente de la rotación

Una credencial recién rotada todavía puede autorizar una mala acción, y una acción aprobada con cuidado puede usar una credencial obsoleta. Rotación y aprobación reducen riesgos distintos, por lo que ninguna debe sustituir a la otra en silencio.

La autoridad del ciclo de vida responde: "¿Es válida esta generación?" La pasarela responde: "¿Puede este solicitante causar este efecto ahora?" El servicio remoto responde: "¿Tiene permiso esta identidad autenticada?" Mantén visibles las tres respuestas. Una tarjeta de aprobación verde no debe insinuar que la credencial está actualizada salvo que la pasarela lo haya comprobado. Una concesión vigente no debe evitar la aprobación humana exigida para una llamada destructiva.

La reutilización de aprobaciones necesita un alcance definido. Si la pasarela aprueba una sesión de agente, vincula la aprobación con la sesión del proceso y termínala cuando el proceso salga o el usuario la revoque. Si una credencial exige aprobación en cada llamada, la rotación debe conservar esa exigencia para la generación nueva. Un valor nuevo no debe devolver una credencial sensible a una opción predeterminada más débil.

El texto de aprobación debe describir la acción, el destino y el solicitante, no el secreto. "Permitir que el proceso firmado X ejecute POST /deployments en producción" ofrece información para decidir. "Permitir el uso de la clave API prod-3" obliga a reconstruir la intención a partir de nombres de inventario y acostumbra a aprobar avisos opacos.

Sallyport aplica esta mitad de ejecución para acciones HTTP API y SSH en macOS: los agentes se conectan mediante su shim MCP, las credenciales permanecen en su bóveda cifrada dentro del proceso y la aplicación ejecuta la acción. Sus controles fijos separan una bóveda bloqueada, la aprobación de sesión del proceso y la aprobación opcional para cada uso; ese modelo no elimina la necesidad de una autoridad externa del ciclo cuando otro sistema crea o rota la credencial.

Dos rotaciones crean dos autoridades aparentes

No permitas que el sistema de ciclo de vida y la pasarela roten la misma credencial por separado. Algunos equipos lo llaman defensa en profundidad, pero dos escritores producen generaciones ambiguas, reversiones poco fiables y carreras de revocación.

Imagina un proveedor estático que permite dos claves API activas. El flujo de 1Password crea la clave B, la prueba y actualiza el elemento autorizado mientras la clave A sigue activa durante un breve cambio. Al mismo tiempo, el programador local de la pasarela crea la clave C porque su copia de A alcanzó una edad configurada. Algunos procesos resuelven B, la caché caliente conserva A y la pasarela empieza a usar C. Desactivar A demuestra muy poco, porque nadie sabe si debe sobrevivir B o C.

Un coordinador debe ser dueño de la máquina de estados de rotación. Para un secreto dinámico de Vault, Vault ya coordina mediante sus roles y concesiones; la pasarela consume concesiones y no rota la cuenta remota. Para un registro estático gestionado mediante 1Password, el trabajo de rotación coordina al proveedor y al elemento almacenado; la pasarela observa cambios de generación e invalida su caché. El cifrado local de la pasarela protege una copia almacenada, pero volver a cifrar el almacenamiento no es rotar la credencial ante el emisor.

Una rotación estática operativa tiene estados explícitos en vez de un solo indicador rotated:

prepared -> activated -> distributed -> old_disabled -> verified
                |             |
                +-> rollback <-+

prepared significa que el emisor creó una generación candidata. activated significa que una solicitud autenticada e inocua tuvo éxito con ella. distributed significa que la referencia autorizada resuelve a la candidata y las pasarelas reconocen la generación nueva. old_disabled significa que el emisor rechaza la anterior. verified significa que una pasarela con caché caliente y una herramienta directa fallan con el valor antiguo. Permite una reversión solo mientras la generación anterior siga activa de forma intencionada.

La pasarela debe recibir cambios de estado con referencias e ID de generación, nunca los dos valores secretos. Un evento de invalidación puede nombrar credential_ref, old_generation, new_generation y effective_at. Al recibirlo, la pasarela elimina la entrada antigua de caché, cancela acciones en cola vinculadas a ella y vuelve a resolver cuando empieza la siguiente acción aprobada. Si el evento no llega, el límite de caché y la comprobación de generación todavía deben converger en el valor autorizado.

La reversión exige el mismo rigor. Volver a apuntar un elemento de 1Password a la clave A no funciona después de que el proveedor desactive A. Emitir un valor nuevo con el nombre visible anterior tampoco restaura la generación anterior. El coordinador debe crear o reactivar solo lo que admita el proveedor, asignar un ID de generación nuevo y repetir las fases normales de distribución y verificación.

Mantén el registro de propiedad lo bastante pequeño para revisarlo durante un incidente. Para cada referencia de credencial, nombra un coordinador de rotación, un emisor, una política de caché de pasarela, un comando de revocación y una persona o servicio autorizado a iniciar una retirada urgente. Si dos filas afirman que pueden crear la generación siguiente, detente. No es redundancia, sino una carrera con material secreto.

Prueba la unión y no solo cada caja

Una prueba correcta de Vault y otra de la pasarela no demuestran que el traspaso funcione. Prueba cachés antiguas, generaciones solapadas, aprobaciones retrasadas, revocaciones fallidas, reinicios de procesos y campos de unión ausentes en la frontera.

Usa una identidad de destino desechable y ejecuta esta matriz de aceptación antes de producción:

Ejecuta la matriz sobre las mismas rutas que usarán los agentes. Un simulador que devuelve 401 cuando se le ordena no revela si un complemento real de base de datos eliminó un usuario, si un proveedor admite claves solapadas ni si una conexión SSH sigue viva tras revocar la credencial.

Define criterios de aprobación explícitos. Ninguna acción empieza después de not_after. Una generación revocada o retirada falla incluso mediante una caché caliente. Cada registro de ejecución se une a una generación del ciclo sin material secreto. Un fallo al revocar ante el emisor impide afirmar que la retirada tuvo éxito. Un registro de aprobación identifica una sesión de proceso y caduca según el control configurado.

La frontera cumple su función cuando los fallos quedan contenidos. Vault o el flujo de rotación de 1Password pueden reemplazar credenciales sin enseñar valores secretos al agente. La pasarela puede cambiar las aprobaciones sin convertirse en emisor. El equipo de respuesta puede revocar una generación, detener una sesión y ver qué efectos remotos pueden haber ocurrido ya. Si la prueba de la unión no demuestra esas tres operaciones por separado, corrige el contrato antes de añadir otro sistema de secretos.