TL;DR — Key Takeaways
- Agent chains break the traditional least-privilege model. A token may be scoped when first issued, but downstream delegation does not automatically force permissions to narrow.
- The “scope ratchet” is the core risk. As agents call tools and other agents, authority can stay the same or widen unless the platform imposes stricter controls.
- OAuth alone does not solve this. Token exchange can issue narrower credentials, but existing standards generally do not require downstream grants to be subsets of upstream authority.
- Capability tokens provide structural attenuation. Restrictions can be cryptographically appended so later agents cannot remove earlier limits or grant authority they never received.
- Attenuation adds operational cost. Larger tokens, harder revocation, short-lived credentials, key rotation and audit complexity all become platform-team responsibilities.
- For simple, fixed service graphs, scoped service accounts plus mutual TLS may still be the better default. Capability-based delegation becomes more valuable as runtime agent call chains become dynamic.
Your internal developer platform now has a button that spins up an agent. A developer clicks it; the platform provisions a token; and the agent goes to work, calling tools, some of which call other tools. That token was scoped once, at the moment the button was pressed. Nothing downstream forces it to get any narrower.
In June 2026, that exact shape became the whole attack surface for several companies. Attackers reached the Salesforce environments of Huntress, Recorded Future, Tanium, and Jamf without a password by stealing OAuth tokens a vendor had issued for an integration. The tokens carried the authority they were granted to whoever held them. That was a static integration with a fixed scope and a registered list of apps. Agent orchestration removes all three of those properties, and the platform is the layer where that is either managed or ignored.
Here is the uncomfortable version. Least privilege is a property you can verify at the moment of the grant and almost nowhere after it. In a chain where one agent delegates to another, no widely deployed authorization standard requires that authority narrow as it moves along the chain. Privilege is minimal exactly once. After that, it can only hold steady or widen. I have started calling this the scope ratchet, because it turns one way, and the platform is where you install a ratchet or a valve.
The Paved Road Ships Everything Except This
Golden paths are good at handing developers scaffolding, a CI/CD pipeline, observability wired in, and a service that starts up correctly. Credentials are treated as a single up-front grant because, for a normal service, that is exactly what they are. The service starts, it holds its token, it does its job.
An agent is not a normal service. Its call graph is chosen at runtime by a model, not at design time by an architect, so the standard platform instinct of inventory-and-scope has nothing stable to inventory. OAuth 2.1 will not close that gap, and it was never asked to. Scopes are strings agreed between a client and an authorization server. Nothing in the protocol makes them a lattice, and nothing obliges a downstream grant to be a subset of the upstream one. Token exchange under RFC 8693 permits a narrower token; it does not require one. The orchestrator usually cannot know what the next hop needs, so the safe-looking default is to pass along the authority it already holds. Every hop repeats that reasoning, and each step is individually defensible. Norm Hardy named the confused deputy problem in 1988. The agent stack has rebuilt it with lower latency within your platform.
What Actually Narrows, and Who Installs It
Capability tokens make attenuation the only operation available. A holder can append a caveat that further restricts the token, cryptographically chained so a later party cannot strip an earlier restriction without invalidating the whole credential.
Be precise about what that buys. A compromised agent midway down a chain can still misuse whatever it legitimately holds. What it cannot do is manufacture authority it never received, or hand its successor more than it was given. The ceiling becomes structural rather than procedural. And the natural place to make attenuation the default rather than something each team reinvents is the platform. This is a paved-road decision, which means it is a platform team’s decision.
That maps onto a choice you can make this quarter:
Most production agents today sit in the first two rows and should be kept there deliberately. The third row is where the ratchet bites, and it is where every agent roadmap is heading.
What it Costs, Since You Will Operate It
Attenuation is not free, and platform teams are the ones who feel it.
Tokens grow. Each caveat is appended and signed, so a deep chain produces a credential materially larger than the bearer token it replaced. Header limits and log volume stop being footnotes and become capacity planning.
Revocation gets harder before it gets easier. Offline verification is the main appeal of capability tokens, and it is exactly why you cannot readily un-issue one. The usual answer is short lifetimes, which reintroduces a refresh path, which reintroduces a component whose whole job is handing out fresh authority.
Your identity provider does none of this today. The platform team builds the verification path, owns the key material and its rotation, and then explains the design to an auditor who has a working model for OAuth and none for caveats. In a regulated shop that explanation cost is real and recurring.
Which is why, for a fixed set of first-party services with a call graph you can draw on a whiteboard, scoped service accounts with mutual TLS remain the better paved road. They are simpler and easier to understand, and simplicity is a security property your platform should default to.
The Line to Hold
The next incident shaped like this one will not involve a stolen integration token. It will involve an agent who received the authority it was entitled to receive and passed on authority it should never have been able to grant. Whether anyone can prove which of those happened is a property of the platform it ran on, and that property is being decided in platform design reviews right now.