TL;DR: MCP standardizes how AI agents connect to tools and data, but Unosecur argues that the real risk is identity-driven: once agents operate in production with real credentials, trusted access, context propagation, and broad permissions can turn legitimate actions into unsafe outcomes. MCP is no longer just an AI integration layer; it is an identity expansion problem.
NHIMG editorial — based on content published by Unosecur: Model Context Protocol (MCP): The Hidden Identity Risk Behind Agentic AI
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
Questions worth separating out
Q: What breaks when MCP agents are given broad permissions?
A: Broad permissions turn one compromised or manipulated agent into a wide-blast-radius identity.
Q: Why do MCP servers create new NHI governance concerns?
A: MCP servers create new NHI governance concerns because they expose application capability to non-human callers through tools and prompts that can be invoked at runtime.
Q: What do security teams get wrong about prompt guardrails?
A: Teams often treat prompt guardrails as if they were authorisation controls, but they are only one layer of defence.
Practitioner guidance
- Discover every MCP-connected identity Inventory clients, servers, service accounts, tokens, and delegated pathways before production rollout.
- Scope tool access by task and time Limit MCP permissions to the minimum set of tools needed for a defined workflow and remove persistence wherever possible.
- Monitor context drift and chained actions Track sequences of tool calls, not just single requests.
What's in the full article
Unosecur's full blog covers the operational detail this post intentionally leaves for the source:
- Concrete examples of MCP risk patterns in production workflows, including tool misuse and transitive trust.
- Operational guidance for deciding where agent credentials should be short-lived versus persistent.
- The article's own framing of how developers, platform teams, and security teams divide responsibility.
- The vendor's examples of where traditional IAM and perimeter controls fail to see legitimate but unsafe agent activity.
👉 Read Unosecur's analysis of MCP and the hidden identity risk behind agentic AI →
MCP server security: what identity teams need to govern now?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
MCP is an identity expansion event, not an AI feature release. The protocol turns AI systems into actors that can request tools, carry context, and execute inside production workflows. That means every deployment decision is also an identity governance decision, because access scope and trust now travel with the agent. Practitioners should stop treating MCP as a connector and start treating it as a governed authority layer.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- 52% of companies can track and audit the data their AI agents access, which means 48% still operate with a complete compliance and investigation blind spot.
A question worth separating out:
Q: How should teams govern AI agents that use MCP?
A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle. The practical control set is familiar: least privilege, secret rotation, access expiration, and auditability across the systems the agent can reach.
👉 Read our full editorial: MCP turns AI agents into identity and access decisions