Runtime identity controls for AI agents are replacing perimeter defenses

At a glance

What this is: This is an analysis of why AI agents create a runtime attack surface that perimeter tools cannot reliably see, and why identity-aware controls are needed to govern their actions.

Why it matters: It matters because IAM, PAM, and NHI programmes must account for agents that act with delegated access, chain tools, and move data without human approval or edge-based visibility.

By the numbers:

• 51% of organizations 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.

👉 Read LEVO's analysis of runtime protection for AI agents

Context

AI agent security is becoming a governance problem, not just a tooling problem. Agents do more than generate output. They query APIs, invoke MCP tools, retrieve context, and execute live changes across systems, which means the control question shifts from output quality to runtime authority and traceability.

The gap is that most legacy controls were built for static requests, not autonomous, multi-step activity inside the environment. That makes AI agents relevant to IAM and NHI governance because they behave like continuously acting identities with delegated access, even when the log record still looks human or service-account driven.

Key questions

Q: What breaks when AI agents are managed like ordinary machine identities?

A: What breaks is the assumption that access scope can be fully understood from provisioning data and quarterly review. Ordinary machine identities are repeatable; agents are not. If teams only review entitlements, they miss context shifts, delegated actions, and credential creation inside the session.

Q: Why do AI agents create risk even when they stay within approved permissions?

A: AI agents can be authorised correctly and still produce harmful outcomes because permission is not the same as intent or behavioural appropriateness. If an attacker manipulates the session mid-flight, the agent may keep acting inside scope while exfiltrating data, taking destructive steps, or chaining actions that no human would have approved.

Q: How can security teams tell whether agent access is actually under control?

A: Look for evidence that the team can trace every tool call, secret use, and cross-system action back to a named owner and a valid approval path. If an agent can reach messaging, browser, and infrastructure tools without a revocation chain, access is not truly governed. Control exists only when the runtime can be stopped as fast as it can act.

Q: Should organisations treat AI agents as NHI or as application automation?

A: They should treat them as governed non-human identities with application behaviour. That framing captures the need for identity, scope, lifecycle, and audit controls while still recognising that agents operate through APIs, tools, and workflows. Pure automation language hides the governance gap.

Technical breakdown

Why runtime visibility matters for AI agent identity

AI agents operate inside the application and orchestration layers, where perimeter tools have little or no context. They can call APIs, chain through services, and act through tokens or delegated credentials without crossing a visible network boundary. That creates a gap between who or what was authorised and what actually happened at execution time. In identity terms, the problem is not only access issuance but action provenance. If the agent is using a human OAuth token or a shared service credential, the logging layer can lose the distinction between human intent and machine execution.

Practical implication: teams need runtime control points that bind every action to a verifiable agent identity and scope, not just a login event.

How MCP and internal tool chaining expand the attack surface

MCP and similar tool interfaces let agents move from reasoning to action by invoking external tools, data sources, and business systems. That is useful for automation, but it also enlarges the attack surface because each tool call becomes a new trust decision. A poisoned prompt, manipulated retrieval, or over-permissive connector can redirect the agent into actions that appear legitimate in isolation but are unsafe in sequence. This is where AI agents start to resemble NHI estates: many identities, many permissions, and many opportunities for scope drift if the lifecycle is not governed tightly.

Practical implication: inventory agent tool permissions the same way you inventory NHI entitlements, then constrain each tool to task-scoped access.

Why legacy perimeter controls miss agent-to-agent behaviour

Traditional WAFs, IDS, and edge filters focus on north-south traffic. AI agents often communicate east-west through APIs, shared memory, message brokers, or databases, so the risky behaviour happens inside the perimeter and often in encrypted traffic. Agent-to-agent delegation can therefore look like normal system activity while still enabling lateral movement, data exfiltration, or policy violations. Without a policy layer that understands session state, sensitivity, and delegation context, the security stack cannot separate expected automation from malicious or mis-scoped behaviour.

Practical implication: add east-west policy enforcement and session-aware inspection where agents exchange data or delegate tasks.

Threat narrative

Attacker objective: The attacker wants to turn a trusted AI agent into an internal execution path for unauthorized access, data exfiltration, or operational disruption.

1. Entry occurs when an attacker poisons a prompt, manipulates retrieval, or abuses an over-permissive token to influence an AI agent inside a trusted workflow.
2. Escalation follows when the agent uses delegated access to query APIs, invoke MCP tools, or chain into adjacent systems that were never intended for that task.
3. Impact occurs when the agent leaks sensitive data, performs unauthorized changes, or initiates lateral movement that bypasses perimeter monitoring.

NHI Mgmt Group analysis

