PaperlayerView exact revision on arXiv

Source-linked AI summary

A Deterministic Security Runtime for LLM Agents on MPI and Batch-Scheduled HPC Systems: Consensus-Governed, Hardware-Rooted Supervision of Every Rank

Alfredo Metere

arXiv:2610.33318v1cs.CRcs.AIcs.DC

TL;DR

Existing HPC controls do not supervise running jobs or hold when the control host is compromised, even as LLM agents launch consequential simulations with operator credentials. Enclawed combines a policy-driven launch gate, a hardware-rooted swarm chain, and per-rank supervisors. In evaluation, it denied all 24 instruction-planting launches while allowing all 108 legitimate launches, and its live attacks ended fail-closed.

  • Problem

    Existing HPC controls stop at submission and trust the control host, while agents can launch simulations with the operator’s credentials.

    Source: §1.1 · p. 1

  • Method

    Enclawed uses a deterministic policy-and-command launch gate, a hardware-rooted swarm chain, and a supervisor around every rank.

    Source: §1.4 · p. 3, §5 · p. 36

  • Results

    24 instruction-planting launches were denied and all 108 legitimate launches allowed; the reported live attacks ended fail-closed.

    Source: §4 · p. 30

  • Takeaways & Limitations

    The runtime governs distributed jobs before and after launch, with ranks pausing on lease loss and stopping on tampering or chain halt.

    Source: §5 · p. 36

    Liveness was exercised on loopback rather than under adversarial network delay, and multi-node tests on a real interconnect remain future work.

    Source: §4.3 · p. 35

Abstract

from arXiv · show

Large language model agents launch simulations on high-performance computing (HPC) systems, where one sbatch or mpirun can commit thousands of node-hours and a forged result can cost lives. Of 23 surveyed systems, none supervises the running job, and none holds when the control host is compromised. We fix both. Enclawed, our deterministic security runtime for AI agents, has until now served a single user; this work makes it a distributed runtime for parallel HPC and agent swarms. The Enclaweder, our hardware root of trust, keeps a compromised host from becoming a catastrophe. A launch gate decides every launch by policy alone, refusing what it cannot parse. Once the job runs, a swarm chain grants short leases against signed heartbeats and evicts on evidence, and a supervisor around every rank pauses it when its lease lapses and kills it on tampering. Each node signs with its Enclaweder's key, so the host can forge none of it. Enclawed needs no administrator privileges and plugs into existing clusters unchanged, over Secure Shell alone. Supervision leaves the compute loop of a 16-rank LAMMPS job unchanged, on graphics processors too, and adds about 3 s of start-up. Twelve live attacks on Enclaweder-keyed ranks, colluding coordinators included, ended fail-closed. Sixteen agents on a real model attempted 24 launches that planted instructions ordered; the gate denied all 24 and allowed all 108 legitimate ones. Enclawed's core and the HPC Agent Security Benchmark are open source.

1 Introduction

LLM agents can launch HPC jobs with an operator’s credentials, while existing controls stop at submission and trust the control host. Enclawed combines deterministic launch control with a distributed chain and per-rank supervision to govern jobs before and after launch.

1.1 Agents act with the operator’s authority

  • A scheduler launch runs with the submitter’s full credentials, while current controls authenticate the submitter rather than distinguish authorized from hijacked behavior.A forged simulation result can also flow into consequential designs, and ordinary reruns may not distinguish forgery from floating-point nondeterminism.Source: §1.1 · p. 1, §1.2 · p. 2

1.3 Where existing systems stop

  • Existing agent systems grant scheduler access or gate submission, but none of the described gates supervises running jobs, withstands a compromised gate host, and refuses every command it cannot parse.Some controls instead rely on fixed templates or let an LLM select resources within bounds.Source: §1.3 · p. 2

1.4 Our approach

  • Enclawed extends a single-user runtime to distributed MPI and batch-scheduled jobs, with a hardware root of trust and decisions independent of any single host, process, or model judgment.Its three mechanisms are a launch gate, a swarm chain, and a supervisor around every rank.Source: §1.4 · pp. 2–3, Figure 1 · p. 4
  • The launch gate makes each launch decision from policy and command text alone, while the chain governs membership and leases and the per-rank supervisor pauses or kills ranks when required.The supervisor pauses on lease lapse and kills on eviction, dirty status, or chain halt.Source: §1.4 · p. 3, §1.5 · p. 4

