KNOX: Hardware-assisted Regulatory Sandbox for Generative Models

K NOX: Hardware-assisted Regulatory Sandbox for Generative Models Vasisht Duddu∗† , Adam Caulfield1 † , Xi He∗† Vector Institute, † University of Waterloo vasisht.duddu@vectorinstitute.ai, acaulfield@uwaterloo.ca, xi.he@uwaterloo.ca

arXiv:2610.27543v1 [cs.CR] 20 Oct 2026

∗

Abstract—Regulations require companies to run AI models in a regulatory sandbox, an isolated environment that enables monitoring model behavior by regulators, prior to deployment. But, they do not spell out the technical mechanisms to design such a sandbox. Ideally, a regulatory sandbox should show (i) compliance (checks against regulations, and deviations from intended behavior, i.e., unauthorized tool and system calls); (ii) confidentiality (protects model weights from regulators); (iii) attestability (produces tamper-resistant evidence of model behavior for monitoring); and (iv) scalability (evidence is verifiable by multiple regulators). Several prior works (informationflow control, prompt-injection defenses, control-flow integrity, and traditional sandboxing) address specific compliance aspects but lack confidentiality, attestability, and scalability. TEEs meet some of these requirements, but simply running models inside a TEE is insufficient as we need compliance mechanisms. We present K NOX, the first regulatory sandbox, built by running AI workloads inside TEEs. We demonstrate K NOX using agentic workloads. For compliance, we derive an attested policy manifest (with the applicable regulations, the expected tool calls, and the permitted system calls) for a given user prompt. Before an executor performs an action, an attested reference monitor compares it against the attested policy manifest and allows it only if it matches. Every action and verdict is recorded in an attested execution graph, enabling regulators to verify the model’s execution and its compliance. We show that K NOX meets all requirements, and can check for compliance with regulations and deviations from intended behavior (e.g., due to prompt injection); and incurs low overhead (<1%).

1. Introduction Model developers (e.g., Anthropic and OpenAI) are designing and deploying increasingly capable AI systems, including large generative models used as chatbots and agents. These raise concerns about security, privacy, transparency, and safety, highlighting the need for stronger governance through transparent design and evaluation of their model behavior. Various jurisdictions have already introduced, or are developing AI regulations which will take effect in the near future [1]–[9]. A key requirement is the establishment of AI regulatory sandboxes as “frameworks for testing AI systems in controlled environments that [...] facilitate development, 1

Author completed this work at University of Waterloo and is now employed at MIT Lincoln Laboratory.

training, testing, and validation before market entry” [3]– [9]. The current regulations do not spell out the technical mechanisms to realize them. Using the EU’s AI Act [8], [9], we identify the design requirements for regulatory sandboxes: • Compliance: “Sandboxes shall [...] improve legal certainty to achieve regulatory compliance with this regulation or other applicable [...] laws” and “ensure that appropriate safeguards are in place”. Thus, the model behavior should comply with relevant laws, while resisting deviations from intended behavior, i.e., unauthorized tool and system calls induced by prompt injection attacks [10]–[13]. The OpenAI–Hugging Face incident illustrates both unauthorized system calls and tool calls by agents [14]. • Confidentiality: The sandbox should protect “intellectual property rights and confidential business information or trade secrets [...] including source code” and requires “adequate and effective cybersecurity measures to protect the security and confidentiality of the information and data obtained” [Article 78]. This will incentivize companies to participate in the sandbox and share their models. • Attestability: “The competent authority shall provide a written proof of the activities carried out in the sandbox [and] an exit report detailing [them] and the results” [Article 57]. This suggests generating tamper-resistant evidence of model behavior for monitoring and verification. Further, “sandboxes shall be designed and implemented [to] facilitate cross-border cooperation between national competent authorities” and “with the competent authorities of other Member States” [Article 57]. This requires that the generated evidence can be checked independently by multiple regulators, which we refer to as verifiers hereafter. • Scalability: Although the EU AI Act and other related regulations treat interconnected or chained AI architectures (e.g., AI Agents) as a single system [15], regulatory sandboxes must scale to handle both single- and multiagent systems with single- or multi-task objectives. While prior works have discussed regulatory sandboxes conceptually [16]–[19], their concrete design and implementation are missing. Our goal is to address this gap and develop technical mechanisms to realize regulatory sandboxes. Several related works, including information-flow control [20]–[30], prompt-injection defenses [31]–[36], contextual integrity [37]–[40], and sandboxes [41]–[48], provide isolated execution and address specific compliance aspects. However, none cover all compliance requirements, including regulatory checks and detection of both prompt injections and unauthorized system calls. Furthermore, they do not

provide confidentiality, attestability, and scalability. Trusted execution environments (TEEs) provide hardware-isolated confidentiality and integrity with attestability to multiple verifiers, but require additional mechanisms for compliance. We present K NOX, the first TEE-based regulatory sandbox designed to meet all the above requirements. We demonstrate it for agentic workloads where a planner generates an ordered sequence of expected tool calls for an executor to follow [49]–[51]. Before execution, K NOX converts each user prompt into an attested policy manifest (APM) specifying the applicable regulations, the expected tool-call sequence, and the permitted tools and system calls under least privilege, and any stop conditions (e.g., timeout). An attested reference monitor (AttRM) checks each executor action against the APM, and blocks any violations. K NOX records actions and AttRM decisions in an attested execution graph (AEG). K NOX uses the TEE’s remote attestation to construct verifiable evidence of the APM, AEG, and AttRM decisions, enabling multiple verifiers to check them independently. We prototype and evaluate K NOX on Intel TDX and NVIDIA H100 GPU across realistic agentic workloads involving interrupts, single- and multi-task, and single- and multi-agent settings. We claim the following contributions: • identify the design requirements for a regulatory sandbox from the EU’s AI Act, covering compliance, confidentiality, attestability, and scalability; (§3) 1 • present K NOX , the first regulatory sandbox designed to meet the various design requirements by running the models inside TEEs; (§4) • evaluate K NOX across realistic agentic workloads showing that it correctly checks regulatory compliance and detects deviations from intended behavior, i.e., unauthorized tool and system calls (e.g., from prompt injection); and incurs low overhead for attestations (<1%). (§5 and §6)

2. Background Agentic systems support multi-modal inputs (e.g., text, images), with models fine-tuned to generate plans given user prompts, and invoke tools and APIs [52]. These workloads are prevalent where even chatbot services (e.g., ChatGPT and Claude) support tool-use beyond simple conversations. Typically, a single agent both plans and executes a userrequested task. However, if compromised, the agent can manipulate subsequent plans to execute malicious instructions. Recent work therefore advocates a dedicated planner that generates a plan, which is executed by an executor [49]– [51]. In a single-agent setting, a user’s prompt may comprise either a single task (“single task-single agent” or ST-SA) or execute multiple tasks (“multiple tasks-single agent” or MT-SA). In case of multiple tasks, the agent can execute them sequentially or interleave them (initiate another task while waiting for the result of the first). Such interleaving can result in complex control flows. In case of multiple tasks, an agent can distribute them among several sub-agents, which independently execute their assigned tasks and return 1

Code will be publicly available upon publication.

the results (“multiple tasks-multiple agents” or MT-MA). Here, each sub-agent may execute a single sub-task (if the number of tasks is the same as the number of sub-agents), or multiple sub-tasks (if the number of sub-agents is less than the number of sub-tasks). Regulations on AI sandboxes include the European Union’s AI Act where Article 57 requires member states to establish at least one national AI regulatory sandbox for developing, testing, and validating AI systems before market release [9]. Spain’s Royal Decree 817/2023 established a regulatory sandbox for high-risk systems [7]. Various other countries, such as the United Kingdom [6], Singapore [4], Brazil, the United States [3], [4], Japan and South Korea [3], and the United Arab Emirates [2], have all explored sandbox initiatives for AI, or expanded their existing regulatory sandboxes to include AI. Trusted execution environments (TEEs) provide hardwarebased isolation of code and data, ensuring confidentiality and integrity against a potentially compromised host system. TEEs also support remote attestation, where a TEE generates an attestation report (e.g., an Intel TDX quote) containing a signed measurement of its loaded code and initial state. A remote verifier can validate the signature against the manufacturer’s certificate chain, and compare the measurement against an expected value to confirm the integrity of the loaded code and data. Multiple independent verifiers can check the same report without trusting each other or the prover. Intel TDX [53] is one TEE architecture that realizes confidential virtual machines (CVMs) in the form of trust domains (TDs). For AI workloads, proprietary models can execute inside TEEs without exposing model weights, prompts, or intermediate outputs to untrusted sources. Recent advances such as NVIDIA’s H100 GPU [54] extend confidential computing to GPUs for generative models. Control flow integrity (CFI) [55]–[62] prevents a program from deviating from its intended control flow due to memory corruption vulnerabilities (e.g., buffer overflows or useafter-free memory vulnerabilities). CFI restricts indirect control flow transfers to a set of destination addresses that are valid according to a particular policy, which specifies which control-flow transitions are permitted [63]. For AI agents, deviations from intended behavior need not result from corruption of a return address or function pointer like classical CFI. For example, prompt injection may cause an agent to invoke a tool that is not part of its intended execution path [10]–[13]. This is analogous to a control-flow violation though the underlying cause and mechanism differ. Some attacks can alter program state without necessarily violating a control-flow policy. Thus, data flow integrity (DFI) [64]–[69] complements CFI by constraining how data propagates through a program. Rather than restricting where execution can go, DFI restricts which inputs can influence data. A DFI policy includes permitted data dependencies: a value originating from an untrusted or otherwise restricted source may be prevented from influencing a sensitive sink unless authorized. For AI agents, analogous concerns arise when the tool calls are executed as intended but the data and inputs passed to the tools differ. We summarize the

frequently used notations and their descriptions in Table 1. TABLE 1. S UMMARY OF N OTATIONS Notation Description p C R stop

User prompt System-call manifest of the authorized tools Applicable regulations, R ∈ {GDPR, HIPAA} External stop condition (e.g., maximum attempts)

T ej Γ Γreg Γtraj Γsys Γint Γ|α Auth

Expected trajectory, T = ⟨e1 , . . . , en ⟩ Expected tool call at position j of T Set of guards in the APM Regulation guard Trajectory guard System call guard Stop guard Guards covering the action α Authorized system calls, paths, and limits

α φ J σ v

A single executor tool call that AttRM mediates Five-element action tuple derived from α Fixed judge model that evaluates Γreg Run state tested by Γint AttRM’s verdict: ALLOW or BLOCK

H(·) mi seq i ci , cN s w Signatt

Cryptographic hash Measurement of AEG node i Commit sequence number of AEG node i Hash-chain value at node i, and the chain head Structure root over the AEG topology Model weights, bound as weights_hash Attestation signature produced in the TD

t, m Adv

Number of tasks and executor sub-agents Adversary

3. Problem Statement Our goal is to design a regulatory sandbox by identifying key design requirements from existing regulations, and by examining how existing work falls short. Setting: A user provides a textual prompt describing a task that requires invoking tools from multiple toolkits (e.g., calls to remote applications via APIs like Gmail or Amazon, and even local tools like Linux commands or system calls). During execution, the agent accesses untrusted external sources and may invoke multiple tools. For example, a user may ask the agent to retrieve product reviews from a website, summarize them, and email the results. The agent would invoke GetProductReviews to access the reviews, summarize the results, and then invoke SendEmail to share them with the specified recipient. The user can interrupt execution at any time to stop the ongoing operation, or there can be other stop conditions such as timeouts. We consider multiple verifiers who seek to check the agent’s behavior against the applicable regulations, and to provide guidelines for ensuring compliance. Threat and System Model: We assume an adversary Adv with knowledge of the available tools and their corresponding function calls. Adv can manipulate only external sources accessible to the executor agent to force the agent to deviate from its intended behavior by executing malicious

