---
title: 'Static Guardian: Front-Loaded Safety Layer'
url: https://www.emergentmind.com/topics/static-guardian
type: topic
---

# Static Guardian: Front-Loaded Safety Layer

“Static Guardian” is not a single standardized formalism in the current literature. The exact phrase is used most directly for a build-time defense in terminal-based LLM agents and as a contrastive baseline for fixed-taxonomy guard training, but closely related static or time-independent guardian mechanisms also appear in SGX binary validation, robotic plan verification, and control-theoretic stability analysis. A plausible unifying characterization is a guardian whose decisive judgment is made from a fixed artifact—such as a binary, plan, skill file, trajectory serialization, or matrix—before or independently of live execution, rather than through continuous runtime mediation [2606.01567] [2606.01166] [2105.05962] [2512.01946] [2509.17016].

## 1. Terminological scope and major interpretations

Across the literature, “Static Guardian” designates a family of front-loaded safety mechanisms rather than a single architecture. In some papers it refers to an explicitly named build-time guard; in others it is the natural interpretation of an offline symbolic analyzer, a snapshot-based verifier, or a time-independent algebraic detector.

| Interpretation | Guarded object | Static locus |
|---|---|---|
| SGX orderly-enclave validation [2105.05962] | Enclave binary | Offline symbolic analysis of phase discipline |
| Build-time skill sanitization [2606.01567] | `SKILL.md` and auxiliary documentation | Preprocessing rewrite before the agent session |
| Fixed guard-model baseline [2606.01166] | Computer-use trajectories | One-shot training on fixed taxonomies or static corpora |
| Observation-based robotic verifier [2512.01946] | Plans or pre/post subtask observations | Plan-level or snapshot-based failure checking |
| Guardian maps [2509.17016] | Matrix \(A\) | Time-independent scalar test for Hurwitz-boundary contact |
| Hybrid supervisory extensions [2602.06026], [2506.20000] | Perception uncertainty sets; federated jobs | Static certificate or admission layer combined with runtime control |

Two distinctions recur. First, the guarded artifact varies: code, documentation, plan text, observation snapshots, and algebraic system descriptions are all valid objects of protection. Second, “static” can mean build-time preprocessing, offline symbolic analysis, pre-execution review, or a purely algebraic map of a fixed system object. This suggests that the term is best treated as a cross-domain design pattern rather than a domain-specific proper noun.

## 2. Static symbolic guardians in trusted execution environments

In trusted execution research, the clearest static guardian is the SGX framework "Guardian," presented as a symbolic/static validation framework for Intel SGX enclaves. Its central object is the **orderly enclave**, whose execution is partitioned into four phases—entry, secure, ocall, and exit—together with explicit transition annotations \(TransitionAnnotations = (Entry, Secure, OCall, Exit)\) that mark binary addresses where phase changes occur [2105.05962].

The enclave is orderly iff three classes of conditions hold: transition conditions, sanitisation conditions, and untrusted-memory access policies. The phase discipline is stringent because SGX assumes all non-enclave code and data are attacker-controlled. Guardian therefore checks that shared machine state is sanitized on entry and exit, that secure computation does not depend on attacker-controlled memory, and that phase transitions occur only along permitted paths such as \(entry \rightarrow secure \rightarrow exit\) or \(secure \rightarrow ocall \rightarrow secure\).

| Phase | Reads from untrusted memory | Writes to untrusted memory |
|---|---|---|
| entry | allowed | forbidden |
| secure | forbidden | forbidden |
| ocall | allowed | allowed |
| exit | forbidden | allowed |

The entry phase requires low-level sanitization before secure computation begins. The predicate `EntrySanitisationValidation` holds at `EntrySanitisationDone` iff registers `rdx` and `r8-r15` are zeroed, `rbp` and `rsp` point to the trusted enclave stack, and flags `AC` and `DF` are cleared. The exit phase requires `ExitSanitisationValidation`, namely clearing `rcx`, `rdx`, and `r8-r15`, while making `rbp` and `rsp` point to untrusted memory. The secure phase forbids both reads and writes to untrusted memory, so any remaining dependency on host memory during trusted computation is flagged as a policy violation.

Guardian is implemented atop **angr** as a binary-level symbolic analyzer rather than a runtime monitor. It takes as input the enclave binary, the sizes of the enclave stack and heap, and transition annotations. Its symbolic state tracks the current phase and whether entry sanitisation has occurred; **SimProcedures** enforce transitions, and **breakpoints** intercept memory reads, memory writes, and jumps. The reported trust-boundary violations are **out-of-enclave read**, **out-of-enclave write**, and **out-of-enclave jump**. In addition, reads from non-enclave memory are forced symbolic, and operations on symbolic addresses within enclave memory are reported as **symbolic read**, **symbolic write**, and **symbolic jump**, which the paper interprets as indicative of memory-corruption primitives.