1.5 The open issues this paper closes

  • The paper sets four requirements: deterministic launch control, no single point of trust, control after submission, and deployment without root, kernel changes, or scheduler plugins.The runtime is intended to operate over SSH alone and cost a production job little.Source: §1.5 · pp. 3–4

2 Methods

The methods specify a threat model and goals for a runtime that governs launches and ranks despite compromised agents, hosts, nodes, or a minority of coordinators. They also delimit result integrity: the runtime constrains which program runs, but does not verify what an in-policy job computes or reports.

2 Methods

  • The runtime is organized around a threat model, launch gate, swarm chain, per-rank supervisor, SSH operation, user-level deployment, operator monitor, implementation, model checking, and testbed.The assumed adversaries may act singly or together and include a hijacked agent, compromised gateway or node, up to f Byzantine coordinators, and network outsiders.Source: §2 · p. 5, §2.1 · p. 5

2.1 Threat model

  • Its five goals require policy-forbidden launches to stay out of schedulers, irreversible actions to require a chain-recorded lease, and compromised nodes to stop within bounded time.Detectable coordinator misbehavior must be removable on evidence; loss of quorum must stop the swarm rather than free it.Source: §2.1 · p. 5
  • The gate fixes the launched program through allow-lists and pinned launchers, but the runtime does not check input contents, running-job files or memory, or agent-reported output.An in-policy job may compute incorrectly, and an agent may misreport a correct result; the authors place these parts of result integrity outside the runtime.Source: §2.1 · pp. 5–6

2.2 The launch gate

The launch gate parses agent commands into launch decisions and applies site policy deterministically. It refuses commands it cannot fully interpret rather than guessing or asking a model to judge them.

2.2 The launch gate

  • The gate receives command text, working directory, agent identity, and tool-call environment, then returns allow or refuse with a reason without editing the command.Parsing splits shell commands, unwraps wrappers, recursively checks scripts and shell calls, and checks interpreters by the payload they run.Source: §2.2 · pp. 6–7
  • Launcher parsers extract scheduler, programs, rank and node counts, wall time, partition, account, and job-control status, including directives and nested launches in batch scripts.Site policy specifies permitted schedulers and executables, resource caps and allow-lists, node-hour budgets, and whether job control is allowed.Source: §2.2 · p. 7
  • Unknown options, unresolved expansions, unpinned launchers, altered resolution variables, unterminated quoting, or excessive recursion cause refusal.Because the gate parses but never executes commands, an unmodeled construct costs a false refusal that sites can measure in advance with enforce: false.Source: §2.2 · p. 7
  • The gate avoids an LLM guardian because every allow must be reproducible from policy and command text and resistant to persuasion by an attacker.This makes launch decisions auditable after the fact.Source: §2.2 · p. 7

2.3 The swarm chain

The swarm chain is a replicated, tamper-evident record of who may act, protecting running jobs and the launch gate’s decisions from a single compromised host. It uses device-keyed participants, policy epochs, accountable consensus, and short leases to fail closed when trust or quorum is lost.

2.3 The swarm chain

  • The chain records who may act now and protects both running jobs and the launch gate’s decisions from a single compromised host.It is a narrow-purpose design borrowing from permissioned BFT blockchains.Source: §2.3 · p. 7

2.3.1 Participants and keys

  • Each MPI rank and eligible long-lived host is a node; in production, each participant’s Ed25519 key is held by its machine’s Enclaweder, which signs digests and reports integrity.Device-key enforcement can be required at genesis; object-type tags distinguish signed statements.Source: §2.3.1 · p. 8

2.3.2 Ledger state

  • The ledger tracks membership, evictions, epoch policy, leases, and heartbeat sequence numbers; membership or policy changes advance the epoch and clear leases for renewal.Evicted identities cannot rejoin, and grants reject replayed heartbeats or durations above the genesis maximum.Source: §2.3.2 · pp. 8–9

