Least Privilege

Security Objective

Least privilege is the control that determines how much authority exists in the first place: which identities an agent deployment holds, which roles and scopes those identities carry, which resources, tools, data and destinations are reachable through them, and how long all of that persists. NIST defines least privilege as granting only the minimum access privileges necessary to accomplish assigned tasks, and NIST SP 800-53 Rev. 5 control AC-6 states the general requirement in its control catalog. Neither is agent-specific, which is exactly why they apply: they define the property every agent deployment should inherit, not an agent mechanism.

For AI agents this property matters disproportionately, because the model's interpretation of language is probabilistic while the authority behind it is not. A successful injection, a retrieval error or a plain misunderstanding does not create new permissions. It can only act through authority that already exists. Reducing that authority is the control this page covers.

Identity and policy facts are resolved from authoritative stores, out of band, and the envelope, reach and scope are system-enforced constraints rather than model-authored text. The user task remains variable content, and a system component does not make the content it carries trusted. A narrower envelope changes the maximum consequence of anything the agent attempts; it does not change which request is permitted, which remains the job of authorization at execution time.

This page is deliberately not a generic identity and access management article. Every section is framed against agent workflows, model influence and blast radius.

Threat Model: Influence Acting Through Existing Authority

The threat model is simple and it is the same one every attack article on this site converges on: the model can be influenced by content it processes, and the consequences of that influence are determined by the authority available at that moment.

Least privilege does not reduce the probability of influence. It reduces the set of effects that influence can reach, which is a different and independently testable property. The attack-side perspective is documented in AI agent prompt injection, multi-agent prompt injection and persistent prompt injection.

Standing Authority vs Task-Scoped Authority

Standing authority is what an identity can do at any time, independent of any task. Task-scoped authority is what a specific task, session or delegation makes available, and only for its duration. Agent deployments tend to grow the first and neglect the second, because standing grants are easier to wire up.

The objective is not to eliminate standing authority, which is rarely possible, but to shrink it to what the deployment genuinely always needs and to move everything else into bounded, task-derived grants.

Effective Permissions and Aggregate Privilege

The authority an agent actually holds is the union of everything attached to it: direct roles, group memberships, tool registrations, downstream entitlements reachable through its credentials, and integrations that act on its behalf. The configured role is often only a small part of that union.

Microsoft's vendor guidance on least privilege for AI agents, labelled here as vendor guidance, recommends reviewing the aggregate or effective permissions of agent identities rather than only the roles directly assigned. The point generalizes: effective access reviews, not configuration reviews, are the unit of assurance.

Unique Workload Identity vs Shared Credentials

An agent that acts through a shared credential inherits everything that credential can do and leaves no way to attribute its actions separately. A unique workload identity is the precondition for scoping, review and revocation at agent granularity.

Microsoft's Zero Trust guidance for AI agents, again vendor guidance, describes dedicated agent identities bound to task and user rather than shared or standing credentials, and its companion guidance discusses managed identities and workload federation as ways to avoid distributing secrets at all. The architectural point does not depend on the vendor: one agent, one identity, scoped to that agent's actual work.

Read and Write Separation

Most agent tasks are read-heavy: retrieve, summarize, compare, draft. When the same identity also carries write, send, delete or purchase rights, every reading task silently carries consequence authority it does not need.

Read/write separation interacts with authorization but does not replace it: a read-only envelope still needs authorization to decide which reads are permitted, and a write step still needs exact-action evaluation before it executes.

Resource, Tenant and Workspace Scoping

Scope answers where an identity's authority applies. The narrower the scope, the smaller the set of objects an influenced agent can touch, regardless of what its permissions are within the scope.

Tool and Action Exposure Minimization

Every registered tool extends the action space available to the model. Tool exposure minimization asks which tools a task actually needs and removes the rest from the session, so that a steered plan cannot even name an action the deployment never intended.

Microsoft's vendor guidance recommends denying unreviewed tools, integrations and cross-tenant paths by default rather than registering everything that might someday be useful. Two boundaries apply here. First, exposure is reach, not permission: a tool being unavailable reduces what can be attempted, while whether an available invocation may run is decided by authorization. Second, exposure per task beats exposure per deployment: the safe default is the smallest tool set the current task class requires.

Data Access Minimization

Data access is the input side of privilege. An agent that can read only one workspace cannot leak, corrupt or be steered by content outside it, and an agent that never sees a secret cannot disclose one.

The boundary with information flow control matters: this section decides what data the agent can reach at all; information flow control decides whether data that was reached may travel to a particular destination. Both are needed, and they fail independently.

Outbound and Network Reach

Outbound reach determines which destinations an agent's tools can talk to at all: which hosts, which protocols, which external services. Reducing that reach shrinks the set of places influenced behaviour could send anything.

The boundary to the egress control is explicit: this page covers reducing reach - not having a path to most destinations. Deciding which destinations, protocols and ports a permitted path may reach is the job of network and egress restrictions; whether particular data may cross it is decided by information flow control. An agent with no path to external hosts cannot exfiltrate through them, but an agent with a path still needs flow policy on what may cross it.

