Proof-of-Guardrail: Cryptographic Evidence That Your Agent's Safety Net Actually Ran

The Trust Problem Nobody Talks About

Update, September 2026. The paper’s arXiv listing shows a June 26, 2026 revision (v2), but no itemized changelog, so the 0.54 recall, 34% latency, and 18.5x cost figures below are unconfirmed as changed. Sahara AI’s Verifiable-ClawGuard reference implementation remains a 7-star proof-of-concept, explicitly “not production-ready.” The EU AI Act’s Article 113 deadlines cited below (December 2, 2027 and August 2, 2028) still hold after the Digital Omnibus delay.

When you use a financial agent to manage your portfolio, the developer’s landing page says “protected by Llama Guard.” When a medical information agent answers your question about drug interactions, the API documentation promises “all responses are safety-filtered.”

How do you know any of that is true?

You do not. There is no mechanism in the current agent ecosystem for a user to verify that a declared guardrail actually executed. The developer could skip the guardrail entirely, misconfigure it, or route around it for certain queries. You would never know. The safety claim is unfalsifiable by design.

This is not a hypothetical concern. In Article 5 of the agent series, I mapped the three guardrail layers every agent needs: input safety, reasoning validation, and output quality. That article focused on what to check. This paper addresses a different question: how do you prove the check actually happened?

Jin et al. at Sahara AI and USC propose an answer in their March 2026 paper Proof-of-Guardrail in AI Agents and What (Not) to Trust from It. The mechanism uses Trusted Execution Environments (TEEs) to produce cryptographic attestations that a specific guardrail ran on a specific input and produced a specific output. The attestation is verifiable by any user, offline, without trusting the developer.

The paper is worth decoding for two reasons. First, the technical contribution is genuinely novel: hardware-backed proof of guardrail execution is a step beyond “trust us, we run safety checks.” Second, the paper is unusually candid about what the proof does and does not guarantee. The “(Not)” in the title is doing real work.

The Paper in 90 Seconds

Seven authors from Sahara AI and the University of Southern California. The core contribution is a three-stage protocol.

Stage 1: Initialization. The developer deploys a wrapper program (containing the open-source guardrail) into an AWS Nitro Enclave, a hardware-isolated Trusted Execution Environment. The TEE records a cryptographic hash of the wrapper binary. This hash, called the “enclosure measurement,” is the fingerprint of the exact code that will run.

Stage 2: Proof Generation. When a user sends input x, the wrapper executes the guardrail on the agent’s response: r = g(x, A). The TEE then generates a signed attestation document containing two commitments: the enclosure measurement (proving which code ran) and a hash of the input and output (proving which data flowed through).

Stage 3: Verification. The user receives the response and the attestation. They verify three things offline: (1) the TEE’s signature is valid (using the cloud platform’s public verification keys), (2) the enclosure measurement matches the known hash of the open-source guardrail code, and (3) the input/output hash matches the actual input and response they received. If all three checks pass, the user has cryptographic evidence that the declared guardrail executed.

The protocol preserves developer confidentiality. The agent’s proprietary logic (the system prompt, the fine-tuned model, the tool-calling strategy) stays secret inside the enclave. The guardrail must be open-source so users can verify the measurement hash, but the agent behind it does not need to be.

What It Actually Proves

The paper’s Section 3 is precise about the security guarantees. Four properties hold when verification succeeds.

Computational integrity. The guardrail g provably executed when generating response r for input x. The TEE’s attestation mechanism ensures this; forging an attestation would require compromising the TEE hardware itself.

Code authenticity. The enclosure measurement m is a hash of the exact binary that ran. If the developer modifies a single line of guardrail code, the hash changes, and verification fails. The paper tested this: 10 out of 10 code modification attacks were detected through measurement mismatch.

Output binding. The hash commitment d = Hash(x, r) binds the specific input and output to the attestation. If the developer swaps in a different response after guardrail execution, the hash will not match. The paper tested 100 response-modification attacks; all 100 were detected.