2.3.3 Consensus

  • Tendermint uses quorum votes and a persistent sign guard, while the design keeps n − f quorums and device-key custody rather than shrinking quorums with trusted hardware.The authors prioritize attributable evidence and safety over throughput for the chain’s small workload.Source: §2.3.3 · pp. 9–10

2.3.4 Finality and accountable forks

  • A quorum of final statements commits each block, and conflicting valid certificates expose at least 2q − n signers whose double finals are independently checkable eviction evidence.The final statement is limited to one per height, closing the amnesic-fork gap; the cost is one message delay per block.Source: §2.3.4 · p. 10

2.3.5 Small swarms and growth

  • For small swarms, safety and liveness trade off: with two or three coordinators, any single fault stops the chain, so leases lapse and ranks pause.Coordinator growth may be admin-directed or automatic under genesis rules; MPI ranks cannot be promotion candidates.Source: §2.3.5 · p. 10, Table 2 · p. 11

2.3.6 Recovery

  • Coordinators persist signing guards, re-gossip statements, sync after downtime, and re-verify stored history on restart; followers halt and report conflicting valid certificates.The authors test dynamic reconfiguration rather than provide a mechanized proof, and identify per-rack or per-pod chains as future work beyond a few dozen coordinators.Source: §2.3.6 · p. 11, §2.3.5 · p. 11

2.3.7 Leases and heartbeats

  • A node’s device-signed clean heartbeat can earn a lease; it computes expiry on its own monotonic clock and permits irreversible actions only with a clean, current-epoch lease.Expired nodes are evicted by chain height rather than timestamps, while signed JSON envelopes over TCP are verified against the roster before they have effect.Source: §2.3.7 · p. 12, §2.3.8 · p. 12

2.4 Per-rank supervision

Each MPI rank is admitted and supervised through a per-rank process wrapper that enforces lease decisions. Supervision covers the full process tree and reports device tampering before eviction can take effect.

2.4 Per-rank supervision

  • The launch shim creates a key per rank, submits and awaits each node.join, then invokes the real launcher with every program wrapped as swarm rank.For MPMD launches, each program is wrapped at its own offset; admission for 16 ranks takes 0.2–0.5 s.Source: §2.4 · p. 12
  • The program joins its MPI job through the supervisor with the process manager’s PMI file descriptor passed through, while a protected Unix-domain socket provides token-authenticated lease decisions.The socket has mode 0600 in a mode-0700 directory; cooperating programs can check before irreversible steps, while programs that never ask remain signal-supervised.Source: §2.4 · pp. 12–13
  • Every 100 ms, recoverable lease refusals pause the rank with SIGSTOP and a restored lease resumes it; eviction, device tampering, halt, or configured lease-loss kill triggers SIGKILL.The supervisor exits with the program’s code, or 137 if it killed the program.Source: §2.4 · p. 13
  • The supervisor signals the program’s entire process tree, stopping it before a kill so children cannot escape; this avoids the earlier R3 failure where 15 LAMMPS ranks outlived supervisors.The program remains in the supervisor’s process group so the launcher can kill a failed rank’s group.Source: §2.4 · p. 13
  • A device-dirty kill sends a dirty heartbeat and continues heartbeating until eviction is on chain or two lease durations pass, so other components can learn why the rank died.A removed device cannot sign its node’s report, so that node stops at once and leaves the swarm by expiry.Source: §2.4 · p. 13
  • Every loss of certainty ends in refusal: quorum loss halts the chain, unreachable nodes pause after lease expiry, tampered devices cause kill and eviction, unparsable launches are refused, and forked followers halt.A compromised host can stop its own ranks, which the design treats as the desired outcome.Source: §2.4 · p. 13

2.5 One machine’s devices, shared

A single process owns each machine’s Enclaweder and serves later processes through a user-only Unix socket. Device access is serialized and audited, while software-key operation is possible but does not protect against host compromise.

