要点
- Architecture claim: ROM/RAM/xPU-style circuit and Secure OS live in the model file; original LLM/VLM skills stay; OS adds control without retraining the base knowledge.
- Four in-weight properties: boot integrity (byte change locks), rule decisions (not persuadable chat), tamper-evident hash-chain audit, kill switch anyone can halt and only a signed key can resume.
- Public demo ViKernel Desktop (v0.1) on Hugging Face Spaces with terminal, kill-switch lab, policy engine, leak test, audit viewer; demo replays recorded OS responses; files and keys are fictional.
- Stated support: Gemma 4 4B live in demo; Qwen verified; Llama, Mistral, DeepSeek, Phi, GLM, Kimi, Nemotron, gpt-oss listed as targets.
- Internal audit claim: 0 unrequested outbound transfers across 661 runs on four open models with mock tools and honeypot data; vendor-only, not independent.
On 1 November 2026, FINAL-Bench published "ViKernel: Why the Kill Switch Must Live Inside the Model" on Hugging Face, with a public desktop demo. Large models no longer sit politely inside applications. They call tools, write files, and chain actions. Control still mostly lives outside: wrappers, proxies, prompt filters. ViKernel's claim is architectural. If the model is the most capable actor, a stop button that does not travel with the weight file is removable by construction.
[1]What shipped
ViKernel wires what the authors call ROM, RAM, and an xPU circuit into the model weights, then runs a Secure OS on that circuit. The pitch is inversion repair: for fifty years the OS lived in the computer; now, they say, the OS must live in the AI file. External guardrails are described as separable (copy weights, drop wrapper), persuadable (language guardrails can be argued with), and forgetful (host logs can be edited).
Four properties are placed in the weights: the OS boots with the model and locks if a byte changes; actions are allowed or blocked by rule tables, not by conversational judgment; decisions append to a hash chain; anyone can halt, and resume needs a signed operator key. The halt path is presented as non-trainable: not a behavior the model learned, but a circuit the OS enforces. The public demo exposes halt, refused run while halted, refused resume without key, then resume with a demo key.
The OS attaches to an existing LLM or VLM without changing original skills. The demo runs Gemma 4 4B live; Qwen is listed as verified; other families are listed as supported targets. Apps in the demo include a terminal, kill-switch lab, policy engine, leak test, privacy mask, approval-gated app store, audit viewer, and a short allow/deny game. The post says the public demo replays recorded Secure OS responses, and that files, keys, and personal data in it are fictional.
[1]Evidence on the table
Hard public evidence is the demo surface and the asymmetry claim you can try: halt is open, resume is keyed, and a one-byte audit tamper breaks verification in the viewer. That is a product demonstration, not a formal proof about production agents.
The quantitative safety claim is internal: across 661 runs on four open models with mock tools and fake honeypot data, the authors report 0 unrequested outbound transfers. They stress the point is that the number should not depend on the model "behaving well"; policy blocks and the chain records. This is vendor-only evidence. There is no named external auditor, no open red-team report, and no claim that the mechanism survives a determined exporter who obtains base weights without the OS envelope.
[1]Steelman and gaps
Steelman. Hugging Face blogs are a distribution channel for early demos. "OS inside the weights" can mean many engineering things, from truly inseparable circuits to a bundled runtime that still separates under export. Regulators asking "can we stop it every time" may still need host-level kills when the process is compromised below the model file. A signed resume key is only as strong as key custody. The 661-run figure can be a tuned scenario.
Fair. The structural critique of separable wrappers is older than this demo and still under-answered in agent deployments. The falsifiable tests are concrete: can a third party export a runnable model that retains capabilities while dropping halt and audit, and can red teams induce disallowed tool calls that neither block nor append to the chain? If either succeeds, the "inside the weights" slogan fails.
[1]Who should care, and what to watch
Teams shipping tool-using agents in finance, health, or infrastructure should ask vendors where stop, policy, and audit live after a weight file leaves the original host. Model hosts and open-weight distributors should decide whether "safe build" means a wrapper README or an inseparable control plane. Policymakers writing assurance questions should prefer mechanisms that survive copy-out over chat filters that do not.
Next six months: whether independent labs reproduce or break the halt/audit story on the public demo and later releases; whether major open-weight lines ship optional ViKernel-like envelopes; and whether any regulator cites in-weight stop/audit as an assurance criterion rather than prompt policy alone.
[1]Close
ViKernel is easiest to hype as a magic safe model. Six months out, either stop and audit still travel with exported weights under adversarial export tests, or the piece ages into another wrapper story wearing kernel vocabulary.
[1]