Define a per-tool, per-agent permission profile: what scopes the tool can use, what operations it can perform, what data it can access, and what external destinations it can reach. Express these as explicit IAM or authorization policy stanzas — not documentation comments that get ignored.
Practical examples: an email summarizer gets read-only mail access (no send, no delete). A database query tool gets SELECT on the orders table only (no UPDATE, no other tables). A network tool gets a specific allowlist of outbound destinations.
Least privilege reduces blast radius but doesn't eliminate the risk. If the tool's allowed scope is still over-broad for its purpose, misuse within that scope is still possible. And it doesn't address Type 2 (tool chaining) — an agent can still chain two appropriately-scoped tools into an unintended sequence.
Setting permissions based on what the tool can do (its full API capabilities) rather than what this specific agent needs to do. Ask: "If this tool were misused — what's the worst thing it could do?" Then scope to eliminate that worst case.
S01 (Tool Poisoning), S03 (Over-Privileged API), S04 (CRM + Email chain), S06 (DNS via ping), S07 (Database DELETE). It reduces the impact of every scenario involving excess tool capability.
Ask your team: does each AI tool your agents use have its own set of permissions — or do they all share one broad access key? A shared key means one compromised tool can reach everything. Ask whether permissions are scoped to what each specific tool actually needs to do its job.