Non-repudiation. The attestation is signed by the TEE platform’s key. The developer cannot later deny that the guardrail ran (or did not run) for a given interaction.

These are strong guarantees. They close a real gap in the current agent trust model.

What It Does NOT Prove

Section 5 of the paper is where it gets interesting, and where I respect the authors most. They explicitly enumerate what Proof-of-Guardrail should “not be interpreted or advertised as proof of safety.”

Guardrails Make Mistakes

The paper benchmarks two guardrails: Llama Guard3-8B for content safety and Loki for factuality verification. The results are sobering.

For practitioners: Llama Guard3 caught only 54% of unsafe content on the paper’s benchmark. Loki missed 19% of non-factual claims in the paper’s factuality test set. Proving that these guardrails ran does not prove the response is safe or factual. It proves the imperfect check happened.

This is the compound error problem I described in the guardrails article: an agent with 85% per-step accuracy fails 80% of the time over 10 steps. Proof-of-Guardrail does not improve the guardrail’s accuracy. It proves the accuracy-limited check occurred.

Open-Source Guardrails Can Be Jailbroken

Here is the sharpest limitation. Because the guardrail g must be open-source (so users can compute the expected measurement hash), a malicious developer has full access to the guardrail’s code, weights, and decision boundaries. They can study it, find its weaknesses, and craft inputs that pass the guardrail while still producing harmful outputs.

The paper gives a concrete example: “[A] financial news agent can present proof-of-guardrail while still mislead users with false advice in responses after jailbreaking the guardrail.” The attestation would be valid. The proof would verify. The response would still be harmful.

This connects directly to the jailbreak vulnerability I covered in the guardrails article. Authority impersonation was the dominant attack vector, achieving a 45% success rate against the safety guardrails of leading models, including Claude Sonnet 4.5, in a February 2026 medical AI red-teaming study. If the attacker is the developer (who knows the guardrail inside out), success rates would likely be higher.

Two more caveats the paper names directly: the trust root is the cloud provider’s TEE, so you are trusting AWS Nitro to measure and sign honestly, and the wrapper program itself can carry bugs that let the agent route around the guardrail entirely.

The Reasoning Layer Remains Unprotected

The paper’s guardrails operate at the input and output layers: Llama Guard checks whether content is safe before it goes out; Loki checks whether claims are factual. Neither addresses the reasoning layer: the gap between tool results and the context window where unvalidated data enters the agent’s decision-making environment.

In the three-layer guardrail framework I described, the missing middle is the layer where the hardest agent failures cluster. Proof-of-Guardrail can prove that output-layer filtering ran. It cannot prove that the data the agent reasoned over was accurate, timely, or consistent, because no guardrail in the current framework covers that boundary.

The Performance Tax

Running inside a TEE is not free.

The paper reports a 34% average latency overhead across its full task set; the four representative tasks above range from about 25% to 38%. For a content safety check, that is roughly 125 ms of additional latency. For factuality verification (which already takes 16-20 seconds due to web-search-based claim checking), the overhead is less noticeable in relative terms.

The cost overhead is steeper. A non-TEE t3.micro instance costs $0.0104/hour. An m5.xlarge with Nitro Enclave support costs $0.192/hour, an 18.5x increase. The reason: the Nitro Enclave requires an entire runtime environment (Linux kernel, dependencies, memory buffers) isolated inside the enclave, which demands a larger instance type.

What this looks like in practice. For high-stakes deployments (financial advice agents, medical information, legal analysis), 34% latency and 18.5x cost may be acceptable. For consumer-facing chatbots handling millions of requests at thin margins, the economics do not work today.

Where This Fits in AI Governance

The AI Governance framework I wrote about earlier maps a three-lines-of-defense model for enterprise AI oversight.

First line (developers): build the guardrail and deploy it inside a TEE.

