Un Vault de Secretos Simple para Agentes CLI

Qué construí y dónde está el límite de seguridad

Para septiembre de 2026, había creado un vault de secretos básico para mis propios agentes CLI. En mi artículo de Medium sobre la creación de un gestor de secretos describí el proyecto y el motivo por el que surgió. No pretende reemplazar soluciones maduras, sino responder de forma práctica a una pregunta incómoda: ¿qué recibe exactamente un agente cuando obtiene acceso a un token?

El principio básico es sencillo: un secreto no debe aparecer en el prompt, las instrucciones ni el repositorio. Si el agente ve una clave API como texto normal, una inyección de prompt o una llamada fallida a una herramienta pueden convertir la automatización local en un canal de filtración. Es más seguro guardar una referencia opaca e inyectar el valor real solo mientras se ejecuta un comando.

Para una CLI local, una base razonable es el almacén seguro de credenciales del sistema operativo. La documentación de Keeper Secrets Manager CLI describe el guardado de configuración mediante macOS Keychain, Windows Credential Manager y Linux Secret Service. La biblioteca keyring de Python proporciona una interfaz unificada para estos mecanismos, por lo que un vault casero no necesita inventar su propio almacenamiento de claves.

En producción, es más lógico separar por completo la CLI de los secretos persistentes. Google Secret Manager y AWS Secrets Manager documentan el almacenamiento y la recuperación de claves API, contraseñas y otros valores sensibles; AWS también documenta la rotación. En este modelo, la CLI se convierte en intermediaria, no en la caja fuerte.

Sin embargo, un vault solo resuelve el almacenamiento. La siguiente capa debe emitir credenciales de corta duración para una tarea o sesión, restringir el acceso del agente a archivos y red, y registrar las solicitudes a nivel de herramienta. De lo contrario, solo habremos ocultado mejor una clave demasiado poderosa.

Por qué un vault por sí solo no basta

La principal ventaja no es un nuevo formato de almacenamiento, sino separar el modelo del secreto. El agente puede conservar el derecho de solicitar una operación sin ver el valor que la firma o autoriza.

Para experimentos locales, incluso un vault primitivo es mejor que un token en un archivo junto al proyecto. Para agentes autónomos, no basta: hacen falta privilegios mínimos, sandboxing, revocación de acceso, rotación y un registro de acciones. El peor patrón sigue siendo una clave universal y permanente en las variables de entorno de cada proceso.

Yo revisaría primero no el cifrado del almacén, sino el recorrido del secreto tras extraerlo. Los argumentos de línea de comandos, los logs, los volcados de errores y el contexto del modelo son especialmente peligrosos. Sin controles de última milla, incluso un backend sólido se convierte en una forma cara de enviar un secreto al lugar equivocado.

Por eso mi vault primitivo resulta más interesante como punto de partida para una arquitectura correcta. El verdadero límite de seguridad no rodea un archivo de claves, sino cada operación que el agente puede realizar en nombre del usuario.

Antes analizamos cómo Secret Storage en Obsidian afecta a la seguridad de los plugins y la automatización con IA. Estos principios también son útiles al diseñar un vault de secretos al que acceden los agentes.