01 / The operating case
What changes in a real workflow?
An invoice assistant may read a matched invoice yet cannot release payment merely because its service token can reach the payment endpoint.
- 01Authority origin
- 02Task and grant
- 03Current decision
- 04Observed outcome
02 / Decision boundary
Put the check where it can stop the effect.
Evaluate payment release against the named invoice, payee, amount ceiling, task expiry and any approval. Place the interlock before the payment API commits.
Architecture review / negative test
Make the boundary testable.
A review should list the protected effects first, then name the principal and grant that can authorize each one. For the invoice case, write a distinct rule for reading, preparing and releasing payment; do not translate a broad API role directly into a business approval. The payment executor needs an immutable view of the payee and amount that the decision evaluated.
03 / Failure and evidence
What goes wrong, and what can be proven?
A broad role or startup-time approval is reused for later actions whose purpose and target have changed.
Record the originating grant, policy version, request arguments, decision reason, executor response and observed payment state.
04 / Canonical scope
Why this reference stands alone
The existing agent-authorization solution page describes the commercial problem; this reference owns the decision model and the testable action boundary.
Implementation review
The authorization unit is a proposed effect.
A signed workload token identifies the caller, while an agent grant explains why it may act for this task. For a payment release, the policy input must include the originator, agent instance, active task, operation, payee, currency, amount, invoice and approval state. The payment executor must apply the decision to those exact values. A broad “finance agent” role cannot safely stand in for these facts.
subject: finance-agent/task-42 origin: treasury-team/grant-17 action: release_payment resource: invoice-I42 arguments: payee-V8, USD 8,400 context: approval-A9, active=true result: ALLOW only for this request digest
Run the denial test
Keep the same token and task but change the payee or amount before submission. The executor must deny because the proposed effect no longer matches the evaluated request. Repeat after task cancellation; credential validity must not resurrect the grant.
Evidence to examine
Retain the grant ancestry, normalized request digest, policy version, approval binding, final decision and separately observed payment state. A decision log is not proof of settlement.
Primary source: NIST NCCoE agent identity and authorization concept ↗
Related: Parameter-level authorization.
Architecture field test
The consequential action model
What exactly is being authorized?
- 01Identify principal and origin
- 02Resolve task and grant
- 03Evaluate action, target and parameters
- 04Enforce and observe the effect
Work the boundary
For invoice I-42, a finance agent proposes an $8,400 payment to vendor V-8. The decision is for that invoice, vendor, amount and task, not for the payment API in general. A second proposal to V-9 needs a fresh decision even if the same process and token submit it.
| Required facts | Principal, originating grant, task purpose, operation, immutable target, normalized values, current policy and any approval. |
|---|---|
| Allow only when | The request is inside every live grant constraint and policy rule, and the executor receives the same evaluated values. |
| Deny when | A valid credential arrives with a changed payee, expired task or unapproved amount. |
Break the assumption
Change only the beneficiary after approval. Compare the canonical request digest at the payment executor and deny before release. Then check the payment system separately; an ALLOW receipt does not show settlement.
Design tradeoff
Rich action context increases integration work and makes cache keys more specific. That cost is justified at consequential write boundaries, while low-risk reads may use coarser policy.
For the consequential action model, consult NIST NCCoE agent identity and authorization concept. This worked decision and negative test are ProofGrid analysis.
Continue with Parameter-level authorization.
Primary references