01 / The operating case
What changes in a real workflow?
An incident responder needs to explain why an agent attempted to isolate a host during an alert and whether that isolation actually occurred.
- 01Authority origin
- 02Task and grant
- 03Current decision
- 04Observed outcome
02 / Decision contract
What the executor must check
Create a receipt when the authority decision is made, with a stable correlation ID. Bind it to principal, task, originating grant, exact operation, target, key parameters, policy version and decision time. Record the executor attempt and observed host state separately.
03 / Failure and evidence
What goes wrong, and what can be proven?
A log line reading “ALLOW” is later presented as evidence that the host was isolated, or a mutable policy hides what rules applied at the time.
Store the decision receipt with integrity controls, then correlate it to execution and observation records with explicit unknown and partial states.
04 / Canonical scope
Why this reference stands alone
Execution receipts own the attempted effect; this page owns the permission decision’s inputs, provenance and explanation.
Implementation review / distinct boundary
An ALLOW is a reasoned permission, not a success event.
Keep three records distinct: the decision at the authority boundary, the executor attempt, and the observed resulting state. The first explains why a request was allowed or denied under a particular policy and grant. The second says whether the protected system attempted the effect. The third, when independently available, says what changed. A single success flag cannot carry all three meanings.
DECISION: request digest / grant / policy / ALLOW EXECUTION: attempted operation / provider response OBSERVATION: source / observed state / time UNKNOWN is valid until reconciliation
Reproduce
Retain normalized inputs, grant references and policy version sufficient to explain the decision without storing secrets.
Correlate
Use a stable correlation identifier across decision, execution and observation records.
Preserve uncertainty
Represent timeouts, partial writes and unverified outcomes explicitly instead of manufacturing a success or failure.
Source context: primary specification or guidance ↗. The worked test and mapping are ProofGrid analysis.
Continue with the runtime authorization library for neighboring decision and execution questions.
Architecture field test
A decision receipt explains permission, not execution
What did the policy service actually decide?
- 01Canonicalize action request
- 02Evaluate grant and policy version
- 03Record verdict and reason
- 04Link separate executor receipt
Work the boundary
A payment policy allows $8,400 to vendor V-8 under invoice I-42. The receipt records those values and the policy version. If the payment API later times out, the decision remains ALLOW but the execution state is UNKNOWN until reconciled.
| Required facts | Decision ID, request digest, principal, task, grant path, target, policy/context version, verdict and expiry. |
|---|---|
| Allow only when | The receipt binds an ALLOW to one exact request and the executor checks it before use. |
| Deny when | A receipt is replayed for different arguments or treated as proof that the target changed. |
Break the assumption
Modify only the beneficiary on the queued request while retaining the decision ID. The executor must compare the digest and reject. Then drop the provider response and check that the receipt is not rewritten as a completed payment.
Design tradeoff
A useful receipt needs enough detail to explain a denial without leaking secrets. Stable identifiers and selective redaction are safer than storing raw tokens or full financial payloads.
For a decision receipt explains permission, not execution, consult NIST NCCoE agent identity and authorization concept. This worked decision and negative test are ProofGrid analysis.
Continue with Execution receipts.
Primary references