The Halo Open-Source Project: Building Tamper-Evident Runtime Evidence for AI Agents

The Trust Crisis of AI Agents

As AI agents powered by large language models move from concept to production environments, a previously overlooked problem is coming to the surface: How do we prove what an AI agent actually did?

An AI agent refers to an AI system capable of perceiving its environment, planning autonomously, and executing multi-step tasks—typically with a large language model (LLM) as its core reasoning engine, complemented by tool use, memory modules, and external API integration. To understand the difficulty of auditing such systems, we first need to understand their technical architecture: an agent is usually composed of four modules—an LLM reasoning engine (responsible for understanding instructions and planning steps), a tool-calling layer (allowing the model to invoke external APIs, code interpreters, search engines, etc.), a memory system (divided into short-term context window memory and long-term vector database storage), and an execution feedback loop (the Agent Loop).

At the control-flow architecture level, ReAct (Reasoning + Acting) is currently one of the most widely adopted paradigms. Proposed by Yao et al. (2022), its core idea is to have the LLM alternately generate a "Thought" and an "Action" at each reasoning step, and inject the observation returned by the tool into the next round of reasoning context, forming a closed-loop iteration of Thought → Action → Observation. The Plan-and-Execute paradigm decouples planning from execution: a planner LLM first generates a complete task-decomposition plan, and then an executor invokes tools step by step to complete each subtask. This suits long-horizon tasks with complex dependencies, but at the cost of errors in the planning phase cascading and amplifying across the entire execution chain. The essential difference between these two paradigms directly influences the design of auditing strategies—ReAct's interleaved execution requires collecting evidence at every reasoning-action transition point, while Plan-and-Execute requires simultaneously recording both the planning graph and execution deviations.

It is precisely due to the autoregressive generative nature of LLMs—where the same input can produce different outputs under different temperature parameters and different sampling randomness—that agent behavior carries intrinsic non-determinism, forming a fundamental divergence from the auditable paths of traditional deterministic software. This non-determinism, combined with genuine write access to external systems, makes auditing far more difficult than in traditional software systems.

When agents begin executing tasks autonomously—calling APIs, modifying databases, initiating transactions, accessing sensitive files—every step they take can produce real business consequences. Yet in most existing systems, an agent's runtime process is a black box: logs can be tampered with, execution traces are hard to reproduce, and once a problem arises, assigning responsibility and tracing back the incident becomes nearly impossible.

Recently debuting on Hacker News in the form of a "Show HN" post, the open-source project Halo targets exactly this pain point. It provides AI agents with tamper-evident runtime evidence, attempting to establish verifiable, non-repudiable records for every action an agent takes.

What Problem Does Halo Solve?

From "Observable" to "Provable"

Traditional application monitoring (Observability) focuses on "how is the system running right now," whereas Halo answers a far more demanding proposition: "Can we prove after the fact that the system did indeed run this way at the time?"

The distinction is crucial. The records of an ordinary logging system are writable, deletable, and modifiable—if a malicious actor or a flawed agent tampers with execution records, subsequent audits will remain completely unaware. "Tamper-evident," by contrast, means that any modification leaves a trace and is caught by a verification mechanism.

This design draws on the experience of mature fields such as blockchain, Git commit chains, and transparency logs—especially the Certificate Transparency (CT) framework, proposed by Google in 2013 and now a mandatory standard in the browser HTTPS ecosystem. CT was designed by Google's Ben Laurie and others, and its core data structure is an append-only Merkle Tree. Whenever a CA issues a TLS certificate, it must submit it to at least two independent CT log servers, which return a Signed Certificate Timestamp (SCT); browsers verify the existence of the SCT during the TLS handshake.

