Code Assistant Duplicate-Detection Filters and Vendor IP Indemnity: Enforcing Policy and Retaining Provenance Evidence

How filter-linked indemnity conditions work

An AI coding assistant vendor may offer to defend or compensate a customer against copyright or licence claims over generated output. Where it does, the offer is usually bounded by conditions. A common pattern is a requirement that the customer keeps specific safeguards enabled, such as a filter that checks suggestions against public code and suppresses close matches. The protection then depends on how the customer used the product, not only on what the product produced.

This makes the filter a condition of contractual protection. It is not a licence-compliance solution. A filter that suppresses matches to known public code reduces one kind of risk, but it does not establish that remaining output is free of licence obligations, and it does not record anything about what was suggested. Treat it as one input to your risk position, and read the exact contract language rather than the vendor's summary of it.

Guidance from NIST, in a draft generative AI profile now marked withdrawn, points in the same direction: third-party contracts and service agreements should be updated to address generative AI risks and may include GAI-specific indemnity clauses. Use it as guidance on direction, not as a current requirement.

What can change when the filter is disabled

The first change is contractual. If the indemnity is conditional on the filter, a disabled filter may mean the condition was not met for code generated in that period. Whether coverage is lost entirely, reduced, or affected only for the code produced while the filter was off depends on the drafting. Legal counsel should interpret that; this guide does not.

The second change is evidential. A security team usually cannot show which developers or repositories ran with the filter off, what was suggested or accepted in that window, or what origin and licence context applied. If a claim or customer due diligence request arrives, the organisation then has to reconstruct events without records. A control that cannot be shown to have been active is, in practice, hard to rely on.

The third change is operational. Filters can be turned off for productivity reasons, either by an individual developer or by an organisation that leaves them off by default. Either way, assistant settings become security-relevant state. OWASP guidance already treats AI coding-agent configuration files as executable supply-chain artifacts and advises that security monitoring cover configuration changes in tools such as Claude Code, Cursor, Gemini CLI and VS Code. The same reasoning applies to a filter setting.

Enforcing policy in the execution path

A written policy that says the filter must stay on does not change developer behaviour. Enforcement has to happen where the assistant is used. Three layers are worth separating: the setting itself, which may live in an IDE, an organisation-level policy or an API configuration; monitoring of that setting for change; and policy applied to each interaction as it happens. Which of these an organisation can centrally enforce depends on the assistant and the licence tier, so establish this per tool rather than assuming it.

Per-interaction enforcement adds something settings alone cannot. In the execution path, a policy engine can allow a request, redact sensitive content, block a request or response that breaches policy, or escalate to a human for approval. NIST's draft cyber AI profile describes output filtering, pattern detection, access control, thresholds and rules as control categories. Mapping those onto allow, redact, block and escalate is a reasonable design choice, though not a standard.

Two cautions apply. Filtering and pattern detection are not proof of licence compliance, so human review of suggested code and packages should stay in the workflow, as OWASP guidance on output handling stresses. And safeguards can be defeated by those with access to the code that runs them, a point NIST makes about watermarking. Test that any control behaves as intended instead of assuming it does.

What provenance evidence should capture

To support an indemnity claim or answer an auditor, evidence needs to link three things: the configuration in force, the person and place, and the code. The following record elements are inferences from general provenance and secure development practice, not a defined standard.

For configuration, record the filter and policy state at the time of each suggestion. For person and place, record the individual account, the repository and the review or approval decision. NIST SSDF practice PS.1.1 calls for storing code with accountability to the individual account, with examples such as commit signing and code-owner review and approval of changes made by others. For the code, record origin, any similarity or matched-source information, licence context and security context. The NIST draft profile lists similarity metrics, metadata consistency and source reliability as measures for content provenance risk.

Retention matters as much as capture. Claims and due diligence requests can arrive long after the code was written, so retention period, export format and data residency should be set deliberately. The SSDF also suggests asking third parties to provide provenance data and integrity verification for their components, which is a fair expectation of assistant vendors as well.

Where Trussed fits

Trussed is one runtime-control approach. It enforces policy in the execution path across models, agents, tools, MCP servers and coding assistants, with allow, redact, block, rate limit and escalate-for-human-approval actions applied to individual interactions and tool calls. Its code provenance capability covers the origin, licence and security context of code, and enforcement generates continuous audit-ready evidence. It can be self-managed in the customer cloud, with configurable retention and data residency.

This does not replace contract review, and it does not make any vendor's indemnity apply. It addresses the gap between a stated condition and actual developer behaviour, so that a regulated enterprise can show what its assistants were allowed to do and what they did. Legal teams remain responsible for interpreting coverage.