Is Least Privilege Enough for the Agentic Enterprise?

I've been researching what the Agentic Enterprise will look like, what it means for security, and how Zero Trust must evolve to meet the challenge. Along the way, I keep coming back to a pretty basic question: Is least privilege enough when the identity we're securing can act autonomously?

I don't think it is.

Least privilege has been foundational to Zero Trust for good reason. Give a user, device, workload or application only the access it needs to do its job. Nothing more. Limit the attack surface, reduce the blast radius and continuously verify that the access still makes sense.

But AI agents change something fundamental. They don't just access resources. They act on them.

That distinction may seem subtle, but I think it has profound implications for how we think about Zero Trust. If least privilege is about limiting what an identity can access, perhaps we also need to think about Least Agency. Its about limiting what an autonomous identity can independently decide to do with that access.

The more I've researched the Agentic Enterprise, the more important that distinction has become.

When AI stops assisting and starts acting

We've spent the last several years talking about copilots. They summarize documents, analyze information, generate content and recommend what we should do next. For the most part, the human remains the actor. We ask the AI for help, consider its answer and decide whether to act.

The Agentic Enterprise changes that relationship. We begin delegating bounded authority to software actors capable of planning, selecting tools, communicating with other agents and causing changes in business systems.

The key word is action.

A chatbot that summarizes a contract creates information. An agent that retrieves the contract, evaluates the terms, contacts the vendor, updates a procurement record and submits a purchase request has changed the state of the enterprise.

Once AI moves from recommending an action to actually taking it, our security question changes. It's no longer enough to ask whether the agent was authorized to access a resource. We also have to ask whether it should have been authorized to produce the resulting outcome.

Think about a procurement agent. It might legitimately need to read contracts, access vendor information, communicate with suppliers, create purchase orders and interact with financial systems. Look at each permission independently and everything might satisfy a well-designed least-privilege policy.

Now combine them.

Should the same agent be able to change a supplier's banking information, create a payment, approve that payment and communicate the change to the supplier without a human ever entering the process?

Maybe not.

But here's what makes this interesting: nothing necessarily violated least privilege. Every individual permission may have been legitimate. The problem came from combining those permissions with autonomous decision-making.

That's a very different security problem.

Traditional least privilege asks what resources a principal needs to access. Autonomous systems force us to consider what combinations, sequences and consequences of otherwise legitimate actions the principal should be allowed to produce independently.

An agent with permission to read CRM records may be perfectly legitimate. An agent with permission to send email may also be legitimate. But an autonomous sequence of read customer records, extract the information and transmit it externally isn't really an access problem anymore. It's an action problem.

That's the gap I think Least Agency needs to address.

From least privilege to Least Agency

I don't think we need to abandon least privilege. Quite the opposite. Least Agency is an extension of the same idea.

Least privilege says we should give an identity only the access necessary to perform its job. Least Agency says we should give an autonomous system only the freedom to act necessary to accomplish its authorized objective.

That means agency can't simply be treated as a switch—autonomous or not autonomous. There are degrees of agency.

A procurement agent might be able to draft a purchase order but not submit it. It might automatically renew contracts below $10,000 but require approval above that amount. It might use three approved tools but be prohibited from dynamically discovering others. It might be able to delegate a task to one approved sub-agent, but that sub-agent can't delegate again. Its authority might last four hours rather than indefinitely.

Even velocity becomes part of the security model. An agent that normally changes twenty records during a workflow and suddenly attempts to change twenty thousand should probably encounter a very different policy boundary.

The research I've been doing suggests this starts to look less like traditional RBAC and more like a combination of capability security, policy engines, transaction controls and workflow state machines.

And that's where I think this becomes a Zero Trust conversation.

Zero Trust still works. But what it protects is changing.

I've always thought one of the strengths of Zero Trust is that it removes assumptions. Being on the corporate network doesn't make you trustworthy. Successfully authenticating doesn't mean you should have unlimited access. Having access yesterday doesn't mean you should automatically have it today.

