Agent Vault: probé el proxy de credenciales open-source para agentes y esto resuelve (y esto no)

¿Por qué seguimos pensando en credenciales de agentes como si fueran credenciales de apps? Llevamos años con .env, Vault, Secrets Manager — toda una industria construida sobre la premisa de que un humano decide cuándo se usa una credencial. Con agentes, esa premisa se rompió y nadie lo dice en voz alta.

Vi el Show HN de Agent Vault con 107 puntos el martes a la mañana. Primera reacción: "otro vault". Segunda reacción, después de leer el README completo: "espera, esto tiene una idea específica que vale revisar". Tercera reacción, después de instalarlo contra mi setup: "resuelve algo real, pero no lo que yo necesitaba resolver".

Voy despacio porque el tema lo merece.

El problema estructural que Agent Vault dice resolver

Cuando construí CrabTrap el año pasado, el problema era diferente: quería un juez entre mi agente y el output final para detectar alucinaciones en producción. Credenciales no eran el foco — las manejaba con variables de entorno como cualquier backend normal y listo.

Después de medir los costos reales de cada decisión de diseño de mi agente, empecé a prestarle más atención a qué tan seguido el agente tocaba recursos externos. Y ahí apareció la incomodidad: el agente no solo usaba credenciales, decidía cuándo usarlas basado en el contexto del prompt.

Eso es fundamentalmente distinto a una app tradicional.

En una app tradicional:

El flujo es determinístico. El handler siempre llama a la misma API con la misma credencial en el mismo punto del código. Podés auditar eso.

En un agente:

El agente razona sobre qué herramienta usar. Una credencial de Stripe puede activarse porque el agente interpretó que "gestionar el pago" requería una acción de reembolso que vos no pediste explícitamente. Eso pasó en un setup mío hace tres meses. No fue catastrófico, pero me hizo sentar a pensar.

Mi tesis: el problema de credenciales en agentes no es de almacenamiento — es de autorización dinámica. Y Agent Vault resuelve el primero mejor que cualquier alternativa open-source que probé, pero el segundo lo deja casi sin tocar.

Qué es Agent Vault y cómo lo instalé

Agent Vault es un proxy HTTP que se sienta entre tu agente y las APIs externas. Las credenciales viven en el proxy, no en el proceso del agente. El agente hace requests a localhost:8743 (o donde lo corras), el proxy las intercepta, inyecta la credencial correspondiente y las reenvía.

La idea tiene parentesco con lo que hice con agentes paralelos en Zed donde empecé a pensar en capas de intermediación — pero Agent Vault va más abajo en el stack.

Instalación en mi Railway + Docker setup:

# Dockerfile.agent-vault
FROM node:20-alpine

WORKDIR /app

# Clonar Agent Vault (open-source, MIT)
COPY package.json package-lock.json ./
RUN npm ci --production

# Configuración de credenciales — nunca en el build, siempre en runtime
COPY agent-vault.config.js ./

EXPOSE 8743

CMD ["node", "src/proxy.js"]

// agent-vault.config.js — este archivo NO va a git
// Las credenciales reales vienen de variables de entorno en Railway

module.exports = {
  port: 8743,
  credentials: {
    // Cada herramienta del agente tiene su propio namespace
    stripe: {
      secret: process.env.STRIPE_SECRET_KEY,
      // Importante: definir qué endpoints puede tocar
      allowedPaths: ['/v1/customers', '/v1/payment_intents'],
      // Qué métodos HTTP están permitidos para este namespace
      allowedMethods: ['GET', 'POST'],
    },
    github: {
      token: process.env.GITHUB_TOKEN,
      allowedPaths: ['/repos/**', '/user'],
      // Solo lectura — el agente no puede hacer push
      allowedMethods: ['GET'],
    },
    postgres: {
      connectionString: process.env.DATABASE_URL,
      // Acá Agent Vault tiene menos soporte, volvemos a esto
      allowedQueries: 'readonly', // experimental en v0.4
    },
  },
  // Logging de cada acceso — esto sí me gustó mucho
  auditLog: {
    enabled: true,
    output: './logs/agent-vault-audit.jsonl',
  },
};