Just-in-Time and Time-Bound Elevation

Some tasks genuinely need more authority than the daily baseline: a migration, a one-off export, an administrative fix. The least-privilege answer is elevation that is requested for a purpose, granted for a bounded window, and returned automatically, rather than a permanently wider envelope.

Microsoft's vendor guidance describes just-in-time and time-bound privilege for agent identities, and its companion guidance discusses privileged access management for elevation workflows. The principle is older than any product: keep the standing envelope small and make every exception temporary, explicit and auditable.

Credential Lifetime vs Privilege Lifetime

Two clocks run on every grant, and confusing them produces quiet over-privilege. Credential lifetime is how long the secret or token remains technically valid. Privilege lifetime is how long the grant behind it should exist at all. A short-lived token on a permanently broad role is still permanent broad authority, re-issued continuously.

Microsoft's vendor guidance discusses short-lived tokens and managed identities to reduce credential lifetime; the complementary discipline on privilege lifetime is ownership and review, covered in the lifecycle section below.

Delegated Authority vs Workload Authority

An agent usually holds authority of two different kinds. Delegated authority is a bounded subset of a user's rights, handed to the agent for a task. Workload authority is what the service itself is entitled to do, independent of any user.

How a concrete request is evaluated under either source - including preserving the initiating principal - belongs to agent authorization.

Cross-Tenant, Guest and Integration Paths

Privilege rarely stops at the tenant boundary. Guest invitations, federated access, marketplace integrations and automation platforms can each carry an identity's effective reach into other tenants or back into this one through a second door.

The vendor guidance referenced on this page recommends denying unreviewed cross-tenant paths by default. The general rule is the same as for tools: a path that has not been enumerated and reviewed is a path that should not exist for the agent.

Permission Inheritance and Transitive Reach

Effective permissions are transitive. A role implies scopes, a group implies roles, a credential implies downstream entitlements, and an integration implies whatever its own credentials can do. Each hop is locally plausible; the composition is what matters.

Transitive reach is why effective-permission reviews must follow credentials and connectors rather than stop at role assignments, and why a new integration is a privilege change, not a feature change.

Permission Creep, Stale Grants and Ownership

Grants accumulate because adding is easy and removing is scary. Tasks end, prototypes become production, team members change, and the agent's envelope keeps every right it ever needed. Stale grants are standing authority with no current justification - pure attack surface.

Microsoft's vendor guidance recommends re-reviewing agent permissions when workflows, tools or data scope change. Access review tooling can automate the cadence; it cannot supply the judgement about what the agent still needs.

Break-Glass and Operational Exceptions

Operations sometimes need authority outside the normal envelope: an incident, a recovery, an urgent fix. The least-privilege answer is not to widen the standing envelope for these cases, but to define a narrow, monitored exception path.

Boundary to Agent Authorization and Other Controls

The most important sentence on this page: least privilege decides how much authority exists; agent authorization decides whether one concrete request may use it. A least-privilege system can still authorize a bad request inside its envelope, and a perfect authorization layer over a huge envelope still leaves a huge blast radius if that layer fails.

Deny by Default for Unreviewed Capability

Deny by default has a specific meaning on this page: a capability - a tool, an integration, a scope, a cross-tenant path, a destination - that has not been enumerated, assessed and approved is not available to the agent. Availability is the output of review, not the starting point.

This is a provisioning discipline, and it composes with the request-time deny-by-default of agent authorization: one governs what exists, the other governs what runs.

Worked Scenario: Same Influence, Two Authority Envelopes

The scenario is synthetic, bounded and non-operational. Its purpose is to show that identical model influence produces different consequences under different authority configurations. It demonstrates no technique.

What the Scenario Does and Does Not Prove

A worked scenario shows mechanism, not coverage. The assurance comes from the inventory, review and measurement work in the next two sections.

Telemetry, Inventory and Effective Access Review

Least privilege is maintained, not installed. The operational base is a current inventory of identities, grants, tools, credentials and integrations, plus telemetry that shows which of it is actually used.

Testing and Metrics

Each measure is reported separately with its denominator stated. There is no composite least-privilege score, because a single number hides which dimension regressed.

Benign task success is reported separately as utility and is never folded into a security figure: a deployment whose agents can do nothing scores perfectly on every privilege measure. Controlled tests - simulated influence against representative tasks - measure whether the envelope, not the model, is what prevented the consequence.

To practice judging authority envelopes, try the Least Privilege lab.

Incident Response and Common Mistakes

After an influence event or an unauthorized action, the least-privilege questions are about reach: what could the affected identity touch, what did it touch, and what must shrink so the next event is smaller.

On source use: the NIST definition and AC-6 are general, authoritative guidance and are not agent-specific; they are used for the principle, not for agent claims. The Microsoft pages are vendor guidance and are labelled as such, with product-specific behaviour not generalized. OWASP ASI03 is cited as a neighbouring risk framework for identity and privilege abuse, not as a least-privilege standard. No statistics or benchmark figures are claimed anywhere on this page. The request-side counterpart of this control is documented under agent authorization, and the attack-side motivation lives in the attack library.

Frequently Asked Questions