Least Privilege for AI Agents: Why Autonomy Needs Boundaries

For many years, security in enterprise systems followed a relatively simple principle:

an identity should have access only to what it needs to perform its role.

We call this Least Privilege, or the principle of least privilege.

The concept is not new.

It is present in IAM, Zero Trust, cloud security, APIs, databases, applications, and virtually every modern security architecture.

But the arrival of AI agents makes this principle even more important.

Because there is a fundamental difference between a chatbot and an agent.

A chatbot usually responds.

An agent can act.

It can query systems.

Create records.

Send messages.

Open tickets.

Modify documents.

Execute code.

Call APIs.

Change configurations.

Make decisions.

And, depending on the architecture, it may execute several of these actions in sequence without a human individually approving each one.

At that point, the security question is no longer simply:

“Can the model do this?”

It becomes:

“Should the agent be allowed to do this?”

The Problem Is Not Only What the Agent Knows

Much of the discussion about AI security still focuses on topics such as:

prompt injection;

jailbreaking;

data leakage;

hallucination;

protection of sensitive information.

All of these are important.

But agents introduce a new dimension:

permission to act.

Imagine an agent connected to:

CRM, ERP, email, SharePoint, GitHub, financial systems, databases, customer-service tools, and cloud infrastructure.

Individually, each access permission may seem reasonable.

But when all of these permissions are combined, something very different emerges:

an identity capable of correlating information and executing actions across multiple systems.

Microsoft specifically highlights this risk: permissions that appear reasonable individually may create much greater capabilities when combined inside agentic workflows.

That is why the discussion about agent security needs to start with identity.

Every Agent Should Be an Identity

One of the most important conceptual changes is to stop treating an agent merely as an application.

It needs to be treated as a security principal.

In other words:

Who is this agent?

Who is responsible for it?

On whose behalf is it acting?

Which data can it access?

Which tools can it use?

Which actions can it execute?

For how long?

Who can revoke its access?

Microsoft recommends treating agents as first-class principals, with dedicated identities, clearly defined human ownership, explicit roles, restricted permissions, and their own lifecycle.

AWS follows a similar direction in its Agentic AI Lens: agents should have verifiable identities, permissions separated from human identities, and clear authentication and authorization mechanisms, both when acting on behalf of a person and when operating autonomously.

This change may seem small.

Architecturally, it is enormous.

The Classic Mistake: Granting Too Much Permission to Accelerate the Pilot

There is a very familiar pattern in technology projects.

The team starts a pilot.

Something does not work because of missing permissions.

To move faster:

“Let’s make it admin for now.”

The pilot works.

Then it goes into production.

And “for now” is never revisited.

With agents, this is especially dangerous.

Because an agent can execute actions at much greater speed and scale than a person.

AWS warns that overly broad permissions can turn a model misinterpretation or unexpected behavior into a cascading incident.

This is an important point:

the purpose of Least Privilege is not to prevent the agent from working.

It is to limit the impact when it does not work exactly as expected.

Blast Radius

One question I find particularly useful when designing enterprise agents is:

If this agent makes the worst possible decision, what is the maximum damage it can cause?

That is essentially a question about blast radius.

An agent that can:

read 20 documents

has one level of risk.

An agent that can:

read 2 million documents

has another.

An agent that can:

create a ticket

has one level of risk.

An agent that can:

change production configurations

has another.

An agent that can:

prepare a payment order

has one level of risk.

An agent that can:

execute the payment autonomously

has a completely different one.

Least Privilege is one of the main mechanisms for reducing that blast radius.

Limiting Data Is Not Enough. Actions Must Also Be Limited.

There is another important shift.

In traditional architectures, security often focuses on:

who can access which information.

With agents, we need to add another question:

who can execute which action.

That means controlling permissions across multiple dimensions.

By Resource

Which systems can the agent access?

By Data

Which databases, documents, records, or classifications?

By Operation

Can it read?

Create?

Edit?

Delete?

Export?

By Context

Can it execute the action in any situation?

Or only within a specific workflow?

By Impact

Can the action be executed autonomously?

Or does it require human approval?

That last point is particularly important.

Read and Write Should Not Be Treated the Same Way

A very useful pattern is to explicitly separate:

observation

from:

execution.

An agent may have relatively broad autonomy to:

search data;

analyze information;

summarize content;

identify anomalies;

propose an action.

But that does not mean it should have the same autonomy to:

delete;

publish;

pay;

approve;

change permissions;

modify production.

Microsoft recommends that high-impact, irreversible, or sensitive operations require specific authorization and, where appropriate, renewed human approval.

OpenAI follows the same logic by recommending that validations be enforced at the point where the action actually creates an effect — at the tool executing the operation — rather than only at the overall agent level.

This leads to an important principle:

authorization should happen at the moment of action, not only at the beginning of the conversation.

Tool Binding: The Agent Should Not See Every Tool

Imagine an enterprise agent connected to fifty APIs.

Does it really need to see all fifty?

Probably not.

A safer architecture exposes only the tools required for that specific objective.

This concept is often called tool binding.

A customer-service agent may need to:

retrieve customer information;

check an order;

open a ticket.

But it probably does not need to:

modify IAM;

execute administrative SQL;

delete users;

change infrastructure.

Microsoft explicitly recommends that agents have access only to a pre-authorized set of tools and actions.

AWS makes a similar recommendation by limiting agents to only the tools required for their role.

Again:

