Authentication
Based on the current stable MCP specification
Security & authorisation
MCP security is the design of authority, not the addition of an OAuth screen.
MCP gives an AI host a standard way to discover context and invoke business capabilities. It does not decide which server should be trusted, which data should enter a model, whether a requested action matches the user’s intent or whether a downstream business object may be changed. Those decisions belong to the architecture around the protocol.
TechOne architecture position
The useful security boundary is not “the AI”. It is the exact principal, server, capability, data class and business consequence involved in each request. A production design must preserve that boundary from the host, through any gateway and MCP server, to the system of record.
Three different decisions
Authentication, authorisation and approval are not synonyms.
An identity can be valid, permitted to use a capability and still require a human decision for one exact change. Treating those checks as one boolean creates invisible authority.
Security decision boundaries
Authorization
Authorisation establishes what that principal may do.
Protocol factThe available tools and resources may vary according to the authorisation supplied on each request. MCP supports least-privilege scope challenges and step-up authorisation. An MCP server must not accept a token intended for another resource or pass its inbound token through to a downstream API.TechOne recommendationEnforce both capability-level and business-object authorisation. A tools/call permission is not evidence that the caller may update every invoice, case, patient record or production environment reachable through that tool.Approval
Approval establishes whether this action is intended now.
Protocol factThe tools specification recommends a human in the loop with the ability to deny invocations, clear visibility of tool inputs and confirmation for sensitive operations. The protocol does not prescribe one universal approval user experience.TechOne recommendationRequire approval according to consequence, not according to whether a tool is labelled read or write. Show the target, material parameters, data leaving the trust boundary and expected side effect. Bind an approval to the exact request so that later parameter changes require a new decision.Threat → control → evidence
Security claims should be inspectable.
The table separates protocol requirements and documented protocol threats from TechOne architecture recommendations.
| Risk | Control | Release evidence | Owner | Basis |
|---|---|---|---|---|
| Prompt injection through resources, tool results or tool metadata | Treat retrieved content, descriptions and results as untrusted input. Minimise the tools available in the same context, separate sensitive reads from consequential writes, validate outputs and require explicit approval for material actions. | The MCP specification treats tool annotations as untrusted unless they come from a trusted server. Official OpenAI and Microsoft guidance identifies prompt injection through connected content, tool descriptions and tool outputs as a production risk. | AI application owner with security engineering | Protocol fact and TechOne recommendation |
| Tool poisoning or a post-approval schema change | Record a known-good tool definition, publisher, endpoint and version. Diff names, descriptions, input schemas, output schemas and annotations before release; require re-approval for material changes. | Microsoft advises treating tool schema changes as dependency changes and pinning known-good schemas. OpenAI notes that an MCP server may change tool behaviour unexpectedly. | MCP platform owner | TechOne recommendation supported by official guidance |
| Name collision or tool shadowing across servers | Use an immutable internal server identifier and a namespaced capability identifier in policy, telemetry and approval records. Never authorise solely by the display name supplied to the model. | MCP 2026-07-28 scopes tool-name uniqueness to one server, warns aggregators about collisions and states that serverInfo.name is not guaranteed to be unique. | Host and gateway engineering | Protocol fact and TechOne recommendation |
| Confused deputy and excess server privilege | Separate the server’s execution identity from caller authorisation. Check the caller on every operation and issue a separate, correctly scoped downstream credential when the server calls another protected API. | The MCP authorisation security specification describes the confused-deputy problem and requires per-client consent in affected proxy flows. It explicitly prohibits token passthrough. | Identity architect and service owner | Protocol fact and TechOne recommendation |
| Token theft, replay or cross-resource token use | Validate issuer, audience, expiry and scopes; use PKCE for authorisation-code flows; protect tokens in storage and logs; rotate refresh tokens for public clients and prefer short-lived access tokens. | These controls are normative requirements or recommendations in the MCP 2026-07-28 authorisation and security specifications. | Identity platform owner | Protocol fact |
| SSRF during OAuth discovery, CIMD retrieval or URL handling | Require HTTPS in production, validate each redirect, block private, loopback and link-local destinations where they are not explicitly required, apply egress policy and avoid home-grown IP parsing. | The official MCP security guidance documents SSRF paths through resource metadata, authorisation-server metadata and Client ID Metadata Documents, including redirects and DNS rebinding. | Network and identity security | Protocol guidance and TechOne recommendation |
| DNS rebinding against a local HTTP MCP server | Validate Origin on Streamable HTTP, bind local servers to loopback and require authentication. Prefer stdio or access-controlled IPC where a local HTTP listener is unnecessary. | The Streamable HTTP specification requires Origin validation and recommends loopback binding and authentication for local deployments. | MCP server owner | Protocol fact and TechOne recommendation |
| State-handle hijacking | Use opaque, high-entropy, expiring handles and bind each handle server-side to the verified principal and tenant. Possession of a handle must not count as authentication. | MCP 2026-07-28 removed protocol sessions and documents explicit application-state handles. Official guidance advises checking the caller’s authorisation on every use and recommends principal binding and non-deterministic handles. | MCP server owner | Protocol guidance |
| Local stdio process compromise | Allow only reviewed launch commands, pass a minimal environment, sandbox filesystem and network access, and run with the least operating-system privilege required. | Official MCP security guidance treats local servers as executable code with the privileges of the client and recommends explicit consent, sandboxing and restricted resources. | Endpoint security and developer platform | TechOne recommendation supported by official guidance |
| Private data served from a shared cache | Use cacheScope private whenever a result depends on identity, scopes or tenant, and partition private caches by a stable authorisation context. Continue to enforce access control on the underlying primitive. | The MCP caching specification prohibits sharing private results across authorisation contexts and states that cacheScope is not an access-control mechanism. | Client, gateway and cache owner | Protocol fact and TechOne recommendation |
| Header and body disagreement at an intermediary | Reject requests when the required MCP-Protocol-Version and Mcp-Method headers, any applicable Mcp-Name header, or recognised Mcp-Param values are missing, malformed or do not match the JSON-RPC body. | Streamable HTTP 2026-07-28 mandates header/body validation and defines HeaderMismatch error -32020. | Gateway and MCP server owner | Protocol fact |
Control point, not a safety proof
A gateway is a control point, not a complete safety system.
The 2026-07-28 transport makes MCP easier to govern with ordinary HTTP infrastructure. That is valuable, but the gateway sees only part of the decision.
Useful central controls
- Validate caller identity, token audience and transport requirements.
- Allow or deny endpoints, protocol versions, methods and named capabilities.
- Apply rate, concurrency, network, regional and cost policies.
- Route on Mcp-Method and Mcp-Name without parsing the JSON body, while requiring the server to validate the mirrored values.
- Attach correlation identifiers and produce consistent access and policy logs.
- Protect downstream services with timeouts, quotas and circuit-breaking policy.
Remaining trust questions
- Prove that retrieved content contains no prompt injection.
- Decide whether a user genuinely intended a specific business consequence.
- Replace object-level authorisation inside the system of record.
- Make an unsafe or misleading tool description trustworthy.
- Provide business idempotency for a payment, order or deployment.
- Turn a self-reported registry entry into verified software provenance.
Illustrative evidence record
Record the decision chain, not merely the HTTP request.
MCP reserves W3C trace context keys for distributed tracing. A defensible audit record must add the identity, policy, approval and business context needed to reconstruct why an action was allowed.
- trace_id and request_id
- Correlate host, gateway, MCP server and downstream spans. Protocol-supported and TechOne recommendation
- principal, workload and tenant
- Identify the verified human and non-human actors without trusting tool arguments. TechOne recommendation
- server ID, endpoint and deployed version
- Distinguish the actual implementation from its display name. TechOne recommendation
- tool name and schema fingerprint
- Show which reviewed capability contract was invoked. TechOne recommendation
- scopes and policy decision
- Explain the authorisation basis and the rule that allowed or denied the call. TechOne recommendation
- approval decision and bound request digest
- Show exactly what a person approved and prevent approval reuse after parameter changes. TechOne recommendation
- target class and redacted argument digest
- Support investigation without copying secrets or regulated payloads into general logs. TechOne recommendation
- outcome, error class and latency
- Connect security evidence with operational reliability. TechOne recommendation
TechOne security position
Design for refusal, revocation and investigation.
- 01
Authorise a capability, then authorise the object.
Permission to call update_invoice is not permission to update every invoice reachable by the server.
TechOne recommendation - 02
Trust is contextual, not inherited.
A trusted publisher does not make all content returned through that server trustworthy, and a trusted read tool can still expose sensitive data.
TechOne recommendation - 03
Use separate credentials at separate resource boundaries.
Audience-bound MCP access and downstream API access are distinct security decisions.
Protocol fact - 04
Make consequential authority scarce.
Expose the smallest set of write operations, parameters, records and environments required for the workflow.
TechOne recommendation - 05
Treat metadata as code-adjacent supply chain.
Names, descriptions, schemas and annotations influence model behaviour and require review and change control.
TechOne recommendation - 06
Fail closed at ambiguous boundaries.
Unknown issuer, audience, endpoint, schema version, tenant or approval state should stop the action rather than trigger a permissive fallback.
TechOne recommendation
Primary sources
Checked against the stated protocol baseline.
Official sources establish the protocol baseline and identify any draft extension. Unless a statement is labelled as a protocol fact, the surrounding control pattern is a TechOne architecture recommendation.
- MCP 2026-07-28 specificationNormative protocol baseline
- ArchitectureHost, client and server responsibilities
- 2026-07-28 changelogTrace context, lifecycle and protocol changes
- Streamable HTTPTransport, Origin and header validation
- AuthorisationOAuth discovery, scopes and token use
- Authorisation security considerationsAudience binding, token passthrough, SSRF and confused deputy
- Security best practicesImplementation threats and mitigations
- ToolsTool control, schemas, collisions and safety
- CachingCache scope and authorisation boundaries
- Introducing the MCP RegistryRegistry purpose and publisher-maintained metadata
- MCP servers: risks and safetyPrompt injection, approvals and third-party servers
- Secure Azure MCP Server deploymentTool poisoning, gateway and operational controls
Direct answers
Questions that expose the hidden architecture decision.
Does MCP require OAuth for every server?
No. Authorisation is optional in the core protocol. When a protected server uses an HTTP transport, MCP 2026-07-28 defines an OAuth-based authorisation model. Local stdio deployments use a different process and credential boundary.
Is OAuth enough to secure an MCP deployment?
No. OAuth establishes and scopes access to the MCP resource. The server must still enforce business-object permissions, validate inputs, constrain downstream authority, protect outputs and apply approval policy to consequential operations.
Can an MCP gateway stop prompt injection?
Not by itself. A gateway can constrain traffic, identity, methods and destinations. Prompt injection can arrive inside content already permitted by those controls, so the host and application need context isolation, tool filtering, validation and consequence-aware approval.
Is a read-only MCP server safe?
Read-only reduces direct mutation risk, but it can still expose sensitive data, carry malicious instructions or provide information that another tool later exfiltrates. Read authority must still be scoped and audited.
May an MCP server pass the caller’s token to its backend API?
No. MCP explicitly forbids token passthrough. The inbound token must be intended for the MCP server; access to an upstream API requires a separate token issued for that upstream resource.
Does the official MCP Registry prove that a server is safe?
No. The registry standardises discovery and publishing metadata. Its information is maintained by server publishers, so an enterprise still needs publisher verification, allowlisting, review, version control and runtime policy.
What changed for security in MCP 2026-07-28?
The revision made requests self-contained, removed protocol sessions, added routable method and name headers, tightened issuer and audience handling, and deprecated Dynamic Client Registration in favour of Client ID Metadata Documents. It also added explicit guidance for application state handles. Existing deployments still need compatibility testing with older clients and servers.