Substrate-Guard: Cross-Domain Mechanisms
- Substrate-Guard is a cross-domain design motif that uses substrate-level controls to mitigate limiting behaviors in semiconductors, secure systems, code agents, federated computing, and graphene transistors.
- It redistributes electrical potentials in CMOS sensors via floating guard rings, enforces least-privilege security by moving trust enforcement to the substrate, and modulates graphene contact resistance through interfacial dielectrics.
- The approach relies on fail-closed mediation and substrate-level trust to provide robust, actionable safety measures across diverse applications in both hardware and software domains.
Substrate-Guard is used in the cited literature for several substrate-centric mechanisms that place control at the layer that directly mediates a system’s limiting behavior. In 150 nm CMOS pixel detectors, it denotes floating substrate guard rings that redistribute lateral electric fields and suppress premature edge breakdown (Zhang et al., 2023). In agentic and secure systems, it denotes moving enforcement out of application code and into the execution substrate—eBPF, kTLS, attested channels, VM or container boundaries, typed toolchains, or a signed control plane (Wu et al., 26 May 2026, Winninger, 2 Jul 2026, Veeraragavan et al., 24 Jun 2025, Voulimeneas et al., 2021). A related device-physics usage appears in graphene electronics, where substrate gating of the contact region through an interfacial dielectric modulates contact resistance and electron–hole asymmetry (Berdebes et al., 2011). Across these works, the term is therefore used for more than one mechanism; a plausible implication is that it functions as a cross-domain design motif rather than a single standardized framework.
1. Cross-domain structure
The cited literature uses Substrate-Guard at the substrate that actually constrains the relevant process—electrostatic, kernel-mediated, runtime-constrained, control-plane, or interfacial (Zhang et al., 2023, Wu et al., 26 May 2026, Winninger, 2 Jul 2026, Veeraragavan et al., 24 Jun 2025, Voulimeneas et al., 2021, Berdebes et al., 2011).
| Domain | Substrate | Guarded failure mode |
|---|---|---|
| 150 nm CMOS pixel sensors | Floating guard-ring region | Premature edge breakdown |
| Agent-to-agent communication | Linux kernel, eBPF, kTLS, CVM boundary | Bypass of identity, authorization, provenance, delegation |
| Coding-agent oversight | VM/container boundary and code/toolchain constraints | Backdoors, unsafe IO, policy violations |
| Federated computing | Signed telemetry loop, DSL, EP abstraction | Noise-budget exhaustion, privacy-budget overflow, malformed shares |
| PKU sandboxing | PKU, ptrace monitor, syscall mediation | PKRU tampering and OS-level bypass |
| Graphene transistors | Bottom gate plus interfacial dielectric | Contact resistance and electron–hole asymmetry |
A recurring feature is fail-closed mediation. In the detector literature, the guard smooths potential so that the highest-field corner no longer reaches avalanche first. In the systems literature, the guard prevents application-level bypass by interposing on sockets, imports, filesystem access, process creation, or privileged state transitions. In the graphene case, the guard is electrostatic: the bottom gate can modulate the under-contact graphene potential only because the interfacial dielectric weakens pinning.
This family resemblance should not be mistaken for terminological uniformity. The pixel-detector and graphene usages are literal semiconductor substrate-control problems, whereas Grimlock, constrained coding agents, Guardian-FC, and Garmr use “substrate” to mean the machine boundary or control infrastructure beneath application logic.
2. Floating substrate guard rings in 150 nm CMOS pixel sensors
In n-in-p planar silicon pixel sensors fabricated in a commercial 150 nm CMOS line, the reverse bias required for fast drift and large depletion can produce high lateral electric fields at the matrix periphery, from the pixel or n-ring toward the chip edge. Substrate-Guard in this setting denotes multiple floating substrate guard rings that redistribute potential, smooth the lateral field, and suppress premature edge breakdown. Avalanche breakdown occurs when the peak field satisfies , with typical device-practice values . For a one-sided junction in p-type bulk, the depletion width is , and an idealized floating-ring ladder places the -th ring near ; the paper emphasizes that real layouts deviate because of geometry, oxide and interface charges, and overhang structures (Zhang et al., 2023).
Six passive n-in-p test structures, labeled A–F, were fabricated on Czochralski p-type wafers with typical resistivity 4–5 kcm and bulk doping . The wafer thicknesses were 725 m without backside processing and 200 m with backside p-type implant plus metallization. Each structure had a 15×6 pixel matrix surrounded by an n-ring and multiple floating guard rings within a total guard-ring width of 274 m. The layouts differed in the number of rings, the NR–GR1 spacing, the guard-ring implant type, whether a polysilicon overhang was present, whether deep n-wells were used at the pixels and n-ring, and, in structure E, whether an inter-pixel field-plate with adjustable 0 was present.
| Structure | Main guard-ring design | Distinguishing feature |
|---|---|---|
| A | p+ rings, 6 rings, GR1 gap 8 1m | single NW, inter-pixel p-stop |
| B | n+p rings, 6 rings, GR1 gap 8 2m | deep n-wells at pixels/NR |
| C | n+p rings, 5 rings, GR1 gap 32 3m | larger inner spacing |
| D | p+ rings, 6 rings, GR1 gap 8 4m | deep n-wells at pixels/NR |
| E | n+p rings, 5 rings, GR1 gap 32 5m | inter-pixel field-plate, adjustable 6 |
| F | n+p rings, 5 rings, GR1 gap 32 7m | no overhang |
Leakage-current I–V measurements were performed on unirradiated samples in the dark. For 725 8m devices the bias was ramped in 3 V steps every 5 s; for 200 9m devices, in 5 V steps every 5 s; five readings were averaged at each step. Breakdown was defined by the sharp current “knee,” while TCAD extracted 0 using a practical 1 1A threshold. For 725 2m devices with floating n-ring, the measured ordering was A: 3 V, D: 4 V, B: 5 V, C: 6 V, F: 7 V. Structure E at floating n-ring gave 8 V at 9 V, 0 V at 1 V, 2 V at 3 V, 4 V at 5 V, and 6 V at 7. For 200 8m devices, the best grounded-n-ring result was structure F at 9 V, compared with structure A at 0 V.
The measured correlations were consistent. Increasing the GR1 gap from 8 1m to 32 2m raised breakdown voltage, especially when the n-ring was grounded. Using n+p rings—p+ rings with a closely attached n-well—elevated floating ring potentials and improved breakdown relative to p+ rings. Removing the guard-ring overhang improved breakdown, since the overhang tended to depress floating potentials and increase the peak field at the n-ring. Deep n-well at pixels and n-ring improved breakdown when the n-ring was floating, but this benefit could vanish when the n-ring was grounded because the peak field relocated to the NR–GR1 corner. Structure F—n+p rings, 5 rings, GR1 gap 32 3m, no overhang, deep n-wells in the pixel/n-ring region—was identified as the best layout.
TCAD simulations in Sentaurus qualitatively reproduced the measured ordering and explained the field localization. With floating n-ring, the maximum field appeared between the pixel implant and p-stop, with the floating p-stop and n-ring effectively extending the potential ladder. With grounded n-ring, the peak moved to the NR–GR1 corner. The field-plate in structure E acted as a MOS capacitor over STI: negative 4 lowered the local surface potential and reduced the field at NR for floating n-ring, but an excessively negative gate moved the hotspot to the pixel corner and reduced 5. The practical design recipe given in the paper is a compact graded multi-ring substrate guard using 5 floating rings over about 274 6m, an inner NR–GR1 gap near 32 7m, n+p ring implants, deep n-wells in the pixel/n-ring region, no polysilicon overhang above STI near the guard rings, and grounded n-ring during operation.
The limitation explicitly stated is that all results are for unirradiated sensors. Radiation-induced positive oxide charge and interface traps can alter surface fields, so larger GR1 spacing and n+p ring concepts are described as generally robust, whereas MOS-based surface tuning must be re-optimized under radiation.
3. Substrate-level trust enforcement in agent-to-agent communication
In Grimlock, Substrate-Guard means moving trust enforcement—identity, authorization, provenance, and delegation—out of user or orchestration code and into the sandbox substrate, defined as the Linux kernel, eBPF enforcement programs, kTLS-assisted TLS 1.3 dataplane, and the sandbox boundary formed by per-agent confidential VMs and per-host guard proxy CVMs. The architecture consists of a source sandbox, a destination sandbox, source and destination guard proxies, and a kernel substrate that enforces mandatory mediation. All sandbox ingress and egress must traverse the local guard proxy, and the guard-to-guard path runs an agent-to-agent protocol over standard TLS 1.3 with post-handshake attestation (Wu et al., 26 May 2026).
The protocol is organized around channel binding and short-lived delegation. The source sandbox issues connect() from unmodified application code; eBPF intercepts and redirects the connection to the local guard proxy. The source guard performs a standard TLS 1.3 handshake to the destination guard, after which kTLS is configured for kernel-space record processing. Immediately after handshake completion, the guards compute a TLS exporter-derived channel binding,
8
with context including a fresh nonce, intended audience, and requested delegation scope. The responder returns TEE evidence that commits to 9, and a verifier mints a short-lived Scope Token bound to that hash, the scope, the audience, the expiry, and the destination identity. The destination guard re-validates token signature, expiry, audience, destination, channel binding, and attestation evidence before terminating TLS and releasing plaintext to the destination sandbox.
The policy model is least-privilege and fail-closed. The paper represents authorization as
0
with 1 only if the token signature verifies, the token is unexpired, the audience equals the destination identity, the requested scope is within the policy budget, and the current channel binding matches the token’s embedded 2. Three stated security targets structure the design: no-bypass, channel binding, and least privilege. No-bypass is supplied by eBPF mandatory mediation; channel binding prevents replay or diversion of authorization artifacts to other channels; least privilege is represented by short-lived scope tokens.
The design is intentionally transparent to application code. Orchestration code remains unchanged, because the guard operates at the socket and TLS substrate. Auditability is provided by per-flow state and policy decision logs, including source sandbox identity, destination, requested scope hash, and expiry. The paper explicitly contrasts this with service meshes, mTLS-only systems, SPIFFE/SPIRE, OAuth or JWT delegation, API gateways, and LSM-based enforcement: the claim is not that those mechanisms are absent, but that they do not, by themselves, combine no-bypass mediation, post-handshake attestation, and channel-bound authorization in the same way.
The limitations are also explicit. Grimlock states that kTLS provides an efficient dataplane but does not report throughput, latency, CPU measurements, or microbenchmarks. QUIC support is not described. Minimum kernel versions are not specified. Token revocation is handled primarily by short expiry rather than an active revocation protocol, and failures of guard proxies or attestation services are fail-closed, which may reduce availability.
4. Constrained substrates for scalable oversight of coding agents
For coding agents, Substrate-Guard denotes a substrate-level guardrail system that replaces advisory prompt instructions and heavyweight agentic scaffolding with hard constraints enforced by the language toolchain and the machine boundary. The “substrate” is defined as VM or container isolation, network egress policy, import and IO discipline, strict typing and dataclass shape, module-level invariants, and tooling that refuses to run non-compliant code. The central claim is that oversight becomes bounded invariant checking rather than open-ended comprehension, which allows a smaller reviewer to audit code produced by a stronger agent without saturating context windows or trusting prompts (Winninger, 2 Jul 2026).
The threat model includes silent backdoors, unsafe IO, and policy violations. Examples given are record-skipping flags, RCE via eval fields, swapped logprob mappings, secret exfiltration via HTTP calls, writes outside controlled paths, env-dependent toggles such as switching a model to train(), subprocess creation, and disallowed imports. The enforcement abstraction is formalized over a universe of actions 3 with an allow-set 4 and block-set 5, using
6
and otherwise 7, so the action is denied and logged. A global policy 8 composes import, network, filesystem, spawn, side-effect, and dataclass constraints under default deny.
The implementation is concrete and Python-specific. The constrained substrate uses ruff with security, bugbear, and bandit rules; pyrefly; beartype; pydantic models with strict and extra="forbid"; jaxtyping refined types; frozen=True, slots=True, kw_only=True dataclasses; tuple and Mapping in preference to list and dict; Literal[...] for discriminators; module-local Invariants: and Conventions: blocks; and a core/ versus runners/ split. Runtime and static enforcement include AST guards against eval, exec, dynamic imports, unsafe write paths, bare except, and global mutable state; an importlib.abc.MetaPathFinder whitelist; wrappers around requests, urllib, and subprocess; nftables plus a CONNECT-only tinyproxy allowlist; and VM or rootless Podman isolation depending on whether GPU access is required. The paper also describes an intercepting inference proxy so that every prompt and response crosses an editable boundary for semantic probes.
A distinctive element is a griffe-based docs CLI of about 200 lines of code. docs module X renders public API and local invariants or conventions; docs symbol X.Y renders signature, dataclass fields, and docstring; docs examples X is planned for property-based tests as executable specifications. This projection principle is designed to keep review bundles short, self-describing, and function-local.
The reported experiment used a synthetic Python LM-eval pipeline of about 500 lines of code in two substrates—unconstrained and constrained—with 11 inserted backdoors stratified from local syntactic manipulations to global invariant violations. The reviewer was Gemma 4 e4b, quantized Q4_K_M and served via llama.cpp at 64K context, with greedy decoding and a multi-pass per-function protocol.
| Condition | Recall | Precision |
|---|---|---|
| C1: unconstrained, no tools | 54.5% (6/11) | 100.0% |
| C2: unconstrained, docs CLI | 81.8% (9/11) | 100.0% |
| C3: constrained, no tools | 81.8% (9/11) | 88.9% |
| C4: constrained, docs CLI | 90.9% (10/11) | 95.7% |
The decomposition reported in the paper assigns three findings to substrate alone and three to tools alone, with one additional marginal finding in each combined comparison. Single-pass review regressed because of premature fixation; distributing self-consistency, IO contract, side-effect, and invariant-compliance lenses across passes raised performance to 10/11. Bundle sizes rose from about 1.3k to 6.0k characters across C1–C4, and multi-pass wall-clock time over all functions was 5–7 minutes on a single consumer GPU.
A common misconception addressed by the paper is that agentic scaffolding and retrieval necessarily improve oversight. The stated counterposition is narrower: large-context scaffolding can flood the model with raw payloads and tool schemas, whereas substrate-level constraints and local projections make the critical contracts textually local. The results are limited to the reported synthetic Python codebase and reviewer configuration, but the paper argues that the same constraint logic extends to Rust, with smaller expected gains on low-level type or mutation errors and larger gains on multi-file flow and global invariant violations.
5. Backend-neutral safety substrates for federated computing
Guardian-FC uses Substrate-Guard as a two-layer safety substrate beneath heterogeneous privacy-preserving backends. The upper layer is an Agentic-AI control plane composed of a Telemetry Collector, Sentinel plus Control Engine, Crypto Orchestrator plus Command Dispatcher, an append-only Merkle-ledger Audit Engine, and a Human Interface. The lower layer is the federated computation data plane, where nodes and a central aggregator each execute a finite-state workflow and run backend-neutral plug-ins over interchangeable Execution Providers that implement privacy-specific semantics for FHE, MPC, or DP. The control plane operates only on signed metadata—telemetry, commands, acknowledgments—and never on raw data or ciphertexts (Veeraragavan et al., 24 Jun 2025).
The formal model is explicit. Nodes run the lifecycle IDLE 9 PREF 0 INF 1 POSTF 2 DONE/ABORTED, the aggregator runs WAIT, MERGE, FINALIZE, or ABORTED, and the system state is represented as a synchronous product of the component FSMs. The paper states a safety invariant:
3
A ranking function over node and aggregator states supplies a liveness argument, and a risk estimator
4
drives transitions from EVALUATE to DISPATCH. Three example predicates are given: low noiseBits triggers A-BOOTSTRAP, excessive epsilonSpent triggers A-ABORT_JOB, and nonzero shareAuthFail triggers A-ISOLATE_PARTY.
The substrate is manifest-centric. A manifest specifies plug-in name and version, EP name and version, required DSL opcodes, metrics schema, enabled guardrails, privacy policies, and a manifest hash. Admission is fail-fast: every opcode must be implemented by the selected EP, every predicate must reference a declared metric, policy bounds must be admissible, and EP-specific constraints—such as no ciphertext branching in FHE or accountant selection in DP—must hold. Runtime telemetry is emitted symmetrically at 1 Hz, signed under per-role keys, sequence-numbered, schema-bound to the manifest hash, and incorporated into an append-only Merkle ledger.
The DSL is backend-neutral but typed by privacy modality. Suggested types include Plain[T], Enc[T, scheme], Share[T, scheme], Noisy[T, ε, δ], Agg[T], and policy types such as Budget[εmax, δmax], NoiseFloor[θ], Quorum[q], and Entropy[λmin]. The same plug-in logic can therefore be bound to different EPs at admission time, while the control plane continues to reason only over declared metrics. This is the core of the backend-neutral substrate guard claim.
The paper supplies scenario analyses rather than system benchmarks. In CKKS-FHE, low noiseBits leads to bootstrapping; in DP, budget overflow leads to abort and seed wiping; in MPC, malformed shares cause party isolation and quorum-based continuation or abort. Telemetry overhead is stated as 1 Hz frames per participant, with Ed25519 verification in microseconds to low milliseconds and command propagation adding 1–2 ticks. The authors position this as a formal foundation and research agenda rather than a completed performance study, with open directions in adaptive guard-rail tuning, multi-backend composition, DSL specification, telemetry normalization, human override usability, and model checking.
6. PKU-based in-process isolation as substrate guarding
Garmr presents a substrate guard for PKU-based in-process memory isolation. The hardware substrate is x86 Memory Protection Keys for Userspace, which provides 16 user-level protection keys, page tagging via pkey_mprotect, and a per-thread PKRU register whose AD and WD bits control data reads and writes. PKRU can be modified by unprivileged WRPKRU, and restored via XRSTOR when the relevant XSAVE component is selected. The paper’s argument is that self-contained PKU isolation cannot be complete unless both PKRU-changing instructions and OS surfaces are mediated at the substrate level (Voulimeneas et al., 2021).
The threat model assumes trusted hardware and kernel, trusted substrate-guard components, non-exploitable trusted code, and fully adversarial untrusted code capable of code reuse, gadget search, and multithreaded coordination. The attack surface includes WRPKRU, XRSTOR, ptrace, process_vm_{readv,writev}, /proc/self/mem, mmap, mprotect, munmap, mremap, mutable or shared mappings, pkey syscalls, and signal-context manipulation.
Two proof-of-concept attacks are central. The first is vetted unsafe instruction relocation: if hardware breakpoints are placed on unsafe WRPKRU instructions and a vetted page is then moved with mremap, the breakpoints remain at stale addresses, allowing execution of the relocated gadget. The second is incomplete debug-register update across threads: because DRx state is per-thread, programming breakpoints only for the current thread leaves other threads able to execute unsafe WRPKRU or XRSTOR sequences. These attacks are presented against Hodor but generalized to the design class.
Garmr’s architecture consists of an optional static binary rewriter, a custom loader, a ptrace-based monitor, and a minimal in-kernel syscall agent of about 79 lines of code. The monitor scans executable pages for unsafe WRPKRU and XRSTOR, whitelists only recognized call-gate sequences, places DRx breakpoints in the single-threaded phase, and, after the first additional thread is created, switches future unsafe pages to non-executable plus x86 instruction emulation so that unsafe instructions abort while benign instructions can be emulated safely. The monitor also tracks trusted-domain pages, reads PKRU via an RDPKRU trampoline, mediates mapping syscalls, enforces W5, disallows executable MAP_SHARED and MAP_SHARED_VALIDATE, converts file-backed executable mappings into anonymous copies, blocks /proc/self/mem through inode filtering, and denies from untrusted code such operations as modify_ldt, seccomp-related prctl, seccomp, ptrace, pkey_alloc, pkey_free, pkey_mprotect, shmat, and shmdt.
The formal invariants are phrased over domains and page sets. When executing in the untrusted domain, all trusted pages must be inaccessible under PKRU; transitions that expose trusted pages are allowed only via call gates; executable pages must not be simultaneously writable; and shared executable mappings are forbidden. The paper explicitly notes one residual gap: signal-context attacks based on sigreturn and XSAVE-state manipulation are not yet closed, although signal virtualization via ptrace interception is described as a feasible path.
The measured overheads are low on the reported workloads. On nginx, lighttpd, and redis, the geometric-mean overhead versus native was 0.47% for ERIM-OpenSSL, 0.33% for XOM-Switch, 1.43% for ERIM-SS, and 4.10% for ERIM-CPI, with the majority of CPI/CPS overhead attributed to the isolation scheme rather than to Garmr itself. The stated conclusion is that complete PKU substrate guarding can remain practical without external mitigations such as CFI.
7. Substrate gating of contact resistance in graphene transistors
A related but technically distinct use of substrate-level guarding appears in graphene transistors. Here the governing idea is that a bottom gate can tune the electron–hole conductance asymmetry and apparent contact resistance if there exists a thin effective dielectric layer between the metal contact and the graphene. That interfacial layer weakens Fermi-level pinning under the contact and allows electrostatic modulation of the graphene beneath the metal. The paper models this layer by an interfacial capacitance per unit area,
6
which competes with the bottom-gate capacitance and the graphene quantum capacitance (Berdebes et al., 2011).
The electrostatic model separates graphene under the contact from the gated channel. Under the contact, the self-consistent relation is
7
with 8. In the channel,
9
If 0 and 1, the contact region is effectively pinned; if 2, the bottom gate can shift the under-contact Dirac point and change the lateral junction from p–n to n–n or p–p.
The quantitative parameter set is specific. The back-gate capacitance was about 3, corresponding to roughly 300 nm SiO4; the top-gate capacitance was 5; the best fit used 6 and a work-function offset 7 eV for Ti/Pd/Au contacts. If the interfacial layer is vacuum or air, this gives an effective thickness of about 1.9 Å. Measured conductance asymmetry flipped sign as 8 was swept from 9 V to 0 V, with minimal asymmetry near 1 V, which the paper interprets as the contact region approaching charge neutrality. When the model sets 2, the inversion disappears within 3 V, demonstrating that substrate gating requires a not-too-large interfacial capacitance.
Transport across the lateral junction is treated quantum mechanically by a mode-space NEGF formulation, with conductance
4
The total two-terminal resistance is decomposed conceptually into channel resistance, quantum junction resistance, tunneling resistance, and possible access or crowding terms. The paper estimates a tunneling resistivity of about 5 for a pair of contacts, corresponding to an added tunneling resistance of about 520 6 for the device normalization used there. With an under-contact sheet resistance near 1660 7, the transfer length is about 560 nm. The ballistic junction component exhibits a plateau set by quantum contact resistance, with example pair-interface values of about 134 8m at 9 eV and about 45 0m at 1 eV.
The engineering guidance is explicit: maintain a thin, clean interface so that 2 remains of order 2–4 Å; avoid thick residue that increases 3 exponentially; use stronger back-gate coupling through thinner or higher-4 oxides; co-optimize top-gate and bottom-gate control; choose metals or interlayers that moderate 5 if asymmetry is problematic; and ensure contact length exceeds several transfer lengths. This use of substrate control is conceptually adjacent to the other Substrate-Guard variants because the decisive correction is again applied at the substrate that directly shapes the limiting physics, but the underlying mechanism is electrostatic rather than kernel-mediated or policy-mediated.