Compare
Credential broker vs MCP authentication
Last updated:
In short
MCP authentication controls how a client connects to an MCP server. A credential broker controls whether and how the agent may use a specific downstream credential at runtime.
They work at different layers and can be complementary. MCP's authorization model decides which client may open a session with which MCP server and what scopes that session has. A credential broker decides — for one specific downstream API call — whether this workspace, this agent, this action, and this account are approved before the credential is applied. Used together, they cover a case neither covers alone: a properly authenticated MCP session that could otherwise reach any client's account with equal ease.
This is not a case against MCP. MCP connects agents to tools, and it is good at that job. A credential broker controls how approved downstream credentials are used once a tool call is already happening — a layer MCP was never designed to own.
What MCP authentication controls
MCP's authorization model is connection-level: a client authenticates to an MCP server (typically OAuth-based), the server grants that session a set of scopes, and the session can call the tools those scopes allow for as long as it holds them. The question it answers is "can this client talk to this server, with these permissions?" — decided once, at connection time.
What a credential broker controls
A credential broker acts later and narrower: at the moment a tool call is about to touch a real downstream credential — an ads account, a CRM, a mailbox — it decides "given this connection is valid, may it use this specific account, for this action, right now?" It checks workspace, account pin, host, and approved action, applies the credential host-side, and returns a redacted result. The agent requests an action, never the credential itself.
Why they are different layers
MCP authorization is decided once, per session, at the connection. A credential broker decides again, per request, at the point of use. A session that is correctly authenticated under MCP can still reach the wrong client's account if nothing governs which downstream credential a given call should use — MCP's scopes describe which tools a session may call, not which of many client accounts behind that tool is the right one for this task. That is the gap a credential broker closes.
When MCP authentication is enough
For a single developer or a single-account setup — one MCP server, one downstream account, no multi-tenant question — MCP's session-scoped authorization is enough on its own. There is no "wrong client" to protect against when there is only one client.
When a credential broker is still needed
The gap opens as soon as the same MCP tool has to serve more than one downstream account — the common case for agencies and operators running agents across client workspaces — or when a requirement exists that the raw credential never enter agent context at all, regardless of what the MCP session is scoped to, or when a per-request, per-client audit trail is required for what actually ran.
Multi-client example
An agency runs one MCP server exposing a CRM tool. Client A, Client B, and Client C each have a separate CRM account. MCP's session authorization has no concept of which client the current task is for — it only knows the session is allowed to call the CRM tool at all. A credential broker does know: the request carries the workspace it came from, and the workspace is pinned to the correct client account before the credential is applied.
Wrong-account example
An agent, correctly authenticated under MCP, is asked to run an update inside what should be Client A's workspace — but a stale session or a copied configuration points it at Client B's account instead. MCP's authorization layer has no way to catch this: the session is still valid and the scope still matches. A credential broker checks the workspace-to-account pin before the credential is used and denies the mismatched request before any backend call runs — see wrong-client access in agent loops.
How a request flows once a credential broker is added
- 01
Agent request
The agent asks for an approved action or alias — not a raw key.
- 02
Policy & tenant check
Outloop checks project, tenant identity, and runtime policy before anything runs.
- 03
Local broker
On approval, the local broker uses the credential on the wire to perform the call.
- 04
Redacted result
The agent receives a sanitized, non-secret result. Raw values never enter its context.
- 05
Audit log
Every attempt is written to a redacted local audit — decision, tenant, service.
The agent never sees the credential. A wrong-tenant request is denied at the policy check, before any backend call.
Side by side
| Dimension | MCP authentication | Credential broker |
|---|---|---|
| What is authenticated | The client's connection to an MCP server | A specific request to use a specific downstream credential |
| Where the credential lives | Wherever the MCP server or tool stores it | Local vault or OS keychain (e.g. macOS Keychain) |
| Does the agent see the raw credential | Depends on the server/tool implementation | No — applied host-side, redacted result returned |
| Tenant / client scoping | Not a native concept — one session, one scope set | Workspace-to-account pinning per client |
| Downstream account pinning | — | ✓ |
| Token lifetime | Session-scoped, per MCP server config | Applies the credential you already hold; not universal short-lived minting |
| Runtime, per-request policy | — | ✓ — checked before every call |
| Audit | Depends on the server/tool | Redacted local audit of every attempt, allowed or denied |
| Redaction | Depends on the server/tool | ✓ — secret_exposed:false on every brokered call |
| Destructive-action controls | Depends on the server/tool | Policy-gated; off by default for irreversible actions |
| Best fit | Single account, one MCP server, no multi-client question | Multiple client accounts behind the same tool, or agent must never hold the raw credential |
Related: MCP for multi-client AI agents, what is a credential broker for AI agents, Outloop is not a vault, agent runtime access, and AI agent security. Outloop is available with guided onboarding for agency teams; the local app is verified on the founder's Mac; Apple signing/notarization and second-machine reproduction are still in progress.
MCP connects the tool. A credential broker controls how it's used.
Outloop is available with guided onboarding for AI agencies, operators, and dev shops.