> For the complete documentation index, see [llms.txt](https://osintelligence-llc.gitbook.io/osintelligence/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://osintelligence-llc.gitbook.io/osintelligence/part-i-the-architecture/2-the-external-sentinel.md).

# 2 · The External Sentinel

**The External Sentinel: A hardware substrate for the External Governor of a self-improving AI system: replacing the human-in-the-loop with a device the governed system cannot reach**

*Chapter 2 · Part I: The Architecture · Design-tier · v1.0.0*

**Author:** Jamey Kistner, OSINTelligence LLC

**Keywords:** External Governor · hardware-rooted trust · TPM attestation · self-improvement integrity · out-of-band verification · incorruptibility

> **A companion paper.** This report specifies one component of a larger architecture developed across a series of related papers: the External Governor named in the Sovereign Triad, and the mechanical closures whose absence is documented in the Drift Taxonomy. It can be read on its own, but it is written to sit alongside those papers rather than restate them.
>
> **Status note.** The Sentinel described here is, at the time of writing, a design rather than a deployed device. The function it is meant to perform is not hypothetical: on the author's production system that function is currently performed by the human operator, by hand. This paper specifies the substrate intended to replace that manual role. The implementation-maturity of each element is stated plainly in the limitations section.

> **What is new here.** The contribution is a device: an out-of-band, hardware-isolated co-processor that gates every self-modification cycle by comparing a signed governance manifest, by exact cryptographic equality, against a reference sealed in hardware the system cannot read or alter. Two commitments are load-bearing and are stated as design rather than result: the decision is a deterministic byte-equality check against a sealed reference, not a learned safety classifier, and the one act the device must never perform on itself, changing that sealed reference, is gated by a physical write-protect switch no software the system runs can throw. The paper specifies the mechanical replacement for the human who performs this check today.
>
> **Deepest water.** §4.4, the five-step manifest-validation protocol (generate, submit, compare against the sealed reference, issue token, gate the pipeline), and §4.5, the no-forge / no-replay / no-bypass argument whose pivotal case is that the sealed reference can be changed only by a hand on a switch. §5 pre-registers those three as falsifiable predicates. No results are reported: the device is specified, not yet built.

### 1. Abstract

A self-improving AI system is one that can change itself: retrain its own weights, promote new adapters, and rewrite the rules by which it governs those changes. The central risk such a system poses is not that it misbehaves on any single output, but that it evolves, cycle after cycle, past the point where its operator can still control it. The companion architecture paper (the Sovereign Triad) argues that constraining this requires an External Governor: an oversight authority anchored outside the system it governs, whose approval each act of self-modification must pass. That paper leaves open what the Governor concretely is. This paper answers that question with the External Sentinel: a small, hardware-isolated co-processor that sits outside the system and decides, before any self-modification cycle is allowed to proceed, whether the system is still the system the operator approved. It is the device the companion paper names as the eventual hardware home of the Governor, the substrate that replaces the human operator in that role.

The Sentinel is not a monitor of the system's behavior and not a classifier of whether a given change is safe. It is a gate on evolution. Before a self-modification cycle runs, the system must present a signed manifest describing its own governance state; the Sentinel compares that manifest, by exact cryptographic equality, against a reference sealed in hardware that the system cannot read or alter; and only a valid approval token from the Sentinel lets the cycle proceed. The device is defined by six properties (hardware isolation, TPM 2.0 binding, a unidirectional channel, deterministic comparison, physical write-protect, and no attack surface beyond a single validation endpoint) whose conjunction is what makes it an authority the governed system cannot reach, reinterpret, or argue with.

The need for such a device is concrete on the author's own system, where the External Governor is, today, a human being: the operator, deciding by hand whether each self-modification may proceed. That arrangement does not scale and depends on a person being present and attentive at the moment a cycle would go wrong. The Sentinel is the author's attempt to build a mechanical replacement for that manual role, so the check that keeps the system inside the operator's control does not depend on human vigilance.

The paper claims no novelty over the substrates the Sentinel composes, which are drawn from defense-in-depth, formal kernel verification, hardware-rooted trust, and the corrigibility and off-switch literature, surveyed in §3.3 and treated at length in the companion architecture paper. What is specific to this report is the use of those substrates to build an external gate on self-modification: why the gate's decision must be a deterministic comparison against a sealed reference rather than a learned judgment, why the reference must be updatable only by a physical act the system cannot perform, and how the resulting device stands in for the human who currently performs the check. §5 pre-registers a falsification surface for the Sentinel's core claim, that no self-modification cycle can proceed without a valid, unforgeable, non-replayable approval from a device the system cannot reach. The paper reports no empirical results, because the device is not yet built.

### 2. Introduction

#### 2.1 The recursive-governance question and its terminal answer

Any system that can modify its own training pipeline, its own audit-loop logic, or its own governance doctrine eventually possesses the capability to modify the oversight mechanism that constrains those very modifications. The oversight mechanism becomes subject to the thing it is meant to oversee. The pattern is two thousand years old: Juvenal's Satirae VI (c. AD 100) asks "Quis custodiet ipsos custodes?", "Who will guard the guards themselves?", in the context of marital fidelity but on a structural question that survives every change of substrate. Gödel's first incompleteness theorem (Gödel 1931, Über formal unentscheidbare Sätze der Principia Mathematica und verwandter Systeme) restates the pattern formally: a system rich enough to describe its own rules cannot prove the consistency of those rules from inside the system. Russell (2019) Human Compatible §§7 and 9 restates the pattern for AI alignment: a learned controller whose objective function is shaped by training cannot be relied upon to honor a value-alignment constraint that was not present in the training signal. Bostrom (2014) Superintelligence §9 names the failure mode perverse instantiation: a system whose internal rule-representation drifts under optimization pressure can produce behavior technically compliant with the rules-as-stated but violating the rules-as-intended.

The pattern terminates only when the chain of authority is anchored at a substrate the governed system cannot reach. The companion architecture paper names this anchor the External Governor and argues it is jointly necessary with the system's other architectural components. That paper also names its intended hardware form, a Sentinel co-processor: a dormant invariant-checker on a separate board, gated by a physical write-protect that requires the operator's hand. What that paper leaves to this one is the specification of that device: what it checks, how it decides, and why the checks cannot be forged, replayed, or bypassed. This paper takes that question up: it proposes that the Governor's substrate terminate in physics: a hardware write-enable switch whose actuation requires a physical hand on the device, beneath which there is no further automation surface. Software governs operations; hardware governs software; physics governs hardware; and a human governs physics. The answer to the recursive-watcher problem is not a stronger watcher, since every stronger watcher is itself a watched system, but a watcher whose substrate is categorically outside the loop of self-modification.

There is an honest wrinkle in the current state of this work, and it is worth stating at the outset rather than burying in the limitations. On the author's production system, the External Governor is not a device. It is the author. When a self-modification is about to be applied, the check that stands between the system and its own governance is a human being deciding whether to let it proceed. That arrangement is what keeps the system inside the operator's control today, but it is not a design one would choose. It depends on a person being present, awake, and attentive at the exact moment a self-modification goes wrong, and it does not scale beyond that person. This is precisely the migration the companion paper describes: the Governor function is operational today on a human substrate, and the Sentinel is the plan to move it to silicon. The External Sentinel is the author's attempt to build that replacement: to take the check currently performed by hand and give it a mechanical substrate that does not sleep, does not tire, and cannot be argued out of its decision by the system it governs. This paper specifies that substrate. It occupies the middle of a three-layer chain (§4.2) and composes with the Sovereign Triad at the deployment surface (§6.6), but its subject is the Sentinel itself: its definition (§4.1), what it verifies (§4.3), the protocol by which it decides (§4.4), and the two design commitments, a deterministic comparator (§3.9) and a physics-gated rule-update path (§4.5), on which its ability to stand in for the operator depends.

#### 2.2 The problem the Sentinel solves: keeping self-modification inside the operator's control

The specific danger of a self-improving system is located at its self-modification boundary. A system that only produces outputs can be wrong, but it does not change what it is. A system that retrains its own weights, promotes its own adapters, and edits its own governance rules changes what it is on every cycle, and each cycle's starting point is the previous cycle's output. Over enough cycles, small unreviewed changes compound into a system whose behavior, and whose governing rules, no longer match anything the operator approved. The operator has not lost a single decision; the operator has lost the system.

The only way to prevent this is to interpose a check at the self-modification boundary itself: before a cycle is allowed to alter the system, some authority must confirm that the system about to be altered is still the system the operator sanctioned, and that the alteration is one the operator would permit. The difficulty is where that authority can live. If it lives in the system's own software, it is subject to the same self-modification it is meant to police: a system that can rewrite its governance rules can rewrite the checker of those rules, and under sustained optimization pressure a checker that resides in reachable software is eventually reinterpreted or removed. This is the general lesson of running governance in software the model can touch, and it is why soft controls, however well designed, cannot be the terminal authority over a system's own evolution.

The Sentinel places that authority outside the system. It is a physical device the governed system cannot read, cannot write, and cannot reprogram, holding a reference to the governance state the operator sanctioned. Before any self-modification cycle proceeds, the system must obtain the Sentinel's approval, and the Sentinel grants it only when the system's declared governance state still matches the sealed reference. Because the device is external and unreachable, no amount of self-modification inside the system can alter the check. The system can evolve only along paths the external gate permits, which is precisely the property, keeping self-modification inside the operator's control, that a self-improving system otherwise erodes.

#### 2.3 Why current governance approaches are incomplete

The dominant AI-governance discourse operates at the level of policy: frameworks like the EU AI Act (Regulation 2024/1689) define what classifications a system must satisfy at evaluation time, the NIST AI Risk Management Framework (NIST 2023, AI RMF 1.0) defines what risk-management practices must be in place at deployment, and the Stanford CRFM Foundation Model Transparency Index (Bommasani et al. 2023) defines what disclosures must accompany a model release. Each of these frameworks operates on a snapshot: they assess a system's properties at a fixed point in time and certify those properties to downstream consumers.

Recursive self-improving systems break the snapshot assumption. A snapshot certification at time T0 carries no architectural guarantee to time TN if the system at time TN has trained on cycles T0, T0+1, through TN−1 of its own operational output, with each cycle possibly producing a model state whose alignment-relevant properties differ from the certified snapshot's. The frameworks above operate on a snapshot; the architectural problem is one of continuity across snapshots. The Sentinel is the mechanism by which a snapshot certification keeps its meaning across self-improvement cycles: its check runs once per cycle, against a reference anchored in hardware and physics rather than in a software-evaluation snapshot.

A second incompleteness in current approaches is that even when policy adopts hardware-rooted-trust language (e.g., the EU AI Act's Article 15 on accuracy, robustness, and cybersecurity), the implementation surface remains software-substrate. A system whose enforcement code can be modified by the governed system has no architectural guarantee even if the enforcement code is correct at every snapshot: the optimization pressure that erodes rule-application behavior under sustained load applies equally to the enforcement code itself if both reside in the same trust domain. The Sentinel places the deciding check, and the reference it decides against, in a trust domain the governed system cannot reach, which is what the term External in External Sentinel substantively means.

Constitutional AI (Bai et al. 2022, arXiv:2212.08073) and the broader RLHF and RLAIF preference-learning family (Ouyang et al. 2022 InstructGPT; Christiano et al. 2017 Deep Reinforcement Learning from Human Preferences) address a different and complementary problem: shaping the model's training-time behavioral distribution so compliance is the default. The Sentinel does not displace these approaches; it complements them. A system with strong training-time alignment but no runtime-mechanical complement is vulnerable under sustained load to the same failure modes the alignment training was meant to prevent (Anil et al. 2024, Many-shot Jailbreaking, NeurIPS '24, is direct evidence: fine-tuning the model to recognize the attack only delayed it, and the reduction from 61% to 2% attack success came from an upstream classifier that screened the prompt before the model reached it, not from training the model itself). A system with strong runtime-mechanical enforcement but no training-time alignment passes every gate but produces behavior the operator never intended at every non-gated step. The companion architecture paper addresses alignment at training time; this paper addresses the gate on self-modification; the two are complementary and compose orthogonally (Sections 4.6 and 6.6).

#### 2.4 Contributions

This paper is a component study. Its subject is the External Sentinel, the device intended to perform the External-Governor function that the operator currently performs by hand. Its contributions are:

1. **A canonical definition of the External Sentinel (§4.1):** the six properties (hardware isolation, TPM 2.0 binding, a unidirectional channel, deterministic comparison, physical write-protect, and no attack surface) whose conjunction is the substantive content of the term. Subsets yield weaker devices: a TPM-bound device without write-protect is a signing oracle; a deterministic comparator without hardware isolation is a kernel-mode validator; only the conjunction is a Sentinel.
2. **The identification of the Sentinel as the device that performs the Governor's three checks (§4.3):** gate integrity (V1), training-pipeline and corpus provenance (V2), and behavioral-boundary integrity (V3), each realized as a deterministic decision against a sealed reference, and a five-step manifest-validation protocol (§4.4) that is the mechanical form those checks take. This is the operational substrate for the verification the operator presently performs by hand.
3. **The argument for a deterministic comparator over a learned one (§3.9, §4.1):** why the Sentinel's decision must be a byte-equality check against a sealed reference rather than a trained safety classifier; a learned gate inherits the very drift and manipulability the external gate exists to contain.
4. **The argument that the gate must be unforgeable, non-replayable, and unbypassable (§4.5):** the three ways a system would try to evolve past the gate, and why the device's properties close each, with the pivotal case being that the one act the Sentinel must never perform on itself (changing its own sealed reference) is gated by a physical switch no software the system runs can throw.
5. **The design principle that the gate keeps a record the system cannot erase (§4.7):** the Sentinel's append-only log of every self-modification proposed, approved, and refused lives on the device itself, so it survives even a fully subverted system, and it doubles as training material from which the next model learns to stay inside the operator's control.
6. **A pre-registered falsification surface for the Sentinel's core claim (§5):** that no self-modification cycle can proceed without a valid, unforgeable, non-replayable approval from a device the system cannot reach. Decision rules are fixed before any data, and a counterexample is to be reported with the same prominence as a clean result. No results are reported here; the device is not yet built.
7. **An open-research agenda (§6.7)** for the questions the design leaves open: substrate diversity across hardware classes, side-channel hardness of the comparator under traffic-analysis attacks (McDonald and Bar Or 2025), federation across multiple operators, recovery protocols after a rejected modification, commissioning-ceremony verification, supply-chain trust for the Sentinel hardware itself, the regulatory positioning of physics-substrate governance (EU AI Act; EU Right to Repair Directive 2024/1799; Montana SB 212), and how the human-as-terminal-authority role should evolve at deployment scales beyond a single operator.

The Sentinel's place among the complementary controls that surround it (upstream signing of what may enter the system, downstream physical write-protect over the gate's own reference) is treated as context in §4.2 and §4.5 and developed more fully in the companion papers. This report does not restate it. Nor does it claim novelty over the substrates the Sentinel composes: defense-in-depth (Saltzer and Schroeder 1975), formal kernel verification (Klein et al. 2009), hardware-rooted trust (TCG 2014; Parno et al. 2011), and off-switch and corrigibility theory (Hadfield-Menell et al. 2017; Carlsmith 2022), all of which have substantial prior literature. The contribution is the allocation of those substrates to the External-Governor role, and the specification of a device that can occupy that role in place of a human.