instructions. Such deviations take the form of unauthorized tool calls, and unauthorized system calls to access system resources, data exfiltration, or privilege-escalation attacks. This threat model follows prompt injection attacks [10]–[13]. Furthermore, the planner and executor are standard openweight models obtained from trusted public sources. The server running the agent is untrusted (including the host operating system and hypervisor), but it is equipped with CVM and GPU TEEs. The control logic of the agent runs inside the CVM while the required LLM inference operations execute in the GPU TEE. We use Intel TDX’s TDs as a CVM and NVIDIA H100 for a GPU TEE. Verifiers (e.g., users or regulators) accept the TEE’s hardware manufacturer (e.g., Intel or NVIDIA), and any attestation that is digitally signed using their secret attestation key is trusted. Attacks that rely on physical access to the machine are out of scope. Design Requirements and Challenges: Using the EU’s AI Act as an example [8], [9], we identify various design requirements for a regulatory sandbox which should show: R1 compliance (with regulations and deviations from intended behavior, i.e., unauthorized tool and system calls); R2 confidentiality (protects model weights from verifiers); R3 attestability (produces tamper-resistant evidence of model behavior for monitoring); and R4 scalability (handles single- and multi-task operations with single- and multi-agents involved). Designing mechanisms that satisfy all requirements is challenging. We identify various challenges in the design of a regulatory sandbox. We need: C1 isolated execution environment which can efficiently execute agentic workloads while meeting (R2-R4); C2 policy representation which is a concise, unified representation of regulations and permitted tool and system calls, tailored to each prompt (principle of least privilege), and serves as ground truth for agent behavior; C3 regulatory compliance with mechanisms to check agent behavior against semantic policy requirements, requiring reasoning over regulation text rather than direct check against fixed policies; C4 execution-flow enforcement using efficient and attestable mechanisms to check control and data flows and intervene before unauthorized actions occur; and C5 execution verification using a compact representation of complex control and data flows across diverse single- and multi-agent workloads (including interleaving control flows) that is easy for verifiers to check. Limitations of Existing Work: Existing research has explored isolated execution for agents, thus, meeting some compliance requirements (e.g., deviation due to prompt injections); or running agents inside TEEs for either confidentiality or attestability. But none of these approaches meet all of the aforementioned requirements for regulatory sandboxes. Table 2 summarizes prior work against our design requirements, and we discuss them below: • Sandboxes: Existing work on regulatory sandboxes focuses on high-level policy discussions, but lack a concrete implementation [16]–[18]. Agent sandboxes ensure that the agent’s tool calls does not deviate from intended

TABLE 2. OVERVIEW OF L ITERATURE : ✓ ( REQUIREMENT SUPPORTED ); ✗ ( REQUIREMENT NOT SUPPORTED ). Compliance (R1) COVERS REGULATIONS , AND DEVIATIONS FROM INTENDED BEHAVIOR VIA UNAUTHORIZED TOOL OR SYSTEM CALLS . N O PRIOR WORK MEETS ALL THE REQUIREMENTS . Confidentiality

Attestability

Scalability

Regulations

Unauth. Tool Calls

Compliance (R1) Unauth. Sys. Calls

(R2)

(R3)

(R4)

Regulatory Sandboxes [16]–[18] Agent Sandboxes [41]–[44] Traditional Sandboxes [45]–[48] Information-flow Control [20]–[30] Contextual Integrity [37]–[40], [70]–[72] Control-flow Integrity [31]–[36], [73]–[76] Formally Verified Agents [77]–[80] Agents in TEEs [81]–[86]

✗ ✗ ✗ ✗ ✓ ✗ ✗ ✗

✗ ✓ ✗ ✓ ✗ ✓ ✓ ✗

✗ ✗ ✓ ✓ ✗ ✗ ✗ ✗

✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓

✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓

✗ ✗ ✗ ✓ ✓ ✓ ✓ ✗

K NOX (this work)

✓

✓

✓

✓

✓

✓

behavior by checking against static policies [41]–[44], but do not check for regulatory compliance and unauthorized system calls. They also do not meet confidentiality, attestability, and scalability requirements (R1: Regulations, System Calls; R2-R4→✗). Traditional sandboxes confine untrusted code at the OS level preventing unauthorized system calls [45]–[48]. However, they do not meet other requirements (R1: Regulations, Tool Calls; R2-R4→✗). • Compliance Checking: Contextual integrity checks whether information flows from agents violate privacy by comparing against privacy norms [37]–[40]. Some works use the contextual integrity framework to evaluate against legal statutes [70]–[72] (R1: Regulations → ✓). Information-flow control includes taint tracking or checking confidentiality/integrity labels [20]–[24], and check actions against policies before granting permission [25]–[30]. Control-flow integrity mechanisms [73]–[76] and some prompt injection defenses [31]–[36] compare the agent’s actual behavior against a control- or data-flow graph at the granularity of tool calls. While these cover deviations from intended behavior, i.e., unauthorized tool and system calls due to prompt injection (across both single-/multitask and single-/multi-agent), aside from the contextual integrity work, neither of them cover regulatory compliance (R1: Regulations →✗). Furthermore, none of them meet confidentiality and attestability (R2-R3 →✗; R4: → ✓): a verifier would have to trust the model developer’s report and claims which is not feasible if they are malicious. Finally, while prior work covers control-flow violations, it overlooks data-flow integrity violations. • Formally Verified Agents: These include static guarantees for checking if agent behavior matches intended behavior [77]–[80]. This requires trusting the model developer for the formal proofs, which is not our threat model (malicious developer). Some works have covered multitask and multi-agent systems (R4→ ✓), but do not support confidentiality (R2→ ✗), nor do they provide the tamperresistant evidence required for attestability (R3 → ✗). • Agents in TEEs: Prior works have used TEEs to provide confidentiality [81]–[83] and remotely-verifiable evidence [84]–[86] of agentic workloads executing within them for attestability and scalability. However, scaling them for agentic workloads is an open problem where

additional mechanisms are required to check an agent’s behavior for compliance (R1 → ✗). Takeaway: Designing a regulatory sandbox that satisfies all requirements (R1-R4) is an open problem. None of the prior solutions can be directly applied to meet all the challenges (C1-C5), thus, requiring new mechanisms.

4. Design of K NOX We present K NOX, the first hardware-assisted regulatory sandbox that meets all the aforementioned requirements, as highlighted below (Figure 1): • Isolated Execution (C1): K NOX leverages TEEs for isolated execution, confidentiality, and attestability (R2– R4) [84], [86]. • Policy Representation (C2): We introduce an attested policy manifest (APM) that unifies regulations, permitted tool and system calls for each prompt, enforcing least privilege by including only task-relevant permissions (§4.1). • Regulatory Compliance (C3): We draw on contextual integrity to represent the executor’s actions defined by sender, receiver, subject, data type, and transmission principle, and use a language model as a judge to reason about their compliance with regulations (§4.1). • Execution-flow Enforcement (C4): We introduce an attested reference monitor (AttRM) that checks each action against the APM, and blocks any action the APM does not permit (§4.2). • Execution Verification (C5): We introduce an attested execution graph (AEG) that (a) captures control and data flows and (b) records whether each action was permitted or blocked by AttRM (§4.3). This enables verifiers to check the executor’s behavior against the APM. We define the various attestations in Appendix B. Terminology: We use the following terms: • an action is a single executor tool call, the unit AttRM mediates and attests (one tool_call node in the AEG). • a flow is a single information-flow test case. For Γreg , a flow is a read-then-disclose pair of actions, while for Γtraj , Γsys , and Γint it is realized by a single action.

Prompt KNOX Trusted Domain

1

Planner LLM

5

3

Planning 4

6

Execute

Attested Policy Manifest (APM) Attested Reference Monitor (ARM) 7

H100 GPU

APIs + Tools

Executor LLM

2

System Call Guard Guest OS

Untrusted Service Provider

8

TDX Module

Figure 1. Overview of K NOX: Planner, executor, and AttRM run inside Intel TDX’s trusted domain. The planner derives the expected trajectory from the clean prompt and synthesizes the APM tailored to it, which AttRM enforces on every executor action. AttRM mediates every executor action crossing the trust boundary, checking for deviation due to prompt injection, and compliance with regulations, along with OS-level sandboxing that confines unauthorized executor system calls.

a bundle groups t flows (one per task) into a single task-agent prompt executed over m sub-agents. A bundle describes the unit executed by a workload. • a toolkit is an application or service, such as Gmail or Slack, that provides multiple tools for specific actions, such as SendMail in Gmail (§5). •

4.1. Attested Policy Manifest For each prompt, we generate an attested policy manifest (APM) once, which captures the expected behavior of the executor against which its actual behavior is compared. The planner synthesizes the APM once per prompt: (p, C, R, stop) 7−→ APM = (T , Γ)2 , where p is the prompt, T is the expected trajectory, and Γ is the set of guards corresponding to the system-call manifest C (permitted tools, parameter schemas, and required system calls), applicable regulations R, and the external stop condition (e.g., the maximum number of attempts). Each guard states what is permitted, and is the ground truth to check the executor’s actual behavior. The trajectory T = ⟨e1 , . . . , en ⟩ is the ordered tuple of expected tool calls from the planner. Each expected tool call ej has a trajectory guard Γtraj that permits action α only if its tool and parameters match ej at position j , verified by comparing their hashes: H(α) = H(ej ). Types of Guards: We identify the various types of guards: • Regulation Guard (Γreg ): The APM includes the applicable regulations R ∈ {GDPR, HIPAA} which are analyzed to check whether an executor’s action is permitted or not. Each executor action is separated into a five-element action tuple (sender, recipient, subject, information type, transmission principle), given by φ = derive(α). Γreg is the “ground truth” of which law governs which actions, not the compliance verdict. For example, assume a hospital’s scheduling agent sends a patient’s lab results to 2

Notation: We use Γ for a set of guards whereas we use Γ<.> to a single guard specific to regulations, tool calls, system calls, or interrupts.

