Threat Model#

This page is under active drafting. The placeholder below reflects the boundary the threat model will be written against, not the final content.

In scope#

ANNIE is designed to protect against:

• Unsafe model output reaching real-world actuators. Even if the underlying model produces a harmful intent, the safety kernel must reject it before any external system observes it.
• Silent hardware faults producing plausible-looking output. Memory access faults, arithmetic exceptions, and other compute-unit failures must trigger a halt before the corrupted result can propagate.
• Tampering with the audit log. Any modification to historical ledger entries must be detectable by an independent verifier.
• License bypass. The daemon must refuse to run without a valid, binding-matching license.
• Long-tail latency excursions. The control loop must complete inside its documented budget, every iteration, or the deployment must refuse to start.

Out of scope#

ANNIE does not protect against:

• Bugs in the integrating application. If your application takes a kernel-approved decision and misuses it, ANNIE has done its job and your application has not.
• Side-channel attacks against the host (timing, power, electromagnetic). These belong to the hardware-level threat model.
• Compromise of the operator’s offline license-issuance machine. That is a runbook concern, not a runtime concern.
• Adversaries with physical access to the deployment hardware. Physical security is a deployment-environment concern.

Independent verification#

The annie verify tool, shipped with every install, walks the ceremony audit log and reports tampering at row-level granularity. It does not phone home and does not require our cooperation.

Full threat-model writeup landing soon.