Securing the Model Context Protocol as an enterprise control plane

01 The two MCPs, and why they are the same problem

The acronym collision is not a nuisance to be disambiguated in a footnote. It is the argument.

Deploy the first at enterprise scale and you have built the second. An MCP estate connected to a ticketing system, a cloud account, a source repository, a database and a deployment pipeline can open accounts, read secrets, change configuration, move money and ship code. That is the definition of a control plane, and it inherits the control plane's governing property:

What MCP adds to that inheritance is a caller that cannot be reasoned about deterministically. Traditional control-plane security assumes an authenticated human operator or a program whose behaviour is fixed at build time. Here the caller is a language model that composes its next action from whatever text has entered its context — including text supplied by an attacker through a support ticket, a web page or a tool description. The perimeter assumption that the client is on your side does not survive that.

02 Reference architecture

Vendor-neutral, expressed as planes and boundaries rather than products. The rule that matters is that no tier inherently holds the authority of another.

03 Trust boundaries and what crosses them

A boundary you have not written down is a boundary you are not defending. For each, the question is what crosses, what could be forged, and what the blast radius is if it is.

Three boundaries the four-way model does not number

The numbered boundaries are the ones a request crosses. These three are real boundaries that a request does not cross, which is exactly why they get forgotten.

04 Threat taxonomy

Three tiers, because they need three different kinds of answer. Tier 1 is inherent to the protocol and its ecosystem. Tier 2 arises from putting a language model in the decision path. Tier 3 is ordinary control-plane security that people skip because the deployment feels experimental.

05 The untrusted caller

Indirect prompt injection is the threat that makes MCP security different from API security. It deserves to be modelled as a path, with named gates, so that the honest question can be asked at each: is this a control, or is it a hope?

What follows from taking that seriously

• Read scope and write scope belong to different tokens. If one exchanged credential can both read the ticket and post the webhook, the injection has everything it needs. Split them and the chain requires two independent authorizations.
• Mutating tools should be structurally constrained, not free-form. A tool that accepts a SQL string accepts an instruction; a tool that accepts a table name, a bounded filter and a row limit accepts a request. Schema design is a security control and it is usually the cheapest one available.
• Approval must bind to the exact payload. An operator who approved a diff should not have approved whatever executes next. Bind consent cryptographically to a hash of the concrete request, with a short freshness window, so approval cannot be transplanted.
• Cross-server chains are the unit of analysis. Threat-model the pairs, not the servers. “Read from the ticketing server, write to the repository server” is the risk; neither server can see it alone.
• Human-in-the-loop is a control only where a human can actually adjudicate. The specification says there should always be a human able to deny tool invocations. That is right, and it is also the control most eroded by volume — which is why tiering it matters more than mandating it.

06 What the specification now requires

MCP historically prescribed no authentication and no authorization model, which is why so much published guidance treats identity as entirely the implementer's problem. That is out of date. Revision 2026-07-28 carries a normative authorization specification, and several of its requirements are the exact controls this architecture argues for.

07 Delegated identity without passthrough

The single highest-value control in the architecture, because it bounds a class of compromise: a server that is fully compromised holds a credential no other MCP server will accept, so its blast radius collapses to its own downstream scope rather than the user's whole session.

Delegation, not impersonation

RFC 8693 distinguishes the two precisely, and the distinction is the whole audit story. Under impersonation the acting party becomes indistinguishable from the subject; under delegation it keeps its own identity and the token carries both. The act claim is what expresses delegation. Be careful how far you push that, though: the RFC leaves the token representation of impersonation to the authorization server's discretion and policy, so the absence of act is a strong convention rather than a test a verifier is entitled to rely on. If the distinction matters to a downstream control, require the claim explicitly rather than inferring it from a gap.

“The act (actor) claim provides a means within a JWT to express that delegation has occurred and identify the acting party to whom authority has been delegated.”

“For the purpose of applying access control policy, the consumer of a token MUST only consider the token's top-level claims and the party identified as the current actor by the act claim.”

RFC 8693, OAuth 2.0 Token Exchange, §4.1 — Proposed Standard, January 2020

POST /oauth/token HTTP/1.1
Host: sts.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <host client credentials>

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&subject_token=<the user's token — consumed here, never forwarded>
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token
&resource=https%3A%2F%2Fmcp.example.com%2Fissue-service
&scope=mcp%3Atools%3Aexecute+issues%3Aread
&requested_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token

Verification at the resource server

