How do you implement the principle of least privilege f...

The design principle is the same one that governs database roles, and it should be applied with the same discipline: start at zero access and grant only what the specific task genuinely needs, never “just in case.”

In practice that means scoping on several axes at once, not just read-versus-write:

• Resource scope — a support agent should query one customer’s orders by ID, not run unrestricted queries against the whole orders table.
• Action scope — read-only where a write isn’t the point of the tool; a refund tool capped at a dollar amount below which it can act automatically, with anything larger requiring escalation rather than a blanket “can issue refunds” permission.
• Time scope — permissions that expire rather than standing indefinitely, so a credential leak or a stale configuration doesn’t leave a door open long after the task that needed it finished.

The reason this matters more for agents than for most software is that agents make the call on when to use a permission themselves, at runtime, based on a model’s judgment rather than a hardcoded path. A well-scoped agent that’s compromised or simply makes a mistake can still only create a wrong support ticket or email the wrong thing to one customer; a broadly-privileged agent making the same mistake can touch data or take actions far outside what the task ever required.