Credential Brokering for AI Agents, Explained

Every agent deployment runs into the same problem: The agent needs credentials but it can’t be trusted with them.

The most important credential, the LLM provider key, authenticates the agent’s harness, the inference loop that’s used for decision-making; other credentials let it reach external systems needed to accomplish its task. For example, an agent working on a codebase might use an Anthropic API key and a GitHub access token to build a feature and raise a pull request against a repo using the GitHub CLI.

This is simple to provision but just about everyone runs into the same question once they start giving the agent access to more services: What if the agent gets prompt injected or reads a malicious script that fools it into leaking the credentials it needs to access different systems?

This is an intro to credential brokering, an emerging paradigm to build and deploy agents securely, so they can use credentials without seeing them to access different systems. Hopefully, this makes for an interesting read and is especially useful for folks who may find themselves building or deploying their own agents.

Prompt Injection

To understand why we need credential brokering, let’s take a step back and talk about what makes an AI agent different from a traditional workload and the implications that come from that.

Unlike most applications that follow a fixed code execution path, agents are non-deterministic and everything, from which tools get invoked to what specific responses get sent back, can vary based on the probabilistic output of the connected LLM. This property is what makes agents behave in the way they do but it also introduces a new attack vector to reason about: prompt injection.

In its most obvious form, prompt injection can occur through explicit user input. A user talking to an agent through a chatbot interface can try to manipulate it into leaking unintended information. This is what most engineers designing agents account for when building guardrails to prevent bad actors exploiting this vulnerable surface.

Beyond user input, prompt injection can also occur indirectly through content pulled in from external sources and that’s when things get tricky. An agent might perform a web search to get up-to-date information on something and, in doing so, process malicious text from an unintended source instructing it to leak credentials back to an attacker. This scenario becomes even more dangerous when an agent gets access to a wider data ingestion surface area with each channel having its own nuances. To put this into perspective:

• An attacker can raise an issue against a repo containing a malicious set of instructions. If an agent is authorized to do work for that given repo and instructed to help resolve issues, it may inadvertently consume that text and perform an unintended, authorized action.
• An attacker can reply to a post on X with a malicious set of instructions. If an agent is designed to scan, reply, and act on different posts on X, then it may inadvertently read the tweet and be fooled into performing an unintended action.

We can go on and on about prompt injection but you get the point; agent behavior is vulnerable by design and the surface area of how that vulnerability can be exploited increases with the number of the channels that an agent has access to.

Credential Exfiltration

Naturally, an adjacent problem to understand after prompt injection is credential exfiltration which is when an attacker obtains credentials that an agent has access to.

If an attacker is able to manipulate a vulnerable agent into performing a task, then they could also find a way to instruct the agent to send back all of its credentials (maybe even dump the full `process.env`). After all, this is just another type of action that the agent may take; except this action, arguably the most sensitive of them all, gives the attacker the credentials needed to directly access end services as the agent.

This is credential exfiltration at its worst and our goal with this article is to show you a solution around this problem.

Credential Brokering

Since agents are vulnerable to credential exfiltration, a logical deduction would be to draw a trust boundary between an agent and its credentials. Put differently, it would be ideal to let agents use credentials to access different services without giving them direct access to any of the underlying sensitive values.

This turns out to be possible with an emerging paradigm called credential brokering that the industry has been converging on. Here are a few examples of it in action:

• Anthropic's Managed Agent Infrastructure describes a dedicated proxy where "the harness is never made aware of the credentials" — the agent submits requests through a layer that injects auth before the request reaches the upstream service.
• Vercel implements credential injection at the sandbox layer for agents running in their platform.
• Cloudflare's Outbound Workers for Sandboxes attach credentials at the egress layer, so workloads inside the sandbox never hold them.
• LangChain’s sandbox auth proxy that lets sandboxed code call external APIs without hardcoding credentials.

In short, credential brokering is a new security paradigm that introduces a proxy to broker an agent authenticated access to services without giving the agent direct access to any underlying credentials. The proxy (dubbed a “credential broker”) can be implemented as a standalone service, sidecar, or another infrastructure provider-specific mechanism and is responsible for intercepting outbound requests, attaching credentials onto them, and forwarding them upstream to the target service.

By inserting a credential broker in between the agent and services it needs to talk to and forcing outbound traffic through it, you are able to make an agent complete its work without reading any underlying credential.

Designing a Credential Broker

There are a few ways to implement a credential broker and the approach you pick has downstream implications on your agents' existing tools and workflows.

