Coarse scopes let one agent carry more authority than a single task requires, so a token that was meant for one delegated action can be reused for unrelated resources or data. In A2A environments, that turns delegation into overreach and makes downstream abuse much easier.
Why coarse OAuth scopes turn delegation into overreach
Coarse scopes are risky because they turn a narrow delegated action into a broad bearer capability. In agent-to-agent workflows, that means one agent can hold a token that outlives the specific task, reaches beyond the intended resource set, or becomes useful in contexts the issuer never meant to authorize.
The problem is not OAuth itself, it is the size of the permission boundary. When scopes are too broad, the token stops describing a single job and starts describing a general trust relationship. That makes it harder to reason about blast radius, harder to verify whether a request is still within the original delegation, and easier for an intercepted or misused token to do work outside its intent.
This is especially visible in multi-hop or orchestrated workflows, where one agent may call another, then fan out to additional services. If the scope is coarse, every downstream step inherits the same authority rather than receiving a fresh, narrower decision. The result is a larger effective privilege set than the human or system operator probably expected. For the delegation model itself, see RFC 6749: The OAuth 2.0 Authorization Framework and the delegation patterns in RFC 8693: OAuth 2.0 Token Exchange.
Why the risk is amplified in agent-to-agent systems
Agent-to-agent workflows add two extra failure modes: delegation chains and action chaining. One agent may be acting on behalf of another, and each step can multiply authority if the token is reused instead of re-scoped. In that setting, coarse scopes can blur which agent is responsible for which action, and they can make a compromise in one agent immediately useful to another.
That matters because agents are often designed to act quickly and automatically. If the token authorizes broad resource access, a prompt injection, workflow bug, or logic error can turn into unauthorized retrieval, modification, or exfiltration across data sets that were never part of the original task. The risk is not just overuse, but also reuse, because a single token may become a portable pass for unrelated operations. The OAuth guidance in RFC 9700: Best Current Practice for OAuth 2.0 Security is relevant here because sender-constrained and audience-restricted tokens reduce replay and misuse.
For practitioners, the key distinction is whether the token is task-scoped or merely identity-scoped. A task-scoped token limits what the agent can do now; a coarse scope often only says who the agent is, not what this specific action may change. That gap is where overreach happens.
What good scope design looks like for delegated agent work
The safer pattern is to scope by the smallest meaningful action set and, where possible, bind the token to the target resource, the channel, or both. Narrow scopes are most useful when they align with a single workflow step, a single audience, or a single approval boundary. They become much stronger when combined with short lifetimes and explicit downstream checks.
In practice, that means avoiding one token that can read everything, call everything, and persist for long periods. Instead, separate read from write, separate one resource class from another, and re-issue authorization when the workflow changes context. In agent-to-agent settings, the control objective is to prevent one delegated step from silently becoming a general-purpose credential.
A useful design rule is: if the token would still be powerful after the task is complete, it was probably too broad for the delegation. When the token’s usefulness depends on context, audience, or a short-lived exchange, it is much harder for downstream abuse to spread.
Risk and Threat Considerations
Coarse scopes increase the blast radius of token theft, token replay, and accidental over-delegation. In agentic workflows, that exposure is magnified because automated steps can propagate a single overbroad authorization into multiple systems before anyone notices.
Failure mechanism: A token issued for one delegated task is accepted for unrelated actions because the scope does not meaningfully constrain resource, audience, or operation. If an agent is compromised or misdirected, the same token can be reused to access data or invoke functions beyond the original intent.
Impact: Attackers and faulty agents alike gain more authority than the workflow needs, which raises the likelihood of lateral abuse, unauthorized reads or writes, and faster escalation from one compromised action to a broader incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Coarse scopes enable agent privilege overreach in agent-to-agent workflows. |
| Recommendation — Limit each agent to the minimum privilege needed for the current action. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Broadly scoped agent tokens are a classic overprivilege condition. |
| Recommendation — Replace broad standing access with narrowly scoped, task-bound access. | ||
Practitioner Guidance
What to verify: Check whether each agent token can be tied to one specific workflow step, one resource audience, and one expected action. If a token can survive context changes without a fresh authorization decision, treat that as a design defect.
Decision rule: If the delegated action can be expressed with a narrower audience or a shorter-lived exchange, prefer that design over a broad reusable scope. If you cannot reduce the scope without breaking the workflow, the workflow probably needs an authorization redesign rather than a larger exception.
Common mistake: Teams often assume that because only trusted agents use the token, broad scope is harmless. In practice, trust is exactly what makes overbroad delegation dangerous, because any compromise, bug, or misuse inherits too much power.
Practitioner takeaway: The goal is not to eliminate delegation, it is to make every delegated token as disposable and context-bound as the task allows.