01 / The operating case
What changes in a real workflow?
A user can view account A, while an agent has permission to prepare payments for account B; neither fact permits the agent to pay from A or B.
- 01Origin grant
- 02Parent agent
- 03Narrow child grant
- 04Action boundary
02 / Decision contract
What the executor must check
Evaluate each independently sourced constraint and accept only an action inside all required sets; explain which constraint denied it.
Architecture review / negative test
Make the boundary testable.
Compute an action’s effective permission across relevant domains: human initiator, agent grant, resource owner and organizational policy. The intersection is constrained by the most restrictive required rule. A union of individually plausible entitlements can accidentally create a payment capability that neither the user nor the assigned agent actually held.
03 / Failure and evidence
What goes wrong, and what can be proven?
Combining the user’s broad account view with the agent’s broad payment role creates a permission neither was granted.
Record the constraints evaluated and their intersection result without leaking unrelated entitlements.
04 / Canonical scope
Why this reference stands alone
Shared budgets constrain aggregate consumption; this page owns logical combination of authorization domains.
Primary references