🚧 Roadmap — The capability described here is on the roadmap. The concepts and design are settled; interfaces and steps are subject to the final release.
Agent access to third-party SaaS
Fang Yuan is the VP of sales at a 200-person company: three hundred emails a day and a calendar that fills the screen. His team set him up with an assistant agent — summarize the morning's mail, reschedule calendar conflicts automatically, ping him on IM the moment an important customer writes in. It sounds wonderful, as long as the agent can reach his mailbox, his calendar, and his IM. Those three happen to be the three most private things in Fang Yuan's digital life.
Every old answer IT could offer is bad in its own way. Give the agent the password? That hands over the entire digital identity, and the day he changes it, every integration breaks at once. Run a one-time third-party authorization and stuff the long-lived credential into the agent's environment variables? Now the credential lives on the agent side forever — breach the agent and mail, calendar, and IM all go together. Worse, three months later nobody remembers clearly what was authorized, to whom, or how many grants are still alive. That is IT's knot: withhold it and the thing is useless; hand it over and you can't get it back.
The flow
The fix in one line: custody for credentials, dispatch for tokens. Fang Yuan's third-party credentials are held by the Token Dispatcher and never leave custody. Each time the assistant agent works, all it can do is present a Delegate Token and request a short-lived, attenuated, recallable access token. The agent never touches the original credential from start to finish — every token it holds has a deadline, a scope, and an audit record. For the mechanism, see Token Dispatcher. Steps ①–⑦ number the full flow and match The full journey of one delegation; this page zooms in on ②–⑤.
Three moments that matter
- Consent — two layers, both required. At connect time (one-off): Fang Yuan connects his mailbox and calendar accounts into custody, going through each third-party service's own standard authorization flow. The credential lands in custody, and the agent is not present at any point. At delegation time (per task / session): the consent page spells out the scope the assistant agent is asking for this time — read-only mail, read/write calendar, no sending mail on his behalf. That scope can be narrower than what custody was granted at connect time, and it can only ever be narrower, never wider (attenuation).
- Audit record: every dispatch lands in the audit chain with an
audit_id: who granted it — Fang Yuan; on whose behalf — Fang Yuan, with the assistant agent acting on behalf of the user (on-behalf-of); what it did — which third-party service got a token, in what scope, and what it accessed next. For IT, this is the first time the question "which agents in this company are accessing which third-party services, in whose name?" has an answer that lives in the audit chain rather than in somebody's memory. - Revocation: Fang Yuan changes roles, the agent behaves oddly, or he simply stops wanting it — disconnect the connection and custody stops dispatching new tokens. The grant can be revoked at any time; for how quickly already-issued tokens stop working, see Revocation and emergency response. Changing the password is no longer the only emergency lever, and because the original credential never left custody, there are no "copies scattered around" to chase down.
Capabilities used here
| Capability | What it does in this scenario | Read more |
|---|---|---|
| Token Dispatcher | Custody for credentials, dispatch for tokens — the core of this scenario | Token Dispatcher |
| Delegate Token and attenuation | Every dispatched token is short-lived and scope-limited | Delegate Token and attenuation |
| Consent | Two layers, connect and delegate, both decided by Fang Yuan | Consent and approval |
| Audit chain | Every dispatch and every access is traceable | Audit and accountability chain |
Next steps
- Concept: Token Dispatcher — how custody and dispatch actually work.
- Guide: Let an agent access third-party services on behalf of a user — the full path from connect to consent to lease.
- Scenario: Employee data assistant — the same delegation logic when the target is an internal resource.