Signature validity is not authorization. The Storm-0558 investigation turned on precisely this: libraries verified signatures cryptographically but did not automatically perform issuer and key-scope validation, and callers assumed they had. A conforming validator checks all of it — issuer, audience, scope, lifetime, key scope and the presence of the expected delegation claim — and returns 401 for an invalid or expired token, 403 for insufficient scope with a WWW-Authenticate challenge naming the scopes actually required.

08 The deterministic policy gate

Between a model that decided to do something and a system that would do it, there should be a component whose behaviour does not depend on what the model was told. This is the gate that holds when everything upstream has been fooled.

The rule shape

Default deny, an allow that requires both an empty violation set and an affirmative authorization rule, and violations aggregated from independent families so that adding a new class of check cannot accidentally weaken an existing one. Expressed in Rego:

package mcp.tools.authz

# On OPA 1.0 and later, Rego v1 semantics are the default and
# `import rego.v1` is a no-op. It is retained only by libraries
# that must also parse under pre-1.0 runtimes.

default allow := false

allow if {
    count(violations) == 0
    is_action_authorized
}

violations contains r if { some r in structural_violations }
violations contains r if { some r in destructive_violations }
violations contains r if { some r in classification_violations }
violations contains r if { some r in approval_violations }
violations contains r if { some r in environment_violations }

# Every family needs at least one rule head, or the module does not
# compile — an undefined family is an unsafe variable, not an empty
# set. One placeholder each; replace the bodies with the real checks.

structural_violations contains "Operation was not parsed into a typed structure." if {
    not input.operation.parsed
}

destructive_violations contains "Mutation submitted without a bounded predicate." if {
    input.operation.kind == "mutate"
    not input.operation.predicate
}

classification_violations contains "Restricted data touched without a data-owner role." if {
    input.target.classification == "restricted"
    not "data_owner" in input.principal.roles
}

environment_violations contains "Production change outside an approved window." if {
    input.target.environment == "production"
    not input.change.window_open
}

# Affirmative rules are separate and additive. A read in a
# non-production environment by a recognized role is allowed;
# the same read in production additionally requires assurance;
# a mutation additionally requires a bound approval.

is_action_authorized if {
    input.operation.kind == "read"
    input.target.environment in {"development", "staging", "qa"}
    some role in input.principal.roles
    role in {"analyst", "developer", "admin"}
}

is_action_authorized if {
    input.operation.kind == "read"
    input.target.environment == "production"
    input.principal.assurance == "phishing_resistant"
    some role in input.principal.roles
    role in {"admin", "data_owner"}
}

is_action_authorized if {
    input.operation.kind == "mutate"
    some role in input.principal.roles
    role in {"admin", "data_owner"}
    approval_is_bound
}

# Approval is bound to the exact payload and is short-lived, so an
# approval obtained for one request cannot authorize another. Note that
# the current time arrives in the input document rather than being read
# from the clock inside the policy: a rule that calls time.now_ns() is
# not replayable from its logged input, which forfeits the reproducibility
# this gate exists to provide.

approval_is_bound if {
    input.approval.verified == true
    input.approval.payload_hash == crypto.sha256(input.operation.canonical)
    age_ns := input.context.now_ns - (input.approval.issued_at * 1000000000)
    age_ns >= 0
    age_ns <= 300 * 1000000000
    endswith(input.approval.approver, "@example.com")
}

approval_violations contains "Mutating operations require a verified approval." if {
    input.operation.kind == "mutate"
    not input.approval.verified
}

approval_violations contains "Approval hash does not match the submitted payload." if {
    input.operation.kind == "mutate"
    input.approval.verified == true
    input.approval.payload_hash != crypto.sha256(input.operation.canonical)
}

# Without this rule an expired approval denies with an empty violation
# set: the caller learns only that it was refused, not why. Every path
# that can deny needs a reason, or the deny is undiagnosable in
# production and untestable in review.

approval_violations contains "Approval is outside its freshness window." if {
    input.operation.kind == "mutate"
    input.approval.verified == true
    input.context.now_ns - (input.approval.issued_at * 1000000000) > 300 * 1000000000
}

What the input document must carry, and what it must not

09 Execution isolation

Assume the server is hostile. Not because most are, but because the cost of that assumption is a container configuration and the cost of the alternative is the workstation.

