Securing the Model Context Protocol as an Enterprise Control Plane

Executive overview

An authored reference architecture and threat model for governing AI tool access at enterprise scale — treating an MCP estate as what it becomes in practice, a control plane with a non-deterministic caller, and placing the enforceable controls where determinism still exists.

Assessment artifacts

The full reference in a self-contained interactive page: the layered architecture and trust-boundary model, a filterable three-tier threat taxonomy mapped to current OWASP identifiers, the indirect prompt-injection path with its deterministic and probabilistic defence gates, the delegated-identity model with the specification's normative requirements quoted in full, a validated Open Policy Agent policy skeleton, the execution-isolation posture matrix with its negative tests, control-plane separation of duties, an incident register drawn from six real compromises, the standards crosswalk, the assurance programme, enforcement metrics, a phased roadmap, open questions, and a published record of every correction made during verification.

Business challenge

The Model Context Protocol solved a real problem — it replaced bespoke per-integration glue with one standard way for an AI application to reach tools, data and workflows. What it also did, quietly, was change what an integration layer is. An 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 a control plane by any working definition, and it inherits the control plane's governing property: it converts identity and policy into authority at scale, so a compromise that would affect one host in an ordinary application affects the estate. Two things then make it harder than the control planes that came before. The caller is a language model that composes its next action from whatever text has entered its context, including text an attacker placed in a support ticket or a web page, so the assumption that the client is on your side does not survive. And the published guidance is unreliable in a specific and dangerous way: much of it was written against an MCP revision that no longer describes the protocol, against OWASP identifiers that have since been renumbered, and around statistics that turn out to be misquoted from a single vendor blog. Organizations are therefore hardening against a specification that has moved and a threat picture nobody has checked.

Environment and constraints

• This is authored research and technical writing. It is not a client engagement, and no client, delivery, deployment or measured result is described anywhere in it.
• Written against MCP specification revision 2026-07-28, the OWASP Top 10 for LLM Applications 2026 edition, NIST SP 800-63-4, NIST CSF 2.0, CIS Controls v8.1 and SLSA v1.2, verified as of 8 August 2026.
• The subject moves quickly. The MCP specification and the OWASP LLM identifiers both changed within the preceding twelve months, and both changes invalidate widely circulated guidance; the reference is written on the explicit assumption that parts of it will be wrong within a year and states so.
• Vendor-neutral by constraint. The architecture is expressed as planes, boundaries and controls rather than as products, so that it can be assessed against an estate that has already made its platform choices.
• All code, configuration and policy fragments are illustrative skeletons showing shape and intent. They are not production artifacts and have not been deployed.
• No credential material, customer data, client identity or vulnerability specific to any live system appears anywhere in the work.
• OAuth 2.1 is treated throughout as an active Internet-Draft rather than a published standard, because it is one — including where the MCP specification itself depends on it normatively.

Objectives and success measures

• Establish why an enterprise MCP estate should be governed as a control plane rather than as an integration layer, in terms a platform owner and a risk owner can both act on.
• Enumerate the trust boundaries explicitly, including the ones a request never crosses and that consequently go undefended.
• Separate the controls that hold under a successful prompt injection from the mitigations that merely reduce its rate, and be explicit about which is which.
• Bring the architecture into line with the current specification, and quote its normative requirements rather than paraphrasing them.
• Give the policy gate a defensible design — structural evaluation over a typed input document, with approval cryptographically bound to the payload.
• Map the control set to NIST CSF 2.0, ISO/IEC 27001, CIS v8.1, OWASP and the AI-specific frameworks, as an architectural crosswalk and never as a claim of conformity.
• Define metrics that measure enforcement and exposure rather than activity, including a quantitative handle on consent fatigue.
• Publish the verification record — corrections made, figures removed, claims that could not be substantiated — so a reader can judge how far to trust the rest.

Role and responsibilities

