Remote MCP servers should use proper authorization. No argument there.

But authorization is only the front door. Once an agent is inside, you still need to decide what it can actually do. That is where a lot of MCP security discussions get too neat too quickly.

A valid token can tell an MCP server, "this caller may connect." It does not answer the more uncomfortable production question: should this identity, through this agent, call this tool against this target right now?

What MCP authorization gives you

The MCP authorization specification builds on OAuth patterns for protected resources and authorization-server discovery. For remote servers, that matters. An MCP server should not become a public tool proxy just because an agent knows how to speak MCP.

In a serious deployment, teams should be able to point to a few basic things: where the authorization metadata lives, which authorization server issues tokens, what audience or resource the token is meant for, and how clients are stopped from replaying a token against the wrong server.

Useful references are the official MCP authorization specification and the official MCP security best-practices guide.

What it does not decide

The mistake is treating server access as tool permission.

A valid access token can prove that a caller may reach an MCP server. It does not prove that every tool exposed by that server is safe for every prompt, credential, target system, or runtime state.

Tool policy has to ask a different set of questions:

  • Who started this call: a user, workload, agent, or session?
  • Which MCP server and package version will execute it?
  • Is that server still allowed, given its dependency and configuration state?
  • Is the tool read-only, write-capable, or execution-capable?
  • What credential class will it use?
  • Which repository, ticket, database, or filesystem path is in scope?
  • Can we prove later why the call was allowed or denied?

OAuth belongs at the transport boundary. Tool policy belongs at the action boundary.

The confused deputy case

MCP makes confused-deputy failures easier to miss because the call chain has several actors: a user, a host application, an agent, an MCP client, an MCP server, and the downstream system the tool reaches.

Each actor can be "authorized" in a narrow sense and still produce the wrong outcome.

A user may be allowed to use an agent. The agent may be allowed to reach an MCP server. The server may hold a credential for a downstream SaaS product. None of those facts proves that this particular tool call should modify a production record, read a private repository, or send data somewhere new.

This is why the OWASP MCP Security Cheat Sheet frames MCP security across clients, servers, and the connections between them, not only as a server-login problem.

Tool policy should sit before execution

The policy decision has to happen before the MCP server performs the action. Afterward, you are reviewing damage or explaining luck.

A useful pre-call gate looks at identity, server state, tool name, requested action, target resource, credential class, and environment. It does not need to be theatrical. It needs to be specific.

For example:

  • A documentation-search tool may be allowed for every agent session.
  • A repository-write tool may require a human-approved session and a specific repository.
  • A filesystem tool may be limited to a project directory, even if the server process can see more.
  • A browser or shell tool may be blocked unless the server runs in an isolated profile.
  • A server with critical reachable dependency risk may be denied until patched or excepted.

The important part is simple: the policy has to understand the MCP action, not just the HTTP request wrapped around it.

Receipts close the evidence gap

Authorization decisions should be reviewable after the run. This is where plain logs start to feel thin.

Logs can show that a request happened. Receipts should show which policy allowed or denied the exact tool call and what context the decision used.

A useful MCP receipt binds:

  • User or workload identity.
  • Agent or session identity.
  • MCP server identity and version.
  • Dependency or server-state signal used by policy.
  • Tool name and action class.
  • Target resource class.
  • Credential class.
  • Policy rule and allow/deny result.
  • Timestamp and result category.

This matters for security review, incident response, vendor-risk review, and audit files. It also makes exceptions less sketchy. An exception should not live as a private chat message or a dashboard toggle with no durable context.

A practical production baseline

For remote or shared MCP deployments, use both layers.

Keep standards-based authorization for access to the MCP server. Then add tool policy for the actual action the agent is trying to take.

  • Use standards-based authorization for remote MCP server access.
  • Validate token audience, issuer, expiry, and resource binding.
  • Inventory every tool exposed by each server.
  • Classify tools by read, write, execution, credential, and data-exfiltration risk.
  • Evaluate tool calls against identity, server state, target scope, and environment.
  • Record tamper-evident receipts for sensitive allow and deny decisions.

The shortest version is this: MCP authorization gets the caller to the building. Tool policy decides which rooms can be entered, under what conditions, and with what evidence left behind.