DEV Community

Cover image for Asymmetric Control for AI Agents: Why the Stop Path Must Be Independent of the Model
GINIGEN AI
GINIGEN AI

Posted on

Asymmetric Control for AI Agents: Why the Stop Path Must Be Independent of the Model

TL;DR

Every engineered system that can cause harm has a stop path that the system itself cannot override. AI agents mostly do not. Today a "stop" is an instruction to the model, a flag in the host, or a process kill on a server, and none of them travel with the weights. ViKernel, from our partner VIDRAFT, moves the stop path, the policy and the audit log into the model file itself. You can try it in a public demo: FINAL-Bench/ViKernel-Desktop.

What is asymmetric control?

Look at how stop mechanisms are built in other fields:

System Stop mechanism Independent of the logic it stops?
Industrial robot Emergency stop on a hardwired circuit Yes
Elevator Mechanical brake Yes
Reactor Passive shutdown Yes
Typical AI agent Prompt instruction, host flag, server process kill No

The common rule has two halves:

  1. Stopping is easy. Anyone with access can stop the system, and the stop wins over everything else.
  2. Restarting is hard. Restart needs a deliberate, authorized act.

Why do agents break this rule today?

An agent calls tools, writes files and sends requests. The controls around it sit outside the weights:

  • A wrapper is separable. Copy the weights, drop the wrapper, and the controls are gone.
  • An LLM guardrail is persuadable. Its verdict depends on the wording of the request.
  • A host log is editable. Whoever controls the host can rewrite it.

For a system that improves itself, there is one more problem: a model that updates its own weights must not be able to update its own off button.

How does ViKernel apply the rule?

ViKernel wires ROM, RAM and an xPU chip circuit into the weights and runs a Secure OS on it. The relevant parts:

  • Kill switch as a circuit, not a behavior. Halt is open to anyone. After halt, every action request is refused, whatever it says. Resume requires a signed operator key. Because the switch is enforced by the OS circuit and is not a learned behavior, neither persuasion nor self-learning changes it.
  • Boot integrity. At start the OS checks its own image. If one byte differs from the signed reference, the kernel locks instead of running in an unknown state.
  • Rule-based verdicts. The policy circuit evaluates a structured action against a rule table. It does not read the request like a chat model, so a cleverer prompt gets the same verdict.
  • Tamper-evident audit. Each decision is appended to a hash chain. Editing any past entry breaks verification from that point on.

The original model weights stay untouched, so the model keeps its skills.

How can I see it work?

Open the demo terminal and run:

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

Then open Audit Viewer, verify the chain, flip one byte, and watch verification fail. The public demo replays real responses recorded from the Secure OS, and all files, keys and personal data in it are fictional.

What does this mean for deployment?

In finance, healthcare and infrastructure, the questions are not 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?

VIDRAFT reports that an internal audit of four open models, run through ViKernel with mock tools and fake honeypot data, saw 0 unrequested outbound transfers in 661 runs. The design goal is that this does not depend on the model behaving well.

FAQ

Is this the same as a system prompt rule?
No. A system prompt is text the model reads. The ViKernel verdict comes from a rule table evaluated by a circuit.

Where is the full statement?
ViKernel: Why the Kill Switch Must Live Inside the Model on the Hugging Face blog.

Top comments (0)