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

Abstract: As AI agents become widely deployed as online services, users often rely on an agent developer's claim about how safety is enforced, which introduces a threat where safety measures are falsely advertised. To address the threat, we propose proof-of-guardrail, a system that enables developers to provide cryptographic proof that a response is generated after a specific open-source guardrail. To generate proof, the developer runs the agent and guardrail inside a Trusted Execution Environment (TEE), which produces a TEE-signed attestation of guardrail code execution verifiable by any user offline. We implement proof-of-guardrail for OpenClaw agents and evaluate latency overhead and deployment cost. Proof-of-guardrail ensures integrity of guardrail execution while keeping the developer's agent private, but we also highlight a risk of deception about safety, for example, when malicious developers actively jailbreak the guardrail. Code and demo video: https://github.com/SaharaLabsAI/Verifiable-ClawGuard

• The paper introduces cryptographic attestation of AI guardrails through trusted execution environments to verify that declared safety measures are executed.
• It details an end-to-end system that binds user input and agent responses to open-source guardrail code while preserving proprietary confidentiality.
• Empirical validation demonstrates robust tamper detection and manageable latency overhead, emphasizing the balance between security and performance.

Proof-of-Guardrail: Cryptographic Attestation of Safety Measures in AI Agents

Motivation and Context

The proliferation of AI agents with increasing autonomy and ability to make complex decisions has heightened scrutiny of their safety and trustworthiness, especially in deployment contexts where users must depend on APIs or hosted services without direct visibility into how the system is governed. Existing paradigms for safety, which rely on the presence of guardrails—mechanisms to restrict responses or enforce policy—are undermined by the impossibility of independently verifying guardrail application in the traditional SaaS model without full code and execution transparency. This creates a latent security risk: a developer may either omit, misconfigure, or falsely advertise the presence or integrity of guardrails for user-facing agents.

Proof-of-guardrail provides a robust yet practical response to this challenge, leveraging trusted execution environments (TEEs) and remote attestation to produce cryptographic, user-verifiable evidence that a declared open-source guardrail was in fact enforced for a specific agent response. Notably, this scheme preserves agent implementation confidentiality, which is essential for protection of proprietary models and system prompts, while decoupling safety traceability from third-party trust or centralized auditing. The architecture and user-facing benefits are summarized in (Figure 1).

Figure 1: Proof-of-guardrail enables users to cryptographically verify that declared guardrails were executed for each agent response, enhancing trust for agent-mediated services.

System Design

The core protocol operationalizes verifiable safety by executing the guardrail and agent inside a TEE, typically realized via AWS Nitro Enclaves. The public guardrail logic $g$, as well as a wrapper program $f$ which orchestrates the pre- and post-processing of I/O (including tool invocation mediation), are loaded and measured at enclave instantiation. The developer's proprietary agent $A$ is loaded as a secret input, consistent with TEE confidentiality properties (Figure 2).

Upon user request, the system generates an attestation document $\sigma$, which includes a measurement $m$ (essentially a hash capturing the exact binary identity of $f$ and $g$ as loaded), and a commitment $d = \mathsf{Hash}(x, r)$, where $x$ is the user input and $r$ the agent response. This attestation is signed by the platform's hardware-protected signing key. Users or downstream agents can then verify the signature and the hash against the open-source code of $f$ and $g$, the observed input and output, and the published platform key. This provably demonstrates that the response was generated only after the known, unmodified guardrail was executed on the particular user input.

Figure 2: End-to-end flow of proof-of-guardrail: (a) guardrail and wrapper are measured in a TEE enclave, (b) the TEE generates an attestation with measurement and I/O commitment, (c) offline verification is enabled for any user.

Importantly, agent $A$ does not need to be disclosed publicly; it is loaded as a confidential payload, which maintains IP security for developers while enforcing externally-auditable safety. A fresh attestation is produced per interaction, binding each response individually.

Empirical Validation

The proof-of-guardrail system was implemented using OpenClaw agents with GPT-5.1, deployed on AWS Nitro Enclave m5.xlarge instances. Two primary classes of guardrails were evaluated: a content safety guardrail (Llama Guard3-8B) and a factuality guardrail (Loki). Test datasets included the ToxicChat (for content moderation) and FacTool-KBQA (for factuality assessment).

