Notifications
Clear all
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.
NHIMG editorial — based on content published by Pomerium: Agentic Access Management for Model Context Protocol (MCP) Workflows
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
Q: How should security teams govern AI agents that can call tools through MCP?
A: Security teams should govern MCP-connected agents as runtime actors, not as passive applications.
Q: Why do AI agents create more risk than traditional automation in IAM programmes?
A: AI agents create more risk because they can infer intent and choose actions dynamically instead of following a fixed workflow.
Q: What do security teams get wrong about logging agent activity?
A: Teams often assume that detailed logs equal control.
Practitioner guidance
- Map every MCP-connected agent to a named business owner and policy scope Identify who is accountable for the agent, which systems it can reach, and which actions require explicit approval before execution begins.
- Enforce per-action authorisation at the model-to-tool boundary Do not rely on broad service account entitlements alone.
- Separate observability from approval Send prompt, tool, and system-level events into a central log pipeline, but ensure the policy engine can stop or narrow the action before downstream systems are touched.
What's in the full article
Pomerium's full blog post covers the operational detail this post intentionally leaves for the source:
- A practical breakdown of how its enforcement point evaluates prompts, models, and actions in sequence
- The vendor's examples of how identity-based per-action policy is applied across internal tools and SaaS systems
- Implementation detail on audit logging, SIEM integration, and policy enforcement across workflows
- The source article's product framing for agentic access management inside MCP-driven environments
👉 Read Pomerium's analysis of agentic access management for MCP workflows →
MCP workflows and agentic access management: are controls keeping up?
Explore further
25/06/2026 6:24 am
Agentic access management is the natural governance layer for MCP, not a feature add-on. MCP creates an execution model where models can act, not just advise, and that changes the identity problem from authentication to runtime authorisation. Existing IAM programmes were designed for stable principals and predictable requests, so the relevant question is no longer whether the model can connect, but whether it can be governed at the moment it decides. Practitioners should treat MCP as a control-plane issue, not a plugin problem.
A few things that frame the scale:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who should be accountable when an AI agent takes an unauthorized action?
A: Accountability should sit with the business or technical owner who approved the agent’s scope, the team that defined the policy, and the platform that enforced it. If no one can answer who allowed the action, then the governance model is incomplete. In agentic systems, ownership must be explicit before deployment, not reconstructed after an incident.
👉 Read our full editorial: Agentic access management for MCP workflows needs identity controls