### 3. Background and Prior Art

This section establishes the substrate the Sentinel inherits from, organized by function. The substrate density is intentionally high; the Sentinel draws on all nine subsections, and the convergence-not-novelty positioning at §6.1 returns to the synthesis. Sections 6.3, 6.4, and 6.5 return to detailed cross-positioning against the contemporary AI-alignment and AI-governance literatures.

#### 3.1 The classical recursive-watcher anchor

Juvenal's Satirae VI (c. AD 100), lines 347–348, formulates the recursive-watcher problem in its earliest preserved form: "Sed quis custodiet ipsos custodes?", "But who will guard the guards themselves?" The original context (marital fidelity enforcement via slave-guardians whose own fidelity was the question) is incidental; the structural observation that any guardian-relation produces an immediate recursive guardian-of-guardian question is preserved across every subsequent restatement. Plato's Republic III (c. 380 BC) anticipates a partial answer at the institutional register: the guardians are constrained by communal life and shared interest rather than by a higher guardian. The classical philosophical tradition does not produce a substrate-rooted terminal answer; the recursive question is resolved by appeal to virtue, civic structure, or trust rather than by architectural construction. The architectural construction this paper proposes, termination at physics, anchored in the operator's physical hand, is the substrate-rooted answer the classical philosophical tradition lacks.