A local server launched over stdio is a child process of the host application and inherits the invoking user's privileges — the home directory, the cloud credential files, the SSH keys, the browser profile. Compromise it through a poisoned dependency or a prompt-driven misuse and the attacker has everything the user has. Standard container runtimes reduce that but share the host kernel, so a kernel-level escape remains on the table. A userspace application kernel interposes: the sandboxed workload's system calls are handled by a kernel implemented in userspace rather than passed to the host.

Server-side input handling

Isolation bounds the damage; input validation prevents most of it from starting. Three requirements carry disproportionate weight in an MCP server, because they are the three that a model-driven caller will reach accidentally as well as maliciously:

• Path containment resolved, not inspected. Rejecting .. in a string is not containment. Resolve the candidate path fully — through symlinks — and then assert that the resolved result is still inside the permitted root. A canonicalization step that falls back to the original path when resolution fails is a real, exploited bug class, not a hypothetical one.
• Bounded payloads. Size caps on reads and writes, row limits on queries, and iteration limits on tool loops. Absent these, a single tool call is a denial-of-service primitive and a cost incident.
• Typed schemas over free text. Constrain parameters to enumerations, patterns and ranges wherever the tool's purpose allows. Every free-form string field is a place where an instruction can be smuggled to something downstream that parses it.

10 Control-plane discipline

Everything to this point is AI-specific. This section is not, and it is the part most MCP deployments skip — because the estate still feels like a pilot long after it has become infrastructure that can change production.

Separate the powers that combine into ownership

The objective is narrow and worth stating as a single sentence: one compromised identity, process, server, key, API or administrative endpoint must not be able to become permanent authority over the estate. Everything below is a mechanism for making that true under a different failure mode.

The controls, in priority order

Incident response for a compromised plane

11 Incident register

Six compromises — five with nothing to do with AI, all of them directly instructive. They are here because the failure pattern is the one an MCP estate will reproduce.

12 Standards crosswalk

An architectural mapping, not an official equivalency. A control that satisfies one framework should never be assumed to satisfy another — the point of the table is to make the evidence conversation tractable, not to claim conformity.

Regulatory scope follows what the estate touches

Obligations attach to the systems an MCP deployment can reach, not to the deployment's own novelty. Three worth naming precisely:

• GDPR Article 32 requires risk-appropriate technical and organizational measures, and names four elements explicitly: pseudonymisation and encryption; the ability to ensure ongoing confidentiality, integrity, availability and resilience; the ability to restore availability and access in a timely manner after an incident; and a process for regularly testing, assessing and evaluating the effectiveness of those measures. The fourth is the one architecture documents usually omit and auditors always ask about.
• HIPAA technical safeguards at 45 CFR §164.312 — access control, audit controls, integrity, person or entity authentication, and transmission security — map cleanly onto the controls above. HHS published a proposed rule in January 2025 to strengthen the Security Rule; as of publication it is neither finalized nor withdrawn, and the existing Security Rule remains in effect. Design to the rule that is in force and track the proposal separately.
• SOC 2 and ISO/IEC 27001 treat these components as in-scope systems once they can affect a system in scope. An MCP server that can change a production configuration is a production system, whatever the internal project classification says.

13 Assurance and testing

Different techniques find different defect classes. They are layers, not competing options, and an annual penetration test is not a testing programme.

14 Metrics that mean something

Measure enforcement and exposure, not activity. “Servers reviewed” and “people trained” are weak outcome indicators if administrators still hold reusable global tokens and one endpoint is public.

15 Phased roadmap

Sequenced so that each phase is independently valuable and each gate is a thing that can fail. A phase whose exit criterion cannot fail is not a gate.

16 Decisions and open questions

Recorded with the reasoning intact, including the ones that are genuinely unresolved. An architecture document that contains no open questions is describing a system nobody has thought hard about.

Open questions — genuinely unresolved

17 Source discipline

This reference was assembled from working drafts and then checked against primary sources. Several claims did not survive. Recording that is not a disclaimer — it is the part of the method that makes the rest usable.

What could not be verified, and is therefore not asserted

• Any count of MCP ecosystem vulnerabilities or exposed servers. Circulating figures range from nine to more than forty across the same period, none from an authoritative registry. No number appears on this page.
• The current status of the proposed HIPAA Security Rule strengthening. The rulemaking record shows neither a final rule nor a withdrawal, and the responsible pages have not been refreshed recently enough to restate it. The defensible statement is that it remains proposed and the existing rule is in force.
• Effectiveness rates for prompt-injection defences. Vendor-published detection rates are not independently reproducible and are not cited here in either direction.
• The exact release date of CSA's AI Controls Matrix v1.1, where the issuing body's own pages disagree by three weeks. The version is cited; the date is not.

