Skip to content

Customer service agent looking up a customer's order

10:40 p.m. Li Lei opens the app and asks support: "Where is the coffee machine I bought last week?" The human agents went home hours ago; what greets him is a customer service agent. To answer, the agent has to reach into the order system and look up Li Lei's order — Li Lei's, and only Li Lei's.

Su Qing, who runs support, worries about this more concretely than anyone. A traditional support system carries one all-powerful service account that can query every customer's orders in the database. In the human-agent era that hole was papered over with training and spot checks. Once an agent is wired in, the nature of the problem changes: an agent's input comes from any stranger who walks up, and one carefully worded sentence (prompt injection) can steer it into someone else's orders, someone else's address, someone else's phone number. Su Qing doesn't want to "trust the agent not to slip." She wants a hard boundary: when the agent works for Li Lei, the ceiling on what it can see is Li Lei's own data.

The flow

The answer is to move the granting party from "the system" to "this customer himself." Li Lei consents once when the session starts, and the agent receives a Delegate Token whose subject is Li Lei — so the resource side no longer checks "is this service account allowed?" but "does this record belong to Li Lei?" Steps ①–⑦ number the full flow and match The full journey of one delegation; this page zooms in on ②–⑥.

Useremployee / end userAppyour app and resource servicesAgentGenAuthHuman IAM② Start the delegation (per task / session)Hand off the task(“where is my coffee machine?”)1Delegation request (interactive)2Consent page (scope + duration)3③ Attenuation check: real permissions ∩ explicit delegation ∩ approved boundaryEvaluate the user's real permissions4Permission assertion5④ Issue the Delegate TokenApprove6Delegate Token(short-lived · attenuated · carries audit_id)7⑤ Token exchange (RFC 8693)Request a resource access tokenwith the Delegate Token8Access token (sub = user, act = agent)9⑥ Constrained access (resource-side checks)Call the API with the access token10Check the sub / act / scopeintersection11Return only data insidethe granted scope12

How to read this diagram in a consumer scenario

In a consumer scenario the User lane is your end customer, and the Human IAM lane is your customer identity system. "The human's real permissions" has a plain meaning here: Li Lei could only ever see Li Lei's own orders — and what he delegates to the agent can never have a higher ceiling than that.

Three moments that matter

  1. Consent: a grant card appears in Li Lei's chat window: "Allow the support agent to look up your orders on behalf of you, query only, valid for 30 minutes." Li Lei taps Allow, and only then does the lookup start. He doesn't need to know what OAuth is — the subject of the grant is himself, and that's enough. The whole thing happens inside the conversation, without breaking the flow.
  2. Audit record: this lookup lands in the audit chain with an audit_id: who granted it — Li Lei (the end user); on whose behalf — Li Lei, with the support agent acting on behalf of the user (on-behalf-of); what it did — one call to the order lookup API, one record matched, read-only. The flip side matters more: if the agent is talked into querying data that isn't Li Lei's, the resource side checks sub=Li Lei and refuses outright, and the refusal is recorded too — so the security team sees an alert lead, not a silent privilege escalation.
  3. Revocation: at the end of the session, after a complaint, or when risk controls flag something odd, the grant can be revoked at any time, after which new token requests are no longer accepted. For how quickly already-issued tokens stop working, see Revocation and emergency response. In the normal case nobody has to lift a finger: 30 minutes in, the token expires and the grant falls back to zero.

Capabilities used here

CapabilityWhat it does in this scenarioRead more
Delegated mode (on-behalf-of)The token's subject is the customer, not an all-powerful service accountThree access patterns
User-level consentThe customer understands it in one line and grants it in one tap, inside the sessionConsent and approval
Attenuation and token exchangeRead-only, orders only, 30 minutes onlyDelegate Token and attenuation
Resource-side checksThe order API welds the data boundary shut on the sub/act/scope intersectionLet an agent call your APIs on behalf of a user
Audit chainEvery lookup — including the refused ones — is traceableAudit and accountability chain

Next steps