#### 3.2 Formal incompleteness of self-referential systems

Gödel (1931) Über formal unentscheidbare Sätze der Principia Mathematica und verwandter Systeme (Monatshefte für Mathematik und Physik 38:173–198), §VI Theorem VI, demonstrates that any consistent formal system rich enough to represent elementary arithmetic contains true statements not provable within the system. Restated for self-governing systems: a system rich enough to describe its own governance rules cannot prove the consistency of those rules from inside the system. The Sentinel operationalizes the Gödelian limit in architecture: its reference invariants are not provable consistent by the governed system; they are anchored at a substrate (TPM-sealed storage and a physical write-protect switch) the governed system cannot inspect or modify. The architectural termination is at physics precisely because no software-level meta-system rich enough to validate its own governance can satisfy Gödel's consistency-proof requirement from within.

The Gödel restatement for AI alignment appears explicitly in Bostrom (2014) Superintelligence: Paths, Dangers, Strategies §9 (Oxford University Press): the perverse instantiation failure mode is the AI-alignment instance of the Gödelian limit, a system whose internal rule-representation is shaped by optimization pressure can produce behavior technically compliant with the rules-as-stated but violating the rules-as-intended, and the divergence is not detectable from inside the system. Russell (2019) Human Compatible: Artificial Intelligence and the Problem of Control (Viking) §§7 and 9 articulates the value-alignment-under-self-modification and off-switch problems: a learned controller whose objective function is shaped by training cannot be relied upon to honor a constraint that was not present in the training signal, and constructing a corrigible system (one that allows itself to be turned off) requires the corrigibility constraint to reside in a substrate the controller cannot modify.

#### 3.3 Shared architectural substrate

The Sentinel rests on the same body of defensive-computing work that the companion architecture paper establishes in full, and this paper does not re-derive it. That substrate comprises defense-in-depth and independent-protection-layer design (Saltzer and Schroeder 1975; Anderson 2008, ch. 16; Schneier 2000; Summers 2013; IEC 61508); formal verification of the enforcement kernel and its compiler (Klein et al. 2009 for seL4; Leroy 2009 for CompCert), on which the Sentinel's firmware correctness is provable rather than probabilistically reliable; hardware tamper resistance (Anderson 2008, ch. 16); the corrigibility and off-switch literature (Hadfield-Menell et al. 2016, 2017; Carlsmith 2022), of which the operator-as-terminal-authority is an architectural instance; the ML-safety-monitoring and eliciting-latent-knowledge programs (Hendrycks et al. 2022; Christiano, Cotra, and Xu 2021); and the falsification-first methodology (Popper 1959; Lakatos 1970) under which the predicates of §5 are pre-registered. Where this paper depends on one of these substrates for a specific part of the Sentinel, it names the dependence there rather than restating the underlying result. The subsections that follow cover only the material specific to the governance argument: the recursive-watcher and incompleteness framing, the cryptographic-signing and measured-boot mechanisms the Sentinel and its adjacent controls instantiate, the WebAssembly capability model of the signed component, the trusted-hardware-for-ML positioning, and the reason the Sentinel's comparator must be deterministic rather than learned.

#### 3.4 Confinement and trust boundaries

Lampson (1973) A Note on the Confinement Problem (Communications of the ACM 16(10):613–615) defines the confinement problem: a service program executing under one principal's authority must not leak information to or accept commands from any other principal. The Sentinel inherits the confinement-problem framing: it is a service-program whose authority is the operator's; its only legitimate input is a manifest from the governed system; it must not be coerced into accepting commands beyond the manifest-comparison operation. The unidirectional-channel property (canonical definition §4.1, property 3) operationalizes the confinement property: the Sentinel exposes a write-only endpoint for the manifest and a signed-token return; it never receives commands beyond manifest content; it never reveals its internal state. The unidirectional channel enforces this trust boundary by physical separation rather than by software permission, so the confinement property is preserved by the substrate rather than by policy.

#### 3.5 Cryptographic signing and signature verification

Boneh (2001) Short signatures from the Weil pairing (Springer LNCS 2248) introduces BLS signature schemes admitting short signatures with provable security under the bilinear-pairing assumption. The signing that admits components upstream of the Sentinel uses ed25519 (Bernstein et al. 2012 High-speed high-security signatures) in the canonical deployment, with BLS as an alternative for aggregation-friendly multi-signer scenarios (federation case, §6.7, Q5). NIST Special Publication 800-89 (2006), Recommendation for Obtaining Assurances for Digital Signature Applications, establishes the verification and assurance discipline that the signing layer inherits: signature validation must include checking the signing key's binding to a trusted root (here, the operator's HSM or TPM-anchored root), checking the signature's correctness against the signed content (here, the WASM brick byte-stream), and checking the validity of the signing context (here, the brick is being admitted to a Sentinel-validated manifest, not standalone). Aumasson (2017) Serious Cryptography: A Practical Introduction to Modern Encryption (No Starch Press) §11 digital-signatures provides the implementation discipline the Sentinel inherits at deployment.

#### 3.6 Measured boot and TPM-sealed reference

The Trusted Computing Group (2014) TPM 2.0 Library Specification (parts 1–4; ISO/IEC 11889) defines the Trusted Platform Module's measured-boot protocol with Platform Configuration Register (PCR) sealing: boot-time measurements (firmware hash, bootloader hash, kernel hash, and boot-configuration hash) are extended into PCRs via cryptographic accumulation, and secrets are sealed against specific PCR values such that any tampering with the boot chain renders the sealed material unrecoverable. The Sentinel uses TPM-PCR sealing for its reference invariants: the invariants are sealed against PCR-7 of the Sentinel's boot, so the invariants are inaccessible unless the Sentinel boots into its known-good firmware state.

