Runtime identity controls for AI agents are replacing perimeter defenses

At a glance

What this is: LEVO argues that AI agents are outgrowing perimeter defenses because they act inside systems, not just across the edge.

Why it matters: For IAM, PAM, and NHI teams, the practical shift is from authorising access once to governing every agent action at runtime, with identity and scope as the control point.

By the numbers:

• 51% of organisations already deploy AI agents, and 35% more plan to do so within 2 years.
• 82% of AI enterprises report sensitive data access by agents, with 58% saying it happens daily.

Context

AI agents are now acting inside enterprise systems rather than merely producing outputs, which changes the control problem from request filtering to runtime governance. Once agents can query APIs, invoke MCP tools, retrieve context, and execute live changes, the old assumption that edge defenses can see and stop risky behaviour stops holding.

This is an identity problem as much as a security problem. When an agent uses tokens, delegated credentials, or shared access to operate across systems, teams must know what identity is acting, what scope it has, and whether that scope still matches the task.

The article's starting position is not unusual for AI adoption. Many organisations begin by extending human-era controls to machine-speed agents, then discover that the resulting visibility gap is structural rather than incidental.

Key questions

Q: Why do perimeter controls fall short for AI agent security?

A: Perimeter controls fall short because they can observe traffic and still leave action-level decisions ungoverned. An agent can be visible, inspected, and logged while still having overly broad privileges inside the environment. For AI and NHI programmes, the missing layer is continuous authorization that can approve or deny each operation as context changes.

Q: Why do autonomous AI agents increase the risk of data exfiltration in enterprise systems?

A: Autonomous agents increase risk because they can read, write, call tools, and chain steps with credentials attached to their identity. If an attacker hijacks the agent through prompt injection or another control gap, the agent may perform legitimate-looking actions that move sensitive data, transfer money, or delete records. The blast radius depends on what that identity can reach.

Q: What are the signs that agent controls are not working?

A: The clearest warning signs are unexplained tool calls, unexpected privilege use, unreviewed delegated actions, and memory or context changes that alter later decisions. If an agent can move from one system to another without visible policy checks, governance is happening too late. Practitioners should look for behaviour that outpaces their logging and approval boundaries.

Q: How should organisations govern AI agent delegation and session scope?

A: Organisations should define each agent's allowed identities, approved tools, and session boundaries, then enforce those limits at runtime. Delegation chains, subagents, and shared tokens should be treated as explicit trust relationships, not informal workflow details. That approach preserves auditability while limiting blast radius when a session goes wrong.

Technical breakdown

Why perimeter controls miss AI agent activity

Perimeter tools are built to inspect ingress and egress, not the sequence of internal calls that define agent behaviour. AI agents often operate through east-west traffic, chaining API requests, database lookups, message broker events, and tool invocations inside the trusted zone. By the time a WAF or IDS sees anything, the action may already be complete. That makes the real security boundary the execution context, not the network edge. For identity teams, this means authorization has to follow the agent into runtime, where identity, scope, and data sensitivity determine whether a call is allowed.

Practical implication: move control enforcement from the edge to the point where the agent actually executes.

How delegated credentials change the trust model

An AI agent is not just another service account because it can choose when to act, which tools to call, and whether to chain actions across systems. That makes its credential usage dynamic rather than static. If the agent borrows a human OAuth token or a delegated machine token, logs may show a legitimate identity performing an illegitimate action, which breaks audit clarity. In identity terms, the token is no longer enough to establish trust on its own. The system also needs context about the active agent, its task boundary, and the intended data domain.

Practical implication: bind agent identity, task scope, and token use together so audit trails remain trustworthy.

Why agent-to-agent communication needs explicit governance

Agents can interact with other agents, subagents, or downstream services without ever crossing a traditional trust boundary. That creates a new kind of lateral movement, where one compromised agent can trigger another to take actions the first should never have been able to request. These chained behaviours are difficult to detect because each step can look benign in isolation. The control issue is not just whether an agent is authenticated, but whether delegation chains, inherited privileges, and inter-agent messages are explicitly governed. Without that, autonomous workflows become amplification paths for compromise.

Practical implication: govern delegation chains and inter-agent permissions as a distinct control surface.

Threat narrative

Attacker objective: The attacker wants to turn a trusted AI agent into a high-speed execution path for data theft, unauthorised system changes, or workflow disruption.

1. Entry occurs when a poisoned prompt, manipulated retrieval, or over-permissive token gives an AI agent a route into internal tools and APIs.
2. Credential access and abuse follow when the agent uses delegated credentials or shared tokens to perform actions that appear legitimate in logs.
3. Escalation happens when the agent chains additional tools or subagents, extending the original access beyond its intended scope.
4. Impact comes from data exfiltration, unauthorized changes, or operational disruption that security teams only discover after the action has already completed.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
• postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.

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

