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 memoria. Sin credenciales en la línea de comandos. El agente no conoce la clave, no puede filtrar la clave, no puede ser engañado para revelar la clave.
$ export HTTPS_PROXY=http://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-proj-abc123.
# 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 token de inscripción, establezca HTTPS_PROXY en el agente. Hecho. Por defecto, el proxy se enlaza a 127.0.0.1:1983 (sidecar para un agente); establezca CLAVITOR_PROXY_LISTEN para enlazar en otro lugar cuando un proxy sirva a varios agentes en una red privada.
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 localmente. La credencial existe en la memoria del proceso durante la duración de una solicitud. No hay un servicio en la nube que contenga sus claves en texto sin formato. No hay un punto final de API que sirva sus secretos. No hay nada que violar.
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.