Verify. Apply policy. Minimize access. Continuously observe.

Over time we've built those ideas across an architecture that, at a high level, looks something like:

Identity → Device → Network → Application → Data → Policy → Telemetry

The Agentic Enterprise doesn't make any of those controls obsolete. If anything, it makes every one of them more important. But what we're asking those controls to understand starts to change.

Identity is a good example. Knowing which agent acted isn't enough. We also need to know on whose behalf it was acting and how it acquired the authority to act.

Suppose Sarah asks her procurement agent to renew a software contract. The procurement agent delegates contract analysis to a legal agent and supplier risk analysis to a security agent. It then interacts with an external vendor agent, invokes a purchasing API and ultimately causes an ERP system to issue a purchase order.

Whose identity belongs in the audit trail?

Sarah's? The procurement agent's? The legal agent's? The external vendor agent's?

The answer is all of them.

The enterprise needs to preserve both authority and causality through that chain. The identity tells us who acted. The delegation record tells us on whose behalf they acted, for what purpose and under what authority.

The device and workload layer changes as well. We need to understand where the agent is executing, which model and configuration are running, whether that runtime can be trusted and what credentials or secrets are available to it. When an infrastructure or security agent can modify cloud environments, networks or code, runtime integrity becomes inseparable from identity.

The network also takes on an interesting new role. We've traditionally thought about segmentation as a way to constrain lateral movement by attackers. In an Agentic Enterprise, the network can also constrain lateral action by agents.

Which systems can an agent reach? Can it communicate with the public Internet? Can it connect to another agent? Can a finance agent suddenly invoke a messaging service it has never used before? Can an agent reach an unapproved external tool or MCP server?

Network policy becomes one of the physical boundaries around agency.

Applications change too, although I don't think they're disappearing. If anything, systems of record may become more important because autonomous actors need authoritative state. What's changing is how those applications are consumed.

The research led me to think about the future application interface as Human UI + API + Agent Tool Contract + Event Stream. An application built for autonomous consumers needs more than an API. It needs narrowly defined actions, explicit schemas, authorization hooks, rate limits, transaction identifiers, dry-run capabilities and, wherever possible, compensating or rollback operations.

Data may be even more interesting.

One of an agent's greatest advantages is its ability to correlate information across systems at a scale humans simply can't. But that also means authorized access can produce unexpected risk. A sales agent might legitimately access CRM data. A legal agent might legitimately access contracts. A finance agent might legitimately access spending information. An executive agent might reasonably have access to all three.

Every individual access decision can be correct while the aggregate result creates an entirely new capability.

So protecting data in the Agentic Enterprise can't stop at asking whether the agent was authorized to retrieve something. We also need to understand what it can infer, combine, retain and transmit after access has been granted.

And eventually all of this arrives at policy.

Today's policy might say that Agent X can access System Y. Tomorrow's policy may need to say that Agent X can access System Y for a specific purpose, use certain tools, perform certain actions, for a defined amount of time, below a transaction threshold, at a particular volume and with a limited ability to delegate to other agents.

That's Least Agency in practice.

There is another part of this that I think is especially important. The AI model cannot be the final authority on whether the AI model is allowed to act.

Models can reason. They can recommend. They can propose an action. But consequential authorization needs deterministic enforcement outside the model. The architecture emerging from the research looks more like this: the agent proposes an action, policy evaluates it, transaction constraints are verified, a trusted executor performs the action and the result is recorded.

That's actually a very Zero Trust idea.

Don't trust the actor to determine whether the actor should be trusted.

The SOC can't approve every action

There is also an operational reality we need to acknowledge. We aren't going to secure potentially millions of agent actions by putting a human approval dialog in front of every one of them.

Humans will do exactly what they do today when confronted with too many security prompts. They'll click Allow.

The more scalable model is to establish safe operating envelopes and monitor what happens inside them.