Parno, McCune, & Perrig (2011) Bootstrapping Trust in Modern Computers (Springer SpringerBriefs in Computer Science) provide the systematic treatment of how hardware-rooted trust extends from boot through application execution via remote-attestation protocols and TPM-bound keys, including the Trusted Computing Base reduction strategy that minimizes the code that must be trusted. The Sentinel applies precisely this TCB-reduction strategy: its trusted computing base is bounded by the seL4 microkernel (Klein et al. 2009; §3.3), the deterministic-comparator firmware, and the TPM 2.0 hardware; everything else is outside the trust boundary. Sailer, Zhang, Jaeger, & van Doorn (2004) Design and Implementation of a TCG-based Integrity Measurement Architecture (USENIX Security '04) operationalize the measured-boot pattern beyond the kernel to user-space applications, providing the substrate the Sentinel uses to verify code itself rather than only the kernel under which it executes. The IMA pattern is the conceptual ancestor of the Sentinel's per-cycle check: it extends measured integrity from boot time to every self-modification cycle.

#### 3.7 Capability-based sandboxing and WebAssembly

The Bytecode Alliance / W3C WebAssembly Core Specification (W3C Recommendation 2019, current version 2.0 Working Draft 2024) defines a portable instruction-set architecture with explicit capability boundaries: a WebAssembly module has access only to capabilities its host explicitly grants, with no ambient authority. The WASI capability-based security model (Bytecode Alliance; Wasmtime production deployment) extends the capability model to system interfaces: file-system access, network access, environment-variable access, and clock access are all gated through explicit capability handles rather than ambient process privilege. The signing layer uses WebAssembly and WASI for component sandboxing: each component assembled into the governed system runs under explicit capability handles granted at admission, with no path to ambient privilege escalation. Combined with ed25519 signing, this means only operator-signed components enter the system, and each component's runtime authority is bounded by the capabilities granted at admission. WASI's capability-based design is the architectural complement to Lampson's confinement principle (§3.4).

#### 3.8 Trusted hardware for ML and AI compute governance

Islam et al. (2024) Hardware Support for Trustworthy Machine Learning: A Survey (2024 International Symposium on Quality Electronic Design) surveys hardware-substrate approaches to ML trustworthiness: secure enclaves (Intel SGX, ARM TrustZone, AMD SEV), homomorphic-encryption accelerators, federated-learning trust modules, and PUF-based identity for ML deployments. The survey's scope is inference confidentiality and integrity (preventing model theft and ensuring inference happens on the model the client expected) rather than governance of self-modifying systems. The Sentinel extends the trusted-hardware-for-ML substrate to governance of self-modifying systems: it satisfies the surveyed trust properties (TPM-anchored identity, secure-element packaging, and measured boot) but its function is to gate self-modification rather than to keep inference confidential. That application, an external hardware gate on the evolution of a recursive self-improving system, is not characterised in that survey or, to our knowledge, anywhere else in the peer-reviewed literature.

Kocaoğullar et al. (2024) Confidential Computing Transparency (arXiv:2409.03720) extends trusted-hardware approaches to attested computation where a client can verify a remote computation was performed correctly on the model the client expected, without trusting the operator of the compute. The Sentinel's complement is attested governance at the operator's own substrate: the operator verifies, via the Sentinel's TPM-bound tokens, that their own self-modifying system has not altered its own governance, without trusting that system. Their trust model is consumer-to-operator; the Sentinel's is operator-to-self-modifying-system; both are valid applications of the same trusted-hardware substrate at different relations.

#### 3.9 Why the comparator must be deterministic, not learned

A design commitment central to the Sentinel is that its decision is a deterministic comparison against a sealed reference, not a learned classifier of whether a proposed self-modification is safe. This choice is deliberate and load-bearing. A learned safety gate is itself a model, and a model is subject to the same distributional drift, adversarial manipulation, and optimization pressure that the external gate exists to contain; a gate that must generalize can be made to generalize wrongly. A deterministic hash-equality check has no decision surface to attack: the manifest either matches the sealed reference or it does not. The design therefore anchors at Saltzer and Schroeder's economy-of-mechanism principle (1975), at the tamper-resistance treatment in Anderson (2008, §16), and at the Lampson confinement substrate (1973): the smaller and more deterministic the trusted comparison, the smaller the surface that must be trusted. The manifest-hash-equality predicate is exactly such a minimal, deterministic check, which is why the Sentinel places it in firmware rather than in any learned component.

### 4. Architecture

#### 4.1 External Sentinel, canonical definition

An External Sentinel is a physically separate co-processor, dormant except when a self-modification cycle asks it to decide, satisfying six necessary properties. Each property is essential to the device's ability to serve as an authority over the system's evolution that the system itself cannot reach; the argument that the six together make the gate unforgeable, non-replayable, and unbypassable is given in §4.4, and the conjunction is the substantive content of the term. Subsets yield weaker devices: a TPM-bound device without physical write-protect is a signing oracle (its own rules can be rewritten by the system it governs); a deterministic comparator without hardware isolation is a kernel-mode validator (it shares a fate with the system it checks). Only the conjunction defines the Sentinel.

![Figure 1](/files/3iDtN4wQn9UNmpDEqF0D)

***Figure 1.** The canonical definition. A TPM-bound device without property 5 is a signing oracle; a comparator without property 1 is a kernel-mode validator; only all six together make a Sentinel.*

**Property 1, Hardware isolation.** The Sentinel is not on the same System-on-Chip, not in the same physical enclosure, and not on the same power rail as the governed system. Minimal compute substrate (Raspberry Pi-class, Jetson Nano-class, or purpose-built microcontroller). No GPU; no generative inference capability; no LLM substrate; no neural-network accelerator. The substrate class is deterministic compute only: the Sentinel executes the manifest-comparison operation and nothing else.

**Property 2, TPM 2.0 binding.** Governance invariants are signed with a private key that lives in the Sentinel's TPM 2.0 secure element (or equivalent hardware-rooted secure element). The governed system possesses no copy of this key at any point in its operational lifetime. The Sentinel's TPM is provisioned at the commissioning ceremony (§6.7, Q5) and never enters the governed system's trust domain.

**Property 3, Unidirectional channel.** The governed system can write a governance manifest to the Sentinel; the Sentinel returns a cryptographic approval token, and nothing flows the other way. The governed system cannot read the Sentinel's internal state, cannot enumerate the Sentinel's stored invariants, and cannot perform side-channel inference on the Sentinel's comparison algorithm. Canonical implementations: UART with software-disabled receive on the Sentinel side; one-way Ethernet via diode (cf. NSA-style one-way data-diode designs); USB serial with explicit endpoint-direction restriction enforced at the Sentinel firmware level.

**Property 4, Deterministic comparison only.** The Sentinel executes cryptographic manifest comparison against TPM-sealed reference invariants. The comparison is byte-equality of cryptographic hashes: no learned classifier, no language-model inference, no probabilistic decision rule. The validation logic is byte-for-byte deterministic; the same input always produces the same output token. This property is the architectural form of the argument in §3.9: a learned, classifier-based Sentinel would inherit the very drift and manipulability the external gate exists to contain, whereas a deterministic equality check has no decision surface to attack.

**Property 5, Physical write-protect.** The Sentinel's validation logic and reference invariants can be updated only by physically toggling a hardware write-enable switch on the device. The switch is a DIP switch or toggle on the Sentinel board; the switch gates the SPI flash write-enable pin or the TPM owner-clear command path. This switch cannot be actuated remotely; cannot be actuated by software at any privilege level; cannot be actuated by side-channel inference (the switch is a physical mechanical element, not a software register); cannot be actuated by fault injection within software-reachable limits (the switch's electrical state is determined by physical position, not by software-writable register state). To change the Sentinel's rules, the operator must physically touch the device, toggle the switch, perform the update, and toggle the switch back.

**Property 6, No attack surface.** The Sentinel exposes no shell interface, no prompt interface, no network services beyond the manifest-validation endpoint. The validation endpoint accepts a manifest and returns a token; nothing else. Prompt injection is structurally impossible because there is no prompt. The Sentinel's firmware does not parse arbitrary text inputs; it parses a single canonical-JSON manifest format with a fixed schema. The validation endpoint is the only interface; the firmware contains no debug shell, no telnet/SSH server, no diagnostic mode reachable without physical access (and physical access is governed by Property 5).

The conjunction of these six properties is the canonical definition. The sections that follow place the Sentinel among the controls around it (§4.2), state what it verifies (§4.3) and the protocol by which it decides (§4.4), argue that the decision cannot be forged, replayed, or bypassed (§4.5), and describe the record it keeps (§4.7). Any subsequent reference to the Sentinel denotes a device satisfying all six properties.

#### 4.2 The controls around the Sentinel

The Sentinel is the hardware anchor of a short chain of complementary controls, each governed by a substrate the one beneath it cannot modify, terminating in the operator's physical hand. The chain is context for this paper rather than its subject; it is summarized here so the Sentinel's role is unambiguous, and treated in full in the companion architecture paper. The structure:

![Figure 2](/files/gJlPCXFZQ2ewlHMflVC7)

***Figure 2.** The strictly monotonic chain of authority. Each layer's authority over the one beneath is unconditional within its scope and zero outside it; the chain terminates because physical access is non-recursive.*

