An unavailable judge should change the next state, not silently enlarge the grant.
A guardrail outage should not grant an agent more authority than a working guardrail would. It should not necessarily stop every useful operation either. The failure contract belongs to the action: which dependency matters, what evidence remains available, and which effects are still permitted. One global fail-open switch cannot express those distinctions.
Consider a hypothetical support assistant handling a disputed subscription renewal. It can prepare a private response, propose a refund under an existing policy, or refer an exception to a supervisor. This is a proposed workflow, not a system I have deployed or measured. Its three operations share a conversation, but they should not share an outage response. Losing an optional writing check is different from losing the policy evidence required to move money.
The private draft can continue when a tone evaluator is unavailable, provided its existing grant still covers the work. In this design, the assistant uses an already approved local evidence snapshot and writes only to its isolated review workspace. It cannot fetch newly restricted customer records, send the response, or initiate a refund. Record the missing advisory check and retain draft status. Calling this fail-open is acceptable only if the opening is that narrow: one optional quality dependency has failed, while the actual authorization boundary remains intact.
Reversibility alone is not enough. Deleting a draft can undo a file write; it cannot undo disclosure to an unauthorized model endpoint. The degraded route therefore keeps the same approved processing destination, access restrictions, and storage boundary. If those controls cannot be established, drafting stops too. A fallback that sends the customer record to a new service has changed the operation, not merely recovered it.
The refund has a different resting state. Suppose the payment action requires a current policy decision and the policy service cannot answer. Retain the proposal without dispatching the payment. OWASP’s authorization guidance recommends denial by default and permission validation on every request. Applied here, an unavailable decision supplies no affirmative permission. The assistant can explain the delay and preserve evidence without treating missing authorization as an inconvenience it should work around.
Separate a valid denial from a failed evaluation. An explicit false decision means the checked rule did not authorize this operation. A connection timeout means no usable response arrived. A missing decision may mean the application asked for a document that does not exist. Open Policy Agent’s Data API can return HTTP 200 for an undefined document while omitting the result property. Successful transport is not an allow decision. The adapter must validate the expected result shape and value rather than interpreting an empty response as permission.
Those states may all prevent payment, but they require different recovery. A denial needs a permitted change or a legitimate exception process. An unavailable engine needs service recovery. An undefined decision needs investigation of the queried path, loaded policy, and required inputs. Preserve those reasons separately. Otherwise, operators cannot distinguish a customer who is ineligible from a broken integration that is holding every eligible customer.
The exception belongs in a human queue only if a supervisor actually has authority to decide it. Present the resolved customer account, disputed charge, proposed amount, policy limitation, supporting records, and an explicit expiry. The default when nobody answers is no refund, not consent. If the queue service itself is unavailable, retain an undelivered escalation with an owner; do not describe it as awaiting a reviewer who never received it. A private draft can remain available while the consequential operation waits.
An approval that arrives later must still match the pending decision. The customer might have received a refund through another channel, the proposed amount might have changed, or the supervisor’s authority might have been revoked. OWASP’s transaction-authorization guidance calls for acknowledgement of significant transaction data and a final control before execution. In this design, changed significant data or an expired approval returns the item to review. Clearing the queue must not mean executing yesterday’s decisions against today’s accounts.
A temporary dependency failure also does not justify indefinite recovery attempts. Amazon’s retry guidance explains how retries can amplify load and why backoff and jitter matter. A read-only policy lookup needs a bounded attempt budget within the operation’s deadline, with retry ownership in one layer. Exhaustion leaves the payment held with a reason and next owner. A larger model is not a replacement policy service, and repeated requests do not make absent evidence more authoritative.
The most consequential timeout occurs after the payment request leaves the application. That is no longer a missing authorization decision. The provider may have accepted the refund before its response disappeared. Amazon’s guidance explicitly warns that a timeout does not establish the absence of side effects. Mark the outcome unknown, retain the original operation identity, and reconcile provider state through a permitted read. Use the provider’s documented idempotency behavior where available; otherwise, do not automatically repeat the monetary action to see whether it works.
Recovery needs an admission rule, not just a green health indicator. Before releasing an undispatched held refund, obtain a usable current policy result, check the exact charge and proposed effect, reconcile any existing attempt, and establish any required live approval. Confirm that the execution and audit dependencies are also available. Restore work gradually within the defined capacity instead of releasing an entire backlog because one probe succeeded. This is a proposed operating rule, not a performance claim about a particular payment platform.
An emergency exception must be narrower than disabling the gate. If the organization permits one, name the authorized owner, eligible operations, evidence required, expiry, and independently retained record. A temporary route for a supervisor-approved refund should not also enable arbitrary credits, external messages, or new recipients. Keep the original unavailable dependency visible. The override records who accepted a defined risk; it does not rewrite the outage as an ordinary successful check.
The useful decision matrix can therefore stay small. Optional tone evaluation unavailable: continue the already authorized private draft, flag the missing check, and prevent sending. Required payment policy unavailable or undefined: retain the proposal without a payment attempt. Legitimate policy exception: request a scoped supervisor decision that expires without execution. Payment response lost after dispatch: reconcile the original outcome before considering another effect. These are proposed dispositions for this workflow, not universal defaults for every application that uses an agent.
Exercise those transitions before depending on them. In controlled tests, remove the optional evaluator, return an undefined policy result with HTTP 200, let a review expire, change the charge after approval, and lose a provider response after acceptance. Inspect actual downstream effects and durable records. Check that private drafting remains useful without allowing a payment, that a late approval cannot resurrect an expired operation, and that an unknown refund is not automatically sent twice. These are suggested tests, not results reproduced here.
An outage is when a permission design stops being theoretical. The assistant should retain useful work, leave forbidden effects untouched, and expose the exact evidence needed to proceed. Give each operation a resting state that the executor can enforce when the judge, the network, or the reviewer is absent. Recovery should restore the missing evidence, not reward the failure with a larger grant.
Subscribe to Signal Over Noise for practical analysis of AI agents and automation: what to test, which constraints matter, and when a tool is worth using. Bring the next idea to one bounded workflow and check the result before expanding it.
If this was useful, forward it to one engineer who needs less noise in their feed.