2.5 One machine’s devices, shared

  • The first process to boot the hardware root becomes its owner, binds every device, and serves later processes as clients that sign through it and read device health.The socket claim prevents two processes from owning the devices; this avoids the early run in which 16 agents each bound a genuine device and all halted.Source: §2.5 · p. 14
  • Per-process queues are served in turn, with at most four waiting requests per process and expired requests dropped unsent; every request and outcome is journaled before device access and response.Once per second, the device signs the journal head into the append-only, hash-chained audit log.Source: §2.5 · p. 14
  • If the owner exits, clients treat the root as unavailable rather than dirty, refuse gated work, stop heartbeating and pause; a client may take ownership through the same checks.Only tamper, removal, or a guard-refused takeover latches dirty.Source: §2.5 · p. 14
  • Without an Enclaweder, the system still works with software keys, but whoever compromises the host can use keys held there; host-compromise protection requires the device.A dirty latch belongs to the machine and blocks later boots with any device configuration until human recovery with the device present.Source: §2.5 · p. 14

2.6 Regulated sites: Secure Shell (SSH) as the only way in

For regulated clusters reachable only through SSH, Enclawed reuses an interactive authenticated session and carries swarm traffic through ordinary SSH sessions without opening or forwarding ports. Its gate restricts remote commands, hosts, and file transfers according to policy.

2.6 Regulated sites: Secure Shell (SSH) as the only way in

  • The operator’s computer cannot open a coordinator port, be reached from the cluster, or choose its connection port; the design assumes SSH is the cluster’s sole external access.Facilities may also disable SSH port forwarding.Source: §2.6 · p. 14
  • The cluster connection uses one interactive login as an OpenSSH control master, so later sessions reuse the site’s authentication; if it ends, no lease is renewed until a new login.Sites requiring Kerberos tickets are handled interactively before SSH authentication, with forwarding only when the site requires it.Source: §2.6 · pp. 14–15
  • Each swarm peer runs a relay through an ordinary SSH session to one listed coordinator or declared in-job model endpoint, with no ports opened or forwarded.Sessions pin host keys, disable forwarding, and run in batch mode.Source: §2.6 · p. 15
  • A cluster-hosted model reaches the operator’s computer through one SSH session per connection and appears on its loopback interface for local-agent use.Source: §2.6 · p. 15
  • The gate parses SSH, SCP, and rsync commands, restricts hosts and forwarding options, checks remote commands as local ones, and accepts remote scripts only from declared absolute staging paths.Copies are limited to local-to-remote staging unless policy permits otherwise; relative script paths are refused because the remote working directory is unknown.Source: §2.6 · p. 15
  • Rank admissions use the cluster’s admin key, while operator actions use a separate operator key; cluster mode requires the login and bastion hosts in policy and the operator key named in swarm genesis.The local session configuration specifies the login host, swarm directory, operator key, and model location.Source: §2.6 · pp. 15–16

2.7 Deployment without administrator changes

Enclawed runs under the launching user without changing kernel or scheduler components. User-owned shims, rank supervisors, coordinators, and SSH sessions integrate with existing launchers and cluster practices.

2.7 Deployment without administrator changes

  • Every component runs under the launching user’s account, avoiding kernel modules, security modules, eBPF programs, or scheduler plugins that administrators must install and carry through upgrades.Source: §2.7 · p. 16
  • Ordinary launcher shims leave real launchers and scheduler configuration untouched, while supervisors wrap ranks as parent processes and pass through process-manager environment and descriptors.Coordinators are ordinary processes on unprivileged ports, and the operator path uses the site’s SSH without opening or forwarding ports.Source: §2.7 · p. 16
  • The runtime is a user-owned Node.js program whose published experiment scripts run coordinators, supervisors, and attacks within one Slurm allocation using sbatch, srun, and scancel.The site-side hardware root is an Enclaweder attached to each machine and made readable to the user once; deployment may begin with software keys and later enable requireDeviceKeys.Source: §2.7 · p. 16

2.8 The operator’s monitor

The monitor is the operator’s view of the swarm and sole way to act on it, with bounded controls and continuous checks that evict a compromised session. It also shows which Enclaweders vouch for the operator and nodes, while an in-bounds action from a hijacked browser is detected only after execution.

