Agent Vault 0.35.1 Fixes the Bug That Would Have Made Dynamic Secrets Feel Fake

Agent Vault 0.35.1 is a one-commit release with the kind of bug fix that decides whether an architecture feels real or performative. The premise of Infisical’s Agent Vault is straightforward and correct: AI agents should not hold raw credentials. They should route through a broker that attaches secrets at the edge, enforces policy, and keeps the model away from the thing attackers most want it to reveal.

That design only works if the data plane is as trustworthy as the dashboard. In 0.35.1, Infisical fixed a bug where dynamic credentials could appear configured in the UI while proxied requests failed with credential_not_found. Static credentials worked. Dynamic credentials did not. For a product whose most important long-term value is dynamic secret brokering, that is not a cosmetic bug. That is the credibility line.

The release was published on June 14, 2026, with ten assets. At research time the repository had roughly 1,671 stars and 87 forks and described itself as “A HTTP credential proxy and vault for AI agents like Claude Code, OpenClaw, Hermes, custom agents + harnesses, and more.” The changelog contains a single item: commit 30ff25ce8f3c8cfd855e4e2d3e7713bb0b007eed, “fix(broker): resolve dynamic secrets through the MITM proxy (#269).” The compare from v0.35.0 to v0.35.1 shows one commit and two changed files.

Small diff, large blast radius. That is agent infrastructure in one sentence.

The bug was initialization order masquerading as security behavior

PR #269 explains the failure clearly. Proxied requests using an Infisical dynamic credential failed with credential_not_found and a 502 even though the credential was visible in the credentials table. The root cause was timing. attachMITMIfEnabled called srv.CredentialProvider() once at attach time. The old provider only set its Dynamic resolver if s.infisicalDynamic was already initialized. But s.infisicalDynamic was created later inside srv.Start(), so the proxy captured a nil dynamic resolver and kept it for the lifetime of the process.

The fix is a lateDynamicResolver adapter that reads s.infisicalDynamic per request instead of snapshotting it during attach. The public broker-core surface stays unchanged; the lifecycle complexity remains in the server package. That is a good fix not just because it resolves the bug, but because it puts dynamism where it belongs: at request time.

This is the sort of issue that rarely gets a big launch thread because it sounds like plumbing. But for security products, plumbing is product. A UI can truthfully say “this dynamic credential exists” while the proxy data path cannot resolve it. To an operator, that feels like the system is lying. To a security engineer, it means the control plane and data plane disagree. Both are bad. Credential brokers live or die on consistency between what the administrator configured and what actually happens on the outbound request.

Why dynamic secrets are the adult version of agent security

Agent Vault’s broader argument is stronger than “store secrets somewhere encrypted.” Infisical’s launch post frames the principle bluntly: “agents should never see the underlying secret in the first place.” That is the correct abstraction for a world where prompt injection, poisoned documentation, malicious tool output, and accidental transcript leakage are normal operating conditions.

Short-lived credentials help, but they do not fully solve the problem if the agent can still read, print, or exfiltrate the credential during its lifetime. Credential brokering changes the topology. The agent sends ordinary HTTP traffic through a forward proxy, sidecar, or egress layer. The broker swaps dummy headers such as placeholder API keys for real credentials, or replaces authorization headers entirely. The upstream service receives valid auth. The agent never sees the underlying secret.

Static credentials inside a broker are useful. Dynamic credentials are where the model becomes much more compelling. Databases, cloud resources, internal services, and vault-backed workflows all benefit from just-in-time issuance and short blast radius. If a broker can mint or fetch a dynamic credential at the moment of use, attach it to the request, and keep it invisible to the agent, the security posture is materially better than “put an API key in an environment variable and hope the model behaves.”

That is why the 0.35.1 bug matters. If dynamic credentials fail through the MITM proxy while static credentials work, teams will do the predictable thing under delivery pressure: fall back to static secrets or paste credentials into the agent environment. The system does not need to be catastrophically broken to lose. It only needs to make the safer path feel unreliable.

The useful details are in the boring security docs

Agent Vault’s documentation is unusually specific in places where specificity matters. The docs describe AES-256-GCM encryption at rest, a KEK/DEK wrapping architecture, Argon2id with time cost 3, memory cost 64 MiB, parallelism 4, and 256-bit DEK/KEK lengths. Token prefixes include av_sess_, av_agt_, av_appr_, and av_uinv_. The network guard blocks cloud metadata endpoints including 169.254.169.254/32 and fd00:ec2::254/128.

The metadata endpoint block deserves more attention than the crypto list. Crypto choices matter, but most agent credential disasters will not start with someone breaking AES-GCM. They will start with an agent being convinced to call a URL it should never call, read an environment variable it should never see, or proxy a request through a path that bypasses policy. Blocking cloud metadata endpoints, defending against DNS rebinding by resolving and validating IPs before connecting directly, and keeping proxy authorization hop-by-hop are practical controls for practical failures.

The docs also note an important deployment assumption: the local proxy link carries the session token in cleartext unless deployed on localhost, a private network, or a VPN. That honesty is valuable. Too many agent-security pitches imply a magic boundary where there is only a process boundary and some wishful thinking. Agent Vault is strongest when it is explicit about what it protects, what it assumes, and where the operator still has work to do.

Credential brokering belongs in the agent evaluation checklist

The industry conversation around coding agents still overweights editor UX and model benchmarks. Those are real. They are not enough. A team comparing Claude Code, OpenCode, Qwen Code, Codex, Gemini-style CLIs, or a custom OpenClaw harness should ask a more basic question: where do the credentials live?

If the answer is “in the agent process environment,” then the model may not intentionally leak them, but the architecture has already made leakage possible. If the answer is “in a local config file the agent can read,” same problem with nicer indentation. If the answer is “in a broker the agent can only use indirectly, with network policy preventing bypass,” now there is something worth evaluating.

A serious eval should test ugly paths, not just happy paths. Create a dynamic credential and confirm it resolves through the same proxy path as a static one. Rotate it. Restart the broker. Force the proxy to initialize before the dynamic subsystem if that is possible in your deployment shape. Confirm the request still resolves dynamically. Try to bypass the broker. Try to reach cloud metadata endpoints. Confirm the agent token is not forwarded upstream. Run the test while the agent is handling concurrent tool calls, because concurrency is where lifecycle bugs become production bugs.

The deeper lesson from 0.35.1 is that initialization order is part of the security model. A stale nil resolver is not just a programming bug; it changes who can access what, when, and through which surface. Agent systems are full of these seams: daemon startup, plugin registration, MCP server auth, OAuth token refresh, background worker launch, shell approval prompts, sidecar readiness. Any one of them can create a gap between the policy you think you configured and the behavior your agent actually gets.

Infisical’s release also includes supply-chain verification instructions for checksums.txt and Docker image signatures using cosign verify-blob and cosign verify, pinned to the GitHub Actions OIDC issuer https://token.actions.githubusercontent.com. That is table stakes for infrastructure distributed as binaries and containers, but it is still worth noting. If the credential broker is part of your agent trust boundary, its build provenance is not decoration.

The forward-looking take is simple: agent security is moving from “hide environment variables better” to “design the credential path so the model never receives the secret.” Agent Vault 0.35.1 is a small patch in that larger shift. It fixed the dynamic resolver at the moment of use, which is exactly where a broker earns its keep.

If you build agents, adopt this mental model: credentials are not configuration; they are runtime authority. Do not hand runtime authority to a probabilistic system and then act surprised when a prompt-injection bug becomes an access-control bug. Put a broker in the path, make the broker boring, and then test the lifecycle edges until they stop being interesting.

Sources: Agent Vault v0.35.1 release, Infisical Agent Vault launch post, Agent Vault security docs, PR #269, Agent Vault repository, v0.35.0...v0.35.1 compare