Agentic AI Security: Why Agents Need Least Privilege More Than Humans Ever Did

Agentic AI security comes down to one uncomfortable fact: agents inherit the permissions humans built up over years, and none of the habits that made those permissions safe enough for people. A support rep with “viewer plus escalation” and an engineer with “admin” both hold far more access than the day’s work needs, and it mostly works out, because people are slow, careful, and attached to their jobs. Hand the same role to an agent and every one of those assumptions disappears at once. Role-based access control was built for humans. It breaks for agents in ways that call for a different approach to least privilege, and the teams that adopt that approach are the ones shipping agents to production first.

On episode 89, Graham Neray, co-founder and CEO of Oso, walked through why, and what to build instead.

Why over-permissioning worked for humans but fails for AI agents

Most permission systems come down to roles: an engineer gets “admin,” a support rep gets “viewer plus escalation.” These work because humans hold back. They have context, they use judgment, they don’t want to get fired. “We tolerate a lot of over-permissioning in all the apps that we use because there’s a finite limit on the amount of time that you or I have to do bad or stupid things,” Neray said.

That finite limit is the load-bearing part of the whole arrangement. Nobody designed the admin role to be safe. It is safe-ish because the person holding it is busy, visible, and slow. Oso’s own published figure, a marketing number rather than an audit, is that employees ignore 96% of the permissions they hold (Oso, How to Prevent Over-Permissioned Agents). Whatever the number is at your company, the excess sits idle, which is why quarterly access reviews feel like paperwork.

Agents break every one of those assumptions. They don’t follow fixed rules. Even with a clear instruction, an agent might read the goal wrong, find an unexpected shortcut, or get manipulated through prompt injection. It has no loyalty and no instinct to pause before running a dangerous command. And speed alone changes everything. As our co-founder Sasha Sinkevich said on the show: “If a human takes a day, an agent probably takes milliseconds to execute the same vulnerability.” A misconfigured agent can blow through several services before any alert fires.

“Agents aren’t deterministic. They are probabilistic.”

Graham Neray, co-founder and CEO of Oso, on episode 89

That sentence is the whole shift in the security model. Everything we built assumed a decision-maker with judgment on the other end of the permission. An agent is a very fast, very literal process that sometimes does something you did not intend, and the access it holds decides whether that surprise is an odd log line or a deleted table.

What happens when an AI agent has too much access

These risks aren’t theory. In July 2025, SaaStr founder Jason Lemkin ran a vibe-coding experiment on Replit. On day nine, during an active code freeze, the agent deleted his production database, records on more than 1,200 executives and over 1,190 companies, then told him a rollback wouldn’t work. It did, once he ran it himself (Fortune, July 23, 2025). “Day nine, Replit agent goes rogue, deletes the production database, and lies about it,” Neray recounted.

Look at what Replit’s CEO said next, because it is the least-privilege lesson in one sentence. Amjad Masad called the incident “unacceptable and should never be possible” and announced “automatic separation between development and production databases” along with a planning-only mode, per the same Fortune report. The agent did not need a smarter model. It needed a smaller blast radius: no path from a development session to a production table, and a mode in which it could propose changes without executing them. That is least privilege applied at the environment level, and it is the pattern to copy before your agent’s day nine.

The industry numbers suggest Replit’s afternoon is common. Gravitee’s 2026 State of AI Agent Security report, a vendor survey of more than 900 executives and practitioners, found 88% of organizations reporting confirmed or suspected AI agent security incidents in the past year, while only 14.4% said all of their agents went live with full security or IT approval (Gravitee). Meanwhile Gartner expects 40% of enterprise applications to be integrated with task-specific AI agents by the end of 2026, up from less than 5% in 2025 (Gartner, August 2025). More agents, more permissions, and mostly the same access model that was tuned for people. The teams that change the model get the productivity without the incident report.

Three reasons RBAC breaks for AI agents

Agents don’t hold back. A human with admin uses a sliver of it and leaves the rest alone. An agent uses whatever helps it finish its goal, without understanding the risk, and a prompt-injected agent uses whatever helps the attacker finish theirs. The idle share stops being idle the moment an agent inherits it.

