Least privilege

What is least privilege?

Least privilege means every identity gets the minimum access it needs to do its job, and no more. A person, a service account, a data pipeline, a notebook or an AI agent should hold exactly the permissions its task requires, and only while the task lasts.

The idea goes back to Jerome Saltzer and Michael Schroeder, whose 1975 paper The Protection of Information in Computer Systems stated that every program and every user should operate with the least set of privileges needed to complete the job. The purpose is to limit the damage: if an account is phished or misused, tight permissions decide whether the fallout is one table or the whole warehouse.

Least privilege is narrower than zero-trust data architecture: zero trust decides whether to trust a request at all, least privilege decides how much it can touch.

The identities teams forget

Least privilege is easy to picture for people and hard to enforce for machines, which is exactly where it slips. A BI viewer can read reports but not edit datasets, and row-level security keeps that viewer to their own customers' rows. The service account behind a nightly load is what teams miss.

Non-human identities have no manager and never complain, so they collect broad rights for convenience and run unattended, an attractive target once an attacker is inside. NIST SP 800-53 is explicit that least privilege covers processes acting on behalf of users, not only the users themselves.

A pipeline that loads one source into one target needs read on that source and write on that table, not owner rights on the whole storage account. A notebook that explores production data needs read access, never the right to delete production tables.

How teams make it practical

Three habits keep permissions small over time:

• Start from deny. Grant nothing by default, then add the specific permissions a task proves it needs. This is Saltzer and Schroeder's fail-safe default: base access on permission, not exclusion.

• Elevate just in time. Give higher rights temporarily and let them expire instead of leaving standing admin access on an account. Microsoft frames this in zero trust as access for the shortest time required.

• Review access periodically. The NIST AC-6 control asks you to re-check assigned privileges on a schedule and remove the ones no longer justified. AWS supports this with last-accessed data that flags permissions a role has not used.

How you express them is a separate choice: RBAC bundles them into roles, ABAC derives them from attributes, and secret management guards the credentials behind machine identities.

Privilege creep

The honest failure mode is privilege creep. People change roles, join projects and cover for colleagues, and every move adds a permission that is almost never removed. Access piles up that nobody can account for. Temporary access is the classic culprit: someone gets admin rights to fix an incident, the incident closes, and the rights stay.

Creep is why least privilege is a habit, not a one-off setup. Periodic access reviews and clear ownership sit inside everyday data governance, keeping the gap between what an identity can do and what it needs from widening.