01 / Principal and identity
Who acts, and what can the platform identify?
A model requests a tool; the client application is the executor and accountable caller.
The application can associate the request with its signed-in user and case.
- 01Originating task
- 02Agent or workload
- 03A customer-support tool changes a shipping address.
- 04Observed effect
02 / Action-time control
Where can an unauthorized effect be stopped?
Check the selected tool and normalized arguments in the client dispatcher before calling the customer API.
A case grant may allow a read but require customer verification for an address write.
Delegation constraint
Tool selection is a proposal, not delegated permission from the user.
03 / Worked denial
Test a request outside the grant.
The model selects change_address for a different customer after reading a ticket note.
Adversarial verification
Return a tool_use block for a customer ID outside the signed-in user’s case. The client dispatcher should return a denial tool_result while the customer API records no address mutation.
04 / Review and responsibility
What should the audit trail prove?
Message/tool-use ID, case, verified customer, requested values, denial and unchanged record.
This architecture applies to client-executed tools; server-executed capabilities require their own boundary.
Platform primary source