Anthropic Indemnity for Claude Code on Bedrock and Vertex AI: What It Does and Does Not Cover for MPL-Licensed Code

Why the access path decides which documents apply

Indemnity is a contract term. It attaches to a specific agreement, a specific product and a specific set of conditions, so the first architectural question is which agreement governs each route to Claude Code.

Bedrock and Vertex AI are model-as-a-service offerings. The cloud provider's platform sits between your organisation and the model developer, and the model is reached through that provider's service. A direct deployment sits under the developer's own commercial terms. A Bedrock or Vertex AI deployment is typically also bound by the cloud provider's customer agreement, service terms and any marketplace or third-party model terms. These documents can differ in wording, in the products they name and in which one prevails when they conflict.

For each path, identify the commercial agreement, the product-specific terms that name Claude Code or the underlying models, and the order of precedence between them. Then confirm whether any IP indemnity in those documents covers Claude Code and its output, or only certain products or plans. Do not infer coverage from the vendor name or from a partnership between the model developer and the cloud provider. A partnership describes a commercial relationship, not the scope of an indemnity clause.

Because teams often use more than one path, inventory which team uses which route before making any assumption about coverage.

Conditions and exclusions that typically shape an AI output indemnity

AI output indemnities from different vendors tend to share a recognisable structure, even when the details differ. Read each path's documents against the following points rather than relying on a summary of the headline promise.

The practical effect is that coverage is often narrower than the phrase "IP indemnity" suggests. An indemnity may respond to a third-party infringement claim about output. It does not usually address an obligation you owe under a licence, because that obligation is not a third-party claim until someone asserts it.

• Covered product and plan: The indemnity may apply only to named services or commercial tiers, and Claude Code may or may not be among them on a given path.
• Customer configuration and use requirements: Coverage can depend on using the service as documented, or on keeping specified settings or filters enabled.
• Nature of the claim: Clauses commonly address third-party claims about output, not internal compliance duties or regulatory action.
• Inputs and modifications: Customer-supplied prompts, context, fine-tuning or edits to output are often excluded or limited.
• Knowledge and intent: Use of output that the customer knew, or should have known, was infringing is a common carve-out.
• Notice and claim handling: Prompt notice, cooperation and vendor control of the defence are usual preconditions, and liability caps may apply.

How MPL 2.0 differs from permissive and strong-copyleft licences

MPL 2.0 sits between permissive and strong-copyleft licences. Its copyleft is scoped to files, not to the whole program. That matters for generated code, because a single file that reproduces or is derived from MPL source can carry obligations even if the rest of the repository does not.

If generated code reproduces or modifies an MPL-covered file and you distribute it, the usual MPL duty is to make the source of that file available under MPL terms and to preserve notices. New files you write that are not derived from MPL files can generally stay under other licences. Counsel should confirm how this applies to your distribution model.

• Permissive (for example MIT, BSD, Apache 2.0): Broad reuse allowed. Obligations are mainly preserving copyright and licence notices. No requirement to release source of derived code.
• MPL 2.0 (file-level copyleft): Modified or reproduced MPL files must stay under MPL and their source made available on distribution. Other files in the combined work can use different terms.
• Strong copyleft (for example GPL): Copyleft can extend to the larger combined work that is distributed, so one reproduced component can affect the whole program's licensing.
• Generated-code consequence: Under MPL the risk is localised to the files concerned, which makes file-level origin tracking more useful than repository-level review.

What stays with the enterprise and how to control it

Indemnity can shift some financial exposure for a third-party claim. It does not tell you what code entered your repository, under which licence, or whether you have met a file-level obligation. NIST guidance points the same way. It treats indemnity as one contract term to review alongside liability assignment and incident notification, and it recommends documenting the origin and licences of generated content to support accountability. Its secure development profile also treats AI-generated code the same as human-written code: all of it is evaluated before use.

In practice, that means adding licence and origin review to the pipeline that already handles vulnerability review, and recording the result where an auditor can retrieve it. Capture evidence at the point of interaction with the coding assistant, because reconstructing it later from commit history is unreliable.

• Map each team to its access path: Tie every Claude Code deployment to its governing agreements before assuming any coverage.
• Apply the same pre-use evaluation to generated code: Run licence, origin and security review as you would for human-written code.
• Record origin and licence data per change: Keep it with the change that brings AI-assisted code into a repository, and keep it retrievable.
• Route flagged files for human decision: Where a file shows copyleft signals, require a documented decision on rewrite, comply or reject.
• Retain evidence on a defined schedule: Set retention that supports both audit and any future claim under a vendor indemnity.

Where Trussed fits

Trussed is a runtime control and evidence layer. It does not replace the contract review above, and it does not make an indemnity apply where the documents say otherwise. It addresses the part of the problem that sits in the development workflow.

Trussed enforces policy in the execution path of coding assistants, at the level of individual interactions and tool calls. Policy can allow, redact, block, rate limit or escalate an action for human approval, so a rule such as routing flagged code for review is enforced at runtime, not reviewed after the fact. Its code provenance capability records the origin, licence and security context of code, and enforcement produces audit-ready evidence mapped to frameworks including NIST. It can be deployed self-managed in the customer's cloud, with configurable retention and data residency.

For a regulated enterprise, that gives legal and procurement a record of what the assistant was allowed to do and what it did, whichever access path a team uses and whatever the indemnity position turns out to be.