Every MCP server and agent integration carries a grant of access: an API key, an OAuth token, a filesystem root. What matters is not whether the grant exists but how large it is relative to the work, and the gap is usually wide - an agent that needs to read one project holds an org-wide admin token. That surplus is dormant, which is why it goes unnoticed, and it is the difference between a contained incident and a breach when something goes wrong.
Excessive permissions are not an attack on their own. They are a force multiplier: a prompt injection, a compromised MCP server, or a stolen token does damage in proportion to what the underlying grant allows. Impact is the reachable surface times the chance something puts hostile instructions or a bad actor inside the loop, and least privilege attacks the first term directly. When an injected instruction tells an agent to read secrets and send them out - the lethal trifecta - a read-only, single-project token limits the payoff to that project, while an admin token turns the same injection into a full-tenant compromise. Over-provisioning is the org deciding, in advance, which of those it gets.
How the attack works
Over-provisioning happens for mundane reasons, not negligence. Broad scopes make setup work on the first try, so a developer under deadline pastes in the admin key rather than debug a permission error. Vendor docs routinely ask for a personal access token or all-scopes OAuth grant, and most MCP servers offer no per-tool scoping, leaving the choice all-or-nothing at the connection level. The result is a standing grant that outlives the experiment that created it: the proof-of-concept becomes the production path, and no one narrows the token.
Attack scenarios
- Admin key where read-only would do. A ticketing MCP server is connected with an admin token because the vendor quickstart used one. An injected instruction in a ticket now lets the agent delete boards and rewrite workflows, not just read the one ticket.
- OAuth grant scoped to everything. An email integration requests full-mailbox and send scopes when the task only reads free/busy. Steered by malicious content, the agent turns those scopes into an exfiltration and phishing channel.
- Filesystem root instead of project directory. A local MCP server is pointed at the home directory rather than the repo, so one code-execution step reaches SSH keys, credential files, and browser sessions well outside it.
- Service-account sprawl. Each new agent gets its own broadly scoped service account that no one deprovisions, leaving standing, high-privilege identities with no owner.
Related techniques
- Supply-chain grants - a malicious MCP server inherits whatever scope you hand its connection, so the grant and the trust decision are the same act.
- Standing credentials - broad tokens in config and env files are also the target of crown-jewel theft.
Mitigations
- Scope to the task, not the platform. Grant the narrowest role that completes the workflow, and treat admin scopes as an exception that needs justification, per least privilege for AI agents.
- Prefer short-lived, per-agent credentials. Replace standing personal tokens with scoped, expiring, individually owned grants, and give every agent identity an owner and expiry so access decays instead of accumulating. See AI access control and least privilege.
- Audit OAuth scopes on every integration. Enumerate what each connection holds versus what it uses; the gap is the finding. The AI OAuth risk report covers the common over-grants.
- Enforce at the tool-call boundary. Even a correctly scoped token allows some dangerous calls, so a hook that evaluates each call against policy before it runs contains what scoping alone cannot.
How Anomity helps
Anomity's Endpoint Sensor discovers every MCP server, agent, and integration on the endpoint and records its source, owner, version, and reach, so over-scoped and forgotten grants become visible instead of dormant. On agents that expose a hook, such as Claude Code's PreToolUse, each tool call is allowed, denied, or logged before it runs, which caps the surplus a broad token would otherwise permit. Scope and config changes surface as change events, violations route to SIEM, Slack, email, and Jira, and every decision lands in a queryable 90-day audit trail alongside the identity and GRC controls already in place.
