TL;DR: AI agents using MCP can move across enterprise systems at machine speed, but traditional access controls cannot reliably inspect, enforce, or attribute those actions before execution, according to Linx Security. The governance gap is now the point of failure, because policy without runtime enforcement leaves agent actions effectively unreviewable.
At a glance
What this is: This is an analysis of why MCP-based AI agents outgrow traditional access controls, and the key finding is that enforcement must happen before tool calls execute.
Why it matters: IAM, NHI, and human governance teams all have to rethink how accountability, policy evaluation, and auditability work when the actor is an AI agent operating across systems.
By the numbers:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
👉 Read Linx Security's analysis of real-time governance for AI agent actions through MCP
Context
MCP, or Model Context Protocol, makes it easier for AI agents to connect to enterprise tools, but that convenience creates a governance problem for AI agent identity and access control. Existing IAM models were built around users or service accounts performing bounded actions inside a single control plane, not agents chaining tool calls across multiple systems in seconds.
The issue is not visibility alone. It is that policy enforcement, attribution, and auditability have to move earlier in the control path, before the tool call executes. For organisations already trying to govern NHI and autonomous workloads, MCP exposes the gap between access assignment and real-time behavioural control.
This is a typical challenge for teams pushing agentic AI into production: the identity model is present, but the enforcement model is not yet mature enough to follow the actor across systems.
Key questions
Q: How should security teams govern AI agents that can act through MCP?
A: Security teams should govern MCP-connected AI agents with a pre-execution control point, not only with logging and periodic review. The practical requirement is to inspect each tool call, apply policy before execution, and preserve an identity chain that links the request back to the human, workload, or persona behind it.
Q: Why do AI agents complicate existing access control models?
A: AI agents complicate existing access control models because they can chain tool calls across systems at machine speed instead of staying inside one application boundary. That breaks assumptions about predictable authorisation, stable scope, and post-event accountability. Traditional IAM can record that something happened, but it often cannot enforce or explain the decision before the action occurs.
Q: What do security teams get wrong about MCP server governance?
A: Many teams confuse MCP connectivity with meaningful authorisation. A server connection tells you an agent can reach a tool surface, but it does not define which read, write, or administrative actions should be allowed. If governance stops at the server layer, risky tool calls can still execute inside trusted systems.
Q: Who should be accountable when an AI agent takes a harmful action?
A: Accountability should sit with the organisation that defined the agent’s access, the policy that allowed the action, and the team that failed to enforce it at execution time. In practice, the evidence trail must show the requester, the non-human identity, the access profile, and the decision taken, so responsibility is not diluted after the fact.
How it works in practice
Why MCP breaks traditional access control assumptions
Traditional access control assumes a request lands inside one application, where authentication, authorisation, and logging happen in a predictable sequence. MCP changes that by letting an AI agent fan out across many tools in one session, often without a stable, application-local control boundary. That means downstream logs record effects, but not the decision path that produced them. For identity teams, the technical failure is not just missing visibility. It is the absence of a control point that can evaluate the request before the action is committed across multiple systems.
Practical implication: place policy enforcement before execution, not after logs are written.
Tool-level governance versus server-level connectivity
MCP server access tells you an agent can connect, but it does not say what that agent may do once connected. Tool-level governance is more precise because it scopes read, write, and administrative actions individually, rather than treating the server as a single permission bucket. This distinction matters because many governance failures come from broad connection approval followed by uncontrolled action breadth. In agentic environments, the meaningful unit of control is the tool invocation, not the server relationship.
Practical implication: define permissions at the tool level and avoid treating connectivity as equivalent to authorisation.
Identity chain context and auditability for autonomous actions
A useful audit trail for AI agents needs more than a timestamp and an endpoint name. It should preserve the human requester, the non-human identity in use, the access profile that applied, the tool called, and whether the request was approved or denied. Without that chain, investigation becomes guesswork and accountability weakens. This is where AI identity governance starts to converge with NHI governance: the organisation needs a record that ties autonomous action back to the governing identity context, not just the machine that executed it.
Practical implication: require end-to-end identity attribution for every agent-initiated action.
NHI Mgmt Group analysis
Real-time enforcement is now the boundary that identity governance must own. The article is pointing at a structural shift: once AI agents can chain tool calls across systems, after-the-fact logging no longer equals control. NHI and IAM programmes have historically relied on post-event traceability, but agentic execution demands a pre-execution decision point. The practitioner conclusion is that governance must be measured by what is blocked before action, not by what can be reviewed later.
Access assigned at provisioning time is too static for agentic behaviour. Least privilege was designed for actors whose scope can be defined before execution starts. That assumption fails when an agent can choose its next tool call at runtime and move across systems without a human approval gate. The implication is not simply that controls are missing. It is that the provisioning-time model no longer matches the behaviour of the actor being governed.
Unified identity context is becoming the only defensible basis for policy decisions. The strongest point in the article is that the human requester, the non-human identity, the access profile, and the action itself all have to be evaluated together. That is a governance pattern NHIs and autonomous systems are forcing into the open. Practitioners should treat isolated request evaluation as insufficient for any environment where the actor can delegate, chain, or re-enter tools at speed.
MCP gateway governance is really a control-plane response to identity blast radius. The named concept here is identity blast radius: how far a single identity can move once granted tool access. MCP makes that radius wider because one request can touch multiple systems before a human can intervene. The practical conclusion is that identity teams need to model blast radius per tool, per persona, and per action class rather than per connection alone.
Agent coverage has to extend beyond the agent itself to the governance model behind it. The article shows that organisations already understand humans and service accounts, but struggle when the agent becomes the active executor. That gap matters because the same governance logic is being stretched across different actor types with different timing and decision characteristics. The practitioner conclusion is to review whether current identity governance can represent agent behaviour without collapsing into broad, ineffective permission sets.
From our research:
- 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, according to AI Agents: The New Attack Surface report.
- Only 92% of respondents agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to the same SailPoint research.
- For a deeper control-model baseline, OWASP Agentic Applications Top 10 shows how tool misuse, identity abuse, and prompt-driven actions fit together.
What this signals
Identity blast radius is now the right way to think about MCP risk. Once an agent can fan out across multiple systems in one session, the real question is how far one request can travel before governance intervenes. That changes programme design for AI agent identity, NHI oversight, and access review processes alike. Teams that already struggle to see 48% of agent-accessed data will need stronger segmentation, stronger attribution, and a much clearer view of tool-level privilege.
The governance pattern also aligns closely with OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework, because both treat runtime behaviour and accountability as first-class concerns. For practitioners, that means access reviews alone are not enough when the actor can decide and act between reviews.
The operational signal to watch is whether policy evaluation happens before execution or only after logs are generated. If an organisation cannot prove that a tool call was checked in real time, then its AI governance model is still dependent on retrospective investigation rather than active control.
For practitioners
- Insert a pre-execution enforcement layer for MCP traffic Place policy evaluation between the AI platform and downstream tools so requests can be approved or blocked before any action reaches Salesforce, Jira, GitHub, Snowflake, or internal systems.
- Scope permissions at the tool level Separate read, write, and administrative capabilities inside each MCP-connected system instead of approving an entire server connection as if it were a single entitlement.
- Tie every agent action to the full identity chain Record the human requester, the non-human identity in use, the access profile, the tool invoked, and the final decision so investigations can reconstruct who authorised what and why.
- Review whether your audit trail can prove intent Check whether downstream logs show only that something happened, or whether they also show the policy basis for approval or denial before execution.
- Map agent blast radius before expanding access Classify which tools, personas, and departments an agent can touch, then limit combinations that would let one prompt fan out across multiple critical systems.
Key takeaways
- MCP expands AI agent reach faster than legacy access controls can govern it, creating a runtime enforcement gap.
- The evidence is already clear: organisations struggle to audit agent access, and many have no policies in place to govern it consistently.
- Practitioners need pre-execution policy checks, tool-level scoping, and end-to-end identity attribution before agent adoption scales further.
Key terms
- Model Context Protocol: A standard that lets AI systems connect to tools and data sources through a common interface. In identity terms, it widens the action surface of an agent, so governance must focus on what the actor can do at runtime rather than only what it can reach.
- Tool-level governance: A control approach that scopes permissions to individual actions inside a connected system instead of treating the entire connection as one entitlement. For AI agents, it is the difference between allowing access to a platform and allowing specific read, write, or administrative operations within it.
- Identity chain: The linked set of identities and policy artefacts behind an action, usually including a human requester, a non-human identity, and an access profile. It matters because it preserves accountability when the actor making the request is not the same identity that ultimately executes it.
- Identity blast radius: The practical extent of damage or reach a single identity can achieve once it has been granted access. In agentic environments, blast radius grows when one request can fan out across multiple systems, so governance has to limit both scope and combinational privilege.
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 identity security programme, it is worth exploring.
This post draws on content published by Linx Security: Introducing Linx AI Access Control, real-time governance for AI agent actions through MCP. Read the original.
Published by the NHIMG editorial team on 2026-06-10.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org