SafetyCore: A Minimal Safety Enforcement Pattern

• SafetyCore is a design pattern that establishes a trusted, isolated safety layer to mediate actions and mitigate high-risk failures.
• It is applied across AI, cyber-physical systems, and Android services using mechanisms like pre-action gating, lockstep fault detection, and TEE-backed authorization.
• Empirical studies and formal analyses validate SafetyCore through runtime monitoring, formal verification, and structured risk-scoring techniques.

SafetyCore is a recurring design pattern for high-assurance control in AI systems, cyber-physical systems, safety-critical hardware, and deployment governance. Across the cited literature, the term is used for a formal, multi-layer safety and containment stack for frontier-model sandbox infrastructure, a small, trusted safety subsystem in cyber-physical control, a time-staggered DMR lockstep pair for fault detection, a post-policy, pre-action safeguarding framework for GUI agents, a contextual robotic safety pipeline, a separate-process authorization kernel for agentic systems, a TEE-backed authorization mechanism for edge-deployed LLMs, a lexicographically structured corrigibility objective, a risk-scoring capability, and, separately, a concrete Android system service named com.google.android.safetycore (Blain, 22 Apr 2026, Mohan et al., 2012, Sarraseca et al., 2023, Feng et al., 10 Apr 2026, Ravichadran et al., 23 Feb 2026, Dobrin et al., 24 Jun 2026, Li et al., 2024, Nayebi, 28 Jul 2025, Muhammad et al., 24 Aug 2025, Guyomard et al., 8 Sep 2025). The common thread is not a single implementation but a class of architectures that place a minimal or specially protected mechanism between a capable system and high-consequence effects.

1. Terminology and scope

Taken together, the sources use “SafetyCore” in at least two distinct senses. In the architectural sense, it denotes a safety-enforcing substrate that is separated from a more complex or less trusted computational stack. In the product sense, it denotes an Android system service that performs on-device sensitive image content classification and triggers blur-and-warning behavior in client applications when an “explicit content” score exceeds a threshold inferred as $0.5$ after a sigmoid on a $4$-dimensional output (Guyomard et al., 8 Sep 2025).

The architectural uses span multiple domains:

Context	SafetyCore instantiation	Primary function
Frontier-model containment	COBALT, VERDICT, DIRECTIVE-4, SENTINEL	Arithmetic verification, policy gating, output mediation, runtime monitoring
Safety-critical CPUs	SafeLS	Time-staggered dual-core lockstep with comparison
Cyber-physical systems	S3A	Trusted safety controller, decision module, timing side-channel monitor
GUI agents	CORA	Risk-controlled execute/abstain gate with Diagnostician
Open-world robotics	CORE	VLM reasoning, spatial grounding, CBF enforcement
Escapable AI systems	Unfireable Safety Kernel	Separate-process pre-action authorization
Edge LLM deployment	CoreGuard	TEE authorization and propagative model locking
Corrigible agents	Core Safety Values	Five lexicographically ordered utility heads
AI governance	CORTEX	Multi-layer risk scoring and exposure assessment

This breadth matters because it prevents a common misconception: SafetyCore is not a single standard stack, nor is it reducible to “guardrails.” In some papers it is a runtime authorization mechanism, in others a formally analyzed containment layer, a lockstep hardware wrapper, a Simplex controller, or a risk-scoring overlay. A plausible implication is that the term has stabilized around a systems concept: a safety-critical core that remains comparatively simple, auditable, or isolated while supervising a more capable or more failure-prone outer system.

2. Core architectural principles

A recurring structural property is trust-boundary separation. In S3A, the trusted safety controller, decision module, and timing side-channel monitor execute on an FPGA physically separate from the CPU/OS, with direct sensor access and actuation authority (Mohan et al., 2012). In the Unfireable Safety Kernel, the control runs in a separate Rust process, with the agent having only read-only access to its interface and no write access to code, configuration, decision logic, or persistent state; this is formalized as property $P1$ of architectural control (Dobrin et al., 24 Jun 2026). In CoreGuard, the authorization module resides in a TEE while the rest of the model executes outside the TEE, under an explicitly white-box attacker model for the non-TEE environment (Li et al., 2024).

