Amazon Q Developer indemnity and AGPL code: what the Free Tier decision depends on

Indemnity scope is a per-tier contractual question

Vendors commonly scope IP indemnification differently across product tiers, and an assistant that offers a free and a paid tier should not be assumed to apply one set of terms to both. The practical consequence is that the Free Tier decision cannot rest on the vendor's general reputation or on marketing descriptions of the paid offering. It rests on the terms that govern the specific account type your developers use.

Indemnity clauses also tend to carry conditions. Typical examples are requirements that output be used unmodified, that particular filtering or tracking settings remain enabled, or that the customer notify the vendor promptly of a claim. Each condition is an operational dependency. If a developer edits a suggestion, or an administrator cannot enforce a setting on individual users, coverage that looks broad on paper may not apply in practice.

NIST's draft generative AI profile makes a related point at a general level. It advises updating third-party contracts, service agreements and warranties to address generative AI risks, and notes they may include AI-specific indemnity clauses alongside dispute resolution mechanisms and other risk controls. Indemnity is one control in that list, not a substitute for the others.

What reference filtering can and cannot remove

A reference tracker or open source filter compares suggestions against a body of known public code and surfaces or suppresses close matches. That is a similarity mechanism. It is useful, but it is not a licence determination, and it has limits that security engineers should test rather than assume.

A match depends on what the matching corpus contains and how similar the output must be to trigger a flag. Code that is functionally derived from an AGPL project but restructured may not be flagged. Code that is flagged still needs a human or a policy to decide what happens next. A filter also operates inside the assistant, so it produces no independent record of what was suggested, what was accepted and what licence context applied at the time.

For evaluation, the useful questions are what the filter detects, whether results are visible to administrators, whether behaviour can be enforced centrally instead of per developer, and what record exists afterward. Treat the filter as a reduction in likelihood, not an elimination of exposure.

How AGPL differs from other licence families

The licence family determines what obligation follows the code once it is incorporated. This is a general technical summary, not legal advice, and legal review of AGPL exposure is required before any policy decision.

• Permissive (MIT, BSD, Apache-style): Generally require attribution and licence notices. They do not require releasing your own source code.
• Weak copyleft (LGPL, MPL-style): Obligations are scoped to the covered library or files. Modifications to those components are typically shared, while surrounding code can stay separate.
• GPL-3.0: Strong copyleft triggered by distribution. Distributing a combined work generally means offering its source under the same terms.
• AGPL-3.0: Strong copyleft that adds a network-use provision. Users interacting with modified software remotely can be entitled to its source, even without distribution of binaries.

Why AGPL changes the risk for server-side code

Most internal and SaaS code is never distributed. It runs on servers and is accessed over a network. For GPL code, that pattern usually avoids the distribution trigger. AGPL was written to close that gap: its network-use provision applies when a modified version of the program lets users interact with it remotely.

For AI-generated code, three implications follow. First, a short snippet that resembles AGPL code is hard to assess, because whether it is a protectable, copied portion of the work is a legal judgement, not something a scanner decides. Second, the exposure is concentrated in the code most enterprises generate with assistants: backend services, APIs and internal tooling that users reach over a network. Third, remediation after release is expensive, since removing or rewriting code does not undo a prior period of operation.

Indemnity does not alter these mechanics. At most it addresses who bears certain costs of a third-party claim under defined conditions. It does not relicense code, restore a clean repository history or satisfy a customer's or regulator's question about what entered the codebase.

Customer-side controls that indemnity does not replace

Start with tier policy. If the terms for a tier do not meet your criteria, restrict it by identity and organisation, and make the restriction technical, not a memo. Then add detection: software composition and licence scanning in the pipeline, with AGPL and other strong copyleft treated as blocking findings for network-facing services.

Detection after commit is late. The more reliable position is policy enforced at runtime, not reviewed after the fact, at the point where the assistant produces or a developer accepts code. Code provenance, meaning the origin, licence and security context of code, lets a policy act on a suggestion before it reaches the repository. Trussed enforces policy in the execution path of coding assistants and can allow, redact, block or escalate for human approval at the level of individual interactions and tool calls, and it produces audit-ready evidence of those decisions. Its scope is those interactions, not a legal determination of licence status.

Finally, keep the evidence. A regulated enterprise that must show an auditor what its assistants were allowed to do needs durable records of policy and outcomes. Contract terms, scan results and enforcement records together make a defensible position. The contract alone does not.