Infisical Agent Vault: como um proxy de credenciais mantém chaves de API fora de agentes de IA

O gerenciamento de segredos tradicional devolve as credenciais às aplicações e aos serviços que as utilizam. O Infisical Agent Vault segue outro caminho: o agente nunca tem acesso à credencial real.

Este guia mostra como funciona esse padrão de proxy de credenciais, onde ele reduz o risco e onde não reduz. A organização segue um modelo de três camadas que chamamos de Placeholder / Proxy / Perímetro:

• Placeholder: o agente guarda apenas um valor substituto, nunca a chave real.
• Proxy: um intermediário separado guarda a credencial real, aplica as políticas e a injeta nas requisições aprovadas.
• Perímetro: a rede obriga toda chamada de saída a passar por esse intermediário.

Por que entregar segredos a agentes de IA quebra o modelo antigo

O gerenciamento de segredos clássico se apoia num acordo simples. Uma aplicação que você escreveu e revisou se autentica num gerenciador de segredos, recebe uma credencial e a utiliza.

Os agentes quebram esse acordo. O repositório do Agent Vault diz isso com todas as letras: o gerenciamento de segredos tradicional devolve credenciais a aplicações e serviços, e esse modelo não se sustenta com agentes de IA, que podem ser enganados por prompt injection e acabar vazando segredos. Tony Dang, CTO da Infisical, defendeu o mesmo ponto no lançamento: o gerenciamento de segredos foi criado para um mundo em que as aplicações buscavam credenciais e as usavam, e essa premissa não vale mais para agentes de IA.

O problema não é má intenção. O post de lançamento da Infisical admite que, mesmo com proteções suficientes, não há como garantir que o agente não será manipulado para vazar seus segredos.

As defesas no nível do modelo não fecham essa lacuna. A cheat sheet de prompt injection da OWASP cita Hughes et al. (2024), que relataram 89% de sucesso nos ataques contra o GPT-4o e 78% contra o Claude 3.5 Sonnet, com até 10.000 prompts aumentados por requisição. Esse estudo mediu o sucesso de jailbreaks com prompts aumentados no estilo Best-of-N, e não a frequência com que prompt injection indireto exfiltra segredos. Para nós, ele é um motivo para não tratar recusas do modelo como uma barreira de segurança.

Em vez de confiar uma chave ao agente, você mantém a chave totalmente fora do contexto dele. Essa é a camada Placeholder. As outras duas existem para mantê-la intacta.

Como funciona o proxy de credenciais do Agent Vault

A Infisical descreve o Agent Vault como um forward proxy que intercepta TLS e injeta credenciais, criado para cargas de trabalho de agentes. O fluxo é este:

1. O agente recebe um valor placeholder ou um token de sessão no lugar da chave de API real.
2. O tráfego HTTP dele passa pelo proxy, normalmente porque a variável de ambiente HTTPS_PROXY está definida.
3. O proxy intercepta a conexão TLS, compara o host de destino com os serviços configurados e insere a credencial real na requisição de saída.
4. A requisição segue para o destino com a credencial real, e a resposta volta para o agente.

No binário open source, o servidor sobe uma API HTTP de gerenciamento na porta 14321 e um proxy HTTP/HTTPS transparente na porta 14322.

A API de destino vê uma requisição autenticada normal. O agente, e qualquer provedor de inferência que registre o contexto dele, vê apenas o placeholder. É por isso que o padrão também trata o risco dos logs do provedor, discutido na seção sobre proteção mais abaixo.

A confiança no certificado é uma etapa da implantação

Sugerimos tratar a confiança no certificado como uma etapa explícita da implantação: com qualquer proxy que intercepta TLS, planeje para que cada runtime de agente confie na autoridade certificadora que assina os certificados do proxy. Instale esse certificado de CA de forma deliberada em cada imagem de agente e siga a documentação da sua edição sobre como ele é emitido. Nunca desative a verificação de certificados para fazer as conexões funcionarem.

Duas regras decidem se a garantia se mantém

A primeira é a localização, que sustenta a camada Proxy. Segundo o repositório, o Agent Vault deve rodar numa máquina separada dos seus agentes de IA, para que os agentes não consigam acessar diretamente as credenciais guardadas nele. Se o agente consegue ler o armazenamento do vault, o padrão traz pouquíssimo benefício.

A segunda é a imposição, a camada Perímetro. Definir apenas o HTTPS_PROXY não garante que o tráfego passe pelo proxy, observa a Infisical, porque o agente pode remover a variável. Ela só orienta clientes que a respeitam. Uma implantação completa restringe a rede para que todo o tráfego de saída seja forçado a passar pelo Agent Vault.

A superfície de controle: allowlists, modo deny, sessões e auditoria

Um proxy que injeta credenciais também é o lugar natural para aplicar políticas.

