Disclosure: BlueBear sells a gateway that performs the credential checks described here, so we have a commercial interest. The decision itself is an architecture choice you make regardless of what you buy, and the checklist at the end is written to be run against any stack, including one you build yourself.
The question you will eventually be asked
At some point after the agents are working, someone asks a question that sounds administrative and is not: which system was that credential issued for? It may come from an auditor, from a customer's security review, or from your own team at two in the morning trying to establish what an agent touched. The answer is determined years earlier, by a decision that felt like plumbing at the time.
If you are putting AI in front of your own staff or your own customers, on infrastructure and systems you already run, most of the hard work is not the model. It is the wiring: the agent needs to reach an ERP, a CRM, a file store, an internal API. Each of those already has a way to authenticate. The shortest path is to reuse it.
Why the shortcut is the default
Reusing a token is not laziness. When you already operate the systems, you already hold working credentials for them, and the fastest way to make an agent useful is to hand it what you have. The agent receives a token, and when it calls the next system it presents that same token. This is token passthrough, and it works immediately, which is exactly the problem: nothing fails, so nothing prompts a second look.
It is also easy to arrive at by accident. An integration built for one system gets extended to a second. A service account created for a nightly job becomes the identity an agent runs under. No one decides to adopt passthrough; it accumulates.
What it costs
A leak stops being local
A credential that several systems accept is worth whatever the most valuable of those systems holds. If any one component is compromised -- a dependency, a misconfigured log sink, a developer laptop -- the attacker does not get access to that component's scope. They get everything the token was ever good for. You did not choose that exposure; it is a property of having one credential do several jobs.
Attribution becomes an argument
This is the more expensive cost, and the slower one to surface. When the same credential is accepted everywhere, a log entry can record that something happened but cannot establish that a particular agent, acting on behalf of a particular person, was authorised against that particular system. You are left correlating timestamps and inferring intent.
That inference is fine until it is contested. In a security review, a regulatory conversation, or a customer dispute, "we believe this was the reconciliation agent because the timing matches" is an argument. "This credential was issued for this system, on behalf of this user, with this scope, and the request was allowed" is evidence. The difference is not effort spent on logging. It is whether the credential carried enough information to log in the first place.
What replaces it
One credential per system, and each system checks
The replacement is to issue the agent a separate credential for each system it reaches, and to have each system verify that the credential names it as the intended recipient. That check is the audience claim. The mechanism for requesting a credential scoped to a specific system is a resource indicator, standardised in RFC 8707, and the Model Context Protocol authorization specification requires both the indicator and server-side validation for exactly this reason.
Two things change. A leaked credential now opens one door rather than all of them. And every system can state, from the credential alone, that it was the intended recipient -- which is the sentence your audit record needs.
Short lifetimes, so a leak expires
Audience binding limits where a credential works. Short lifetimes limit how long. Minutes rather than hours means a credential captured from a log or a crash dump is usually worthless before anyone reads it. The operational cost is real but bounded: something has to reissue credentials continuously, and that machinery has to be reliable, because when it fails your agents stop. This is a genuine trade, not a free win, and it is worth deciding deliberately rather than defaulting to long-lived tokens because refresh is inconvenient.
Records that keep the decision without keeping the secret
There is a real tension between an audit trail complete enough to defend and one that does not itself become a liability. Storing tokens to preserve context creates a new place credentials live.
The resolution is that the useful part of an authorization event is not the credential. It is the decision: which identity, acting for whom, against which system, with what scope, allowed or denied, and on what basis. Record that and discard the credential. You get an audit trail that answers the question and contains nothing worth stealing.
Four checks that tell you which design you have
These are answerable in an afternoon, against your own stack or a vendor's:
- Does a credential accepted by one system also work against another? Take a token your agent uses for one system and present it to a second. If the second accepts it, you have passthrough, whatever the architecture diagram says.
- Does each system verify it was the intended recipient? Not whether the credential is valid -- whether it names that system. A valid credential meant for somewhere else should be refused.
- How long is a credential useful after it leaks? Read the actual lifetime, not the policy. If it is hours, assume anything that ever reached a log is still live.
- Can you answer "which system was this issued for" from a record, without replaying the credential? If answering requires correlating timestamps, you have logs but not evidence.
What this costs to do
Honestly: the first two checks usually cost nothing to fix if you catch them early, because they are configuration on the authorization server and a validation step at each system. The third is where the real work sits, since short lifetimes demand reliable reissue. The fourth is mostly deciding what to write down, which is cheap to do at the start and expensive to retrofit once you have a year of logs in the wrong shape.
None of it requires buying anything. It requires deciding it before the wiring calcifies -- because the credential design is the part of an agent deployment nobody revisits once it works.
BlueBear MCP Authorization Evidence Contract
The MCP specification prohibits token passthrough because a server accepting a token that was not issued for it breaks audience validation and the authorization boundary. In a BlueBear architecture review, this becomes a testable execution contract rather than a reminder to “secure the token.”
| Decision point | Required evidence | Failure test |
|---|---|---|
| Issuer and subject | Trusted issuer, authenticated human or service subject, tenant, and workspace. | Reject an unknown issuer or subject outside the workspace. |
| Audience and resource | The token audience/resource matches the MCP server or protected resource receiving it. | Replay a token issued for a different service and confirm denial. |
| Capability scope | Assigned MCP connection, permitted tool, action class, resource scope, and approval requirement. | Request an unassigned tool or broader action and preserve the denial reason. |
| Credential resolution | Credential reference, expiry, selected connector, and execution receipt; no reusable token in model context. | Inspect prompts, model logs, and workspace artifacts for bearer material. |
| Delegation and outcome | Correlation from authenticated actor through policy and tool execution to the accepted result. | Attempt to complete a run when the delegation or approval context is missing. |
BlueBear boundary: workspace assignment, policy evaluation, scoped credential resolution, and correlated execution evidence are platform controls where configured. Issuer policy, identity-provider configuration, token lifetime, key ownership, and downstream resource authorization remain deployment-specific and must be verified.
Questions people actually search for
- what is token passthrough and why is it a problem for ai agents
Token passthrough is when a service accepts an access token and forwards that same token to the next system rather than obtaining one scoped to it. It is a problem for agents because the token stops describing a relationship between one caller and one system. Any system that accepts it will honour it, and no system can demonstrate the token was issued for it. That costs you two things at once: a stolen credential reaches everything the original was good for, and your logs cannot establish which system a credential was actually meant for.
- how do i connect an ai agent to our existing erp and crm safely
Issue the agent a separate credential per system rather than reusing one you already hold, and have each system verify the credential names it as the intended recipient. That check is the audience claim, and the mechanism for asking for it is a resource indicator (RFC 8707). Keep the lifetimes short so a leaked credential expires before it is useful, and record the authorization decision -- who, which system, what scope, allowed or denied -- without recording the credential itself.
- what is audience binding for access tokens
Audience binding means an access token names the system it was issued for, and that system rejects it if the name does not match. It converts a credential from a general key into a specific one. The practical effect is that the blast radius of a leak becomes one system rather than every system that would have accepted the original token, and your audit record can state which system the credential was for rather than inferring it.
- can we prove what an ai agent did if it uses shared credentials
Not reliably. If the agent acts with a credential that several systems accept and several callers share, the log can show that an action happened but not that this agent, acting for this person, was authorised against that system. Attribution then depends on correlating timestamps, which is an argument rather than evidence. Per-system credentials with a recorded authorization decision turn the same question into a lookup.