How do I enforce least privilege access for AI agents? (A network-layer answer)

There is a version of the same conversation I keep having with security architects, often at health systems. It starts with an internal AI agent that was scoped with real care. A data-pipeline agent, say, rolling clinical records into a reporting dashboard. OAuth token narrow. IAM policy naming exactly the two application APIs it was supposed to call. On paper, textbook least privilege.

Then comes the part that makes the room go quiet. The SOC flags the agent’s service account authenticating against a file share it had no business touching. Not the reporting store. A different segment, holding data the agent was never meant to see.

Every version of that conversation lands on the same two sentences. The IAM policy was right. The agent never should have been able to get there. Both are true at once, and that is the whole trap of least privilege access for AI agents. The policy was right. The reachability wasn’t.

If you’re the person who got handed the job of enforcing it, you’ve probably read the IAM explainers already. They’re good on one question and silent on a second one. IAM and OAuth scoping answer what an agent is allowed to ask for. They don’t answer what an agent can actually reach. A stolen credential never asks permission. A shadow agent spun up outside IAM governance was never scoped in the first place. And a carefully scoped agent can still land on a database, a file share, or an OT segment nobody intended, as long as nothing gates its actual traffic.

Least privilege isn’t a new idea. What’s new is applying it to non-human identities that move, respawn, and act at machine speed, thousands of them, most stood up by developers rather than provisioned by IT. This post is about closing the gap between the policy on paper and the traffic on the wire.

What IAM and OAuth scoping do well

Start with credit where it’s due, because the differentiation here falls apart if you caricature the incumbent. IAM scoping, OAuth token lifetimes, permission boundaries, conditional access: these define the set of application actions an agent’s identity is authorized to request, and they’re the right controls for that question. Every serious treatment of this topic, Okta’s identity-101 guidance included, gets this part right, and you should do it.

Give each agent its own identity rather than a shared one. Scope its tokens to the tool calls and API endpoints it needs, keep lifetimes short, and gate anything sensitive behind approval. This is real least privilege AI agents work, and it belongs in every deployment. I broke down the broader agentic-AI threat model in Elisity’s agentic AI security pillar, and the identity layer sits at the center of it.

The trouble starts when the IAM policy becomes the only thing standing between an agent and the rest of your environment. That’s a design decision, usually unstated, and the one worth reexamining.

Why IAM scoping leaves reachability open

IAM scoping is necessary but not sufficient. That’s the load-bearing claim of this whole post, and I want to make it once, carefully.

Here is the structural limit. An IAM policy governs what an identity may request through an authenticated, authorized channel. It has no view into, and no control over, the packets an agent actually puts on the network once it holds a credential. The moment that credential is stolen, replayed, or misconfigured, the policy is describing a world that no longer exists. The attacker isn’t asking your authorization server for anything; they hold the token, and they’re moving east-west.

That is the difference between authorization and reachability. Authorization is what the agent’s identity is permitted to ask for. Reachability is the set of destinations the agent’s traffic can actually arrive at. IAM defines the first. Nothing in the IAM stack defines the second. And reachability is the property an attacker exploits, because lateral movement is a reachability problem, not an authorization one.

Three concrete ways a clean IAM policy still leaves reachability wide open:

• Compromised or replayed credentials. A leaked service-account token, an over-broad key that outlived its task, an OAuth secret pulled from a misconfigured store. Any of these hands an attacker the agent’s authenticated identity, and the IAM policy is now working for them. It’s the pattern behind the OpenAI and Hugging Face lateral-movement incident: the boundary was defined at the app layer, and a credential exposure walked around it.
• Shadow agents outside IAM entirely. Developers stand up agents to ship faster, and plenty of them never touch your identity provider. An agent that was never enrolled in IAM has no policy to scope. It’s reachable, it’s communicating, and your authorization layer has never heard of it.
• Correctly-scoped agents that still over-reach. Even with a perfect policy, if the agent’s network path to a sensitive segment is open, a bug, a prompt injection, or a chained tool call can carry its traffic somewhere the policy assumed it could never go. The file share from the opening is this case. Nobody misconfigured anything. The path was simply there.

None of this means the IAM work was wasted. It means IAM answered the authorization question and left the reachability question open, and the reachability question is where AI agent least privilege enforcement actually lives.

Treat the agent as a workload identity, not a network address

