Least Privilege: Give Only the Access a Task Requires

Every permission creates a possible action.

If an account is compromised or a script behaves incorrectly, its permissions define how far the damage can spread.

Least privilege grants only the access needed for a defined task, resource, condition, and duration.

It is not a one-time policy document; permissions must evolve as people and systems change.

A concrete example: report generation

A report generator needs to read approved reporting tables.

It receives:

read-only database access,
to one reporting schema,
from its workload identity,
during normal execution.

It does not receive database administrator permission, customer password access, or the ability to delete source records.

Subjects, actions, and resources

An authorization decision connects:

subject: who is acting,
action: what they want to do,
resource: what they want to affect,
condition: under which context.

"Database access" is too broad. Reading one view differs from altering every table.

Human access

People should receive roles aligned with job responsibilities.

Examples:

support can view account status but not payment details,
finance can export invoices but not modify application code,
developers can deploy to test without permanent production administration.

Role definitions should reflect real work rather than organizational titles alone.

Workload access

Applications, pipelines, functions, and devices need identities of their own.

One shared service credential makes it impossible to:

identify the actor,
revoke one workload,
or scope permissions independently.

Use workload roles and short-lived credentials where possible.

Read versus write

Read access can still be highly damaging when data is sensitive.

Separate:

read,
create,
update,
delete,
administer,
and delegate.

A backup service may need read and write to backup storage but should not delete source production data.

Resource scope

Limit permissions to exact resources:

one bucket prefix,
one database schema,
one queue,
one cloud account,
or records belonging to one tenant.

Wildcards are convenient and can silently include resources created later.

Time-bound access

Some access is needed only temporarily:

incident investigation,
migration,
vendor support,
or one deployment.

Just-in-time access grants a role for a short approved session and removes it automatically.

Expiration is safer than relying on someone to remember cleanup.

Conditions

Access can require:

multi-factor authentication,
managed device,
approved network,
business hours,
ticket reference,
or specific environment.

Conditions should supplement identity and permission rather than substitute for them.

Default deny

A default-deny model rejects actions unless a policy explicitly allows them.

This prevents new resources and actions from inheriting broad access accidentally. It requires usable role design so teams do not bypass controls to get work done.

Safe defaults must be paired with an efficient request path.

Separation of duties

High-risk workflows may require more than one role.

For example:

one person proposes a payment destination,
another approves it,
an automated system applies the verified change.

Separation reduces fraud and single-person mistakes but should not create meaningless rubber-stamp approval.

Privilege escalation

An apparently narrow permission can enable broader control.

Examples:

modify a role policy,
attach a privileged role to a workload,
change deployment code that receives secrets,
or update a startup script on an administrator machine.

Review indirect paths, not only obvious administrator actions.

Service account ownership

Every nonhuman identity needs:

purpose,
owner,
permissions,
credential method,
usage monitoring,
and removal condition.

Dormant service accounts are easy to forget and attractive to attackers.

Break-glass access

Emergency administration may need broad access.

Protect it with:

strong authentication,
restricted custody,
real-time alerting,
short sessions,
detailed audit,
and mandatory review.

If break-glass is used routinely, normal roles are inadequate.

Access reviews

Review access when:

a person changes role,
a project ends,
a service is replaced,
a vendor contract expires,
or on a regular schedule.

Compare assigned permissions with observed use, but do not assume an unused emergency permission is unnecessary without understanding its purpose.

Permission testing

Test allowed and denied cases.

Examples:

report generator can read approved view,
cannot alter data,
cannot read another schema,
cannot assume administrator role.

Negative tests prove the boundary, which successful operation alone cannot.

Audit

Record sensitive authorization events:

role grant,
role assumption,
policy update,
denied high-risk action,
and privileged data access.

Audit logs should identify the human behind a federated session where possible.

Usability

If least privilege makes ordinary work painfully slow, people will seek shared keys or administrator shortcuts.

Provide:

well-designed standard roles,
self-service temporary elevation,
clear denial messages,
and responsive access review.

Security controls must support the legitimate path.

Privilege creep

Permissions accumulate over time.

A user moves teams but keeps old access. A service receives one temporary permission that is never removed. Regular review and automated lifecycle integration reduce this creep.

Access removal is as important as access grant.

Discovering required permissions

Teams can start from documented actions, then use authorization logs and policy simulation to identify the exact permissions real work needs.

Observed use must be interpreted carefully: a disaster-recovery permission may be intentionally rare, while an unused broad wildcard may be obsolete. Record why exceptional access remains so future reviews do not have to guess.

Knowledge check

Which dimensions make an access grant precise?
Why should workloads have separate identities?
How can a non-administrator permission still enable privilege escalation?
What makes break-glass access different from a normal administrator role?
Why should authorization tests include denied actions?

The one idea to remember

Least privilege limits each human and workload to the actions, resources, conditions, and time required for a named purpose. Design usable roles, inspect indirect escalation paths, audit sensitive use, and remove access as responsibilities change.