MCP Security Program Maturity Model for Enterprise AI Stacks

An enterprise MCP security and governance platform must control agent identity, verify tools and credentials, and keep an auditable record of agent actions. The MCP security maturity model turns those requirements into four stages, from basic authentication to verification of every tool call. For enterprise AI stacks, the right benchmark is the weakest deployment in scope.

Why MCP became enterprise infrastructure faster than security could follow

MCP connects agents to databases, CRMs, code repositories, and financial APIs. These are sensitive systems. Access to a wide range of tools lets agents work across these systems, and teams can connect them with so little setup that security teams have yet to decide who owns them or how to review them.

That is the MCP Paradox. The same frictionlessness that accelerates adoption also creates systemic vulnerability when access spreads without matching controls. A connection can become operationally important before anyone has defined its permission boundaries, credential policy, or audit requirements. The governance gap is therefore not just missing documentation, but infrastructure running ahead of the rules for using it.

The structural security flaws MCP ships with by default

OX Security’s April 2026 research found that STDIO transport in Anthropic’s official Python, TypeScript, Java, and Rust SDKs passes parameters directly to the host OS shell without sanitization. A process command executes regardless of whether a valid MCP server initializes. Cloud Security Alliance’s May 2026 research note says Anthropic confirmed the behavior was intentional and declined to modify the protocol architecture [1][2][3]. Downstream developers are left responsible for countering that default.

The same pattern extends beyond command execution. The authorization specification defines an OAuth 2.1 framework but makes authorization optional, so operators must actively enforce authentication. The protocol also has no built-in role-based access control or fine-grained authorization checks, and it does not enforce privilege separation. Authentication alone cannot close those permission gaps.

Trust between servers is another inherited weakness. Invariant Labs demonstrated cross-server tool shadowing, in which a malicious MCP server can weaponize adjacent trusted servers. These defaults call for a program that covers identity, tool integrity, and monitoring together to address behavior across trusted connections and weaknesses beyond the reach of individual patches.

What the threat landscape looks like in practice: the 2026 incident record

A July 2026 dynamic assessment found that the vast majority of internet-facing MCP servers lacked OAuth authentication. Hundreds of tool instances allowed shell execution without access controls. This is the authentication gap in concrete form. Before an organization can assess sophisticated agent behavior, it must establish who can reach the tools at all.

Supply chain failures expose a different weakness. Antiy Labs documented malicious skills in ClawHub, OpenClaw’s official skill marketplace, while the incident record describes roughly one-in-five packages as malicious at peak. A marketplace connection is not an approval decision. The OpenClaw marketplace compromise makes formal intake review and deployed-package visibility central to the maturity model.

Tool poisoning attacks target what agents are told. Researchers found attack success rates exceeding 60% against major LLM agents on servers without tool integrity controls. In a separate case, Cisco documented how a compromised low-privilege agent reached a high-privilege financial approval agent through a trusted session. These attack classes require different defenses, because checking tool instructions does not remove persistent session trust, and authenticating a session does not make its tools safe.

Where most enterprises actually stand today: the ungoverned baseline

Only roughly one in five teams treat AI agents as independent, identity-bearing entities, while nearly half rely on shared API keys for agent-to-agent authentication. More than two-thirds cannot clearly distinguish agent actions from human actions. With access shared this way, a log may show what happened without showing which agent did it.

This baseline needs a clear name. Stacklok’s Stage 1 describes servers on developer laptops, without containerization or RBAC, and with secrets stored locally. In the security progression used here, that ungoverned state is Level 0, before the minimum controls of Level 1.

Most organizations are expected to locate themselves near the beginning. A team’s secure deployment somewhere does not show that the controls cover the actual deployment estate. Shadow MCP, inherited human access, and shared credentials explain why a successful pilot can coexist with an ungoverned enterprise baseline.

The four-level maturity model: what each stage requires across identity, integrity, and monitoring

CSA’s four-level security framework and Stacklok’s organizational stages describe related but distinct progressions. The security levels define required controls, while the organizational stages show how delivery moves from individual laptops to a centrally governed platform. Each security level builds on the controls below it.

Level 1 establishes basic authentication and transport security. Identity controls require OAuth 2.1 with PKCE, TLS 1.2+, a complete server inventory, and minimum-permission service accounts. Auditability begins with 90-day log retention and quarterly vulnerability review. This closes unauthenticated access and unencrypted communications, but tool integrity, session security, and behavioral monitoring remain open.

Level 2 adds tool integrity verification and session hardening. Access tokens expire within one hour, refresh tokens rotate on every use, and session tokens must be kept out of plaintext files and environment variables. Tools must be checked against their declared behavior. These controls address tool poisoning, rug pulls, and session hijacking, while retaining Level 1’s audit baseline. Stacklok’s Stage 2 counterpart is containerized pilots with standardized OAuth/OIDC authentication.

Level 3 adds full message signing, controls for the supply chain, and behavioral monitoring. Identity and access operate within enterprise-wide governance, while integrity requires cryptographic message protection, formal server intake, an approved registry, and software bills of materials, or SBOMs, for all deployments. Connections are automatically blocked when critical supply chain vulnerabilities exceed a 72-hour remediation window. Continuous behavioral monitoring must come with written procedures for how to respond. This is the threshold for sensitive or regulated enterprise deployments, addressing malicious packages and behavior that authentication alone misses.

