Proving LLM Logs Were Captured Inline and Not Reconstructed Later

Inline capture versus post-hoc reconstruction

Inline capture means the record is written by a component that sits in the execution path of the interaction. The prompt, the response or tool call, and the policy decision are observed as they happen, and the record is produced as a side effect of that observation. The component creating the record is the same one that acted on the traffic.

Post-hoc reconstruction means the record is assembled afterward from other artifacts: application traces, gateway records, provider exports, or a developer's reading of what the system probably did. Reconstructed logs can be useful for debugging. As evidence they carry a weakness, because some fields are inferred rather than observed, and the person or system doing the assembling had the opportunity to omit, correct or fill in gaps.

Auditors and regulators ask what an AI system was allowed to do and what it actually did. A reconstructed record can describe the second part plausibly but cannot easily show the first, because the policy decision that governed the interaction was not captured at the moment it was made.

Integrity after capture is not provenance at capture

Two properties are often conflated. Integrity after capture asks whether a record changed once it was written. Provenance at capture asks whether the record was created when and where it claims, and whether anything was left out before it was written.

Hash chaining addresses the first. A hash chain is an append-only structure in which each block includes a hash of the previous block's data, so altering an earlier entry breaks every later link. Log file integrity checking works similarly by comparing the current message digest of a log file to the original digest. Both only work if the original digest or chain head is protected from the party being audited.

A signed record with verified log inclusion and an independently trusted timestamp shows the record existed by a given time and sits in the checked log state. It does not show when the underlying events were captured, whether they occurred, or whether any were omitted before submission. OWASP also notes that log trustworthiness often rests on the logging party being audited properly, and that digital signatures are hard to utilize well for logs. Cryptography narrows the question but does not close it. The capture point still needs independent examination.

Where common capture patterns can introduce gaps

The comparison below is a general architectural analysis, not a ranking. Any pattern can be built well or badly, so evaluate the specific implementation against the properties in the next section.

• Application-level instrumentation: Records are written by the code being monitored. The application can skip, alter or delete entries, and a compromised agent that can modify its own logs undermines the record. Coverage depends on every code path being instrumented.
• Gateway or proxy capture: Records are created at a network hop, which separates the logger from the application. Gaps appear if traffic can route around the hop, and a record of traffic is not by itself a record of the policy decision applied to it.
• Provider-side exports: Records are produced by a third party after the fact and delivered later. They show provider-side activity, not the enterprise's own policy decisions, and the enterprise relies on the provider's collection and retention.
• In-path policy enforcement: Records are created by the component that decides whether the interaction proceeds, so the decision and the record share an origin. Bypass resistance, storage separation and completeness still have to be demonstrated.

Retention, minimization and ownership tradeoffs

Evidentiary completeness pulls against content minimization. OWASP guidance for LLM systems advises logging minimal interaction metadata and redacting or anonymizing prompt and output content before storage. An evidence design should therefore record that a redaction occurred, what category it covered and which policy required it, without retaining the raw content. Document how this balance is struck.

Retention has a similar tension. For high-risk AI systems, the EU AI Act, as of October 2026, requires that systems technically allow automatic recording of events over their lifetime. Providers must keep the automatically generated logs to the extent they are under their control, for a period appropriate to the intended purpose and at least six months unless Union or national law, in particular data protection law, provides otherwise. Providers must also give a competent authority access to those logs on a reasoned request. Whether a given system is in scope needs a separate legal determination.

Because these duties attach to logs under the provider's control, assign ownership explicitly for any records held by vendors or model providers. Finally, since trust in logs often rests on auditing the logging party, plan periodic independent review of the logging mechanism itself, not only of the logs it produces.

How enforcement-generated evidence fits

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Its actions are allow, redact, block, rate limit and escalate for human approval, applied to individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact.

Because the enforcement point is where the decision is made, the audit-ready evidence is generated by that enforcement rather than assembled from other systems. The record and the decision share an origin, which addresses the capture point and decision linkage questions above. Evidence is mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Trussed is deployed self-managed in the customer cloud, with configurable retention and data residency, which bears on the access and retention questions.

Trussed has run continuously in production at a regulated enterprise for more than 18 months and generates more than 30 GB of audit evidence per day. As with any vendor, test these properties directly: ask where records are created, how completeness is shown, and who holds the integrity anchors.