TL;DR: MCP is moving agent actions into internal systems, and the current security model was not built for that shift, according to Pomerium’s discussion with RedMonk analysts. Real-time, request-level authorization is now the control point that determines whether human, service, and agent identities can be governed safely.
At a glance
What this is: Pomerium’s discussion with RedMonk argues that MCP turns agent access into an internal-system governance problem, with request-level authorization now the deciding control.
Why it matters: IAM and PAM teams need to rethink how access is checked when the requester may be a human, service account or agent acting through MCP.
Context
Model Context Protocol links LLMs to internal systems so they can do work, not just answer questions. That changes the identity problem from authentication at the edge to authorization at the moment of each request, because the actor can be a human, service account, or agent using the same path.
The governance gap is not that MCP exists, but that older access models assume stable sessions, predictable request patterns and coarse authorization boundaries. For agentic access, the practical question is whether access is decided in real time with enough context to stop overreach before the action runs.
Key questions
Q: What breaks when MCP relies on sessions instead of request-level authorization?
A: Session-based authentication breaks because MCP requests can be generated dynamically by nonhuman identities and routed through tools or intermediaries that were never part of the original trust decision. A session can hide who is actually acting, while request-level authorization forces the server to verify the client, audience and operation each time.
Q: Why does MCP increase the importance of runtime authorisation for agentic AI?
A: MCP increases the importance of runtime authorisation because it turns tool use into a dynamic, session-based decision path. If a model can choose when to call tools and which context to use, static approvals lose precision. Runtime controls keep the agent within the task scope that was actually intended, not the one assumed at design time.
Q: What are the signs that MCP-based agent access is not being governed effectively?
A: Poor governance usually shows up as unclear permissions, inconsistent tool approvals, and weak auditability across agent actions. If teams cannot trace what an agent accessed, changed, or disclosed, they do not have meaningful control. Another warning sign is when security can describe the model but not the boundary between allowed automation and unsafe escalation.
Q: How should teams govern agent access when both CLI and MCP are available?
A: Govern them separately, because they expose different execution patterns. CLI is usually easier to inventory, validate, and retire, while MCP can preserve state across multiple actions and therefore needs tighter session controls. Access reviews should include interface type, exposed tools, and how state is retained or discarded.
Technical breakdown
Why session-based access breaks for MCP requests
MCP gives models a path into internal tools and data sources, which means the request itself becomes the security decision point. Traditional session controls are too coarse when a single prompt can trigger multiple actions across systems, because the risk is not just login success but what the agent is allowed to do after authentication. OAuth and VPN-style assumptions do not map cleanly to this pattern because they were not designed for per-request authorisation across mixed identity types. The architectural shift is from trusted sessions to continuously evaluated requests.
Practical implication: Treat each MCP call as an authorisation event, not a continuation of an already trusted session.
Why context-aware authorization matters for agentic access
Context-aware authorization means the decision can incorporate the requesting identity, the target system, the action, and any policy signals available at runtime. That matters because agents do not behave like static service accounts and do not follow human interaction patterns either. If the policy layer cannot distinguish a harmless read from a high-risk write, then MCP becomes an over-permissioned shortcut into core business systems. The control point shifts from who authenticated to what is being asked right now.
Practical implication: Use runtime policy decisions that inspect identity, action and target resource before allowing MCP execution.
How auditability changes when humans, services and agents share access paths
When different actor types share a tool path, the audit problem is not only logging but attribution. Teams need to know which identity initiated an action, what it touched, and whether the action was executed by a person, a service, or an agent. Without that traceability, incident review and access governance both degrade because the organisation cannot reconstruct intent or responsibility. In agentic environments, audit trails become part of the control surface, not a post-event convenience.
Practical implication: Record identity, request context and resulting action for every MCP transaction so reviews can distinguish human, service and agent behaviour.
Threat narrative
Attacker objective: The objective is to abuse agent-mediated access to perform unauthorised internal actions while appearing to operate through legitimate workflows.
- Entry occurs when an LLM connects to MCP and receives a path into internal systems that can execute real actions rather than only return text.
- Credential or authorisation weakness appears when broad permissions or session assumptions let the agent reuse access that was never scoped for per-request decisions.
- Impact follows when the agent can pull reports, edit issues or move deals inside business systems without sufficiently granular runtime checks.
Breaches seen in the wild
- iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
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
Request-level authorisation is the new control boundary for MCP. Once models can trigger internal actions, the old distinction between login and access decision stops being sufficient. The practical governance shift is that authorisation must happen at the moment of each request, with enough context to evaluate identity, action and target system together.
Session-centric access models create an assumption collapse for agentic workflows. They were designed for users or services whose intent is relatively stable across a session. That assumption fails when an agent can generate multiple different requests inside one interaction, so the implication is that governance has to move from session trust to action trust.
Agentic access management is emerging as a distinct governance problem, not a UI problem. The article shows that MCP is not just a new integration pattern. It creates a control plane issue across human, service and agent identities, which means IAM, PAM and application teams now share responsibility for the same request path.
Identity-aware logging becomes part of policy enforcement, not after-the-fact evidence. If teams cannot tell who initiated a request and what the agent did with it, they cannot govern access meaningfully. The result is that observability, authorisation and accountability need to be designed together, with traceability built into the access decision.
MCP request governance: the decisive risk is not model intelligence but the collapse of static access assumptions under runtime tool use. That makes fine-grained authorisation the field’s immediate design constraint. Practitioners should treat MCP as a governance boundary that requires per-request controls rather than broader trust in the surrounding session.
What this signals
MCP request governance: agentic access changes the control point from authentication to per-action authorisation. That means programmes built around coarse session trust will miss the real decision boundary, especially where tools can both read and modify internal systems.
Identity governance teams should expect more overlap between IAM, PAM and application security as MCP-style access paths spread. The practical question is no longer whether a model can connect to a tool, but whether the request can be explained, authorised and attributed in real time.
For practitioners
- Implement per-request authorization for MCP paths Check every agent-initiated action against policy before it reaches the target system, rather than inheriting trust from the login session.
- Separate human, service and agent identities Assign distinct identity treatment to each actor type so the policy engine can evaluate who initiated the request and what privileges apply.
- Limit agent access to narrow action scopes Constrain what MCP-connected agents can read, write or invoke, and remove broad permissions that are acceptable only for human workflows.
- Log request context and resulting action Capture the initiating identity, requested tool, resource and outcome so investigations can reconstruct agent behaviour without guesswork.
Key takeaways
- MCP pushes identity governance from session trust toward per-request control because agents can now act inside internal systems.
- The article’s core risk is over-broad authorisation, especially where a single interaction can trigger multiple actions across different business tools.
- Practitioners need distinct identity handling, runtime policy and auditable request traces if they want to govern human, service and agent access safely.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on agents using internal access paths with insufficient runtime scoping. |
| Recommendation — Apply ASI03 to constrain agent identity and privilege before MCP requests reach internal tools. | ||
| NIST AI RMF | MANAGE — AI Risk Management and Governance | The piece argues for runtime governance over agent-initiated actions and accountability. |
| Recommendation — Use MANAGE to enforce governance, oversight and accountability for agent-mediated access decisions. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Per-request authorization is the central control theme in the article. |
| Recommendation — Apply PR.AA-05 to validate every MCP request against current permissions and entitlements. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Agent-connected access paths can become overprivileged when broad permissions are reused. |
| Recommendation — Reduce overprivileged agent access by tightening scopes on every MCP-connected identity. | ||
Key terms
- Agentic Access: Agentic access is delegated system access granted to an AI agent or autonomous workflow so it can perform defined tasks across tools and data sources. It differs from human access because the actor can execute continuously, combine actions quickly, and amplify mistakes at scale.
- 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.
- Request-level Authorization: Request-level authorization means access is decided for each request rather than once at login or network entry. It lets operators scope permissions by route, method, and identity, which is far more precise than broad network access and better suited to distributed systems and NHIs.
- Identity-Aware Logging: Logging that connects AI activity back to the human, service account, or agent that performed it. This is essential when data access, model calls, and approval states must be traced across cloud, SaaS, and internal systems.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org