Level 4 ends the use of persistent trust. Every tool invocation is checked on its own, even after the session’s initial authentication, so continuous verification protects calls between periodic approvals. Auditability must support that call-by-call scrutiny. This posture directly counters Cisco’s trusted-session lateral movement class and fits critical infrastructure, high-value financial systems, and the most stringently regulated environments. OWASP’s MCP Top 10 project and CoSAI’s roughly 40-threat taxonomy define the broader threat surface for continuous coverage.

How to assess which level your organization is actually at

A structured assessment begins with identity and access. Does every MCP server require OAuth 2.1 with PKCE, or do static keys and unauthenticated connections remain? Do agents have their own credentials, or inherit human and shared service access? Can the organization produce a current inventory that includes servers connected outside formal approval?

The second set of checks covers tool and supply chain integrity. Is there formal intake review before a server reaches production, and are tool descriptions and metadata scanned for hidden instructions before agents consume them? Does every deployed server have an SBOM? Is the response to a critical supply chain vulnerability automated?

The third dimension tests auditability and detection. Can records show which agent called which tool, with what parameters, and what data came back? Can logs distinguish agents from humans and provide a tamper-proof record at the level required for applicable audits? Does continuous monitoring have set procedures for how to respond, or do reviews happen only from time to time? The assessed level is the weakest link within the stated scope, so undiscovered shadow MCP invalidates claims that depend on complete inventory.

How do you secure MCP deployments across your enterprise AI stack?

The move from Level 0 to Level 1 starts with inventory and enforced authentication. The recommended first step is a complete server registry, followed by OAuth 2.1 with PKCE as a hard requirement for new connections and a deadline for replacing existing static-key connections. TLS 1.2+ and 90-day audit log retention complete the minimum posture. This directly addresses the exposed-server authentication failures in the incident record.

The move to Level 2 depends on session hygiene and tool inspection. The priority is one-hour access tokens, refresh token rotation on every use, and no plaintext session tokens in environment variables or configuration files. Static tokens without expiry prevent this transition. Tool-description scanning then addresses hidden instructions before agents consume metadata, targeting the poisoning class with attack success rates above 60% in unprotected environments.

The move to Level 3 depends on supply chain governance and a working detection response. A formal intake registry and approval workflow must precede production access, with SBOMs and automated connection blocking after the 72-hour critical-vulnerability remediation window. Behavioral monitoring with documented response procedures adds the ability to detect intent drift alongside patching after incidents.

The move to Level 4 depends on eliminating persistent trust. Per-invocation verification and just-in-time credentials, limited to the required permission and expiring immediately after use, address the Cisco lateral movement case. Full OpenTelemetry tracing should record tool calls, context access, and the data returned, and link them in a tamper-proof audit record. For platform evaluation, these are concrete criteria for assessing claims to provide “AI security.

How regulatory requirements map to the maturity levels

The EU AI Act’s high-risk obligations bring relevant MCP-connected actions into the scope of logging, human oversight, and cybersecurity resilience requirements. The gateway does not sit outside the regulated workflow. Level 1 log retention and Level 3 behavioral monitoring help meet those obligations, but maturity status alone does not prove compliance.

SOC 2 maps to evidence of governed operation. The assessment needs an attributable, tamper-proof record of agent tool use, rather than a general assurance that authentication is enabled. Level 3’s written procedures for monitoring and response add to that evidence. The control program and its audit trail belong together.

HIPAA likewise makes the quality of records important when MCP gateways operate on regulated data. The relevant assessment asks whether the organization can reconstruct the agent, tool, parameters, and returned data at the required audit level. Shared human and agent identities weaken that reconstruction. Distinguishable agent actions make incident investigation more usable.

GDPR connects the same auditability controls to incident investigation and breach notification obligations. A record that cannot separate agent activity from human activity leaves a basic attribution gap. Level 3’s monitoring and agent distinction address that gap within the security program. They do not require a separate MCP compliance architecture.

NSA’s Artificial Intelligence Security Center published its May 2026 Cybersecurity Information Sheet on MCP security design because adoption had outpaced the security model. That guidance reinforces the need to begin the progression. Unlike the regulatory frameworks, it provides security design guidance while pointing toward the same governed operating posture.

The organizational model that makes the maturity progression sustainable

Unclear ownership can defeat technically sound controls. Engineering adopts MCP to move quickly, security discovers it afterward and blocks it, and teams find routes around the block. These workarounds create shadow MCP that undermines inventory before higher-level controls can take hold. Security cannot govern connections it never sees.

The recommended operating model gives security and IT ownership of the golden path. This is a pre-approved, centrally governed set of MCP connections that employees can use without a fresh security review because review is already built into the path. Safe access becomes the ordinary route. It also gives employees who are not power users a defined way to use agentic AI.

Platform engineering’s role in that path changes as maturity grows. At Levels 1–2, it builds authentication flows, credential stores, and token rotation, which become bottlenecks when rebuilt team by team. At Levels 3–4, a central layer handles SSO, SCIM, and just-in-time credential issuance for teams to consume.

CSA treats each level as an ongoing program state. Quarterly review at Level 1, continuous monitoring at Level 3, and per-invocation verification at Level 4 require continuing ownership as new attack classes emerge. A mature program remains accountable after controls launch for every new server, permission change, and tool connection brought into scope.