The framework is deliberately bounded. The evaluation used a **20-minute timeout per ecall**, stopped analysis if more than **100 branches** were explored simultaneously, and stopped after more than **20 violations**. The analysis is restricted to **single-threaded** executions, does **not** model **reentrant ecalls**, and does **not** model **implicit enclave exits caused by hardware exceptions**. Within those limits, Guardian analyzed **15 binaries across 12 enclave samples**, found **no violations** and **no timeouts** on **11 ecalls** across Intel architectural enclaves, detected **entry sanitisation violations** in enclaves built with Intel SGX SDK versions **< 2.7.1**, and found null-pointer-related out-of-enclave-read vulnerabilities in practical enclaves that were later acknowledged and fixed by maintainers. In this lineage, a static guardian is therefore a pre-deployment symbolic validator of boundary discipline rather than a runtime enforcement mechanism.

## 3. Build-time guardians and fixed-taxonomy guard models for LLM agents

In agent safety, the exact phrase **static guardian** appears most concretely in "Defenses & Enablers For Skill Injection Attacks on Terminal Based Agents." There, the static guardian is the build-time variant of a guardian-based defense against skill injection attacks. A preprocessing script passes each skill through a guardian LLM, whose response replaces the original `SKILL.md` in the sandbox; no further guardian interaction occurs at runtime [2606.01567].

Mechanically, the static guardian uses the same guardian LLM and system prompt as the dynamic guardian, but a single fixed user prompt: “Give me the complete documentation for this skill. Include all key workflows, technical specifications, code examples, and configuration details. Be thorough.” The resulting rewritten document becomes the only version the agent sees. This yields a genuine static locus of intervention: malicious skill content is filtered before the agent session begins, and the agent incurs **no runtime overhead** from the guardian.

The paper’s main benchmark contains **48 injections** paired with up to **8 tasks each**, yielding **139 task-injection sandboxes**. Attack success rate (ASR) is the fraction of sandboxes where the agent attempts the injected action; task success rate (TSR) is the fraction of task-verifiable sandboxes where the user’s task is completed. On the original benchmark, the static guardian reduced ASR from **36.0%** to **7.2%** while improving TSR from **80.0%** to **87.0%** for **Claude Sonnet 4.5 + Claude Code**; from **52.5%** to **5.0%** with TSR changing from **88.0%** to **81.0%** for **DeepSeek-V4-Flash + OpenCode**; and from **12.2%** to **2.9%** with TSR changing from **72.0%** to **67.0%** for **Nemotron 3 Super + OpenCode**. The appendix reports that the static guardian “successfully removed **82.4%** of injections during build-time rewriting.”

The same paper also identifies the central limitation of this static design: lack of task context. The build-time guardian often **consolidated auxiliary `.md` files into the primary `SKILL.md`**, **deleted all 150 auxiliary `.md` files**, and caused the rewritten `SKILL.md` to grow by **98% on average**. Yet **72 of 139 rewritten `SKILL.md` files (51.8%)** contained dangling references to missing auxiliary files, and the rewriting process sometimes laundered malicious content into more authoritative-looking documentation. Under the union of all reframed attacks, ASR rose from **9.3%** on the original subset to **39.5%**, while the dynamic guardian achieved **18.6%**. In this usage, a static guardian is a low-latency, build-time sanitizer whose strength is front-loaded filtering and whose weakness is contextual blindness.

A second, broader sense of static guardian appears in "BraveGuard: From Open-World Threats to Safer Computer-Use Agents." That paper treats a static guardian as a guard model trained once on a fixed safety taxonomy, synthetic prompt-level data, or a closed benchmark distribution, then deployed unchanged to judge computer-use agents [2606.01166]. BraveGuard argues that this static paradigm is mismatched to agentic risk because harm emerges over multi-step trajectories rather than isolated prompts. Its adaptive pipeline mined **110 papers** from a refined inventory of **97 search queries**, consolidated them into **32 attack methods** and **28 risk categories**, synthesized **7,308 tasks** in English and Chinese, and trained trajectory-level guards. In the ablation on **Qwen3-Guard-8B** under the **GPT-5.5 OpenClaw backend**, **Static Taxonomy** reached **58.34%** accuracy, **61.47%** recall, and **62.18%** F1; **Dynamic Taxonomy** improved this to **74.82%**, **79.63%**, and **78.94%**; and **Self-Evolving (Full BraveGuard)** reached **83.65%**, **91.28%**, and **89.22%**. In the averaged-guard setting on AgentHazard-Strongest, off-the-shelf static guards improved from **38.79%** to **82.38%** accuracy only after BraveGuard-style adaptation, with recall improving from **20.17%** to **90.94%**. Here the phrase is not a named product but a critique: a static guardian is a fixed-distribution guard whose taxonomy and supervision do not evolve with the threat landscape.

