Principle of Least Privilege in App Authorization

The principle of least privilege says that every identity should have only the access its task requires. It’s one of the oldest rules in cybersecurity and one of the easiest to agree with. Implementing it isn’t always easy, though, and maintaining it as you scale is harder. Access is usually minimal when it’s first granted, then grows: people change roles and keep their old permissions, temporary grants never expire, and roles get broader because a few broad roles are easier to manage than many precise ones.

In customer-facing applications, that privilege creep plays out across every user, every business customer’s tenant, and now every AI agent acting on a user’s behalf. This guide covers what least privilege means in app authorization, why sticking with it gets difficult, and how your choice of access control model can help you achieve it.

At a glance

• Least privilege means granting each identity the minimum access its task requires, which limits the damage a compromised account, token, or agent can do.

• Access tends to drift upward through privilege creep, role explosion, standing access, and permissive defaults, so least privilege needs ongoing maintenance.

• The access control model sets a limit on precision. Roles alone can’t express access to one specific document, so object-level access needs relationship- or attribute-based checks.

• Entitlements, the access an identity actually holds, are where least privilege is measured.

• An AI agent’s access should be scoped to its task, last only as long as the task, and never exceed the access of the user who delegated it.

What is the principle of least privilege?

The principle of least privilege is the practice of giving each identity the minimum access it needs to do its job. NIST’s definition of least privilege frames it as a design property: each entity gets only the resources and authorizations it needs to perform its function. The identity can be a person, a service, or an AI agent, and the access can be permission to read a record, call an API, or change a setting.

The reason least privilege is usually codified as a principle is because it limits the blast radius of a compromise. A stolen session for a read-only user exposes what that user can read, while a stolen session for an over-scoped admin can expose an entire tenant. The same logic applies to virtually any area of computing, even running code during development: bugs in software are harmless if they run in an isolated environment, but disastrous if deployed to production apps. 

OWASP’s 2025 Top 10 on broken access control ranks the category as the top web application risk, reports finding some form of it in every application tested, and lists least privilege violations—where access is open to anyone instead of granted to specific roles or users—as a typical example.

In an application, least privilege has several dimensions, with each being a separate way access can be too broad:

Roles handle the action dimension well, and tenant-scoped roles can handle tenants. Resources and time are where least privilege most often breaks down, and it’s where most organizations begin to experience the consequences of non-adherence.

Why is least privilege hard to maintain?

Least privilege usually erodes after access is granted, because granting and removing access aren’t symmetric. A grant happens because someone asks for access and has a reason. Removal happens only if someone notices the access is no longer needed, and usually nothing prompts that. 

There are four main patterns that arise when least privilege starts to slip:

• Privilege creep is the gradual buildup of access as people change teams, projects, or responsibilities. New access gets added for a user’s new job and their old access still stays, so long-tenured users end up holding the union of every role they’ve had. In B2B applications, this happens inside each customer’s organization, where the application has no direct view of who changed roles.

• Role explosion happens when real access needs don’t fit neatly into roles. Each exception either becomes a new role, until there are hundreds of near-duplicates nobody can audit, or gets handled by assigning an existing, broader role that grants more than the task needs. Both outcomes undermine least privilege, and role explosion is often what pushes teams from RBAC toward relationship-based models.

• Standing access is access granted for a one-time task that never ends. A support engineer gets admin rights to resolve a ticket, or a contractor gets access for a project, and the grant has no expiration, so it outlives its purpose. We see this increasingly with the static API keys often held by AI agents rather than the safer, sanctioned delegated tokens that agent credential best practices recommend. 

• Permissive defaults are access rules that allow by default, like when a new endpoint, feature, or resource type ships without a check or inherits a broad one. As with long-lived access, this is increasingly a problem with AI agents: instead of receiving ephemeral tokens, they automatically use the same shared service account or the same broadly scoped API keys as traditional machine identities.

How does access control enforce least privilege?

Access control is how an application turns least privilege into a decision on each request: allow or deny this identity this action on this resource. The application defines the rules, and evaluating them is often handled by access control software such as an authorization library, a policy engine, or an identity platform.

The access control model determines how precisely those rules can be written, and so how close to least privilege an application can get. If roles are the only tool, letting one user edit one document means giving them a role that can edit every document. That’s over-provisioning by design rather than by mistake.

An access control list (ACL) is the oldest of the four, the most literal, and the one you’re least likely to actually set up in modern authorization. In ACL, each resource simply carries its own list of who can do what. Role-based access control (RBAC) groups permissions into roles such as admin, member, and viewer, which makes access easy to assign and reason about, but coarse. Attribute-based access control (ABAC) evaluates conditions like a user’s department, a tenant’s plan, or the time of a request. Relationship-based access control (ReBAC) derives access from how identities relate to resources, the model behind sharing in collaborative tools, where access follows ownership and membership.

Most applications combine models rather than choosing one. Roles cover broad tiers, relationships cover object-level access, and attributes cover context. Tenant scoping cuts across all of them. In Descope, for example, a single user can belong to multiple tenants with different roles and permissions in each, and those roles and permissions are carried in the user’s session token. ReBAC can complement RBAC or replace it when an authorization model is mostly relationship-based.

