Mechanism · Cryptographic & computational
Safeguard attestation
Hardware-signed evidence that an AI service ran its declared safeguards, such as a guardrail classifier or monitor, when producing a given response.
Also called Proof of guardrail; Attested safeguards; Verifiable safeguard execution
Summary
Safeguard attestation aims to let users, auditors or other governments check that an AI service ran the safeguards it declares, such as a safety classifier, filter or usage monitor. Published designs run the safeguard inside a trusted execution environment (TEE), whose hardware signs a measurement of that code with a hash of each input and response. A research prototype with public code does this for an AI agent and an open-source guardrail on AWS Nitro Enclaves, though it calls the guardrail model through an outside API. Related work attests which model answered, and limits monitoring to a jointly signed plan. As of September 2026 no system has been independently evaluated or relied on by another party. The main obstacles are showing that all traffic took the attested path and scaling to frontier GPU clusters. Attestation shows a safeguard ran, not that it works: a guardrail can still be jailbroken.
R2, narrowly. One prototype with public code attests a guardrail end to end on cloud enclaves. Nothing has been independently evaluated or relied on.
Rubric assessment
- R1 met: designs that state the claim (a response was produced after a specific guardrail ran) and their trust assumptions are published 1, alongside designs for attesting inference properties 3 and plan-scoped monitoring 5.
- R2 met through the proof-of-guardrail prototype. Its code is public 2, and its authors report end-to-end results on production cloud enclave hardware (AWS Nitro Enclaves) against a stated adversary, a developer who skips or modifies the guardrail 1. PAL*M adds attested session inference on Intel TDX with an H100 GPU, but its properties do not cover safeguards 3.
- R3 not met. Criterion (a) fails: no party other than a developer is documented as relying on safeguard attestation, and the code is described as a proof of concept that is not production-ready 2. Criterion (b) fails: no independent audit or red-team has been published, and the monitoring prototype has not been stress-tested by a counterparty 6.
Confidence is low because the demonstration is far from a frontier serving stack. It reaches both its guardrail model and the agent's backend model through external APIs, attests only the responses for which attestation is offered, and runs on CPU enclaves 1. Its README states that the enclave does not yet restrict the agent's command execution, which could be used to bypass the guardrail 2. Intel TDX attestations have also been forged by attackers with physical access to the memory bus 11.
- An independent public evaluation (audit, red-team or peer-reviewed security analysis) of a safeguard-attestation system.
- Reliance by a party other than the developer on safeguard attestations for a verification decision, or a production-grade system that is generally available.
- A demonstration in which the safeguard model itself runs inside the attested boundary on GPU hardware at a realistic serving scale.
- A published way to show that all of a service's traffic, not only attested responses, passed through the attested safeguard path.
How it works
Users of AI services often have to rely on a developer's word about how safety is enforced, so safety measures could be falsely advertised 1. A paper on frontier AI auditing notes that swapping in a different safety classifier or relaxing a filter threshold can materially change how easily a system is misused 8. A governance analysis of trusted execution environments (TEEs) lists "policy adherence" as a property a verifier needs: a workload should show that it uses the approved model or enforces access controls and safeguards 7.
The published designs follow one pattern: run the safeguard inside a TEE and have the hardware sign what ran 1 3 5.
- Proof of guardrail. A wrapper program containing a public guardrail and its configuration mediates all of an agent's inputs and outputs inside the enclave 1. When a user asks for it, or the agent offers it, the enclave signs a document containing a hash of the wrapper and a hash of the input and response 1 2. A user compares the wrapper hash with the published open-source build and checks the signature offline, while the developer's agent stays private 1.
- Property attestation. PAL*M runs inference in a confidential virtual machine with a GPU, and attests that a response came from a specific model and tokenizer on a given query or chat history 3. Its defined inputs are the query, model and tokenizer; it has no separate safeguard input 3.
- Audit-to-deployment binding. Attestable Audits returns, with each response, an attestation that links the model, its earlier audit result, the prompt and the response 4. Binding weights to attestation is covered in Model identity attestation.
- Scoped monitoring. The monitoring party and the monitored party co-sign a plan, which an open-source classifier runs inside an attested TEE 5. Queries outside the plan's scope are never evaluated 5.
Two approaches do not use TEEs:
- Verifier-side screening. In a low-trust system design, the verifier re-executes sampled records and screens them itself for compliance, for example for blacklisted uses 9. See Sampled inference recomputation and Low-trust AI compute verification system overview.
- Black-box testing. Prompt Detective compares output distributions to judge whether a given system prompt was used 10. It was developed to detect reuse of proprietary prompts, not to audit declared safeguards 10.
What it establishes
It can establish:
- that the declared guardrail code ran for an attested response, without revealing the developer's agent 1;
- that tampering is visible: in the authors' tests, modified guardrail code, modified attestation bytes and modified responses were all detected 1;
- in scoped monitoring, that the monitor evaluated only what the co-signed plan allows 5.
It cannot establish:
- that the safeguard works, since guardrails make errors and can be jailbroken 1;
- that all traffic was covered, since attestations are per response and the prototype offers them for high-stakes questions 1;
- anything the measurement leaves out, such as configuration, flags or later changes at runtime 7.
Threat model
- Proof of guardrail assumes a developer who might skip or modify the guardrail 1. It trusts the cloud provider's enclave hypervisor to measure code and protect keys, and it needs an open-source guardrail so that verifiers know the expected measurement 1.
- PAL*M assumes an adversary who controls the host, hypervisor and disk 3. It trusts the Intel TDX module and the H100 GPU 3. It treats side-channel defences as orthogonal and places physical attacks, such as memory-bus interposition, out of scope 3.
- Treaty setting. A governance analysis contrasts the confidential-computing adversary, a dishonest operator, with a treaty adversary: a state with physical access to data centres and leverage over hardware vendors 7.
Evidence
- Proof of guardrail. The authors implemented it for OpenClaw agents on AWS Nitro Enclaves, with Llama Guard 3 for content safety and a fact-checking tool 1. They report 34% added latency on average compared with running outside the enclave 1. The code is public; its README calls it a proof of concept that is not production-ready 2.
- PAL*M. Implemented on Intel TDX with an NVIDIA H100 3. The authors report 3.8–11.4% overhead for session inference over the same machine without PAL*M, and they modelled the protocol formally with the Tamarin prover 3.
- Attestable Audits. A prototype ran a 4-bit 8-billion-parameter model in CPU-only AWS Nitro Enclaves at 1.84 tokens per second 4.
- Scoped monitoring. A reference implementation runs in Tinfoil confidential virtual machines 6. Its authors state that user data and plan execution in the demo are not actually secure, and that the system has not been stress-tested by a counterparty 6.
Limitations
- Effectiveness gap. An attested guardrail can still be jailbroken 1.
- Selective attestation. Provers might attest only favourable executions 3 1.
- Outside the boundary. The prototype called its guardrail model and backend model through external APIs 1.
- Hardware attacks. With physical access to the memory bus, researchers forged Intel TDX attestations and, by pairing them with relayed H100 attestations, made a workload outside TEE protection pass as GPU confidential computing 11. Other attacks forged AMD SEV-SNP attestations, one through a DDR4 interposer and one from software alone before AMD's fix 12 13.
- Scale. Frontier model inference typically needs several GPUs 7. CPU inference, which the enclave prototype had to use, cost 21.7 times as much per token as GPU inference and ran about 100 times slower 4.
For confidential workflows that combine several parties' private inputs, see Confidential multi-party verification.
Known flaws
Published flaws, with their severity, kind and status. How flaws are rated.
Attestation shows a safeguard ran, not that it is effective
Proof of guardrail ensures that the guardrail executed, but the guardrail can still err or be jailbroken. Because the guardrail must be open source, a malicious developer can attack it with jailbreaks while still presenting a valid proof. In the authors' evaluation, Llama Guard 3 reached an F1 score of 0.56 on the unsafe class of the ToxicChat dataset. The authors state that proof of guardrail should not be interpreted or advertised as proof of safety.
Sources: [1]Selective attestation leaves traffic uncovered
Attestations are issued per response. In the prototype, the agent offers them when it receives high-stakes questions, so nothing shows that unattested traffic went through the same path. PAL*M's authors note that a prover could cherry-pick favourable executions, and suggest verifier-published nonces or requesting only session-level proofs. A governance analysis notes that auditors also need assurance that all activity is accounted for, since a host could start a second confidential virtual machine that bypasses monitoring.
Measurements may omit behaviour-relevant configuration or runtime changes
Every component that influences inference behaviour must be covered by the launch measurement, including feature flags, environment variables and invocation arguments. A launch measurement also does not show that a program keeps running as measured if the kernel is later compromised.
Sources: [7]Components outside the attested boundary
In the proof-of-guardrail experiments, the guardrail model and the agent's backend model were both reached through external APIs, and the authors leave the decision to trust those APIs to the verifier. The measured wrapper must also have no vulnerability that lets the unmeasured agent bypass the guardrail, for example by executing arbitrary commands inside the enclave. The code's README states that the enclave does not currently restrict the agent's arbitrary command execution, which could be used to bypass guardrails.
Memory-bus interposition extracts attestation keys and forges attestations
With physical access to a server's DDR5 memory bus and equipment costing under $1,000, researchers extracted a per-CPU Intel attestation provisioning key and forged TDX attestations. Against AMD SEV-SNP the same attack recovered a signing key used inside the virtual machine, not an AMD attestation key. Other attacks have forged SEV-SNP attestation: Battering RAM with an interposer on DDR4 servers, and RMPocalypse from a malicious hypervisor until AMD's firmware fix. By pairing forged TDX attestations with genuine H100 attestations relayed from rented hardware, they made a workload without TEE protection appear to run under GPU confidential computing. Intel, AMD and NVIDIA acknowledged the findings. PAL*M places physical attacks outside its threat model. A governance analysis calls such key extraction "relatively low-hanging fruit" in an international treaty setting.
Blockers
No published design shows that all of a provider's traffic passes through the attested safeguard path; current evidence covers individual attested responses.
Frontier model inference typically needs several GPUs, GPU confidential computing is less mature than CPU support, and CPU inference, which an enclave prototype had to use, ran about 100 times slower than GPU inference.
Trust rests on a small number of hardware vendors, and a per-CPU Intel attestation key has been extracted by physical attack.
Safeguard evidence must be bound to the model actually served, which depends on model-identity attestation.
No independent red-team or audit of a safeguard-attestation system has been published, and the available prototypes are described by their authors as proofs of concept that have not been stress-tested by a counterparty.
Technical detail
Show technical detail
- Proof-of-guardrail protocol. (1) A wrapper program f bundles the public guardrail g, its configuration and the mediation of all agent inputs and outputs. (2) When f is loaded, the enclave records a measurement m, a hash that depends on the binary of f. (3) The private agent is loaded afterwards as a secret input, so it is not part of m. (4) For a user input x and response r, f returns a document signed with the platform's attestation key that contains m and d = Hash(x, r). (5) The verifier checks the certificate chain against the platform's published root, compares m with the expected measurement of the open-source f, and checks d 1.
- Prototype costs. On AWS Nitro Enclaves, the authors report 34% added latency on average over the same agent and guardrail run outside the enclave, 97.8 ms to generate an attestation and 5.1 ms to verify it. Holding the whole guardrail runtime in enclave memory needs an m5.xlarge instance, which costs 18.5 times as much per hour as a t3.micro 1.
- PAL*M. It defines single and session inference properties, r = M(M_tok(q)) and its multi-turn form over the chat history. It binds hashes of the query, tokenizer, model and response into an Intel TDX quote, together with an NVIDIA H100 attestation token and a verifier challenge 3. Compared with the same TDX machine without PAL*M's measurements, session inference cost 3.8–11.4% more and single-prompt inference 45.5–66.4% more, across Llama-3.1-8B, Gemma-3-4B and Phi-4-Mini 3.
Sources
- BX. Jin et al. (2026). Proof-of-Guardrail in AI Agents and What (Not) to Trust from It. arXiv. Source recordSupports: problem statement; protocol; threat model and trust assumptions; implementation and overheads; tamper tests; guardrail accuracy on ToxicChat; jailbreak risk; proof-of-safety caveat; external APIs; wrapper-bypass risk; selective attestation · abstract; §3; §4.1; Tables 1-3; Appendix A
- BSaharaLabsAI (2026). Verifiable-ClawGuard: proof-of-guardrail reference code. GitHub. Source recordSupports: public code; proof-of-concept status; stated limitation on agent command execution · README, including Limitations
- BP. Chantasantitam et al. (2026). PAL*M: Property Attestation for Large Generative Models. arXiv. Source recordSupports: inference property definitions; TDX+H100 implementation; overheads and baseline; threat model; cherry-picking discussion · abstract; §3.2; §4.3.4 (Defs. 7-8); §4.4; Table 6; Appendix A
- BC. Schnabl et al. (2025). Attestable Audits: Verifiable AI Safety Benchmarks Using Trusted Execution Environments. ICML 2025 Workshop on Technical AI Governance. Source recordSupports: inference protocol linking model, audit result, prompt and response; CPU-only enclave prototype; CPU versus GPU cost and slowdown · §3 (Inference protocol); §5; Table 2
- BB. Penchas et al. (2026). Enabling Verifiably-Scoped Monitoring through Large Language Models and Trusted Compute. ICML 2026 Workshop on Technical AI Governance Research. Source recordSupports: verifiably-scoped monitoring protocol · abstract
- CR. Rinberg & B. Penchas (2026). Auditor-in-a-Box: Tools for Third-Party Auditing. LessWrong. Source recordSupports: reference implementation in Tinfoil confidential VMs; stated limitations · reference implementation; limitations
- CGloria Z (2026). On TEEs for Privacy-Preserving Monitoring in AI Governance. MIRI Technical Governance Team. Source recordSupports: policy adherence as a verification property; measurement completeness; runtime state; second-CVM completeness gap; vendor root of trust; treaty threat model; GPU TEE maturity and multi-GPU inference · deployment integrity; hardware auditability; resource accounting; physical attack surface
- BM. Brundage et al. (2026). Frontier AI Auditing: Toward Rigorous Third-Party Assessment of Safety and Security Practices at Leading AI Companies. arXiv. Source recordSupports: configuration drift, such as swapping safety classifiers or relaxing filter thresholds · §5.2
- BN. Cankaya (2026). A System Overview for Near-Term, Low-Trust AI Compute Verification. Machine Intelligence Research Institute. Source recordSupports: verifier-side compliance screening of re-executed records · §3.2.2; §5.2.3
- BR. Levin et al. (2025). Has My System Prompt Been Used? Large Language Model Prompt Membership Inference. arXiv. Source recordSupports: black-box statistical test for system-prompt use; its prompt-protection setting · abstract; §3.2
- AJ. Chuang et al. (2026). TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition. 2026 IEEE Symposium on Security and Privacy (SP). Source recordSupports: physical key extraction from TDX and signing-key extraction in SEV-SNP; forged attestations against NVIDIA GPU confidential computing; cost; vendor acknowledgement · project site summary; paper abstract and disclosure
- AJ. De Meulemeester et al. (2026). Battering RAM: Low-Cost Interposer Attacks on Confidential Computing via Dynamic Memory Aliasing. 47th IEEE Symposium on Security and Privacy (S&P 2026). Source recordSupports: Battering RAM forges SEV-SNP attestation with a DDR4 interposer
- AB. Schlüter & S. Shinde (2025). RMPocalypse: How a Catch-22 Breaks AMD SEV-SNP. 2025 ACM SIGSAC Conference on Computer and Communications Security (CCS '25). Source recordSupports: RMPocalypse forges SEV-SNP attestation from a malicious hypervisor
- BAMD (2025). SEV-SNP RMP Initialization Vulnerability (AMD-SB-3020). AMD product security bulletin. Source recordSupports: AMD firmware fixes for RMPocalypse (CVE-2025-0033)
- CTinfoil Team (2026). How Tinfoil Proves Exactly What Model Is Running. Tinfoil. Source recordSupports: binding model weights to enclave attestation · whole post