Proving to Auditors That AI Coding Assistant License Filters Were Enabled for Every Request

What an auditor needs before accepting the claim

The statement "license filters were enabled for every AI coding assistant request" has three parts. The filter was configured on. It was applied to each request. Nothing changed or bypassed it during the audit period. A configuration export speaks only to the first part, and only at the moment it was taken.

Continuous monitoring guidance from NIST frames assurance as assessing whether controls are implemented correctly, operating as intended, producing the desired outcome, and continuing to be effective over time as the system and its environment change. That is the standard a reviewer applies to this claim, whether the framework is SOC 2, ISO 27001 or NIST AI RMF.

In practice, an auditor will want to define the population of requests, draw a sample, and see for each sampled request which policy applied and what happened. They will then ask how changes were detected, how exceptions were handled, and how long the records are kept. The design task is to make each of those questions answerable from data, not from narrative.

Where configuration-based evidence falls short

Not all evidence establishes the same thing. The useful question for each artefact is what it can show about a specific request, and what it cannot.

• Admin console screenshot: Shows the state when captured. It cannot show earlier states, whether the filter was applied to a given request, or activity outside the console's scope.
• Point-in-time configuration export: Shows setting values at export time. Drift between exports, and requests from clients or accounts the export does not cover, remain invisible.
• Vendor attestation: Records the vendor's assertion. It comes from a component you did not build, so it needs separate assessment of what it establishes, and it does not describe your population of requests.
• Vendor-generated logs: May show activity, but what they establish about filter application should be assessed field by field. Coverage and retention are set by the vendor.
• Enforcement-generated records: Written at the point of decision by a system you operate. One record per interaction, carrying the policy version and the decision applied.

What a per-request evidence record should contain

There is no mandated schema for this. The fields below are a proposed design that maps to the questions an auditor is likely to ask about a sampled request. Where suggestion content is sensitive, store hashes or references instead of the code itself, and decide that deliberately.

Trussed enforces policy in the execution path for coding assistants and provides code provenance covering the origin, license and security context of code. Audit-ready evidence is generated by that enforcement and can be deployed self-managed in the customer cloud, with configurable retention and data residency. The same record design applies if you build the enforcement point yourself.

• Request ID and timestamp: A unique identifier and a trustworthy time of the decision.
• Identity: User, workspace and client or extension that originated the request.
• Policy ID and version: The exact license policy in force when the decision was made.
• Decision and reason: Allow, redact or block, with the rule that triggered it.
• Origin and license context: What the provenance check determined about the suggested code.
• Integrity metadata: Hash, chaining or signature so alteration is detectable.

Failure modes and how path enforcement addresses them

Configuration drift is the most common weakness. A setting changes, or a workspace is created with different defaults, and the exported configuration no longer describes what happened. When the policy version is recorded on every decision, drift shows up as a change in the version field, and policy and setting changes can be documented and impact-assessed, as continuous monitoring guidance expects.

Unmanaged clients and extensions, and personal accounts, create requests that never reach your controls. Enforcement in the path does not prevent a developer from using an unapproved tool, but it makes the gap measurable. Reconcile the request counts at the enforcement point against identity and network data, and treat the difference as exceptions that need an owner, not as noise.

Vendor-side changes can alter filter behavior without any action on your side. Because your record is written by your own enforcement point, the decision you applied does not depend on what the vendor's filter did that day. You should still review vendor changes, and request third-party audit reports, but pair them with your own evidence.

There is a tradeoff. An enforcement point in the path becomes a dependency, so you must decide what happens when it is unavailable. Failing closed protects the claim and interrupts developers. Failing open keeps developers working and creates unenforced requests. Whichever you choose, record it as a defined, reviewable exception.