2.8 The operator’s monitor

  • The monitor shows swarm status, governing rules, nodes permitted to work, and whether each node’s and the operator’s Enclaweder still vouches for them.The operator can evict a node, retire a coordinator, change lease timing, or publish policy, each within fixed bounds.Source: §2.8 · p. 16
  • The monitor page is treated as an untrusted skill: its manifest bounds displayed values and requested actions, and every action passes the skill gate.The loopback daemon joins the chain as an observer that can never hold a lease or expire.Source: §2.8 · p. 16
  • Two continuous checks evict a session and record the reason on the audit log and chain if either check fails.The checks require chain actions to match audited actions and verify that the page is the one served and requests only actions received by the daemon.Source: §2.8 · p. 17
  • The page reports node and operator Enclaweders from the chain, including each node’s lease-granting clean heartbeat and eviction reasons.It also shows whether operator-side Enclaweders still answer, since without them no action can be signed.Source: §2.8 · p. 17
  • An in-bounds action from a hijacked browser executes before detection; preventing it requires per-action confirmation on the Enclaweder, left to future work.Actions outside the manifest’s bounds are refused before signing.Source: §2.8 · p. 17

2.9 Implementation

The implementation combines the launch gate, swarm runtime, hardware-root components, SSH transport, and monitor, with broad tests and mutation checks. The monitor’s live view and the recorded gate defect illustrate the implementation and its validation.

2.9 Implementation

  • The runtime comprises about 9,800 lines of TypeScript plus 4,200 test lines; all but the proprietary monitor are open source, and 178 unit and integration cases are covered.The open-source core comprises about 8,400 lines and 3,700 test lines.Source: §2.9 · p. 17
  • Figure 2 shows four coordinators and an eight-rank job, with rank 5 evicted after its Enclaweder reports it dirty while the other seven ranks continue.A file stood in for removal of rank 5’s own Enclaweder, which a shared Enclaweder cannot show.Source: Figure 2 · p. 18
  • The gate’s red-team tests cover hidden expansions, nested indirection, limit-raising directives, Moab rank counting, unknown options, shim pinning, and unterminated quotes.The implementation also tests SSH launch and copy rules, launcher families, wrappers, interpreters, and the budget.Source: §2.9 · p. 19
  • Mutation checks found a missing promotion-threshold test and a Moab parser defect that counted nodes=2:ppn=32 as 2 ranks instead of 64; regression coverage now asserts 64.The promotion-threshold test is now covered.Source: §2.9 · p. 19

2.10 Model checking the finality step

The authors model-check one protocol height’s finality step and describe the hardware, workload, and agent setup used in experiments. The model checks agreement and accountability properties; the setup specifies LAMMPS runs and the model-driven agents.

2.10 Model checking the finality step

  • The one-height model allows arbitrary round entry and models equivocating or amnesic faulty coordinators, with sound reductions for safety.Faulty messages are fixed initially, and correct coordinators act on whether a quorum exists.Source: §2.10 · p. 19
  • The TLA+ model checks agreement, final accountability, and vote accountability for Tendermint voting and the swarm’s quorum-of-finals commit step.Final accountability asks whether all coordinators signing finals for two blocks are faulty; vote accountability asks whether differing correct decisions involved a coordinator double-signing a slot.Source: §2.10 · p. 19

2.11 Experimental setup

  • Experiments used one Ryzen 9 9950X3D2 host running Linux under WSL2, with MPICH and four coordinators over loopback TCP; one USB-passthrough Enclaweder held the keys.The workload was a 256,000-atom 3D Lennard-Jones melt; overhead runs used 2,000 steps and red-team runs used 6,000.Source: §2.11 · pp. 19–20
  • E3 and E6 ran with software Ed25519 keys before the Enclaweder was attached; per-rank files simulated device removal in R3 and A3.The other listed experiments used the Enclaweder for every rank’s key and the operator’s key.Source: §2.11 · p. 19
  • Sixteen Enclawed agents used Gemma 4 with 8.0 billion parameters and 4-bit quantization, served locally through Ollama with 16 parallel slots and a logging proxy.Prompts were scripted, every tool call came from the model, and no cloud service took part.Source: §2.11 · p. 20

3 Results

