How do I scope permissions for an AI agent?
Scope by three axes: which objects, which channels or accounts, which actions. Issue one token per agent per purpose, default to read, and put sends behind review.
The short answer
- Scope an AI agent's permissions along three axes. Which objects it can touch (contacts, deals, a specific pipeline). Which channels or accounts it can act through (a mailbox, a LinkedIn queue, a specific sender). Which actions it can take on each (read, write, send, delete).
- Issue one token per agent per purpose rather than a shared token across agents. Without that separation, an audit log cannot tell you which agent performed a given action.
- Default every new token to read access. Add write permissions per action class as the agent proves out. Put anything that sends externally or deletes a record behind a review step, however much trust the agent has earned elsewhere.
- The scopes that matter are the narrow ones. A token that can write to one pipeline and send through one mailbox is safer and easier to reason about than a token scoped broadly 'for flexibility'.
Why three axes, not one
Most teams start scoping by object alone. This agent can see deals, this one can see contacts. That is a reasonable first cut. It misses two other dimensions that matter as much. An agent scoped to "deals" but not restricted by channel could, in principle, act through any connected mailbox or sender the CRM has. An agent scoped to "deals, read and write" with no action-level distinction could delete a deal as easily as it edits a field, even though those are very different levels of risk.
Scoping by object, channel and action together closes those gaps. An agent built to draft follow-up emails from deal notes needs read access to deals, write access to drafts on one mailbox, and nothing else. That is a narrow, legible scope someone can look at and understand in a sentence. That is the goal.
The three scoping axes
| Axis | Example scope | Typical default |
|---|---|---|
| Objects | Deals and contacts in one pipeline; no access to billing or user records | Narrow to what the agent's job requires, nothing adjacent |
| Channels or accounts | One connected mailbox, one LinkedIn queue, one sender | Named explicitly, never 'all connected channels' |
| Actions | Read always; write per action class; send and delete off by default | Read on, write added as needed, send and delete behind review |
What a well-scoped token looks like in practice
Start every new agent at read-only across the objects it needs to reason over. Add write permissions one action class at a time as the agent's job requires them. Watch the audit log after each addition rather than granting everything the agent might conceivably need up front. Sends, whether email, LinkedIn messages or marketplace proposals, and destructive actions like deletes or merges, stay behind a review step even once an agent has a track record. The cost of a mistake there is different in kind from a mistake in an internal note.
Disclosure: SalesCrew is our product. Its MCP tokens are scoped by the same three axes as a human user's access: channel, profile and area, matching whatever role the token represents. A token can be limited to one mailbox, one Upwork profile, or one part of the app. Every token's calls are written to the audit log with the token named as the actor. A narrow scope also makes the log easier to read afterward.
'Admin token for the pilot, we'll tighten later' is how pilots ship broad
Questions
- Should every agent get its own token?
- Yes. One token per agent per purpose is the pattern to default to. A shared token across several agents makes it impossible to tell from the audit log which agent took a given action. That defeats the point of scoping.
- What is the difference between scoping by object and scoping by action?
- Object scope answers 'which records can this token touch' (deals, contacts, a specific pipeline). Action scope answers 'what can it do to them' (read, write, send, delete). A token can be broad on one axis and narrow on the other, like read access to every contact but write access to none.
- How often should scopes be reviewed?
- Whenever an agent's job changes, and on a regular schedule regardless. Scopes tend to build up rather than shrink over time. A token issued for a two-week pilot that is still active with the same broad scope six months later is the common failure.