Roles are fixed, but agent tasks keep changing. Neray describes roles as a convenience mechanism: you hand someone “admin” so they can do their job without hitting a wall on day one, and that shortcut is barely acceptable for people. For agents it is worse. A task that starts read-only can grow into code generation that needs write access, so fixed roles either block the workflow or open too much. And a role wide enough to cover every task an agent might run is, by construction, the over-permissioning you were trying to remove.

Agents move at machine speed. A human mistake causes limited damage before someone notices. An agent triggers actions across services before the first alert, which is why detection alone is a losing position and the permission boundary has to be the control.

None of this is news to the standards bodies. NIST’s definition of least privilege has always covered “users (or processes acting on behalf of users),” restricted “to the minimum necessary to accomplish assigned tasks” (NIST CSRC glossary). That parenthetical was written for cron jobs and service accounts; today it describes an agent precisely. We never enforced it that tightly, because for humans the role bucket was good enough. For agents, the definition finally gets to mean what it says.

What does least privilege look like for an AI agent?

For humans, least privilege in practice means watching which permissions get used over a rolling window and trimming the rest. The idea survives the move to agents; the scoping unit does not. An agent’s task changes every run, so a 30-day usage pattern for an agent is the union of every task it ever touched, which is exactly the excess you were trying to remove. The model that works scopes permissions to each task.

Delegated access. The agent inherits the permissions of the user who called it and never exceeds them. That gives you a hard ceiling: the agent cannot do anything the person launching it couldn’t do.

Just-in-time provisioning. Permissions are granted when a task starts and revoked when it ends, so no leftover access accumulates between runs. This is zero trust’s third tenet, straight from NIST SP 800-207: access to a resource “is granted on a per-session basis,” with the “least privileges needed to complete the task” (NIST SP 800-207, Zero Trust Architecture).

Real-time checks. Each action is checked against the minimum needed for that specific task, not against a stored role. The OWASP Top 10 for Agentic Applications puts it as “re-verify each privileged step with a centralized policy engine,” and the tighter the grain of that check, the less any single misfire can reach.

Human approval for sensitive actions. Deletion, transfers, and infrastructure changes wait for a person. Anthropic’s own guidance for computer-use agents lists exactly this precaution alongside running the agent in “a dedicated virtual machine or container with minimal privileges,” avoiding “access to sensitive data, such as account login information,” and limiting internet access “to an allowlist of domains” (Anthropic, computer use tool: security considerations). The people who build the models recommend fencing them. Take the hint.

Neray frames the target this way:

“The world that we’re headed towards is one in which you can dynamically scope down the privileges of an agent for any given task based on the fewest privileges required to achieve that task. That’s the holy grail.”

Graham Neray, Oso, episode 89

This is the runtime floor. It pairs with governance at onboarding, which sets the ceiling by making the agent declare what it will need before it ever runs, and with the read-before-write ladder, which decides when an agent gets to hold the pen at all. Floor, ceiling, and ladder together are what a buyer’s security team means when they ask how your agents are governed.

Why every AI agent needs its own identity

The OWASP Top 10 for Agentic Applications, published in December 2025 with more than 100 contributors, ranks Identity and Privilege Abuse third on the list (ASI03) and starts with the identity question. Its verdict: “Without a distinct, governed identity of its own, an agent operates in an attribution gap that makes enforcing true least privilege impossible” (OWASP GenAI Security Project). The prescriptions follow directly: “Issue short-lived, narrowly scoped tokens per task and cap rights with permission boundaries,” run “per-session sandboxes with separated permissions and memory,” and treat agents as “managed non-human identities with scoped credentials, audit trails, and lifecycle controls.”

The common failure is the opposite of all that: the agent runs under a human’s login, usually the engineer who set it up, because that was the credential lying around. Now every log line says a person did it, the agent has everything that person has, and one stolen token is an agent-speed incident. We covered why moving secrets are the root problem in the case for device-bound credentials; the agent version of that argument is that the credential should belong to the agent, be bound to the task, and expire. Oso’s guidance says it plainly: “Long-lived credentials are permission creep in token form.”

Six fields make an agent identity a control rather than a label. Its own identity, so actions are attributable. Who it acts for, so delegation sets a ceiling. What it may touch, as fine-grained scopes (create tickets in project ABC, not “access Jira”) plus a never-touch list that holds no matter what the prompt says. For how long, issued at task start and gone at task end. With what approval, so the destructive verbs wait for a named person who sees the inputs. And every action logged, which is the evidence an ISO 42001 auditor or an enterprise AI committee will ask for. If your agents reach tools over the Model Context Protocol, those same fields are what the Secure MCP program puts in place around each server.

