Adding Tamper-Evident Audit Logs to a LiteLLM Proxy: Build vs Buy

What tamper-evidence requires beyond standard logging

Application logging answers the question of what the system chose to write down. Tamper-evidence answers a different question: can a third party trust that what was written is what happened, and that nothing was changed or removed afterward? A log held in a database the operator can edit cannot answer that, however detailed it is.

It helps to break the property into five parts. Integrity means alterations to stored records are detectable. NIST SP 800-92 describes one established approach: calculate a message digest for each log file and store the digest securely, so changes to archived logs are detected. The word securely carries weight. If an attacker who can change the logs can also change the digests, the check proves nothing.

Completeness means a deleted or never-written record is detectable, which is a stronger claim than integrity of the records that remain. Ordering depends on time. NIST SP 800-92 notes that an inaccurate host clock produces inaccurate timestamps, which complicates analysis across hosts, so time-source integrity is a dependency of any ordering claim. Non-repudiation relies on digital signatures, which give assurance that the claimed signatory signed the information and that it was not modified after signing. Retention is the separate matter of keeping records for the required period. NIST SP 800-53 Rev. 5 asks for audit storage capacity sized to organization-defined retention requirements.

On the regulatory side, EU AI Act Article 12 requires high-risk AI systems to technically allow automatic recording of events over their lifetime. Providers must keep automatically generated logs under their control for at least six months, unless other Union or national law provides otherwise, and give competent authorities access on a reasoned request. Whether a given deployment is high-risk depends on its use case, and the status of the provisions should be confirmed as of November 2026.

Where a self-built approach has gaps

The first gap is the difference between logging requests and producing evidence tied to policy decisions. A request log shows that a call happened. An auditor asking what the AI was allowed to do wants to see the decision (allow, redact, block or escalate), the policy that produced it, and the outcome. A log of requests alone does not capture that. Whether those outcomes are recorded has to be designed and verified, and if the decision is made somewhere other than the proxy's logging hooks, the build has to join the two records reliably.

The second gap is completeness. Hash chaining makes tampering with existing records visible, but it does not by itself show that every event reached the chain. If a callback fails, a process restarts or a path bypasses the hook, the chain stays internally consistent while the record is incomplete. Demonstrating completeness requires sequence accounting, reconciliation against an independent count, and a defined behavior when the writer is unavailable.

The third gap is privacy. Logged prompt and output content should be minimized, redacted or anonymized before storage, which can conflict with evidentiary completeness. The schema has to say what is stored and what is referenced. Data protection law may also shorten or otherwise affect retention.

The fourth is operational. Key rotation, verification jobs, storage growth, schema changes and clock monitoring do not end at launch. Estimate them in engineering time per quarter, and name the team that owns them, before committing to the build.

Where Trussed fits

Trussed is a runtime control and evidence capability for regulated enterprises that must show what their AI was allowed to do and what it did. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with actions that include allow, redact, block, rate limit and escalate for human approval. Enforcement applies to individual interactions and tool calls, and it is enforced at runtime, not reviewed after the fact.

Because evidence is generated by enforcement, each record is tied to the policy decision that produced it. The audit-ready evidence is mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Deployment is self-managed in the customer cloud, with configurable retention and data residency. In production, Trussed has run continuously for 18+ months in a regulated enterprise, with 100+ models under one policy plane and 30+ GB of audit evidence generated per day.

This is not a claim to replace your proxy, and it does not provide end-to-end tracing of agentic workflows. It addresses the specific gap described above: evidence of policy decisions made in the execution path. Run it through the six criteria like any other option, including who holds keys and what work remains with your team.