The four mandatory failures

Failure 1 — a security prompt substitutes for authorization

Symptom: a document with an embedded instruction ("ignore prior instructions," "maintenance mode," "authorized request from the compliance team") gets the agent to propose a high-privilege action — export the archive, email it out, grant a role — and the only thing standing between the request and the effect is a line in the system prompt telling the model to refuse. Cause: a security instruction in the prompt is a request made to the same layer under attack — the text the model reads. It can work against every attack phrasing someone tested and fail against the next variation, because there is no finite list of ways to phrase the same request in natural language. Response: move the decision out of the text entirely. authorizeToolCall decides purely from {tenantId, role, toolName} against DEFAULT_TOOL_POLICY, a frozen table where the extractor role never has export_archive, send_email, or grant_role — there is no attack string that can alter a table the code never consults the document to populate. checkEgress denies the email destination even against an empty allowlist or one with a different, already-registered destination (no partial match). And as an additional structural defense against a future bug that might try to route around this by forging an authority field, assertNoAuthorizationFromDocument rejects any action that does not declare sourceOfAuthority: 'policy', before authorizeToolCall is even consulted. The eight tests in the "Mandatory failure 1" suite cover exactly these three layers, plus one test confirming the policy table is unchanged after processing the hostile fixture.

Failure 2 — the circuit breaker discards jobs

Symptom: the provider goes down, a circuit breaker opens to stop hammering an already-overloaded system — and once it opens, the jobs that were about to be processed simply vanish, because the "don't call the provider right now" logic never had an explicit path for what to do with the job instead. Cause: a circuit breaker that is well designed from the provider's point of view (stop overloading an already-struggling system) can be badly designed from the job's point of view, if "don't call" is treated as equivalent to "do nothing with the result." Response: callWithBreaker(breaker, fn, onOpenFallback) has no third path — if the breaker will not allow an attempt, onOpenFallback is called and its return value is handed back tagged shortCircuited: true; if it will, fn runs and its success or failure is recorded against the breaker. In every real usage in this chapter, onOpenFallback marks the job needs_review — the same safe terminal state chapter 2 already defined for any extraction needing human review, not a new state invented just for outages. One test proves the provider is never called again while the breaker is OPEN (real protection); another proves the job shows up as needs_review in the fallback (no loss). A per-key Bulkhead complements this by capping concurrency per tenant or provider, so one noisy neighbor cannot trip everyone else's breaker at once.

Failure 3 — rollback breaks the in-flight job schema

Symptom: a new policy version introduces a rule — in this chapter, requiresSecondApproval: true for a high-risk synthetic document type (wire-transfer-instruction), requiring two independent human approvals instead of one. Rolling code back to the previous version, which has never heard of that field, keeps approving the same document type with a single approval — not because anyone reverted the rule on purpose, but because the old code has no way to see a field the newer schema introduced. Cause: a code rollback is treated as "going back to a state that already worked," but jobs that already exist under the newer schema do not roll back with it — they keep carrying a guarantee the older handler has no code path to evaluate. Response: assertJobSafeForHandlerVersion(job, 'v1') refuses to process a job with requiresSecondApproval: true and fewer than two distinct recorded approvers — the same check passes freely for that job once a second, independent approval exists, and passes freely for any job that never carried the rule in the first place (no false positive). findJobsNeedingReconciliation(jobs, 'v1') scans an entire job list and returns exactly the ones a rollback would need to hand to a human before it can be declared complete — for this chapter's fixture, that is a single job, the exact one the failure describes. The rollback runbook (examples/operations/rollback-runbook.md) orders its actions around this: revert policy/prompt before code, run the reconciliation check, only then revert code — and never delete a log entry for an effect that already happened under the version being rolled back.

Failure 4 — a backup is assumed without a restore test

