
KNOX: Hardware-assisted Regulatory Sandbox for Generative Models
KNOX is a regulatory sandbox for generative models that runs AI workloads inside trusted execution environments (TEEs). For agentic workloads, it derives an attested policy manifest from the user prompt (applicable regulations, expected tool calls, permitted system calls). An attested reference monitor checks each action against it, and an attested execution graph records every action and verdict. Overhead is under 1%.
What it claims
KNOX is a regulatory sandbox for agentic LLM workloads, prototyped on Intel TDX confidential VMs with NVIDIA H100 GPU TEEs. Its four design requirements come from the EU AI Act (Articles 57 and 78): compliance, confidentiality of model weights from regulators, tamper-resistant evidence, and scalability to multi-task and multi-agent setups. The authors (Vector Institute and University of Waterloo, October 2026) report that KNOX checks compliance with GDPR and HIPAA and detects unauthorized tool and system calls, such as those caused by prompt injection, with attestation overhead under 1%. Their comparison table says no prior class of work meets all four requirements. That class includes agent sandboxes, information-flow control, contextual integrity, CFI-style prompt-injection defenses, formally verified agents, and agents in TEEs.
How it works
The agent follows a planner/executor split. A planner turns the prompt into an ordered sequence of expected tool calls, and a separate executor carries them out. Agent control logic runs inside a TDX trust domain, and LLM inference runs in the H100 GPU TEE.
For each prompt, KNOX builds an attested policy manifest (APM). It holds the applicable regulations, the expected trajectory T = ⟨e1..en⟩, a system-call manifest for the authorized tools (permitted syscalls, paths and limits, under least privilege), and stop conditions such as timeouts, maximum attempts or user interrupts. The APM is a set of four guards:
- Regulation guard: a fixed judge model evaluates it, because regulation text needs semantic reasoning rather than fixed rule matching.
- Trajectory guard: a check on the tool-call order, analogous to control-flow integrity.
- System-call guard: a check on syscalls against the authorized set.
- Stop guard: a check on run state.
The attested reference monitor (AttRM) turns each executor tool call into a five-element action tuple. It tests that tuple against the guards covering the action and returns ALLOW or BLOCK before the action runs. The authors also frame data-flow integrity as a gap in prior work: the tool calls can be correct while the arguments passed to them differ.
Each action and verdict becomes a node in the attested execution graph (AEG). Nodes carry measurements, commit sequence numbers and a hash chain, plus a structure root over the graph topology. The model weights are bound as a hash. TDX remote attestation signs this evidence, so several regulators can verify it independently without trusting each other or the developer.
flowchart LR
P[User prompt] --> PL[Planner]
PL --> APM[Attested policy manifest]
EX[Executor action] --> RM{AttRM checks guards}
APM --> RM
RM -->|ALLOW| RUN[Tool / syscall runs]
RM -->|BLOCK| STOP[Action blocked]
RUN --> AEG[Attested execution graph]
STOP --> AEG
AEG --> V[Multiple regulators verify quote]
subgraph TEE[TDX trust domain + H100 TEE]
PL; APM; EX; RM; RUN; STOP; AEG
endEvidence
The evaluation covers workloads with interrupts and three settings: single task with a single agent, multiple tasks with a single agent (including interleaved tasks), and multiple tasks with multiple agents. The fetched text ends before the evaluation sections. It gives no detection rates, attack benchmarks, judge-model identity or baseline overheads beyond the "<1%" figure for attestation.
Limits
- Threat model: the adversary controls only external sources the executor reads. The planner and executor are assumed to be open-weight models from trusted sources, so a malicious or backdoored model, or a compromised planner, is outside scope.
- Trust anchors: physical attacks are out of scope, and verifiers must trust Intel and NVIDIA attestation keys.
- Judge model: the regulation guard depends on the judge model's judgement, and the page does not report its accuracy.
- Regulations: only GDPR and HIPAA are named.
- Hardware: the prototype needs TDX-capable CPUs and H100 confidential computing.
- Code: the code is not yet released. The paper says it "will be publicly available upon publication."
Organisations named here
- arXiv
Technologies named here
- KNOX
- Trusted execution environments
- LLM
- trusted execution environment
Techniques named here
- Attested policy manifest
- Attested reference monitor
- Attested execution graph
- Regulatory sandbox requirements
Related in research



