The Conventional Wisdom
Security teams are rushing to implement tamper-evident logging for AI agents. The logic seems sound: hash-chained logs prevent modification, cryptographic signatures prove authenticity, and you have an audit trail that satisfies emerging standards like AIUC-1. Problem solved.
Tools like halo-record make this easier than ever. With 5,300 lines of Python and no runtime dependencies, you can integrate it into your agent framework and start generating verifiable logs. When something goes wrong, you'll have an immutable record of what your agent did.
Why It's Incomplete
Tamper-evident logs address the wrong problem first.
Sure, you need to know that log entries weren't modified after the fact. But the tougher question is: how do you know you're seeing all the log entries? A hash chain proves each entry links to the previous one. It doesn't prove your agent didn't take 50 other actions that never made it into the chain.
Consider the Hugging Face incident from July. An intruder executed 17,600 actions over five days. Imagine if that attacker had access to your logging infrastructure. They could:
- Selectively log only benign actions
- Complete the hash chain correctly
- Present you with a "tamper-evident" log that's technically valid but functionally worthless
The hash chain would verify. The signatures would check out. And you'd have no idea what actually happened.
This isn't theoretical. Your AI agent runs in the same environment as its logging code. If an attacker compromises the agent, they likely control the logger too. Tamper-evidence protects against modification. It doesn't protect against omission.
The Evidence
Look at how we handle this problem elsewhere in security architecture.
When you implement PCI DSS v4.0.1 Requirement 10.2.2, you don't just log authentication attempts on the system being accessed. You send those logs to a separate collector that the application server can't modify. The segregation matters more than the cryptography.
SOC 2 Type II auditors ask about log forwarding and retention controls because they know local logs are vulnerable. The question isn't "can someone change this log entry?" It's "can someone prevent this log entry from existing?"
Even halo-record's developer acknowledges this gap. The package provides hash-chained integrity, but you need an external witness to ensure completeness. That witness requirement isn't optional security theater. It's the difference between a log you can trust and a log you merely can't modify.
What to Do Instead
Start with segregation, then add tamper-evidence.
First, get logs off the agent's host. Your AI agent should write to a logging endpoint it doesn't control. Use syslog, a message queue, or a dedicated logging API. The agent can append entries but can't read, modify, or selectively omit them. This solves the completeness problem before you worry about the integrity problem.
Second, implement the external witness pattern. Every N seconds, your logging infrastructure should publish a checkpoint to a service the agent can't access. This could be:
- A blockchain or distributed ledger (if you need public verifiability)
- A hardware security module with a trusted timestamp
- A separate logging service that signs and timestamps checkpoints
The witness doesn't need to see every log entry. It just needs to periodically confirm "at timestamp T, the log chain had hash H and contained N entries." If your agent later presents a log that doesn't match these checkpoints, you know something's missing.
Third, add tamper-evidence within that architecture. Now hash-chaining makes sense. You're protecting against tampering in transit and at rest, not relying on it to detect omissions. Tools like halo-record fit naturally here as the on-host component of a larger system.
Finally, test the failure modes. Give a red team access to your agent's runtime environment. Can they suppress logs? Can they modify the logger before it writes? Can they replay old checkpoints? Your logging architecture should survive an attacker who controls everything the agent controls.
When the Conventional Wisdom Is Right
Tamper-evident logging isn't useless. It's necessary but insufficient.
If you're building an AI agent that operates in a trusted environment with no external access, local hash-chaining might be enough. Consider an agent that runs batch analysis on internal data with no network access. The threat model is simpler: you're protecting against accidental corruption or later attempts to rewrite history, not against active compromise.
For agents that interact with external systems or make high-stakes decisions, you need both properties: tamper-evidence and completeness guarantees. The hash chain proves what's in the log is real. The external witness proves the log is complete.
AIUC-1's mandate for tamper-evident runtime logging is a step forward. But don't confuse compliance with security. The standard requires logs you can't modify. It doesn't require logs you can't hide. That's on you to design.
If you're evaluating halo-record or similar tools, ask: where does this fit in my logging architecture? Is it the complete solution, or is it the on-host component that feeds a more robust system? The answer determines whether you're checking a compliance box or actually securing your AI agents.
Your logs need to survive an attacker who controls the agent. Plan accordingly.