Correspondência de hosts e modo deny. Por padrão, o proxy open source encaminha como tráfego de proxy comum as requisições que não correspondem a nenhum serviço configurado. Ao mudar um vault para o modo deny estrito (unmatched_host_policy=deny), essas requisições passam a ser rejeitadas com HTTP 403.

Faríamos do modo deny o padrão de base em todo vault. Com o repasse ativado, um agente direcionado a um host controlado por um atacante ainda consegue alcançá-lo, só que sem uma credencial intermediada. O modo deny transforma o proxy numa allowlist de saída, além de injetor de credenciais. Se a sua edição oferece regras por caminho ou por método HTTP, verifique na documentação qual granularidade é de fato aplicada.

Sessões com prazo. No Agent Vault comercial, toda sessão de agente expira segundo um cronograma definido por você, e os agentes em execução perdem o acesso em até 60 segundos após o fim da sessão. Sessões curtas limitam por quanto tempo uma execução sequestrada pode continuar usando o acesso intermediado.

Proxies compartilhados. Quando vários agentes compartilham um proxy, eles enviam o token de sessão a ele por HTTP simples, ponto que a documentação da Infisical destaca como alerta. Mantenha essa configuração numa rede privada compartilhada por agentes e proxy, como seus próprios servidores, um cluster Kubernetes ou runners de CI auto-hospedados.

Auditoria. Todo o tráfego intermediado passa por um único ponto de controle, o que dá às equipes de segurança um só lugar para revisar o que os agentes chamam. Antes de usar isso como evidência, descubra o que a sua edição registra e por quanto tempo guarda esses dados, e confirme que é possível exportá-los. Se você já rastreia execuções de agentes com tracing GenAI do OpenTelemetry, correlacione os registros do proxy com esses traces em vez de tratar qualquer um dos dois como completo.

Contra o que o padrão protege, e contra o que não protege

Segundo a documentação da Infisical, se um prompt injection levar o agente a revelar uma credencial, não há nada ali para revelar. É um avanço real em relação a segredos guardados em variáveis de ambiente que o agente consegue imprimir.

A discussão do lançamento no Hacker News trouxe outro ângulo. Um comentarista argumentou que o padrão não resolve o problema de agentes hostis, e sim o de provedores de inferência hostis ou comprometidos, porque você não quer segredos nos logs de um provedor de IA. De todo modo, chaves que nunca entram em prompts, completions ou saídas de ferramentas nunca vão parar em logs de terceiros, haja ou não alguém atacando você.

Uso indevido de acesso permitido. Se um agente pode chamar um endpoint de exclusão pelo proxy, um agente manipulado ainda pode chamá-lo, e o proxy anexa a credencial real normalmente. A intermediação mantém a chave em segredo. Ela não torna seguras as ações do agente, e isso pesa mais em ferramentas MCP acionadas por eventos que rodam sem revisão humana.

Credenciais nas respostas. Um crítico na mesma thread do Hacker News apontou que, se a credencial for um token OAuth2 e o serviço tiver um endpoint de refresh de token, a resposta levaria um token novo direto para o agente. APIs de emissão de tokens, criação de chaves e leitura de segredos trazem o mesmo risco. A intermediação protege a requisição, então você ainda precisa revisar o que volta.

Tratamento de tokens no MCP. As boas práticas de segurança do MCP determinam que servidores MCP não devem aceitar tokens que não tenham sido emitidos explicitamente para o servidor MCP. Um proxy de credenciais não substitui verificações corretas de audience dentro dos seus servidores MCP.

Agent Vault open source vs. comercial: o que mudou e por que isso importa

O Agent Vault vem da Infisical, que afirma processar bilhões de segredos por mês para equipes, pipelines de CI/CD e servidores.

A análise independente da Codeline no lançamento registrou cerca de 800 estrelas, um rótulo de Preview e uma API explicitamente sujeita a mudanças. Ela também descreveu o funcionamento interno: a senha mestra protege uma chave de criptografia de dados aleatória por meio de Argon2id, com parâmetros padrão de 3 iterações, 64 MiB de memória e 4 threads. Por padrão, o binário guarda todo o estado num banco SQLite local que não exige configuração, e o PostgreSQL é a opção para produção.

Em poucos meses, segundo uma contagem posterior da Infisical, o Agent Vault passou de 2.000 estrelas no GitHub, com dezenas de milhares de instalações e milhões de execuções de agentes. Esses números são do fornecedor e não foram verificados de forma independente.

Uma observação sobre nomes: a Infisical chama a edição paga de Agent Vault comercial ao descrever as sessões, e chama seu componente intermediário de Agent Proxy ao descrever o redesenho. Usamos os dois termos da mesma forma aqui.

