Compare
MCP authentication — and where a credential broker fits
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 authorization governs requests to the MCP server, including token audience and scope checks. 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. A server can also implement its own downstream account policy; a broker is one way to centralize that decision.
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 | Depends on server and downstream policy | Workspace-to-account pinning per client |
| Downstream account pinning | Server-specific | ✓ |
| Wrong-client protection | Requires a configured downstream account policy | ✓ — denied before any backend call if the workspace-to-account pin does not match |
| Token lifetime | Token lifetime and permissions depend on configuration | Applies the credential you already hold; not universal short-lived minting |
| Runtime, per-request policy | Token validation plus server-specific 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 |
See Outloop’s side of the comparison.
Watch the workspace policy check, approved action and recorded denial that downstream credential brokering adds to a workflow.
This is an Outloop example, not a side-by-side MCP implementation benchmark.
- Workspace-scoped action requests
- Labeled dashboard views and recorded denials
- Redacted API evidence
Create your trial, then install on your company-controlled Mac. Set up your first workspace.
56 seconds · One request, the right client · No form required
The opening is an architecture illustration. Dashboard views and recorded denials are labeled in the video; API evidence is redacted. Shown campaign execution stays PAUSED.
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
For HTTP transports, MCP authorization uses access tokens scoped to the intended MCP server. Authorization accompanies every HTTP request; the server validates the token and applicable permissions. The question it answers is "can this client talk to this server, with these permissions?". Downstream account selection still needs an explicit policy.
How MCP authentication works
The MCP authorization specification (revision 2026-07-28) makes authorization optional. When a server uses it, what happens depends on the transport:
- →Remote servers (HTTP): OAuth 2.1. The MCP server acts as an OAuth resource server; the client discovers its authorization server through OAuth Protected Resource Metadata, and the access token must be issued for that specific server as its audience (Resource Indicators, RFC 8707).
- →Local servers (STDIO): the specification says they should not use that flow and should take credentials from the environment instead — in practice, an API key in an environment variable next to the agent.
- →No token passthrough: an MCP server must only accept tokens issued for itself and must not accept or pass through any other token. To call a downstream API — Google Ads, a CRM, a mailbox — the server needs its own credential for it.
That last point is where the two layers meet. MCP authentication proves the client may use the server. Which downstream credential the server then uses — and for which client's account — is outside what the specification decides. That is the question a credential broker answers.
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 protects requests to the MCP server. Downstream account policy decides which client's resource a tool may use. A server can implement both; a credential broker provides a separate place to enforce the downstream decision and record the result.
When MCP authentication is enough
For a single developer or a single-account setup — one MCP server, one downstream account, no multi-tenant question — a well-configured MCP server may provide the controls you need. Review its credential handling, downstream permissions and audit behavior before deciding whether to add a broker.
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. If the server only checks access to the CRM tool, that check does not establish which client the task is for. A configured broker adds this decision: 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 alone may not catch this if the server has no downstream account policy. A configured 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
Client task
Start with the intended client and a defined result.
- 02
Approved Workspace
Use this client’s Context, accounts and resources.
- 03
Supported action
Work through the approved API, browser or file path.
- 04
Reviewable result
Inspect the output and involve a person where required.
- 05
Work history
Keep the work record with the intended Workspace.
Conceptual workflow. Supported actions depend on the configured service, runtime and approved resources.
Related: MCP for multi-client AI agents, what is a credential broker for AI agents, Outloop is not a vault, Outloop vs Zapier MCP, agent runtime access, and AI agent security. Outloop is available with setup guides and product support for agency teams; the Mac app is signed with a Developer ID and notarized by Apple, and two-Mac reproduction was first verified with release v1.1.6 on 24 July 2026 (a historical milestone, not a statement about the current release).
MCP connects the tool. A credential broker controls how it's used.
Outloop is available with setup guides and product support for AI agencies, operators, and dev shops.