Infisical Agent Vault: cómo un proxy de credenciales mantiene las claves de API fuera de los agentes de IA

La gestión tradicional de secretos devuelve las credenciales a las aplicaciones y servicios que las utilizan. Infisical Agent Vault sigue otro camino. El agente nunca tiene la credencial real.

Esta guía explica cómo funciona ese patrón de proxy de credenciales, dónde reduce el riesgo y dónde no. Está organizada en torno a un modelo de tres capas que llamamos Placeholder / Proxy / Perimeter (valor sustituto, proxy y perímetro):

• Placeholder: el agente solo tiene un valor sustituto, nunca la clave real.
• Proxy: un intermediario independiente guarda la credencial real, aplica las políticas y la inyecta en las solicitudes aprobadas.
• Perimeter: la red obliga a que cada llamada saliente pase por ese intermediario.

Por qué entregar secretos a los agentes de IA rompe el modelo anterior

La gestión clásica de secretos se basa en un contrato sencillo. Una aplicación que tú escribiste y revisaste se autentica ante un gestor de secretos, recibe una credencial y la usa.

Los agentes rompen ese contrato. El repositorio de Agent Vault lo dice sin rodeos: la gestión tradicional de secretos devuelve credenciales a aplicaciones y servicios, y esto deja de funcionar con los agentes de IA, a los que se puede engañar mediante inyección de prompts para que filtren secretos. Tony Dang, CTO de Infisical, defendió lo mismo en el lanzamiento: la gestión de secretos se creó para un mundo en el que las aplicaciones obtenían credenciales y las usaban, y esa premisa ya no se cumple con los agentes de IA.

El problema no es la mala intención. El artículo de lanzamiento de Infisical admite que, incluso con salvaguardas suficientes, no hay forma de garantizar que el agente no sea manipulado para filtrar sus secretos.

Las defensas a nivel de modelo no cierran la brecha. La hoja de referencia de OWASP sobre inyección de prompts cita a Hughes et al. (2024), que informaron de un 89% de éxito de ataque en GPT-4o y un 78% en Claude 3.5 Sonnet con hasta 10,000 prompts aumentados por solicitud. Ese estudio midió el éxito de jailbreaks con prompts aumentados de tipo Best-of-N, no la frecuencia con la que la inyección indirecta de prompts exfiltra secretos. Lo interpretamos como una razón para no tratar las negativas del modelo como una frontera de seguridad.

En lugar de confiarle una clave al agente, la mantienes completamente fuera de su contexto. Esa es la capa Placeholder. Las otras dos existen para que se mantenga intacta.

Cómo funciona el proxy de credenciales de Agent Vault

Infisical describe Agent Vault como un proxy de reenvío que intercepta TLS e inyecta credenciales, diseñado para cargas de trabajo de agentes. El flujo es así:

1. El agente recibe un valor sustituto o un token de sesión en lugar de la clave de API real.
2. Su tráfico HTTP pasa por el proxy, normalmente porque la variable de entorno HTTPS_PROXY está definida.
3. El proxy intercepta la conexión TLS, compara el host de destino con sus servicios configurados e inserta la credencial real en la solicitud saliente.
4. La solicitud sale hacia el servicio con la credencial real y la respuesta vuelve al agente.

En el binario de código abierto, el servidor inicia una API HTTP de gestión en el puerto 14321 y un proxy HTTP/HTTPS transparente en el puerto 14322.

La API de destino ve una solicitud autenticada normal. El agente, y cualquier proveedor de inferencia que registre su contexto, solo ve el valor sustituto. Por eso el patrón también aborda el riesgo de los registros del proveedor que se analiza más abajo, en la sección sobre protección.

La confianza en el certificado es un paso del despliegue

Te recomendamos tratar la confianza en el certificado como un paso explícito del despliegue: con cualquier proxy que intercepte TLS, prevé que cada entorno de ejecución del agente tenga que confiar en la autoridad de certificación que firma los certificados del proxy. Instala ese certificado de CA de forma deliberada en cada imagen del agente y sigue la documentación de tu edición sobre cómo se emite. Nunca desactives la verificación de certificados para que las conexiones funcionen.

Dos reglas deciden si la garantía se cumple

La primera es la ubicación, que sostiene la capa Proxy. Según el repositorio, Agent Vault está pensado para ejecutarse en una máquina distinta a la de tus agentes de IA, de modo que los agentes no puedan acceder directamente a las credenciales que contiene. Si el agente puede leer el almacenamiento del vault, el patrón te aporta muy poco.

La segunda es la aplicación obligatoria, la capa Perimeter. Definir HTTPS_PROXY por sí solo no garantiza que el tráfico pase por el proxy, advierte Infisical, porque el agente puede eliminar la variable. La variable solo orienta a los clientes que la respetan. Un despliegue completo bloquea la red para que todo el tráfico saliente pase obligatoriamente por Agent Vault.

La superficie de control: listas de permitidos, modo de denegación, sesiones y auditoría

Un proxy que inyecta credenciales también es un lugar natural para aplicar políticas.

