How to Scope an AI Agent's Access to Your Workspace

Scope an AI agent's access the way you would scope a new contractor's: grant read access to the few areas it needs, add one write scope at a time when a specific task earns it, make sure the token can never do more than the person who created it, and log every call so you can see what it touched. In MCP terms, that means OAuth 2.1 scopes chosen at consent time, a 403 when the agent steps outside them, and an audit log on the server.

This post is the recipe we use for our own agents at Atrix, with the standards side taken from the MCP authorization specification and the product side from our own server, which has 49 grantable scopes as of October 2026.

Why agent permissions are different from user permissions

A person reads a screen before acting. An agent reads a tool description and acts in milliseconds, hundreds of times an hour, on text that may have come from a web page, an email or a ticket written by someone outside the company. Prompt injection is the usual example, but ordinary mistakes are more common: an agent asked to "clean up stale issues" that interprets "clean up" as "delete".

Two consequences follow. First, the blast radius of a wrong action is limited only by what the token can do, so the token must be small. Second, you cannot review each action in advance, so you need a log good enough to review afterwards.

User permissions answer "what may this person see and change?". Agent permissions answer "what may this program do on this person's behalf, for this task, this week?". The second question has a narrower answer.

What the MCP authorization spec gives you

The Model Context Protocol's authorization specification (the 2025-06-18 revision, the current one as of October 2026) treats an MCP server as an OAuth 2.1 resource server and the MCP client as an OAuth 2.1 client. The parts that matter for scoping:

Requirement	What it means for you
Servers MUST publish Protected Resource Metadata (RFC 9728) and answer 401 with a `WWW-Authenticate` pointer	The client discovers the authorization server itself; nobody pastes a token into a config file
Clients MUST use PKCE and SHOULD support dynamic client registration (RFC 7591)	Your agent host registers itself and runs the browser consent flow
Clients MUST send the `resource` parameter (RFC 8707) and servers MUST validate the token audience	A token issued for one server cannot be replayed against another
401 for a missing or invalid token, 403 for invalid scopes or insufficient permissions	Scope failures are explicit, so an agent can tell "not allowed" from "not logged in"
Authorization servers SHOULD issue short-lived access tokens and MUST rotate refresh tokens for public clients	A leaked token expires; a stolen refresh token is caught at next use
Token passthrough is forbidden	A server may not forward your token to a downstream API

The spec deliberately leaves the names and granularity of scopes to each server. It gives you the mechanism (consent, audience, 403) and leaves the policy to you. The rest of this post is the policy.

The recipe: reads first, widen per write, never exceed the person

Five rules, in the order we apply them.

Start with read scopes only, for the areas the task touches. An agent drafting a weekly status needs to read issues, goals and the feed. It does not need to read customers, pay or hiring. Pick the three or four read scopes and stop.
Add a write scope only when a named task needs it, and only that one. "Comment on the issue it implemented" needs issue-write. It does not need project-write, page-write or the ability to post to the team feed. If a write scope implies its read, that is fine; the reverse is never true.
Treat destructive and outward-facing actions as separate grants. Deleting, publishing, emailing and posting notifications are the actions you cannot take back. Keep them behind their own scopes, and ideally behind a confirmation the human sees.
A token must never exceed the person who minted it. If an agent token could read something its owner cannot, scopes have become a way to escalate. Resolve the owner's permissions on every call, not at mint time, so revoking the owner's access revokes the agent's.
Audit every call, and read the audit. Tool name, outcome, the kind and id of what was touched. Not the contents: an audit log full of customer data is a second breach waiting to happen.

The failure mode to avoid is the "connect everything" consent screen, where the agent host asks for all scopes at once and the person clicks approve because the list is long. Short lists get read.

Worked example: Atrix AI's 49 scopes

Atrix's MCP server is the one we administer, so it is the honest example. As of October 2026 it has 85 tools behind 49 grantable scopes, listed in the developer docs. The design choices map to the rules above:

