TL;DR: The Model Context Protocol standardises how AI models connect to external tools, replacing custom integrations with a universal client-server layer that can send documents, query databases, and update records in real time, according to Youtrust. That interoperability makes agentic AI practical, but it also shifts security focus to authorisation scoping, data exposure limits, and compliance controls.
At a glance
What this is: Youtrust’s guide says MCP is becoming the standard connection layer between AI models and business systems, with security determined by how tightly servers scope tools and data.
Why it matters: It matters because MCP turns AI assistants into action-taking systems, so IAM, NHI, and AI governance teams must treat tool access, write permissions, and exposed data as control points rather than implementation details.
Context
Model Context Protocol is a standard way for an AI assistant to discover and use external tools, data sources, and services through a defined client-server interface. The security question is not whether the model can act, but which actions it can perform, on which data, and under what authorisation rules.
For identity and access teams, MCP matters because it moves AI systems closer to the operational plane where credentials, approvals, and data permissions already live. That creates a genuine governance intersection with NHI, delegated access, and enterprise controls around read and write scope.
The article frames MCP as a simplification layer, but simplification does not remove governance responsibility. In practice, the more universal the connection layer becomes, the more important consistent policy design becomes across environments and tool providers.
Key questions
Q: How should security teams govern MCP tool access in enterprise environments?
A: Security teams should bind MCP tool access to enterprise identities, entitlements, and lifecycle state before a request reaches production tools. A gateway can enforce policy at the edge, but governance only exists when the identity system knows who is calling, what they are allowed to do, and whether approval or offboarding has already occurred.
Q: Why do AI assistants and MCP servers create new access-control risks?
A: They are not just productivity tools. Many can read files, call APIs, access databases, and interact with external services, which means they operate inside the trust boundary normally reserved for approved software and users. Without scoped permissions and enforcement, they can become a fast path to secrets exposure and lateral movement.
Q: What breaks when MCP servers are over-permissioned?
A: When MCP servers are over-permissioned, the agent inherits broader access than its task needs, and a compromise in that layer can reach every connected system. The result is excessive blast radius, weak auditability, and poor separation between legitimate automation and abuse. Access scope should be narrowly segmented and revocable by workflow.
Q: How do organisations decide whether MCP is safe for regulated workflows?
A: They should evaluate whether the deployment can prove least-privilege access, dataset-level scoping, auditability, and compliance with the regulations that apply to the underlying data. If those controls are absent, the workflow is not yet governed enough for regulated use.
Technical breakdown
How MCP client-server discovery changes control design
MCP uses a host, client, and server pattern. The host is the AI application, the client packages structured requests, and the server exposes tools and resources. Unlike fixed API integrations, MCP lets the client discover capabilities at runtime, which is convenient but shifts trust to server-side scoping and capability exposure. That means the security boundary is not the model itself, but the set of tools and datasets the server advertises and permits.
Practical implication: treat MCP server registration and capability exposure as access-management decisions, not just integration setup.
Why authorisation scoping is the core MCP security control
MCP security depends on narrowing what the server is allowed to do. A properly configured server can expose read-only queries, block writes or deletions, and limit access to specific datasets. That is materially different from giving an AI assistant broad API credentials and hoping prompt discipline will constrain behaviour. In governance terms, MCP makes privilege design explicit: the server, not the model prompt, should define the boundary of permissible action.
Practical implication: separate read, write, and destructive functions in MCP server policy and review them as privileged access.
MCP and NHI credential exposure risk in agentic workflows
When MCP connects AI assistants to live systems, the workflow often relies on tokens, service credentials, or delegated access behind the server. That makes the MCP server part of the NHI estate, even if the assistant appears to be the visible actor. The risk is not only unauthorised model action, but also accidental overexposure of credentials, datasets, or transaction paths through the integration layer. This is where AI governance and NHI governance meet.
Practical implication: inventory MCP-connected credentials as NHIs and apply lifecycle controls, rotation, and offboarding discipline.
Threat narrative
Attacker objective: The objective is to abuse the AI-to-tool connection layer to reach data, actions, or credentials that should have remained outside the assistant's scope.
- Entry occurs when an AI assistant is connected to an MCP server that exposes business tools and data sources through delegated credentials.
- Escalation happens if the server allows broader tool access than the task requires, turning a prompt-driven request into write, delete, or data retrieval capability.
- Impact is the misuse or overexposure of business actions, records, or credentials through an integration that was meant to be constrained by server policy.
Breaches seen in the wild
- postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.
- 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
MCP creates a new governance layer, not just an integration standard. The important change is not that AI can now call tools. The important change is that tool exposure becomes a policy decision that must be governed consistently across identities, workloads, and AI assistants. Organisations that treat MCP as a developer convenience will miss that it effectively centralises privilege design for agentic workflows.
MCP turns AI assistants into NHI-adjacent actors when they operate through delegated credentials. Even when a human triggers the workflow, the actual action is often executed through tokens, service accounts, or server-side permissions. That means NHI governance has to expand from human-created service accounts to AI-mediated access paths, especially where the assistant can read data and trigger writes in the same session.
Authorisation scoping is the decisive control concept here. MCP does not eliminate the need for trust, it makes the trust boundary easier to define if teams enforce it properly. Read-only, write-limited, and dataset-scoped configurations are not implementation details, they are the difference between bounded automation and an AI system that can operationalise excess privilege.
The named concept is MCP privilege brokerage. This is the practice of placing a policy-mediated server between the model and enterprise systems so every action is brokered, bounded, and attributable. That concept will matter as agentic AI moves from experimentation to production because it aligns AI activity with existing access governance rather than bypassing it.
Security teams should expect MCP adoption to surface hidden access sprawl. Any environment that rapidly adds servers, tools, and delegated credentials without a unified inventory will create a new class of shadow AI access. The practical conclusion is that MCP governance has to sit alongside identity governance, not beneath it.
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
MCP privilege brokerage: enterprises should start treating the AI-to-tool boundary as a governed access layer rather than a convenience layer. The operational question is no longer whether an assistant can call a tool, but whether every tool call is policy-brokered, logged, and limited to the minimum scope required.
MCP adoption will expose where identity governance stops at human users and does not extend cleanly to service accounts, tokens, and AI-mediated access paths. That gap matters because the assistant may be the visible actor, but the exposed credentials and server permissions are the real control surface.
For practitioners
- Define MCP server scope as a privilege policy Classify each MCP server by the specific tools, datasets, and write paths it exposes, then approve that scope through access governance.
- Inventory MCP-linked credentials as NHIs Treat tokens, service accounts, and delegated credentials behind MCP integrations as managed non-human identities with owners, rotation, and offboarding.
- Separate read-only and write-capable workflows Create distinct MCP servers or policy profiles for retrieval, transaction initiation, and destructive actions so prompts cannot silently expand privilege.
- Verify compliance before enabling live data access Check that any MCP deployment touching regulated data meets your GDPR, ISO 27001, and sector-specific requirements before production rollout.
Key takeaways
- MCP makes agentic AI operationally useful, but it also shifts the security problem to tool exposure, server policy, and delegated permissions.
- The biggest governance risk is not the model itself, but the access paths and credentials hidden behind the MCP server.
- Teams that want MCP in production need to inventory it as part of IAM and NHI governance, not as a standalone integration choice.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | MCP workflows rely on delegated access and server-side trust, making authentication boundaries central. |
| NHI-05 — Overprivileged NHI | The article's main risk is broad AI-linked access becoming over-permissive through server scope. | |
| NHI-07 — Long-Lived Secrets | MCP integrations often depend on tokens and credentials that can persist longer than the task they support. | |
| Recommendation — Enforce strong authentication and scoped trust for every MCP server and connected credential. Review MCP-connected identities for excess privilege and remove permissions the workflow does not need. Replace persistent secrets in MCP integrations with short-lived credentials wherever possible. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | MCP access depends on managing tokens and other authenticators across AI-linked workflows. |
| Recommendation — Apply authenticator lifecycle controls to rotate, revoke, and constrain MCP credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on how permissions and authorisations govern AI-to-tool access. |
| Recommendation — Use PR.AA-05 to formalise and review MCP entitlements before production use. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The threat pattern involves credential abuse and movement through connected systems. |
| Recommendation — Map MCP abuse scenarios to credential access and lateral movement for detection and hunting. | ||
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.
- MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
- Authorisation Scoping: The practice of limiting what a connected system is allowed to do based on policy, role, dataset, or action type. In MCP deployments, scoping is the control that prevents a general-purpose assistant from becoming a broad privilege conduit.
- Delegated access path: A delegated access path is the chain of identities, tokens, connectors, and approvals that lets one system act through another. It becomes a governance concern when the path outlives the original approval or can be reused for actions beyond the intended business purpose.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners who need to govern delegated access paths. It helps identity and security teams connect access policy to the controls that protect modern automation.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org