Author. I wrote the architecture, the threat taxonomy and the control set, and did the verification behind them. Every RFC, CVE, CVSS score, version number, framework identifier and quoted normative sentence was checked against a primary source rather than written from memory, and the resulting corrections are published on the page itself rather than quietly absorbed. The policy skeleton was compiled and evaluated under Open Policy Agent rather than presented untested, and the finished reference was put through an adversarial review pass whose findings were applied. This is research and technical writing; it does not describe a delivered client system.

Architecture and design approach

• I started from the naming collision rather than disambiguating it away. 'MCP' now means both the Model Context Protocol and, in enterprise architecture usage, a managed control plane — and the argument of the whole piece is that at scale they are the same object. Deploy the protocol across an enterprise and you have built the control plane, which means the discipline that governs one is the discipline that governs the other: identity separation, key custody, deny-by-default authorization, independent audit ownership and recovery that does not depend on the system being recovered.
• The design position everything else answers to is that prompt injection is not solved and must not be planned around as though it will be. Treat the model as an untrusted, occasionally hostile caller holding a legitimate credential, and put the enforceable controls where determinism still exists. That single assumption is what makes the architecture testable: each control is then assessed on whether it holds regardless of whether the model was manipulated, which is a property you can write a negative test for.
• I modelled indirect prompt injection as a path with five named defence gates, and then did the thing that write-ups in this space usually avoid — marked which gates are deterministic and which are probabilistic. Ingestion filtering and provenance framing reduce the rate at which injection succeeds; they are classifiers operating on adversarial natural language and cannot carry a safety case. The policy gate, the identity and audience binding, and egress control do not care whether the model was fooled. Budget the first two as defence in depth and put the safety case on the last three.
• The trust model is four numbered boundaries — model context to enforcement, enforcement to execution, execution to managed systems, and everything to the evidence and recovery domain — plus three that a request never crosses and that therefore get forgotten: server-to-server, registry-to-runtime, and the management plane's own path into policy authoring.
• For identity I took the position that exchange replaces forwarding without exception, and then found that the current specification agrees in normative terms. It is worth quoting rather than paraphrasing: MCP servers 'MUST NOT accept any tokens that were not explicitly issued for the MCP server', clients 'MUST NOT send tokens to the MCP server other than ones issued by the MCP server's authorization server', and a server acting as a client to an upstream API 'MUST NOT pass through the token it received from the MCP client'. Zero passthrough stopped being a hardening recommendation and became a conformance requirement, which changes the conversation with a sceptical platform team entirely.
• The policy gate evaluates structure, never intent. A component that reasons about what a request appears to mean inherits the ambiguity it exists to remove; a component that evaluates a typed input document answers a closed question reproducibly, testably and in a form an assessor can follow. That distinction is also where I found the most serious defect in the source material — see the decisions and lessons below.
• Execution isolation is tiered by provenance rather than applied uniformly, because a uniform strict posture gets relaxed to whatever the least trustworthy server needed, and a uniform weak one is indefensible for unreviewed third-party code. Each control in the isolation table is paired with its negative test, since the failure mode here is a configuration everyone believes is in force.
• For the control-plane half I used six real compromises — Storm-0558, CircleCI, Okta, two TeamCity vulnerability classes and ingress-nginx — none of which involved AI, because the failure pattern is the one an MCP estate will reproduce. In every case authority was transferable or amplifiable: a stolen session was reusable, a service credential remained useful outside its intended context, a signing key made forged identity authoritative, a component's default privilege reached every secret in the cluster. None was a failure of one decisive perimeter control, which is the argument against designing around one.
• I wrote the roadmap as a sequence with gates that can fail, and deliberately without a calendar. Published day counts for programmes like this are guesses dressed as plans and they are the first thing a sponsor holds you to. The durable part is the ordering — exposure and passthrough before isolation, isolation before policy, policy before approval workflows, recovery proven before the estate is treated as production.
• Finally I published the corrections. A section records what was checked, what was wrong in the drafts, and what could not be verified at all. Anyone can assemble a plausible security architecture from secondary sources; the failure mode is that it reads well and contains a dozen quiet untruths. Showing the corrections is the only way a reader can tell checked work from written work.

