Proof-of-Guardrail in AI Agents and What (Not) to Trust from It

This paper proposes "Proof-of-Guardrail," a system leveraging Trusted Execution Environments to provide cryptographic, verifiable attestation that AI agents enforce specific safety measures, thereby addressing the threat of falsely advertised safety while acknowledging remaining risks like active jailbreaking.

The Gist

Here is an explanation of the paper "Proof-of-Guardrail" using simple language, everyday analogies, and creative metaphors.

The Core Problem: The "Trust Me" Trap

Imagine you are ordering food from a new, mysterious restaurant that delivers via a drone. The restaurant claims, "Don't worry! We have a strict Health Inspector who checks every single meal before it leaves the kitchen to make sure it's safe and fresh."

You have a problem: You can't see inside their kitchen. You have to take their word for it.

• The Risk: What if the restaurant is lying? What if they skipped the inspector, or worse, what if they hired a corrupt inspector who just stamps "Safe" on poisoned food?
• The Current Reality: In the world of AI, users often have to trust developers blindly. Developers say, "We use safety filters to stop our AI from saying mean things or giving bad advice." But since the AI runs on the developer's private servers, users can't verify if those filters are actually working.

The Solution: The "Tamper-Proof Receipt"

The authors propose a system called Proof-of-Guardrail.

Think of this not as a promise, but as a cryptographic receipt that proves the safety check actually happened.

Here is how it works, using a Bank Vault analogy:

1. The Special Room (The TEE):
   Imagine the developer has to run their AI inside a special, high-tech Bank Vault (called a Trusted Execution Environment or TEE). This vault is made of unbreakable steel and is monitored by a hardware security system.

   • Why? Inside this vault, the developer can put their secret AI recipe (which they don't want to share), but they must also put in the public "Safety Inspector" (the Guardrail).

2. The Process:
   When a user asks the AI a question, the question goes into the Vault.

   • The AI thinks about the answer.
   • The Safety Inspector checks the answer.
   • If the answer is safe, the Vault lets it out.
   • If the answer is dangerous, the Vault blocks it.

3. The Magic Receipt (The Attestation):
   Crucially, the Vault has a built-in camera and a digital stamp. Every time it lets an answer out, it prints a signed receipt.

   • This receipt says: "I, the Vault, confirm that the Safety Inspector checked this specific answer before it left."
   • The receipt is signed with a unique key that only the Vault hardware possesses. It is mathematically impossible to fake.

4. The User's Check:
   The user receives the answer and the receipt. They don't need to trust the developer. They just need to check the receipt against the public rules of the Safety Inspector. If the receipt is valid, they know for a fact that the safety check happened.

Why This is a Big Deal

• Privacy vs. Proof: Usually, to prove you are safe, you have to show your whole kitchen (your code) to the public. This system lets you keep your secret recipes (your private AI) hidden inside the vault, while still proving you followed the safety rules.
• No Middleman: You don't need a third-party auditor to come inspect the kitchen. The Vault does the auditing automatically and instantly.

The Catch: It's Not a "Safety Guarantee"

The paper ends with a very important warning. Proof-of-Guardrail is not the same as Proof-of-Safety.

Let's go back to the restaurant analogy:

• What the receipt proves: "The Health Inspector looked at the burger."
• What the receipt does NOT prove: "The burger is actually good."

The Risks:

1. The Inspector Might Be Wrong: Even if the inspector checks the burger, they might miss a hair in it. The paper shows that safety filters (Guardrails) aren't perfect; they sometimes let bad things through or block good things.
2. The "Jailbreak" Trick: If the developer is malicious, they might try to trick the Safety Inspector. Imagine the developer whispers to the inspector, "Hey, this burger looks like a toy, so you don't need to check it." If the inspector is fooled, the receipt still says "Checked," but the food is still bad.

The Bottom Line

Proof-of-Guardrail is like a tamper-proof seal on a medicine bottle.

• It proves the bottle was sealed by the factory (the safety check happened).
• It proves the seal wasn't broken in transit.
• But, it doesn't guarantee the medicine inside is effective or that the factory didn't put the wrong pills in the bottle to begin with.

Why use it?
In a world full of shady AI developers, this system allows honest developers to say, "Look, I have the seal to prove I'm playing by the rules," which builds trust. But users should still be smart and know that the seal doesn't mean the product is perfect.

Technical Summary

Here is a detailed technical summary of the paper "Proof-of-Guardrail in AI Agents and What (Not) to Trust from It."

1. Problem Statement

As AI agents are increasingly deployed as online services (e.g., chatbots, automated trading bots), users rely on developers' claims regarding safety measures. However, a critical trust gap exists:

• The Threat: Developers may falsely advertise that safety guardrails (rules restricting tool calls or content) are being enforced. They might skip guardrails entirely, use modified versions, or "jailbreak" them to generate unsafe or misleading responses while claiming compliance.
• The Limitation of Current Solutions:
  • Public Audits: Requiring developers to open-source their entire agent implementation (including proprietary prompts and logic) for public audit is unrealistic due to intellectual property concerns.
  • Third-Party Auditors: In decentralized or cross-platform deployments, there is no universally trusted third party to verify execution.
• The Goal: Create a system where users can cryptographically verify that a specific, open-source guardrail was executed to generate a response, without forcing the developer to reveal their private agent implementation.

2. Methodology: Proof-of-Guardrail

The authors propose Proof-of-Guardrail, a lightweight system leveraging Trusted Execution Environments (TEEs) and Remote Attestation.

Core Architecture

1. Wrapper Program ($f$): The developer creates a wrapper program that bundles the open-source guardrail ($g$) and the logic to mediate inputs/outputs. This program is public and verifiable.
2. Private Agent ($A$): The developer's proprietary agent logic is treated as a secret input ($s$). It is loaded into the TEE but is never exposed to the outside world.
3. Execution Flow:
   • The wrapper $f$ runs inside a TEE (e.g., AWS Nitro Enclaves).
   • For a user input $x$, the TEE executes $f$, which invokes the private agent $A$ and enforces the guardrail $g$.
   • The system produces a response $r$.
4. Attestation Generation:
   • The TEE hardware generates a signed attestation document ($\sigma$).
   • This document includes:
     • Measurement ($m$): A cryptographic hash of the wrapper program $f$ (proving the exact code ran).
     • Commitment ($d$): A hash of the input $x$ and output $r$ (binding the specific response to the execution).
     • Signature: Signed by the TEE platform's private key, rooted in a hardware trust anchor (e.g., Intel or AWS).
5. Verification:
   • The user receives $r$ and $\sigma$.
   • The user verifies the signature using the TEE platform's public key.
   • The user checks if the measurement $m$ matches the hash of the known open-source guardrail wrapper $f$.
   • The user checks if the commitment $d$ matches the hash of their input and the received response.

Key Design Principles

• Computational Integrity: Proves the guardrail code actually ran.
• Confidentiality: The private agent logic ($A$) remains hidden inside the TEE as a secret input.
• No Trusted Third Party: Verification is done offline by the user using public keys and open-source code.

3. Key Contributions

• Novel System Design: Introduced "Proof-of-Guardrail," the first system to enable cryptographic verification of safety enforcement in AI agents without compromising proprietary agent logic.
• Implementation & Evaluation: Successfully implemented the system using OpenClaw agents (a powerful open-source agent framework) and AWS Nitro Enclaves.
• Security Analysis: Demonstrated that the system is robust against tampering, including code modification, attestation byte alteration, and response modification.
• Critical Risk Identification: Highlighted that while the system proves execution, it does not guarantee safety if the guardrail itself is flawed or jailbroken.

4. Experimental Results

The authors evaluated the system on AWS m5.xlarge instances using GPT-5.1 as the backend model.

Security Verification

• Attack Simulations: The system successfully detected 100% of simulated attacks, including:
  • Modifying the guardrail code (Measurement mismatch).
  • Modifying the attestation document (Signature invalid).
  • Modifying the response after generation (Hash mismatch).

Performance & Cost

• Latency Overhead:
  • TEE execution introduced a 25% to 38% latency overhead compared to non-TEE baselines.
  • Attestation generation added ~100ms.
  • Total overhead was deemed acceptable for human-chatbot interactions.
• Cost:
  • TEE instances (m5.xlarge) cost ~18.5x more than standard instances (t3.micro).
  • The authors argue that in low-trust markets, the value of user trust gained via proof outweighs the infrastructure cost.

Guardrail Efficacy

• Tested with Llama Guard 3 (Content Safety) and Loki (Fact Checking).
• Results showed imperfect accuracy (e.g., Llama Guard 3 had an F1 of 0.56 for "Unsafe" detection), reinforcing that the proof validates process, not outcome quality.

5. Significance and Limitations

Significance

• Trust Mechanism: Provides a verifiable alternative to "trust us" claims, allowing users to cryptographically confirm safety measures were applied.
• Market Differentiation: Enables honest developers to distinguish their agents from malicious ones, potentially unlocking partnerships and user adoption in a low-trust environment.
• Privacy Preservation: Solves the dilemma of verifying safety without exposing proprietary AI logic.

Limitations & Risks (Crucial Nuance)

The paper explicitly warns that Proof-of-Guardrail $\neq$ Proof-of-Safety.

1. Guardrail Errors: If the open-source guardrail itself is inaccurate (e.g., fails to detect toxicity), the proof will still validate the execution of that flawed guardrail.
2. Jailbreaking: A malicious developer could jailbreak the open-source guardrail before or during execution. The TEE proves the guardrail ran, but not that it successfully blocked the malicious intent.
3. Wrapper Vulnerabilities: If the wrapper program $f$ has vulnerabilities, a private agent could potentially bypass the guardrail logic within the enclave.

Recommendation: The authors advocate for a "Best-Practice" approach where the community agrees on high-quality, red-teamed open-source guardrails. Users should verify the proof and trust the quality of the underlying guardrail code.

Conclusion

"Proof-of-Guardrail" represents a significant step toward verifiable AI safety. By combining TEEs with remote attestation, it shifts the burden of trust from the developer's word to cryptographic evidence. However, it is a tool for verifying integrity of execution, not a guarantee of safety outcomes, and must be used in conjunction with robust, community-vetted guardrail standards.