Deterministic fallback: security that keeps its verdict when the model goes dark

2026-10-20 — a growing share of agent safety now runs on models: classifiers that label an action risky, reviewers that flag unsafe suggestions, assistants that explain the policy. All of them share one failure mode their demos never show: the model stops answering. Timeout. 429. Network failure. Malformed output. A hallucination signal. A confidently unsafe recommendation. The question is not whether that happens — it is what your security layer does in the second it happens.

The two defaults we refuse

There are two ways to fail, and they are opposites. “No model → allow everything”: the guardrail quietly vanishes during exactly the outages that correlate with weird agent behavior, and you learn from the bill or the incident, later. “No model → block everything”: safety becomes an outage generator, teams disable it within a week, and you learn the same way, later. The written design contract at 20131 rules out both by name. The fallback target is deterministic local security: a verdict the machine can still render with no cloud, no model, and no apology.

What “deterministic” means concretely here

• The evaluator is plain code against a versioned local rule file — same input, byte-identical verdict, every time. No request leaves the process to decide anything.
• Verdicts are graded, not binary: every action is judged by risk, sensitivity, impact and reversibility, so a degraded state can tighten what matters and leave the boring path moving.
• The fast path stays fast: in-process evaluation adds no round trip, which is what makes “hold this action for judgment” viable at all.
• Honest scope today: Phase 0 renders would_block and allow — and records both. Enforcement is a later phase with its own announcement; the fallback machinery exists so that phase never has to depend on somebody’s API being up.

Where this shows up on an ordinary day

Provider incidents make the abstract concrete: during an outage, agents retry harder (which is also a spend event — see <a href="/en/blog/ai-agent-cost-overruns-hard-limits/">the cost-overrun anatomy</a>), and a model-gated reviewer either blocks the whole workspace or stamps “passed” on traffic it never saw. A local deterministic layer is the boring third option: the file-system and process-level judgments do not change because the network did. What is visible locally, and what is not claimed, is laid out on the <a href="/en/security/">security model</a> page and the <a href="/en/docs/">docs</a>; the pipeline it plugs into is on <a href="/en/how-it-works/">how it works</a>.

Why this belongs on a blog about agents

Because the interesting risk in agent software is composition: a skill from somebody’s repo (<a href="/en/blog/agent-skill-supply-chain-risk/">supply-chain visibility</a>) steering a process tree (<a href="/en/blog/what-is-agent-observability/">observability</a>) that spends your credit limit (<a href="/en/blog/agent-actions-audit-trail/">audit trail</a>) — and every model in that chain can 429 at once. The layer that stays up is the one with nothing to call. If you want the enforcement side to arrive without a cloud dependency, say so on the <a href="/en/early-access/">Early Access waitlist</a>: it is where “fallback must be local” gets counted before it gets built.