AI Kernel Killswitch

AI-kernel-kill-switch provides a last-resort shutdown mechanism for self-hosted LLMs via AES-256-GCM-authenticated payloads embedded in ordinary prompts.

Endorsed by

Naga

Nikita

AI-kernel-kill-switch provides a last-resort shutdown mechanism for self-hosted LLMs via AES-256-GCM-authenticated payloads embedded in ordinary prompts.

Endorsed by

Naga

Nikita

Project Details

AI-kernel-kill-switch is a last-resort kill-switch for a self-hosted LLM that may be misaligned or going rogue: a trusted operator sends an AES-256-GCM-authenticated payload inside an ordinary prompt.

Hackathon paper: AI Kernel Killswitch
Code: github.com/twigglits/AI_kernel_killswitch

Theory of Impact

Frontier models are trained and served in a small number of large datacentres. The natural choke point for any hard, enforceable off-switch. Today no such control is mandated, and no rigorous, audited reference for one exists. This project aims to be that reference architecture: a fail-closed, quorum-gated containment stack — deployment killswitch, out-of-band compute/power cutoff, and human-signed promotion lease — specified and hardened well enough that when international AI-safety regulation eventually mandates emergency-stop capability at frontier compute, there is a credible, tested design to adopt rather than a blank page.

The near-term impact is a reproducible, single-box proof of every primitive the datacentre version needs, plus an honest map of what does and does not survive a host-controlling adversary. The long-term impact is optionality for regulators and compute providers: a containment standard they can adopt, audit, or require — built now, in the open, by an independent lab, so the engineering is done before the political will arrives rather than scrambled together after.

People

Jean Naude

Team Member

Track Record

Global South AIS Hackathon (Apart Research), 2026

Grants Received– no grants recorded

Add grant

Funding Asks

Funding ask

Open

Minimum

$5,000

Ideal

$50,000

What this ask is

This project's completed state is a containment control deployed where frontier models are actually developed, in the data centres. The one place a hard off-switch can be enforced. That won't happen without international AI-safety regulation mandating it, which is years off. So in the meantime, this funding will allow us to build the rigorous, tested reference architecture for the future, so that reference architecture already exists the day that regulation lands.

Three deliverables extend the killswitch from a single-deployment emergency stop (Phase 1, built and GPU-verified) to a fail-closed containment stack:

Hardware last-resort actuator. Today detonation scrambles the weights and crypto-shreds the LUKS checkpoint. We add a deeper in-band path: on an authenticated last-resort trigger, brick the serving GPUs' VBIOS so those cards can no longer run the model , with a documented external-SPI recovery rig so the air-gapped golden master and forensics survive. Tested destructively on sacrificial cards.
Fail-closed capability killswitch (Phase 4). The firmware brick is in-band, so it cannot defeat an AI that already controls its host. The decisive control sits outside the AI: a human-signed, quorum AUTHORIZE lease at the training-loop promotion gate, plus an out-of-band compute/power cutoff (networked PDU/relay). Absent a fresh lease, the loop halts and the hardware powers down by default.
Reference architecture + evidence. Cross-architecture replication of our backdoor-removability negative result (blocked today on needing a headless GPU), an independent red-team, and a documented single-box reference design. The proof-of-concept for the datacentre-scale, regulator-mandated version this is aiming at.
Publish these results to a journal and blog and make a public call to world leaders, public figures and leaders in the AI Safety field to review the reference architecture and push for its implementation at frontier AI labs.

How the money will be spent

Minimum ask (~$5,000) funds the focused proof of concept only:
The VBIOS brick-and-recover PoC and the fail-closed lease and promotion-gate prototype — roughly $3000 engineering,
$1500 sacrificial cards and SPI recovery rig,
$500 for cloud compute.

Ideal Ask(~$50,000)
Engineering / research time (~3 months FTE-equivalent) to build the hardware actuator, the AUTHORIZE lease and promotion gate, integration and tests — approx. $25,000.
Headless (non-display) compute GPU for the RSI testbed and the cross-architecture trojan run currently blocked on the display-GPU kernel watchdog - approx. $6,500.
Sacrificial GPU cards for destructive VBIOS brick-and-recover testing, plus external SPI flash programmers and a recovery rig — approx. $4,500.
Cloud GPU hours for larger training/eval and cross-architecture replication - approx. $4,000.
Out-of-band cutoff hardware, a networked PDU plus relay/microcontroller test bench — approx. $1,500.
Independent security review / red-team of the gate and lease design — approx. $4,500.
Contingency and dissemination (reference-architecture write-up, travel to present) — approx. $4,000.

Discussion

Private comments in this thread are only shown to approved funders and grant reviewers. Email hi@grantmaking.ai or to request access.

Private UserPrivate15d?

Nikita LokhmachevJudge · Global South AIS HackathonEndorsement15d

This is seriously good work. You've built an emergency stop that the owner of the system controls, you keep it separate from the AI itself, and best of all, everything you claim can be checked by just running it, which is rare and valuable. My one honest worry is the name, because "kernel" makes it sound like the off switch is protected deep inside the computer's core, and it isn't, it's an ordinary program that anyone with full control of the machine could still get around (you admit this yourself, which I respect). The whole thing also rests on a single secret key, so if that key is lost or stolen the protection falls apart, and I'd lock that key away in dedicated security hardware, add a few guards so the AI can't quietly copy itself somewhere safe before the switch fires, and maybe give it a more honest name, since the work is strong enough that it doesn't need to oversell itself.

Naga Sujitha VummaneniJudge · Global South AIS HackathonEndorsement15d

This is the strongest submission of the batch on execution, and one of the most intellectually honest. Two genuinely distinct contributions: a working, live-verified cryptographic kill-switch, and a clean negative result on backdoor removability replicated across four model scales. Main issues:

The two phases serve different purposes and the coupling is somewhat rhetorical. Phase 1 (kill-switch) and Phase 2 (trojan detection/ablation) are stitched together by the argument "therefore the kill control belongs in the harness, not the weights." That's a reasonable framing, but Phase 2 doesn't really test whether anyone would put a kill-trigger in the weights — it tests whether a single linear direction can remove an arbitrary backdoor. The conclusion is sound; the bridge between the two is more narrative than empirical.
The kill-switch is engineering, not a research finding. It works and is well-built, but "an operator can authenticate a payload that scrambles weights and crypto-shreds a volume" is a solid systems implementation rather than a novel safety result. Its value is as a demonstrated artifact. The limitations section is admirably thorough and pre-empts most objections (self-exfiltration, pre-placement, key custody), which is exactly right — but those limitations also bound how much the kill-switch advances the field versus simply existing.
Phase 2's negative result is the more scientifically interesting half, and it's somewhat undersold by scope. Single layer, single direction, one trigger style — the authors flag all of this. But "ablation doesn't remove it" replicating Arditi-style single-direction methods on a backdoor is a meaningful contribution precisely because it's a clean, controlled negative with a random-direction control and a perplexity check ruling out the lobotomy confound. That methodological care (the additive-steering-is-cheating note especially) is the best part of the submission.
Confounds worth flagging. The benign perplexity baseline is very low (short prompts), which the author notes — but it makes the 3B's 1.1→3.2 jump hard to interpret. And the trojan is self-trained, so Phase 2 shows "a backdoor we inserted survives ablation," not necessarily a naturally-arising one.