Permission playbook
Grant the least it needs.
Nobody sets out to give an agent too much access. It happens in six reasonable additions over a year, each made for a good reason that no longer applies — which is why the interesting part of this is not the first decision but the review.
Start from nothing, not from everything
A new agent can do nothing at all, and that is the right starting state. Work forward from the job: what does it have to read to decide, and what does it have to do to finish? Most working agents end up holding three or four capabilities, and a permission list that fits on a card is a sign the agent is well scoped rather than crippled.
Separate reading from doing, deliberately
Agents almost always need to read far more than they need to change. Treat them as two lists and grant them at different times: a fortnight of read-only running tells you whether the agent is drawing the right conclusions, before it can act on a wrong one.
Drafts before sends
Where a capability has a draft equivalent, grant the draft first. An agent leaving prepared replies for a person to send is useful immediately and cannot embarrass you. Many teams run that way for two weeks and then grant send having read forty drafts, which is a far better basis for the decision than a description.
Scope to records, not just to capabilities
"Read customers" is not a scope. Its own assigned accounts, one team's, one region's — an agent that needs three accounts should not be able to read three thousand. This is the single most effective control available and the one most often skipped, because the broader grant is easier to configure and works fine until it doesn't.
Put the threshold where the judgement starts
The point of an approval is not to review the agent's work; it is to catch the cases where the answer depends on something the agent cannot see. A reminder at day nine needs no judgement. A payment plan at day forty does. Find that line and put the approval on it, rather than approving a sample of everything.
The review is the whole exercise
Every agent should carry a review date and a named reviewer. The review that matters asks two questions: which granted capabilities has it not used in ninety days, and is the reason each was granted still true? Unused access is almost always removable, and removing it costs nothing.
- Which capabilities has it not called in ninety days?
- Is the reason each was granted still true?
- Has its scope widened without its job changing?
- Does the owner still exist, and do they know they own it?
Refuse the convenient thing
The request that should always be declined is a wide capability standing in for several narrow ones — a general query tool, a broad write scope, an integration credential shared between agents. Each is genuinely easier to set up, and each removes your ability to say what the agent can actually do.
Give AI a job.
Build an agent, choose what it can access, define what it may do, and deploy it to work safely across your business.
No code required · Full SDKs and API · Stop any agent instantly · [email protected]