Proxy de credenciales
Sus agentes realizan llamadas a la API.
Nunca deben contener las claves.
Clavitor Proxy se sitúa entre sus agentes de IA y las API a las que llaman. Las credenciales se inyectan en la capa de red: el agente nunca ve, almacena ni registra el secreto real. Un binario. Una variable de entorno. Cero cambios en el código.
El problema que ya tiene
Secretos en variables de entorno
Sus agentes leen OPENAI_API_KEY del entorno. Esa clave es visible en /proc, en volcados de errores, en registros de CI, en cada herramienta que invoca el agente. Una línea de registro filtrada y la clave es pública.
Secretos en la memoria del agente
Incluso si el agente obtiene la clave en tiempo de ejecución, la mantiene en memoria durante la duración del proceso. Una habilidad comprometida, una inyección de prompt, un volcado de depuración: la clave está ahí para ser tomada.
Sin auditoría de lo que se utilizó
Cuando una clave de API se comparte como una cadena, no hay registro de qué agente la utilizó, cuándo o para qué. Si la clave se filtra, la rota y espera. No hay rastro forense.
Los problemas que esperamos que no tenga
Claves de API en el código fuente
Codificadas en un archivo de configuración, confirmadas en git, clonadas por cada desarrollador y ejecutor de CI del equipo. Una bifurcación pública y está en el panel de escaneo de secretos de GitHub, o peor aún, no lo está.
Credenciales en Slack
"¿Puedes enviarme la clave de Stripe?" Pegada en un mensaje directo, buscable para siempre, exportada en cada archivo de cumplimiento. Slack no es una bóveda. Tampoco lo es el correo electrónico, Google Docs o una nota adhesiva en un monitor.
Archivos .env en cada portátil
Doce desarrolladores, doce copias de credenciales de producción en archivos de texto sin formato que nunca se rotan. Un portátil robado, una fuga de ~/.bash_history, una herramienta de copia de seguridad demasiado servicial, y usted estará rotando cada clave de la empresa a las 2 AM.
Retire las credenciales del agente por completo.
El proxy se sitúa entre el agente y la API. El agente escribe una referencia — clavitor://OpenAI/key — donde debería ir el secreto. El proxy la resuelve localmente, inyecta la credencial real en la solicitud HTTPS y la reenvía. Los registros del agente muestran el marcador de posición. La API recibe la clave. Nada en medio la almacena.
Sin variables de entorno. Sin secretos en la memoria del agente. Sin credenciales en la línea de comandos. La clave real nunca entra en el entorno del agente, ni en su memoria, ni en sus registros, de modo que el agente no tiene nada que pegar ni imprimir, ni nada de lo que se le pueda convencer para que lo revele. Eso cubre las claves enrutadas a través del proxy. Quien controle la máquina puede seguir usando el proxy, o leer la clave de la memoria del proxy con root, y un agente comprometido puede seguir haciendo un uso indebido del acceso que se le ha concedido. El alcance, los límites de frecuencia y la auditoría limitan eso.
# proxy-auth is the proxy's access token, the file beside the binary
$ export HTTPS_PROXY="http://clavitor:$(cat proxy-auth)@127.0.0.1:1983"
$ curl -H "Authorization: Bearer clavitor://OpenAI/key" \
https://api.openai.com/v1/chat/completions
# The proxy resolved the placeholder. The agent never saw sk-EXAMPLE_not_a_real_key.
# Neither did the logs, the crash dump, or the conversation history.Funciona con cualquier agente que realice llamadas HTTPS: Claude Code, Codex, OpenClaw, CrewAI, LangChain, scripts personalizados. Establezca una variable de entorno y las llamadas a la API del agente fluirán a través del proxy. Sin SDK, sin plugin, sin cambios en el código.
Lo que sucede bajo el capó
Descifra localmente, por solicitud
El proxy obtiene la credencial cifrada de la bóveda y la descifra en el dispositivo. El texto sin formato existe en la memoria del proceso para una solicitud HTTP, luego desaparece. Nada se almacena en caché. Nada se escribe en disco. Cada solicitud se descifra de nuevo.
Mapea campos a encabezados
Tokens Bearer, claves de API, autenticación básica: el proxy mapea las etiquetas de campo de la bóveda a los encabezados HTTP correctos automáticamente. O el agente elige el campo exacto con una referencia clavitor://. En cualquier caso, la credencial llega al lugar correcto sin que el agente la vea nunca.
Alcances, límites de velocidad, auditoría
La bóveda aplica límites de alcance y límites de velocidad. Un agente que accede a demasiadas credenciales distintas se bloquea automáticamente. Cada acceso se registra. Incluya un ID de agente en el marcador de posición — clavitor://agentid@Entry/field — para registros de auditoría por agente y límites de velocidad a través de un proxy compartido.
Despliegue
Un binario. Sidecar para el agente. Sin cambios en la infraestructura de red.
Host de agente único
Descargue el binario, ejecute clavitor-proxy init con el blob de inscripción y la clave, y establezca HTTPS_PROXY en el agente. Listo. El proxy se vincula a 127.0.0.1:1983 (sidecar de un agente). No se vinculará por sí solo a ninguna otra dirección: el puerto transporta un token de acceso en texto plano, así que fuera de loopback se niega a arrancar salvo que establezca CLAVITOR_PROXY_LISTEN en la dirección y cree además un archivo de solo propietario llamado proxy-allow-private junto al binario, lo que hace únicamente cuando esa dirección es una red privada de confianza (VPN o Tailscale).
Host de múltiples agentes
Cada agente obtiene su propia copia del binario con su propio archivo de configuración sidecar. Cada copia tiene su propio alcance, sus propios límites de velocidad, su propio registro de auditoría. El agente A no puede ver las credenciales del agente B. Aislamiento por diseño.
Cada proxy de credenciales que se ejecuta en la nube — el suyo o el de otra persona — es un objetivo. Si se viola el proxy, se obtienen las credenciales de todos los clientes. Ese no es un riesgo teórico. Es el modelo de negocio de cada servicio de proxy de credenciales como servicio.
El proxy de Clavitor se ejecuta en su infraestructura. Descifra en local. La credencial permanece en la memoria del proceso durante una solicitud. No hay ningún servicio en la nube que conserve sus claves en texto en claro. No hay ningún endpoint de API que sirva sus secretos. No hay ninguna copia en la nube de sus claves que pueda vulnerarse.
Sus agentes ya están realizando llamadas a la API.
Manténgalos en su carril.
Su bóveda, sus alcances, su registro de auditoría. El proxy añade un punto de aplicación a nivel de red con cero cambios de código en el agente.