Your Agent Knows Your API Keys: Credential Brokering With Infisical's Agent Vault

In August 2024, researchers at PromptArmor disclosed a prompt injection flaw in Slack AI: an attacker could hide a malicious instruction in a public channel or an uploaded document and get the assistant to exfiltrate data from private channels it was never supposed to share — including API keys developers had pasted into private threads. No exploit chain, no privilege escalation. The model could read the secret, so a cleverly worded sentence could make it repeat the secret. Every agent you run today with credentials in its environment inherits exactly that failure mode.

Here is the verdict up front: stop putting secrets where the model can read them. Short-lived tokens narrow the blast radius but leave the mechanism intact — a key that lives for an hour can still be exfiltrated in a second. The pattern the industry is converging on is credential brokering: the agent holds a dummy placeholder, and an egress proxy swaps in the real credential on the way out. Infisical's Agent Vault, an open-source HTTP credential proxy that hit 156 points on Hacker News in the spring of 2026, is the most portable implementation of that pattern to date. This post walks through how it works, how it compares to the alternatives, and what a self-hosted platform should build so tenants' keys never transit an LLM.

How Agent Vault works​

The core idea fits in one sentence: the agent's traffic passes through a proxy that knows the secrets so the agent doesn't have to. The implementation is a single self-hostable Go binary (server plus CLI, also available as a Docker container) that wraps any local agent process:

agent-vault run -- claude

That command creates a scoped session, sets HTTPS_PROXY plus CA-trust environment variables (SSL_CERT_FILE, NODE_EXTRA_CA_CERTS, and friends), and launches the agent. From that moment, all of the agent's HTTPS traffic is transparently routed through Agent Vault's MITM proxy, which runs its own certificate authority — the server exposes its root CA, and the child's trust store is configured to accept it, so TLS interception works without touching the agent's code.

The request flow for one authenticated API call looks like this:

1. The agent reads its configuration and finds a dummy credential — something like __anthropic_api_key__ — instead of a real key. This placeholder is the only thing that ever enters its context window, its logs, or its persisted memory.
2. The agent makes a normal HTTPS request with the dummy credential, exactly as it would have with a real one. No SDK changes, no wrapper libraries; CLIs, SDKs, and MCP clients all keep working unmodified.
3. The proxy terminates TLS, recognizes the dummy credential, injects the real vault-managed secret, applies any configured request rules, and opens a fresh TLS connection upstream.
4. The response flows back untouched. The agent used the API successfully and never held anything worth stealing.

Two properties make this more than a clever hack. First, it is interface-agnostic: because brokering happens at the HTTP layer, it covers every tool surface an agent might use — REST calls, CLIs that shell out to HTTPS, MCP servers reached over Streamable HTTP — without per-integration work. Second, the TLS-termination point doubles as a policy enforcement point. Since the proxy already inspects traffic to inject credentials, it can also apply firewall-like rules per request: this session may call this host and path, nothing else. Infisical's launch post explicitly names that extension path, and it is the same shape Anthropic described in its Managed Agents architecture ("the harness is never made aware of the credentials"), with similar schemes emerging from Vercel and Cloudflare's Outbound Workers.

The honest caveat, stated in the launch thread itself: Agent Vault shipped as a research preview with an unstable API and a clunky first-run configuration experience. Treat it as a reference implementation of the right pattern, not a finished product.

The comparison: four ways to give an agent credentials​

Brokering is not the only answer. Here is how it stacks up against the three alternatives teams actually run, scored on the properties that matter for agent workloads on a self-hosted platform.

Each column wins somewhere real:

• Env-var injection wins on simplicity and stays correct for deterministic, non-agentic workloads — a cron job cannot be prompt-injected. It is specifically wrong for agents, which are non-deterministic, read untrusted content, and can be manipulated into echoing what they hold.
• Short-lived tokens win as defense in depth. A token vending service that mints scoped, minutes-long credentials bounds what any single exfiltration yields. But bound the damage as you like, the exfiltration channel stays open: the token still crosses the context window.
• SPIFFE/SPIRE workload identity wins where both ends are yours. A SPIRE agent attests the workload and issues auto-rotating X.509 SVIDs, so services authenticate with short-lived certificates instead of shared secrets — no keys anywhere, mTLS between everything. Red Hat's 2026 zero-trust-agents work shows the shape extended to agents with hour-TTL identities. The catch is the third-party wall: Stripe's API will not accept your SPIFFE ID. The moment an agent calls an outside service with an API key, workload identity has nothing to say.
• The egress broker wins exactly at that wall. It is the only approach that keeps working when the credential is a third-party API key the agent must use but must never see — which describes nearly every deploy, payment, and SaaS integration an operations agent touches.

