TL;DR: The NSA’s first MCP security guidance splits into nine controls across identity, network and application layers, and no single product covers all of them, according to NetFoundry. The practical implication is that MCP governance has to assign named owners for reachability, logging, validation, sandboxing and patching rather than assuming the protocol itself provides security.
At a glance
What this is: The NSA’s first MCP security guidance says production deployments need nine controls spread across identity, network and application layers because MCP itself enforces very little security.
Why it matters: IAM, NHI and platform teams need a clear control split for MCP because reachability, logging, signing, validation and patching land on different owners and cannot be handled by one layer alone.
Context
MCP is a tool-access protocol for AI-driven automation, but its security model is intentionally thin: authentication can be optional, transport security does not equal message integrity, and the protocol does not enforce comprehensive policy on its own.
That leaves organisations with a governance split. Identity, network and application controls all matter, and the first question is not whether to secure MCP, but which control owner is responsible for each boundary and failure mode.
The control problem is especially visible in production environments where agents reach internal tools and services. Without explicit ownership, the protocol becomes a coordination problem between platform, application and security teams rather than a single security stack.
Key questions
Q: What breaks when MCP security is treated as a single control layer?
A: Teams overestimate runtime coverage and miss the risks that sit above it. That usually leads to weak assumptions about intent validation, context leakage, and shadow endpoints, while the real control gaps remain unowned across identity, platform, and agent operations.
Q: Why do MCP tools create higher risk when they can reach internal services or private network ranges?
A: MCP tools become dangerous when fetch or write actions can be redirected into internal targets, because an agent can be tricked into making requests the operator never intended. Without allow-lists and private range blocking, SSRF can expose metadata endpoints, internal APIs, or privileged backends. The result is data exposure, unauthorized actions, and harder incident containment.
Q: How do you know if MCP security controls are actually working?
A: You know MCP controls are working when untrusted endpoints are blocked, privileged tool calls are minimal, and audit logs show only approved commands and data flows. If teams cannot reconstruct which server asked for what, or if secrets appear in configuration files, the control set is not operating as intended.
Q: What is the difference between MCP network controls and MCP application controls?
A: Network controls decide who can connect, where the server is reachable from, and whether the public internet can see it. Application controls decide what happens after a connection exists, including parameter validation, output handling, sandboxing and message integrity. Both are needed because MCP does not cover both layers itself.
Technical breakdown
Why MCP’s built-in security model is incomplete
MCP was designed to connect agents to tools and data sources, not to provide a full security boundary. That means the protocol can carry requests, but it does not by itself guarantee who may connect, whether the message contents were altered, or whether the target server should have been reachable in the first place. In practice, organisations must layer controls around the protocol rather than expecting the protocol to enforce policy. That is why the NSA’s guidance breaks the problem into identity, network and application controls instead of treating MCP as a self-protecting interface.
Practical implication: Treat MCP as an integration fabric that still needs external access control, integrity protection and operational oversight.
How identity and network controls shape MCP reachability
The identity and network layers decide whether an agent or server can talk at all. Cryptographic endpoint identity, default-deny reachability and segmentation by identity create a policy boundary before any application logic runs. This matters because MCP servers often need to be exposed to internal tooling while remaining inaccessible from the public internet. When those controls are enforced at the connector or gateway, the security model shifts from trusting network location to verifying identity and policy on each connection attempt. That is a different control plane from payload inspection or prompt filtering.
Practical implication: Enforce connectivity policy before application execution so MCP servers are never broadly reachable by default.
Why application-layer MCP controls remain necessary
Application controls address what happens after a connection is established. Parameter validation, output filtering, sandboxing and message signing all sit above transport and identity controls because they inspect the semantics of the interaction, not just the path it takes. This is where prompt injection, tool poisoning, chained execution and unsafe outputs are contained. The key point is that these controls cannot be collapsed into network policy alone: a denied network path prevents exposure, but a permitted path still needs content-aware enforcement and secure execution handling. The protocol’s security story is therefore layered by design. Read OWASP Agentic Applications Top 10.
Practical implication: Keep validation, sandboxing and output controls in the application stack even when network policy is already enforced.
Threat narrative
Attacker objective: The attacker’s objective is to reach MCP-enabled tools or servers and use that access to trigger uncontrolled actions, data exposure or internal service abuse.
- Entry begins when an MCP server is exposed through weak or missing boundary controls, allowing an agent or external path to reach a tool that should not have been available.
- Credential or trust abuse follows when the connection is accepted without strong endpoint identity, message integrity checks or logging that would expose misuse.
- Escalation occurs when the connected tool can execute chained actions, access internal services or consume unvalidated parameters without sandboxing or output constraints.
- Impact is the unintended execution of tool actions, exposure of internal services, or data loss through a reachable MCP server that was assumed to be protected by the protocol itself.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity, network and application controls are not interchangeable in MCP governance. The NSA’s guidance is useful precisely because it separates reachability from integrity and from content handling. A team that treats gateway policy as a substitute for validation or sandboxing is still leaving the highest-risk execution paths inside the application layer ungoverned. The practical conclusion is that MCP programmes need control ownership by layer, not a single security label.
Default-deny reachability is the core boundary for MCP servers. When MCP servers are hidden behind connectors and disconnected from public exposure, the first stage of abuse becomes much harder. That does not remove the need for application hardening, but it changes the baseline from ambient network trust to explicit identity-based reachability. Practitioners should treat this as a governance boundary, not just a deployment preference.
Signed transport is not the same as trusted content. The protocol can move messages securely while still carrying malformed parameters, poisoned outputs or unsafe tool instructions. That is why the NSA’s split between transport identity and payload-level validation matters. The implication for the field is that MCP security should stop being framed as a single proxy problem and be governed as a layered execution model.
Open MCP exposure creates an identity problem before it becomes an application problem. If a server is internet-reachable, the organisation has already lost the ability to make access a policy decision. The breach pattern here is not just insecure configuration; it is uncontrolled reachability that turns every downstream control into damage limitation. Security teams should recognise public MCP exposure as a governance failure in the control plane, not a minor deployment issue.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
Identity-based boundary design will become the default way to talk about MCP security. Teams that can only describe MCP in terms of prompts and tools will miss the more important operational question: who is allowed to reach which server, under what policy, and with what evidence trail. That framing matters because MCP control failures start at access time, not after the tool has already executed.
Public exposure is the wrong operating model for MCP. Once servers are hidden behind enforced connectors and default-deny reachability, the control conversation shifts from perimeter exposure to governed access. That is the model practitioners should prepare for across both commercial and classified environments.
The practical pressure point is ownership. If identity, logging, validation and patching all live with different teams, MCP will be governed like a collection of features instead of a security boundary. That creates an execution boundary gap, where the organisation protects the transport path but leaves the actual action path fragmented and under-assigned.
For practitioners
- Assign each MCP control to a named owner Map identity, network and application controls separately so no recommendation is left without an accountable team or tool.
- Enforce identity-based reachability for every MCP server Place MCP servers behind policy enforcement that denies all connections by default and only permits explicitly approved identities.
- Keep MCP servers off the public internet Remove inbound exposure, public DNS records and unauthenticated entry paths so external scanning finds no directly reachable server.
- Separate content controls from connectivity controls Use application validation, output filtering and sandboxing for payload safety, while using network policy for access and segmentation.
- Log MCP access events into the SIEM Record which identity reached which service, then correlate those access events with invocation parameters and output hashes from the application layer.
Key takeaways
- MCP security is not a single control problem because identity, network and application risks sit in different layers.
- The NSA’s guidance makes clear that no one product covers all nine recommendations, so ownership has to be explicit.
- For practitioners, the key decision is which controls govern access, which govern content, and which teams are accountable for each.
Related NHI Mgmt Group resources: MCP Security Guide · NHI Lifecycle Management Guide · Smithery.ai MCP hosting breach 2025 · Identity Security Programme Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP agents rely on delegated access and identity-bound tool use, which this guidance constrains. |
| Recommendation — Apply ASI03 to separate agent reachability from application execution and privilege assignment. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | MCP depends on endpoint identity and authenticated connections rather than implicit trust. |
| Recommendation — Enforce authenticated endpoint identity and remove unauthenticated MCP access paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about who can reach which MCP server under what policy. |
| Recommendation — Use PR.AA-05 to govern MCP reachability and entitlements by identity and policy. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust principles — Zero Trust principles | The guidance maps directly to default-deny connectivity and verified access for MCP servers. |
| Recommendation — Apply Zero Trust principles so MCP servers are only reachable after explicit policy approval. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Open MCP reachability and weak trust boundaries enable credential and service movement abuse. |
| Recommendation — Map exposed MCP paths to TA0006 and TA0008 to prioritise reachability reduction and access logging. | ||
Key terms
- Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
- Default-Deny Reachability: Default-deny reachability means a service is unreachable unless policy explicitly allows the connection. For MCP, this is the difference between a server being broadly exposed to the network and only being reachable by approved identities through controlled connectors.
- Identity-Driven Segmentation: Identity-driven segmentation is a control model that allows or denies communication based on verified identity rather than only on subnet, firewall, or VLAN placement. It is especially useful in operational environments where topology changes frequently and network paths no longer describe trust accurately.
- Payload-Level Integrity: Payload-level integrity is the assurance that a message has not been altered in transit or by an intermediary. MCP transport security does not provide this by itself, so signing and verification at the application layer are needed when message content must be trusted.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org