What is fine-grained authorization?

Fine-grained authorization (FGA) is an umbrella term for access control that enforces access at the level of individual resources and request context rather than broad roles. ReBAC and ABAC are its two common forms. Where a role answers whether editors can edit documents, FGA answers whether this user can edit this document.

FGA addresses the flat over-provisioning often introduced by static roles, potentially making it easier to achieve least privilege. An individual agent or user’s access can match exactly what a task needs, like a single document or only one project’s records, without also getting access to all the documents a role might touch. However, FGA’s granularity only shifts the burden of maintaining least privilege rather than eliminating it. Every relationship and attribute is part of a framework that has to stay up-to-date, and stale relationships are FGA’s version of privilege creep. 

FGA audits are also quite different from RBAC. With roles, listing who can access something means reading role assignments. With relationships, access can be inherited through a chain, such as a member of a team that owns a folder that contains a document, so answering “who can reach this?” takes a query against the relationship graph. Authorization systems built for FGA provide those queries. Descope’s ReBAC checks, for example, can return who has access to a given resource and everything a given identity can reach.

As you scale, you should consider how your ReBAC schema is defined at regular intervals, not just once when initially setting up your auth. There’s no one-size-fits-all method for achieving least privilege, and you shouldn’t be discouraged from trying out different combinations: RBAC alone, ReBAC with RBAC for specific environments, or all three (RBAC, ReBAC, and ABAC) for different scenarios in the same organization. 

What is an entitlement?

An entitlement is a specific access right an identity actually holds, such as permission to view billing in one tenant or edit one project. Roles, groups, relationships, attributes, and direct grants are all ways of granting entitlements. The entitlement is the result.

The distinction matters because least privilege is measured at the entitlement level. A role definition can look appropriate while the people holding it accumulate entitlements from other roles, inherited relationships, and old grants. Reviewing roles shows what access was intended, while reviewing entitlements shows what access exists.

In SaaS, “entitlements” also commonly means the features a customer’s plan includes, such as single sign-on (SSO) on an enterprise tier or higher API limits on a paid one. That sense is about what a tenant has bought rather than what a user needs, but the two combine: a user’s effective access is bounded by both their own permissions and their tenant’s plan. Descope’s ABAC, for instance, can gate features on tenant attributes such as subscription tier.

How does least privilege apply to AI agents?

AI agents strain least privilege in two ways. Firstly, an agent decides which tools to call at runtime, so the access it needs can’t be fully listed ahead of time the way a role’s permissions can. Secondly, agents also usually act on behalf of a user, so two identities’ access matters at once: the agent’s and the user’s. The concern is widespread. In Descope’s 2025 State of Customer Identity survey, 57% of respondents said they were concerned about AI agents accessing unauthorized data or sharing it with unauthorized users.

For delegated access, least privilege means an agent’s access is no broader than the task requires and no broader than the delegating user’s own access. An agent reconciling a user’s invoices needs read access to those invoices, not the user’s full account, and never access the user doesn’t have. Duration of access for agents matters more than it does for people, since an agent’s access only needs to last as long as the task. That’s why agent credentials are typically short-lived, narrowly scoped tokens rather than long-lived API keys or a borrowed user session.

In OAuth terms, the agent requests specific scopes, the user consents, and the authorization server issues a short-lived token limited to what policy allows. When the agent calls downstream services, token exchange can issue a narrower credential for each hop while keeping the original user’s identity attached for auditing. Descope’s Agentic Identity Hub follows this pattern: Policies determine which scopes an agent can request or a user can consent to, and agents get their own short-lived, scope-limited credentials rather than the delegating user’s token. Agents that act without a user typically authenticate with the client credentials flow, and agents running on cloud infrastructure can use workload identity federation to prove their identity without a stored secret.

What does least privilege look like in action?

Because the patterns that erode least privilege never stop, the practices that preserve it are ongoing too. Each one counters a specific pattern:

Lifecycle-driven access is harder in B2B applications, because the lifecycle events happen inside the customer’s organization. When an enterprise customer connects its identity provider over System for Cross-domain Identity Management (SCIM), role changes flow into the application automatically. Just-in-time provisioning through SSO creates accounts on first login but gets no signal when someone leaves, so it covers the start of the lifecycle but not the end. Descope, for example, maps SCIM groups to roles, so a group change in the customer’s directory becomes a role change in the application. The customer’s IT admins also can configure SCIM themselves through the SSO Setup Suite.

Applying least privilege with Descope

Descope supports each layer this guide describes: tenant-aware roles for broad tiers, ReBAC and ABAC for per-resource and contextual decisions, SCIM provisioning to keep roles in sync with customers’ directories, and the Agentic Identity Hub to issue AI agents short-lived, policy-scoped tokens. To try it, sign up for a Free Forever account, book a demo to talk through an authorization model for a specific app, or start with the Descope authorization docs.

FAQs about least privilege