CMMC Level 2 and MCP: connecting AI agents to CUI systems

The Model Context Protocol (MCP) is how many AI agents reach tools and data: a file share, a PLM system, a ticket queue, a database. If one of those systems holds Controlled Unclassified Information (CUI), the MCP server in front of it, and the agent host calling it, are part of the CMMC Level 2 assessment scope. Neither 32 CFR Part 170 nor NIST SP 800-171 names MCP. This page puts the MCP specification’s own security rules next to the SP 800-171 Rev. 2 requirements an assessor will use.

The scoping rules are covered in CMMC Level 1 vs Level 2: when an AI tool brings a system into scope. This page assumes CUI is involved.

Which MCP version

The current MCP specification is dated 28 July 2026. Its changelog lists changes including Remove protocol-level sessions and the Mcp-Session-Id header from the Streamable HTTP transport. and Deprecate the OAuth 2.0 Dynamic Client Registration Protocol. The Security Best Practices page now says MCP is stateless and has no protocol-level sessions. Guidance written against earlier versions, including advice on session hijacking, may not match the servers you deploy. Record which protocol version each server and client implements in your system security plan.

The spec is explicit that it relies on implementers: While MCP itself cannot enforce these security principles at the protocol level, implementers should Implement appropriate access controls and data protections. Compliance with the spec is not compliance with SP 800-171.

Scope: MCP components are assets like any other

Under § 170.19, CUI Assets are assets that process, store, or transmit CUI. Analysis, not sourced fact: an MCP server that reads CUI from a back-end system transmits CUI, and so does the agent host that receives the tool result and passes it to a model. Both belong in the asset inventory. If the model behind the host is a cloud service, the § 170.16 rule applies: a cloud offering that handles CUI must be FedRAMP Authorized at the FedRAMP Moderate (or higher) baseline or meet security requirements equivalent to those established by the FedRAMP Moderate (or higher) baseline.

A remote, third-party MCP server is an external system. SP 800-171 Rev. 2 requirement 3.1.20 is to Verify and control/limit connections to and use of external systems. Its discussion says it also addresses the use of external systems for the processing, storage, or transmission of CUI, including accessing cloud services.

Authorization: identify the agent and the user

For HTTP-based servers, the MCP authorization spec says Authorization servers MUST implement OAuth 2.1 with appropriate security measures for both confidential and public clients. But Authorization is OPTIONAL for MCP implementations., and for local servers Implementations using an STDIO transport SHOULD NOT follow this specification, and instead retrieve credentials from the environment.

SP 800-171 Rev. 2 does not make authentication optional. Requirement 3.5.1 is to Identify system users, processes acting on behalf of users, and devices. Requirement 3.5.2 is to Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems. An agent is a process acting on behalf of a user. Analysis: an MCP server in front of CUI that runs without authorization, or with a shared static credential, is hard to square with 3.5.1 and 3.5.2.

Token rules in the spec that support this:

• MCP servers MUST validate that access tokens were issued specifically for them as the intended audience
• Access tokens MUST NOT be included in the URI query string
• MCP clients MUST implement PKCE according to the OAuth 2.1 draft
• Authorization servers SHOULD issue short-lived access tokens to reduce the impact of leaked tokens.

No token passthrough

The spec says The MCP server MUST NOT pass through the token it received from the MCP client. The Security Best Practices page explains why that matters for accountability: with passthrough, The MCP Server will be unable to identify or distinguish between MCP Clients when clients are calling with an upstream-issued access token, and The downstream Resource Server’s logs may show requests that appear to come from a different source with a different identity. Both factors make incident investigation, controls, and auditing more difficult.

That is the 3.3.2 problem. Requirement 3.3.2 is to Ensure that the actions of individual system users can be uniquely traced to those users, so they can be held accountable for their actions.

For MCP proxy servers that sit in front of third-party APIs, the spec addresses the confused deputy problem: To prevent confused deputy attacks, MCP proxy servers MUST implement per-client consent and proper security controls as detailed below.

Least privilege and scopes

For local servers, the Security Best Practices page says to Execute MCP server commands in a sandboxed environment with minimal default privileges.

Human in the loop is a SHOULD

The spec says Tools represent arbitrary code execution and must be treated with appropriate caution. and Hosts must obtain explicit user consent before invoking any tool. The tools page is weaker in normative terms: For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations. It also warns that clients MUST consider tool annotations to be untrusted unless they come from trusted servers.

Analysis: for tools that can move, change or export CUI, decide in policy which invocations need human approval, configure the host to enforce that, and document it in the SSP. A “read-only” annotation from an untrusted server is not evidence that a tool is read-only.

Logging

The tools page says clients should Log tool usage for audit purposes, and the best practices page says to Log elevation events (scope requested, granted subset) with correlation IDs. Requirement 3.3.1 is to Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity. Analysis: an assessor will want to follow one action from the user, through the agent host and MCP server, to the back-end system. Correlation IDs and per-user tokens make that possible.

What government has said about agents and MCP

We found no DoD CIO, CMMC or FedRAMP page that names MCP. NIST’s CAISI issued a request for information on agent security in January 2026, asking about topics including methods to constrain and monitor the extent of agent access in the deployment environment; NIST says it will inform future work on voluntary guidelines and best practices related to AI agent security.

The NCCoE’s February 2026 draft concept paper on agent identity and authorization does name the protocol: Model Context Protocol (MCP) is a protocol that enables AI models and agentic systems to discover, access, and interact with external tools and data. It is a draft project description, not a requirement.

On the program itself, DoD CIO says the program is paused in Phase 1 and may only require self-assessments at two levels, and that the pause does not eliminate the requirement for companies to protect information in accordance with DFARS clause 252.204-7012. The SP 800-171 requirements apply to MCP deployments that handle CUI whether or not a CMMC assessment is scheduled.

Questions

Is an MCP server in CMMC scope? If it processes, stores or transmits CUI, it is a CUI Asset under § 170.19 and is assessed against the Level 2 requirements. The rule does not name MCP; the scoping test is the same as for any system.

Does following the MCP spec satisfy SP 800-171? No. The spec says MCP cannot enforce its security principles at the protocol level, and several of its controls (authorization, human in the loop) are optional or SHOULD-level. Use it as implementation guidance and map each control to the SP 800-171 requirement in your SSP.

Can a local (stdio) MCP server skip authentication? The MCP spec says stdio implementations should take credentials from the environment instead of following its OAuth flow. SP 800-171 still requires identifying and authenticating processes acting on behalf of users, so document how the host and the credentials it uses meet 3.5.1 and 3.5.2.

Has DoD published MCP guidance for contractors? As of 25 October 2026 we found no DoD CIO, CMMC or FedRAMP page that names MCP.