How to Document Blocked LLM Requests as Audit Evidence

A blocked request is a control test result

Most teams that block LLM requests at runtime keep some trace of the event. The trace is usually an application log entry or a screenshot from an investigation. These show that something was refused. They rarely show that a defined policy produced the refusal, what the policy evaluated, or that the content never reached the model or tool.

Auditors ask a different question: did the control operate as designed? Answering it means treating each block the way you would treat any other control operation. The record is an observation of a preventive control working, and it should be complete enough that someone who was not present can reach the same conclusion.

This matters for audit sampling requests, incident reviews and control testing alike. Without a consistent record per block, control effectiveness is asserted rather than demonstrated, and each sampling request becomes a manual reconstruction exercise.

Define the minimum evidence record

Set the minimum record once and require it for every enforcement decision, not only blocks. Traceability guidance for LLM systems points to identity, correlation IDs, authorization decisions, model versions and tool invocation outcomes as a practical starting point. Extend that with the elements an auditor needs to follow the decision from request to outcome.

Keep the record to fields you can populate reliably at the moment of enforcement. A field that is sometimes empty weakens every record, because a reviewer cannot tell whether a gap is a gap in the control or a gap in the capture.

• Request context and identity: The authenticated user, agent or service, the target model or tool, and the type of interaction.
• Policy identifier and version: The exact policy that applied, so the decision can be tied to the rule as it stood at that time.
• Evaluated conditions: Which conditions were checked and which matched, for example sensitive data detected or a disallowed tool call.
• Enforcement decision: Allow, redact, block, rate limit or escalate, recorded as a single explicit value.
• Timestamp and correlation ID: A trusted time and an ID linking the request, the decision and any downstream tool outcome.
• Non-delivery confirmation: A statement from the enforcing component that the interaction did not proceed to the model or tool.

Enforcement in the execution path versus after-the-fact review

Evidence is stronger when it comes from an observer positioned to witness the execution. A component that sits in the execution path makes the decision and records it at the same moment. It knows what was evaluated and whether the request was forwarded, so the record is a first-hand observation.

Reconstruction works differently. When a team assembles proof later from application logs, gateway traces and screenshots, each source records only part of the event. The reviewer has to infer the policy that applied and infer that nothing was delivered. That is a plausible account, not a direct observation.

Two further points apply to any design. First, a record's integrity and its truth are separate questions. A signed, timestamped record shows that it existed by a given time. It does not show that every event was captured or that none were omitted before submission. Second, a missing entry is not proof that nothing happened if the recording path could have failed. Record failures of the evidence path explicitly, and never count missing telemetry as a block.

Finally, ask who could fabricate or omit a record. Evidence supplied by the party being assessed remains an assertion until someone independent can re-check it.

Retain and protect the evidence itself

Blocked requests often contain exactly the content you blocked, such as personal data or secrets. Copying that content into general application logs creates a second exposure. Keep sensitive prompt content out of routine logs. Where an investigation needs content, capture only the necessary redacted fields in a restricted evidence store with access controls and retention limits, and make sure investigators are authorized for the underlying data.

Retention periods are a policy decision. Set them from the regulation or internal policy that governs the data and the control, and configure them per evidence class. Data residency belongs in the same decision: the evidence store should sit where the data is allowed to sit.

For integrity, make tampering detectable and make the capture path auditable. Restrict write access to the enforcing component, record gaps in the evidence path as events, and decide in advance what an independent verifier can check for themselves, such as record inclusion and timing, and what remains an assertion.

Map the evidence to frameworks and present it in an audit

The EU AI Act requires that high-risk AI systems technically allow for the automatic recording of events over the lifetime of the system. Whether a given LLM deployment is high-risk is a separate determination. NIST publishes a Generative AI Profile as a companion resource to AI RMF 1.0. As of October 2026, use the full text of each framework when mapping individual fields to specific provisions.

For an audit sample, classify each sampled case as violation observed, no violation observed, inconclusive or not applicable. Errors, unsupported contexts and missing telemetry go under inconclusive. Report block counts alongside the false-positive rate, pending reviews and task-completion rate. Small samples need care: zero false positives across seven trials is consistent with a true rate as high as roughly 35 percent, so it is not evidence of a zero rate.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, covering individual interactions and tool calls. Audit-ready evidence is generated by that enforcement and 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. Its scope is the interaction and the tool call, not workflow-level tracing.