OAuth scopes and least privilege: right-sizing agent permissions

An AI agent with read-write access to everything is a single bad prompt away from destroying what it can read. Scopes are the mechanism OAuth gives you to prevent that: each scope is a permission, and the set you request is the set the agent gets. Least privilege for agents is mostly a scoping discipline — but it’s a discipline that’s easy to skip when a provider’s default is “request everything.”

Why scope sprawl happens

The path to sprawl is predictable. The first integration asks for the broadest scope “to be safe.” It works, so the next one copies it. Nobody wants to debug a 403, so nobody narrows anything. Six months later every agent in the fleet carries the same wide permission set, and the agent that only reads a calendar can also send mail.

The cost shows up in an incident, not in a code review. When a prompt injection makes an agent call an API, the call succeeds with the scopes the token carries — wide scopes turn a mistake into a breach.

Scopes as a blast-radius control

Think of scopes as the blast radius of any single compromised call. Narrow scopes mean a bad tool call fails with a 403 instead of mutating data. Concretely:

• request the minimum scope set for the task, per integration
• prefer read-only scopes where writes aren’t required
• avoid wildcard or “all” scopes entirely
• if the provider offers granular scopes, one per resource type, use them

A token that can only read one calendar can’t exfiltrate your contacts — the failure is loud and logged rather than silent.

Right-sizing: a practical checklist

1. Enumerate the actual API calls the agent makes. Every scope should map to a real call in the code.
2. Split agents by job. A research agent and a deployment agent shouldn’t share a token or a scope set.
3. Set scopes at token issuance, not only at registration. Many providers let the token request narrow the registered scopes — do both.
4. Test with the narrowest set. If integration tests pass with minimal scopes, the wide set was never needed.
5. Review quarterly. Agent tooling changes faster than scope sets rot; an annual review is too slow.

What scopes can’t do

Scopes constrain what an API allows, not what an agent attempts. A scope-limited agent can still be manipulated into leaking data it can read, or into abusing the legitimate calls it has. Scopes also say nothing about rate limits, quotas, or data retention — those are enforced elsewhere. Scopes are a necessary layer, not a complete control — pair them with output sanitization, logging, and the assumption that the agent may be compromised.

Wiring narrow scopes into agent workflows

The practical blocker is usually token management: if issuing a narrow token means a manual browser flow per agent, people reuse one wide token instead. Tooling that makes per-agent, per-scope tokens cheap changes the economics. trustless oauth login issues compact single-line JSON token entries with auto-refresh and single-use refresh-token rotation, and trustless oauth status reports whether a token is valid, expired, or needs re-authorization — the project is at https://github.com/ikkun1222/trustless.

Scopes are the cheapest security control you already have. The question is whether your agents actually carry the narrowest set that works — what would break if you cut every agent’s scopes in half today?