Employee data assistant

Zhang San works in sales operations. Every Monday morning he owes the regional manager a weekly customer report. The data sits in the CRM: export, clean, build the table — two hours, every week, without fail. His team rolled out a reporting agent, and the demo looked great. Zhang San still would not use it. His reason was specific: for the agent to touch the CRM, it needs CRM access, and the only access Zhang San has to give is his own account. That account can see every customer record in the region — contacts, contract values, all of it. The weekly report needs a tiny corner of that.

People on the team had tried workarounds. One wrote the password into the agent's config file — which hands over the entire identity. If the agent errs or gets talked into something, the damage happens under Zhang San's name, and there is no taking it back. Another exported a full CSV and dropped it on the agent — the report wasn't done yet, but the sensitive data had already left the controlled system. What Zhang San wants fits in one sentence: let it do this one thing, only in this scope, only for this long.

The flow

This is exactly what explicit delegation solves. What Zhang San grants is not an account but a slice carried by a Delegate Token: read-only, the customer report API only, valid for two hours. Steps ①–⑦ number the full flow and match The full journey of one delegation; this page zooms in on ②–④, the part Zhang San lives through himself.

Exchange, access, and the trail left behind (steps ⑤–⑦) are covered in the full journey. This page sticks to the three moments Zhang San actually cares about.

Three moments that matter

1. Consent: after Zhang San hands off the task, what appears on screen is not a login page but a grant sheet: the reporting agent is asking to call the customer report API on behalf of you, read-only, valid for 2 hours. Scope and duration, in writing. The delegation exists only once Zhang San taps Approve; tap Deny and nothing happens. He doesn't need to understand the protocol — he needs to understand those three lines.
2. Audit record: from the moment Zhang San approves, one audit_id (something like audit_demo_5f2c81) runs through everything that follows. The audit answers three questions afterwards — who granted it: Zhang San himself; on whose behalf: Zhang San, with the reporting agent acting on behalf of the user (on-behalf-of); what it did: several calls to the customer report API, all read-only. The report shipped, and the evidence chain stayed.
3. Revocation: Monday afternoon, Zhang San notices the agent behaving oddly? He can revoke the grant 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. Doing nothing is safe too — two hours in, the token expires on its own and the slice is void.

Capabilities used here

Capability	What it does in this scenario	Read more
Delegate Token and attenuation	Turns "Zhang San's account" into "a two-hour read-only slice"	Delegate Token and attenuation
Consent	Scope and duration in writing; it counts only when Zhang San says so	Consent and approval
Audit chain	One audit_id answers who granted it, on whose behalf, and what it did	Audit and accountability chain
Revocation	Pull permissions back when something goes wrong; let them die on schedule when nothing does	Revocation and emergency response

Next steps

• Scenario: Customer service agent looking up a customer's order — swap "employee" for "your end customer" and see where the boundary goes.
• Hands-on: Your first delegation in 30 minutes — run Zhang San's path yourself.
• Concept: The full journey of one delegation — the whole mechanism, from registration to pulling permissions back.