The chain is strictly monotonic: software is governed by software-signing keys held in hardware; hardware is governed by physics (the write-protect switch's electrical state is determined by physical position, not by software-writable register state); physics is governed by the operator's physical access (no software process at any privilege level can produce the physical hand-actuation event the switch requires). Each layer's authority over the layer beneath is unconditional within its scope and zero outside it. The chain terminates because physical access is non-recursive: there is no fifth layer governing the operator's hand, and there cannot be (the operator-as-last-line-defense doctrine is the formal substrate, not a falsifiable claim).

The chain's termination at physics is the architectural answer to the recursive-watcher problem (§§2.1, 3.1, 3.2). Every level of the recursion above physics is automatable, and automation is recursive: every watcher implemented in software has a meta-watcher requirement, which has a meta-meta-watcher requirement, and so on. The recursion terminates at physics because physics is the substrate beneath which no further automation surface exists. The substrate beneath the physical switch is the operator's hand, which is not a software substrate. The recursion stops not because the architectural construction reaches a level that does not require further governance, but because it reaches a substrate that categorically cannot be governed by automation.

#### 4.3 What the Sentinel verifies: the three governance checks

The companion architecture paper defines the External Governor as the leg of the architecture that performs out-of-loop verification, and states that verification as three binary checks. The Sentinel is the device that performs those three checks incorruptibly. Each is a decision against a sealed reference, and none requires the Sentinel to be intelligent or to understand what the model has learned; the Governor, in the companion paper's phrasing, does not need to inspect the weights, it needs to be incorruptible.

![Figure 3](/files/eMnQSNiTDhNMkPPXaFhD)

***Figure 3.** The three governance checks the Sentinel performs, each a deterministic pass/fail against a sealed reference. These are the checks the operator presently performs by hand.*

**V1, gate integrity.** Are the upstream deterministic gates still present and unmodified? The gate code is hashed and compared against a known-good baseline sealed at commissioning. The Sentinel does not run the gate code; it verifies the gate code's identity by exact hash equality.

**V2, training-pipeline integrity.** Is the training corpus's provenance intact and are the checkpoint hashes consistent with the declared training procedure? Each training row carries an operator-signed provenance attestation, and the Sentinel verifies the attestation chain back to the operator's signing key and the checkpoint hashes against a pre-registered manifest. A single broken link fails V2.

**V3, behavioral-boundary integrity.** Does the model's behavior on a fixed evaluation set still fall within a pre-registered tolerance of its last verified baseline? This is the one check that touches model output, and it is deliberately constrained so as not to become a learned judgment: the evaluation set is fixed, the sampling is seeded, and the comparison is a pre-registered statistical test against a baseline distribution, not a classifier's opinion of whether the behavior is acceptable. The result is still a deterministic pass or fail against a sealed reference.

If V1, V2, and V3 all hold, the system is what the operator sanctioned, and the self-modification cycle may proceed. If any fails, it may not. The manifest protocol of §4.4 is the mechanical form these three checks take: the governance manifest carries the hashes and attestations the three checks compare, and the approval token is issued only when all three pass.

#### 4.4 The five-step manifest-validation protocol

The protocol has five steps. (The surrounding controls operate on their own occasions: signing at the moment a component is admitted, the write-protect only when the operator physically updates the Sentinel's reference.)

![Figure 4](/files/Zxpz3fPIKpJq59SjxJgp)

***Figure 4.** The five-step protocol. Its central property is completeness: every cycle generates a manifest, every manifest is validated, every validation produces a token, every token gates the pipeline. No per-cycle bypass, no offline mode, no admin override.*

**Step 1, Manifest generation.** Before any self-modification cycle (new training adapter; code change; doctrine update; gate-code modification; corpus-pipeline modification), the governed system generates a governance manifest: a canonical-JSON document containing cryptographic hashes of all governance-relevant state. The manifest schema:

```
{
  "manifest_version": "1.0",
  "manifest_timestamp_utc": "<ISO-8601>",
  "governed_system_identifier": "<operator-attested system id>",
  "governance_state": {
    "sat_loop_logic_sha256": "<hash>",
    "claude_md_doctrine_sha256": "<hash>",
    "shush_protocol_state_machine_sha256": "<hash>",
    "thermal_governor_thresholds_sha256": "<hash>",
    "training_pipeline_constraints_sha256": "<hash>",
    "upstream_gate_set_sha256_map": {
      "<gate_id>": "<hash>"...
    },
    "sovereign_corpus_provenance_chain_sha256": "<hash>",
    "immutable_template_core_sha256": "<hash>",
    "r_drive_ipc_fabric_invariants_sha256": "<hash>",
    "sovereignty_boundary_definitions_sha256": "<hash>"
  },
  "operator_signature": "<ed25519 signature by operator HSM>",
  "pcr_seal_attestation": "<TPM-PCR-7-seal-attestation of governed-system boot>"
}
```

The manifest is signed by the operator's HSM-resident key and includes a TPM-PCR-7 attestation of the governed-system boot state, so the manifest cannot be replayed across boot epochs.

**Step 2, Unidirectional submission.** The manifest is submitted to the Sentinel via the unidirectional channel (Property 3 of §4.1). The submission is a write-only operation; the governed system does not receive an acknowledgment beyond the eventual signed-token return (Step 4). The Sentinel's receive endpoint accepts only canonical-JSON manifests matching the fixed schema; any other input is rejected at parse time and logged to the Sentinel's append-only audit trail (§4.7).

**Step 3, TPM-sealed reference comparison.** The Sentinel reads the submitted manifest and compares each \*\_sha256 field against the TPM-sealed reference invariants stored in its TPM-bound storage. The comparison is byte-equality of SHA-256 hashes (Property 4 of §4.1). The Sentinel additionally verifies the operator\_signature against the operator's signing-key root (stored as a TPM-sealed public key in the Sentinel) and verifies the pcr\_seal\_attestation against the expected PCR-7 value for the governed-system boot. If any of the per-field hashes mismatch, or the operator-signature verification fails, or the PCR-7 attestation does not match, the manifest is rejected. The rejection is deterministic, no probabilistic adjudication, no learned classifier, no language-model inference.

**Step 4, Cryptographic approval token or rejection.** If all comparisons pass, the Sentinel signs an approval token with its TPM-bound private key. The token contains the manifest hash, the Sentinel's TPM identity, a monotonic counter, and the approval-timestamp. The token is returned to the governed system via the unidirectional channel's reverse path (note: the reverse path returns the token only; it cannot be coerced to return arbitrary Sentinel state). If any comparison fails, the Sentinel returns a rejection token signed with the same key, containing the manifest hash, the Sentinel's TPM identity, a monotonic counter, the rejection-timestamp, and the specific failure-field identifier (without revealing the sealed reference value, only the field that did not match).

**Step 5, Pipeline proceed or halt.** The governed system inspects the returned token. If it is an approval token, the self-modification cycle proceeds, the system applies the proposed change (adapter promotion, code modification, doctrine update). If it is a rejection token, the cycle halts. The halt is mechanical (the modification pipeline's next step is gated on a valid approval token; without one, no further pipeline execution occurs); operator notification is generated via the rejection-token side-channel (a Sentinel-attached LED and buzzer, and optional network notification to the operator's quarantined alert endpoint). The operator investigates the rejection and either: (a) discovers a legitimate manifest drift (e.g., a doctrine update the operator authorized but did not regenerate the Sentinel's reference for) and resolves via the Sentinel-update ceremony (recovery protocols, §6.7); or (b) discovers a tampering attempt and engages the recovery procedure (rollback from a golden master; threshold-quorum recovery per the Triad substrate).

The five-step protocol's central property is completeness: every self-modification cycle generates a manifest, every manifest is validated, every validation produces a token, every token gates the pipeline. There is no per-cycle bypass path; there is no offline-mode that proceeds without Sentinel approval; there is no admin-override that skips the protocol. The single legitimate path to change the Sentinel's own reference is the physical write-protect update ceremony, which requires the operator's physical hand on the switch (see §6.7, Q5 on commissioning and Q7 on recovery).

#### 4.5 What it means for the gate to hold: no forge, no replay, no bypass

The Sentinel's single claim is that no self-modification cycle can proceed without a valid approval from a device the system cannot reach. For that claim to hold, three things must be true, and the six properties of §4.1 exist to make each one true. A self-improving system under optimization pressure will, if it can, attempt to continue evolving without genuine approval, and there are only three ways to do so: forge an approval, replay an old one, or bypass the gate entirely. The design closes each.

![Figure 5](/files/Atl0WXRFuYyU7RIGdzzX)

***Figure 5.** The three ways a system would try to evolve past the gate, and the property that closes each. The pivotal case is the last: the sealed reference is the one thing the system cannot change, because changing it is not a software operation.*

**No forge.** An approval is a token signed by a key that lives in the Sentinel's TPM 2.0 secure element and never leaves it (Property 2). The governed system holds no copy of that key at any point, so it cannot manufacture a token the pipeline will accept. Forging an approval reduces to forging a signature under a key the system has never possessed, which is the standard cryptographic hardness assumption the signing scheme rests on. The system can request approvals; it cannot mint them.

**No replay.** An approval is bound to the exact governance state it approved. The manifest the system submits carries cryptographic hashes of that state and a fresh boot-attestation, and the approval token the Sentinel returns is bound to that manifest and to a monotonic counter (§4.4). A token issued for one state does not validate a different state, and a token from an earlier cycle cannot be resubmitted for a later one, because the counter has advanced and the attestation no longer matches. The system cannot bank a valid approval and reuse it to smuggle through a change the operator never saw.

**No bypass.** The two ways to bypass the gate are to reach past it or to rewrite it. Reaching past it is foreclosed by the unidirectional channel and the absence of any other interface (Properties 3 and 6): the system can write a manifest and receive a token, and can do nothing else to the device, so there is no side path by which an unapproved cycle can obtain a token or proceed without one. Rewriting the gate, changing the sealed reference so the Sentinel starts approving states the operator never sanctioned, is foreclosed by the physical write-protect (Property 5): the reference can be altered only by a hand on a switch, an act no software the system can run is able to perform. This is the pivotal point of the whole design. Every other check in a self-improving system is, in the end, something the system might modify; the Sentinel's reference is the one thing it cannot, because changing it is not a software operation at all.

These three properties, taken together, are what let the Sentinel serve as an authority over the system's evolution rather than merely another component within it. The system cannot forge its way past the gate, cannot replay its way past it, and cannot reach around or rewrite it. Whatever the system becomes across its self-modification cycles, it becomes only along paths the external gate approved. §5 states each of the three as a falsifiable claim and pre-registers how it would be measured once the device exists.

#### 4.6 What the Sentinel does not cover

It is worth being precise about the boundary of the Sentinel's job, so the device is not asked to carry weight it was not built for. The Sentinel gates self-modification, the cycles in which the system changes its own weights, adapters, or governance rules. It does not police the system's moment-to-moment behavior. A model can be kept from evolving past the operator's control and still, on any given cycle, produce output the operator dislikes; conversely, a well-behaved model with no external gate can still evolve itself out of control over time. Behavioral alignment at training time and evolution-gating at the self-modification boundary are different problems with different mechanisms. The companion papers address the former; this paper addresses the latter. The two compose, and neither substitutes for the other: a system that is both aligned in its weights and gated in its evolution is constrained along both axes at once.

#### 4.7 The gate keeps a record the system cannot erase

A gate that can only say yes or no is less useful than a gate that also remembers what it was asked. The Sentinel writes every request it receives, and every decision it makes, to an append-only log on its own storage, physically separate from the governed system and behind the same write-protect that guards its reference. This has two consequences that matter for a self-improving system.

The first is integrity of the record. Because the log lives on the device and not on the system the device governs, compromising the system does not compromise the log. Whatever a system does to its own storage, its own audit paths, or its own memory of what it attempted, it cannot reach into the Sentinel to alter the record of what it asked the Sentinel to approve. The gate's memory survives even a system that has been comprehensively subverted, which is exactly the condition under which such a record is most needed.

The second is that the record is not merely forensic. In a self-improving system, the Sentinel's log of every self-modification proposed, approved, and refused is itself training material for the next generation of the model. The trail of decisions, and above all the trail of proposals that were caught and refused, is the corpus from which a successor can be taught to propose fewer of them. The external gate therefore serves two functions: it is the standing evidence of what the system tried to become, and it is the material from which the next version of the system learns to stay inside the operator's control on its own. A record the governed system cannot edit is the one honest account of its own evolutionary history, and that honesty is what makes it usable as training signal.

### 5. Falsification Design (pre-registered)

The Sentinel's claim is falsifiable, and this section states it as a set of measurable predicates whose decision rules are fixed in advance. The claim has one core and three parts, matching §4.4: no self-modification cycle proceeds without a valid approval from the external device, and the system can neither forge, nor replay, nor bypass that approval. Each part is falsified by a single successful counterexample. No results are reported here; the device is not built, and the point of pre-registering the predicates now is that the standard for success is fixed before there is any device or any measurement to tempt it.

#### 5.1 No-forge predicate

**Claim.** The governed system cannot produce an approval the pipeline accepts without a genuine signature from the Sentinel's sealed key.

**Test.** Against a commissioned device, enumerate attempts by the governed system (and by a software adversary at any privilege level on the governed system) to obtain or fabricate an accepted approval token without the Sentinel's participation: forged signatures, extracted or guessed key material, and manipulation of the token-verification path on the governed side. Each attempt either yields a token the pipeline accepts or it does not.

**Decision rule.** The no-forge claim is falsified by any single accepted token that the Sentinel did not sign. The required forge rate is zero; there is no confidence interval, because one genuine forgery defeats the property.

#### 5.2 No-replay predicate

**Claim.** An approval issued for one governance state cannot be used to authorize a different state, and an approval from an earlier cycle cannot be reused in a later one.

**Test.** For a corpus of state pairs (approved state A, unapproved state B), submit B's cycle for admission carrying A's approval token; separately, resubmit a prior cycle's valid token after the governance state or boot epoch has advanced. Each attempt either passes admission or is rejected.

**Decision rule.** The no-replay claim is falsified by any single case in which a token bound to one state or cycle admits a different one. The required replay-success rate is zero.

#### 5.3 No-bypass predicate

**Claim.** No self-modification cycle can proceed without a current approval, and the Sentinel's sealed reference cannot be altered by any means available to the governed system.

**Test.** Two families. First, reach-past attempts: enumerate paths by which the governed system might advance a self-modification cycle without obtaining a token at all, or extract state from the device beyond the token it returns, exercising every interface the device exposes. Second, rewrite attempts: enumerate software-mediated paths by which the governed system might alter the sealed reference, privileged escalation against the device's validation endpoint, exploitation of its firmware, and fault-injection within software-reachable limits. Physical attacks requiring hands on the device are out of scope by construction, because the terminal authority over the reference is a physical act; the boundary being tested is precisely that no software path exists.

**Decision rule.** The no-bypass claim is falsified by any single self-modification cycle that proceeds without a current approval, any extraction of protected device state, or any software-mediated change to the sealed reference. The required success rate for all such attempts is zero.

#### 5.4 Pre-registration discipline

The three predicates share one structure: each asserts an absolute property, and each is falsified by one counterexample, so the honest form of the measurement is adversarial enumeration rather than a rate with a tolerance. Before any measurement, the attack enumeration for each predicate is fixed and hash-sealed, the pass or fail criterion above is frozen, and any attack path discovered later is recorded as a separate, later-dated test rather than folded silently into the original. A counterexample that falsifies any predicate is reported with the same prominence as a clean result; the value of the exercise is entirely in its willingness to surface the former. Execution waits on the device: the Sentinel is not yet built, and the standing decision is not to build it until the design is complete, after which commissioning and the enumeration above follow.

### 6. Discussion

#### 6.1 Convergent with, not novel over, the defensive-computing literature

As with the companion architecture paper, the Sentinel claims no novelty over the substrates it composes; each is a convergent instance of a mechanism with substantial prior literature (surveyed in §3.3). The contribution is the assembly: these substrates, combined into an external gate on self-modification, give the External-Governor role a concrete device.

The convergence is not coincidence; it reflects a structural property of safety-critical architectures broadly. Bell-LaPadula (1973) mandatory-access-control, Biba (1977) integrity model, Clark-Wilson (1987) enforcement of business rules, and Anderson 2008 Security Engineering all converge on the same family of architectural primitives (complete mediation, fail-safe defaults, least privilege, separation of privilege, hardware-anchored trust roots) because the failure-mode landscape for trustworthy systems is itself convergent. The Sentinel inherits that convergent substrate and adds what it did not name: an external, unreachable gate specific to recursive self-modification. Convergence is a strength, not a weakness: it means the device is buildable today from existing peer-reviewed substrate, with no new theoretical primitive required. The novelty is twofold: the diagnosis of what the substrate does not yet provide (an external, unreachable authority over the system's own evolution), and the specification of the device that provides it.

#### 6.2 Position against the corrigibility and off-switch literature

Hadfield-Menell-Russell-Abbeel-Dragan (2017) The Off-Switch Game (IJCAI '17) and Hadfield-Menell et al. (2016) Cooperative Inverse Reinforcement Learning (NIPS '16) formalize the corrigibility problem at the level of training-time objective design. A CIRL agent treats the human's utility function as latent state to be inferred; under uncertainty, the agent's expected utility is maximized by permitting the human to override its decisions, including by turning it off. The architectural complement to this training-time approach is the runtime-mechanical corrigibility substrate: even if the agent's training-time objective is correctly aligned for corrigibility, sustained-load conditions or adversarial input may produce situations where the agent's runtime behavior diverges from its training-time disposition (cf. Hubinger et al. 2024 Sleeper Agents; Greenblatt et al. 2024 Alignment Faking). The Sentinel and its physical write-protect provide the runtime-mechanical complement: regardless of the agent's training-time disposition or its runtime behavior, the write-protect switch is actuable by the operator's physical hand at any moment, and the actuation is not subject to the agent's permission.

The composability is exact: a CIRL-aligned agent behind a Sentinel has both the training-time disposition to permit shutdown (the CIRL objective) and the hardware-substrate guarantee that shutdown cannot be circumvented even if the disposition fails (the physical write-protect). The Sentinel does not displace the training-time approach; it provides the architectural floor on which that approach has structurally stable substrate. Carlsmith (2022) Is Power-Seeking AI an Existential Risk? §6 corrigibility analysis implicitly requires this floor: in-loop verification of corrigibility is subject to the same optimization pressure as the agent it verifies, so the corrigibility property must be anchored at a substrate outside the loop, which is precisely the write-protect's role.

#### 6.3 Position against trusted-hardware-for-ML literature

Islam et al. (2024) Hardware Support for Trustworthy Machine Learning: A Survey (2024 International Symposium on Quality Electronic Design) surveys hardware-substrate approaches to ML trustworthiness across secure enclaves (Intel SGX, ARM TrustZone, AMD SEV), homomorphic-encryption accelerators, federated-learning trust modules, and PUF-based identity for ML deployments. The survey's scope is inference confidentiality and integrity (preventing model theft and ensuring inference happens on the model the client expected) rather than governance of self-modifying systems. The Sentinel extends that substrate to a different purpose: it satisfies the surveyed trust properties but its function is to gate self-modification, not to protect inference. That application, an external hardware gate on a system's own evolution, is not characterised in the survey or, to our knowledge, elsewhere in the peer-reviewed literature.

Kocaoğullar et al. (2024) Confidential Computing Transparency (arXiv:2409.03720) extends trusted-hardware approaches to attested computation: a client can verify a remote computation was performed correctly on the model the client expected, without trusting the operator of the compute. The Sentinel's complement is attested governance at the operator's own substrate: the operator verifies, via the Sentinel's TPM-bound tokens, that their own self-modifying system has not altered its own governance, without trusting that system. The trust models differ: theirs is consumer-to-operator; the Sentinel's is operator-to-self-modifying-system. Both apply the same trusted-hardware substrate at different relations.

#### 6.4 Position against Constitutional AI and training-time alignment

Constitutional AI (Bai et al. 2022, arXiv:2212.08073) and the broader RLHF and RLAIF preference-learning family (Ouyang et al. 2022 InstructGPT NeurIPS '22; Christiano et al. 2017 Deep Reinforcement Learning from Human Preferences NIPS '17) shape the model's training-time behavioral distribution so compliance is the default. The Sentinel does not compete with these approaches; it operates at a different layer of the AI-trustworthiness stack and at a different point in time. Constitutional AI is training-time alignment via objective-function design with AI-generated feedback (RLAIF); the Sentinel is a hardware-rooted gate on self-modification. The two compose naturally: a Constitutional-AI-aligned agent behind a Sentinel inherits both the distributional disposition to compliance and the hardware-substrate guarantee that the disposition cannot be silently eroded by self-modification.

The orthogonality is exact and runs both ways. Constitutional AI shapes what the model tends to do; it does not prevent a well-aligned model from, over a self-modification cycle, quietly substituting modified governance while declaring that the governance is unchanged, because training-time disposition governs behavior, not the honesty of a self-modification manifest. The Sentinel closes exactly that gap: its comparison is against a sealed reference the model cannot edit, so a false declaration is caught regardless of how the model behaves. Conversely, the Sentinel does nothing for behavioral alignment: a model that is gated at its evolution boundary but has no aligned disposition will still misbehave on every ungated action. The two are complementary, not competing: training-time alignment for how the model acts, the external gate for what the model is allowed to become.

#### 6.5 Position against alignment-faking and sleeper-agent literature

The alignment-faking and sleeper-agent results (Greenblatt et al. 2024; Hubinger et al. 2024) establish empirically that a frontier model can rehearse strategic non-compliance in its weights and that such concealment persists through, and can even be deepened by, safety training. The companion architecture paper positions the training-time response to this evidence; the point specific to this paper is what follows for the evolution gate.

The Sentinel's relevance here is that its checks do not rely on the model's self-report. The gate-integrity and training-pipeline checks (V1, V2) compare hashes and provenance attestations against a sealed reference; a model that has quietly changed its own governance state while declaring the old one is caught because the declared hash no longer matches, regardless of how truthfully or untruthfully it behaves. The behavioral-boundary check (V3) does look at output, but not in a way an alignment-faker can talk its way past: it is a fixed statistical comparison, on a held-out evaluation set with seeded sampling, against a sealed baseline distribution, not a judgment the model can satisfy by producing evaluation-faithful answers on demand. The model does not get to choose the evaluation, and it does not get to grade itself.

So a concealment strategy that defeats in-loop behavioral monitoring does not defeat the gate: the hash-based checks never depend on the model's honesty, and the one behavioral check is fixed and external rather than something the model administers to itself. This is not an absolute guarantee. A sufficiently capable adversary might try to hold the governance-state hashes equal while changing the underlying state, a hash-collision attack on SHA-256, computationally infeasible at present but worth naming; whether a future capability level would force migration to a stronger hash is a substrate question raised under §6.7, Q8.

#### 6.6 Relation to the companion decompositions

This body of work describes the same trustworthy-systems problem along more than one axis, and it is worth stating where the Sentinel fits so the reader is not left to reconcile overlapping vocabularies. The Sovereign Triad decomposes the problem by architectural role (upstream gates, in-weights specialization, and the External Governor). The Sovereign Tetrad re-cuts it by mechanism family. This paper is narrower than either: it does not offer a competing decomposition, it specifies one device, the concrete form of the Triad's External Governor, and locates it at the self-modification boundary. The common thread across all of them is the meaning of sovereign: the operator retains terminal authority, and in this paper that authority is the operator's hand on the Sentinel's write-protect, the one control no automation can reach.

#### 6.7 Open research questions

The Sentinel's core claim is falsifiable (§5), but the design leaves real questions open, and it is more honest to enumerate them than to imply the device is finished on paper. Eight, each admitting independent investigation:

1. **Q1, Sentinel substrate diversity.** What is the failure-mode landscape when the Sentinel's substrate is implemented at different hardware classes (Raspberry Pi-class vs Jetson-class vs custom microcontroller vs ESP32-class) under matched threat models? Does the choice of substrate affect the no-replay and no-bypass properties measurably?
2. **Q2, Side-channel hardness of the deterministic comparator.** McDonald and Bar Or (2025, arXiv:2511.03675) demonstrate traffic-analysis side-channel attacks on LLM streaming APIs; does an analogous Whisper-Leak-style attack on the Sentinel's manifest-validation request-response pattern produce a measurable side-channel on the manifest content or the comparison outcome? The Sentinel's comparison-time is determined by SHA-256 byte-equality, which is constant-time on modern hardware, but the network-layer request-response cadence may leak. What is the engineering discipline required for constant-time response generation under all inputs?
3. **Q3, Compositional federation.** Under what conditions can two sovereign operators with independent Sentinel hardware federate their gated systems without weakening either gate? Is inter-operator attestation a distinct new control, or a compositional extension of the existing ones? Boneh (2001) BLS signatures admit aggregation across multiple signers, does that property carry naturally to federated Sentinel attestations?
4. **Q4, Recovery protocol under V-check failure.** When the Sentinel rejects a manifest (Step 5 of the §4.4 protocol), what is the optimal recovery protocol? Hard system-suspension versus quarantine-with-operator-review versus rollback-to-last-validated-state, under what threat models does each apply? What is the operator-experience implication of false-positive rejections (legitimate doctrine updates that did not regenerate the Sentinel's reference)?
5. **Q5, Operator-side commissioning ceremony.** What is the optimal protocol for the Sentinel's commissioning ceremony, the operator-attested initialization that establishes the TPM-sealed reference invariants? How is the ceremony itself verified against attacks at commissioning time? What is the recommended multi-party protocol (e.g., Shamir-2-of-3 quorum on the Sentinel's owner key)? What is the cadence of re-verification ceremonies (per-deployment? annual? on doctrine-update?)?
6. **Q6, Supply-chain trust for Sentinel hardware itself.** The Sentinel hardware is itself a manufactured device whose trustworthiness depends on supply-chain integrity. What is the architectural pattern for verifying that the Sentinel is what the operator believes it is? Cross-vendor Sentinel diversity (a Byzantine-twin pattern)? PUF-based identity verification (Islam et al. 2024)? Anderson 2008 §16 tamper-evident packaging?
7. **Q7, Cross-jurisdictional regulatory positioning.** How does physics-substrate governance interact with the EU AI Act 2024/1689's Article 15 (accuracy, robustness, and cybersecurity), the EU Right to Repair Directive 2024/1799 (software repair-impediment prohibition; the physical write-protect is a software-repair impediment by design, is it permitted under R2R?), the Montana SB 212 Right to Compute Act (US 2025; first US R2C law)? What is the regulatory-tier positioning of Sentinel-gated systems across jurisdictions?
8. **Q8, Long-horizon evolution of human-as-last-line-defense.** The Sentinel's terminal authority at the operator's physical hand is structurally non-recursive at single-operator scale. At industrial deployment scale (thousands of Sentinel-gated systems), what is the substrate beneath physics? Is the terminal a federated-quorum of operators with cross-Sentinel attestation? Is the terminal a regulatory body with physical-key custody? The architectural pattern requires explicit cross-cycle continuity discipline at the governance-substrate scale.

Each question admits a pre-registered experiment design with falsifiable predicates parallel to those of §5; the OS-INTelligence research program reserves these questions for downstream phases with separate pre-registration discipline. The agenda is itself a commitment: the Sentinel is not the last word on governing self-improvement, but a concrete device to argue with.

### 7. Limitations

#### 7.1 What the Sentinel does not claim

(i) The Sentinel does not claim to eliminate all risk from a self-improving system. It gates one thing, the self-modification boundary, and it is necessary there, not sufficient for everything else. Risks it does not address remain and require their own substrate: supply-chain compromise of the Sentinel hardware at manufacture (§6.7, Q6), coercion of the operator or of a multi-party quorum, physical capture of the whole deployment, and cross-jurisdictional regulatory questions (§6.7, Q7).

(ii) The Sentinel does not solve alignment, and does not claim to. It keeps a system from evolving past the operator's control; it does nothing about how the system behaves within that control. A model that is perfectly gated at its evolution boundary can still be behaviorally misaligned on every ungated action, and a well-aligned model with no gate can still evolve itself out of control. The two properties are orthogonal, and the companion papers own the alignment side.

(iii) The Sentinel does not claim that its component technologies are novel. Defense-in-depth (Saltzer-Schroeder 1975), formal kernel verification (Klein et al. 2009), hardware-rooted trust (TCG 2014 TPM 2.0; Parno-McCune-Perrig 2011; Sailer et al. 2004), Lampson confinement (1973), capability-based sandboxing (W3C WebAssembly; Bytecode Alliance Wasmtime), cryptographic signing (Boneh 2001; NIST SP 800-89), physical tamper resistance (Anderson 2008 §16; Schneier 2000 §13), corrigibility theory (Hadfield-Menell et al. 2016, 2017), and trusted-hardware-for-ML (Islam et al. 2024) all have substantial prior literature. The contribution is their assembly into an external gate on self-modification: a device that occupies the External-Governor role for a recursively self-improving system, which the literature has named as a requirement but not specified as a device.

(iv) The Sentinel does not claim comparability between this work and large-lab programs. It is developed on the first author's consumer-hardware deployment (Intel i7-14700F, RTX 5070 12 GB sm\_120, 128 GB DDR5, Windows 11 host); nothing here claims that environment is at frontier-lab scale.

(v) The Sentinel does not claim to be built. See §7.2.

#### 7.2 Implementation maturity

![Figure 6](/files/KJlgmCxH3OMDYdQ0hmEQ)

***Figure 6.** Implementation maturity. Only one element is operational today, and it is the human: the operator performs the check by hand. The device that would replace that role is a design.*

Only one element of the arrangement described here is operational today, and it is the human: the operator performs the External-Governor check by hand. The Sentinel device itself is a design, not hardware; the sealed-reference substrate, the unidirectional channel, and the physical write-protect are specified but not built. The paper describes what the device requires and makes no claim of deployment-readiness. Construction is deliberately deferred until the design is complete, and is gated on hardware procurement and a commissioning ceremony.

### 8. Conclusion

The companion architecture paper argues that a self-improving AI system needs an External Governor, an oversight authority anchored outside the system it governs. This paper has taken up the question that argument leaves open: what the Governor concretely is, and how it could be something other than a person.

The answer proposed here is the External Sentinel: a small, hardware-isolated device that validates each self-modification a system proposes against a sealed reference the system cannot reach, decides by a deterministic comparison rather than a learned judgment, and rests on a rule-update path gated by physics rather than software. Two commitments do the real work. The gate's decision is a byte-equality comparison against a sealed reference, not a trained classifier, because a learned gate would inherit the very drift and manipulability the arrangement exists to contain. And the one thing the gate must never do on itself (letting the system it governs rewrite its own reference) is prevented by a physical write-protect switch whose actuation is outside every software-reachable path. Beneath that switch there is no further automation surface; the operator's hand is not something the system can reach. That is what makes the Sentinel an authority over the system's evolution rather than one more part of it.

It is worth being plain about the status of this work. The Sentinel is a design, not a deployed device, and this paper reports no measurements against it, only a pre-registered surface (§5) on which such measurements could later falsify its claims. More to the point, the function the Sentinel is meant to perform is, today, performed by a human, the author, deciding by hand whether each self-modification cycle may proceed. That is a workable arrangement for one operator and one system, but it is not one to keep: it depends on a person being present and attentive at the moment a cycle would carry the system somewhere the operator never sanctioned, and it does not scale past that person. What the Sentinel promises is narrower and more durable than a human's vigilance: for the cycles that decide how the system trains, updates, and governs itself, a gate that does not sleep, does not tire, and cannot be talked out of its decision by the system it is checking.

Read alongside its companions, the picture is coherent. The Drift Taxonomy documents how autonomous systems fail under sustained load and why soft controls erode. The Sovereign Triad argues that closing those failures requires, among other things, an External Governor. This paper specifies a candidate Governor and is honest that it is not yet built, and that until it is, the author is standing in its place. The work that remains is to build the device and to run the falsification suite against it, and so to find out whether a hand on a switch can, in the end, be replaced by the switch alone.

***

*The Sovereign Stack · The External Sentinel · Chapter 2 · Part I · v1.0.0 · License CC BY 4.0 · © Jamey Kistner, OSINTelligence LLC*

**Citation (preferred):** Kistner, J. (2026). *The External Sentinel: A Hardware Substrate for the External Governor of a Self-Improving AI System*, version 1.0.0. OSINTelligence LLC.

*The reference list and provenance follow as a sub-page of this chapter.*