18 References

Primary sources only. Every technical claim on this page traces to one of these; where a source has since been revised, the revision is what is cited.

Protocol

• Model Context Protocol specification, revision 2026-07-28 — the current revision. Statelessness, primitives, trust and safety principles.
• MCP Authorization — resource-server role, RFC 9728, RFC 8707, token handling, error semantics.
• MCP Security Best Practices — confused deputy, token passthrough, SSRF, state handle hijacking, proxy scenarios.
• MCP Authorization — security considerations — per-client consent, token audience binding, access-token privilege restriction.
• MCP Streamable HTTP transport — Origin validation, localhost binding, and the removal of protocol-level sessions.

Identity and authorization

• RFC 8693 — OAuth 2.0 Token Exchange (Proposed Standard, January 2020). Delegation versus impersonation; the act claim.
• RFC 8707 — Resource Indicators for OAuth 2.0. The resource parameter and canonical resource identifiers.
• RFC 9728 — OAuth 2.0 Protected Resource Metadata.
• RFC 9700 — Best Current Practice for OAuth 2.0 Security (BCP 240, January 2025). Audience restriction; implicit grant SHOULD NOT, password grant MUST NOT.
• RFC 7636 — Proof Key for Code Exchange.
• RFC 9449 — OAuth 2.0 Demonstrating Proof of Possession (DPoP).
• draft-ietf-oauth-v2-1 — The OAuth 2.1 Authorization Framework. An active Internet-Draft, cited as direction of travel and never as a standard.
• NIST SP 800-63B-4 — Authentication and Authenticator Management (July 2025). Phishing resistance at AAL2 and AAL3.
• SPIFFE / SPIRE use cases. Workload attestation and automatically rotated short-lived identities.

Frameworks and control catalogues

• NIST Cybersecurity Framework 2.0 (CSWP 29, February 2024). The six Functions.
• NIST SP 800-207 — Zero Trust Architecture. Seven tenets; no implicit trust from network location.
• NIST SP 800-53 Rev. 5, Release 5.2.0 (27 August 2025), emphasizing software update and patching controls.
• NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment.
• NIST AI Risk Management Framework 1.0 (AI 100-1, January 2023). GOVERN 1.2; MANAGE 2.4.
• CIS Critical Security Controls v8.1 (June 2024). Controls 3, 5, 6, 7, 8, 12, 16, 17.
• OWASP API Security Top 10 — 2023.
• OWASP Top 10 for LLM Applications, 2026 edition (published August 2026). The identifiers used throughout §04.
• SLSA v1.2 specification. Build and Source tracks; provenance and attestation.
• CSA AI Controls Matrix v1.1. Cited by framework and version, per §17.
• MITRE ATT&CK T1078 — Valid Accounts, and M1026 — Privileged Account Management.
• Regulation (EU) 2016/679 (GDPR) — Articles 32 and 33.
• HHS — Summary of the HIPAA Security Rule. Technical safeguards at 45 CFR §164.312.

Runtime, policy and incidents

• gVisor — Linux/amd64 syscall compatibility. The 288-of-351 figure, from the project itself.
• gVisor architecture guide. The Sentry as a userspace application kernel.
• Open Policy Agent — policy reference and built-in functions. Including trim_right, which is the function that exists.
• OPA v0 compatibility. Why import rego.v1 is now a no-op.
• Kubernetes auditing. Audit levels, external backends, and the memory cost of detailed capture.
• Microsoft — Storm-0558 key acquisition investigation, including the March 2024 addendum stating the crash dump was never found.
• CircleCI — incident report for the January 4, 2023 security incident.
• Okta — unauthorized access to the support case management system: root cause and remediation.
• JetBrains — CVE-2026-63077 additional guidance following reports of active exploitation, and the NVD record.
• NVD — CVE-2024-27198 and CVE-2024-27199. Note the difference in class and severity.
• Kubernetes — ingress-nginx CVE-2025-1974.
• NVD — CVE-2018-1002105. The kube-apiserver proxied-upgrade confused deputy.
• Cursor security advisory — CVE-2026-50548 / CVE-2026-50549. The primary record for the sandbox-escape flaws discussed in §11.
• Microsoft — control plane and data plane operations. The distinction this architecture borrows.