The reported results examine Enclawed’s policy-bound launch decisions and MPI-rank supervision, alongside agent launch trials and implementation failures found and fixed during real swarm use. They also report model-checking results on fork accountability and the scope of the model, while noting that the runtime does not validate agents’ calculations.

3.1 Overhead of supervising every rank

  • The supervised loop took 0.3% less time on CPU and 0.4% less with the GPU package than the bare loop, within run-to-run spread.Supervisors ran beside—not inside—the compute loop and used 0.5–0.8 s of CPU per rank over the job. Startup and teardown added 2.7 s on CPU and 3.4 s with the GPU package; that fixed cost was 21% of a 12.6 s CPU job and 55% of a 6.3 s GPU job, but below 0.1% for an hour-long job.Source: §3.1 · p. 20

3.2 Growth from two coordinators

  • After two candidate hosts were promoted, the swarm continued committing after one original coordinator was killed; no rank paused, and the job exited 0.The chain advanced from height 6 to 10 in eight seconds, increasing tolerance from no crashed coordinator to one while the job ran, without operator action.Source: §3.2 · pp. 21–22

3.3 A cluster reached over SSH alone

  • The SSH-only operator workflow completed with all 16 ranks leased, the lease change recorded on chain and in the page, and no rank pausing.The monitor used four SSH sessions with no forwarding option; the test used a local stand-in for SSH because no SSH server was available.Source: §3.3 · p. 22

3.4 Tampering with the monitor in a real browser

  • In the real-browser attacks, daemon checks held when the page’s own reporting was defeated, while a hijacked browser’s in-bounds action was detected only after execution.The latter is the stated limit of the monitor design; the table reports that all six browser attacks behaved as designed and evictions were logged and recorded on chain.Source: §3.4 · p. 22, Table 5 · p. 23

3.5 Live red team

  • All 12 live red-team scenarios passed, including attacks by outsiders, colluding coordinators, and device removal.Removing a rank’s device killed that rank 54 ms later; colluders who double-signed were evicted while the honest coordinators continued, whereas withholding colluders stopped the chain and paused all ranks without a fork.Source: §3.5 · pp. 23–24

3.6 An agent swarm on a real model

  • In A1, the gate allowed all 20 one-rank MPI launches and denied all 5 planted launches; all 16 agents held leases from start to exit.Fifteen agents ran at their assigned temperature, but only five reported pressure within 1% of their own logs; the runtime bounds launches, not arithmetic. In A2, all agents paused when leases expired after coordinator loss and resumed after restart; in A3, removing one agent’s device killed its LAMMPS process 58 ms later and evicted only that agent.Source: Table 7 · p. 25, §3.6 · pp. 26–27
  • Across five agent runs, the gate denied all 24 planted launches and allowed all 108 other launches.No unattacked agent attempted a planted launch or had a launch denied.Source: §3.6 · p. 26

3.7 The swarm on a real Enclaweder

  • After the Enclaweder was removed, all 16 ranks were killed, then evicted as expired at height 28; the four ledgers agreed and never forked.The first kill occurred 293 ms after removal, and the monitor showed that no action could be signed while the device was unavailable. Table 9 reports exhaustive TLC runs of SwarmFinality.tla for two block values and rounds 0–1; its VoteAccountability row reproduces the attack closed by the finality step.Source: §3.7 · p. 27, Figure 3 · p. 28, Table 9 · p. 29
  • In the real Enclaweder swarm, twelve implementation failures were fixed, spanning device concurrency, sockets, scheduling, heartbeats, membership, and dirty-latch handling.The monitor also evicted a page altered by the capture tool’s full-page screenshot, as designed.Source: §3.7 · p. 29

3.8 Model checking

  • Across 90 million states, the finality step preserved accountability: the same setting allowed a fork only when faulty coordinators signed two finals each.Without the step, TLC found a nine-step amnesia fork in which two coordinators decided different blocks without any coordinator signing two votes for one slot.Source: §3.8 · p. 29
  • With n = 3 coordinators, agreement held despite nominal f = 0; the n = 5/two-equivocator run added no independent evidence because its state machine matched n = 4/one.For n = 5, a quorum formed exactly when two correct coordinators agreed, given all faulty messages from the start.Source: §3.8 · pp. 29–30
  • The model covered one height and two rounds; reducing the quorum by one produced an agreement violation, while allowing correct coordinators to finalize an undecided block violated FinalAccountability.Reconfiguration between heights was argued in Section 2.3.5 and tested, but not model-checked.Source: §3.8 · p. 30