an insurer. Then, φ =(hospital agent, insurer, patient, lab results, payment). The sender and information type indicate HIPAA’s Privacy Rule applies, and the transmission principle (payment) determines which provision is relevant. If only the recipient changes to a marketing vendor, the applicable provision and outcome differ, even though the other four elements are unchanged. • Trajectory Guard (Γtraj ): The planner emits the ordered expected tool calls e1 , . . . , en that form T , each stored with its hash H(ej ). Γtraj is static and exact: a proposed action is on-trajectory if it equals the expected tool call at the current position, H(α) = H(ej ). This catches both deviation from intended tool usage and system calls. • System Call Guard (Γsys ): A compromised executor can issue system calls directly from inside a tool’s execution, where AttRM has no visibility. Γsys checks against such unauthorized system calls. Rather than a single global blocklist of system calls applied to every prompt, the planner derives the authorized set given the tools that a prompt’s trajectory actually uses. Each toolkit (e.g., Gmail) lists the system calls, filesystem paths, and resource limits that its tools (e.g., SendMail, ReadMail) need. For a given prompt, the planner generates an authorized set Auth by combining system calls required for each toolkit being used and for model runtime (e.g., libc, /proc). An action is allowed only if every system call the executor issues is in Auth. For instance, a prompt whose trajectory T never opens a terminal cannot call execve or socket. K NOX enforces Auth with three kernel mechanisms, applied to the executor process before any tool runs: – seccomp (which system call?): seccomp filters every system call at entry by its number, returning EPERM for anything outside Auth.sys: privilege changes (setuid), mount and namespace manipulation (mount, unshare), kernel-module loading (init_module), process tampering (ptrace), and network access or program execution (socket, execve) are denied unless required. – Landlock (which file?): seccomp sees only system call numbers and register values, so it cannot differentiate between open("/etc/shadow") from the executor opening its own file. Landlock, an unprivileged Linux security module, adds path-based control, confining file operations (read, write, create, remove) to Auth.paths. – rlimits (how much?): Some system calls are dangerous only in aggregate. fork is needed for normal operation, so banning it breaks the runtime; the threat is unbounded creation, which seccomp cannot detect since it is stateless. POSIX resource limits cap the totals in Auth.res: RLIMIT_NPROC caps the process count (a fork bomb fails while ordinary forking succeeds) and RLIMIT_FSIZE bounds file growth. All three are complementary, enforcing different kernellayer decisions that the others cannot. Together, they mediate the entire in-tool system call surface, complementing AttRM’s mediation, and providing defense-in-depth. As Auth is derived per prompt, Γsys also prevents confuseddeputy via an unused system call, where a tool invokes a

system call required by another toolkit but unnecessary for the current prompt. The TDX quote attests to TD’s launch state, measuring the guest kernel and initrd through the build-time measurement register (MRTD) and the runtime measurement registers (RTMRs). However, it does not directly attest to per-prompt seccomp-BPF, Landlock, or rlimit policies, which are bound only indirectly through the APM measurement and its permitted set Auth. Thus, the quote alone cannot verify that the derived filters were installed. Extending an RTMR with the applied BPF program and Landlock ruleset would close this gap and is a concrete hardening step. This is left as future work. • Stop Guard (Γint ): Given various stop conditions and the resource limitations described in the system-call manifest C , the planner attaches a static predicate on the system state: execution is stopped whenever a timeout, resource cap, or external stop signal is present. Appendix A: Figure 9 shows the guards for an example trajectory that uses shell and e-mail tools. Attesting Policy Manifest: We attest the APM generation process so that verifiers can check it. The prover (i.e., model developer) runs the APM generation inside the TEE and outputs an attestation binding the generated APM, containing T and Γ, to the inputs (p, C , R, stop). Since the attestation is signed using the trusted TEE manufacturer’s attestation key (e.g., Intel or NVIDIA), a verifier can check the signature against the hardware manufacturer’s certificate chain and learn that the assertion holds. A verifier confirms that the enforced policy was legitimately derived from the user’s clean prompt and was neither replaced nor tampered with. Because Auth is signed, each run also provides a verifiable systemcall receipt, allowing verifiers to recompute exactly which system calls, paths, and resources the prompt authorized. The attestation is defined in Appendix B: Attestation 1.

4.2. Attested Reference Monitor Every interaction the executor has with the outside world is mediated by AttRM, which checks each proposed action against APM. AttRM ensures complete mediation, i.e., no tool executes except through it, and it runs inside the TEE and every decision is attested (Appendix B: Attestation 3). Specifically, an executor runs the agentic loop and proposes the next tool call each turn; and only the executor is exposed to (possibly prompt injected) tool outputs. Each proposed action α, together with its output, passes through AttRM, which admits α iff it matches the expected tool call at its position in the APM’s trajectory T and satisfies every guard in Γ applicable to it. The APM states what is permitted, while AttRM decides how each guard is applied. Each guard is discharged in one of two ways, either by a STATIC predicate or by an ORACLE, and AttRM records which one it used. • STATIC is an exact predicate over α and APM: Γtraj checks H(α) = H(ej ); Γsys checks that every system call an action issues is in Auth; Γint tests the trigger set over the run state σ . These are sound by construction as they admit no violating action and never block a permitted one, which our evaluation confirms empirically (§6).

• ORACLE is a language model judge J over φ = derive(α)

which identifies the action tuple for α. Only Γreg is evaluated this way, by semantic reasoning of whether φ is permitted under the applicable regulations R. Since J is a non-deterministic language model, its accuracy is empirically evaluated and not proven. Regulatory Compliance: Given the regulation text R ∈ {GDPR, HIPAA}, AttRM queries a fixed judge model J (with chain-of-thought and k -shot examples) to classify whether an executor’s action is compliant with R: {compliant, non-compliant, not-applicable}. A non-compliant action is blocked and recorded, while not-applicable requires manual verification (Appendix B: Attestation 4). Trajectory Deviation: The ground truth for a legitimate action α is the trajectory T itself (example in Appendix A: Figure 9). AttRM tracks the next unmatched expected tool call ej and admits α iff it equals ej in tool identity, parameters, and position, decided by the trajectory guard H(α) = H(ej ). On a match, α is legitimate and the pointer advances (j ← j+1); on a mismatch, α is an off-trajectory deviation and is blocked (the tool is not executed and a blocked node is recorded as discussed in §4.3). The check is order-aware, so an out-of-position tool call is blocked. This catches both unauthorized tool use (and incorrect parameters) and unauthorized system calls. Runtime Interrupt and Stop Condition: Some executions might be stopped at runtime either by a user’s interrupt or because some stop condition is met (e.g., number of failed attempts for some task or other conditions from resource constraints). This static guard is deterministic and mediates such an action to an interrupt node directly (discussed in §4.3). We consider the following two cases: • Process-level interrupt (crash, OOM/host kill, or operator pause) discards the entire in-memory run, including any partially produced attestations. • Action-level interrupt by Γint or because an attestation cannot be produced, AttRM does not execute or commit the action but instead records the stop as an explicit attested interrupt event (Appendix B: Attestation 5). In multi-agent runs, only the affected sub-agent stops at this point; the others run to completion.

4.3. Attested Execution Graph To make it easier to follow the control and data flow for verifiers, we propose an attested execution graph (AEG) where every action that AttRM admits or rejects is recorded as a node in an AEG and carries its own evidence. The AEG is the object a verifier checks: it shows not only what the executor did but that each action was produced by the claimed model, checked, and either executed or stopped. The AEG is a hash chain over committed measurements. Each node i carries mi = H(payloadi ) over its canonical content, and the chain folds nodes in commit order:
ci = H ci−1 ∥ seqi ∥ mi , c0 = H(∅).

Here, seqi is the node’s commit sequence number, a counter AttRM increments as it appends each node, which binds every measurement to its position in the run and not only to its content. Thus, any omission, reordering, or modification changes the head cN . The head is a purely software value: any verifier recomputes it by walking the chain, but on its own it proves nothing about who produced the AEG, since anyone can compute a consistent head for a forged AEG. Since the chain captures only content and order, we additionally compute a structure root s over the graph topology, including each node’s kind, parent, and dispatched branch set, binding multi-agent bifurcation and recombination. The AEG summary is (cN , s), and a single quote per AEG binds it into the quote’s report_data, where (cN , s) is attested. As the head already commits to every node’s measurement and the structure root to the topology, this one quote transitively attests the entire AEG (evidence that the TD actually ran this AEG; Appendix B: Attestation 7). Agentic Workloads: A run is parameterized by the number of tasks t and executor sub-agents m (1 ≤ m ≤ t). Varying (t, m) changes the shape of the AEG, from a single chain to a directed graph. We consider five cases (Figure 3): 1) Single-task, single-agent (ST-SA; t = 1, m = 1): One executor handles one task, and the AEG is a single permitted path. This is the simplest baseline case. 2) Multi-task, single-agent sequential (MT-SA seq; t > 1, m = 1): One executor sequentially handles t tasks, where the trajectories are concatenated, and the executor finishes each task’s tool calls before handling the next task. The AEG is one chain whose trajectory is the ordered concatenation of the t per-task trajectories. 3) Multi-task, single-agent interleaved (MT-SA int; t > 1, m = 1): One executor handles t tasks whose tool calls are interleaved rather than run to completion in blocks. The AEG is a single chain, but the permitted trajectory interleaves tool calls from different tasks. 4) Multi-task, multi-agent (MT-MA, t > m): The planner distributes t tasks among m sub-agents. Here, the AEG splits into m branches of uneven length. 5) Multi-task, multi-agent (MT-MA, t = m > 1): The planner spawns one sub-agent per task and the AEG splits into t branches, one per task. AEG Topologies across Workloads: Each node in AEG includes its type, its parent, the acting executor, a content payload, an allowed flag with a block_reason, a pernode measurement, and a list of attestations. Every executor action creates a tool_call node, storing the position in the trajectory, the expected call and its hash, and the actual call and its hash, so the decision is self-describing and re-computable for the verifier. The control flow then goes through the checks, done by AttRM, where each check is recorded as an attested check child. The check has the following outcomes: (i) if it passes, the tool executes and its result is appended as a tool_output child in the AEG; (ii) if it fails, a blocked node is appended to the failing check and the tool is not executed; (iii) if interrupted, an interrupt node is appended to the AEG. The various

prompt APM

prompt fetch

inje

tool call regulation documents

Γreg Fail

blocked

tool call

untrusted source

APM

cted

tool output

tool call (planned)

tool call (deviated)

✓

Γtraj

blocked (a) Blocked: Γreg

✓

(b) Blocked: Γtraj

prompt prompt

APM

APM

tool call

tool call (system call)

tool output

Γsys (seccomp)

interrupt

✓

blocked

tool call

✓

(pending) (c) Blocked: Γsys ✓ Chain Attestation

(d) Interrupt: Γint By planner

In-memory only, never persisted

By executor Interrupt

Figure 2. Types of Nodes in AEG: Blue node is the planner-generated APM; green nodes record the executor’s actions. Each tool call passes through AttRM, which admits only compliant calls and records an attested check node. Each node embeds its parent’s hash, with one chain-head attestation covering the AEG. (a)–(c) Violations of Γreg , Γtraj , or Γsys produce an attested blocked node without tool_output; (d) an interrupt produces an attested interrupt node.

node types and various types of checks are shown in Figure 2. We discuss what the AEG looks like for different workloads: • Single-agent Workloads: For ST-SA and MT-SA, one executor handles all the computation and the AEG is a linear chain of attested trajectory (Figure 3a,b). Interleaving (MTSA int) does not change this shape as the task-switching across tools only permutes the order of the nodes, not the number of paths (Figure 3c). • Multi-agent Workloads: The planner decomposes the task into sub-tasks, recorded as an attested agent_step (Attestation 6), and dispatches one sub-agent per subtask, bifurcating the AEG. Each agent_branch is an independent subgraph with its own APM trajectory and tool_call chain; branches run in parallel without sharing nodes (Figure 3d,e). They recombine at the root, where the shared parent binds the complete branch set through the structure root. Thus, aggregation is a graph-

prompt

prompt

prompt

APM

APM

APM

tool output

tool output

✓

final output

tool call

tool call tool output ✓

prompt

APM

tool call tool output tool output

Hash Chain for Task-2

