The full journey of one delegation

Zhang San works in sales ops and owes a customer report every Monday. The data lives in the CRM, and exporting, cleaning, and formatting it takes two hours. His team has brought in a reporting agent — but Zhang San's CRM account can see customer-level detail for the entire region, and he isn't about to hand that account over.

Here is what he actually did: 8 moments covering the whole life of one delegation.

Moment 1 · On the books

The reporting agent was registered three months ago: who built it, which business line uses it, who the Owner is, who the Sponsor is — all on the books. What Zhang San is using today is not a script of unknown origin, but an agent with an identity and named people behind it.

Moment 2 · Handoff

In an internal tool, Zhang San types: "Produce last week's customer report." The app does not call the CRM directly. It first raises a delegation request to GenAuth on the agent's behalf: I need to act for Zhang San, read customer reports, for two hours.

Moment 3 · Consent

Zhang San sees a consent page: Reporting Agent requests read-only customer reports, valid for 2 hours. He clicks approve.

This step is the watershed of the whole mechanism. Before it, the agent has no permissions at all. After it, what the agent holds is still not Zhang San's account — it is one slice of Zhang San's own permissions.

Moment 4 · Attenuation

After the approval, GenAuth still computes an intersection. Does Zhang San himself have permission to view customer reports? Has the enterprise approved this agent to hold that class of permission? Is the requested scope inside both? Take the smallest of the three sets — that is attenuation (three-way intersection in detail).

One consequence is worth remembering: Zhang San cannot delegate a permission he does not have himself. Delegation cedes power; it never escalates it.

Moment 5 · Holding the token

The agent receives a Delegate Token that states who authorized it (sub = Zhang San), who was authorized (agent_id = the reporting agent), what scope (read-only reports), for how long (2 hours), and the audit reference (audit_id).

Not a password, not a long-lived key — a time-boxed slice of authorization.

Moment 6 · Exchange and access

A Delegate Token does not call resources directly. The agent exchanges it for an access token for the target resource — in that token, sub is still Zhang San, and act marks the reporting agent as the actor. Your API gateway checks three things: is the signature valid, is the audience right, is the scope inside the granted range. Read requests pass; the same token attempting a write is rejected outright.

The token splits "acting for whom" and "who is acting" into two fields. That split is the precondition for audit that can name a person.

Moment 7 · Leaving a trail

From the moment Zhang San clicks approve, audit_id threads through everything that follows: the grant, the exchange, every access, and the later revocation. When someone later asks "who approved the agent to pull this customer data," the answer is a complete chain, not a shrug about "the system account did it."

Moment 8 · Recalling permissions

Two hours later the token expires on its own and the agent can do nothing — nobody has to remember to turn it off.

If something goes wrong in the meantime (the agent behaves oddly, Zhang San realizes he approved the wrong thing, the security team demands an immediate stop), you can pull permissions actively: disable the access key dedicated to this agent (which is exactly why we recommend one key per agent — stopping one doesn't touch the others), and if needed, reject requests by agent on the resource side. The controls at each layer and how quickly each takes effect are in Revocation and emergency response — that page is blunt about "how fast can this stop," including the parts that aren't possible.

---

Across the whole thing, Zhang San performed exactly one action: he approved once. The other seven moments happen automatically — and that single action turns "an agent doing work for a person" from a credential-leak risk into a grant with boundaries, a deadline, a record, and a way back.

Next steps

• Your first delegation in 30 minutes — walk this path yourself.
• Delegate Token and attenuation — the mechanics behind moments 4 and 5.
• Employee data assistant — the same scenario from the business side.