The security industry has been talking about least privilege for decades, and the idea itself has always been simple enough, giving people and systems only the access they need to do their jobs and nothing more. The reality is that we have been pretty bad at it. On-prem, we ended up with sprawling admin rights and service accounts that nobody remembered creating, and when we moved to the cloud we did it all over again, only faster and at greater scale, with overly permissive roles and long-lived keys scattered across environments.
Now AI agents are here, and the stakes have gone up considerably. Agents don't just have access, they take action, reading data, calling tools, making changes and chaining decisions together, often at machine speed. That is why the conversation is evolving from least privilege toward what is increasingly being called least autonomy, a concept that groups such as OWASP and others are now referencing. It is no longer only about what an agent can touch, but about how much it is allowed to do on its own.
It Starts With Identity
You can't govern what you can't attribute, and today many agents simply borrow a human's identity and act on that person's behalf. That is convenient, but it creates a real problem, because when something goes wrong the logs say Chris did it when in reality an agent did.
Agents need their own unique identities, and the Coalition for Secure AI (CoSAI) makes this the first principle in its Agentic Identity and Access Management paper, arguing that every agent should have its own distinct and verifiable identity rather than a shared account or repurposed human credentials. When an agent does act for a person, the chain of authority, meaning who authorized what, when and through which other agents, should be traceable and preserved in logs that can't be altered. That is ultimately how we tell the difference between what a human did and what an agent did on their behalf.
The Ecosystem Is Catching Up
The good news is that the standards community is moving, with emerging work on agent authentication such as AAuth, along with updates to OAuth aimed at how agents request, receive and delegate access. When I sat down with identity expert Karl McGuinness on Resilient Cyber, he made a point that has stuck with me ever since. We spent two decades building authentication and authorization for people moving at human speed, and agents remove the natural pacing and limits that made those controls work in the first place. In Karl's view the real frontier is delegation, which means turning a human's approved intent into bounded authority that stays governed as the agent does its work. As he puts it, agents don't need your passport, they need your authority.
It is still early days, and Karl was candid about the gap between what the standards bodies are actually drafting and the "agentic IAM" being marketed on conference show floors. Even so, the direction is clear, and agents are becoming first-class identities rather than an afterthought bolted onto human accounts.
Identity Is How You Right-Size Autonomy
Once an agent has its own identity, you can finally start answering the questions that matter most, such as what the agent actually did, what permissions it holds, and whether its scope is broader than the work it needs to do. This is where least privilege grows into least autonomy.
Part of the challenge is that access isn't authorization. Just because an agent has been granted access to a system or a dataset doesn't mean that what it is doing or touching in any given moment is actually appropriate, and an agent with perfectly valid permissions can still take an action that falls well outside what its user intended. I dug into this with Rock Lambros, Co-Lead of the OWASP Top 10 for LLM Applications, in our Resilient Cyber conversation, where he made the case that agency is not authorization. It is also why you'll increasingly hear folks discuss concepts such as intent analysis, which looks at whether an agent's action in the moment actually lines up with what it was asked to do rather than simply whether it was allowed to do it.
CoSAI's guidance here is direct in calling for no standing privilege. Agents should receive short-lived credentials that are scoped to the task at hand and taken away once the task is done, and when one agent hands work off to another, access should only narrow and never expand. It also isn't enough to check credentials once at the door, and Karl framed this well when he said that governing the stay matters more than governing the entry. Agents need to be right-sized based on what they are actually doing at runtime, with access tightened whenever it is broader than the task requires.
It Has to Fit the Enterprise You Actually Have
Most organizations don't have a single tidy identity provider. They have several, spread across business units, clouds and SaaS tools, along with all of the agents now showing up across them, and agent identity has to fold into that reality. One of CoSAI's most practical findings is that organizations don't need to rip and replace what they have, since the identity providers, policy engines and logging they already run can serve as the foundation and be extended to handle agents. Karl made a similar point about SaaS, arguing that we need to move past app-by-app islands of access. Security teams need the identity context of their agents brought together across those systems rather than stood up as yet another silo.
CoSAI also lays out a sensible path for getting there, starting with visibility into which agents exist and what they can reach, then layering in contextual access controls, and finally moving to full enforcement and continuous monitoring at runtime.
How We Approach It at Noma
At Noma, we see identity and runtime as two halves of the same picture, with identity telling you who the agent is and runtime telling you what it is actually doing. We focus on bringing the two together through open enforcement that plugs into the identity providers, gateways and tools organizations already use, along with access control that governs which tools and resources agents are able to use. That way security teams can find their agents, understand their access and keep their autonomy in check as they act, rather than discovering the problem after the fact.
We didn't get least privilege right the first time around, but with agents we have a real chance to build it in from the start, and it is an opportunity we can't afford to waste.
Ready to put least autonomy into practice?
Our AI Security Customer Toolkit brings together the frameworks, checklists, and research your team needs to find every agent, right-size its access, and keep its actions in check at runtime. Get the toolkit →