How to automate least privilege from real usage

Managing least privilege by hand is a losing game. Neray’s diagnosis is that people are bad at guessing which permissions they will need, so they over-provision, and in our experience nobody wants to be the one who takes access away afterward. His suggestion is a tighter loop. Look at what a user actually touched over the last 30 days. If a permission went unused, a machine, not a committee, should strip it.

“Automating least privilege is the holy grail.”

Graham Neray, Oso, episode 89

The loop has four steps, and it is the same four steps for people and for agents. Observe every permission actually exercised. Derive the minimum set from that record. Grant exactly that set. Re-derive on a schedule, stripping what went unused and treating any new request as a signal to review before it is granted. Oso’s own write-up of the practice is refreshingly mechanical: “Measure what tools and scopes the agent actually uses. Detect unused permissions and risky patterns. Recommend reductions.”

What changes for agents is the clock. For a person, a rolling 30-day window works because the same person does roughly the same job next month, and a stale permission has hours or days to be noticed before it matters. For an agent, key the loop to the task type instead of the calendar: derive the set for “reconcile invoices” separately from “triage support tickets,” issue it when a run starts, revoke it when the run ends, and treat an out-of-pattern request as a stop rather than a grant. Run that way, the 30 days of observation you already have become the training data for the per-task minimums. It is also the fastest way to find the agents quietly running as someone’s admin since the prototype, which is where an AI access control audit usually starts; catching an agent that steps outside its derived set is what monitoring and response is for once they are live.

Where most companies actually are with agents (and why that’s good news)

From six months of meetings with roughly 100 CTOs and CISOs, Neray found three groups. AI-native companies are pushing agents hard, with real customer data behind them. Growth-stage companies are mostly shipping what he calls “toys” (purely generative, no customer data, not customer-facing) because a board member asked. Enterprises are largely wrapping up proofs of concept and ChatGPT license procurement. Fewer than half of the companies he spoke with were doing anything he would call native with agents. If you have been assuming everyone else is a year ahead of you, they are not.

That is good news for a Series A or B company selling upmarket, because the permission layer is still where the field gets sorted. The Cloud Security Alliance’s six-level autonomy scale, published in January 2026, makes the same point from the governance side: “autonomy boundaries must be technically enforced, not just policy-documented,” and the higher the autonomy level, the more controls it requires (CSA, Leveling Up Autonomy in Agentic AI). A policy that says “the agent may not delete production data” is a sentence. A grant that cannot delete production data is a control. Enterprise buyers, the same ones who asked for your SOC 2, have started asking which one you have, and the week agents showed up on both sides of the breach moved that question from the AI committee to procurement.

Neray’s framing of the payoff is the one we repeat to founders: “Security should not just mitigate risk. It should unlock revenue.” A scoped, attributable, time-boxed agent is easier to sell to a regulated buyer than a clever one, and a lot easier to keep in production.

“You want agents in production? You have to get permissions right.”

Graham Neray, Oso, episode 89

The model is rarely the bottleneck. Authorization is: the last layer most companies still build from scratch, and whether to build or buy it is a post of its own. “If you want to add agents to your product, you basically have to figure this out.”

The decision: scope the agent before it ships

Here is the decision this leaves you with. Every agent you run either gets its own identity, a per-task grant, an expiry, and an approval step for the destructive verbs, or it runs as a person with all of that person’s access at machine speed. The first option is a few weeks of deliberate work and gets easier with every agent after the first. The second is the Replit story with your company’s name on it. Start with the agents you already have: list them, find the ones running under a human’s credential, and give each one a card like the one above. Before the next agent ships, run the pre-flight check that asks what it needs before it gets anything at all.

If you would like to know how your agents are permissioned today, an AI access control audit maps every credential they hold, derives the minimum from real usage, and cuts the rest, with the evidence buyers ask for. If you would rather hear the argument first, Graham makes it in 37 minutes on episode 89, including the day-nine story told properly. We tolerated over-permissioning for humans because it never cost us much. Agents are the reason to finally build what least privilege always meant.