Agents need least privilege more than people do

Permission design for agents is routinely worse than permission design for humans, and the reason is mundane. Getting a scoped credential takes a week of back and forth with whoever owns the system. An admin key takes an afternoon. So the prototype gets the admin key, the prototype becomes the production system, and nobody goes back.

This is a worse problem with an agent than with a person for three reasons. An agent acts faster than anyone can intervene. It acts on instructions that may have originated with an untrusted party. And it has no intuition about which action is unusual, so it will not hesitate before doing something a person would have questioned.

Scope the credential to the workflow, not the system

The unit of access should be the specific action the agent needs, on the specific subset of records it operates over. Read access to open tickets in one queue, not read access to the ticketing platform. Write access to a status field, not write access to the record. This takes longer to arrange and it is the whole job, because every permission you grant beyond the workflow is a failure mode you have chosen to accept.

• Separate credentials per agent and per environment, so a compromise or a runaway loop is bounded and attributable.
• Read and write split into different credentials where the platform allows it, so a read-only failure cannot mutate anything.
• Hard caps on volume and value per action, enforced outside the agent rather than in its instructions.
• Every action logged with the credential, the input that triggered it, and the reasoning that led to it.
• A documented revocation path that someone can execute in minutes without a deploy.

An instruction in a prompt is a preference. A permission boundary is a control. Never let the first one do the job of the second.

Untrusted input is the default, not the exception

Any agent that reads email, tickets, documents, or web content is processing text written by people outside your trust boundary. That text can contain instructions. Treating the content an agent retrieves as data rather than direction is a design property, not a prompt you write, and the only durable version of it is that the agent simply cannot perform the dangerous action regardless of what it was told.

The practical rule: assume the model can be talked into anything it is permitted to do, then design so that the list of things it is permitted to do is short enough that this is survivable.

Do this at the start

Retrofitting least privilege onto a working system is unpleasant, because nobody knows which of the granted permissions are load-bearing and finding out means breaking things in production. Scope it at the start, when the cost is one conversation with the system owner rather than an archaeology project.