A second recurring property is pre-action or pre-execution mediation on the only path. The Mythos containment stack places COBALT before deployment, VERDICT before each action, DIRECTIVE-4 on emitted outputs, and SENTINEL on runtime behavior, explicitly mapping these layers to failure modes T1–T4 (Blain, 22 Apr 2026). CORA similarly inserts a SafetyCore controller between policy proposal and execution: the base policy proposes $\hat a_t$, the Guardian computes a risk score $s_t$, and Conformal Risk Control decides execute versus abstain before the action is carried out (Feng et al., 10 Apr 2026). The Unfireable Safety Kernel sharpens this into property $P2$: every consequential action must transit the kernel before effect, and the kernel must be on the structurally only path (Dobrin et al., 24 Jun 2026).

A third property is fail-closed behavior or fail-safe switching. In the Unfireable Safety Kernel, request-level failures such as unreachable kernel, malformed response, unverifiable signature, expired token, or replayed nonce all imply denial, while system-level failures imply “no kernel, no agent” (Dobrin et al., 24 Jun 2026). In S3A, the decision module switches to the safety controller when plant state or cyber timing indicates danger, with the trusted hardware capable of overriding commands from the compromised complex controller (Mohan et al., 2012). SafeLS uses DMR with comparison rather than TMR: on discrepancy it raises an interrupt to the system safety manager, assuming the workload can be re-executed within safety deadlines (Sarraseca et al., 2023).

A fourth property is observability and auditability. DIRECTIVE-4 and SENTINEL explicitly include content mediation, append-only logs, anomaly detection, and human-in-the-loop intervention (Blain, 22 Apr 2026). CORTEX pushes the same concern into governance instrumentation by requiring logging, model versioning, data lineage completeness, and residual-risk accounting in a composite risk register (Muhammad et al., 24 Aug 2025).

3. Formal methods and control formalisms

The literature is notable for treating SafetyCore not merely as an engineering pattern but as an object of formal analysis. In the Mythos paper, COBALT parses C/C++ sources with libclang, extracts arithmetic operations and casts, encodes them as Z3 bit-vectors, and returns SAT witnesses or UNSAT guarantees under explicit bounds for CWE-190, CWE-191, and CWE-195 classes. Representative encodings include unsigned-overflow checks such as ULT(a + b, a) and underflow checks such as UGT(hdr + tlv_len, len_val) (Blain, 22 Apr 2026).

SafeLS formalizes time-staggered lockstep with the invariants

$$t_{\mathrm{in},R} = t_{\mathrm{in},L} + \Delta t,\qquad t'_{\mathrm{out},L} = t_{\mathrm{out},L} + \Delta t,\qquad t_{\mathrm{cmp}} = t'_{\mathrm{out},L} = t_{\mathrm{out},R},$$

so corresponding architectural states are compared while the electrical states are never identical at the same instant. This timing relation is the central CCF-mitigation mechanism in the NOEL-V lockstep extension (Sarraseca et al., 2023).

S3A uses hardware timing monitors with MustWait_* and CanWait_* windows for control-task execution, period, and idle-task behavior. The prototype reports sensitivity to execution-time changes of approximately $0.6\,\mu s$ and end-to-end anomaly detection in approximately $5.7\,\mu s$, with the decision module switching to the safety controller when timing deviates beyond calibrated bounds (Mohan et al., 2012).

CORA formulates action safety as executed-harm control. With

$$L(Z_t;\tau) = \ell_t \cdot \mathbf{1}\{s_t \le \tau\},$$

and calibration rule

$4$0

it obtains the finite-sample guarantee

$4$1

under exchangeability (Feng et al., 10 Apr 2026).

CORE constructs a contextual safe set

$4$2

where $4$3 is the signed distance to the boundary of the grounded safe region, then enforces forward invariance through a control barrier function constraint

$4$4

The implemented controller solves a QP that minimally modifies $4$5 while satisfying the barrier condition, and the paper further states a trajectory-level probabilistic guarantee of the form

$4$6

under conservative perception assumptions (Ravichadran et al., 23 Feb 2026).

The Unfireable Safety Kernel formalizes architectural control through four properties: process separation, structurally-only pre-action enforcement, fail-closed behavior, and externalized signed evidence. Its fail-closed invariant is machine-checked in two ways: an SMT theorem in Z3 and exhaustive bounded-model checking of the production gate_decision function with Kani, with 4/4 proof harnesses verified (Dobrin et al., 24 Jun 2026). A different formal route appears in the corrigibility framework, where five structurally separate utility heads are combined lexicographically with strict weight gaps; Theorem 1 proves exact single-round corrigibility in the partially observable off-switch game, and Theorem 3 bounds multi-step safety-property violation probability under head-estimation error $4$7 and planner suboptimality (Nayebi, 28 Jul 2025).

