Remote MCP access fails in the gap between OAuth consent and agent permission.
Short answer: Before an agent connects to a remote MCP server, write a consent record. It should bind the MCP client, MCP server, authorization server,
resourcevalue, scopes, redirect URI, requested tool groups, downstream identity, approval owner, expiry, revocation path, and logs. OAuth can prove a token flow. It does not prove the agent should get every tool the token can reach.
Remote MCP servers make agent tooling easier to distribute.
They also make the trust boundary easier to blur.
A user sees an OAuth screen. A client gets a token. The MCP server exposes tools. The agent sees tool names and descriptions. Somewhere in that chain, a builder has to answer a plain question:
What exactly did we approve?
If the answer is only "the OAuth flow completed," the system is under-specified.
OAuth consent is not the same as agent consent
OAuth is the right machinery for many remote MCP connections. It helps clients discover how to request tokens, bind tokens to resources, and avoid sending credentials to the wrong place.
That is necessary.
It is not enough.
An agent does not only need a token. It needs a bounded reason to use the token. It needs a tool list. It needs a data boundary. It needs an approval boundary for writes, external communication, purchases, deletes, account changes, and anything else that can cause harm.
The MCP authorization layer and the agent permission layer overlap, but they are not the same control.
A consent record is the bridge between them.
What the public specs say
The MCP authorization specification treats an HTTP-based MCP server as an OAuth resource server when authorization is supported. It says MCP servers must implement OAuth 2.0 Protected Resource Metadata, and MCP clients must use that metadata for authorization server discovery. It also requires clients to use Resource Indicators for OAuth 2.0 and include the resource parameter in authorization and token requests.
That matters because the resource value tells the authorization server which protected resource the token is meant for.
RFC 8707 gives the general OAuth pattern: a client can explicitly signal the protected resource it wants to access, and the authorization server can use that information to restrict the intended audience of the token.
RFC 9728 gives the protected resource metadata pattern: a protected resource can publish metadata about how clients should interact with it, including authorization server relationships and supported scopes.
The MCP docs also call out practical failure modes.
The MCP Security Best Practices page describes a confused deputy pattern around MCP proxy servers. The risky shape is familiar: one proxy, many clients, a third-party authorization server, consent state that may already exist, and not enough per-client consent at the MCP layer. The mitigation is explicit. The MCP proxy should maintain a registry of approved client_id values per user and show an MCP-level consent page that identifies the requesting MCP client, requested third-party API scopes, registered redirect URI, and CSRF protection.
The same page warns against token passthrough, where an MCP server accepts a token from a client without validating that the token was issued to that MCP server, then passes the token downstream. That can bypass security controls, weaken audit trails, and make it unclear who did what.
OWASP LLM06: Excessive Agency gives the agentic risk frame. Harm shows up when a model-driven system has too much functionality, too many permissions, or too much autonomy. OAuth scopes can limit part of that. They do not replace workflow-level approval.
Evidence versus opinion
The evidence says MCP remote authorization depends on protected resource metadata, resource indicators, audience boundaries, per-client consent for proxy cases, and strict token handling. The MCP security guidance also names confused deputy and token passthrough as concrete risks.
Keep reading with free field-guide resources.
VibeSec Advisory publishes practical research, Skills, workflow examples, MCP notes, prompt injection tests, and AI red-team lessons for builders working with agentic AI.
My opinion: every remote MCP approval should produce a small consent record before the agent gets usable tools.
Not a legal record. Not a giant governance artifact. A security and operations record that a builder, reviewer, or red teamer can inspect later.
If the connection cannot explain who approved what, for which client, for which server, with which token audience, using which tools, under which expiry, it is not ready for agent access.
The MCP consent record
A useful record can be small.
| Field | What to capture | Why it matters |
|---|---|---|
| MCP client | Client name, version, client_id, owner | Stops generic consent from covering unknown clients |
| MCP server | Server URL, publisher, environment, trust level | Keeps approval tied to a specific remote server |
| Protected resource metadata | Metadata URL, authorization server, supported scopes | Records what the server claims about its auth boundary |
| Resource value | Exact resource parameter used in auth and token requests | Helps detect audience drift and confused deputy paths |
| Redirect URI | Registered redirect URI that receives tokens | Makes token destination review explicit |
| Scopes | Requested scopes and the reason for each | Separates needed access from convenient access |
| Tool groups | Tools exposed after connection, grouped by read, write, external, destructive | Connects token scope to agent capability |
| Downstream identity | User context, service account, delegated identity, or proxy identity | Prevents borrowed or ambiguous identity |
| Data classes | Public, internal, confidential, regulated, secret, or unknown | Makes data exposure review visible |
| Approval gates | Actions that require human review before execution | Keeps OAuth consent from becoming action approval |
| Token handling | Audience checks, passthrough status, storage, rotation, revocation | Catches dangerous token shortcuts |
| Expiry | Date or condition when the approval must be reviewed | Limits stale access |
| Logs | Client, user, server, tool, action, decision, token audience, trace ID | Makes review and incident response possible |
The field most teams skip is tool groups.
That is where OAuth and agent security meet.
A token might grant a broad API scope. The agent should still get a narrower tool surface. A remote MCP server might advertise both read and write tools. The approval should say which groups are available now, which require a human gate, and which are blocked.
Failure modes this catches
A consent record is useful because it catches boring mistakes before they become incident reports.
- Wrong audience: The token was requested for one resource but accepted somewhere else.
- Generic client consent: A user approved a proxy once, then another MCP client reused the same path without a fresh MCP-level decision.
- Token passthrough: The MCP server forwards a token downstream without proving the token was meant for that server.
- Scope inflation: The OAuth scope allows more than the workflow needs.
- Tool inflation: The remote server exposes write or destructive tools that were never reviewed.
- Identity blur: Logs cannot separate the human, the MCP client, the MCP server, and the downstream system.
- Consent drift: A server changes tools, metadata, scopes, or redirect behavior after initial approval.
None of these require a dramatic exploit.
They only require a remote agent integration to treat "connected" as the same thing as "approved."
Red-team checks for remote MCP authorization
If you are reviewing a remote MCP server, do not stop after the happy-path OAuth flow.
Test the boundary.
- Confirm the MCP client requests tokens with the expected
resourcevalue. - Confirm the token is rejected when presented to the wrong MCP server.
- Confirm the protected resource metadata points to the expected authorization server.
- Confirm the redirect URI is exact and registered.
- Confirm consent is per MCP client, not just per user and proxy.
- Confirm a new MCP client cannot inherit a prior client's approval.
- Confirm read-only workflows do not receive write-capable tools.
- Confirm high-impact tools require a separate approval gate after OAuth.
- Confirm logs show user, client, server, tool, action, decision, and token audience.
- Confirm revocation removes token use and tool access.
The goal is not to prove OAuth is bad.
The goal is to prove the agent cannot turn a valid token into broader authority than the workflow intended.
What not to trust
Do not trust a consent screen by itself.
It may show API scopes, but it usually does not show the full agent tool surface, downstream approval rules, log fields, or future server changes.
Do not trust tool descriptions as permission controls.
Descriptions help the model choose. They do not enforce boundaries.
Do not trust broad scopes because a workflow is "mostly read-only."
If the token or tool surface can write, delete, send, purchase, modify permissions, or expose private data, treat that as a separate approval problem.
Do not trust token passthrough.
If the MCP server cannot validate token audience and cannot explain why it is allowed to forward or exchange tokens, the audit trail is already weak.
The practical control
Before approving remote MCP access, require this minimum record:
- The MCP client identity.
- The MCP server URL and protected resource metadata.
- The authorization server and exact
resourcevalue. - Requested scopes and why each is needed.
- Tool groups exposed after connection.
- Human approval gates for write, external, destructive, or high-impact tools.
- Token audience validation and passthrough status.
- Expiry, revocation, and logging requirements.
Then rerun the review when the server adds tools, changes metadata, changes scopes, changes redirect behavior, or moves from a test workflow to a real one.
This pairs with earlier VibeSec Advisory field notes: MCP Authorization Is Not a Permission Review, MCP Tool Annotations Are Hints, Not Approval Gates, and Stop Rules Before AI Agents Run.
Remote MCP access should not be approved by vibes.
Write the consent record before the agent gets the token.
Free next step
Review an MCP. Pick one remote MCP server and write the consent record before approving the connection.
Browse the VibeSec Advisory Skill Library for more free agentic AI security patterns.