Tiempo de instalación real: 47 minutos. Documentación clara, un bug con variables de entorno en Docker que resolví en 15 minutos con un issue ya abierto en GitHub.

Lo que Agent Vault resuelve bien

Tres cosas concretas que funcionaron desde el día uno:

1. Aislamiento de credenciales del proceso del agente

El agente nunca ve la credencial real. Hace POST https://api.stripe.com/v1/customers a través del proxy y Agent Vault inyecta el Bearer token. Si el agente se compromete (prompt injection, por ejemplo — tema que toco en mi análisis de security reports con LLMs), las credenciales reales no están en su memoria de contexto.

Eso es valor real. No es poca cosa.

2. Audit log automático

Cada request queda en agent-vault-audit.jsonl con timestamp, endpoint tocado, método HTTP y — esto es lo bueno — el tool call del agente que lo originó (si configurás la integración con el SDK del agente).

{"ts":"2026-07-14T09:23:41Z","credential":"stripe","path":"/v1/customers","method":"GET","agent_tool":"get_customer_info","prompt_hash":"a3f...","latency_ms":234}
{"ts":"2026-07-14T09:23:44Z","credential":"stripe","path":"/v1/payment_intents","method":"POST","agent_tool":"create_payment","prompt_hash":"a3f...","latency_ms":891}

Ese log me mostró algo incómodo: en una sesión de 40 minutos, mi agente hizo 23 calls a Stripe. Yo esperaba ~8. Los 15 extra eran calls redundantes a GET /v1/customers que el agente hacía para "confirmar" contexto en cada paso del loop. Problema de diseño mío, no de Agent Vault — pero sin el audit log no lo hubiera visto.

3. Path filtering como capa mínima de blast radius

Que el agente no pueda tocar /v1/refunds porque no está en allowedPaths es una red de seguridad concreta. No es suficiente sola (después explico por qué), pero es mucho mejor que no tenerla.

Lo que Agent Vault no resuelve (y debería decirlo más claro)

Acá está el nudo del asunto.

Agent Vault controla el acceso: qué endpoints, qué métodos, qué credencial. Pero no controla la intención: por qué el agente está tocando ese endpoint en este momento de la conversación.

Ejemplo concreto. Si mi agente tiene permiso para POST /v1/payment_intents, Agent Vault va a dejar pasar ese request. No sabe si el agente lo está haciendo porque el usuario pidió "procesar el pago del pedido 1234" o porque el agente llegó a esa conclusión por un camino de razonamiento que derivó de un contexto ambiguo.

El problema no es el qué — es el por qué y el cuándo.

Esto me recuerda a algo que aprendí construyendo con MCP: los protocolos de herramientas definen capacidades, pero no definen autorización contextual. Agent Vault es excelente en la capa de capacidades. La capa de autorización contextual sigue siendo territorio sin resolver.

Tres gotchas específicos que encontré:

Gotcha 1: rate limiting por credencial, no por sesión de usuario

Agent Vault permite definir rate limits por credencial:

stripe: {
  secret: process.env.STRIPE_SECRET_KEY,
  rateLimit: { requests: 100, windowMs: 60000 }, // 100 req/min
}

Pero eso es el límite global para todos los agentes que usen esa credencial. Si tenés múltiples usuarios simultáneos en producción, un agente que se vuelve loco puede agotar el rate limit para todos los demás. Necesitás tu propia lógica de sesión encima.

Gotcha 2: credenciales de base de datos son ciudadanos de segunda clase

El soporte para PostgreSQL/MySQL está marcado como "experimental" en v0.4 y se nota. El allowedQueries: 'readonly' no parsea el SQL para verificar que sea realmente de solo lectura — confía en que tu ORM o driver lo haga correctamente. Eso es una falsa sensación de seguridad.

Para mi setup con PostgreSQL en Railway, terminé dejando la conexión a base de datos fuera de Agent Vault y manejándola con un wrapper propio que valida el tipo de query antes de ejecutar.

Gotcha 3: latencia que se acumula

