Topic starter
17/08/2026 5:40 pm
TL;DR: Unosecur argues that Model Context Protocol turns AI agents into operational actors that make real identity and access decisions, so trusted access, persistent credentials, and broad permissions can create unsafe outcomes even when every action looks legitimate. MCP is therefore an identity expansion problem, not just an AI integration layer.
Editorial analysis by NHI Mgmt Group, based on content published by Unosecur: “Identity and Access Risks for MCP & Agentic AI”.
Key questions
Q: What breaks when MCP-enabled agents are given valid credentials but no runtime governance?
A: The access model breaks down because the agent can still chain legitimate tool calls into harmful outcomes.
Q: Why do MCP workflows increase risk when credentials are entered during setup?
A: Because the credential becomes part of a delegated tool path rather than a one-time login event.
Q: What are the signs that an MCP integration is starting to drift out of policy?
A: Warning signs include new servers appearing outside the approved registry, changes in tool descriptions after approval, repeated anomalous tool calls, and agents reaching data or systems beyond their stated scope.
Practitioner guidance
- Map every MCP server to its consuming identities Inventory which agents, service accounts, and tokens can reach each MCP server, then document the business systems each one can influence.
- Constrain permission chaining across tools Review where a single agent can move from one system to another using the same credential or trust context.
- Track credential lifecycles for agentic workflows Tie agent tokens, API keys, and delegated access to explicit owners, expiry rules, and offboarding triggers.
Bottom line: MCP matters because it changes AI from a request layer into an execution layer, which turns ordinary access decisions into identity governance decisions.
What's in the full article
Unosecur's full blog covers the operational detail this post intentionally leaves for the source:
- The article's fuller explanation of why MCP makes AI agents look like operational actors inside enterprise systems
- The vendor's breakdown of common MCP abuse patterns, including prompt injection and tool poisoning
- The security leader framing around continuous discovery, privilege path analysis, and runtime monitoring
- The article's internal FAQ section on MCP, perimeter security, and high-value server risk
👉 Read Unosecur's analysis of MCP and identity risk in agentic AI →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
17/08/2026 5:40 pm
MCP is an identity expansion event, not an AI novelty. The article is right to frame MCP as a shift from passive assistance to active execution. Once agents can query systems, trigger workflows, and keep context across steps, the governance question becomes who is allowed to act and under what conditions. That places MCP squarely in the identity domain, where permissions, trust, and lifecycle controls determine whether the protocol is safe enough for production use.
A few things that frame the scale:
- 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.
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: How should identity teams govern MCP compared with conventional API integrations?
A: MCP needs runtime identity governance because it is not just a transport layer for requests. Conventional integrations can often be reviewed at design time, but agentic workflows require control over context, delegated authority, and the lifecycle of the credentials that power each tool path.
👉 Read our full editorial: MCP turns AI agents into identity and access decisions