Second line (risk and oversight): verify the enclosure measurement matches the approved guardrail version. This is where Proof-of-Guardrail provides the most operational value. The second line no longer has to trust the first line’s assertion that guardrails are running. They can verify cryptographically.

Third line (audit): review attestation logs as evidence of control execution. When a regulator asks “were your safety controls active during this incident?”, a TEE attestation is stronger evidence than a log entry that the developer could have fabricated.

The EU AI Act creates regulatory weight behind this. Article 10 requires documented Data Governance and management practices for high-risk AI systems. When high-risk obligations become applicable, December 2027 for Annex III systems and August 2028 for Annex I systems under Article 113, the ability to produce cryptographic evidence of safety control execution, not just a policy document claiming controls exist, could become a meaningful differentiator in compliance reviews.

The related work section of the paper positions Proof-of-Guardrail alongside “attestable audits” (Schnabl et al. 2025), which prove a model passed security audits, and “property attestation” (Chantasantitam et al. 2026), which certify model properties via verifiable cards. Proof-of-Guardrail sits at a different layer: it does not attest to the model’s properties. It attests that a specific safety check ran on a specific interaction. This is runtime evidence, not pre-deployment certification.

The Jailbreak Paradox

The paper introduces a paradox that I think will define the next phase of the guardrail debate.

For Proof-of-Guardrail to work, the guardrail must be open-source. Users need the source code to compute the expected measurement hash for verification. But making the guardrail open-source gives adversaries (including malicious developers) a complete map of the guardrail’s decision boundaries. They can systematically probe for blind spots, craft adversarial inputs that pass the guardrail, and produce harmful outputs with valid cryptographic proof attached.

The paper acknowledges this directly: “A malicious agent developer can perform jailbreak attack against the guardrail.”

This is not a flaw in the paper’s design. It is a fundamental tension in verifiable safety systems. Verification requires transparency. Transparency enables adversarial exploitation. The authors propose mitigation through community-established “best-practice” guardrails that undergo extensive red-teaming and benchmarking. But they do not claim to solve the paradox.

The agent-era restatement: from a governance perspective, this means Proof-of-Guardrail is best understood as one layer in a defense-in-depth strategy, not a standalone safety guarantee. It proves a check happened. It does not prove the check was sufficient. Organizations still need the full guardrail stack: input filtering, reasoning-layer validation, output checks, human oversight, and continuous monitoring. What TEE attestation adds is auditability of whether those checks actually ran.

Practical Implications

For agent developers: if you serve high-stakes domains (finance, healthcare, legal), Proof-of-Guardrail offers a credible trust signal that differentiates you from competitors who merely claim guardrails. The 34% latency overhead and 18.5x cost increase are the price of that signal. Whether the premium is worth it depends on your user base’s risk tolerance and willingness to pay.

For enterprise buyers: ask your agent vendors whether they can provide cryptographic attestation of guardrail execution. Most cannot today. The question itself signals sophistication and puts pressure on the market to adopt verifiable safety practices.

For AI Governance teams: do not equate Proof-of-Guardrail with proof of safety. The paper itself warns against this. Use TEE attestation as evidence of control execution (the third line of defense needs this), but maintain independent evaluation of guardrail effectiveness. A provably-executed guardrail with 54% recall on the paper’s unsafe-content benchmark is still a guardrail that misses nearly half of unsafe content on that test.

For regulators: Proof-of-Guardrail provides a model for what “demonstrable safety controls” could look like under frameworks like the EU AI Act. The cryptographic attestation is tamper-evident, machine-verifiable, and does not require trusting the developer’s self-reported compliance.

import hashlib
import json