A mudança maior é de arquitetura. Ao avaliar a primeira versão, a Infisical explicou que havia juntado dois conceitos distintos num só: o armazenamento de segredos e o intermediário de segredos. No Agent Vault comercial, o Agent Proxy separa os dois e vem com 30+ presets para serviços comuns, incluindo provedores de LLM como Anthropic e OpenAI e serviços como GitHub, Slack e Datadog. Quanto ao repositório open source, a empresa diz que ele continua no ar e você pode rodá-lo, mas não é mantido ativamente e nunca foi criado para uso em equipe.

Nossas fontes também descrevem o tratamento de hosts sem correspondência apenas para o repositório open source, e a expiração de sessões apenas para a edição comercial. Consulte a documentação atual da outra edição em vez de presumir que as duas são equivalentes.

Sugerimos tratar o repositório open source como uma ferramenta de aprendizado e prototipagem. Para produção, avaliaríamos a edição comercial ou um fork interno que você esteja disposto a manter. Pese o custo de manutenção como faria com qualquer componente de agente em produção (veja nosso checklist de seleção de runtime para agentes de IA duráveis).

Guia prático e checklist pré-lançamento para agentes MCP, CLI e SDK

Estes passos seguem as três camadas e valem para qualquer edição.

Camada Placeholder

1. Faça o inventário das credenciais. Para cada agente, liste todas as credenciais, o host em que cada uma é usada e os endpoints e métodos HTTP mais restritos de que ela precisa.
2. Troque por placeholders. Substitua as chaves reais nas variáveis de ambiente e nos arquivos de configuração dos agentes por valores placeholder ou tokens de sessão.

Camada Proxy

1. Separe o proxy. Rode-o numa máquina separada ou do outro lado de uma fronteira de rede em relação aos agentes. O armazenamento de credenciais nunca fica no runtime do agente.
2. Negue por padrão. Ative o modo deny para hosts sem correspondência e adicione entradas à allowlist por agente, não por equipe.
3. Revise o que volta. Sinalize endpoints da allowlist cujas respostas podem devolver uma credencial ou um segredo, como APIs de refresh de OAuth, emissão de tokens, criação de chaves e leitura de segredos. Mantenha-os longe do agente, a menos que você consiga justificar a exposição.
4. Restrinja os tokens MCP. As chaves de API de destino de cada servidor MCP ficam no intermediário, não na configuração dele. Rejeite tokens de cliente que não tenham sido emitidos explicitamente para o servidor MCP e nunca os repasse adiante.

Camada Perímetro

1. Force a saída. Use regras de firewall, network policies do Kubernetes ou regras dos runners de CI para que o proxy seja a única rota de saída do agente. Depois, defina o HTTPS_PROXY como orientação para clientes que o respeitam.
2. Instale a confiança na CA. Adicione o certificado de CA do proxy ao trust store de cada runtime de agente, com a verificação mantida ativa.
3. Verifique os clientes HTTP. Nem todo runtime respeita as variáveis de proxy. A documentação da Infisical observa que o fetch nativo do Node.js não lê o HTTPS_PROXY por padrão, então você precisa de --use-env-proxy ou NODE_USE_ENV_PROXY=1 no Node 24 ou posterior. Sugerimos confirmar o suporte à flag na versão exata do runtime que você implanta antes de depender dela.

Comprove

1. Teste a revogação e a injeção. Defina sessões de curta duração, encerre uma sessão no meio da execução e confirme que o acesso para. Depois, rode um teste canário de prompt injection pedindo ao agente que imprima suas chaves e verifique se só aparecem placeholders.

Agentes CLI como o Claude Code

A Infisical lista o Claude Code entre os agentes que rodam pelo Agent Vault. Para agentes CLI, a configuração confiável é um contêiner ou uma VM cujas regras de rede permitam conexões de saída apenas para o proxy, com placeholders onde o agente espera chaves de API. Um agente CLI pode executar comandos de shell, então parta do princípio de que ele consegue remover variáveis de ambiente e deixe a rede impor a rota.

Agentes SDK personalizados

Audite todos os clientes HTTP da árvore de dependências. Uma biblioteca que ignora as configurações de proxy deve falhar de forma fechada na camada de rede, e não se conectar diretamente sem avisar.

Leia a allowlist como um atacante leria

Quando as chaves saem do contexto do agente, a allowlist passa a ser o principal alvo que uma injeção bem-sucedida pode explorar, então revise-a desse ângulo antes do lançamento. Para cada entrada, pergunte o que a pior sequência de chamadas permitidas poderia fazer se outra pessoa estivesse escolhendo essas chamadas. Endpoints de exclusão, transferência, criação de chaves e refresh de tokens devem exigir aprovação humana ou ficar totalmente fora da allowlist. A credencial de destino por trás de cada entrada deve ter os escopos mais restritos que o provedor oferece, para que até uma chamada aprovada possa fazer o mínimo possível.

O proxy funciona junto com os controles de prompt injection que você já tem, como filtragem de entrada, verificação de saída e design de ferramentas com privilégio mínimo. Ele não substitui nenhum deles.