Coincidencia de hosts y modo de denegación. De forma predeterminada, el proxy de código abierto reenvía como tráfico de proxy normal las solicitudes que no coinciden con ningún servicio configurado. Cambiar un vault al modo de denegación estricto (unmatched_host_policy=deny) rechaza esas solicitudes con HTTP 403.

Nosotros haríamos del modo de denegación la base de todos los vaults. Con el paso libre activado, un agente dirigido hacia un host controlado por un atacante aún puede llegar a él, solo que sin una credencial intermediada. El modo de denegación convierte el proxy en una lista de permitidos de salida además de un inyector de credenciales. Si tu edición admite reglas por ruta o por método HTTP, consulta la documentación para saber qué nivel de detalle se aplica realmente.

Sesiones con límite de tiempo. En el Agent Vault comercial, cada sesión de agente caduca según el calendario que definas, y los agentes en ejecución pierden el acceso en un plazo de 60 segundos desde que termina la sesión. Las sesiones cortas limitan cuánto tiempo puede seguir usando una ejecución secuestrada el acceso intermediado.

Proxies compartidos. Cuando varios agentes comparten un proxy, le envían su token de sesión por HTTP sin cifrar, algo que la documentación de Infisical señala como advertencia. Mantén esa configuración en una red privada que compartan los agentes y el proxy, como tus propios servidores, un clúster de Kubernetes o runners de CI autoalojados.

Auditoría. Todo el tráfico intermediado pasa por un único punto de control, lo que da a los equipos de seguridad un solo lugar para revisar a qué llaman los agentes. Antes de usarlo como evidencia, averigua qué registra tu edición y durante cuánto tiempo conserva esos datos, y confirma que puedes exportarlos. Si ya trazas las ejecuciones de agentes con trazas GenAI de OpenTelemetry, correlaciona los registros del proxy con esas trazas en lugar de considerar completo cualquiera de los dos.

Qué protege el patrón y qué no

Según la documentación de Infisical, si una inyección de prompts engaña al agente para que revele una credencial, no hay nada que revelar. Es una mejora real frente a los secretos guardados en variables de entorno que el agente puede imprimir.

El debate sobre el lanzamiento en Hacker News aportó otro ángulo. Un comentarista sostuvo que el patrón no resuelve el problema de los agentes hostiles, sino el de los proveedores de inferencia hostiles o comprometidos, porque no quieres secretos en los registros de un proveedor de IA. En cualquier caso, las claves que nunca entran en prompts, respuestas del modelo ni salidas de herramientas nunca acaban en registros de terceros, tanto si alguien te está atacando como si no.

Uso indebido del acceso permitido. Si un agente puede llamar a un endpoint de eliminación a través del proxy, un agente manipulado también puede llamarlo, y el proxy adjunta la credencial real como siempre. La intermediación mantiene la clave en secreto. No hace que las acciones del agente sean seguras, y eso importa sobre todo en las herramientas MCP activadas por eventos que se ejecutan sin revisión humana.

Credenciales en las respuestas. Un crítico en el mismo hilo de Hacker News señaló que, si la credencial es un token OAuth2 y el servicio tiene un endpoint de renovación de tokens, la respuesta llevaría un token nuevo directamente al agente. Las API de emisión de tokens, creación de claves y lectura de secretos conllevan el mismo riesgo. La intermediación protege la solicitud, así que sigues teniendo que revisar lo que vuelve.

Gestión de tokens en MCP. Las buenas prácticas de seguridad de MCP establecen que los servidores MCP no deben aceptar ningún token que no se haya emitido explícitamente para el servidor MCP. Un proxy de credenciales no sustituye las comprobaciones correctas de audiencia dentro de tus servidores MCP.

Agent Vault de código abierto frente a comercial: qué cambió y por qué importa

Agent Vault procede de Infisical, que afirma procesar miles de millones de secretos al mes para equipos, pipelines de CI/CD y servidores.

La revisión independiente de Codeline en el lanzamiento señaló unas 800 estrellas, una etiqueta Preview y una API sujeta a cambios de forma explícita. También describió el funcionamiento interno: la contraseña maestra envuelve una clave de cifrado de datos aleatoria mediante Argon2id con parámetros predeterminados de 3 iteraciones, 64 MiB de memoria y 4 hilos. De forma predeterminada, el binario guarda todo el estado en una base de datos SQLite local que no requiere configuración, y PostgreSQL es la opción para producción.

En pocos meses, según un recuento posterior de Infisical, Agent Vault superó las 2,000 estrellas en GitHub, con decenas de miles de instalaciones y millones de ejecuciones de agentes. Son cifras del proveedor y no se han verificado de forma independiente.

Una nota sobre los nombres: Infisical llama a la edición de pago Agent Vault comercial cuando describe las sesiones, y llama a su componente intermediario Agent Proxy cuando describe el rediseño. Aquí usamos ambos términos de la misma manera.

