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.
Expanded Definition
Model Context Protocol, or MCP, is an open protocol that standardises how an AI agent discovers and uses tools, services, and data sources during execution. In NHI security, MCP matters because it expands the agent’s effective trust boundary beyond the model itself and into every connected system that can return context, secrets, or actions. The protocol is still evolving in industry usage, and no single standard governs this yet, so governance teams should treat MCP implementations as programmable access paths rather than simple integration plumbing. That distinction aligns with the control mindset used in NIST Cybersecurity Framework 2.0, which emphasises asset visibility, access control, and continuous oversight.
MCP becomes especially important when an AI agent can invoke internal APIs, query repositories, or retrieve secrets on behalf of a user. The protocol itself does not create trust; it simply defines the transport and interaction pattern. Security design therefore has to answer who may expose an MCP server, which tools it may surface, what data it may return, and whether the agent should receive permanent or just-in-time access. The most common misapplication is treating an MCP server as a harmless connector, which occurs when teams deploy it without scoping tool permissions or reviewing what sensitive data it can expose.
Examples and Use Cases
Implementing MCP rigorously often introduces additional authorisation and inventory overhead, requiring organisations to weigh agent flexibility against tighter control of data, tools, and secrets.
- An internal coding agent uses MCP to read a ticketing system, then creates a deployment change request. The MCP layer must be governed like a privileged integration, not a generic API shortcut.
- A support agent connects to a knowledge base and document store through MCP to answer customer questions. If access scoping is weak, the agent may retrieve records it should never see.
- A security team deploys an MCP server for incident response workflows and ties it to approved tool sets only. That approach mirrors the least-privilege posture discussed in Schneider Electric credentials breach, where exposed credentials can turn one integration into broad compromise.
- An AI assistant requests temporary access to cloud logs through MCP during an active investigation. This is a practical case for JIT access because the agent needs reach only for the duration of the task.
- A data engineering agent uses MCP to query warehouse tables and trigger ETL jobs. Teams should align that design with NIST Cybersecurity Framework 2.0 so discovery, access review, and logging are built in from the start.
One reason MCP is attractive is that it reduces custom glue code between agents and systems, but that convenience can hide how much authority the agent actually receives. In practice, the same protocol can support a read-only knowledge connector or a highly privileged automation path.
Why It Matters in NHI Security
MCP is important because it often becomes the place where NHI risk concentrates: credentials, tool permissions, and data pathways converge in one operational interface. NHIMG research shows that 53% of MCP servers expose credentials through hard-coded values in configuration files, a clear sign that many deployments start with exposure instead of governance. That pattern is especially dangerous when an agent can chain multiple tools together and escalate from low-risk context retrieval to high-impact action.
This is where NHI controls, PAM, RBAC, and Zero Trust Architecture need to be applied to the protocol surface itself, not just to the model. A secure MCP environment should define which agents can reach which servers, what each tool can do, and how secrets are stored, rotated, and monitored. The risk is not theoretical: once an attacker or over-privileged agent gains a valid path through MCP, the blast radius can include source code, cloud consoles, incident systems, and production data. Additional background on the broader NHI exposure problem appears in Schneider Electric credentials breach, which illustrates how credential misuse can translate into operational loss.
Organisations typically encounter MCP as a security problem only after a credential leak, tool abuse, or agent-driven data exposure, at which point the protocol becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 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 Non-Human Identity Top 10 | NHI-02 | Covers secret handling and exposed credentials in NHI-connected systems. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions and least privilege apply directly to MCP tool reach. |
| NIST Zero Trust (SP 800-207) | MCP should operate under continuous verification and explicit trust boundaries. |
Inventory MCP servers, remove hard-coded secrets, and enforce scoped access for every tool.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