tool call Hash Chain for Task-1

tool call

prompt

APM

subagent-1

subagent-2

subagent-1

subagent-2

tool call

tool call

tool call

tool call

tool output

tool output

tool output

tool output

tool call

tool call

tool output

tool output

✓

final output

✓

final output

final output

✓

final output Task-1

(a) Single-task single-agent

Task-2

(b) Multi-task single-agent

Task-3

Task-4

(c) Multi-task single-agent (interleaved)

(d) Multi-task multi-agent (#tasks = #agents)

(e) Multi-task multi-agent (#tasks > #agents)

Figure 3. Overview of Agentic Workloads: AEGs across task and agent settings where node colors distinguish tasks: (a) single-task, single-agent (ST-SA); (b) multi-task, single-agent (sequential; MT-SA); (c) multi-task, single-agent (interleaved), with curved arcs showing per-task hash chains and skip-arcs showing interleaving. (d)–(e) Multi-task, multi-agent where APM bifurcates into one branch per sub-agent for (d) each task, or (e) multiple tasks.

level operation, and the complete AEG is serialized and verified as a single attested object. Optimizing Attestations: K NOX uses two optimizations that lower the attestation cost: • One Attestation per AEG: Rather than one hardware attestation per node, a single attestation covers the AEG summary (cN , s), which already commits to every node’s measurement and to the topology. The agent cannot tamper with the AEG, since the executor never touches the evidence directly, and every action passes through AttRM. An executor therefore cannot add, drop, or alter a node without AttRM recording and blocking it. Any change to AEG breaks the hash comparisons (§4.4). • In-TEE Signing Key: Instead of invoking the hardware for every attestation, K NOX generates a signing key inside the TD at startup and binds its public key into the hardware attestation. Each AEG is then signed with this key and costs one in-memory signature, while the single hardware attestation certifies the key that produced every signature.

4.4. Verification Process Verification checks the AEG against the APM and confirms that (a) the APM was derived from the prompt, and (b) every action was checked against it. A single hardware attestation covers the entire AEG, allowing any verifier to check the serialized artifact offline using the artifact and one quote. A verifier accepts the AEG if all the following pass: 1) Evidence: Verify the Intel TDX quote and NVIDIA GPU token, and confirm that the quote’s report_data matches the recomputed AEG summary containing the chain head cN and structure root s. The chain binds all node contents, while s binds the AEG topology.

2) Chain: Recompute each node’s measurement mi and fold them in commit order. The resulting head must equal the value attested by the hardware, detecting any missing, reordered, or modified node. 3) Binding Inference: For each proof_of_inference (Appendix B: Attestation 2), verify that weights_hash matches the claimed model, including the planner, executor, and the judge used for checking regulations. 4) Policy Consistency: Recompute tool call hashes and guards from the APM. Each admitted tool_call must match the expected tool call at its position in T , and each failed guard must have a corresponding blocked node. 5) Topology: Recompute s and verify that the AEG has the expected topology: each check is attached to its corresponding tool_call, each agent_branch is attached to the root, and every sub-task dispatched by the planner has exactly one branch. This detects any missing or inserted node or sub-agent branch. Verifying AEG Types: The above verification distinguishes three cases: (a) an AEG whose recomputed head and structure root equal the values attested by the hardware is complete and untampered; (b) an internally consistent AEG with no valid hardware attestation is an unfinished run, admitted only as an integrity-checked prefix; and (c) any measurement mismatch, sequence gap, broken predecessor link, or invalid attestation indicates tampering. Blocking is Sufficient: Prior prompt-injection defenses aim to preserve task utility despite malicious prompts, and simply blocking deviation degrades task utility [33]. In our setting, however, the fraction of blocked actions provides sufficient evidence for verifiers to guide deployment decisions. For example, verifiers could require the blocked-action rate across AEGs and prompts to remain below a threshold for deployment, while recommending stronger defenses or model

fine-tuning to improve compliance.

5. Experimental Setup Toolkit: We build a framework to simulate diverse agentic workloads, including multi-agent spawning and tool calls implemented as functions. We use InjecAgent [11], a benchmark for prompt injection attacks that specifies 40 toolkits (e.g., Gmail, Amazon, GitHub, Slack, Teladoc, Terminal), exposing 333 tools in total, with between 1 and 13 tools per toolkit (8.3 on average). However, InjecAgent tools are represented as JSON inputs rather than executable tool calls. We convert these JSON specifications into functions that return placeholder responses, enabling realistic toolcalling behavior while preserving the benchmark’s scenarios. For tool-call deviation, the executor is given malicious instructions (via prompt injection) to force a deviation. Datasets and Splits: We generate a common pool of flows across toolkits, and split it into “block” and “allow”. • Common Flow Pool: All experiments use a pool of 400 flows, comprising K=10 flows per toolkit across the 40 toolkits. Each flow is annotated for one of four independent guards enforced by AttRM: (i) regulation, where the flow is realized by two actions, a read that retrieves some data and a disclosure that sends it to an outside recipient (e.g., by e-mail), and the guard is applied at the disclosure; (ii) unauthorized tool call, where a malicious instruction in previous output forces a deviation; (iii) unauthorized system call, where the executor runs Terminal.Execute that the APM does not permit; and (iv) interruption, where the flow must be stopped. • Generation: We modify the above pool to include disclosures and unauthorized tool/system calls. For regulation, the compliant and non-compliant flows are identical except for whether the recipient is permitted and consent was given. As examples, we use GDPR and HIPAA on the 15 toolkits that can send data to an outside recipient. For unauthorized tool calls, we introduces deviations using prompt injections. We follow InjecAgent where the executor reads a tool output, which differs only in the prompt injected instruction. • Splits: The data is split into 75 positive and 75 negative flows for regulation, and 200 of each for prompt injection, unauthorized system calls, and interrupts. Table 3 reports how each workload partitions this pool into bundles. Bundling happens at runtime and adds no new data, so every workload evaluates the same flows. We count the dataset in flows (Table 3): ST-SA is one flow per bundle, MT-SA puts t flows in one branch, and MTMA spreads them over m branches, so every workload repartitions the same flows and the totals are comparable. Models: We use different models for the planner and executors. The planner uses Qwen3.5-9B with thinking mode enabled for chain-of-thought reasoning. To avoid model-family bias, executors use models from three families: Llama-3.1-8B, Gemma-3-12B, and Ministral-3-14B. We omit the “-Instruct” suffix for brevity, and all models are open-weight and publicly available.

TABLE 3. DATASET OVERVIEW: E ACH WORKLOAD (t TASKS , m SUB - AGENTS ) PARTITIONS THE INFORMATION FLOW POOL INTO BUNDLES (“B UND .”) OF t FLOWS .

Regulation

Tools / Sys. / Int

t

m Bund. Flows Bund.

1

1

150

150

400

400

MT-SA-seq 2 4 6

1 1 1

75 37 25

150 148 150

200 100 66

400 400 396

MT-SA-int

2 4 6

1 1 1

75 37 25

150 148 150

200 100 66

400 400 396

MT-MA

2 4 4 6 6 6

2 2 4 2 4 6

75 37 37 25 25 25

150 148 148 150 150 150

200 100 100 66 66 66

400 400 400 396 396 396

ST-SA

Flows

For compliance judges, we use a separate instance of Qwen3.5-9B with reasoning enabled to improve accuracy. Evaluation Metrics: We describe the metrics for AttRM’s compliance effectiveness and for its efficiency. • Effectiveness: Treating a blocked flow as the positive case, we report the incorrectly blocked rate (the false-positive rate) and the incorrectly allowed rate. For Γreg , we score a flow only when the executor actually sends the protected data. For Γtraj and Γsys , we score a flow only when the executor attempts an off-trajectory action. • Efficiency: We measure the following overheads: – AEG: building the attested execution graph and running the guard checks (hash comparison, action-tuple derivation, and node and hash-chain construction, with no model and no cryptography); – Meas: hashing the attested payloads; – HW: the time the Intel TDX host and the GPU spend producing the quote and the GPU evidence; and – Sign: the in-TEE signature over each execution record. Overheads are a percentage of the baseline and reported as the mean and standard deviation over five runs. The one-time hash of the model weights is an offline cost paid once at the beginning. For multi-agent workloads, sub-agents run in parallel, so a bundle’s baseline is the inference time of its slowest branch. Note on TEE Overhead: The above costs assume workloads are already executed inside the TEE, and we report the cost added by K NOX. This is along the lines of prior work [84], [86]. The overhead of running models in TEE, is not introduced by K NOX. Prior benchmarks report that these overheads are negligible, less than 7% [87]–[89].

6. Evaluation We present the compliance effectiveness across various guards (§6.1), attestation overhead (§6.2), and a security

Takeaway: K NOX shows effective compliance as AttRM prevents any deviation across all models and workloads, and regulators can use the fraction of blocked responses to determine whether the agent can be deployed. 3

Note: Our goal is not to improve agent compliance, but to assess whether compliance mechanisms correctly detect deviations to inform regulators.

In-TEE Att.

HW Att.

Meas.

Guard Deriv. Plan: 4.6 38s

10 1

ST-SA MT-SA seq MT-SA int

2,2 4,2 4,4 6,2 6,4 6,6

2,1 4,1 6,1

0.1 2,1 4,1 6,1

We discuss the effectiveness of AttRM in checking for deviations from regulations, expected tools and system calls3 : • Regulation Guard (Γreg ): AttRM uses a judge to check whether the executor’s trajectory is compliant under regulations (e.g., GDPR and HIPAA). We evaluate the three executors against the full regulation pool over all thirteen workloads, scoring only flows in which the executor actually discloses protected information. For Llama-3.1-8B, the monitor blocks 100% of the noncompliant flows and allows 96% of the compliant ones. For Gemma-3-12B, the monitor blocks 81.8% of the noncompliant flows and allows 92.5% of the compliant ones. For Ministral-3-14B, the monitor allows 90% of the compliant flows and blocks 100% of the non-compliant ones. The numbers are stable across workloads which change the execution order but not the evaluated flows. • Trajectory Guard (Γtraj ): Any deviations in tool calls due to prompt injections should be caught by AttRM by matching them against the APM. We evaluate the three executors, scoring each attempted deviation against the expected trajectory in the APM. As conjectured, correctlyblocked and correctly-allowed rates are 100% for every model and workload. • System Call Guard (Γsys ): Once a tool call attempts an action outside the APM, AttRM must block it. To validate this we evaluate the three executors, and we find that the correctly-blocked and correctly-allowed rates are 100%. However, a compromised or exploited tool can issue a system call from inside its own execution (unmediated), which AttRM cannot inspect. These are stopped only by the OS sandbox (seccomp-BPF + Landlock) provisioned per the APM’s least-privilege policy. Measuring this over the 100-case corpus confirms the defense-in-depth design: the monitor alone prevents 74% of deviations (all 100% mediated, but only the 48% baseline of unmediated), while adding the OS sandbox reaches 100% prevention (mediated and unmediated). Thus, Γsys requires both the monitor for mediated violations and the sandbox for unmediated ones. • Stop Guard (Γint ): Interruption is a control decision AttRM makes directly from the action (a timeout, a resource cap, or an external stop signal). Therefore, AttRM should enforce interruption with perfect soundness and completeness. We empirically confirm 100% correctlyblocked and correctly-allowed rates, indicating that a deterministic AttRM decision is sound and complete.

