Safeguard attestation

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 ¹. 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 ⁹. 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 ⁸.

The published designs follow one pattern: run the safeguard inside a TEE and have the hardware sign what ran ^{1 4 6}.

• 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 ¹. 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 ¹.
• 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 ⁴. Its defined inputs are the query, model and tokenizer; it has no separate safeguard input ⁴.
• 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 ⁵. Binding weights to attestation is covered in Hardware-attested weight binding.
• Scoped monitoring. In verifiably-scoped monitoring, the monitoring party and the monitored party co-sign a plan, which an open-source classifier runs inside an attested TEE ⁶. Queries outside the plan's scope are never evaluated ⁶.

Two approaches do not use TEEs:

• In a low-trust system design, the verifier re-executes sampled records and screens them itself for compliance, for example for blacklisted uses ¹⁰. See Sampled inference recomputation and Low-trust AI compute verification system overview.
• Prompt Detective compares output distributions to judge whether a given system prompt was used ¹¹. It was developed to detect reuse of proprietary prompts, not to audit declared safeguards ¹¹.

What it establishes

It can establish:

• that the declared guardrail code ran for an attested response, without revealing the developer's agent ¹;
• that tampering is visible: in the authors' tests, modified guardrail code, modified attestation bytes and modified responses were all detected ¹;
• in scoped monitoring, that the monitor evaluated only what the co-signed plan allows ⁶.

It cannot establish:

• that the safeguard works, since guardrails make errors and can be jailbroken ¹;
• that an external guardrail model ran as declared, since the prototype reaches it through an API outside the enclave and leaves trust in that API to the verifier ¹;
• that all traffic was covered, since attestations are per response and the prototype offers them for high-stakes questions ¹;
• anything the measurement leaves out, such as configuration, flags or later changes at runtime ⁸.

Threat model

• Proof of guardrail assumes a developer who might skip or modify the guardrail ¹. 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 ¹.
• PAL*M assumes an adversary who controls the host, hypervisor and disk ⁴. It trusts the Intel TDX module and the H100 GPU ⁴. It treats side-channel defences as orthogonal and places physical attacks, such as memory-bus interposition, out of scope ⁴.
• 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 ⁸.