Credential Brokering for AI Agents, Explained | InfisialInfisical

Stars<br>Docs<br>Careers<br>Blog<br>Pricing

Sign Up

Get a Demo

← Back<br>Blog post • 10 min read<br>Credential Brokering for AI Agents, Explained

Published onSaturday, May 23, 2026

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...