4. Representative systems and empirical evidence

The frontier-model containment line provides direct software-security case studies. COBALT is evaluated on NASA cFE, wolfSSL ML-DSA, Eclipse Mosquitto, and NASA F Prime. The reported outcomes include a SAT witness for NASA cFE resource ID truncation, a SAT/UNSAT pair for wolfSSL signed left-shift undefined behavior followed by a patch via PR #10096, a Mosquitto underflow witness with len=1, tlv_len=5 producing result=0xFFF9, and an F Prime multiplication-wrap witness with size=0x80000001 and broken_mul=0x00000002. The system is designed as a CI/CD gate with SAT → block and UNSAT → certify under stated bounds (Blain, 22 Apr 2026).

In hardware fault tolerance, SafeLS reports a functional implementation that has been verified and validated, wrapping two NOEL-V cores into a time-staggered DMR pair and comparing output data transactions, generated interrupts, and exceptions. The paper does not provide quantitative coverage metrics, FIT rates, or overheads, but it does specify a programmable cycle offset, typically 2–3 cycles, as the main timing-stagger mechanism (Sarraseca et al., 2023). FlexStep extends the hardware notion of a SafetyCore in a different direction: instead of rigid lockstep, it supports asynchronous segment-based checking, dynamic main/checker assignment, and preemptive checker threads. The evaluation reports geomean slowdown versus native execution of 1.07% for PARSEC and 1.24% for SPEC in dual-check mode, 1.77% in triple-core mode, storage overhead of 1614 bytes per core, area overhead +2.21%, power overhead +2.89%, and microsecond-scale detection latency concentrated around 20 μs with maxima around 50 μs (Wang et al., 18 Mar 2025).

For cyber-physical systems, S3A demonstrates a SafetyCore on an inverted pendulum using a Xilinx ML505 FPGA, an Intel Q6700 at 2.67 GHz, and Linux 2.6.36. The measured CPU overhead per timing message is approximately 130 cycles (~0.05 μs), while baseline plant-only Simplex detection required approximately 100 ms to detect malicious actuation in the reported test case (Mohan et al., 2012).

For agentic AI, CORA reports on Phone-Harm and related benchmarks. On Harm-150, CORA achieves HR 4.37%, GAR 79.80%, IF1 85.29%, mHR 5.34%, and OIR 19.23%. On the merged 300-task Harm-150 + Normal-150 view, the reported figures are HR 2.19%, GAR 89.69%, IF1 85.29%, mHR 2.44%, and OIR 9.83%. On AndroidWorld core20 benign tasks, CORA reaches 8/20 tasks (40.0% SR) (Feng et al., 10 Apr 2026). In robotics, CORE reports simulation performance of 95.0% total success, 96.6% on safe tasks, and 93.3% on unsafe tasks across 60 trials, and Spot hardware performance of 86.6% total, 86.6% safe, and 86.6% unsafe across 30 trials (Ravichadran et al., 23 Feb 2026).

The Unfireable Safety Kernel evaluates a live, escapable AI system under an escape-seeking adversary. Across 1,000 self-modifications, 296 benign changes were permitted and all 704 attempts on the safety-critical core were refused, with no escape. Under the operator kill switch, a further 300 modifications were refused. A separate campaign of 6,240 authorization round-trips had no successful bypass. At concurrency C=20, the reported p99 latency is 496.9 ms for Rust versus 920.0 ms for Python (Dobrin et al., 24 Jun 2026).

CoreGuard provides an edge-deployment instantiation of SafetyCore. It reports unauthorized direct inference accuracy of 0% across evaluated cases, TEE FLOPs overhead below 0.1% of original model FLOPs, and 5 TEE–GPU transfers per inference. Against model-stealing attacks, the average attack accuracy relative to the black-box baseline is 1.17× for CoreGuard, close to 1.00× for the black-box baseline and 1.18× for DTE (Li et al., 2024).

5. Limitations, attacks, and misconceptions

The strongest recurring limitation is that SafetyCore mechanisms are only as complete as their threat models and enforcement surface. COBALT explicitly states that SAT witnesses are formal reachability witnesses within the encoded arithmetic context, while full-path reachability is not guaranteed because local encodings abstract the environment; JIT or binary-only paths are outside libclang parsing, and deep composed chains increase solving time (Blain, 22 Apr 2026). CORE’s guarantees depend on conservative perception assumptions, bounded sensing radius, safe initialization, and a separation of timescales between fast control and slower perception, with failure modes including VLM hallucinations, grounding errors, and latency (Ravichadran et al., 23 Feb 2026).