The pragmatic stack is a combination, not a pick-one: SPIFFE-style identity for service-to-service calls inside your own fleet, brokering at the egress boundary for everything keyed, and short-lived tokens underneath both so that even the broker's vault holdings rotate. The table's real message is which layer owns which secret, not which tool replaces the others.

What brokering doesn't solve​

A proxy that holds every secret is a high-value target, and intellectual honesty requires naming what the pattern leaves open.

The network lockdown is mandatory, not optional. Brokering only works if all outbound traffic is forced through the proxy. An agent process with a direct route to the internet bypasses every guarantee — it cannot leak a key it never had, but nothing stops it from sending data elsewhere. In a full deployment that means egress network policy (Kubernetes NetworkPolicy, Cilium rules, or firewall defaults) with the proxy as the only exit. Teams that deploy the proxy without the lockdown get theater.

CA trust management is real operational work. Every agent runtime — containers, sandboxes, CI runners — needs the proxy's root CA in its trust store, or TLS interception breaks with certificate errors. Agent Vault automates this for wrapped local processes, but fleet-wide rollout means baking CA distribution into your base images and sandbox provisioning. Miss one runtime and its agents either bypass the proxy or fail closed, depending on how strict your lockdown is.

The proxy sees everything. Terminating TLS to inject credentials means the broker observes request and response bodies in cleartext. That is the price of the pattern, and it concentrates risk: compromise the broker and you hold every tenant's keys at once. Scope sessions tightly (one session per agent run, least-privilege credential sets), audit every brokered call, and treat the broker's own hardening as tier-zero work. This is also why per-tenant broker instances beat one shared proxy for a multi-tenant PaaS — blast-radius isolation at the layer that holds the keys.

Credential exfiltration is not data exfiltration. Brokering answers "how does the agent authenticate without reading secrets." It says nothing about what the authenticated agent is allowed to do once inside — a prompt-injected agent with a brokered deploy credential can still push a malicious deploy. Authorization policy (which tool calls, against which targets, under whose approval) is a separate layer, enforced at the MCP gateway or API, not at the credential proxy. Solve both; neither substitutes for the other.

Maturity is early. Agent Vault's research-preview status, unstable APIs, and the later arrival of Infisical's own native Agent Proxy (now the recommended path for Infisical users, with Agent Vault positioned as the self-contained open-source option) all say the same thing: adopt the pattern, but budget for churn in any specific implementation.

What a self-hosted PaaS should build​

If your platform treats AI agents as first-class operators — deploy-from-chat, agent-driven rollbacks, tenant agents running against your APIs — then tenant API keys transiting LLM context windows is not an edge case, it is your default data flow. Here is the build checklist that closes it:

1. Brokered egress per tenant. Give every tenant's agents a credential-brokering proxy on their outbound path, whether that is Agent Vault self-hosted, your own HTTPS_PROXY implementation, or a sidecar in the agent sandbox. The tenant stores keys in your secrets backend; agents receive placeholders.
2. Scoped sessions per agent run. Mint a fresh broker session for each agent execution with only the credentials that run needs. A deploy agent gets the deploy key; it does not get the billing key. Session teardown revokes everything at once.
3. Default-deny egress with the broker as the only exit. Network policy should make direct internet access from agent sandboxes impossible. The proxy is not a suggestion in the agent's environment; it is the only route out.
4. An audit log of brokered calls. Log which session used which credential against which host and path. When something goes wrong — and with agents, something eventually goes wrong — "which key called what, when" is the first question, and only the broker can answer it authoritatively.
5. Keep workload identity for your own interior. SPIFFE/SPIRE (or cloud workload identity where you run) for service-to-service auth inside the fleet; brokering at the boundary for third-party keys. Don't stretch either pattern across the other's territory.

The underlying principle generalizes beyond any one tool: anything an agent can read, a prompt injection can repeat. Design your secret flows so that the set of credentials visible to the model is empty — not short-lived, not scoped, empty — and an entire class of agent compromise collapses from "assume breach" to "nothing to steal."

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.