01 / Field notes
Executive Summary
Connecting an assistant to an MCP server creates a new application trust relationship. It does not make every tool call authorized, and it does not turn one access token into a universal credential. A secure design must identify the client, the resource server, the authorization server and any downstream service separately.
This guide is tied to MCP's 28 July 2026 specification. Its authorization flow addresses HTTP transports; stdio has a different credential model. Authorization support is optional in the protocol, but an application exposing sensitive operations still needs an appropriate access-control design. [1]
The practical goal is a reviewable boundary: the right identity can call the intended tool against the intended resource, while unrelated tokens, clients and destinations are refused.
02 / Field notes
Prerequisites / Lab Setup
Draw a diagram of the actual integration before choosing libraries. Include browser or native client, MCP endpoint, authorization service, metadata discovery and downstream APIs. Mark which component stores credentials and which one decides whether a particular user may perform an action.
Use isolated test registrations, fake business records and the provider's supported test environment. Never paste bearer tokens into an assistant conversation, issue tracker or public decoder. Capture redacted claims and validation outcomes. Pin the protocol version in the review record so future changes do not silently invalidate assumptions.
03 / Field notes
Technical Analysis
A token is intended for a resource
The MCP security guidance forbids token passthrough and explains risks from accepting credentials without the intended boundary checks. [2] A server should not treat a token issued for some other API as proof of permission to use its own tools, nor simply forward a received token downstream because doing so appears convenient.
In a fictional expense assistant, the MCP server can read approved expense records. A separate accounting API may require its own authorization. The server needs a deliberate downstream grant and application-level permission decision. The fact that the user authenticated to the assistant does not authorize every accounting operation available to the server.
| Boundary | Review question | Controlled negative case |
|---|---|---|
| Token recipient | Was this credential issued for the intended resource? | Credential for another resource is rejected |
| Issuer | Is the issuing authority trusted for this integration? | Unapproved issuer is rejected |
| Tool permission | Is this user allowed to perform this action? | Read-only user cannot submit an expense |
| Downstream service | Is there a separate appropriate grant? | Incoming credentials are not blindly forwarded |
| State binding | Does continuation state remain tied to the right authorization context? | Another session cannot reuse the state handle |
Discovery creates network decisions
Metadata and authorization discovery can cause software to fetch URLs. MCP's security guidance includes SSRF and authorization-URL validation considerations. [2] Treat those fetches as security-sensitive operations, not harmless string parsing. A URL derived from an untrusted source must not gain unrestricted access to internal services.
Review schemes, host validation, redirects, DNS resolution, response limits and timeouts according to the integration's threat model. If a server must contact known providers, an explicit allowlist is easier to reason about than arbitrary outbound access. Test with a controlled local mock; do not probe real private infrastructure to demonstrate the risk.
The assistant's model should not decide whether a destination is safe. Enforce network and credential policy in deterministic application code. A natural-language explanation from a tool description cannot grant an exception to those controls.
Keep tool authorization narrower than authentication
After token validation, authorize the requested operation and its specific object. “Can use the expense tool” is too broad if the caller may read only one department's records. Check tenant, ownership and action parameters at the resource boundary. Reject unknown or malformed inputs before invoking downstream services.
For actions that alter business state, display a concrete preview when approval is required: target, operation and material effect. Bind that approval to the actual execution parameters. If the parameters change after approval, require a new decision. The agent action-control guide develops this application-level pattern; it is not automatically supplied by MCP authentication.
Version the security review
The July 2026 document references OAuth 2.1 as an IETF draft alongside other specifications. [1] Avoid presenting that reference as evidence that every related standard is final or every library implements the same subset. Record the MCP version, library version, provider behavior and tested flow together.
Future protocol changes should trigger a targeted review of the boundaries that changed. A permanent “MCP compliant” badge is less useful than an integration record explaining what was checked and when.
04 / Field notes
Mitigation / Defense
- Distinguish HTTP and stdio deployments before applying authorization guidance.
- Validate credentials for the intended issuer and resource, then authorize the specific tool action.
- Use separate appropriate downstream grants and prevent token passthrough.
- Constrain metadata fetches and bind continuation state to the correct authorization context.
- Retest wrong-audience, wrong-tenant, revoked-access and changed-parameter cases after upgrades.
Start with a read-only integration and a narrowly scoped account. Add write capabilities only when their authorization, preview, audit and recovery paths are defined. Review existing grants with the OAuth consent checklist rather than treating a successful connection as the end of the security work.
05 / Field notes
References
Sources checked 28 October 2026; specification version 2026-07-28. The expense workflow and test matrix are original illustrative designs. This guide is not a complete protocol implementation or a claim that a library has passed conformance testing. Consult the referenced specification for normative requirements.
- MCP authorization specification, 2026-07-28 ↗Model Context Protocol · accessed 2026-10-28
- MCP security best practices, 2026-07-28 ↗Model Context Protocol · accessed 2026-10-28
Questions readers ask
Does the MCP HTTP authorization flow apply to stdio servers?
The 2026-07-28 specification distinguishes them: HTTP implementations supporting authorization should follow that flow; stdio implementations should obtain credentials from their environment instead.
Can an MCP server forward the incoming token to any API?
No. MCP security guidance explicitly forbids token passthrough. Use the appropriate separately authorized downstream flow and validate intended token recipients.
About this edition: Articles include AI-assisted drafting and editing. Conceptual illustrations are not evidence of a real incident or product test. Read our sourcing and review standards.
Research improves with scrutiny. Send a correction with the article URL and supporting evidence.
Contact the editorial desk ↗
