Principles
Least privilege for AI agents, in practice
Everyone nods at "least privilege." Then the agent gets the broad key anyway, because narrowing it felt like work and the deadline was real. For AI workers the principle is not optional polish — it is the thing that bounds how bad a bad day can get.
Define the role around the task
Start from the job, not the catalog. What does this worker actually need to read and write to do its work? That set — specific tools, specific accounts, specific action classes — is the role. Everything outside it is not "maybe useful later"; it is unnecessary blast radius.
Practical rules that hold up
- Reads are cheap, writes are scoped. Be generous with analysis, strict with mutation.
- No standing access "just in case." If a need is occasional, gate it; do not grant it permanently.
- Separate roles for separate jobs. Don't let one over-broad worker absorb three tasks.
- Re-check scope when the job changes, and remove access the worker no longer uses — the audit log tells you which tools it actually touched.
Every permission an agent holds and never uses is pure downside.
Make the narrow path the easy path
Least privilege sticks only when scoping a worker is easier than over-granting it. Grantry makes the role the unit you configure — tools, connections, and gates per job — so the least-privilege version is also the default one.