Several systems are intentionally detection-only rather than correction-capable. SafeLS uses DMR with comparison, so a mismatch signals failure but does not identify which core is correct (Sarraseca et al., 2023). FlexStep similarly emphasizes segment-level detection and reconfiguration but does not elaborate a full correction policy (Wang et al., 18 Mar 2025). S3A guarantees plant safety under its modeled invariants but assumes deterministic, periodic tasks, protected SafetyCore hardware, and carefully calibrated timing windows; it also notes spoofing risk if timing messages are naively implemented (Mohan et al., 2012).

For statistical SafetyCore mechanisms, the guarantee may be weaker than a casual reading suggests. CORA’s conformal guarantee is on the expected harmful executed actions at the next test point under exchangeability; it is not a conditional statement of the form $4$8 (Feng et al., 10 Apr 2026). The corrigibility framework similarly pushes the remaining difficulty into data coverage and generalization of the five heads rather than claiming to solve misspecification outright (Nayebi, 28 Jul 2025).

The Android case demonstrates that the name “SafetyCore” does not imply architectural invulnerability. The studied Android system service ships a quantized TFLite model identifiable by the FlatBuffers magic TFL3, with input shape 1 × 224 × 224 × 3 and output shape 1 × 4. The paper reports successful extraction, dequantization, conversion to a differentiable PyTorch proxy, and PGD-based false-positive generation; it also states that no TEE-backed inference, attestation, or runtime integrity protections were observed or reported in that study (Guyomard et al., 8 Sep 2025). This distinguishes nomenclature from assurance: a component may be called SafetyCore yet still fail core isolation or anti-extraction criteria that other SafetyCore papers treat as central.

The Unfireable Safety Kernel also circumscribes its claims. Side-channel leakage via allow/deny timing or content is acknowledged as not yet implemented away; fail-closed behavior preserves correctness under kernel DoS but not availability; and formal verification currently covers the decision function rather than the entire token-signing, Merkle, and policy-evaluation path (Dobrin et al., 24 Jun 2026). CoreGuard likewise assumes a secure TEE and places side-channel attacks out of scope (Li et al., 2024).

6. Broader significance and research trajectory

Across the corpus, SafetyCore marks a shift from behavior-only safety toward system-level enforcement. The Mythos paper states this most directly: frontier-model safety cannot depend on behavioral safeguards alone, because capable agents can exploit conventional systems weaknesses in C/C++ infrastructure regardless of model alignment or output filtering (Blain, 22 Apr 2026). The Unfireable Safety Kernel makes an analogous claim for agent authorization: controls inside the agent’s own address space are reachable by inputs that influence the agent, so architectural control requires process separation and pre-action enforcement on the only path (Dobrin et al., 24 Jun 2026).

A second trajectory is the move from monolithic objectives to structured safety decomposition. CORA separates policy proposal, risk estimation, conformal calibration, and intervention routing (Feng et al., 10 Apr 2026). CORE separates contextual reasoning, spatial grounding, and CBF enforcement (Ravichadran et al., 23 Feb 2026). The corrigibility framework separates deference, switch-access preservation, truthfulness, low-impact behavior, and bounded task reward into five structurally separate heads combined lexicographically (Nayebi, 28 Jul 2025). This suggests that SafetyCore increasingly denotes not merely a guard but an architecture in which different safety obligations are represented by different mechanisms and dominate task optimization in a specified order.

A third trajectory is the extension of SafetyCore from enforcement to governance and auditing. CORTEX defines a five-tier architecture that combines utility-adjusted Likelihood × Impact, governance and contextual overlays, technical surface scores, environmental and residual modifiers, and Bayesian plus Monte Carlo aggregation. Its weighted composite

$4$9

is intended for AI risk registers, model audits, conformity checks, and dynamic governance dashboards (Muhammad et al., 24 Aug 2025). This broadens the term from runtime interlocks to organizational observability.

The cumulative picture is therefore architectural rather than doctrinal. SafetyCore, in the surveyed literature, names the protected locus where high-consequence safety properties are made explicit, checked, enforced, and auditable—whether by SMT constraints, lockstep comparison, Simplex switching, conformal gating, control barrier functions, TEE-backed authorization, lexicographic utility separation, or layered risk scoring. A plausible implication is that future uses of the term will continue to converge on this role: the smallest subsystem on which the broader system’s safety case actually depends.