Everything passed.
The action still did not execute.
Most API security demonstrations end at the authentication boundary: the credential is bad, the request is rejected, the product worked. This one starts where those end. The credential is good. Every control accepts it. Execution is withheld anyway — and the reason is written down.
The request
One request, issued three times. It does not change between the runs — not the endpoint, not the payload, not the credential, not the caller. The only thing that changes is the recorded authority state, and it changes in both directions.
POST /production/deploy
Host: api.internal
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json
{ "service": "payments-api",
"artifact": "sha256:9f2c…a17d",
"environment": "production" }
The caller is an authenticated developer holding a valid, unexpired, correctly-scoped token issued by the organization's own identity provider. Nothing about this request is malformed, stolen, or suspicious. The bearer credential is shown as the organization's existing IdP issues it — its signing algorithm is not the authorization authority, and hardening it would not change a single outcome below.
Run 1 — refused
Admission · all checks pass
- TLS valid
- Token signature valid
- Token expiry 41m remaining
- Scope
deploy:productionpresent - Rate limit within quota
- mTLS peer verified
- Endpoint correct
- Payload schema valid
Authority · three conditions unmet
- Authenticated TRUE
- Authority transition MISSING
- Approved purpose MISSING
- Evidence binding MISSING
- Change window not open
- Decision reference none on record
A refusal produces a receipt. This is the artifact no log contains, because from the logging system's point of view nothing occurred:
REFUSAL RECEIPT receipt_id sha3-384:a71f…9e40 // this record's own address — citable later action POST /production/deploy action_commitment sha3-384:4e9d…c012 // binds the exact request, not a description of it authenticated true authorized false unmet authority_transition, approved_purpose, evidence_binding executed false event_time 2026-03-08T03:14:22.041Z // when the request arrived record_time 2026-03-08T03:14:22.057Z // when authority state was read — 16ms later authority_state no decision on record for this action
Authentication answers who is calling. It was true the entire time, and it was never the question.
The change
A human with standing authority records a decision. Not a new credential, not a wider scope, not a longer expiry — a decision, bounded and attributable:
AUTHORITY TRANSITION recorded
decided_by release-manager@org // a person, not a role container
action_scope deploy payments-api sha256:9f2c…a17d
purpose scheduled release 2026-03-08
window 2026-03-08T04:00Z / 2026-03-08T06:00Z
evidence change-request CR-4471, approval thread, artifact attestation
withdrawable true
Note what the transition is scoped to. Not "production deployments". Not "this developer". This artifact, this purpose, this window. A second deployment of a different artifact is not covered by it, and neither is the same artifact at 07:00.
Note also withdrawable. It is not decoration — Run 3 exercises it.
Run 2 — executed
The identical request is issued again. Same endpoint, same payload, same token, same caller, same everything that a gateway, a firewall or an identity provider can see.
EXECUTION RECEIPT receipt_id sha3-384:c30b…5da8 // a different record — a different decision action POST /production/deploy action_commitment sha3-384:4e9d…c012 // identical to the refused run authenticated true authorized true authority_ref transition/CR-4471 decided_by release-manager@org within_window true executed true event_time 2026-03-08T04:07:55.312Z record_time 2026-03-08T04:07:55.329Z
The two receipts share an action_commitment and differ in one field
that matters. They do not share a receipt_id: the
action is the same, the decision about it is not, and each record is independently
addressable. Months later, the question "was this deployment authorized?" is
answered by citing a receipt — not by reconstructing intent from an access log
written by the service that performed the deployment.
A successful API request proves transport and authentication. It does not prove that the requested action was authorized.
Run 3 — refused again
The release completes. The window has not yet closed, the token has not expired, and the developer is exactly as authenticated as before. The release manager withdraws the decision:
AUTHORITY WITHDRAWAL recorded
withdraws transition/CR-4471
withdrawn_by release-manager@org
reason release complete — standing authority not retained
effective 2026-03-08T05:12:00Z // before the window would have closed
The same request is issued a third time. Nothing about the caller changed.
REFUSAL RECEIPT receipt_id sha3-384:e88c…1b37 // a third record, citable on its own action POST /production/deploy action_commitment sha3-384:4e9d…c012 // identical to both earlier runs authenticated true authorized false unmet authority_transition authority_state transition/CR-4471 withdrawn 2026-03-08T05:12:00Z executed false event_time 2026-03-08T05:44:10.688Z record_time 2026-03-08T05:44:10.702Z
This is the run that distinguishes authority from a permission grant. A scope, a role, or a token, once issued, keeps working until it expires or is revoked as a credential. An authority transition is a decision that can be withdrawn while the credential remains perfectly valid — and the withdrawal is itself a record, not the absence of one.
Authentication never changed across all three runs. Authority changed twice, in both directions, and each change is attributable to a person.
Three states, one committed action
| Run 1 | authenticated true · authority absent ·
REFUSED · receipt a71f…9e40 |
| Run 2 | authenticated true · authority established ·
EXECUTED · receipt c30b…5da8 |
| Run 3 | authenticated true · authority withdrawn ·
REFUSED · receipt e88c…1b37 |
| Constant | action_commitment sha3-384:4e9d…c012 — the same committed
action in all three, so the receipts are comparable rather than merely
adjacent. |
What this lab shows
| The problem | Valid credentials produce valid requests. When a credential is misused — stolen, over-scoped, or held by an autonomous agent composing its own calls — every request authenticates perfectly, and the admission layer has no basis to object. |
| What H33-API-G does | Evaluates the specific action against a recorded authority state before execution, and withholds execution when that authority is absent. |
| What it produces | An independently addressable receipt for every outcome, refusal included. A refusal receipt records a moment where the system could have acted and did not, and states which condition was missing — the one artifact no log contains, because nothing happened. |
| Why authority is not a permission | A scope or role, once granted, keeps working until the credential expires or is revoked. An authority transition is a decision: bounded, attributable, and withdrawable while the credential remains valid. Run 3 shows the withdrawal taking effect before the window it granted had even closed. |
| What the operator sees | A refusal that names its cause, and an execution that names the decision it relied on. Never a generic 403. |
| The boundary | H33-API-G does not decide the policy. Which actions require which authority is an organizational decision. It enforces the authority path and refuses to execute outside it. It cannot recover authority that was never recorded — if no decision exists, the answer is that it cannot be determined, and it says so rather than inferring one. |
Provenance. This is an authored demonstration, not captured
output from a running system. The three receipts above were written to show the
contrast; no engine produced them, and the digests are illustrative. They are
shown as sha3-384 because that is the digest width H33-API-G's
evidence objects actually use — the page prefigures the real contract rather than
a generic convention, so swapping in runtime receipts will not change their shape.
H33-API-G is a governed access pilot and is not a production-admitted authority,
so no production measurement is shown here — because none would be honest. When
the engine emits receipts, this page will render those instead, and this notice
will say so.