What OWASP’s MCP Security Guide
Gives You — And What It Can’t

OWASP occupies a specific and valuable position in the security literature. It does not produce original research. It synthesizes practitioner knowledge into frameworks that organizations can adopt with institutional confidence. That function matters — particularly in a field like agentic AI security, where the research-to-practice gap remains large and the practitioner community is still building the vocabulary to talk about the problem. A recognized body putting a minimum bar on paper closes a coordination problem that no individual organization can close alone.

The February 2026 OWASP release, “A Practical Guide for Secure MCP Server Development”, does exactly that for MCP. It names the vulnerability surface accurately. Its eight control domains cover the ground that needs to be covered for a production MCP deployment to be defensible in the conventional security sense. And its review checklist on page 14 is the clearest single-page statement of the minimum bar currently available.

The word “minimum” is load-bearing. This analysis reads the guide as enterprise architects must read it: acknowledging what it accomplishes, identifying three specific contributions that most deployments currently miss, and mapping the structural gap it leaves open by design to the governance infrastructure enterprises must build above it.

Three Things OWASP Got Specifically Right

The guide’s eight control domains are sound. Rather than rehearse them, three contributions deserve specific attention because they address failure modes that current enterprise MCP deployments are most likely to have underestimated.

The Confused Deputy Is a Structural Vulnerability, Not Bad Practice

Section 5 of the guide prohibits token passthrough — forwarding a user’s OAuth token to downstream APIs rather than issuing tokens explicitly to the MCP server. Most security guidance frames this as a best practice. OWASP goes further: it names the failure mode as a Confused Deputy vulnerability, a well-defined category in the security literature where a legitimate intermediary is tricked into misusing the authority of a caller it represents.

The structural consequence is specific. Token passthrough breaks the audit trail at the point where it matters most — the boundary between the agent’s context and the downstream system it is acting within. It also bypasses the policy enforcement the MCP server is supposed to provide, because the server’s own identity never appears in the transaction. An MCP server that passes tokens through is not enforcing policy. It is relaying requests on behalf of an identity it has not validated in the current context.

Our dispatch on structural enforcement at the MCP layer documents the broker architecture that prevents this class of failure. OWASP’s Confused Deputy framing is the standards vocabulary that should accompany it in every enterprise MCP security review.

Non-Human Identity Is a Governance Posture, Not a Configuration Task

Section 7 of the guide requires that automated agents and MCP server systems be treated as first-class identities — unique credentials, tightly scoped permissions, continuous auditing of data access and tool usage. This is stated briefly but its organizational implications are significant.

Most enterprise identity programs treat non-human accounts as service accounts: provisioned once, scoped broadly for operational convenience, audited infrequently. That model fails for agentic systems in a specific way. An agent operating with a service account identity creates an impersonation risk — individual agent actions cannot be attributed to a specific task context, which means the audit trail that governance programs depend on does not actually trace agent behavior. It traces the service account. Those are not the same thing.

Treating NHI governance as a first-class program — with its own lifecycle management, credential rotation schedule, and access review cadence — is an organizational decision, not a technical one. OWASP names it correctly as a governance requirement.

Context Compartmentalization Limits Blast Radius by Design

Section 4 recommends resetting MCP sessions when an agent switches contexts or tasks — “One Task, One Session.” The stated rationale is that context compartmentalization prevents hidden instructions from persisting in long conversation histories. That is accurate. The deeper implication is that it architecturally limits the blast radius of any injection that does succeed.

A session-resident injection can influence the entire downstream task sequence within that session. An injection in a compartmentalized session can only influence the task it was injected into. The security property is structural: it does not depend on the model detecting or refusing the injection. It limits what the injection can reach regardless of model inference. That is the right kind of control.

The Coordination-Grade Ceiling

The three contributions above represent genuine additions to enterprise MCP security practice. They also help clarify what the guide as a whole accomplishes — and where it reaches its designed limit.

This is not a criticism of the guide. It is a description of its scope. The OWASP guide is addressed to software architects, platform engineers, and development teams responsible for MCP server development. Its function is to define what responsible server implementation requires. It is not addressed to enterprise architects designing governance programs for agentic deployments — and it does not claim to be.

The distinction is not a hierarchy where one tier supersedes the other. Coordination-grade controls are necessary. An enterprise that has not met the OWASP minimum bar should address that before anything else. The alignment-grade capabilities are what is required above the minimum bar, not instead of it.