Read and write pairs per area: work.read, work.write, crm.read, crm.write, pages.read, pages.write and so on. A write scope implies its read; nothing else is implied.
Named scopes for the actions you cannot undo or that reach outside: destructive, publish, email.send, feed.post. These are never implied by a write scope. feed.post is separate from feed.write because posting notifies people's phones with no opt-out.
Nine scopes also require the matching permission on the account behind the token: deal values, employment records, agreements, hiring, integrations, billing, invoices and changing products. The permission is checked on every call, so a token can never do more than its creator, and revoking someone's access kills their tokens' reach immediately.
Pay is not grantable at all. No scope reaches a salary and no tool selects a compensation record. Some data should not be one consent click away from an agent, and the way to guarantee that is to leave it out of the scope list.
Limits and audit: 120 calls and 30 writes per minute per token; every call logged with tool, outcome, subject kind and id, never contents.

What this costs: a teammate connecting Claude or Cursor sees a scope picker and has to think for thirty seconds. Linear's server, by comparison, offers a separate read-only URL, which is a simpler way to express "reads only". Both approaches work; ours puts the decision on the person, theirs on the URL.

Step-up: widen when the task asks, not before

The alternative to granting write scopes up front is step-up authorization: the agent runs with reads, hits a 403 on its first write, and the host asks the person to approve the extra scope for that session. The glossary entry on step-up authorization describes the pattern; the spec supports it through the 403 and a fresh consent round.

In practice it works like this. The agent drafts the status report (reads only). You approve the draft. It asks for feed.post to publish it. You grant it for this token, or you post the draft yourself. The write scope exists for exactly as long as the task needs it.

Step-up is slower than a broad grant on day one and faster from day two, because the set of scopes a given agent has earned stops growing once its tasks are stable.

A checklist you can paste into your security policy

Agents authenticate with OAuth 2.1 through the host's consent flow; no long-lived keys in config files except for CI.
Each agent token lists its scopes, its owner, its creation date and its last use.
Default grant is read-only for at most four areas.
Write scopes are granted per task and reviewed monthly.
Destructive, publishing, email and notification actions require their own scope and a human confirmation.
Owner permissions are resolved per call; revoking the owner revokes the agent.
Rate limits exist per token.
The audit log records tool, outcome, subject kind and id, and is reviewed weekly.
Some data (pay, at minimum) is reachable by no scope.

FAQ

What are MCP scopes?

OAuth 2.1 scopes that an MCP server defines to limit what a token can do, chosen by the person at the consent screen. The MCP spec requires servers to respond 403 when a call exceeds the token's scopes. The names and granularity are up to each server; see the glossary entry on scopes.

Should an AI agent get the same permissions as its user?

No. The user's permissions are the ceiling, not the default. Start with read scopes for the areas the task touches and add writes one at a time. The token should resolve the user's permissions on every call so it can never exceed them.

Is an API key in a config file acceptable for an agent?

For CI, where no browser exists, yes, with the narrowest scopes and a rotation schedule. For a person's laptop, prefer the OAuth flow: the token is scoped, short-lived, refreshable and revocable, and the spec requires PKCE and audience binding.

How do I know what an agent actually did?

From the server's audit log. Ask for tool name, outcome, and the kind and id of the thing touched, with timestamps. If the server only logs contents or only logs errors, you cannot reconstruct a session.

What should never be grantable to an agent?

Anything whose exposure you could not undo and whose use by an agent has no routine purpose. For us that is pay. Your list may add health data, bank details or source secrets. The protection is structural: no scope, no tool.

What is step-up authorization in MCP?

Running an agent with narrow scopes and widening only when a specific call returns 403, through a new consent round for the extra scope. It keeps grants tied to tasks rather than to an initial guess.

Next step

Open the consent screen for whatever agent host you use and count the scopes it asks for by default. If the answer is "all of them", that is the first thing to change. The Atrix MCP page lists the 49 scopes and what each unlocks, and the developer docs show the per-tool scope requirements.

How to scope an AI agent's access to your workspace: MCP scopes, least privilege and an audit trail