Security and governance considerations

• The governing objective is stated as one sentence and everything else is a mechanism for making it true under a different failure mode: one compromised identity, process, server, key, API or administrative endpoint must not be able to become permanent authority over the estate.
• Zero token passthrough, without exception. Delegated identity is exchanged per target with an explicit audience, a scope covering the single call, a short lifetime and a recorded actor claim, so a fully compromised server holds a credential no other MCP server will accept and its blast radius collapses to its own downstream scope.
• Authorization is deny-by-default and evaluated over a typed input document carrying principal, workload, parsed operation, target classification, approval binding and correlation identifiers — and explicitly no free-form intent. Cryptographic validity is never treated as authorization: issuer, audience, scope, purpose and lifetime are all validated, which is precisely the check whose absence sat at the centre of Storm-0558.
• Approval for destructive actions binds cryptographically to a hash of the canonical payload with a short freshness window, so an approval obtained for one request cannot authorize another. Consent is risk-tiered rather than uniform, because a prompt that fires on everything stops being a decision — and the architecture treats that degradation as a measurable control failure rather than a usability complaint.
• Execution is isolated by provenance tier, with each control paired to the negative test that proves it: no ambient network, read-only root filesystem, dropped capabilities, non-executable scratch space, explicit minimal mounts, non-root execution and resource bounds. Path containment is resolved and then asserted, never inspected, because a canonicalization step that falls back to the original path on failure is a real and exploited defect class.
• Powers that combine into ownership are separated by design: identity administration from policy administration, key custody from platform administration, artifact signing from production deployment, backup administration from production administration, and — the one to defend hardest — audit administration from the team being judged. Audit custody sits outside the plane's administrative domain, so evidence survives the compromise case.
• The system fails closed. Authorization uncertainty is never silently a permit, and the position is taken before the outage rather than during it, because a rule invented mid-incident gets reversed mid-incident and the reversal is what causes the damage.
• Supply chain is treated as a trust boundary in its own right: a curated catalogue, signature and provenance verification at admission, digest pinning rather than version pinning — because the rug-pull threat is specifically a change behind a stable identifier, which is exactly what a tag is — plus SBOM generation and continuous component scanning.
• Residual risk is stated rather than absorbed. Prompt injection is not solved, the protocol provides no capability attestation, content filtering is probabilistic, and cross-server chain authorization has no production-grade mechanism. Each is named as an open question with the compensating position that is currently available.

Implementation and migration approach

• Research before drafting. Source material was read in full and inventoried claim by claim before any structure was decided, so that the architecture followed from what could be substantiated rather than the substantiation being fitted to a structure.
• Primary-source verification, in two independent passes. One covering vulnerability and incident claims against NVD, CISA's known-exploited catalogue and vendor advisories; one covering RFCs, NIST, OWASP, CIS, SLSA, GDPR, HIPAA, gVisor, Open Policy Agent and the MCP specification itself. Both were instructed to report unverifiable claims as unverifiable rather than hedge them, and both found material errors.
• Normative text quoted rather than paraphrased. Where a requirement carries a MUST or a SHOULD, the sentence is reproduced with the keyword intact and attributed, because strengthening or softening a normative keyword in a summary is the most common way security writing becomes quietly wrong.
• The Rego policy was compiled and executed, not merely written. Running it against allow, tampered-approval and expired-approval inputs exposed a defect that reading it would not have — an expired approval denying with an empty violation set — which is now fixed and documented in the policy comments as a general rule: every path that can deny needs a reason, or the denial is undiagnosable in production and untestable in review.
• Adversarial review before publication, briefed to find errors rather than to assess quality, with authority to verify anything it doubted against primary sources. It returned seventeen findings including a false claim in the introduction to the identity section, a normative NIST sentence truncated in a way that broadened it, a cross-reference to the wrong section, a miscount inside the accuracy section itself, and a broken reference URL. All were applied.
• Accessibility verified by measurement rather than by intent. Contrast was computed for every foreground and background pair in both themes and the light palette was corrected where it fell below the 4.5:1 threshold; horizontally scrollable tables and diagrams were made keyboard-reachable with accessible names, which is a failure most single-file technical artifacts carry.
• Rendering verified in a real browser at desktop, tablet and 390-pixel mobile widths, in both themes, with zero console errors, no horizontal overflow, and every diagram inspected visually — a check that found two connector defects, including an arrow terminating in empty space and boundary labels drawn over the lines they name.
• Corrections published rather than absorbed. The source-discipline section names each claim that changed and what the primary source actually says, including the two figures removed as unsupportable and the four claims that could not be verified at all.