Rug Pulls and the Persistent Constraint Problem

One vulnerability in the guide sits precisely at the boundary between these two tiers — Dynamic Tool Instability, which the guide’s vulnerability section calls “Rug Pulls.”

The architectural fix is continuous manifest re-verification at the broker layer on every tool invocation, not only at load time. This is what our CABP dispatch establishes as a permanent architectural component of enterprise MCP deployments — the broker is not a workaround until the protocol matures, it is the enforcement surface that persists because the protocol cannot provide it natively. The Rug Pulls vulnerability makes the broker’s manifest persistence function mandatory, not optional.

In the alignment-grade taxonomy, this maps to Behavioral Constraint Persistence — the capability that ensures behavioral constraints survive not only session boundaries but tool updates. OWASP names the threat. The capability names the architectural response.

The Five Alignment-Grade Capabilities Mapped

The OWASP guide’s eight control domains each have an alignment-grade extension. Five of them map directly to the capabilities enterprises must build above the minimum bar. The mapping is precise: each capability extends a specific OWASP section to the behavioral layer that section leaves open.

The five capabilities below represent Luminity’s synthesis of the Q1 2026 research corpus, organized around the behavioral gap the OWASP guide leaves open by design. They are not drawn from any single external framework — each capability is grounded in the research literature but the taxonomy and its mapping to OWASP’s control domains is our analytical contribution.

• 1
  Extends OWASP Section 2 — Safe Tool Design Behavioral Constraint Persistence OWASP Section 2 requires cryptographic manifests and load-time verification. Behavioral Constraint Persistence extends this to continuous runtime enforcement: manifest re-verification on each invocation, behavioral comparison against the approved specification, and structured escalation when divergence is detected. Directly addresses Dynamic Tool Instability in long-running sessions.
• 2
  Extends OWASP Section 4 — Prompt Injection Controls Human Review Triggers OWASP Section 4 recommends pausing high-risk actions for human confirmation. Human Review Triggers extend this from a binary pause/proceed gate into a risk-calibrated review mechanism tied to objective context. The question is not only whether an action is high-risk in the abstract, but whether it is consistent with the objective the agent was authorized to pursue in the current session.
• 3
  No OWASP Equivalent Objective Fidelity Auditing The OWASP guide has no control that addresses whether agent behavior remains aligned with the authorized objective over the course of a session. Objective Fidelity Auditing is the capability that monitors for drift between what the agent was tasked to do and what it is actually doing — including cases where individual tool calls are each policy-compliant but their cumulative effect is not. This is the gap the coordination-grade ceiling cannot close.
• 4
  Extends OWASP Section 8 — Tools and Continuous Validation Cycle Interpretability OWASP Section 8 recommends feeding audit logs into a SIEM and configuring alerts for anomalous patterns — high-frequency tool calls, unusual file access. Cycle Interpretability extends this from log-based anomaly detection to causal reasoning about agent behavior. Detecting that tool call frequency spiked is coordination-grade monitoring. Understanding why the agent made the calls it made, and whether the reasoning chain leading to those calls was consistent with the authorized objective, is interpretability.
• 5
  Extends OWASP Section 4 — Session Management Interrupt Authority OWASP Section 4 recommends resetting MCP sessions when an agent switches tasks. Interrupt Authority extends this from a configuration option into a structured, always-available override mechanism: a defined escalation path, a guaranteed stop capability that does not depend on the agent’s cooperation, and a recovery protocol that preserves the audit trail through the interruption. The reset recommendation assumes the operator can detect when a session should be reset. Interrupt Authority provides the mechanism regardless of detection quality.

MCP Security Maturity: From Minimum Bar to Enterprise Assurance

The OWASP guide and the five alignment-grade capabilities together define a three-stage maturity progression for MCP security. The stages are not sequential options — Stage 1 is the precondition for Stage 2, and Stage 2 is the precondition for Stage 3. An organization that treats Stage 2 as an alternative to Stage 1 has misread the structure.

OWASP has done the field a genuine service by establishing Stage 1 in writing. The organizations that read the guide as a destination rather than a starting point will find, when something goes wrong, that their audit trail is complete and their accountability is intact — and their agent was still doing something it should not have been doing.