One refund. Four services. Never one broad credential.

A customer asks for their money back. At every hop the orchestrator trades the customer’s token for a narrower one, scoped to exactly that service — and the authority to call the bank doesn’t exist until the customer and, above their limit, a support employee both say yes.

I’m a customer Support employee sign-in

The four hops

HOP 1 · standing Grant
order-history-service
Does this order exist, for this customer?
HOP 2 · standing Grant
customer-scoring-service
How valuable is this customer? (sets the self-service limit)
HOP 3 · standing Grant
refund-budget-service
Can the budget cover it, and does it need a human?
HOP 4 · Grant created on demand, then revoked
banking-api
Move the money — irreversible.

Every exchanged token keeps the customer as sub, names the orchestrator in act, and carries the login’s sid — so all four hops are provably the same customer in the same conversation.

The original employee demo (Ask Fusion)

RefundBot is built on InFusion Agent, whose scope-gated employee assistant is still here as a secondary mode. The role you choose decides which tool scopes your login even requests.

Employee

Knowledge base + tickets. No directory, payroll, or PTO.

tools:kb.read
tools:tickets.write

Manager

Adds directory, payroll, and PTO — the last two require consent.

tools:kb.read
tools:tickets.write
tools:directory.read
tools:payroll.readconsent
tools:pto.writeconsent

IT Admin

The full tool set, payroll and PTO included.

tools:kb.read
tools:tickets.write
tools:directory.read
tools:payroll.readconsent
tools:pto.writeconsent