Key decisions and trade-offs

• Unify the two meanings of MCP rather than disambiguate them. Treating the protocol estate as the control plane it becomes at scale is the argument that carries the rest of the piece, and it is what makes twenty years of control-plane discipline directly applicable to a two-year-old protocol.
• Assume the model is an untrusted caller holding a legitimate credential. It is the only assumption that survives indirect prompt injection, and it converts a set of hopes into a set of testable design properties.
• Put the safety case on deterministic gates only. Ingestion filtering and provenance framing are included and are explicitly labelled probabilistic; identity binding, structural policy evaluation and egress control carry the weight, because they do not need to have understood the attack.
• Evaluate structure, never intent. This is also where the source material's most serious defect lived — a policy that claimed to validate query structure while performing substring matching on a raw string. Naming that gap, rather than reproducing the example, is the difference between a speed bump and a wall.
• Quote the specification rather than characterize it. Once the current revision is read carefully, several controls that would otherwise need arguing for are already normative requirements — which is a materially stronger position to take into a design review than an appeal to good practice.
• Publish without a calendar. The roadmap is a sequence with gates that can fail rather than a set of day counts, because published day counts for programmes like this are guesses that a sponsor will hold you to.
• Set featured to false. The work stands on its own page; the flag is for selecting among a set, and it stops selecting anything when most of the set carries it.
• Publish the verification record. It costs nothing to be right quietly, and it demonstrates nothing either. The corrections are the evidence that the rest was checked.

Results and outcomes

• A vendor-neutral reference architecture that can be applied without adopting a product: planes, boundaries and controls expressed as design positions with the reasoning attached, so a reader can disagree with a decision on its merits rather than on authority.
• A threat taxonomy in three tiers — protocol-specific, model-mediated, and conventional control-plane — each mapped to the current OWASP LLM and API identifiers, so that a risk register built from it lines up with frameworks an assessor already recognizes.
• An honest separation of deterministic controls from probabilistic ones. The architecture states plainly that no filter or classifier reliably prevents prompt injection, and places the safety case on identity binding, structural policy evaluation and egress control instead.
• The current specification's normative requirements, quoted rather than summarized. Most published MCP security material still asserts that the protocol defines no authentication or authorization model; that has not been true since the specification gained an authorization component, and the difference changes what a platform team is obliged to implement.
• A policy skeleton that actually compiles. It was validated with Open Policy Agent and evaluated against allow, tampered-approval and expired-approval cases; running it exposed a real defect — an expired approval denied with an empty violation set, giving the caller no reason — which was fixed before publication.
• A named architectural defect that most published examples of this control share: policies that claim to evaluate query structure while in fact performing uppercase substring and regular-expression matching on a raw string. That is bypassable by comments, literals, casing and dialect syntax, and the reference states the limitation and pushes parsing into the enforcement point where it belongs.
• An incident register that draws the line from six real control-plane compromises to the specific control each one argues for, including the observation that cryptographic signature validity is not authorization — the failure at the centre of Storm-0558 and the one a broker minting delegated tokens is most likely to repeat.
• A metrics set that measures enforcement and exposure rather than activity, including two indicators this subject needs and rarely gets: an approval grant rate that reveals when human-in-the-loop review has degraded into a click-through, and denied-then-succeeded sequences, which distinguish an agent iterating toward a permitted phrasing from a user making a mistake.
• A published source-discipline section recording fourteen corrections made during verification, two figures removed entirely as unsupportable, and four claims that could not be verified and are therefore not asserted anywhere on the page.
• A set of open questions stated as open — capability attestation, where the parser lives, consent at agentic speed, cross-server chain authorization, transcript custody and standards drift — because an architecture document with no unresolved questions is describing a system nobody has thought hard about.

