AI Guides › Skills & Agents

The Difference Between An Agent's Scope And Its Permissions

By Nigel Guy · 2 min read

People set up an agent by describing the job in a sentence — "keep my inbox tidy," "manage this spreadsheet" — and then accept whatever permission tier the platform offers as a rough match for that sentence. It rarely is. Scope is the job you actually intend; permissions are the technical grants the agent ends up holding, and the two drift apart almost every time, usually with permissions running wider than scope, because platforms tend to bundle access in coarser units than any one task needs.

The mechanism

1. Write the scope in one sentence. Not a feature list — a single sentence naming what the agent is for and, ideally, what it's explicitly not for. If you can't compress it to one sentence, the scope isn't defined yet, and nothing downstream will be either.
2. List every permission actually granted, not the ones you assume come with the feature you turned on. Read the platform's own permission screen, not the marketing description of what the integration "does."
3. Map each permission to a line in the scope sentence. Anything granted that doesn't map to anything in scope is excess permission — access the agent holds but has no stated job needing it.
4. Flag scope with no matching permission too. This is a smaller risk than excess permission, but it usually means the agent will quietly fail or ask for access mid-task instead of failing at setup, which is a worse time to discover the gap.
5. Re-run this check when scope changes, not only when permissions change. People notice a new permission prompt; almost nobody notices that the job they've asked the agent to do has quietly grown past the sentence they wrote for it.

What to skip

Skip debating scope in the abstract without a concrete permission list next to it — the mismatch only becomes visible once you're looking at both side by side. And skip assuming that a platform's named permission tier ("full access," "editor") was designed around your specific scope; it was designed around a generic use case, and yours is rarely generic enough for the fit to be exact without checking.

Guardrails

• Platform permission systems are usually coarser than the scope you actually want — you often can't get the narrow grant you'd prefer, only a wider one. When that's true, write down the excess explicitly and manage the risk consciously rather than pretending the mismatch isn't there.
• This check is about drift, not distrust — the goal is catching the gap between intention and access before something acts on it, not assuming every agent is misconfigured.
• Anything with excess permission touching money, external communication, or anything hard to reverse deserves the narrower grant even if it's more setup effort, or a human in the loop until the platform offers one.

All 751 AI guides · JulieMango plans from £17/mo