Topic starter
24/06/2026 9:16 pm
TL;DR: MCP turns LLMs into decision-making agents that can trigger actions across internal systems, which means static identity, policy, and audit models no longer fit, according to Pomerium. The security problem is not the model itself but the trust assumptions around who it acts for, what it can do, and how every action is proven.
Editorial analysis by NHI Mgmt Group, based on content published by Pomerium: “Agentic Access Management for Model Context Protocol (MCP) Workflows”.
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 autonomous agents make traditional IAM audit models less reliable?
A: Traditional audit models assume a human or static system can be tied to a stable access event and reviewed later.
Q: How should security teams govern MCP workflows that touch production CRM data?
A: Treat each workflow as a governed identity surface, not a convenience integration.
Practitioner guidance
- Define per-action policy for MCP-connected agents Map every agent tool invocation to an explicit allow rule, then scope those rules to the smallest meaningful action set rather than a broad application permission.
- Separate agent identity from human identity Assign non-human identities to model-driven workflows and avoid letting a human user token stand in for autonomous execution, especially where the agent can call internal systems.
- Log prompt, tool call, and downstream effect together Correlate the model input, the authorised action, and the resulting system change so investigators can reconstruct what the agent actually did and why it was allowed.
Bottom line: MCP makes agent behaviour a governance issue because models can move from context to action inside internal systems.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 6:24 am
Static identity governance assumptions do not survive agentic execution: Agentic workflows break the premise that identity can be governed once and then reused safely across a session. When a model can decide, select tools, and act without a human approval gate on each step, the control point has to move from login to action. The practical conclusion is that identity governance for MCP is an execution problem, not just an authentication problem.
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.
A question worth separating out:
Q: What is the difference between agentic access management and ordinary IAM?
A: Ordinary IAM is usually built around users, sessions, and broad permissions that change infrequently. Agentic access management is built around non-human identities that make runtime decisions and can act through tools in ways a traditional session model does not fully describe. The difference is the unit of control: agentic access governs each action, not just the account.
👉 Read our full editorial: Agentic access management for MCP workflows needs identity controls