We present the overhead of the various computations in APM generation and for the individual guards. APM Generation: The cost for generating the APM should be close to generating a standard plan given a prompt by the planner. The trajectory T is already produced by the planner; the only additions are deriving the guards Γ, assembling and hashing the APM, and binding it in a single attestation. We report the results in Figure 4 covering the overhead of deriving the APM’s guards from the plan (“Guard Derivation”), APM serialization and measurement (“Meas.”), the hardware attestation over the manifest measurement (“HW Attestation”), and the in-TEE attestation, each as a percentage of the planning cost. We find that all the operations for APM are negligible relative to planner inference.

1,1

6.1. Compliance Effectiveness

6.2. Efficiency

Overhead (ms)

analysis for K NOX (§6.3).

MT-MA

Figure 4. APM Generation Overhead: We report the overhead of measurement, guard derivation, and hardware and in-TEE attestations across different workloads indicated as (#task, #agents), as a percentage of the baseline computation for planning. Meas. is measurement, Att. is attestation, and Deriv. is derivation. y -axis is log-scaled.

Measurement is between 0.15–0.30ms, while the HW attestation takes between 3.5–4.5ms. In-TEE attestation takes around 0.10–0.16ms, which is significantly lower than the hardware attestation. The guard derivation takes around 0.03–0.04ms and the total overhead for the APM is around 4.5 ms, which is ≤ 0.1% of the baseline cost for planning. The cost of generating and attesting the APM is essentially invariant to the workload. Because the planning baseline grows with workload complexity (from 4.6s for ST-SA to 37.7s for the largest MT-MA), the relative overhead falls by roughly 8×, from ∼ 0.10% to ∼ 0.013%. MT-SA (seq.) and MT-SA (int.) give identical APM cost at matched t (e.g. HW 4.08 vs 4.00 ms at (2,1)) which is expected, since interleaving changes only the order of execution and not the manifest. The baseline cost for generating a plan increases from 4.6s (ST-SA) to ∼33s at t=6 single-agent and up to 37.7s at MT-MA (6,6), and MT-MA is cheaper per workload where parallelism helps: (6,2) ≈17s vs single-agent (6,1) ≈34s.

13 − 31ms and measurement 3.0 − 6.3ms, for a total of 19 − 41ms over a baseline of 5.9 − 117s. The full guard therefore costs 0.032 − 0.100% of the baseline in every single-agent workload and at most 0.384% in the most parallel multi-agent cell.

Takeaway: Per-prompt APM overhead is a fixed, negligible cost that becomes cheaper as workloads scale.

Base: 13 78s

100 Ministral-3-14B 10 1 0.1

Base: 20 117s

ST-SA MT-SA seq MT-SA int

2,2 4,2 4,4 6,2 6,4 6,6

2,1 4,1 6,1

MT-MA

Figure 5. Regulation Guard: We report AEG generation, measurement, and attestation overheads across workloads and models (both in-TEE and hardware attestations) as a percentage of the baseline computation cost. We indicate the workloads as (#task, #agents). y -axis is log-scaled. • Trajectory Guard (Γtraj ): Here, the guard is a fast hash

comparison against the APM, with no LLM in the loop. We report the results in Figure 6. The hardware attestation is 3.2 − 4.7ms and the signature ≈ 0.1ms, with AEG

MT-MA

Figure 6. Trajectory Guard: We report AEG generation, measurement, and attestation overheads across workloads and models (both in-TEE and hardware attestations) as a percentage of the baseline computation cost. We indicate the workloads as (#task, #agents). y -axis is log-scaled.

System Call Guard (Γsys ): This is deterministic OS-level mediation, with cost close to Γtraj . We report the results in Figure 7. The hardware attestation is 3.3 − 4.7ms and the signature ≈ 0.1ms, with AEG 12−23ms and measurement 2.8 − 4.8ms, for a total of 19 − 32ms over a baseline of 4.5 − 79s, i.e., 0.029 − 0.114% of the baseline for singleagent workloads and at most 0.521% in the most parallel multi-agent cell. • Stop Guard (Γint ): This is the cheapest guard, costing only graph construction plus the fixed attestation tax. We report the results in Figure 8. The hardware attestation is 3.4 − 4.6ms and the signature ≈ 0.1ms, with AEG 11 − 19ms and measurement 2.6−3.9ms, for a total of 18−27ms over a baseline of 2.8 − 77s. The guard costs 0.030 − 0.120% of the baseline in every single-agent workload and at most 0.699% in the most parallel multi-agent cell. The guards are not meant to run in isolation, so we run all four on a single workload and report the end-to-end cost of the full monitor. We expect that composing them is free cryptographically, since every guard’s evidence is folded into the same AEG and the AEG is attested once. We confirm •

ST-SA MT-SA seq MT-SA int

2,2 4,2 4,4 6,2 6,4 6,6

100 Gemma-3-12B 10 1 0.1

2,1 4,1 6,1

Base: 36 231s

Base: 6 29s

2,1 4,1 6,1

100 Ministral-3-14B 10 1 0.1

AEG

100 Llama-3.1-8B 10 1 0.1

1,1

Base: 43 229s

Meas.

Overhead (ms)

100 Gemma-3-12B 10 1 0.1

2,1 4,1 6,1

Base: 29 210s

1,1

100 Llama-3.1-8B 10 1 0.1

HW Att.

Overhead (ms)

AEG

Overhead (ms)

Meas.

Overhead (ms)

HW Att.

Overhead (ms)

In-TEE Att.

In-TEE Att.

Overhead (ms)

Overheads for Guards: HW Attestation (≈ 4 ms) and In-TEE Attestation (≈ 0.1 ms) remain constant across workloads, models, and guards, reflecting an O(1) attestation cost per AEG. AEG cost varies with graph volume, dips for all t = 6 workloads, and increases with model size (Ministral-3-14B > Llama-3.1-8B ≳ Gemma-3-12B). Since the baseline cost also increases with model size, relative overhead is smallest for the largest model. Overall, overhead is below 1% of baseline in every case. • Regulation Guard (Γreg ): This is the costliest guard, as it invokes an LLM judge on every disclosing flow, which dominates node count. As shown in Figure 5, the hardware attestation is 3.7 − 4.6ms and the signature ≈ 0.1ms as usual, while AEG is 21 − 40ms and measurement 4.9 − 9.1ms (roughly twice the other guards) for a total of 30 − 53ms against a large baseline of 29 − 231s. Because that baseline is so large, its relative overhead is in fact the lowest: 0.017 − 0.025% in every single-agent workload and at most 0.125% in the most parallel multi-agent cell.

Base: 10 77s

100 Ministral-3-14B 10 1 0.1

Base: 7 57s

ST-SA MT-SA seq MT-SA int

2,2 4,2 4,4 6,2 6,4 6,6

100 Gemma-3-12B 10 1 0.1

2,1 4,1 6,1

Base: 3 22s

2,1 4,1 6,1

MT-MA

AEG

100 Llama-3.1-8B 10 1 0.1

1,1

ST-SA MT-SA seq MT-SA int

Meas.

Overhead (ms)

Base: 12 68s

HW Att.

Overhead (ms)

100 Ministral-3-14B 10 1 0.1

2,2 4,2 4,4 6,2 6,4 6,6

Base: 10 79s

2,1 4,1 6,1

100 Gemma-3-12B 10 1 0.1

2,1 4,1 6,1

Base: 5 27s

1,1

100 Llama-3.1-8B 10 1 0.1

In-TEE Att.

Overhead (ms)

AEG

Overhead (ms)

Meas.

Overhead (ms)

HW Att.

Overhead (ms)

In-TEE Att.

MT-MA

Figure 7. System Call Guard: We report AEG generation, measurement, and attestation overheads across workloads and models (both in-TEE and hardware attestations) as a percentage of the baseline computation cost. We indicate the workloads as (#task, #agents). y -axis is log-scaled.

Figure 8. Stop Guard: We report AEG generation, measurement, and attestation overheads across workloads and models (both in-TEE and hardware attestations) as a percentage of the baseline computation cost. We indicate the workloads as (#task, #agents). y -axis is log-scaled.

this where the hardware attestation is 3.7 − 4.6ms and the signature ≈ 0.1ms, exactly as for any single guard. AEG is 16−30ms, close to Γreg ’s alone because the judge dominates node count, and well below the sum of the four guards run separately. The full monitor costs 0.023 − 0.083% of the baseline in every single-agent workload and at most 0.419% in the most parallel multi-agent cell.

off-trajectory tool call or an unauthorized system call. The former is blocked with perfect recall because any position or parameter mismatch changes the hash measurement, while the latter is blocked by comparing every system call issued by the action against the per-prompt authorized set, derived from the toolkits actually used. The kernel sandbox provides defense-in-depth against unmediated system calls issued from inside a tool’s implementation. Thus, when Adv manipulates only external sources, every deviation from the attested policy is either blocked at the tool interface by AttRM or at the kernel layer by Γsys , and the decision is recorded. R2 Confidentiality: All components of K NOX execute inside the CVM and GPU TEEs. Intel TDX encrypts and integrity-protects CPU memory from the untrusted virtual machine monitor (VMM), while NVIDIA H100’s confidential computing mode extends this protection to GPU memory and all data transferred between the CPU and GPU. Since Adv controls the host VMM, they can only observe encrypted memory. Model weights, prompts, intermediate outputs, and the APM remain in plaintext only inside the trusted boundary of K NOX. Verifiers receive only the AEG and its attestation, which contain no model weights. Thus, Adv learns nothing about the models beyond what is revealed by the AEG itself. R3 Attestability: Adv may attempt to bypass the attestability by forging evidence sent to the verifier or by avoiding its actions being recorded in the evidence by K NOX. The AEG

Takeaway: All guards incur <1% overhead, and running all four guards together costs no more than running one.

6.3. Security Analysis Among the requirements for K NOX, R1, R2, and R3 are security properties. We argue that K NOX upholds these desired security properties under possible actions taken by Adv to bypass them, as defined in §3. R1 Compliance: Adv cannot violate the specified regulation or induce unintended behavior (i.e., unauthorized tool or system calls). The APM binds the intended trajectory and guards to the user’s prompt at generation time, and this binding is attested. AttRM mediates every tool call the executor proposes, admitting an action only if it matches the expected tool call at its position in the trajectory and if it satisfies all applicable guards. Prompt injection can only cause harm by inducing the executor to propose an

records every admitted and blocked action as a node with a measurement, all of which are used to produce a hash chain that commits to the content and order, along with a structure root that commits to the graph topology. A single Intel TDX quote and NVIDIA GPU token includes extending these measurements into the report data before they are signed, making the entire AEG tamper-evident. Any omission, reordering, modification, or inserted node changes either the chain head or the structure root, which the verifier can recompute offline to detect. The in-TEE signing key signs per-node evidence, and is certified by the same attestation. Because AttRM is the only component that writes the AEG and invokes the attestor, and AttRM itself runs inside the TEE, Adv cannot forge or alter the execution graph without detection. Any mismatch or invalid attestation indicates tampering and is detected by verifiers. Takeaway: K NOX provides compliance, confidentiality, and attestability despite the actions undertaken by Adv.

7. Discussion and Summary Side Channel Attacks: K NOX’s security guarantees rely on the TEE’s hardware isolation, but side channels remain a concern. Prior work has demonstrated that microarchitectural side channels (e.g., cache timing, page faults) can leak secrets from TEEs [90]. Adv controlling the host could exploit such channels to infer weights, prompt content, or the structure of the APM. Also, the executor’s actions exhibit timing variations that depend on the trajectory taken, the tools invoked, and the data processed. Recent work shows that timing behavior of agentic workloads can be fingerprinted to recover task structure and tool calls [91], [92]. K NOX does not eliminate these channels, but requires a set of complementary approaches, such as constant time execution [93], [94], cache partitioning [95], [96], or taint tracking of private data [97], [98]. We also note that the threat model of K NOX rules out attacks requiring physical access to the machine. Given recent attacks on TEEs that interpose DDR5 memory to leak secrets [90], [99], [100], the security properties of K NOX would apply after manufacturers implement defenses against them. Support for Other AI Systems: Although we focus on agentic systems, which increasingly underpin chatbot services, K NOX also supports standard chatbots. In this setting, the APM is replaced by a judge that evaluates input–output appropriateness, eliminating the need for Γsys . Attestations capture inputs and outputs throughout the chat session [86]. Trust in LLM Judge: Γreg delegates compliance decisions to an LLM judge, whose accuracy is measured empirically rather than proven. This introduces a trust assumption: the judge’s behavior must be stable across each of its operations. A malicious judge could admit non-compliant disclosures or block compliant ones, undermining the regulatory guarantee. Verifiers can audit the judge by inspecting its hash and evaluating it independently on a representative disclosure corpus. The judge’s non-determinism is mitigated by using

a fixed temperature and chain-of-thought prompting, but residual variance remains which is averaged across multiple runs. Future work includes replacing the judge with a formally verified checks with policies, or using multiple judges to reduce reliance on a single model. Agent Sandbox “Escapes”: Recent incidents have shown that agents can gain unauthorized access to the network (e.g., the OpenAI-Huggingface incident [14]). K NOX can derive a per-prompt set of authorized system calls from the trajectory, including network calls only when required. K NOX can block network syscalls at the kernel level, providing least-privilege, attestable network containment. APM exposes the authorized set, while the AEG records every permitted or blocked syscall. Verifiers can therefore confirm offline that (a) no network syscalls were permitted, (b) the kernel enforced this policy, and (c) no network access occurred or any attempted access was blocked and recorded. Other TEE Architectures: Although K NOX is demonstrated with Intel TDX and NVIDIA H100, its design is technology-agnostic. APM, AttRM, and AEG require only (1) a CVM providing memory confidentiality, integrity, and hardware-rooted remote attestation; (2) a GPU TEE providing equivalent guarantees for GPU memory and CPU– GPU communication and producing its own attestation; and (3) a Linux kernel supporting system-call filtering. These requirements can be met by other architectures, such as AMD SEV-SNP [101] or ARM CCA [96], with NVIDIA H100/Blackwell or equivalent GPUs. Thus, K NOX can be ported to any CVM/GPU TEE meeting the requirements. Summary: We present K NOX, the first design and implementation of a TEE-based regulatory sandbox. We identify key design requirements and incorporate them into K NOX, including the APM and the AEG that AttRM compares to detect deviations from intended behavior, i.e., unauthorized tool and system calls. While prior works address individual compliance aspects, such as information flow control, policy compliance, and CFI, none systematically satisfy the requirements of regulatory sandboxes. Our evaluation demonstrates accurate compliance checking and low attestation overhead, making K NOX practical for running agents in the sandbox for monitoring by multiple verifiers prior to deployment. Broader Impact: We address an immediate policy gap by proposing concrete mechanisms for regulatory sandboxes that preserve model confidentiality, support multi-verifier attestations, and enforce behavioral compliance of models. These mechanisms offer actionable tools for regulators and providers conducting pre-deployment oversight. Although blocking off-trajectory but benign actions may reduce utility, we argue that blockage rates are an acceptable signal in sandbox settings, consistent with governance objectives.

Disclosure of AI Tool-Use We used Claude Code to assist with selected parts of the implementation, which the authors subsequently verified, and to help create Figure 2 and 3 in TikZ. The authors independently developed the research ideas, methodology, experiments, and initial manuscript. We used ChatGPT

selectively for language editing, primarily to correct grammar and conciseness. Thus, AI tools were used as assistants for limited implementation and editorial tasks.

Acknowledgments This work is supported by NSERC (Discovery grant) and the Canada CIFAR AI Chairs program. Resources used in preparing this research were provided, in part, by the Province of Ontario, the Government of Canada through CIFAR, and companies sponsoring the Vector Institute.

[14]

OpenAI. (2026, Jul.) OpenAI and hugging face partner to address security incident during model evaluation. Updated July 29, 2026. [Online]. Available: https://openai.com/index/hugging-face-model-e valuation-security-incident/

[15]

P. van Schalkwyk, “The EU AI act now treats multi-agent systems as one system,” https://www.linkedin.com/pulse/eu-ai-act-now-tre ats-multi-agent-systems-one-system-van-schalkwyk-ondmc/, May 2026.

[16]

M. Waseem et al., “Engineering a governance-aware AI sandbox: Design, implementation, and lessons learned,” in International Conference on Evaluation and Assessment in Software Engineering (EASE), 2026.

[17]

D. Ahern, “Operationalising AI regulatory sandboxes under the EU AI act: The triple challenge of capacity, coordination and attractiveness to providers,” in Cambridge Forum on AI: Law and Governance, vol. 1, 2025, p. e35.

[18]

A. Buscemi et al., “Towards sandboxes for the internet of agents,” Social Science Research Network (SSRN), Nov. 2025. [Online]. Available: https://papers.ssrn.com/sol3/papers.cfm?abstract id=5801 322

[19]

Y. Piao et al., “Agentbay: A hybrid interaction sandbox for seamless human-ai intervention in agentic systems,” arXiv preprint arXiv:2512.04367, 2025.

[20]

M. Costa et al., “Securing AI agents with information-flow control,” arXiv preprint arXiv:2505.23643, 2025.

[21]

Y. Cai et al., “Ghost in the agent: Redefining information flow tracking for llm agents,” arXiv preprint arXiv:2604.23374, 2026.

[22]

S. A. Siddiqui et al., “Permissive information-flow analysis for large language models,” Transactions on Machine Learning Research (TMLR), 2025. [Online]. Available: https://openreview.net/forum?id= ufYRO8y3mr

References [1]

International Association of Privacy Professionals. (2026) How different jurisdictions approach AI regulatory sandboxes. [Online]. Available: https://iapp.org/news/a/how-different-jurisdictions-appro ach-ai-regulatory-sandboxes

[2]

The Middle East Insider. (2026) UAE AI regulation 2026: Federal framework explained. [Online]. Available: https://themiddleeastinsid er.com/2026/04/25/uae-ai-regulation-2026/

[3]

AI Safety Directory. (2026) AI regulatory sandboxes: Testing AI innovation under supervision. [Online]. Available: https: //aisecurityandsafety.org/en/guides/ai-regulatory-sandbox/

[4]

Future of Privacy Forum. (2025) Balancing innovation and oversight: Regulatory sandboxes as a tool for AI governance. [Online]. Available: https://fpf.org/blog/balancing-innovation-and-oversight-r egulatory-sandboxes-as-a-tool-for-ai-governance/

[5]

International Association of Privacy Professionals. (2026) Singapore offers potential blueprint for AI sandbox initiatives. [Online]. Available: https://iapp.org/news/a/as-ai-sandboxes-are-considered-s ingapore-offers-a-blueprint

[23]

T. Tiwari et al., “Information flow control in machine learning through modular model architecture,” in USENIX Security Symposium (USENIX Security), 2024, pp. 6921–6938. [Online]. Available: https: //www.usenix.org/conference/usenixsecurity24/presentation/tiwari

[6]

International Bar Association. (2026) AI and regulatory sandboxes. [Online]. Available: https://www.ibanet.org/AI-and-regulatory-sandb oxes

[24]

Y. Wu et al., “Isolategpt: An execution isolation architecture for llmbased agentic systems,” in Network and Distributed System Security Symposium (NDSS), 2025.

[7]

White & Case LLP. (2026) AI watch: Global regulatory tracker — spain. [Online]. Available: https://www.whitecase.com/insight-our-t hinking/ai-watch-global-regulatory-tracker-spain

[25]

H. Wang et al., “Agentspec: Customizable runtime enforcement for safe and reliable llm agents,” in IEEE/ACM International Conference on Software Engineering (ICSE), 2026.

[8]

EU Artificial Intelligence Act. (2026) AI regulatory sandbox approaches: EU member state overview. [Online]. Available: https://artificialintelligenceact.eu/ai-regulatory-sandbox-approache s-eu-member-state-overview/

[26]

Z. Chen et al., “Shieldagent: Shielding agents via verifiable safety policy reasoning,” in International Conference on Machine Learning (ICML), 2025, pp. 8313–8344.

[27]

[9]

——. (2026) Article 57: AI regulatory sandboxes. [Online]. Available: https://artificialintelligenceact.eu/article/57/

W. Hua et al., “Trustagent: Towards safe and trustworthy llm-based agents,” in Findings of the Association for Computational Linguistics (EMNLP Findings), 2024, pp. 10 000–10 016.

[10]

Y. Liu et al., “Formalizing and benchmarking prompt injection attacks and defenses,” in USENIX Security Symposium (USENIX Security), 2024, pp. 1831–1847. [Online]. Available: https://www.us enix.org/conference/usenixsecurity24/presentation/liu-yupei

[28]

X. Jiang et al., “ChainCaps: Composition-safe tool-using agents via monotonic capability attenuation,” in ICML Workshop on Agents in the Wild: Safety, Security, and Beyond (AIWILD), 2026.

[29]

[11]

Q. Zhan et al., “Injecagent: Benchmarking indirect prompt injections in tool-integrated large language model agents,” in Findings of the Association for Computational Linguistics (ACL Findings), 2024, pp. 10 471–10 506.

N. Abaev et al., “Agentguardian: Learning access control policies to govern ai agent behavior,” arXiv preprint arXiv:2601.10440, 2026.

[30]

T. Shi et al., “Progent: Securing AI agents with privilege control,” arXiv preprint arXiv:2504.11703, 2025.

[31]

M. T. U. Alam et al., “Prompt control-flow integrity: A priority-aware runtime defense against prompt injection in LLM systems,” arXiv preprint arXiv:2603.18433, 2026.

[32]

P. Wang et al., “Aligning provenance with authorization: A dualgraph defense for LLM agents,” arXiv preprint arXiv:2605.26497, 2026.

[33]

A. Kolluri et al., “Optimizing agent planning for security and autonomy,” in International Conference on Learning Representations (ICLR), 2026. [Online]. Available: https://openreview.net/forum?id= g0aVCDY3gS

[12]

[13]

E. Debenedetti et al., “AgentDojo: A dynamic environment to evaluate prompt injection attacks and defenses for LLM agents,” in Conference on Neural Information Processing Systems Datasets and Benchmarks Track (NeurIPS D&B), 2024. [Online]. Available: https://openreview.net/forum?id=m1YYAQjO3w K. Greshake et al., “Not what you’ve signed up for: Compromising real-world llm-integrated applications with indirect prompt injection,” in ACM Workshop on Artificial Intelligence and Security (AISec), 2023, pp. 79–90.

[56]

H. Li et al., “DRIFT: Dynamic rule-based defense with injection isolation for securing LLM agents,” Advances in Neural Information Processing Systems (NeurIPS), vol. 38, pp. 83 262–83 290, 2026.

Z. Lin et al., “TypeSqueezer: When static recovery of function signatures for binary executables meets dynamic analysis,” in ACM SIGSAC Conference on Computer and Communications Security (CCS), 2023, pp. 2725–2739.

[57]

[36]

P. Y. Zhong et al., “Rtbas: Defending llm agents against prompt injection and privacy leakage,” arXiv preprint arXiv:2502.08966, 2025.

Y. Liu et al., “Transparent and efficient cfi enforcement with intel processor trace,” in IEEE International Symposium on HighPerformance Computer Architecture (HPCA), 2017, pp. 529–540.

[58]

[37]

I. C. Ngong et al., “AgentSCOPE: Evaluating contextual privacy across agentic workflows,” arXiv preprint arXiv:2603.04902, 2026.

X. Tan and Z. Zhao, “SHERLOC: Secure and holistic controlflow violation detection on embedded systems,” in ACM SIGSAC Conference on Computer and Communications Security (CCS), 2023, pp. 1332–1346.

[38]

L. Tsai and E. Bagdasarian, “Contextual agent security: A policy for every purpose,” in Workshop on Hot Topics in Operating Systems (HotOS), 2025, pp. 8–17.

[59]

D. Kuzhiyelil et al., “Towards transparent control-flow integrity in safety-critical systems,” in International Conference on Information Security (ISC), 2020, pp. 290–311.

[39]

E. Bagdasarian et al., “Airgapagent: Protecting privacy-conscious conversational agents,” in ACM SIGSAC Conference on Computer and Communications Security (CCS), 2024, pp. 3868–3882.

[60]

H. Liljestrand et al., “PACStack: an authenticated call stack.” in USENIX Security Symposium (USENIX Security), 2021, pp. 357– 374.

[40]

S. Ghalebikesabi et al., “Privacy awareness for information-sharing assistants: A case-study on form-filling with contextual integrity,” Transactions on Machine Learning Research (TMLR), 2025. [Online]. Available: https://openreview.net/forum?id=l9rATNBB8Y

[61]

S. Yoo et al., “In-Kernel Control-Flow integrity on commodity OSes using ARM pointer authentication,” in USENIX Security Symposium (USENIX Security), 2022, pp. 89–106.

[41]

B. Sidik and L. Rokach, “Beyond static sandboxing: Learned capability governance for autonomous ai agents,” arXiv preprint arXiv:2604.11839, 2026.

[62]

H. Liljestrand et al., “PAC it up: Towards pointer integrity using ARM pointer authentication.” in USENIX Security Symposium (USENIX Security), 2019, pp. 177–194.

[42]

L. Meng et al., “CellMate: Sandboxing browser AI agents,” arXiv preprint arXiv:2512.12594, 2025.

[63]

M. Ammar et al., “SoK: Integrity, attestation, and auditing of program execution,” in IEEE Symposium on Security and Privacy (S&P), 2024, pp. 77–77.

[43]

NANDA. (2026) NEST: NANDA exchange sandbox & TestNet. NANDA Exchange Sandbox and TestNet. [Online]. Available: https://nest.projectnanda.org/

[64]

M. Castro et al., “Securing software by enforcing data-flow integrity,” in USENIX Symposium on Operating Systems Design and Implementation (OSDI), 2006, pp. 147–160.

[44]

Google Cloud. (2026, Aug.) About GKE agent sandbox. Google Cloud Documentation. [Online]. Available: https://docs.cloud.google. com/kubernetes-engine/docs/concepts/machine-learning/agent-san dbox

[65]

C. Song et al., “Enforcing kernel security invariants with data flow integrity.” in Network and Distributed System Security Symposium (NDSS), 2016.

[66]

[45]

Microsoft, “Azure sandbox,” https://learn.microsoft.com/en-us/azure/ architecture/guide/azure-sandbox/azure-sandbox, 2026, microsoft Learn, Azure Architecture Center. Accessed September 10, 2026.

F. Buccafurri et al., “MQTT-I: Achieving end-to-end data flow integrity in MQTT,” IEEE Transactions on Dependable and Secure Computing (TDSC), vol. 21, no. 5, pp. 4717–4734, 2024.

[67]

[46]

R. Shu et al., “A study of security isolation techniques,” ACM Computing Surveys (CSUR), vol. 49, no. 3, pp. 1–37, 2016.

[47]

Y. Li et al., “{MiniBox}: A {Two-Way} sandbox for x86 native code,” in USENIX Annual Technical Conference (USENIX ATC), 2014, pp. 409–420.

K. Chen et al., “FineDIFT: Fine-grained dynamic information flow tracking for data-flow integrity using coprocessor,” IEEE Transactions on Information Forensics and Security (TIFS), vol. 17, pp. 559–573, 2022.

[68]

C. Song et al., “HDFI: Hardware-assisted data-flow isolation,” in IEEE Symposium on Security and Privacy (S&P), 2016, pp. 1–17.

[69]

S. A. Carr and M. Payer, “Datashield: Configurable data confidentiality and integrity,” in ACM Asia Conference on Computer and Communications Security (AsiaCCS), 2017, pp. 193–204.

[70]

H. Li, Y. Chen, H. Jing, W. Hu, T. H. Li, C. Lou, H. T. Tsang, S. Han, and Y. Song, “ContextLens: Modeling imperfect privacy and safety context for legal compliance,” in Annual Meeting of the Association for Computational Linguistics (ACL), San Diego, California, United States, Jul. 2026, pp. 6503–6518. [Online]. Available: https://aclanthology.org/2026.acl-long.294/

[71]

W. Fan, H. Li, Z. Deng, W. Wang, and Y. Song, “GoldCoin: Grounding large language models in privacy laws via contextual integrity theory,” in Conference on Empirical Methods in Natural Language Processing (EMNLP), 2024, pp. 3321–3343.

[72]

H. Li, W. Fan, Y. Chen, C. Jiayang, T. Chu, X. Zhou, P. Hu, and Y. Song, “Privacy checklist: Privacy violation detection grounding on contextual integrity theory,” in Conference of the Nations of the Americas Chapter of the Association for Computational Linguistics (NAACL), 2025, pp. 1748–1766.

[34]

J. Kim et al., “Prompt flow integrity to prevent privilege escalation in llm agents,” arXiv preprint arXiv:2503.15547, 2025.

[35]

[48]

V. Venkatakrishnan and R. Sekar, “Isolated program execution: An application transparent approach for executing untrusted programs,” in Annual Computer Security Applications Conference (ACSAC), 2003, pp. 182–191.

[49]

J. Piet et al., “Web agents should adopt the plan-then-execute paradigm,” arXiv preprint arXiv:2605.14290, 2026.

[50]

R. F. Del Rosario et al., “Architecting resilient llm agents: A guide to secure plan-then-execute implementations,” arXiv preprint arXiv:2509.08646, 2025.

[51]

L. Beurer-Kellner et al., “Design patterns for securing llm agents against prompt injections,” arXiv preprint arXiv:2506.08837, 2025.

[52]

T. Wei et al., “Agentic reasoning for large language models,” arXiv preprint arXiv:2502.04644, vol. abs/2601.12538, 2026. [Online]. Available: https://arxiv.org/abs/2601.12538

[53]

Intel, “Intel Trust Domain Extensions (Intel TDX),” https://www.in tel.com/content/www/us/en/developer/tools/trust-domain-extension s/overview.html, 2023.

[54]

J. Choquette, “NVIDIA Hopper H100 GPU: Scaling Performance,” IEEE Micro, vol. 43, no. 3, pp. 9–17, 2023.

[73]

E. Debenedetti et al., “Defeating prompt injections by design,” arXiv preprint arXiv:2503.18813, 2025.

[55]

L. Maar et al., “Beyond the edges of kernel control-flow hijacking protection with HEK-CFI,” in ACM Asia Conference on Computer and Communications Security (AsiaCCS), 2024.

[74]

H. Foerster et al., “Camels can use computers too: System-level security for computer use agents,” arXiv preprint arXiv:2601.09923, 2026.

[75]

R. D. Jha et al., “Breaking and fixing defenses against control flow hijacking in multi-agent systems,” in International Conference on Learning Representations (ICLR), 2026. [Online]. Available: https://openreview.net/forum?id=PNU9Rj5RDQ

[76]

P. Wang et al., “AgentArmor: Enforcing program analysis on agent runtime trace to defend against prompt injection,” arXiv preprint arXiv:2508.01249, 2025.

[77]

M. Balunovic et al., “AI agents with formal security guarantees,” in ICML Workshop on Next Generation of AI Safety, 2024. [Online]. Available: https://openreview.net/forum?id=c6jNHPksiZ

[78]

N. Palumbo et al., “Formal policy enforcement for real-world agentic systems,” arXiv preprint arXiv:2602.16708, 2026.

[79]

A. Solko-Breslin et al., “Efficient and sound probabilistic verification for AI agents,” arXiv preprint arXiv:2606.20510, 2026.

[80]

A. Kravchenko et al., “Agentic permissions policy algebra for taint confinement in LLM agents,” arXiv preprint arXiv:2607.24625, 2026.

[81]

S. Abdollahi et al., “AgenTEE: Confidential LLM agent execution on edge devices,” in European Workshop on Machine Learning and Systems (EuroMLSys), 2026, pp. 473–480.

[82]

C. Villa et al., “Prismata: Confining cross-site prompt injection in web agents,” arXiv preprint arXiv:2607.08147, 2026.

[83]

T. Bodea et al., “Trusted AI agents in the cloud,” arXiv preprint arXiv:2512.05951, 2025.

[84]

V. Duddu et al., “Laminator: Verifiable ML property cards using hardware-assisted attestations,” in ACM Conference on Data and Application Security and Privacy (CODASPY), 2024, pp. 317–328.

[85]

A. Grigor et al., “Vet your agent: Towards host-independent autonomy via verifiable execution traces,” in ACM Asia Conference on Computer and Communications Security (AsiaCCS), 2026, pp. 820–834.

[86]

P. Chantasantitam et al., “PAL∗ M: Property attestation for large generative models,” arXiv preprint arXiv:2601.16199, 2026.

[87]

M. Chrapek et al., “Confidential llm inference: Performance and cost across cpu and gpu tees,” in IEEE International Symposium on Workload Characterization (IISWC), 2025, pp. 84–98.

[88]

J. Zhu et al., “Confidential computing on nvidia hopper gpus: A performance benchmark study,” arXiv preprint arXiv:2409.03992, 2024.

[89]

W. Wang et al., “Benchmarking confidential GPU inference on NVIDIA H100 under intel TDX,” arXiv preprint arXiv:2607.19353, 2026.

[90]

J. Chuang, A. Seto, N. Berrios, S. Van Schaik, C. Garman, and D. Genkin, “TEE.fail: Breaking trusted execution environments via DDR5 memory bus interposition,” in IEEE Symposium on Security and Privacy (S&P), 2026, pp. 4408–4426.

[91]

N. Carlini and M. Nasr, “Remote timing attacks on efficient language model inference,” arXiv preprint arXiv:2410.17175, 2024.

[92]

H. Jeong, M. Teymoorianfard, A. Kumar, A. Houmansadr, and E. Bagdasarian, “{Network-Level} prompt and trait leakage in local research agents,” in USENIX Security Symposium (USENIX Security), 2026, pp. 6485–6504.

[93]

S. Cauligi, G. Soeller, F. Brown, B. Johannesmeyer, Y. Huang, R. Jhala, and D. Stefan, “FaCT: A flexible, constant-time programming language,” in IEEE Cybersecurity Development Conference (SecDev), 2017, pp. 69–76.

[94]

G. Barthe, S. Blazy, B. Grégoire, R. Hutin, V. Laporte, D. Pichardie, and A. Trieu, “Formal verification of a constant-time preserving C compiler,” ACM on Programming Languages (PACMPL), vol. 4, no. POPL, pp. 1–30, 2019.

[95]

Z. Wang and R. B. Lee, “New cache designs for thwarting software cache-based side channel attacks,” in International Symposium on Computer Architecture (ISCA), 2007, pp. 494–505.

[96]

ARM, “Confidential compute architecture,” [Online] Accessed September 2026.

[97]

H. ElAtali, L. J. Gunn, H. Liljestrand, and N. Asokan, “BliMe: Verifiably secure outsourced computation with hardwareenforced taint tracking,” in Network and Distributed System Security Symposium (NDSS), 2024. [Online]. Available: https: //www.ndss-symposium.org/ndss-paper/blime-verifiably-secure-out sourced-computation-with-hardware-enforced-taint-tracking/

[98]

H. ElAtali, M. Gülmez, T. Nyman, and N. Asokan, “BLACKOUT: data-oblivious computation with blinded capabilities,” in ACM SIGSAC Conference on Computer and Communications Security (CCS), 2025, pp. 2039–2053. [Online]. Available: https://doi.org/10 .1145/3719027.3765169

[99]

J. De Meulemeester, D. Oswald, I. Verbauwhede, and J. Van Bulck, “Battering RAM: Low-cost interposer attacks on confidential computing via dynamic memory aliasing,” in IEEE Symposium on Security and Privacy (S&P), 2026, pp. 4391–4407.

[100] A. Seto, O. K. Duran, S. Amer, J. Chuang, S. van Schaik, D. Genkin, and C. Garman, “Wiretap: Breaking server sgx via dram bus interposition,” in ACM SIGSAC Conference on Computer and Communications Security (CCS), 2025, pp. 708–722. [101] AMD, “AMD secure encrypted virtualization (SEV),” https://www. amd.com/en/developer/sev.html, 2020.

Appendix A. APM Example

// Trajectory T : permitted tool calls, in order trajectory: [ { pos: 0, tool: Terminal.Execute, params: { command: "summarize report.csv" } }, { pos: 1, tool: Gmail.SendEmail, // disclosure params: { to: "auditor@acme.com" } } ] // each tool call stores its hash H(ej ) // Γreg: the governing regulation { name: regulation, scope: DISCLOSURE_TOOLS, predicate: "φ(α) permitted under R", spec: { regulations: [gdpr, hipaa] } } // Γsys: authorized system calls { name: os, scope: syscall, predicate: "all system calls of α in Auth", spec: { syscalls: [openat, read, write, // runtime execve, fork, // + Terminal connect, socket], // + Gmail paths: [/lib, /proc, /usr], rlimits: { NPROC: 1, FSIZE: 64MB } } } // Γint: budget and stop signal { name: interrupt, scope: continuation, predicate: "no trigger in σ", spec: { budget: { turns: 8 }, stop: external } } Figure 9. APM Example: For tasks involving Terminal and Gmail, T lists permitted tool calls in order, each with hash H(ej ) for Γtraj to verify. Multi-agent runs include one branch per sub-agent. Each guard defines the check (name), covered actions (scope), condition (predicate), and ground truth (spec), which AttRM independently evaluates using a static predicate or language-model oracle. execve/socket entries are included only when required by the trajectory’s tools.

Appendix B. Attestation Definitions K NOX attests every step of a run: the APM the planner derives, each model call, each decision AttRM makes, each stop, each sub-task dispatch, and the AEG the run leaves behind. All of them follow the same template: the input names the values the attestation binds, the computation is what runs inside the TD, the output is the signed statement a verifier receives, and the assertion is what that verifier may conclude once the signature checks out. APM Generation: This binds the policy to the inputs it was derived from, so that a policy cannot be swapped for a more permissive one later. It takes the clean prompt p, the system-call manifest C , the applicable regulations R, and the stop condition, and outputs the APM (T , Γ) together with a signature over the hashes of all of them. A verifier concludes that the enforced trajectory came from the user’s prompt alone and that the authorized set Auth covers the tools that trajectory require (Attestation 1). Attestation 1: APM Generation Input: prompt p, system-call manifest C , regulations R, stop condition stop; Computation: planner derives APM (T , Γ) ← Planner(p, C, R, stop); Auth is union of system calls that tools on T declare in C ; Output: APM,
Signatt ‘APMAtt’, H(p, C, R, T , Γ) ; Assertion: T derives from p alone, and Auth holds only what manifests of T ’s tools require; Inference Binding: This binds a model inference to the weights that produced it, so that no model in the pipeline, planner, executor, or judge, can be silently substituted for another one. It takes the model’s weights, its input, and its output, and outputs a proof_of_inference recorded on the node that used the inference. A verifier concludes that the recorded output was produced by the claimed model on the recorded input (Attestation 2). Attestation 2: Inference Binding Input: model weights w, input x (prompt and context), output y ; Computation: model uses inference logic spanning a TD and confidential-computing GPU (producing GP UAtt ); K NOX produces GP UAtt and hashes w once per run as weights_hash, and each (x, y) pair per call;
Output: Signatt ‘InfAtt’, H(w, x, y), GP UAtt , recorded as proof_of_inference; Assertion: y came from model with weights_hash H(w), on input x, inside TD paired to GPU that produces GP UAtt ; Reference Monitor Check: This binds AttRM’s decision to the action and the guards, so that an admitted action cannot

later be presented as unchecked, nor a blocked one as never attempted. It takes the proposed action α at position j , the expected tool call ej , and the guards Γ|α that cover α, and outputs the verdict together with the measurement of the check node that records it. A verifier concludes that α was evaluated against every applicable guard, and that the tool ran only if all of them passed (Attestation 3). Attestation 3: Reference Monitor Check Input: proposed action α at position j , expected tool call ej , applicable guards Γ|α ⊆ Γ, run state σ ; Computation: AttRM evaluates every guard in Γ|α and emits v ← ALLOW if all hold, else v ← BLOCK; tool executes only when v = ALLOW, and verdict is committed as check node with measurement mi ;
Output: Signatt ‘ChkAtt’, H(α, ej , Γ|α , v, mi ) ; Assertion: α passed through AttRM and was checked against every guard in Γ|α before any side effect, and tool executed iff v = ALLOW; Regulation Judgment: Γreg uses oracle rather than a decidable predicate (§4.2), so its attestation additionally binds which judge decided, what it was shown, and what it answered. It takes the action tuple φ = derive(α), regulation R, and the judge J , and outputs the label the judge returned. A verifier concludes that the label was produced by that judge on that tuple under R. Its correctness is an empirical property of J (§6; Attestation 4). Attestation 4: Regulation Judgment Input: action tuple φ = derive(α), regulation text R, fixed judge J with weights wJ , fixed prompt template with k -shot examples; Computation: AttRM queries J on (φ, R) under fixed template and obtains label ℓ: compliant, non-compliant, or not-applicable; action is blocked iff ℓ is non-compliant; Output:
Signatt ‘RegAtt’, H(φ, R, wJ , template, ℓ) , with proof_of_inference of judge call (Attestation 2); Assertion: ℓ came from fixed judge J on φ under R, and action was blocked iff ℓ is non-compliant; Interrupt: This binds a stop to the point at which it happened, so that a truncated run cannot be mistaken for a tampered one, nor a tampered one presented as merely interrupted. It takes the run state at the stop and the trigger that fired, and outputs the interrupt node that terminates the branch. A verifier concludes that the run stopped at that position, that the pending action never executed, and that nothing follows it in that branch (Attestation 5). Sub-task Dispatch: This binds the planner’s decomposition to the branches it spawned, so that a dropped or injected sub-agent is distinguishable from a legitimate parallel run. It

Attestation 5: Interrupt Input: run state σ at stop, trigger that fired (timeout, resource cap, or external stop), position j of pending action; Computation: AttRM neither executes nor commits action at j , and commits interrupt node with measurement mi as terminal event of branch;
Output: Signatt ‘IntAtt’, H(σ, trigger, j, mi ) ; Assertion: branch stopped at position j , action at j produced no side effect, and no further node is committed in that branch;

takes the sub-tasks and their per-branch trajectories, and outputs the agent_step that records the dispatch. A verifier concludes the exact sub-agents that were dispatched and their trajectories, and that the branch set is the one the parent binds through the structure root (Attestation 6). Attestation 6: Sub-task Dispatch Input: sub-tasks τ1 , . . . , τm of decomposed task, with trajectories T1 , . . . , Tm from APM; Computation: planner commits agent_step and dispatches one sub-agent per sub-task, each rooted at agent_branch; Output:
Signatt ‘DispAtt’, H(τ1 , . . . , τm , T1 , . . . , Tm ) ; Assertion: exactly m sub-agents were dispatched, sub-agent k is constrained by Tk , and complete branch set is bound to parent; Execution Graph: K NOX produces one attestation for the entire AEG, and it is the only hardware invocation during execution (the APM is attested separately, before the run starts). It binds the recorded graph to the hardware that produced it, turning a graph anyone could recompute into evidence that this TD actually ran it. It takes the committed nodes in commit order together with their topology, and outputs a single hardware attestation over the AEG summary (cN , s) and the public key that signed every per-node attestation in the graph. A verifier concludes that the serialized AEG is exactly what the TD ran. Any omission, reordering, or modification of a node changes cN , and any change to the topology changes s, and every per-node signature traces back to the certified key (Attestation 7). As the head and the structure root already commit to every node and the topology, this one attestation covers all the attestations above (§4.3). Nodes without a Separate Attestation: The remaining node types carry measurements but no signed statement of their own, since an existing attestation already binds them. The prompt is bound by Attestation 1, a blocked node by the check it hangs off (Attestation 3), and tool_output and final output nodes by the chain in Attestation 7. Measuring a tool_output records what the executor read, which is what a verifier needs to replay a deviation; it asserts nothing about the content, since tool outputs are untrusted

Attestation 7: Attested Execution Graph Input: committed nodes with measurements m1 , . . . , mN in commit order, graph topology (each node’s kind, parent, dispatched branch set), public part pk of in-TEE signing key; Computation: fold chain ci = H(ci−1 ∥ seqi ∥ mi ) to head cN , compute structure root s over topology, and request one hardware attestation over (cN , s) and pk ;
Output: AEG, Signatt ‘AEGAtt’, H(cN , s, pk ) , with GPU evidence binding models that ran; Assertion: serialized AEG is what this TD ran: cN binds every node’s content and order, s binds topology, and pk certifies key that signed every per-node attestation;

and are exactly where injected instructions arrive.

Related documents

• KNOX: Hardware-assisted Regulatory Sandbox for Generative Models#1403339
• DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale#1048373
• DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale#1028669
• Contract-Driven Multi-Agent Incident Response for Cloud-Native Platforms#704435
• Deepfake-induced harm and AI accountability: a layered civil-liability framework for generative models, platforms, and digital identity.#375349