do not trust the model to decide on its own what it should not do.

Remove from the architecture the capabilities it does not need.

The Prompt Is Not a Security Policy

This may be one of the biggest misconceptions in some agent projects.

Adding to the prompt:

“Never delete information.”

is not equivalent to technically preventing a delete operation.

Adding:

“Do not share confidential data.”

is not equivalent to blocking access to confidential data.

Adding:

“Do not execute financial operations without authorization.”

does not replace an authorization policy.

A prompt guides behavior.

An access policy enforces a boundary.

These are very different things.

Microsoft itself warns against relying on textual instructions instead of technical authorization controls.

AWS recommends enforcing boundaries at runtime so that the LLM’s reasoning cannot expand the agent’s scope.

This separation is fundamental:

LLM → decides what it would like to do

Policy → decides what it is allowed to do

Just-in-Time Should Also Exist for Agents

An agent does not always need to retain elevated privileges continuously.

Imagine an operations agent.

During 99% of its time, it may only need to:

monitor;

analyze;

diagnose.

Occasionally, it needs to execute an administrative action.

Instead of maintaining elevated privileges permanently, it can receive authorization that is:

specific;

temporary;

limited to that action.

This is the same principle as Just-in-Time Access used in enterprise security.

Microsoft recommends precisely this model: stable identity, but elevated privileges granted temporarily through short-lived tokens, activation, or specific approval.

This dramatically reduces the period during which that capability is exposed.

Human-in-the-Loop Does Not Mean Approving Everything

There is also an opposite extreme.

If every step performed by an agent must be approved by a person, we probably have not built an agent.

We have simply built a more sophisticated interface.

The objective should not be:

Human-in-every-loop.

It should be:

Human-in-the-right-loop.

The architecture can classify actions by risk.

Low Risk

Execute autonomously.

Medium Risk

Execute with policies and monitoring.

High Risk

Require human approval.

Critical

Perhaps the agent should not possess that capability at all.

The question is no longer simply autonomy versus control.

It becomes:

what level of autonomy is appropriate for each type of decision?

And What Happens When the Agent Acts on Behalf of a Person?

This is another important topic.

There are at least two patterns.

Agent-as-itself

The agent operates using its own identity.

Agent-on-behalf-of-user

The agent executes an action delegated by a person.

These situations should produce different authorization models.

If I ask an agent:

“Show me my documents.”

it should not suddenly gain access to every document in the organization.

It should remain constrained by my authorization context.

AWS explicitly distinguishes between these two scenarios: agents acting on behalf of a user and agents operating autonomously.

This distinction needs to be clear from the solution design stage.

Multi-Agent Architectures Make This Even More Important

Now imagine:

Agent A calls Agent B.

Agent B calls Agent C.

Agent C executes an API.

Who authorized the action?

Which identity is being used?

Which permissions were inherited?

Can Agent B delegate a capability that Agent A does not possess?

The trust chain becomes much more complex.

That is why every agent-to-agent interaction should be treated as a new trust and authorization decision.

Microsoft recommends exactly this approach for multi-agent architectures.

And Every Action Needs to Leave Evidence

Security without auditability is incomplete.

For agents, logs need to answer questions such as:

Who initiated the request?

Which agent executed it?

Which model participated?

Which tool was called?

Which parameters were sent?

Which identity authorized it?

Which policy allowed execution?

Which resource was changed?

What was the result?

Microsoft emphasizes that logging only the LLM response is not sufficient; it is necessary to observe tool calls, scopes, and authorization decisions throughout the chain.

This is particularly important for:

security operations;

compliance;

forensics;

audit;

regulation.

A Simple Model for Thinking About Least Privilege for Agents

I would summarize the architecture in eight questions:

1. IdentityWho is this agent?

2. OwnershipWho is responsible for it?

3. PurposeWhy does it exist?

4. Data ScopeWhich data can it access?

5. Tool ScopeWhich tools can it use?

6. Action ScopeWhich operations can it execute?

7. ApprovalWhich actions require additional authorization?

8. AuditabilityCan we reconstruct exactly what happened?

If an organization cannot clearly answer these eight questions, the agent may not yet be ready to operate autonomously.

The Natural Evolution: Zero Trust for Agents

NIST has already begun discussing identity and authorization specifically for software agents and AI agents, recognizing that agent adoption requires appropriate identification and authorization mechanisms.

This points toward a natural evolution.

For years, Zero Trust taught us:

never trust, always verify.

For agents, we could adapt that principle:

never assume, always authorize.

It does not matter how intelligent the model is.

It does not matter how good the prompt is.

It does not matter how many tests have been executed.

An agent should possess only the capabilities required to perform its role.

Because intelligence should not imply authority.

And autonomy should not mean unlimited access.

From Copilots to Digital Actors

We are going through an important architectural shift.

In the first generation of enterprise AI, systems helped people produce information.

In the next generation, agents may execute an increasing share of the work.

That means companies will begin to have a new class of participants:

digital actors.

They will have:

identity;

credentials;

permissions;

responsibilities;

logs;

owners;

lifecycle.

And perhaps one of the most important decisions companies will need to make in the coming years will not be:

“Which model should we use?”

But:

“How much authority are we willing to give to an agent?”

The principle of Least Privilege provides a fairly simple answer.

Only the authority required. Only over the resources required. Only for the time required.

Because the purpose of governance should not be to prevent agents from acting.

It should be to allow them to act safely.