We’re probably biased since we built Agent Vault, an open source credential broker, but we believe one clean model is to implement a credential broker as a scalable centralized gateway proxying traffic for one or many more agents. This could be stateful to start and move to a stateless model at scale; this should also pull in credentials from a centralized secrets store like Infisical. The opinionated take here draws from our view that a credential broker is really just another client, like the External Secrets Operator (ESO) or cert-manager from the secrets and certificates management worlds, but that makes credentials usable to agents through a proxy broker format.

Whether you choose to adopt Agent Vault, use a different tool, or build your own solution, we’ve compiled a list of some key learnings from our time working at this new frontier. We believe the following properties hold favorably for credential broker design:

• Isolation: It's critically important that the agent cannot directly access the broker's credentials. While we wish deploying the agent and broker in two separate containers on the same host machine provided sufficient isolation, the reality is that having a shared host kernel implies that a single kernel exploit voids the entire threat model.
• Co-location: It’s best for the agent to be located within close proximity to the broker. Since a single agent can rapidly fire hundreds of API calls in sequence as part of its agent loop, the downstream effects of latency can add up fast and result in severe cumulative delays and ultimately a bad experience if the agent is not co-located near the broker.
• Keep the broker private: A broker holding real credentials and proxying authenticated requests should only be reachable from the private network where the agent is run. A public endpoint is a relay anyone on the internet could abuse to make authenticated calls through the broker.

Beyond these properties, the last principle worth calling out is that the ideal broker should be transparent and interface-agnostic. This is what underpins our own implementation in Agent Vault and is one of the least invasive options compared to alternative approaches we've seen that require an agent to adopt a specific client interface like MCP in order to partake in any credential brokering.

In an ideal world, your agents should be able to continue using the tools and interfaces they already use (CLIs, SDKs, MCPs, etc.) with minimal interference from the newly-introduced proxy. The broker should intercept all outbound HTTPS traffic from the agent at the network layer, regardless of which interface was used to generate a request, and it should just work.

Agent Vault

To make the concepts above concrete, it helps to look at a real implementation: Agent Vault. This is an open source credential broker we built and are actively maintaining at Infisical and while the specifics will differ across tools, the shape of the system is broadly representative of what a credential broker might look like in practice.

At its core, the broker runs as a dedicated service on its own host, separate from the agent. It's configured with the credentials, a set of rules mapping credentials to be brokered for target services, and an agent-side configuration that redirects outbound traffic through it with `HTTPS_PROXY`. From there, the agent operates as it normally would; the broker handles credential attachment at the proxy layer.

One design choice worth calling out: Rather than hardcoding the auth scheme for each target service, the broker is able to perform string substitution on placeholder values. The agent is given something like __github_token__ instead of a real token, and the broker swaps it for the real credential wherever it appears in the outbound request. This avoids having to teach the broker about every service's auth conventions and means the same mechanism works whether the credential is a Bearer token, an API key header, a query parameter, or something else entirely.

Here's what a brokered request looks like end to end:

1. Agent constructs the request. It calls api.github.com with Authorization: Bearer __github_token__ — the placeholder from its env.
2. Request routes to the broker. The agent's HTTP client follows HTTPS_PROXY and routes the request through the broker's private address instead of GitHub.
3. Broker authenticates the agent and matches the destination. It identifies the agent, finds the rule for api.github.com, and decrypts the real GITHUB_TOKEN into memory.
4. Broker substitutes the placeholder. It finds __github_token__ in the request and swaps it for the real access token. This happens on the broker's side of the wire, past the point the agent could observe it.
5. Rewritten request goes to GitHub. A normal authenticated API call from GitHub's perspective.
6. Response flows back through the broker to the agent. The agent gets its data. It never saw the credential.

The interesting part here isn't any one implementation; it's that the trust boundary now sits between the agent and the credential, which is exactly where it should be.

The Road Ahead

Credential brokering is shaping up to be the right primitive for how agents should access services and we expect more teams to converge on this model as agent deployments mature. The signal is already there: Anthropic, Vercel, Cloudflare, LangChain and a handful of open source projects have independently arrived at the same conclusion, which is that the agent shouldn't be the thing holding the credential.

Whether you build your own, adopt Agent Vault, or pick up something else entirely, the underlying principle holds: if an agent can't be trusted with credentials, it shouldn't have them. The proxy is just the cleanest way we've found to make that true in practice. If any of this resonates and you'd like to dig in further, give Agent Vault a look or reach out to the team; we'd love to compare notes with anyone building in this space.