ViKernel: Why the Kill Switch Must Live Inside the Model

VIDRAFT · Weight-Native OS · Demo v0.1

"For 50 years, the operating system lived inside the computer. Now the operating system lives inside the AI."

ViKernel Desktop, the public demo. The menu bar shows the kernel state, boot integrity, the head of the audit chain, and the 🛑 KILL / ▶ RESUME controls. The panel on the right shows what lives inside a single model file.

Try it: FINAL-Bench/ViKernel-Desktop

1. The paradigm shift: from model as program to model as machine

For half a century, the stack has had a clear shape. Hardware at the bottom, an operating system above it, and applications on top. The operating system was the layer that decided who could do what, kept records, and could stop any process at any time.

Large models broke that shape. Today an LLM or VLM does not run inside a controlled program. It drives programs: it calls tools, writes files, sends requests, and chains actions on its own. The model has become the most capable actor in the system, yet every control over it still sits outside it, in wrappers, proxies, and prompt filters.

That is an architectural inversion. The most powerful component has the weakest boundary.

ViKernel corrects the inversion. It wires ROM, RAM, and an xPU chip circuit directly into the weights of the model, then runs a Secure OS on top of that circuit. The operating system is no longer a neighbor of the model. It is part of the model file itself.

2. Why external guardrails are not enough

External controls share three structural weaknesses.

As agents gain more tools and more autonomy, each weakness becomes a deployment risk. A safety layer that can be removed, talked around, or rewritten is a policy, not a guarantee.

3. Four properties, all in the weights

ViKernel places four functions where they cannot be separated from the model.

The design principle is simple: decisions are made by rule, not by conversation. The policy circuit does not read the request the way a chat model does. It evaluates a structured action against a rule table. A cleverer prompt produces the same verdict, because the verdict was never a matter of language.

4. The kill switch is the foundation, not a feature

Every serious engineered system that can cause harm has a stop mechanism that the system itself cannot override. Industrial robots have emergency stops on a hardwired circuit. Elevators have mechanical brakes. Reactors have passive shutdown. In each case the stop path is independent of the logic it is stopping.

AI has lacked this. A "stop" today is usually an instruction to the model, a flag in the host, or a process kill on a server. None of them travel with the weights.

ViKernel's kill switch follows the engineering rule of asymmetric control:

• Stopping is easy. Anyone with access can halt the kernel. Once halted, every action request is refused, whatever its content.
• Restarting is hard. Resuming requires a signed operator key. Without it, the kernel stays halted.
• The switch is not trainable away. Neither persuasion nor self-learning can change this switch, because it is not stored as behavior the model learned. It is a circuit the OS enforces.

This asymmetry matters most for systems that improve themselves. A model that updates its own weights must not be able to update its own off button. Placing the switch in a protected circuit, verified at boot, is how that separation is kept.

You can try the full cycle in the demo terminal:

vsh> halt
vsh> run weather          # refused: kernel halted
vsh> resume               # refused: key required
vsh> resume --key vikernel-demo
vsh> run weather          # allowed again

5. Integrity and audit as first-class OS functions

Two more functions turn the kill switch from a button into a system.

Boot integrity. At start, the OS checks its own image. If the image differs from the signed reference by a single byte, the kernel locks itself instead of running in an unknown state. The menu bar in the screenshot shows Boot OK and a verified chain head.

Tamper-evident audit. Every decision, allowed or blocked, is appended to a hash chain. Each entry commits to the one before it. Editing any past entry breaks verification from that point onward. In the demo's Audit Viewer you can verify the chain, flip one byte, and watch verification fail.

Together these give operators what regulators and security teams ask for: a model that proves it is the model you approved, and a record of what it did that no one can quietly rewrite.

6. Plugs into any model, without changing what it knows

ViKernel attaches to an existing LLM or VLM. The original weights stay untouched, so the model keeps its original skills. The OS adds control, not retraining.

The demo shows Gemma 4 · 4B live. Qwen is verified, and Llama, Mistral, DeepSeek, Phi, GLM, Kimi, Nemotron, gpt-oss and others are supported targets.

In an internal audit of four open models, run through ViKernel with mock tools and fake honeypot data, we observed 0 unrequested outbound transfers across 661 runs. The point of the kernel is that this number does not depend on the model behaving well. If a model does try, the policy blocks the action and the chain records it.

7. What the demo lets you do

The public demo replays real responses recorded from the Secure OS. All files, keys and personal data in it are fictional.

8. Why this matters now

Agents are moving from chat windows into production systems: finance, healthcare, infrastructure, defense. In those settings, the questions are not about benchmark scores. They are:

• Can we stop it, every time, regardless of what it says?
• Can we prove it is the version we approved?
• Can we show what it did, with a record no one can edit?

When the model is the machine, those answers have to live in the machine. Now every AI carries its own operating system and kill switch.

VIDRAFT · vidraft@mail.vidraft.net · vidraft.net

Model names are trademarks of their respective owners.