What's worth understanding in depth is the "ecosystem game theory" logic behind CT's security model: CT does not rely on trusting any single log provider, but instead builds a Monitor/Auditor Network—independent monitoring programs continuously crawl all public logs, and users or enterprises can subscribe to alert services warning them that "an unknown certificate has appeared for my domain" (Certificate Transparency Monitoring). This design shifts the capability of "detecting attacks" from the log operators to the entire internet community, so any attempt to silently insert or delete records will be exposed through cross-verification by independent observers. CT's security model relies on "split-view attack detection"—cross-verification among multiple independent log providers means that forging or deleting historical records would require compromising multiple parties simultaneously, at an extremely high cost. This mechanism became mandatory as of Chrome 68 in 2018, and today millions of new certificate records are added globally each day, having proven in practice the engineering feasibility of large-scale trusted logs. What Halo borrows is exactly this design philosophy of a "publicly auditable append-only log," applied to the scenario of recording AI agent behavior: through cryptographic hash chains or similar structures, each new record is "bound" to the previous one, so that any mid-stream tampering will break the integrity of the entire chain.

Compliance and Auditing for AI Agents

Since 2024, major regulatory bodies worldwide have begun listing the auditability of AI systems as a mandatory requirement. The EU AI Act (Regulation (EU) 2024/1689) officially took effect in August 2024, imposing clear technical specifications on the logging requirements for high-risk AI systems: Article 12 requires high-risk AI systems to have the capability to automatically record events, with the recorded content being sufficient to trace their operation throughout the system's entire lifecycle; Article 9 requires the retention of complete technical documentation when implementing risk management.

At the technical implementation level, Article 12 of the EU AI Act does not merely require the simple act of "keeping logs," but imposes structural requirements on the logging system: records must be able to support Reconstruction—i.e., the ability to restore the system's complete input-output state at a specific moment; at the same time, logs must possess Accessibility—i.e., regulators must be able to extract and interpret evidence in a standardized way during enforcement investigations. These two points directly constrain the design of auditing systems for AI agents—not only must "what happened" be recorded, but also "why the decision was made this way," meaning the complete reasoning context (prompts, tool-calling chains, model intermediate outputs) must be retained. It is especially worth noting that the Act brings "general-purpose AI models with systemic risk" (GPAI with systemic risk) under additional regulation, directly covering agent systems built on large models such as GPT-4 and Claude, with fines for violations reaching up to 7% of global annual turnover. The AI Risk Management Framework (AI RMF) released by the U.S. NIST also lists "Traceability" as one of its core governance dimensions. In the financial sector, both the U.S. SEC and Europe's ESMA are exploring extending the auditing requirements of algorithmic trading to AI agent decisions; in healthcare, the FDA requires AI-assisted diagnostic systems to retain complete records of the reasoning process. This regulatory trend means that having trustworthy auditing capabilities is no longer just a "nice-to-have" engineering option, but is becoming a threshold for AI agents to enter regulated industries.

Halo's positioning has clear value in the following scenarios:

• Compliance auditing: Regulated industries such as finance and healthcare that deploy autonomous agents must be able to provide a trustworthy chain of behavioral evidence.
• Incident tracing: When an agent makes a wrong decision or causes a loss, teams need to reconstruct "what it saw and what decisions it made at the time."
• Multi-party trust: In scenarios where an agent interacts with third parties on behalf of a user, tamper-evident evidence can serve as a basis for dispute arbitration.

Analysis of the Technical Approach

The Core Mechanism of Runtime Evidence

"Runtime evidence" essentially involves collecting and solidifying state snapshots at key points during an agent's execution—including input prompts, model outputs, the parameters and return values of tool calls, decision paths, and so on. Halo organizes this data into a tamper-evident structure.

Common technical approaches for achieving "tamper-evidence" include:

• Hash Chain: Each record contains the hash of the previous record, forming a chained dependency, i.e., Record_n = Hash(Record_{n-1} || Data_n). Verifying integrity requires a linear scan from start to finish, with a time complexity of O(n), suitable for scenarios with a limited number of records and sequential verification. If an attacker attempts to modify a certain record in the history, that record's hash value will change, causing all subsequent chained hashes to become invalid—exposing the tampering immediately. The engineering implementation of a hash chain is relatively simple; a single SHA-256 hash on a modern CPU takes about nanosecond-level latency, with negligible impact on agent execution performance. However, its linear verification property means that when log scale reaches the millions, the time cost of full verification becomes a practical challenge.

• Merkle Tree: A tree-shaped generalization of the hash chain, and also the shared foundation of systems such as Git version control, the Bitcoin blockchain, and IPFS. Leaf nodes store hashes of the raw data, non-leaf nodes store re-hashes of their child node hashes, and the root node (Merkle Root) is the "fingerprint" of the entire tree. Its key advantage lies in the ability to generate a "Merkle Proof," proving with O(log n) complexity that a specific record belongs to the entire dataset without exposing all the data—for an AI agent auditing system that may contain millions of execution records, this efficient membership proof capability is crucial. In engineering implementation, the Append-only Merkle Tree is a variant widely adopted in CT logs and blockchains: new records can only be added to the rightmost leaf position of the tree, internal nodes update incrementally as new leaves are inserted, and the root hash path of historical records never changes—this property allows an "old version of the Merkle Root" to serve as an immutable proof anchor for historical state, directly corresponding to the AI agent auditing requirement of "proving all behavior before a certain moment." Additionally, the Sparse Merkle Tree can also support "non-membership proof," proving that a certain record was never written, further enhancing the completeness of the audit.

• External anchoring (optional): Periodically committing the root hash of the chain to a public, independent storage or ledger to further enhance non-repudiation.

It is worth specially noting that "tamper-evident" and "tamper-proof" are two distinct goals, and this distinction is extremely important in the field of security engineering. Tamper-proof means physically or logically making the act of tampering itself impossible—for example, Trusted Execution Environments (TEEs) such as Intel SGX and ARM TrustZone provide hardware-level protection through isolated memory regions (Enclaves), and combined with Remote Attestation mechanisms, can prove to a third party that "the code is indeed running on trusted hardware in an untampered state," a stronger root of trust than pure software hash chains. However, the limitations of TEEs are equally obvious: the available memory of an SGX Enclave (EPC, Enclave Page Cache) was only 128MB on early hardware, expanded to 512MB in third-generation Xeon, but still far below the VRAM scale required for large LLM inference, and the performance penalty caused by EPC paging can be several times higher under memory-intensive workloads. Furthermore, SGX has historically been subject to multiple side-channel attacks (such as Spectre, Foreshadow, and SGAxe), shaking its security assumption of "absolute trustworthiness" and requiring solutions that rely on hardware TEEs to continuously track microcode updates and vulnerability disclosures. For software systems, tamper-evidence uses cryptographic means to raise the "concealment cost" of tampering to an extremely high level—which is also the design strategy commonly adopted by mainstream security infrastructure such as blockchain, Git version control, and CT logs, being both engineering-feasible and sufficient to meet most AI auditing needs.

Open-Source Transparency as the Foundation of Trust

Halo's choice of an open-source path has its inherent logic. For a tool whose core value is "trustworthy evidence," the transparency of the code itself is the source of trust. If the verification logic is a closed-source black box, how can users believe that the evidence it generates is reliable? Open source subjects the evidence generation and verification processes to community scrutiny, aligning philosophically with the trust problem the project aims to solve.

This logic has deep precedent in the field of cryptographic engineering: Kerckhoffs's principle (proposed in 1883) long ago pointed out that the security of a cryptographic system should depend only on the secrecy of the key, not the secrecy of the algorithm—modern cryptography has further evolved this into the engineering consensus that "only public scrutiny can bring true security." Widely trusted security infrastructures such as OpenSSL, libsodium, and the Signal Protocol all base their credibility on open-source code subjected to continuous auditing by global security researchers. For AI agent auditing systems, this principle is especially critical: if the evidence generation system itself contains vulnerabilities or backdoors, all the "trustworthy evidence" produced based on it will lose its legal validity and engineering value.

Open Questions Worth Watching

As an early-stage project, Halo still has several questions to observe:

