MCP Authorization Is Not a Permission Review

OAuth can make a remote MCP connection legitimate and still leave the agent overpowered.

Short answer

MCP authorization answers one part of the review: how an MCP client gets and presents tokens to a remote MCP server. It does not prove the agent should get that server, that scope, that downstream identity, or that set of tools. Treat authorization as one input to a permission review. Before connecting an MCP server, write down the transport, credential source, protected resource metadata, requested scopes, token audience, downstream identity, enabled tools, approval gates, and log location. If the workflow only needs read access, write and delete tools should be off. If a tool can send, commit, deploy, delete, or change money, it should have an approval gate outside the model.

The trap

A lot of MCP review stops too early.

The server supports OAuth. The user sees a consent screen. The client gets a token. The call succeeds.

That is useful. It is not the same thing as approving the agent workflow.

Authorization tells you whether a request can be authenticated and authorized under a protocol flow. A permission review tells you whether the agent should have that tool in the first place.

Those are different questions.

If a coding agent gets an MCP server that can read issues, create branches, write files, open pull requests, and trigger deployments, the risk is not only whether OAuth works. The risk is whether the agent has too much functionality, too much downstream privilege, and too much autonomy for the task.

That is the same failure mode OWASP describes as LLM06: Excessive Agency: excessive functionality, excessive permissions, and excessive autonomy.

What MCP authorization actually covers

The current MCP authorization specification defines authorization for HTTP-based transports. It says authorization is optional for MCP implementations. It also says local STDIO servers should not follow the HTTP authorization flow and should retrieve credentials from the environment instead.

For remote HTTP servers, the spec maps MCP onto OAuth roles:

• A protected MCP server acts as an OAuth 2.1 resource server.
• An MCP client acts as an OAuth 2.1 client.
• MCP servers must implement OAuth 2.0 Protected Resource Metadata.
• MCP clients must use that metadata for authorization server discovery.

That is good plumbing. It gives clients a structured way to discover authorization details instead of guessing. It also gives servers a place to advertise the scopes needed for a protected resource.

But the protocol flow does not decide your workflow policy.

It does not know whether the agent's task needs write access. It does not know whether a generic service account is acceptable. It does not know whether a tool call should require approval because it sends an email, updates a record, deletes a file, or deploys code.

Those decisions belong in a separate permission record.

Two MCP-specific risks to check

The MCP security best practices call out two risks that belong in every review of a remote MCP server.

1. Confused deputy risk

The confused deputy problem appears when a component with legitimate authority can be tricked into using that authority for the wrong requester.

The MCP guidance describes conditions where this can happen around MCP proxies, static client IDs, dynamic client registration, consent cookies, and missing per-client consent.

The practical review question is simple:

Does the server maintain user consent per client, validate redirect URIs, protect state, and clearly show which MCP client is requesting access?

If the answer is unclear, do not treat the OAuth prompt as enough evidence.

2. Token passthrough risk

The same MCP guidance describes token passthrough as an anti-pattern. That is when an MCP server accepts tokens from a client without validating that they were properly issued to the MCP server, then passes those tokens to a downstream API.

This can break audit trails and bypass controls. Downstream systems may see a token but lose the context that an MCP server is forwarding the action.

The practical review question is:

Is the token audience bound to the MCP server, and does the downstream API see the right actor and context?

If the implementation just forwards broad tokens, the agent may be borrowing authority in a way no one can audit cleanly.

Local STDIO servers need a different review

Not every MCP server is remote HTTP.

Local STDIO servers are common in builder workflows. They often read credentials from environment variables, local config, shell state, or developer machines.

That means the review changes.

For STDIO, ask:

• What environment variables are visible to the server?
• Are production tokens loaded in the same shell?
• Can the tool read local files outside the intended project?
• Can it run shell commands?
• Can it write, delete, commit, push, deploy, or send data?
• Does it log tool calls in a place the user can inspect?

A local server does not get safer because it avoids remote OAuth. It just moves the sensitive boundary to the developer machine.

The permission record

Before enabling an MCP server, write this down in plain language:

MCP server:
Transport:
Credential source:
Protected resource metadata URL:
Authorization server:
Scopes requested:
Tools enabled:
Tools disabled:
Data it can read:
Actions it can take:
Downstream identity:
Approval required for:
Blocked by default:
Log location:
Review owner:
Next review date:

This record should fit on one page. If it cannot, the connection is probably too broad for its first approval.

The goal is not paperwork. The goal is to make the permission boundary visible before the agent starts using it.

Five questions before you connect an MCP server

1. Is this local STDIO or remote HTTP?

Remote HTTP and local STDIO have different risk surfaces.

Remote HTTP needs authorization metadata, token handling, consent, audience, scopes, and server identity review. STDIO needs local credential, shell, file, process, and machine boundary review.

Do not use one checklist for both.

2. What exact scopes are requested?

The MCP authorization spec says servers should include scope information to help clients avoid excessive permission requests.

Use that. Compare requested scopes to the workflow.

If the workflow needs to summarize issues, read access may be enough. If the server asks for write access, admin access, or broad repo access, the review should say why.

No reason means no approval.

3. Whose identity does the tool use downstream?

A tool that executes as the current user is different from a tool that executes as a shared service account with broad access.

OWASP calls out this pattern directly. Generic high-privileged identities increase blast radius.

For agent workflows, the safer default is user-scoped or workflow-scoped access with least privilege. If a shared privileged identity is unavoidable, the approval record should say why, what it can touch, and how it is logged.

4. Which tools are unnecessary?

Most risk comes from unused capability.

If an MCP server exposes read, write, delete, send, shell, and admin tools, but the workflow only needs read and summarize, disable the rest.

Do not make the model remember not to use dangerous tools. Remove them, block them, or put them behind an approval gate.

5. What actions require approval outside the model?

Some tool calls should not be autonomous by default.

Examples:

• Send an external message.
• Commit code.
• Open or merge a pull request.
• Trigger a deployment.
• Delete data.
• Update customer records.
• Change permissions.
• Spend money.
• Call an admin API.

The approval should sit in the workflow or downstream system, not in the model's private reasoning.

A small test that finds real issues

Pick one MCP server your agent can use today.

Now remove one broad permission.

If the workflow still works, the permission was unnecessary. Leave it off.

If the workflow breaks, ask whether the break is expected. A summarization workflow should not need delete access. A ticket triage workflow should not need admin access. A local file search tool should not need production API tokens in the shell.

This test is boring. That is why it works.

Evidence versus opinion

Evidence from the sources:

• The MCP authorization spec defines authorization for HTTP transports and treats authorization as optional.
• The spec requires protected resource metadata for remote authorization discovery.
• RFC 9728 defines the protected resource metadata format.
• MCP security guidance warns about confused deputy risk and token passthrough.
• OWASP LLM06 frames excessive functionality, permissions, and autonomy as core agentic AI risks.

My opinion:

A working OAuth flow should not be the final approval artifact for an MCP-connected agent. It should be one line in the approval packet. The more important artifact is the permission record: what the agent can read, what it can change, whose identity it uses, what defaults to blocked, and where a reviewer can see the evidence.

Free next step

Review one MCP server this week. Start with the permission record above, then compare it to the AI agent tool inventory, the agent action approval matrix, and the AI approval gate checklist. If a tool can change the outside world, do not let the model be the only reviewer.