Fail-closed behavior for agent actions

When a required authority fact cannot be verified, a consequential action should stop or move to an explicitly narrower mode rather than reuse an unbounded old allow.

01 / The operating case

What changes in a real workflow?

A maintenance agent can inspect telemetry and may restart a server during an approved window. Its authority service becomes unreachable just before a restart.

Trace the authority boundary
  1. 01Authority origin
  2. 02Task and grant
  3. 03Current decision
  4. 04Observed outcome

02 / Decision contract

What the executor must check

Separate operations by consequence. Keep low-risk reads only if a locally valid grant and data policy permit them; deny the restart until the executor can confirm current authority or a narrowly scoped emergency path is activated by an accountable operator.

InputPrincipal · task · action · target
DecisionGrant ancestry · policy · current state
ResultEnforce · record · verify outcome

03 / Failure and evidence

What goes wrong, and what can be proven?

Failure mode

The runtime treats “decision service unavailable” as ALLOW, or silently replays yesterday’s approval with no expiry or target binding.

Evidence to retain

Log unavailable dependency, last verified authority state, local decision mode, denied or reduced operation, operator escalation and later reconciliation.

04 / Canonical scope

Why this reference stands alone

Degraded authority modes address what may continue; this page owns the failure default and the negative test for a missing decision dependency.

Implementation review / distinct boundary

Define failure by action class before an outage.

“Fail closed” is a decision rule for a protected effect, not a requirement to turn off all observability. An incident responder may need read access while a restart, payment, deletion or control command waits for current authority. The permitted reduced state needs its own grant, expiry and enforcement path. Otherwise a fallback mode quietly becomes a second unchecked authorization system.

Example outage decision table
telemetry.read + valid local grant → limited read
configuration.propose → queue without executing
server.restart + PDP unavailable → DENY
parent grant revoked + cached ALLOW → DENY
01

Classify effects

Separate read, proposal, reversible write and high-consequence actuation.

02

Choose outage rule

Write a testable default for missing grant ancestry, stale policy, lost connectivity and unverifiable approval.

03

Reconcile

On recovery, compare local decisions with centrally observed revocations without rewriting the historical record.

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.

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation