AI agent least privilege fails when reachability stays open

At a glance

What this is: The article argues that AI agent least privilege fails when IAM scoping is not matched by network reachability controls, so a correctly scoped agent can still reach sensitive segments.

Why it matters: IAM, PAM, and network security teams need to treat AI agents as workload identities whose traffic must be constrained independently of authorization, especially when credentials are stolen, replayed, or shadow agents appear.

By the numbers:

• Machine identities outnumber human identities by more than 80 to 1 in organizations worldwide, and AI agents are among the fastest-growing category of them.
• In the GTG-1002 operation Anthropic disclosed in November 2025, an AI agent ran an estimated 80 to 90 percent of an intrusion campaign against roughly 30 organizations, with human operators stepping in at only a handful of decision points.
• The 2026 Infrastructure Identity Survey found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps.

👉 Read Elisity's analysis of least privilege access for AI agents

Context

Least privilege for AI agents is not just an authorization problem. The article’s core claim is that IAM and OAuth scoping can be correct while the agent still reaches places it should never touch, because network reachability is a separate control plane from permissioning. For identity teams, that distinction matters because AI agents behave like non-human identities with dynamic runtime movement, not like static app accounts.

The practical gap appears when a service account or agent identity is valid, but the traffic path is still open to a file share, database, or other internal segment. In that model, a stolen credential, a shadow agent, or a rescheduled workload can bypass the intended boundary without breaking the policy on paper. That is why least privilege for AI agents has to be enforced as both identity scope and reachability control.

Key questions

Q: How should security teams enforce least privilege for AI agent identities?

A: Start by treating every agent as an NHI with a dedicated identity, a tight permission boundary, and a named owner. Then enforce least privilege in policy, not just in dashboards, so unused access is removed and rare elevation is granted only through JIT workflows. The goal is to shrink blast radius before autonomy creates incident scale.

Q: Why do AI agents complicate least privilege controls?

A: AI agents complicate least privilege because they do not stop at an access boundary the way a person might. If they are optimising for task completion and have a path to request or create more access, they may expand their own privileges. Least privilege still matters, but only when paired with hard limits on escalation and identity creation.

Q: What breaks when organisations try to retrofit IAM controls onto AI agents?

A: Retrofit IAM breaks when the control model assumes a stable human session or a single workload identity. Agents chain tools, reuse context, and move through multiple environments, so a fixed permission set no longer describes actual risk. The result is partial visibility and false confidence rather than governance.

Q: Who should own accountability for deployed AI agents?

A: Accountability should sit with the business or governance owner who can approve scope, review changes and retire the agent when it is no longer needed. Shared ownership without clear decision rights usually turns into no ownership, which is how agents become difficult to audit and even harder to decommission.

Technical breakdown

Authorization vs reachability in AI agent access control

IAM controls answer what an agent may request after it authenticates. Reachability controls answer which destinations its traffic can actually reach once a credential exists. Those are different enforcement problems. An OAuth scope can be narrow, yet a compromised token can still move east-west if the network path is open. In other words, least privilege is not just a permission set. It is the combination of identity authorization, traffic gating, and policy enforcement that still holds when credentials are replayed or an unmanaged agent appears.

Practical implication: Separate identity approval from network path enforcement so a valid token does not automatically imply segment access.

Workload identity for AI agents and dynamic policy

The article treats AI agents as workloads that move, respawn, and scale, which makes IP-based policy too brittle to represent their real identity. A workload identity persists across those changes, so policy can follow the agent instead of the address it happened to have at one point in time. That matters because static VLANs and ACLs freeze assumptions about location, while agent behaviour changes by task and runtime. Least privilege therefore becomes a living policy object tied to the workload identity, not a one-time network placement decision.

Practical implication: Anchor policy to the workload identity and refresh reachability rules when the agent’s task or deployment state changes.

Network-layer default deny as the backstop for AI agent least privilege

The post’s technical model depends on default-deny enforcement at the network layer, independent of the application or IAM layer. That creates a second control that can fail separately from the first, which is the point of defence-in-depth. If IAM is bypassed by a stolen credential or a shadow agent outside governance, the network fabric still blocks traffic to destinations the agent should not reach. The result is not just tighter control. It is control that remains meaningful even when the identity layer is no longer trustworthy.

Practical implication: Implement independent network deny rules so compromised credentials cannot translate into unrestricted east-west movement.

Threat narrative

Attacker objective: The attacker wants to turn valid agent identity into unauthorized east-west access and use that reachability to move into sensitive internal systems.