Lessons learned

• The most dangerous material in a fast-moving field is not the obviously wrong kind — it is the confidently written kind that was accurate eighteen months ago. Three of the corrections here were not errors when they were drafted; the specification moved underneath them. Any architecture in this space needs a re-verification cadence, not a review date.
• A statistic that everyone repeats is usually one source misquoted. Two widely circulated figures about MCP exposure traced back to a single vendor research post, and both had been inflated in transmission — one of them by roughly a factor of thirty. Chasing a number to its origin is a small amount of work that changes what you are willing to publish.
• Cryptographic validity is not authorization, and the industry keeps relearning it expensively. Verifying a signature while assuming a library performed issuer and scope validation is exactly what happened in Storm-0558, and it is exactly what a broker minting delegated tokens is positioned to repeat.
• Code that has not been run is a diagram. Compiling the policy found that four of its five violation families were undefined and would not load at all; executing it found that an expired approval denied with no reason. Neither is visible by reading, and both would have been found by the first competent person who tried it.
• Prompt injection is a design constraint, not a bug to be scheduled. Architectures that treat it as pending eventually place their safety case on a classifier, and a classifier operating on adversarial natural language cannot carry one. Accepting the constraint early makes the rest of the design simpler, because it forces the enforceable controls into positions where they can actually be tested.
• Human-in-the-loop degrades under exactly the conditions that make it necessary. The workflows with the most authority are the ones designed to run without a person, so the approval prompt arrives most often precisely where attention is scarcest. Measuring the grant rate is the only way to know whether the control is still a decision.
• Naming the limitation is more useful than omitting it. Stating that lexical matching is not structural evaluation, that capability attestation does not exist, and that cross-server chain authorization is unsolved makes the document harder to write and considerably more useful to anyone who has to defend a design built on it.
• An adversarial reviewer instructed to find errors finds them. Briefed to assess quality it would have returned praise; briefed to refute, it returned seventeen defects including one false claim in a section introduction. The instruction is the control, not the reviewer.

Related technologies

• Model Context Protocol (revision 2026-07-28)
• JSON-RPC 2.0
• Streamable HTTP transport
• OAuth 2.0 Token Exchange (RFC 8693)
• Resource Indicators for OAuth 2.0 (RFC 8707)
• OAuth 2.0 Protected Resource Metadata (RFC 9728)
• OAuth 2.0 Security Best Current Practice (RFC 9700)
• PKCE (RFC 7636)
• DPoP (RFC 9449)
• Open Policy Agent and Rego
• gVisor (runsc) userspace kernel isolation
• Container hardening and capability restriction
• SPIFFE and SPIRE workload identity
• Security token service and delegated identity
• SLSA v1.2 provenance and artifact signing
• SBOM and software composition analysis
• NIST Cybersecurity Framework 2.0
• NIST SP 800-207 Zero Trust Architecture
• NIST SP 800-63-4 digital identity
• NIST AI Risk Management Framework
• OWASP Top 10 for LLM Applications 2026
• OWASP API Security Top 10 2023
• CIS Critical Security Controls v8.1
• MITRE ATT&CK
• CSA AI Controls Matrix v1.1

Related projects