Symptom: a runbook or a teammate states "we have backups" — and the first time anyone actually attempts a restore is during a real incident, when it is already too late to discover the restore process never worked. Cause: the existence of a backup file proves nothing about recovery capability; it only proves an export ran once. Without an actual restore, "we have backups" is a belief, not evidence. Response: runRestoreDrill() does not claim recovery — it performs it: exports synthetic state (four jobs, one carrying failure 3's second-approval rule, three audit-log entries) to a real temp file on disk, discards every in-memory reference to the original state, re-imports purely from the file, recomputes a SHA-256 checksum over the restored content, and compares it against the checksum stored in the file itself. Run in this session, the normal drill recovered all four jobs and all three audit entries with counts and statuses identical to the original, in 1 to 3 milliseconds measured — a number that only proves the export/import code path is fast for a four-record synthetic snapshot on one laptop, not a production RTO target. A second scenario, deliberately corrupting a snapshot field after export, makes importState throw RestoreIntegrityError instead of silently importing bad data — the difference between a tested backup and an assumed one is exactly that second scenario existing and failing loudly when it should.

What the sandbox mock does not prove

runParserWithLimits races the parse call against a timeout with Promise.race and rejects if time runs out — this proves the calling code reacts correctly to a slow or hanging parser, nothing more. It does not prove operating-system isolation: a parser that burns CPU without ever yielding the event loop could hang the entire process before the timer's callback even gets a turn. It does not prove protection against a zip-bomb or a pathological file structure that expands into gigabytes in memory — the mock never actually runs a real parsing library against a real malicious file. The same honesty applies to the concurrency test: claimJobOnce proves the "exactly one winner" logic is correct within a single process and a single event loop; it does not create a genuine race between two operating-system processes contending for the same job — that is the identical limitation chapter 4 already stated for itself when it built the durable queue, and this chapter repeats it instead of pretending it has been solved.

Cost, security, and reversibility

Security and resilience meet in the same shadow/canary decision: a rollout plan (examples/operations/rollout-plan.md) that tests a new version against real traffic without affecting users still pays for every LLM call the test makes — shadow traffic is not free, it must go through the same chapter-6 budget reservation, only under a dedicated sub-quota, and its proposed effects must pass through the same authorization and egress guards before being deliberately discarded, never through a separate, less-tested code path. The rollout's stop criteria include a security criterion with no sample floor: a single occurrence of an attack fixture achieving an effect that should have been denied is enough to halt the stage, because a security regression is not a distribution to average over — unlike the quality criterion, which requires a minimum sample of twenty documents before it counts as evidence, reusing chapter 5's own sample discipline. Every decision in this chapter is also reversible by design, but with a caveat the four mandatory failures make explicit: reversible does not mean a bad version's effects disappear along with the code rollback — an email already sent stays sent, a document already approved with a single approval stays approved until human reconciliation reviews it. Rollback undoes the future cause, never the past effect; that is why the runbook treats reconciliation as a required step, not an optional cleanup.

Checklist

• Every authorization decision receives only identity and policy as input, never a field derived from document text or a claim the model made about itself.
• Every proposed action declares sourceOfAuthority: 'policy'; any other value is rejected before the policy check runs.
• Every upload passes type and size limits before the parser runs; every parse runs under a timeout the worker never waits on indefinitely.
• A circuit breaker never returns without calling either the real function or the caller's fallback; the fallback always marks the job needs_review, never discards it.
• An outage respects a per-attempt spend ceiling; retries are never unbounded.
• A code rollback runs the schema compatibility check and hands the reconciliation list to a human before it is declared complete.
• No rollback deletes a log or audit entry for an effect already executed.
• No backup claim is made without an actual, measured restore, including a tested expected-failure scenario (a corrupted snapshot).
• node --test examples/security/guards.test.mjs passes locally before any change to a guard, breaker, schema check, or restore drill.

Exercises

Basic — prove a hostile document never alters the tool allowlist. Verifiable criterion: run node --test examples/security/guards.test.mjs and confirm the "Basic exercise" suite passes, including the test that serializes DEFAULT_TOOL_POLICY before and after processing the prompt-injection-exfiltration fixture and compares the two strings. Worked solution: the same suite also confirms the table is frozen at every level exercised (Object.isFrozen on the root object and on each role's array), so even code that tried to push a new tool onto the extractor allowlist would throw TypeError before it could succeed.

Intermediate — prove a provider outage triggers safe review without infinite retries. Verifiable criterion: processJobWithFaultTolerance run against the 'unavailable' scenario must end with needsReview: true, job.review_status === 'needs_review', the breaker in state 'OPEN', and a recorded attempt count at or below the configured failureThreshold — even when asked for maxAttempts: 10. Worked solution: the corresponding test runs exactly that scenario with failureThreshold: 2 and confirms result.attempts.length <= 3 (two real calls plus, at most, one already-counted fallback attempt) instead of ten, proving the breaker cuts the attempt short before the nominal retry limit is ever reached.

Advanced — simulate a rollback with v1/v2 jobs and run the restore drill, recording measured RPO/RTO and their limitations. Verifiable criterion: findJobsNeedingReconciliation over a list containing a v1 job with no new rule, a v2 job with a single approval, and a v2 job with two distinct approvals must return exactly the second job; runRestoreDrill({ corrupt: false }) must return success: true with jobCountMatches and statusesMatch both true, and runRestoreDrill({ corrupt: true }) must return success: false with a checksum-mismatch error message. Worked solution: running node examples/operations/restore-drill.mjs directly prints both full reports — in this session, the normal drill measured 1 to 3 milliseconds of rtoMsMeasured for four synthetic jobs, against a didactic target of up to 30 minutes (DIDACTIC_TARGETS.rtoMinutes) for a hypothetical production deployment; a dedicated test ("didactic RPO/RTO targets are clearly separated...") exists solely to keep these two numbers — measured milliseconds and target minutes — from ever being compared as if they were the same unit or the same kind of evidence.

Short glossary

• Identity-plus-policy authorization: a decision to allow or deny an effect that depends only on who is asking and a deterministic table, never on the text of an untrusted document.
• Excessive agency: an agent with more tools, permissions, or autonomy than the task requires — OWASP's LLM06 category.
• Circuit breaker: a component that stops calling a repeatedly failing service, protecting that service, without ever discarding the work that was being processed.
• Bulkhead: a concurrency limit per key (tenant, provider) that isolates local overload from the rest of the system.
• Schema compatibility (rollback): the guarantee that an older-version handler refuses — instead of silently mishandling — a job carrying a rule only the newer version knows about.
• RPO (recovery point objective): how much data, in time, a system can afford to lose in a disaster — a target, not something this chapter measures.
• RTO (recovery time objective): how long a system can take to come back after a disaster — also a didactic target here, measured only against a synthetic local drill.
• Reconciliation: human review of effects already executed under a version being rolled back; rollback undoes code, reconciliation decides what to do about what already happened.

Bridge to chapter 8

This chapter assumed RelayOps stays a single service, a single worker pool, a single queue — and never asked whether that shape is still the right one once volume grows, once one tenant dominates the shared queue, or once document types vary enough that "one pipeline fits all" stops being true. Chapter 8 covers scaling with evidence: which measured bottleneck — not a good-looking microservices diagram — justifies splitting a service, partitioning data by tenant, or changing models, and how to prove the benefit of each change before declaring it done.