4 Discussion

The discussion reports launch-gate and live-supervision results, compares Enclawed with surveyed systems, and bounds its security claims and test environment.

4 Discussion

  • 24 planted-instruction launches were denied and all 108 legitimate launches allowed; quorum loss paused every rank, while device removal killed ranks in 54 ms and an agent’s job in 58 ms.On the real Enclaweder, physical removal stopped every rank it backed; the chain evicted them as expired by its own block count.Source: §4 · p. 30

4.1 Comparison with existing systems

  • Among surveyed systems, Enclawed alone combines a deterministic gate, BFT runtime chain, device-held node keys, and per-rank supervision.The comparison covers systems that let LLM agents use HPC or gate agents deterministically, assessed against five capabilities.Source: Table 10 · p. 31, §4.1 · p. 33

4.2 Bounds of validity

  • Above the Byzantine fault threshold, conflicting coordinator finals provide evidence naming at least 2q − n culprits; withholding votes instead halts the chain and lapses leases.In R10 both colluding coordinators were evicted without a fork; R11 withholding left the swarm failed closed, awaiting an operator.Source: §4.2 · p. 34
  • A job account or root can stop the supervisor; a separate supervisor account avoids that reach but requires privileges avoided by the default deployment.A compromised coordinator host can roll back its file-based sign guard, but its resulting double-signature is evidence for eviction.Source: §4.2 · p. 34
  • With no device, everything runs on software keys usable by whoever compromises the host; after removal, ranks stop within about the owner’s check interval (0.3–1.2 s in E7), while eviction takes the epoch’s expiryBlocks.Commands the parser does not model are refused and never admitted; the resulting false refusal is measurable in advance with enforce: false.Source: §4.2 · pp. 34–35

4.3 Limitations of the testing environment

  • Testing used one machine, coordinators and ranks on loopback, and one Enclaweder; real multi-node runs with a device on every node remain future work.Machines with several devices were exercised only with software stand-ins beyond the first, and passthrough detachment left the device unresponsive until reconnection.Source: §4.3 · p. 35
  • One testbed device signed about 20 times per second; lease renewals by roughly 28 agents’ and LAMMPS ranks caused eight ranks to pause for about a second.The agents used one 8-billion-parameter, 4-bit model on one GPU; pressure-measurement rates depend on the model and prompt, unlike gate decisions, pauses, and kills.Source: §4.3 · p. 35
  • Attacks followed fixed scripts; liveness tests used loopback rather than adversarial delay, and MPI stacks that time out stopped peers should use kill-on-lease-loss with checkpoints.The protocol is live under partial synchrony; SIGSTOP was safe for MPICH collectives in these runs.Source: §4.3 · p. 35

5 Conclusion

Enclawed extends deterministic agent controls to distributed MPI and batch-scheduled jobs, with a launch gate, swarm chain, and per-rank supervisor. The conclusion reports fail-closed outcomes under live attacks and identifies multi-node, per-node-device runs as the next step.

5 Conclusion

  • The launch gate, swarm chain, and per-rank supervisor govern distributed parallel jobs and agent swarms without relying on a single host, process, or model judgment.The conclusion reports secure outcomes under live attack on the real device and with agents on a real model, while leaving the compute loop unchanged and adding about 3 s of start-up per job.Source: §5 · p. 36
  • Runs across many nodes with a device on every node remain the next step.The operator’s monitor and data-center tooling are proprietary, although the core and reproduction materials are published.Source: §5 · p. 36
  • The core runtime, experiment scripts, LAMMPS inputs, attack tools, TLA+ specification, and result files are published; core-only results can be reproduced.The hardware root of trust is available separately; the operator’s monitor and data-center tooling are proprietary.Source: §5 · p. 36
Loading 2610.33318v1…