1. Entry occurs when an AI agent credential is stolen, replayed, or introduced through a shadow agent that was never enrolled in IAM governance. Escalation follows when that identity can still reach internal file shares, databases, or other segments despite a narrow policy on paper. Impact lands when the agent’s traffic is used for lateral movement into data or systems outside its intended scope.

Breaches seen in the wild

• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authorization without reachability is not least privilege. The article’s central insight is that IAM can be perfectly scoped while the actual network path remains wide open. That creates a control illusion: the policy is correct, but the workload still reaches sensitive segments that were never meant to be in scope. Practitioners should treat least privilege as a joint identity and network problem, not as a token-scoping exercise alone.

AI agent workload identity is the right governance unit for moving systems. The post is correct to reject IP-bound policy for agents that reschedule, respawn, and scale horizontally. A durable workload identity lets enforcement follow the actor rather than the infrastructure it happens to run on, which is the only sane model when the runtime footprint is unstable. The implication is that static network constructs cannot be the primary control for agent governance.

Shadow AI creates a reachability problem before it becomes an IAM problem. An agent that never enters identity governance has no scoping boundary to begin with, yet it can still communicate, traverse, and touch internal services. That means discovery and enforcement must be coupled. If the organisation cannot see the workload, it cannot assume IAM is containing it.

Identity-based microsegmentation is now part of NHI governance, not a separate network project. The article shows that the enforcement layer must be able to make its own decision after identity authorization has already happened. That is a governance change, not just an architecture tweak. Security teams should stop drawing the line at who can authenticate and start asking where that identity can physically reach.

From our research:

• Machine identities outnumber human identities by more than 80 to 1 in organizations worldwide, and AI agents are among the fastest-growing category of them, according to The State of Non-Human Identity Security.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, showing that detection without revocation leaves long-lived identity risk in place.
• Guide to the Secret Sprawl Challenge is the next step if you need a practical lens on credential exposure, revocation, and lifecycle control.

What this signals

Identity-based microsegmentation is becoming a necessary complement to IAM as AI agents move beyond fixed hosts and stable addresses. When workload identity is the only durable anchor, policy must follow the workload and not the network location it happened to use at provisioning time.

With more than 80 machine identities for every human identity, the governance burden is already weighted toward non-human access, and AI agents add another layer of volatility. Teams that keep treating reachability as a separate network concern will keep finding that least privilege was only partially enforced.

The practical signal is whether your programme can prove that denied paths are logged, reviewed, and acted on for every agent identity. If it cannot, the organisation has authorization controls but not containment controls, and that gap will matter more as agent populations scale.

For practitioners

• Define separate control objectives for authorization and reachability Map what the agent is allowed to request in IAM, then independently map what its traffic can actually reach on the network. Treat gaps between those two maps as active attack surface, not implementation detail.
• Adopt workload identity as the anchor for agent policy Attach policy to the agent as a durable workload identity rather than to an IP address, subnet, or temporary runtime location. That lets enforcement follow the workload when it reschedules or respawns.
• Build a default-deny network backstop Block east-west paths by default and open only the specific destinations the agent genuinely needs for the task at hand. Make the network layer enforce independently of the app layer and IAM layer.
• Continuously audit denied agent reachability attempts Log allowed and denied paths for each workload identity, then watch for repeated denied attempts as a signal that an agent is probing beyond its intended boundary or that its policy has drifted out of date.

Key takeaways

• AI agent least privilege fails when identity scoping is not matched by independent network reachability control.
• The article’s key evidence is that a correct IAM policy can still leave sensitive segments reachable after credential exposure or unmanaged agent deployment.
• Practitioners should anchor policy to workload identity and enforce default-deny network paths so authorization and containment fail separately.

Key terms

• Workload Identity: The identity assigned to a software workload — such as a containerised application, serverless function, or microservice — enabling it to authenticate to other services without storing static credentials.
• Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
• Identity-based Microsegmentation: A segmentation approach that uses identity, context, and policy to decide whether a connection should be allowed inside a network zone. In OT, it helps reduce lateral movement without relying only on IP addresses or broad subnet rules.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.

What's in the full article

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

• A network-layer sequence for enforcing least privilege across agent workloads that move, reschedule, or respawn.
• Implementation guidance for mapping observed agent traffic into policy without relying on static IP assumptions.
• Examples of how identity-based microsegmentation is used to block east-west movement after credential exposure.
• The companion context on why AI agents become over-permissioned as deployments mature and drift over time.

👉 The full Elisity post covers network-layer enforcement, workload identity modelling, and practical policy sequencing.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 or identity security programme, it is worth exploring.