Notifications
Clear all
Topic starter
24/07/2026 4:07 pm
TL;DR: AI agent least privilege breaks when IAM policies govern what an identity may request but not what its traffic can actually reach, according to Elisity’s analysis of agent network enforcement and the OpenAI and Hugging Face incident. The real control gap is reachability, not scoping, and it demands identity-based network policy rather than token-only governance.
NHIMG editorial — based on content published by Elisity: How do I enforce least privilege access for AI agents? (A network-layer answer)
By the numbers:
- The 2026 Infrastructure Identity Survey found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read Elisity's analysis of least privilege access for AI agents →
AI agent reachability control: what IAM teams are missing?
Explore further
24/07/2026 4:12 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI agent least privilege fails when reachability stays open