Performance overhead: How much impact does collecting evidence and maintaining cryptographic structures at every execution node have on an agent's latency and throughput? For production systems with high-frequency calls, this is a key trade-off. From an engineering perspective, the overhead of the hash computation itself is minimal, but serialization (converting structured data such as prompts and tool-call parameters into hashable byte streams) and storage I/O are often the actual performance bottlenecks—especially when the evidence needs to include the complete LLM context window, a single record's data volume can reach tens or even hundreds of KB, making write throughput in high-concurrency scenarios a core challenge in system design.

The integrity boundary of evidence: Halo can only prove that "the content it recorded has not been tampered with," but cannot guarantee that its records cover all of the agent's behavior. If certain operations bypass Halo's collection points, blind spots will exist in the evidence chain, requiring careful design at the integration level. This problem is especially prominent in distributed agent systems—when an agent completes tasks through the coordination of multiple microservices and sub-agents, each node needs to independently connect to evidence collection, and the quality of clock synchronization across nodes directly affects the reconstructability of cross-node event sequences.

The tension between privacy and compliance: Runtime evidence often contains sensitive data (such as user inputs and internal decisions). The Merkle tree structure has a natural advantage here—through a Selective Disclosure mechanism, only the content of certain leaf nodes and their Merkle proofs can be exposed without revealing the entire tree's data. Going further, combining Zero-Knowledge Proofs (ZKP) with Merkle trees—via zk-SNARK or zk-STARK—allows a prover to demonstrate to a verifier that "a record meeting certain conditions does exist in the log" without revealing the actual content of the leaf node—for example, proving that "the data accessed by the agent in a certain operation satisfies differential privacy constraints" without disclosing the specific content.

Understanding the engineering differences between zk-SNARK and zk-STARK helps in judging their respective applicable scenarios: zk-SNARK (Succinct Non-interactive ARguments of Knowledge) generates proofs of extremely small size (usually a few hundred bytes) and verifies extremely fast (millisecond-level), but relies on a Trusted Setup—meaning a multi-party computation ceremony is required before system deployment to generate public parameters; if all participants collude, proofs could potentially be forged, which is a security hazard in scenarios requiring decentralized trust. zk-STARK (Scalable Transparent ARguments of Knowledge), by contrast, requires no trusted setup and is based on the quantum-resistant assumptions of hash functions, but produces larger proofs (usually tens to hundreds of KB), requiring trade-offs in storage- and bandwidth-sensitive AI auditing scenarios. This direction already has extensive engineering practice in the field of blockchain privacy computing, and with progress in recursive proofs and hardware-accelerated ZKP chips (such as Ingonyama's ICICLE framework and Cysic's ZKP ASIC), it is expected to enter the practical stage in the AI auditing field within the next two to three years, providing stronger technical support for balancing privacy protection with verifiable auditing.

Conclusion: The Next Piece of the AI Infrastructure Puzzle

When the industry's enthusiasm pours heavily into the "capabilities" of agents—stronger reasoning, more tools, more autonomous planning—Halo reminds us to focus on a dimension that is equally critical yet easily overlooked: accountability.

An autonomous AI system that cannot be audited or proven can hardly truly enter high-risk, heavily regulated production scenarios. From this perspective, tools for tamper-evident runtime evidence represent an indispensable link in the process of AI agents moving from "demo prototypes" to "production-grade infrastructure." Historically, every generation of emerging computing paradigms has undergone similar infrastructure catch-up: the early boom of the internet gave rise to SSL/TLS, the PKI system, and firewalls; the popularization of cloud computing drove the maturation of security infrastructure such as IAM (Identity and Access Management) and SIEM (Security Information and Event Management); today, the large-scale deployment of AI agents likewise requires establishing its own Trusted Computing Base. Whether Halo can grow into the standard solution in this field remains to be tested by time, but the direction it points to—establishing trustworthy, auditable records for AI behavior—will undoubtedly become increasingly important amid the wave of large-scale agent deployment.

Key Takeaways