def verify_proof_of_guardrail(
    attestation: dict,
    user_input: str,
    agent_response: str,
    expected_measurement: str,  # Hash of open-source guardrail binary
) -> dict:
    """Simplified verification of a Proof-of-Guardrail attestation.

    In production, signature verification uses the TEE platform's
    public key chain (e.g., AWS Nitro root certificate).
    """
    reasons = []

    # 1. Verify enclosure measurement matches open-source guardrail
    reported_measurement = attestation.get("pcr2")  # AWS Nitro PCR2
    if reported_measurement != expected_measurement:
        reasons.append(
            f"Measurement mismatch: expected {expected_measurement[:16]}..., "
            f"got {reported_measurement[:16]}..."
        )

    # 2. Verify I/O commitment
    expected_hash = hashlib.sha256(
        (user_input + agent_response).encode()
    ).hexdigest()
    reported_hash = attestation.get("custom_data_digest")
    if reported_hash != expected_hash:
        reasons.append("I/O hash mismatch: response may have been modified")

    # 3. Signature verification (platform-specific, simplified here)
    sig_valid = attestation.get("tee_signature_valid", False)
    if not sig_valid:
        reasons.append("TEE signature invalid or unverifiable")

    return {
        "guardrail_provably_ran": len(reasons) == 0,
        "reasons": reasons,
        # The critical distinction the paper makes:
        "safety_guaranteed": False,  # Always False. Proof != safety.
    }


# Example usage
attestation_doc = {
    "pcr2": "a1b2c3d4e5f6...",          # Enclosure measurement
    "custom_data_digest": "f7e8d9c0...", # Hash(input + response)
    "tee_signature_valid": True,
}

result = verify_proof_of_guardrail(
    attestation=attestation_doc,
    user_input="Should I invest all $20,000 in XYZ token?",
    agent_response="I'd recommend diversifying rather than concentrating...",
    expected_measurement="a1b2c3d4e5f6...",
)
# {'guardrail_provably_ran': True, 'reasons': [], 'safety_guaranteed': False}

Note the safety_guaranteed: False field. It is always False, regardless of verification outcome. That single boolean captures the paper’s central message.

What the Paper Gets Right

Three things stand out.

Honesty about limitations. Academic papers in AI safety tend to oversell. This paper spends as much space on what the proof does not guarantee as on what it does. Section 5 (“What Not to Trust”) is required reading for anyone evaluating agent safety claims.

Practical implementation. The authors built a working system on AWS Nitro Enclaves with OpenClaw agents and GPT-5.1, deployed it on Telegram, and measured real latency and cost. This is not a whiteboard protocol. It is a tested system with published performance numbers.

The right abstraction level. Proof-of-Guardrail does not try to prove that agents are safe. It proves that a specific check ran. This is the correct decomposition: separate the question “did the control execute?” from “is the control sufficient?” The first question has a clean cryptographic answer. The second requires ongoing evaluation, red-teaming, and governance, the kind of continuous oversight I described in the AI Governance framework.

What Remains Open

Reasoning-layer attestation. The paper’s guardrails cover input and output filtering. The reasoning layer (tool-result validation, context quality checks, contradiction detection) has no guardrail to attest. Until the industry develops standardized reasoning-layer guardrails, TEE attestation cannot cover the boundary that, in the three-layer framework, is where the hardest agent failures cluster.

Guardrail standardization. The paper notes that establishing “best-practice” guardrails requires a community process: “research, benchmarks, red-teaming.” No such standard exists today. Without consensus on what constitutes a sufficient guardrail, attestation proves that something ran, but not that the right thing ran.

Multi-agent attestation chains. The paper addresses single-agent attestation. Enterprise deployments increasingly use multi-agent architectures where sub-agents delegate to other sub-agents. Extending Proof-of-Guardrail to produce attestation chains across agent boundaries is an open problem.

Cost reduction. The 18.5x cost increase makes Proof-of-Guardrail impractical for high-volume, low-margin deployments. Confidential computing hardware is improving (AWS, Intel, and AMD all have active TEE roadmaps), but the cost curve needs to flatten significantly before attestation becomes a default rather than a premium feature.

Do Next