🚧 Roadmap — The capability described here is on the roadmap. The concepts and design are settled; interfaces and steps are subject to the final release.
Token Dispatcher
Custody for credentials, dispatch for tokens — a user's third-party credentials sit in the Dispatcher's custody and the raw credentials never leave it. An agent can only present a Delegate Token and request a short-lived, attenuated, recallable access token.
Why an agent needs it
Agents constantly have to touch systems you don't control: the user's mailbox, calendar, IM, cloud drive, CRM. Access credentials for those systems (OAuth refresh tokens, API keys) share three problems:
- Long-lived. A refresh token can go months without expiring, so handing it to an agent is a long-term cession of power.
- Coarse-grained. Third-party scopes are usually cut by product, not by task — you want "read today's calendar" and you get "read and write all calendars."
- Once it's out, it's out. Once a credential lands in an agent's memory, logs, or prompt context, you no longer know where it went.
The Token Dispatcher's answer is no credentials, only tokens: credentials stay locked in the custody layer, and each time the agent needs one it requests a time-boxed access token that goes void after use.
Dynamic control, not static storage
The common approach in comparable solutions is "build a vault and store the credentials." Storage is necessary, but it only solves half the problem — storing it well is not the same as governing it well.
The Dispatcher's center of gravity is the moment of dispatch: every request has to pass a decision.
| Static storage only | Token Dispatcher | |
|---|---|---|
| Focus | How the credential is encrypted at rest | What conditions each retrieval must satisfy |
| On retrieval | You get the credential itself | You get a short-lived, attenuated access token |
| Decision basis | Whether you have permission to reach the vault | Whether the Delegate Token is valid, whether the delegator is the account owner, whether the scope is inside the grant |
| After an incident | The credential has already leaked; only a full rotation helps | The token dies at expiry; further dispatch can be stopped |
The checks at dispatch time include at minimum: the Delegate Token is valid and unexpired, the delegating person really is the owner of that third-party account (an agent can't use A's delegation to fetch a token for B's account), and the requested scope is inside the intersection of the delegated scope and what the account has already authorized. Fail any one and nothing is dispatched — and the attempt is recorded in the audit trail.
Three usage archetypes
Different agents have different degrees of autonomy, so they need different credential shapes:
| Archetype | Who the agent represents | Credential source | Typical scenario |
|---|---|---|---|
| Pure service | No individual — the organization | Organization-level tool credentials (for example, an app token for a collaboration platform) | Scheduled scraping, batch processing, system integration |
| Single-user delegation | One specific person | A third-party account that user has connected | A personal assistant reading your mail or tidying your calendar |
| Multi-hop chain | A person, via several agents in between | The delegation travels along the chain, narrowing at every hop | An orchestrating agent calling sub-agents to complete a composite task |
All three share one rule: permissions can only narrow at each hop (attenuation). This matters most in multi-hop chains — the longer the chain, the smaller the slice at the end.
How it works
- The user connects a third-party account to your application (through that third party's standard authorization flow), with the scope you declared.
- The Dispatcher receives the returned credential and takes custody of it; the credential is stored encrypted and is never returned in cleartext to the agent or to your application. From then on, refreshing it is the Dispatcher's job.
- The agent, when it needs that third-party service, presents its Delegate Token to the Dispatcher and requests an access token, declaring the scopes it needs.
- The Dispatcher runs the dispatch checks above and, on success, dispatches a short-lived, attenuated access token and records it in the audit chain.
- The agent calls the third-party service with that token. The token goes void at expiry; using it again means requesting a new one.
- The user or an admin can disconnect the account at any time, after which every further request is denied.
Throughout, the only thing the agent ever touches is the short-lived token dispatched in step 4 — the raw credential never leaves custody.
Standards and protocols
- RFC 8693 Token Exchange: the semantic basis for dispatch — trading one token for another, more restricted token.
- OAuth 2.1 authorization code + PKCE: step one, "the user connects a third-party account," runs each third party's standard authorization flow.
- Encrypted storage and refresh of credentials are implementation details and are not part of any external contract.
Next steps
- Agent access to third-party SaaS — the scenario view.
- Access third-party services on behalf of a user — the guide view.
- Delegate Token and attenuation — where the intersection rules in the dispatch checks come from.