Least-Privilege Scoping
Each agent holds only the permissions required for its declared tasks — nothing more.
This page is the complete instruction page for one pattern called "Least-Privilege Scoping." It explains the problem this pattern solves, the idea behind the solution, when you should (and should not) use it, and what happens afterward — both the good effects and the costs.
This matters because building AI agents is not just about making them clever. It is also about making them safe and predictable. Following a well-tested pattern like this one helps avoid common mistakes, and shows you exactly which safety rules and regulations it connects to, listed under "Standards Mesh" on this page.
Context
Agents inheriting broad user permissions, or using service accounts with blanket access, turn any prompt-injection or reasoning error into a potential breach.
Problem
Excess permission converts model error into security incident.
Forces
- Frictionless task execution vs bounded authority
- Static scoping vs dynamic needs
Solution
Derive the agent's permission set from its declared purpose. Permissions are minimum viable: specific resources, specific actions, time-bounded where possible. Require re-scoping as part of any purpose change.
Applicability
- All agents
- Particularly agents with write, delete, or transact capabilities
Anti-Patterns
- "Give it admin so it works"
- Same role for all agents
Consequences
- +Contained damage from any failure
- +Audit clarity
- −Fine-grained scoping is operational work
- −Can require new IAM primitives