“Investigate” gives the child authority to do a bounded investigation, not to spend money. The parent can pass the task, the ticket and account identifiers, permitted read capabilities, a deadline, and references to evidence it is allowed to share. It cannot turn an investigation request into a credit grant by writing “you are the billing expert” in the child's prompt. Tool access must be bound to the user's and application's actual grants.

I would represent delegation as a scoped capability or authorization record: who requested it, on whose behalf, parent and child run IDs, account and ticket, allowed operations, maximum data scope, expiry, and current grant revision. The child should have a separate identity in the audit trail. It can return a proposed credit with amount, reason, evidence, and policy basis. Issuing the credit requires its own action authorization and any product-specific approval. A model-generated recommendation is not that approval.

Suppose an operator later explicitly approves up to $25 for this ticket. That can grant the child a narrowly scoped issue_credit capability if policy allows delegation of that operation. Before the external call, the execution gateway checks the live grant, amount, account, ticket, approval and tool arguments. The gateway records an operation ID so a timeout cannot be mistaken for a clean failure. A generic tool credential in the child's environment would defeat the scoped design. The relevant ArchCrux essay on identity and delegation covers the broader identity tree. This interview scenario forces us to decide when a proposed credit becomes an authorized effect.

Now the parent's authorization is revoked while the child runs. Revocation must make its way to the shared policy authority, not only to the parent's next prompt. The child may continue reading a cached summary, but the next protected read or write must fail the current policy check. Cancel or fence its pending work and invalidate delegated capabilities derived from the revoked grant. If the child acquired a separate explicit approval that survives parent revocation by policy, say so in the grant model. Otherwise the parent cannot leave behind an orphaned spending authority.

There is a race at the gateway. If revocation is committed before the credit's authorization check, reject the call. If the call was authorized and submitted before revocation, it may still commit at the payment service after revocation. A local check cannot pull bytes back. Record that ordering and resolve the external outcome, then tell the user accurately. If the product promises strict prevention until remote commit, the external system has to participate with a conditional authorization or fence. Do not promise that a prompt update can enforce it.

I would test a child that proposes $20, changes the amount to $200, changes the account, waits until the grant expires, or sends immediately as revocation lands. Every tool request is checked against the same scoped grant, not accepted because a previously approved natural-language plan looked close enough. A handoff API, such as the Agents SDK handoff mechanism, transfers control. It is not itself a monetary permission.