Runtime identity, not perimeter inspection, is becoming the decisive control plane for AI agents. Once agents act inside internal systems, the boundary between authentication and authorization moves from the edge to execution. That shift matters because the trust decision now has to be made on every action, not just at login. Practitioners should treat runtime enforcement as part of identity governance, not as an overlay from the SOC.

Agentic access creates a distinct form of privilege sprawl that conventional IAM models do not model well. Human-era controls assume a stable subject, a stable session, and a reviewable access trail. Agents collapse those assumptions by acting quickly, in parallel, and sometimes through delegated or inherited credentials. The named concept here is runtime privilege drift: scope that changes during execution faster than governance workflows can follow. Teams need to govern that drift explicitly.

Identity ambiguity is now an audit problem, not just a detection problem. If a human token is used by an agent, the event log can be syntactically correct and still semantically misleading. That weakens incident response, compliance evidence, and ownership attribution. The practitioner conclusion is clear: identity telemetry must distinguish the actor that authorised the session from the system that executed the action.

Agent-to-agent interaction is the new lateral movement surface for autonomous systems. Legacy monitoring thinks in terms of north-south and east-west network traffic, but agent delegation is a control problem about trust inheritance. Once a compromised agent can direct another agent or service, the blast radius expands beyond the original session. Security teams should govern delegation paths as first-class identity relationships.

Alert fatigue becomes a governance failure when the security model cannot separate agentic intent from ambient machine activity. The article correctly points to the noise problem, but the deeper issue is that legacy controls were never calibrated for dynamic, high-frequency decisioning. When the signal model is wrong, the response model fails too. The practical conclusion is to reduce noise by validating identity, scope, and session state at runtime, not by tuning legacy alerts harder.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Runtime privilege drift: AI agents can gain, chain, and discard access faster than human-era review cycles can observe, so governance must shift to issuance-time enforcement. Teams that still rely on periodic review will miss the most important state change, which is whether the agent was allowed to act at the moment it acted.

The strongest programme response is to treat agent identity, tool scope, and session context as one control surface. That is the only way to preserve auditability when machine-speed workflows generate legitimate-looking activity across APIs, MCP tools, and internal services.

According to the 2026 Infrastructure Identity Survey, systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. That gap suggests the control objective is not merely visibility, but active containment of what an agent can reach and when it can reach it.

For practitioners

• Establish runtime identity enforcement Bind every agent action to an approved identity, task scope, and session state so authorization is evaluated at execution time, not only at onboarding.
• Separate human and agent telemetry Tag logs, traces, and audit events so you can distinguish a human session from an AI agent acting with delegated credentials or shared tokens.
• Control delegated tool access Restrict which APIs, MCP tools, and internal workflows each agent can invoke, and revoke any access path that exceeds the task boundary.
• Govern agent-to-agent delegation Treat agent chaining and subagent handoffs as explicit trust relationships that require policy, inventory, and review, not informal workflow behaviour.
• Reduce false-positive noise at the point of execution Use context from identity, data sensitivity, and live session behaviour to suppress benign activity and surface only policy-violating actions.

Key takeaways

• AI agents change the control problem because they act inside trusted systems and can use delegated access to reach APIs, tools, and workflows that perimeter defenses cannot reliably inspect.
• The article points to a real operational gap between agent adoption and governance maturity, with runtime identity and scope emerging as the deciding controls.
• Teams need to govern agent identity, delegation, and session boundaries as first-class security objects, or autonomous actions will outpace review and response processes.

Key terms

• Runtime Identity Security: Runtime Identity Security is the practice of protecting identities while they are actively being used by software, services, devices, or agents. It focuses on controlling authentication, authorization, secrets, and session behavior at execution time, so compromised credentials, excessive privileges, or abnormal identity actions can be detected and contained quickly.
• Agent-to-Agent Delegation: Agent-to-agent delegation is the handoff of work from one AI agent to another, often across different tools or identity contexts. It expands the governance boundary because the original actor no longer controls every action, and inherited permissions can create risk that the first approval never covered.
• Runtime privilege drift: The expansion of effective access during execution, after a task begins, when an autonomous actor finds or uses paths beyond its original intent. This differs from overprovisioning at setup because the risk emerges from behaviour while the work is in flight.
• Identity-Aware Blocking: Identity-aware blocking is an enforcement approach that stops actions based on who or what is acting, what it is trying to do, and whether the current context matches policy. In AI agent environments, it is more precise than network filtering because it evaluates intent and scope alongside traffic.

Deepen your knowledge

The NHI Foundation Level course covers NHI governance, agentic AI identity, and machine identity security through the industry's only accredited NHI security programme. It is designed for practitioners who need to govern autonomous access without losing operational clarity.