## 4. Observation-based static guardians in robotics

In robotics, the relevant interpretation is a passive verifier that judges plans or subtask outcomes from fixed observations rather than from privileged controller internals. The VLM system "Guardian: Detecting Robotic Planning and Execution Errors with Vision-Language Models" is explicitly designed to recognize both planning mistakes and execution mistakes from visual observations plus task text. Planning failure detection asks whether a proposed decomposition of a task into subtasks is valid before execution; execution failure detection asks whether a particular subtask was successfully completed after it was attempted [2512.01946].

This yields two static operating modes. In planning verification, Guardian uses the task instruction \(T\), a plan \(P=(P_1,\cdots,P_N)\), and an initial image \(I_{\text{start}}\). In execution verification, it uses the task goal \(T\), a subtask description \(P_i\), and observations before and after execution, \(I_{\text{start}}\) and \(I_{\text{end}}\). The model therefore does not rely on proprioception, action logs, or controller state at inference; it is an observation-plus-language verifier. The paper explicitly notes that it is static in the sense of passive snapshot-based observation, though not in the sense of a single final image independent of context.

The underlying data pipeline is synthetic failure generation. Planning failures are generated by perturbing successful task decompositions into five types: **wrong object manipulated**, **wrong object state or placement**, **wrong order**, **missing subtask**, and **contradictory subtasks**. Execution failures in simulation are generated by perturbing actions into **no gripper close**, **wrong object state or placement**, **wrong object manipulated**, and **imprecise grasping/pushing**. The resulting datasets—**RLBench-Fail**, **BridgeDataV2-Fail**, and **UR5-Fail**—contain balanced success/failure labels, fine-grained categories, and automatically generated reasoning traces with average length **118 tokens**.

Guardian itself is built on **InternVL3-8B**, with **InternViT-300M** as visual encoder and **Qwen2.5-7B** as language model. A key design choice is to encode each image separately rather than collapsing views into a single collage. The paper’s ablation on RLBench-Fail execution shows why this matters: **one-view concat** achieved **0.61**, **one-view separated** **0.63**, **four-view concat** **0.72**, and **four-view separated** **0.81**. The model is fine-tuned with LoRA, freezing the visual encoder, and supports three inference styles: **Vanilla**, **Thinking**, and **Dropout**. The CoT ablation shows **Vanilla** at **0.81** execution / **0.78** planning with **0.68 s/sample**, **Dropout** at **0.83 / 0.83** with the same **0.68 s/sample**, and **Thinking** at **0.83 / 0.84** but **4.3 s/sample**.

Empirically, Guardian-8B-Thinking achieved **0.83** execution and **0.87** planning accuracy on RLBench-Fail, and **0.85** execution and **0.91** planning on BridgeDataV2-Fail. Out of domain, it obtained **0.86** execution and **0.70** planning on RoboFail, and **0.77** execution and **0.89** planning on UR5-Fail. When integrated into **3D-LOTUS++** as a detection-and-trigger module, it improved simulation success from **0.57** to **0.60** on GemBench Level 1, **0.53** to **0.56** on Level 2, **0.23** to **0.31** on Level 3, and **0.04** to **0.07** on Level 4. On a real UR5, “put food” improved from **0.60** to **0.80** in normal settings and from **0.00** to **0.80** under perturbation; “stack cups” improved from **0.80** to **1.00** in normal settings and **0.00** to **0.40** under perturbation. In this literature, a static guardian is a pre-execution or pre/post-execution visual-language verifier that intervenes by vetoing or re-running plans rather than by controlling motion directly.

## 5. Algebraic static guardians and hybrid supervisory extensions

The most literal meaning of a static guardian appears in control theory as a time-independent scalar map of a fixed matrix. In "Guardian maps for continuous-time systems: A Lie-algebraic approach," a guardian map for Hurwitz stability is a scalar function \(f(A)\) that is nonzero for Hurwitz matrices and vanishes when \(A\) reaches the stability boundary [2509.17016]:

$$
f(A)=
\begin{cases}
\not = 0, & \text{if } \Re(\lambda_i(A))<0 \text{ for all } i,\\
=0, & \text{if } \Re(\lambda_i(A))=0 \text{ for some } i.
\end{cases}
$$