That's why I've started thinking about the future SOC as something closer to air-traffic control. Air-traffic controllers don't fly every airplane. They establish safe corridors, maintain a shared picture of activity, identify deviations and intervene when something moves outside its expected operating envelope.

The SOC may increasingly need to do the same with agents.

Instead of looking at an isolated login or API event, the interesting unit of observation becomes an action graph: Principal → Agent → Delegation → Tool → Resource → Data → Action → Outcome.

Now we can see that a finance agent suddenly started using a messaging connector. Or an HR agent began accessing source-code repositories. Or an agent that normally executes twenty transactions an hour suddenly attempted twenty thousand. Or an agent delegated authority several layers deeper than its policy allowed.

Those are signals of agency, not simply access.

But there's one more problem.

And I think it may ultimately be one of the most important security questions in the Agentic Enterprise.

What happens when the agent is simply wrong?

Imagine we've done everything right.

The agent has a verified identity. Its workload is trusted. The network is appropriately segmented. Its application permissions are correct. Its data access is appropriate. Least Agency policy has constrained what it can do. Telemetry gives us visibility into its actions.

And the agent still makes the wrong decision.

There doesn't have to be an attacker.

No credentials need to have been stolen. No malware needs to execute. No policy needs to have been violated.

The agent was authorized to act.

It was just wrong.

That's why I think we need to add another element to the Zero Trust architecture for the Agentic Enterprise: recoverability.

Our familiar architecture begins to evolve from Identity → Device → Network → Application → Data → Policy → Telemetry toward Identity → Device/Workload → Network → Application → Data → Policy → Telemetry → Recoverability.

Historically, recovery has tended to come at the end of the cybersecurity lifecycle. Prevent what we can. Detect what gets through. Respond to the incident. Recover afterward.

I'm increasingly convinced that doesn't work for autonomous systems.

Recoverability needs to be designed in before agency is granted.

If an agent modifies ten records, can we undo it? What about ten thousand? If an infrastructure agent pushes a technically valid but catastrophically wrong configuration across hundreds of systems, can we return them to their previous state? If one agent corrupts information that feeds another agent, can we determine where the chain started and what downstream decisions were affected?

If an agent delegates authority to three other agents, can we revoke the entire delegation chain? If a critical business process becomes dependent on an agent, can the business still operate when that agent, model provider or control plane is unavailable?

One conclusion from my research keeps sticking with me:

Do not automate a critical business process beyond your ability to recover, override or reconstruct it.

I think that's bigger than backup.

It's an architectural principle.

From access to action to outcome

This is ultimately where I've landed.

I don't think Agentic AI invalidates Zero Trust. I think it demonstrates why Zero Trust was the right idea in the first place.

But the thing we're securing is changing.

For much of Zero Trust's history, the central question has been: Should this identity be allowed to access this resource?

In the Agentic Enterprise, we need to ask another question: Should this identity be allowed to act on this resource autonomously?

And perhaps a third: Should it be allowed to produce this outcome?

That's the progression I'm interested in:

Access → Action → Outcome.

Can you do it? That's least privilege.

Should you be able to do it autonomously? That's Least Agency.

And if you do it and you're wrong, can we undo it? That's recoverability.

The Agentic Enterprise I'm seeing emerge from the research isn't necessarily one where humans disappear and AI runs everything. The more plausible model is one where humans increasingly define objectives and policies while agents execute bounded workflows and humans manage the exceptions.

But bounded is the important word.

The technology for allowing agents to act is developing faster than our ability to prove why they acted, constrain what they can do and assign responsibility when something goes wrong.

So maybe the next evolution of Zero Trust isn't a replacement for what we've spent the last decade building. Maybe it's an extension of it.

Never trust. Always verify.

And when the identity is autonomous:

Constrain its agency. Observe its actions. Make sure you can recover.

Which brings me back to the question that started this research for me.

Is least privilege enough for the Agentic Enterprise?

I don't think it is.

But I suspect we're only beginning the conversation about what comes next.