LLM traffic recording proxy
LLM Harness Proxy
A structural recording layer between an LLM client and its provider, designed to persist a record before releasing a response.
Why a separate observer matters
An agent-authored report is not an independent account of what the model received or emitted. LLM Harness Proxy puts capture on the traffic path between client and provider. The documented implementation writes a tamper-evident, hash-chained ledger and withholds responses if the required ledger write fails. The design makes recording a structural dependency rather than a request for the agent to remember to be transparent.
A small integration surface
The Rust proxy exposes provider-compatible endpoints so a client can point its base URL at a local recording layer. The repository documents OpenAI-compatible, Anthropic and Gemini routes, including streaming and buffered behavior. Its protocol records provider-visible output, tool-call data and usage when supplied. Missing usage is not silently estimated into an apparently exact number.
What the chain can establish
Chaining entries makes modifications and reordering detectable within the verification model. It does not turn a record into a universal account of reality. The observer sees model-layer traffic that passes through it; it does not automatically see every executor action, a changed repository or the final state of a production system. Those require their own checks. Reasoning that a provider does not expose cannot be recovered by naming a ledger field for it.
Operational boundaries
Capture also creates sensitive records. Storage permissions, retention, routing, secrets handling and deployment isolation matter alongside ledger integrity. A hash chain is not a substitute for protecting the observer and its data. The protocol specification and implementation document exact capture and failure semantics; this portfolio page describes the architectural purpose, not an independent security audit or compliance certification.