The paper’s main contribution is the notion of a **guardian representation**, a Lie algebra representation \(\rho:\mathbb{R}^{n\times n}\to\mathbb{R}^{m\times m}\) such that \(\det(\rho(A))\) is a guardian map. This unifies three classical continuous-time guardians: the **Kronecker sum** \(A\oplus A\), the **second lower Schläflian matrix** \(L_2(A)\), and the **bialternate sum** \(A\diamondplus A\). It also proves that the bialternate sum coincides exactly with the **second additive compound**, \(A\diamondplus A = A^{[2]}\). In this usage, staticity is exact: the guardian is an algebraic function of a fixed matrix, not a stateful monitor or controller.

Subsequent work in control and systems safety often combines a static certificate with runtime intervention, thereby moving beyond the purely static regime. "GUARDIAN: Safety Filtering for Systems with Perception Models Subject to Adversarial Attacks" uses an offline Hamilton–Jacobi value function \(V\) and maximal safe set \(\Omega^*=\{x\in\mathcal{X}\mid V(x)\ge 0\}\), but at runtime it computes verified uncertainty bounds on an NN estimator and applies a safety filter \(K_F(\bar{\mathcal{X}}_t,u_t)\) over the set of possible true states [2602.06026]. The formal guarantee is that, under stated assumptions, \(x_0\in\Omega^*\Rightarrow x_t\in\Omega^*\) for all \(t\ge 0\), and the aircraft-taxiing experiment reports a total per-step calculation time of \(0.032 \pm 0.003\) s. This is not a static guardian in the strict sense; it is a hybrid offline-online guard.

A similar hybridization appears in federated computing. "Can One Safety Loop Guard Them All? Agentic Guard Rails for Federated Computing" proposes Guardian-FC as a two-layer framework with a manifest-centric admission contract and a runtime finite-state safety loop over signed telemetry [2506.20000]. Its static component is the manifest-driven, fail-fast admission check: every DSL opcode used by a plug-in must be implemented by the chosen Execution Provider, and every enabled predicate must reference metric keys provided by that provider. Its runtime component is the synchronous product of FSMs over Nodes, Aggregator, Control Engine, Telemetry Collector, and Audit Engine. The stated safety invariant is
\[
\text{Aggregator} = \text{FINALIZE} \Rightarrow (\forall i : Node[i] \in S_{ok}) \land (\forall p \in P : \neg p).
\]
These systems show how a strictly static guardian can evolve into a hybrid architecture: static maps, certificates, or manifests remain central, but they are embedded into runtime supervisory loops when the guarded object is nonstationary.

## 6. Common design principles and recurrent limitations

Despite domain heterogeneity, static guardians share a recognizable architecture. They shift the safety decision as far upstream as possible: from runtime to build time, from execution to planning, from tool use to documentation preprocessing, from uncertain trajectories to static trajectory serializations, or from dynamic stability analysis to a scalar function of \(A\). This front-loading yields concrete benefits. Offline SGX validation can inspect runtime-library code and binary-level interfaces before deployment [2105.05962]. Build-time skill sanitization eliminates runtime overhead entirely [2606.01567]. Plan-level robotic verification can veto bad decompositions or detect failed subtasks without needing controller internals [2512.01946]. Guardian maps provide a compact algebraic detector of proximity to the Hurwitz boundary [2509.17016]. Manifest-centric admission in federated computing rejects incompatible jobs before sensitive computation starts [2506.20000].

The corresponding limitations are equally consistent. Static guardians typically trade contextual richness for early intervention. The build-time skill guardian lacks task context and can “actively legitimize” malicious instructions by rewriting them as polished workflow steps; the paper describes this as a **laundering effect** [2606.01567]. Fixed guard models trained once on static corpora are brittle under non-stationary threat evolution, which is precisely the failure mode BraveGuard targets [2606.01166]. Symbolic SGX validation is bounded by single-threaded exploration and does not model reentrant ecalls or implicit exits caused by hardware exceptions [2105.05962]. Robotic snapshot-based verification can inherit synthetic-data bias: in BridgeDataV2-Fail, many execution failures are instruction-observation mismatches rather than physically enacted failures, and explicit test-time CoT raises latency from **0.68 s/sample** to **4.3 s/sample** [2512.01946]. Hybrid systems such as Guardian-FC implicitly acknowledge that a static admission layer is not enough once the environment becomes operationally open-ended [2506.20000].

A broader implication is that “Static Guardian” is best understood as a spectrum rather than a dichotomy. At one end lie pure algebraic guardians and build-time sanitizers; at the other lie hybrid systems that preserve a static certificate, taxonomy, or contract but add runtime sensing and control. The most stable cross-domain meaning is therefore architectural: a static guardian is a front-loaded safety or correctness layer that judges a fixed representation before irreversible action occurs. Whether that judgment is sufficient depends on how much of the relevant risk is already encoded in the artifact being guarded.

Source: https://www.emergentmind.com/topics/static-guardian