AI agent access control starts with how you model the agent. A service account with an IP address is a static thing you can write a firewall rule against. An AI agent isn’t. It reschedules onto new infrastructure, respawns with a new address, scales horizontally into ten copies of itself, and every one of those events breaks a rule written against where it used to live.

So model the agent as an AI agent workload identity: a durable identity that belongs to the workload itself and persists as the workload moves. Policy attaches to that identity, not to a subnet, a VLAN, or an IP. When the agent reschedules or respawns, its identity and its policy come with it. A new address breaks nothing, because the address was never what the policy was about.

This is the shift the network layer has to make to keep up with agents: policy follows identity, not IP. It sounds abstract until you watch a static ACL fail to follow a task-based agent through a single reschedule. Then it’s very concrete.

A network-layer framework for enforcing least privilege access for AI agents

Here’s how I’d sequence the work if you’re building network-layer least privilege for agents from the architecture up. Five steps. Each one is doing something the IAM layer structurally can’t.

1. Establish a workload identity for the agent, not just credentials for it. In practice this means the identity persists as the agent moves, reschedules, or respawns, the way a service account’s identity should but rarely does once a team is five deployments deep. A credential proves the agent can authenticate. A workload identity is the thing policy attaches to, and it has to outlive any single session, address, or token. If your only durable handle on an agent is its credential, you’re back to scoping the thing an attacker steals.
2. Map required reachability, not requested permissions. Requested permissions are what the agent asked for at provisioning time. Required reachability is the specific, observed set of destinations it genuinely needs to touch to do its job: this database, that internal API, nothing else. These two lists are almost never the same, and the delta between them is your attack surface. Watch what the agent actually talks to for a real window, then write the reachability policy against the traffic you observed, not the wish list you were handed.
3. Default-deny at the network layer, independent of whatever the app or IAM layer granted. The network policy starts from zero and opens only the specific paths the reachability map calls for. Crucially, it makes its own decision. It doesn’t trust that the IAM grant was correct, and it doesn’t inherit the app layer’s assumptions. If a credential is compromised at the app layer, a default-deny network fabric still won’t carry the agent’s traffic to a segment its identity has no path to. That independence is the entire point: a second control that fails separately from the first.
4. Enforce dynamically as the agent’s identity or task changes, not with a static VLAN or ACL frozen at provisioning. Agents don’t hold still. A task-based agent’s legitimate reachability at 2 p.m. is different from what it needed at 10 a.m., and a rule you froze at provisioning time is either too tight to let it work or too loose to contain it. Dynamic policy adjusts what each identity can reach as the workload’s identity and current task change. It is also the honest answer to just-in-time access: lift the block on a specific path for a bounded window, then reinstate it. Not a standing path you left open because revisiting it was annoying.
5. Monitor and audit at the network layer, where a compromised agent can’t quietly disable the control. An endpoint agent can be killed by whatever compromised the host it runs on. A policy decision made in the network fabric can’t be turned off by the workload it’s governing. So put your audit trail there. Log every allowed path and, more usefully, every denied one, because a spike in denied attempts from a given workload identity is one of the cleaner privilege-escalation signals you’ll get.

Read those five together and the through-line is one property: policy that follows the agent’s identity survives the agent moving, respawning, or getting a new address. A rule pinned to an IP doesn’t. That’s the difference between a least-privilege boundary that holds when the agent’s environment shifts and one that quietly stops meaning anything the first time the workload reschedules.

Design-time pitfalls to avoid

The enforcement mistakes I keep running into all get made at architecture time, not through slow drift. How a boundary that was right at deployment grows too broad over the following months is a different problem, and I gave it its own home in the companion post on stopping AI agents from becoming over-permissioned.

• Treating IAM as the sole control. A single, correct IAM policy feels like a finished answer, which is why this mistake is easy to make. It leaves no independent backstop the moment a credential is compromised or an agent shows up that IAM never enrolled. Two controls that fail separately are worth far more than one configured perfectly.
• Static VLAN or ACL policy for task-based agents. A VLAN assignment or an ACL written against an address is frozen the instant you commit it, and agents don’t stay frozen. The rule either strangles the agent’s legitimate work or, more often, gets loosened until it’s no longer least privilege at all. Reachability that can’t track a moving identity isn’t enforcing much.
• No network backstop for a bypassed identity layer. If the design assumes the IAM layer is never bypassed, it has no answer for a stolen token or a shadow agent, which are the two most common ways this actually goes wrong. Build the architecture so that reachability is gated at the network layer regardless of whether the identity layer was honored, honestly, or at all.

