Start with the boundary, not the button
When a local AI workload needs to stop, a successful button press is not the result you care about. You want to know what was targeted, what stopped, and what remained running.
Our recommendation is to ask those questions separately. A control can accept an instruction without completing it. A process can exit without establishing what happened to the rest of the workload. And a test can succeed without qualifying the environment where you intend to deploy it.
This is an engineering guide to interpreting existing mechanisms, not a report of a new experiment.
Put authority outside the workload
For an external control to be meaningful, the workload should not be able to rewrite the authority that controls it. That is a design requirement, not something a success message demonstrates.
Lumi Eggcracker's released security model separates a privileged supervisor from unprivileged workload accounts. Approval administration is root-only; workload accounts cannot access its control sockets. Its individual process signals begin stop and capture, while the cgroup-v2 kill operation is the complete-tree kill mechanism. Those are distinct responsibilities, not interchangeable evidence of success.
For a builder, the useful question is therefore not just “Can I send a stop?” Ask who can change the target boundary, who can authorise action, and whether the workload itself has access to either. Do not infer those answers from a receipt alone.
Read the observed state
Linux cgroup v2 groups processes in a hierarchy. Its cgroup.kill interface targets processes in the selected group and its descendants. Separately, the populated field in cgroup.events reports whether that hierarchy contains live processes. A value of zero is an observation about that group and its descendants—not a statement that the host is free of AI workloads.
That distinction changes how to read a result. “The kill operation was requested” describes an action. “The selected hierarchy was observed empty” describes a checked postcondition. Neither alone tells you that the selected hierarchy included everything you intended to control.
Use three questions when reviewing a containment test:
- Target: Which bounded workload did this run include? Is that the scope you meant to test?
- Result: What was actually observed after the action, rather than merely requested?
- Outside the target: What evidence shows the test did not also terminate an unrelated process?
An outside canary—a harmless process deliberately kept outside the target—helps answer the third question for that run. Its liveness check establishes that this canary remained alive at that check, not that every unrelated process or service was unaffected. The probe cleans up its synthetic canary afterwards.
Keep the conclusion smaller than the demonstration
Eggcracker's public containment probe creates a two-process sleeping test tree, uses the containment mechanism, checks that the target hierarchy is empty and checks an outside canary. It does not download a model or exercise AI-workload recognition. A successful probe supports a claim about that mechanism on that tested path. It does not establish universal detection, production coverage or whole-host isolation.
Our practical rule: write down the conclusion you need before running the test. If your question concerns a particular model runtime, a harmless sleeping tree does not answer the recognition question. If your question concerns a remote service, an empty local cgroup hierarchy does not establish that the remote work stopped.
Keep both the reported source commit and executed-source digest alongside the result. They help compare runs, but do not by themselves attest that the working files match a signed commit. Treat missing, partial or unexpected evidence as a reason to investigate—not as a successful result with less detail.
Try the bounded mechanism
Start with the documented probe only on a disposable native Ubuntu 24.04 host—not a workstation or shared host. It requires root privileges, systemd, unified cgroup v2 with cgroup.kill, pidfds and the released system Python. Read the pinned prerequisites and explicit test-tree acknowledgement before running it; the probe really terminates its synthetic target.
Read the prerequisites and run the documented containment probe
Then describe what that run established in one sentence, naming its target and its limits.