When to reach for it
- Multiple agents operate across different trust zones.
- Sensitive data or actions are involved.
- Security boundaries should be architecturally visible.
/pattern/least-privilege/
Each agent receives only the tools, data, and permissions its specific task requires — the principle of least privilege applied to agents, so a compromised or misdirected agent can reach only its own blast radius rather than the whole system.
In practiceA content-moderation agent is granted read access to the user-content database and write access to a quarantine bucket only, so even a prompt-injection cannot instruct it to delete production records.
Without itWithout least privilege, a single compromised or misdirected agent holds keys to the entire system, turning a model error into a platform-wide incident. See the anti-pattern →
When to reach for it
When it backfires
The tradeoff
A reduced attack surface is gained against higher role and permission management effort.
Each component gets only the rights it needs.
Multiple agents reuse the same 'shared' role for convenience. The role accretes every permission anyone ever needed; least privilege is the name, not the practice.
Fix · Bind permissions to the agent definition, not to a shared role. Generate the role from the declared toolset at deploy time.
The agent is granted only a 'read report' tool, but that tool authenticates with a service account that can also write. The agent's blast radius is the tool's permissions, not its own grant.
Fix · Scope the credentials the tool itself runs with, not just which tools the agent may call. Audit each tool's effective permissions against the agent's intended scope.
Keep going
Search patterns, frameworks, and pages.