Connecting an MCP server can make a collection of tools visible to an agent. It does not mean the agent may perform every exposed operation on every resource. Discovery, authentication, authorization, and user approval solve different problems.
The MCP authorization specification dated 2025-11-25 describes authorization for HTTP-based transports. Authorization is optional at the protocol level; supported HTTP implementations should follow the specified flow. The same document says STDIO implementations should retrieve credentials from the environment rather than follow that HTTP authorization flow. Do not describe all MCP connections as having identical OAuth behavior.
Trace the chain of authority
A user authorizes an application, the application obtains a credential for a resource, and a server evaluates a requested operation. A successful login tells the server something about identity and credential validity. The requested account, record, action, and scope still need a permission check.
In a synthetic customer-support workflow, an agent may retrieve the user's own order and draft a reply. Cancellation of another customer's order must remain unavailable even if the same server implements a cancellation tool. The tool description is not the policy engine.
Validate audience and scope
The specification requires servers to validate that access tokens were issued for their intended resource. Clients should not send unrelated tokens, and servers must not accept or transit tokens intended for another audience. A token that works against one downstream API is not automatically valid for an MCP proxy.
Keep resource and operation checks server-side. Scopes can be necessary without being sufficient: a broad read scope may still need account-level filtering. Record the user, authorized resource, requested action, and decision without storing raw credentials in the trace.
A proxy is a new trust boundary
The security guidance describes token passthrough and confused-deputy risks. A proxy that accepts an inappropriate credential and forwards it can bypass intended controls or misrepresent which party authorized the action.
Review redirects, discovery endpoints, and outbound destinations as well. Following an untrusted URL can expose internal services or metadata endpoints. Validate destinations under a deliberate network policy; string checks alone are vulnerable to redirects and changing resolution.
Approval must identify the actual action
“Allow the agent to use this server” is different from “approve cancelling order 481 for this customer.” For consequential effects, show the operation, target, meaningful parameters, and consequence. Bind approval to that request so an approved draft cannot silently become a different write.
If the action changes after approval, obtain the appropriate new approval or reject it. If the tool times out after accepting the operation, check its status before retrying. The protocol connection does not provide exactly-once business effects.
Test the implementation, not only conformance
Include an expired token, wrong audience, insufficient scope, wrong-account access, a redirect to an internal endpoint, and a revoked permission between discovery and execution. Also test the normal allowed path and useful error recovery.
Record which protocol version and transport were used. A compliant client and server still need correct deployment configuration, access policy, logging, and incident response. Specifications establish contracts; they do not certify the application around them.
Keep the tool catalogue small
Expose only tools and scopes that serve the current workflow. Clear descriptions improve selection, but fewer unnecessary capabilities also reduce the effects available after a mistake. Evaluate whether the agent can complete the task with that limited catalogue before expanding it.
MCP is valuable interoperability infrastructure. Its value grows when the surrounding product keeps authority explicit rather than assuming that connection implies consent.