Least privilege in practice: what it looks like day to day

Least privilege means limiting users, and the processes acting for them, to the access they need to do their assigned tasks, no more. In practice that means role-based defaults, separate admin accounts, time-limited elevation, and regular review of who still needs what.

What the control actually says

NIST SP 800-53 AC-6 limits users and processes acting on their behalf to the access needed for assigned tasks. Note the scope: it applies to specific duties, to system processes, and across development, implementation and operation. Service accounts and pipelines count, not only people.

Habit one: start from roles

Give new people a role template, not a clone of a colleague. Cloning copies years of accumulated access. A role template is small by design and easy to reason about.

Habit two: split admin from everyday

AC-6(2) asks that people with security-level access use non-privileged accounts for non-security work. The practical form is a separate admin identity, or a just-in-time elevation, used only for admin tasks. If an attacker phishes the everyday account, they get a mailbox rather than the cloud console.

Habit three: make elevation temporary

Permanent admin is the default that causes most damage. Prefer access that expires: a ticket-linked grant for four hours, or a break-glass account that alerts when used. Expiry removes the need to remember to clean up.

Habit four: log privileged actions

AC-6(9) asks for logging of every execution of a privileged function. Without logs you cannot tell whether elevated access was used well. Send admin activity to a place the admins cannot edit.

Habit five: review privileges, not only accounts

AC-6(7) asks for periodic review of assigned privileges, with reassignment or removal where no longer needed. Review what each role can do, not just who exists. See how often to review user access.

Don't forget machines

Service accounts, CI tokens and API keys usually hold broader access than anyone intended, because they were created in a hurry. Give each its own identity, scope it to one job, set an owner, and set an expiry or rotation rule. A shared "deploy" token with admin rights is the common failure.

The same thinking applies to AI agents that act on your behalf: define what each can reach before it runs, not after.

A quick audit you can do this week

1. List all admin users in your cloud, identity provider and source control.
2. For each, write down why they need it. Remove anyone without an answer.
3. List service accounts and tokens. Note owner and last use. Disable the unused.
4. Check that admin actions are logged somewhere durable.

You will usually find more over-privilege than you expected. That is normal, and the fix is mostly deletion.

Safeguard offers agent identity and policies, gates and guardrails, which can help express what an automated agent may do. You can run a free scan at gold.safeguard.sh/scan.

Quick check

Sources

• AC-6 Least Privilege, NIST SP 800-53 Rev. 5

Last reviewed: 19 October 2026.