Topic starter
16/01/2026 12:34 pm
TL;DR: Unosecur argues that Model Context Protocol standardises how AI agents connect to tools and live enterprise data, but that same connectivity turns authorised agents into operational actors with persistent permissions, transitive trust, and production-speed access paths. The security issue is identity governance, not model behaviour, because valid access can still drive harmful actions.
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 agents are given broad permissions?
A: Broad permissions turn one compromised or manipulated agent into a wide-blast-radius identity.
Q: Why do MCP-based agents create more risk than ordinary API integrations?
A: Because the agent is choosing actions, chaining tools, and preserving context across steps.
Q: How do security teams know whether MCP server governance is working?
A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact.
Practitioner guidance
- Inventory all MCP-connected agent identities Map every agent, server, token, and delegated access path that can reach production tools or data, then classify which identities are persistent versus ephemeral.
- Reduce transitive trust across tool chains Trace how authority moves from one MCP server or workflow step to the next, and remove implied trust where one system inherits access it should not possess.
- Shorten credential and token lifetimes Set explicit expiry, revocation, and re-issue rules for agent credentials so production access does not persist longer than the task or workflow requires.
Bottom line: MCP changes the security problem by turning AI agents into operational identities that can act across live systems with legitimate access.
What's in the full article
Unosecur's full blog post covers the operational detail this post intentionally leaves for the source:
- How MCP clients and servers exchange tool descriptions, requests, and structured responses in production workflows
- Examples of common MCP abuse patterns such as prompt injection, tool poisoning, and permission chaining
- The distinction between sandbox use cases and production deployments where live credentials and real data are in scope
- The article's own view on why identity-first controls need to sit alongside agentic AI adoption
👉 Read Unosecur's analysis of Model Context Protocol and AI agent identity risk →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
07/10/2026 6:01 pm
Model Context Protocol is an identity expansion event: MCP does not merely connect AI systems to tools. It expands the set of actors that can act inside the enterprise, which means identity governance now has to account for agent behaviour, delegated authority, and cross-system continuity. The field should stop treating MCP as an integration pattern and start treating it as an access architecture.
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: What should organisations do when MCP agents start crossing multiple systems?
A: They should treat cross-system reach as an identity design problem, not just an integration milestone. That means assigning ownership, reviewing delegated access paths, and deciding which workflows deserve persistent authority versus just-in-time access. If the agent can touch production systems, accountability and offboarding discipline must exist before scale.
👉 Read our full editorial: Model Context Protocol turns AI agents into an identity risk