Agent runtime has become an identity problem, not just an AI problem. Once an agent can query tools and execute changes on its own, it behaves like a non-human identity with active authority. That means governance has to cover identity, scope, and auditability together, not as separate programmes. The practical conclusion is that IAM and NHI teams need a shared control model for agent execution.

Runtime visibility is the control gap that determines whether agentic AI is governable. Perimeter security can still miss the actual abuse because the agent acts inside the environment, often through encrypted internal traffic. That makes action provenance the decisive control concept. The practical conclusion is that security teams should treat agent execution logs, delegation chains, and tool calls as first-class governance evidence.

Scope drift is the named concept practitioners should watch for in AI agent programmes. Scope drift happens when an agent starts within an approved task boundary and then expands into adjacent data, tools, or actions without a new authorisation decision. It is the same structural problem that NHI programmes face when credentials outlive their intended purpose, but with faster execution and less human oversight. The practical conclusion is to bind agent permissions to task scope and session state.

Legacy alert models are becoming less useful as agent autonomy increases. The more quickly an agent moves, the less value noisy detections provide if they cannot distinguish policy violation from expected machine behaviour. That shifts the market toward context-aware runtime controls and away from broad perimeter alerting. The practical conclusion is to re-evaluate whether your current monitoring stack can explain agent intent, not just volume.

The category is converging on NHI governance for autonomous systems. As agent populations grow, the practical question is no longer whether to secure them, but which identity controls govern them at runtime. That aligns with OWASP Agentic AI guidance and NIST AI Risk Management Framework thinking on governance, mapping, and measurement. The practical conclusion is to extend identity governance into AI operations before agent sprawl becomes unmanageable.

What this signals

AI agent programmes are moving faster than most identity governance models can absorb. The next control gap will not be login approval, but whether the organisation can prove which agent touched which data, through which tool, and under whose delegated authority.

Scope drift: the most useful operating concept for agent governance is the moment a task-bound agent expands into adjacent permissions without a new decision. That is where NHI-style lifecycle discipline, runtime policy, and incident evidence need to meet, especially when paired with the OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework.

Security leaders should expect audit, legal, and compliance teams to ask for agent-level evidence the same way they now ask for privileged access evidence. If the organisation cannot show task boundaries, delegated scope, and action history, the programme will struggle to support scaling decisions.

For practitioners

• Define a separate identity model for AI agents Classify each agent by owner, task scope, delegated credentials, and allowed tools so it is not logged as a generic service account or human proxy.
• Constrain tool use to task-scoped permissions Limit MCP tools, APIs, and internal connectors to the minimum actions required for the workflow, then revoke access when the task or session ends.
• Correlate runtime actions to audit evidence Capture agent-to-resource calls, agent-to-agent delegation, and data access events in a form that supports incident investigation and compliance review.
• Prioritise east-west policy enforcement Place controls where agents actually operate, including application layers, service meshes, and internal data paths, rather than relying on edge inspection alone.
• Test for scope drift under real workloads Run abuse-case simulations that try prompt injection, retrieval manipulation, and connector misuse to see whether the agent can be pushed beyond its approved boundary.

Key takeaways

• AI agents create a runtime identity problem because they can act, chain tools, and change systems without a human in the loop.
• The biggest governance gap is visibility, with many organisations unable to track what their agents accessed or changed.
• Practitioners need task-scoped permissions, action provenance, and east-west enforcement before agent sprawl becomes normalised.

Key terms

• AI Runtime Security: AI runtime security is the set of controls that inspect, constrain, and respond to model behavior while the application is live. It includes detection, masking, policy enforcement, and response shaping, all aimed at reducing the blast radius of unsafe model interactions.
• Scope drift: Scope drift is the gradual mismatch between what an integration was meant to do and what its credentials still allow it to do. It happens when permissions are not revalidated as business needs change, creating hidden over-privilege across SaaS and API-connected systems.
• Action Provenance: Action provenance is the record of who initiated a task, which identity executed it, what tool was used, and what decision was made at runtime. It is essential when delegated work crosses systems because it preserves accountability even when the original request and the final action are separated by many steps.
• East-west traffic: East-west traffic is communication that moves between systems inside an environment rather than entering or leaving it. In microsegmentation programmes, it is the traffic most likely to expose hidden trust assumptions and is therefore the main target for workload-level policy.

What's in the full article

LEVO's full blog covers the operational detail this post intentionally leaves for the source:

• The runtime blocking logic for identity-based, scope-based, and data-sensitive enforcement.
• The sensor and telemetry model used to distinguish agent activity from ordinary application traffic.
• The step-by-step explanation of how the vendor maps agent-to-agent interactions and east-west flows.
• The implementation notes on adaptive enforcement and context-aware policy tuning.

👉 LEVO's full post covers the runtime blocking model, telemetry approach, and enforcement logic in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It helps practitioners connect agentic AI risk to the identity programme that has to govern it.