El cambio más importante es de arquitectura. Al repasar la primera versión, Infisical explicó que había agrupado dos conceptos distintos en uno: el almacén de secretos y el intermediario de secretos. En el Agent Vault comercial, Agent Proxy los separa e incluye 30+ configuraciones predefinidas para servicios habituales, entre ellas proveedores de LLM como Anthropic y OpenAI y servicios como GitHub, Slack y Datadog. En cuanto al repositorio de código abierto, la empresa dice que sigue disponible y que puedes ejecutarlo, pero que no se mantiene activamente y nunca se diseñó para un equipo.

Nuestras fuentes también describen la gestión de hosts no coincidentes solo para el repositorio de código abierto y la caducidad de sesiones solo para la edición comercial. Consulta la documentación actual de la otra edición en lugar de suponer que son equivalentes.

Te recomendamos tratar el repositorio de código abierto como una herramienta para aprender y crear prototipos. Para producción, nos fijaríamos en la edición comercial o en un fork interno que estés dispuesto a mantener. Valora la carga de mantenimiento igual que lo harías con cualquier componente de agente en producción (consulta nuestra lista de verificación para elegir el runtime de agentes de IA duraderos).

Guía práctica y lista de verificación previa al lanzamiento para agentes MCP, CLI y SDK

Estos pasos siguen las tres capas y se aplican a cualquiera de las dos ediciones.

Capa Placeholder

1. Inventaría las credenciales. Para cada agente, enumera todas las credenciales, el host contra el que se usa cada una y los endpoints y métodos HTTP más restringidos que necesita.
2. Usa valores sustitutos. Reemplaza las claves reales de las variables de entorno y los archivos de configuración del agente por valores sustitutos o tokens de sesión.

Capa Proxy

1. Separa el proxy. Ejecútalo en una máquina distinta o al otro lado de una frontera de red respecto a los agentes. El almacén de credenciales nunca debe estar en el entorno de ejecución del agente.
2. Deniega por defecto. Activa el modo de denegación para los hosts no coincidentes y añade entradas a la lista de permitidos por agente, no por equipo.
3. Revisa lo que vuelve. Marca los endpoints permitidos cuyas respuestas puedan devolver una credencial o un secreto, como las API de renovación OAuth, emisión de tokens, creación de claves y lectura de secretos. Mantenlos fuera del alcance del agente salvo que puedas justificar la exposición.
4. Limita el alcance de los tokens MCP. Las claves de API de destino de cada servidor MCP residen en el intermediario, no en su configuración. Rechaza los tokens de cliente que no se hayan emitido explícitamente para el servidor MCP y nunca los reenvíes a los servicios posteriores.

Capa Perimeter

1. Fuerza la salida. Usa reglas de firewall, políticas de red de Kubernetes o reglas de los runners de CI para que el proxy sea la única vía de salida del agente. Después, define HTTPS_PROXY como orientación para los clientes que la respetan.
2. Instala la confianza en la CA. Añade el certificado de CA del proxy al almacén de confianza de cada entorno de ejecución del agente, con la verificación activada.
3. Verifica los clientes HTTP. No todos los entornos de ejecución respetan las variables de proxy. La documentación de Infisical indica que el fetch integrado de Node.js no lee HTTPS_PROXY de forma predeterminada, así que necesitas --use-env-proxy o NODE_USE_ENV_PROXY=1 en Node 24 o posterior. Te recomendamos confirmar la compatibilidad del flag con la versión exacta del runtime que despliegues antes de confiar en él.

Demuéstralo

1. Prueba la revocación y la inyección. Define duraciones de sesión cortas, termina una sesión en plena ejecución y confirma que el acceso se detiene. Después, ejecuta una prueba canario de inyección de prompts que pida al agente imprimir sus claves y comprueba que solo salen valores sustitutos.

Agentes CLI como Claude Code

Infisical incluye Claude Code entre los agentes que funcionan a través de Agent Vault. Para los agentes CLI, la configuración fiable es un contenedor o una VM cuyas reglas de red solo permitan conexiones salientes hacia el proxy, con valores sustitutos allí donde el agente espere claves de API. Un agente CLI puede ejecutar comandos de shell, así que da por hecho que puede eliminar variables de entorno y deja que la red imponga la ruta.

Agentes SDK personalizados

Audita cada cliente HTTP del árbol de dependencias. Una biblioteca que ignore la configuración del proxy debería fallar de forma cerrada en la capa de red, no conectarse directamente sin avisar.

Lee la lista de permitidos como lo haría un atacante

Cuando las claves ya no están en el contexto del agente, la lista de permitidos se convierte en lo principal que puede explotar una inyección exitosa, así que revísala desde ese ángulo antes del despliegue. Para cada entrada, pregúntate qué podría hacer la peor secuencia de llamadas permitidas si fuera otra persona quien las eligiera. Los endpoints de eliminación, transferencia, creación de claves y renovación de tokens deberían requerir aprobación humana o quedar totalmente fuera de la lista de permitidos. La credencial de destino detrás de cada entrada debería tener los permisos más restringidos que ofrezca el proveedor, para que incluso una llamada aprobada pueda hacer lo mínimo posible.

El proxy funciona junto a tus controles actuales contra la inyección de prompts, como el filtrado de entradas, las comprobaciones de salidas y el diseño de herramientas con mínimo privilegio. No sustituye a ninguno de ellos.