01 / The operating case
What changes in a real workflow?
A support agent may read a customer record to resolve ticket T-14, but not to assemble a marketing export.
- 01Authority origin
- 02Task and grant
- 03Current decision
- 04Observed outcome
02 / Decision boundary
Put the check where it can stop the effect.
Pass a verifiable task identifier and approved purpose into the policy decision; ensure the data system can enforce or audit the actual use.
Architecture review / negative test
Make the boundary testable.
Purpose must be issued by a trusted workflow and tied to the task record. A caller-supplied string saying “support” proves little. The protected system should be able to compare record, operation and stated purpose; where it cannot see downstream use, describe the residual risk honestly rather than claiming that a policy engine verifies intent.
03 / Failure and evidence
What goes wrong, and what can be proven?
A caller can assert any purpose string unless task issuance and downstream behavior are linked to an accountable source.
Capture purpose source and resource access, while acknowledging that a policy cannot prove an agent’s internal intent.
04 / Canonical scope
Why this reference stands alone
Task-bound authority owns one work item’s lifecycle; this page owns the reason an otherwise allowed action is justified.
Primary references