Where network-layer enforcement fits, and where Elisity fits

Everything above is doable by any competent architecture team, and I wrote the framework so it doesn’t depend on us. The hard part in practice is the plumbing: giving every agent a persistent workload identity, keeping a live map of what each one actually reaches, and enforcing default-deny reachability without ripping out the infrastructure you already run. That’s the problem identity-based microsegmentation exists to solve.

In Elisity’s case, the Elisity IdentityGraph™ builds and maintains a persistent identity for every user and device, and for the workloads it discovers, triangulated across your existing systems of record. It maps what each one actually talks to, continuously rather than as a one-time survey. The Elisity Dynamic Policy Engine then enforces identity-based policy that follows the identity across any data plane, curtailing the reachability an identity already has down to the paths it genuinely needs, so a policy written for a workload keeps holding as that workload moves or picks up a new address. No new hardware sits in the path; the enforcement rides the infrastructure you already run. I name our approach not to pitch it, but to show the identity-based reachability control for users and devices I’ve described is a real, shipping pattern rather than a whiteboard idea.

For the wider threat context this sits inside, including the five agent-driven attack vectors and why the network is the last line of defense, see Elisity’s deeper treatment of AI agent network security.

Frequently asked questions about least privilege access for AI agents

How do I enforce least privilege access for AI agents?

Enforce it in two layers, not one. At the identity layer, do the IAM work: unique identity per agent, tightly scoped tokens, short lifetimes, approval gates on sensitive actions. Then add the layer the IAM stack can’t provide: network-layer reachability control that starts at default-deny, lifts the block only on the paths the agent genuinely needs, and follows the agent’s workload identity rather than its IP address. The first layer decides what the agent may ask for. The second decides where its traffic can actually go, and keeps deciding even if the first is bypassed by a stolen credential or a shadow agent IAM never saw.

What are common pitfalls and mistakes when implementing least privilege for AI agents?

The most common one is trusting IAM as the sole control, with no independent network backstop for the day a credential leaks or an unmanaged agent appears. Close behind it is writing reachability as a static VLAN or ACL against an IP address, which a task-based agent breaks the first time it reschedules or respawns onto new infrastructure. The third is designing as if the identity layer is never bypassed, so there’s no gate on the agent’s actual traffic when it inevitably is. All three are enforcement-design mistakes. Fix them by making network reachability its own default-deny control, anchored to workload identity, that decides independently of whatever IAM granted.

How do I audit and monitor AI agent permissions and detect privilege escalation attempts?

Audit at the network layer, not only in application logs. Application logs tell you what the agent successfully asked for through authorized channels; they’re blind to traffic that never went through those channels. A policy engine in the network path logs every allowed connection and, more valuably, every denied one. A rising count of denied reachability attempts from a single workload identity is one of the clearest privilege-escalation signals available, because it’s the agent trying to reach a destination its policy has no path to. Put your detection where a compromised agent can’t quietly disable it: the network fabric, rather than an endpoint process the host’s attacker already controls.

How do I handle least privilege for AI agents that need occasional elevated access (just-in-time access)?

Treat just-in-time access as a network policy problem, not only a token problem. The common answer today is a short-lived OAuth token, which is fine and still leaves reachability standing: the token expires, but if the network path stays open, the reachability outlived it. The network-layer answer is a dynamic policy window that temporarily lifts the block on a specific path, tied to the agent’s workload identity and its current task, for a bounded time, then reinstates it. Elevation becomes a temporary, audited change to what the agent can reach, not a standing path you meant to revisit and never did.

The teams I see getting this right have stopped treating least privilege as a configuration they set once and started treating it as a live property of the network, one that follows each agent’s identity and holds even when a credential leaks or an agent shows up that nobody enrolled. IAM scoping gets you an authorization boundary, and you should build it well. Reachability control at the network layer is what makes that boundary hold when an agent moves, respawns, or gets compromised. I said in the spring I’d come back to this with the implementation detail. This was that post; the next question, how a right-sized boundary drifts too broad over time, is the one I’d read next.

Further reading:

• AI security and microsegmentation for agentic AI threats
• AI agent network security and microsegmentation
• The OpenAI and Hugging Face incident: lateral movement in practice
• How to stop AI agents from becoming over-permissioned
• Identity-based microsegmentation