Cada request pasa por el proxy. En mis pruebas: +12ms en promedio por call. Solo doce milisegundos — no es dramático. Pero cuando el agente hace 23 calls a Stripe en una sesión (como descubrí con el audit log), eso son 276ms de overhead acumulado solo por el proxy. En el contexto de los benchmarks que vi con TPUs y latencia de inferencia, este overhead es menor, pero en loops de agentes largos se nota.

Cómo quedaría una arquitectura honesta

Lo que uso hoy, después de una semana con Agent Vault en staging:

Lo que Agent Vault NO cubre y necesito manejar yo:

Esa segunda caja es el territorio de CrabTrap (output quality) mezclado con algo que todavía no existe como producto maduro: un intent validator para agentes. Agent Vault y CrabTrap son capas complementarias, no sustitutos.

FAQ — Lo que me preguntaron en el canal de Slack del equipo cuando lo mostré

¿Agent Vault funciona con cualquier agente o solo con frameworks específicos?

Funciona con cualquier cosa que pueda hacer HTTP. Si tu agente usa LangChain, Mastra, LlamaIndex o un SDK propio, lo único que necesitás es apuntar las llamadas a APIs externas al proxy en lugar de a los endpoints originales. La integración con tool calls para el audit log sí requiere un SDK específico o que vos agregues el header X-Agent-Tool en cada request.

¿Es seguro correrlo en producción hoy?

Yo lo tengo en staging y lo voy a mantener ahí hasta que v0.5 salga con el soporte de base de datos más sólido. Para APIs REST tipo Stripe o GitHub, sí lo veo listo para producción. Para bases de datos, no todavía.

¿Qué diferencia hay con usar HashiCorp Vault o AWS Secrets Manager?

Vault y Secrets Manager resuelven el almacenamiento seguro de credenciales. Agent Vault resuelve la inyección dinámica de esas credenciales en requests HTTP sin que el agente las vea. Son capas distintas — de hecho, Agent Vault puede leer sus credenciales desde Vault o Secrets Manager. No son competidores, son complementarios.

¿El proxy se convierte en un single point of failure?

Sí, y eso hay que diseñarlo. En Railway lo corrí con restart automático y en staging no tuve downtime en una semana. Para producción real con tráfico alto, necesitás al menos dos instancias y un health check. La documentación de Agent Vault toca esto pero no da una guía operacional completa.

¿Resuelve el problema de prompt injection?

Parcialmente. Si un atacante logra que el agente ejecute un tool call malicioso, Agent Vault puede limitar el blast radius (no puede tocar endpoints fuera de allowedPaths). Pero no detecta que el tool call fue el resultado de una inyección — para eso necesitás algo más arriba en la cadena, más parecido a lo que exploré con los reports de seguridad generados por LLMs.

¿Vale la pena dado el overhead de 12ms por call?

Para la mayoría de los casos de uso de agentes, sí. El overhead es real pero predecible. Lo que Agent Vault te da — audit log, path filtering, aislamiento de credenciales — vale más que esos 12ms en casi cualquier arquitectura de producción seria.

Lo que me llevo y lo que no compro

Hace dos semanas me acordé de cuando salió el App Router de Next.js en 2021 y me pasé dos semanas enojado porque rompía todo lo que sabía. Después entendí que era la abstracción correcta. Con Agent Vault siento algo parecido, pero invertido: la abstracción existe, es correcta en su capa, pero la venden como si resolviera más de lo que realmente resuelve.

Lo que acepto: Agent Vault es la mejor solución open-source que probé para el problema de almacenamiento y aislamiento de credenciales en agentes. El audit log solo ya justifica la instalación.

Lo que no compro: que proxy de credenciales = seguridad de agentes. Son el mismo problema en el mismo documento de pitch, y no son lo mismo. Un agente puede comportarse de maneras que rompan todas tus suposiciones de seguridad sin tocar un solo endpoint fuera de los permitidos — simplemente usando los permitidos de formas que no anticipaste.

El trade-off honesto: instalalo, usá el audit log para entender qué hace realmente el agente, y construí tu capa de autorización contextual encima. No al revés.

Si construiste algo que ataque el problema de intent validation en agentes — ese segundo cuadro que dibujé arriba — me interesa verlo. Ese es el gap que sigue abierto.