Performance results show that the proof-of-guardrail scheme introduces an average latency overhead of 25–38% for guardrail execution and response generation, with attestation generation adding a fixed 100 ms per interaction. While the switch from baseline t3.micro to m5.xlarge instances (driven by enclave memory requirements) implies a roughly 18$\times$ cost increase, the additional expenses are within reasonable bounds for applications where agent trust is critical.

Attack simulations—such as code tampering in guardrails, modification of attestation documents, or manipulation of outputs—were all reliably detected via failed attestation verification, showing robustness to common developer or infrastructure-side threats. An example transcripted interaction illustrates how, in a typical user-bot session, verifiable attestation data can be provided on-demand for user evaluation, directly addressing trust in high-stakes decision queries.

Security Scope, Limitations, and Threat Modeling

A critical result emphasized in the work is that proof-of-guardrail attests only to execution of the declared guardrail, not to the absolute functional safety of the agent. There remain several important limitations:

• Guardrail Quality and Jailbreakability: Open-source guardrails may have false negatives, as reflected in accuracy/F1 results (e.g., Llama Guard3-8B achieves 0.88 F1 for safe content but only 0.56 for unsafe content). Furthermore, a malicious developer could actively jailbreak the guardrail, since the proof only asserts the code as executed, not its performance boundaries.
• Measured Program Integrity: The measured wrapper program $f$ must be free of vulnerabilities that could allow the confidential agent $A$ to subvert mediation, for instance by executing arbitrary code inside the enclave. Bypasses are possible if $A$ is not strictly sandboxed.
• Hardware and Platform Root of Trust: The scheme assumes trust in the TEE platform provider (e.g., AWS Nitro hypervisor or Intel attestation infrastructure). Side-channel leakage or TEE compromise is out of scope, but this is consistent with TEE assumptions in other confidential computing applications.

Consequently, proof-of-guardrail reduces the attack surface for developer-side false claims about deployed safety measures but does not deliver proof-of-safety for the agent output. Adoption of attested, benchmarked, and community-validated guardrails is necessary for practical risk reduction; the establishment of best-practice guardrails should be community-driven, leveraging benchmarks and red-teaming.

Practical and Theoretical Implications

Practically, proof-of-guardrail provides a scalable foundation for higher-trust agent markets, particularly in decentralized environments where no central auditor exists or where multi-participant evaluations are necessary (e.g., marketplaces, agent platforms, or regulated sectors). The approach de-risks the composition of proprietary and open-source safety logic, enables user choice by exposing verifiable evidence, and incentivizes adoption of empirically-validated safety measures.

Theoretically, the work underscores that attestation technologies (rather than solely cryptographic program proofs or zero-knowledge approaches) are currently the most efficient method to deliver agent governance traceability at scale. However, the system’s security properties are inherently bounded by the class of measurable properties in the open-source guardrail and trust model of the TEE.

Future Directions

Potential future work includes: hardened and formally-verified wrapper programs $f$, integration with streaming guardrails for low-latency generation, establishing dynamic or compositional policy proofs for multi-guardrail settings, and expanding the registry of community-endorsed guardrail benchmarks. Deployment to diverse agentic platforms (e.g., social bots, code-calling agents, API brokers) will elucidate tradeoffs in latency, cost, and utility for different market segments.

Adoption may catalyze further research in agent-in-the-loop verification, post-hoc red-teaming, and cross-provider attestation standards, ultimately enabling a more programmable and trustworthy agent ecosystem.

Conclusion

Proof-of-guardrail offers a technically-sound, deployable solution to the problem of verifying safety enforcement in remote AI agents, leveraging trusted hardware to cryptographically audit the execution of open-source guardrails without revealing proprietary agent details. The approach constitutes a significant advance in aligning developer incentives with safety transparency. Nevertheless, guaranteeing holistic agent safety remains contingent on the ongoing advancement and standardization of robust guardrail implementations, as well as the establishment of clear best-practices within the community.