A useful MCP integration lets an assistant find information and carry out bounded work across services. Its security depends on which user is acting, which resource they may access, and which operation is actually being requested. A tool schema describes an interface. It cannot, by itself, establish those permissions.
This article uses the July 28, 2026 MCP authorization specification, checked on October 16, 2026. The examples are design guidance. Our Unified MCP Platform case study provides the related integration context, rather than evidence that every control discussed here has been audited across every deployment.
Draw the authorization boundary before naming tools
Consider a support assistant that may read a customer's order and prepare a response. Reading an order, changing its delivery address, and issuing a refund are three different permissions. Create separate operations and map each to application policy. Avoid a generic administrative tool that accepts an arbitrary endpoint, method, and body.
Use a concrete access matrix during design: the authenticated user, their organization, the target record, the requested action, and any required approval. The organization should come from verified session context. Accepting it from model-generated arguments lets a plausible-looking request cross a tenant boundary. Query filters and downstream authorization must enforce the same ownership decision.
Discover the resource and verify its issuer
The current specification describes Protected Resource Metadata and authorization server discovery for protected HTTP servers. It also introduces issuer validation behavior and keeps Dynamic Client Registration as a deprecated compatibility option alongside Client ID Metadata Documents. Use a maintained SDK, but check which protocol revision its authorization implementation actually supports. MCP authorization requirements.
Keep the selected issuer associated with the authorization attempt. Reject a returned issuer that disagrees with the expected value, applying the specification's presence and validation rules. Treat the authorization callback as a separate security boundary from the tool endpoint. A working login page does not establish that the callback handles a substituted authorization server safely.
For broader OAuth defenses, follow RFC 9700: protect authorization flows against code interception, validate redirect destinations, and use the relevant protections for the client type. Let the identity implementation handle cryptographic validation. Application code should consume a verified principal rather than decode an unverified token and trust its fields.
Bind tokens to the intended resource
RFC 8707 defines resource indicators so an authorization request can identify its intended resource. In MCP, ask for a token for the MCP service being accessed, and verify that incoming tokens are intended for that service. A token accepted by an unrelated API should not become a universal credential.
When an MCP server calls another service, that second call needs its own appropriate authorization. The MCP security guidance explicitly rejects token passthrough and explains confused deputy risks. Keep upstream credentials outside model context, associate them with the correct user or service identity, and do not include them in tool responses or diagnostic messages.
Request narrow scopes and enforce record ownership
Begin with the minimum permissions needed for the current task. A read-only support view should not ask for refund privileges during initial connection merely because a future workflow might need them. Step up when the user reaches the more privileged operation. Give the consent screen language that describes the business effect, not just an opaque scope string.
The following pseudocode illustrates application authorization after token verification; it is not a JWT validator or a complete MCP handler:
principal = verify_access_token(request, expected_resource)
require_scope(principal, "orders:read")
order = load_order_in_org(args.order_id, principal.organization)
return redact_for_support(order)
The final lookup matters as much as the scope. Permission to read orders does not grant access to another organization's records.
Treat tool descriptions and retrieved content as untrusted input
The MCP tools specification describes tool discovery, schemas, execution, and security considerations. Tool annotations are useful hints for clients, but they do not replace server authorization. A tool marked read-only still needs a review of its actual implementation and dependencies.
Imagine a retrieved support note that instructs the assistant to export all customers before answering. The note is task data, not permission. Enforce write policies outside the model, limit result size, and keep tool outputs away from secret-bearing operational context. For a consequential action, bind confirmation to the specific record, operation, parameters, and expiry so a later argument change cannot reuse it.
Control discovery traffic and ambiguous outcomes
Metadata discovery and tools that fetch URLs can create unexpected network access. The official security guidance covers SSRF and local server compromise. For a public deployment, define permitted destinations and protocols, validate redirects and resolved addresses, and constrain outbound access. A user-supplied URL should not gain the server's unrestricted network position.
After a write times out, preserve its operation identifier and investigate the outcome before repeating it. A second tool call can create a second business action even when the assistant believes it is recovering from failure. Return states that distinguish completed, rejected, and outcome-unknown operations. This is an application workflow decision that the protocol cannot settle for you.
Test rejection paths as deliberately as success
A useful test suite attempts a correct scope with the wrong organization, a correct organization with the wrong scope, an expired token, a token for another resource, a changed redirect, and a replayed approval. Also test a document that requests an unrelated action and a tool response containing misleading instructions.
Record the authenticated actor, action, target, decision, and result with an appropriate retention policy. Avoid logging bearer tokens or indiscriminately copying private documents into traces. Investigators need enough evidence to explain a decision without turning the audit store into a second uncontrolled data source.
Takeaway
MCP makes integrations more consistent; trustworthy execution still requires identity, ownership checks, narrow scopes, and deliberate handling of writes. Start with a small authorized tool surface, verify the protocol revision, and make denial tests part of integration acceptance. Expand capability only when the permission boundary remains understandable.
