Tools
Take control over your API & AI Agents OAuth scopes
OAuth says how to send a scope, not how to name, size or govern one. Each team adds its own, and AI agents make the cost of a broad scope visible.
AI agents raise the stakes. In a UK AI Security Institute study of 177,436 MCP tools created between November 2024 and February 2026, the share of "action" tools, those that modify external environments, rose from 27% to 65% of total usage, measured by downloads [1]. A scope that is too broad no longer only lets an agent read. It lets it change things.
Scopes are created project by project. Duplicates and inconsistent names pile up in the identity provider, unused scopes are never removed, and access reviews cannot say what each scope allows. Every new integration starts with an investigation to find the right scope, and a forgotten scope can still be granted to any client.
Observed in practice. No public measurement exists yet.
One scope grants a whole system. Given to an AI agent, crm:write lets it change or erase the whole customer base, and one malicious instruction hidden in a document is enough to turn it. In reaction, teams create many narrow scopes, and every new feature then needs one more scope, one more review and one more setting.
The IETF notes that OAuth scopes are "sufficient to implement static scenarios and coarse-grained authorization requests" but "not sufficient to specify fine-grained authorization requirements" [2].
An MCP tool that refunds an unhappy customer may touch four APIs. Should it get a dedicated scope, or the ten existing ones? The debate slows down architecture reviews, and without an answer the tool often ends up with the sum of all the rights, far more than its task needs.
As a 2026 research paper puts it, "OAuth scopes bind to operators, not to the operations (operator + operands) implied by a user’s task" [3].
Many narrow scopes mean many authorization prompts. Users end up approving without reading, so their consent no longer proves anything, or they give up and the agent is not adopted. Product teams then bundle scopes back into broad ones.
The MCP security best practices list "Consent abandonment: users decline dialogs listing excessive scopes" among the risks of poor scope design, and "Bundling unrelated privileges to preempt future prompts" among common mistakes [4].
ScopeNeat helps you name an owner for each scope, shows where scopes are too broad or duplicated, and ranks each MCP tool by what its scopes can reach.
Paste your scopes, your OpenAPI description or the tool list of your MCP server below. Everything runs in your browser. Nothing you paste leaves this page.
Fill in one box or several. The more you give, the more ScopeNeat can compare.
A list, one per line or separated by spaces or commas, as exported from your identity provider.
OpenAPI 3.x in YAML or JSON. ScopeNeat reads the OAuth security schemes and the security of each operation.
The result of tools/list, in JSON: names and annotations (readOnlyHint, destructiveHint…).
In YAML or JSON: each tool name, then the scopes its calls need.
The demo is Example Corp, a fictional company whose scopes grew without a plan.
🔒 Nothing you paste or type leaves your browser. Only anonymous counts are measured, never a name.
Paste something above, or load the demo, then press Analyze.
No. Parsing and analysis run in your browser, and nothing you paste is sent to YogaSec or anyone else. The page measures anonymous counts only, such as the number of scopes in ranges, never a name. Keeping your inputs on the device is off unless you turn it on.
None. RFC 6749 leaves scope names to each authorization server, and large platforms each have their own. ScopeNeat finds the convention most used in your inventory and points out the names that differ from it.
Because risk depends on what a tool can reach, not only on what it changes. A tool that reads customer or financial data can bring it into the conversation, and its token may allow more than the tool says. Tick "Reaches sensitive data" on such tools.
Fill in each owner, keep it next to the API description, and review changes to it like code. It is the list a team needs to decide who may add, rename or retire a scope.