GitHub Copilot Indemnity by Plan: Do Free, Business and Enterprise Change the Coverage?

Plan tier is a label; the contract is the coverage

Architecture and procurement reviews often compare Free, Business and Enterprise as a feature matrix, with indemnity as one more row. That framing hides what an indemnity is. It is not a product capability. It is a contractual promise with a defined scope, conditions the customer must meet, and exclusions.

That splits the question in two. First, which agreement governs each plan in your estate? Plans can be offered under different terms, and the administrative controls available to enforce a setting can differ by plan. Second, what does that agreement require of you? Eligible products, required settings and permitted usage can each affect whether a claim falls inside the remedy.

A plan name on an invoice therefore does not establish that a given developer, in a given editor, with a given configuration, is covered. Enterprise architects should avoid recording "Business: covered" or "Free: not covered" as a conclusion and instead record the terms version and conditions that support the claim. Legal counsel should review those terms. This guide does not provide legal advice.

Conditions that can affect eligibility

Three categories of condition matter most in practice: eligible products, configuration, and usage.

Eligible products. Coding assistants are delivered through several surfaces, including editors, command-line tools, chat and agent-style features. A remedy written around one surface does not automatically extend to another. Inventory which surfaces your developers actually use and compare them against the products the terms name.

Configuration. The duplicate detection filter, also called public code matching, compares suggestions against public code. Where the terms tie eligibility to this setting, its state at the time code was generated becomes relevant. The design question is who can change it. If it is enforced at organization or enterprise level, drift is a policy decision. If individuals can alter it, drift is a runtime risk that nobody is watching.

Usage. Terms may distinguish between output used as generated and output that has been modified, or between assistant-generated code and code from other sources. Those distinctions shape what a claim could rely on, and they are difficult to reconstruct later without records.

What the indemnity addresses and what it leaves open

An IP indemnity answers a narrow question: who bears the cost of a covered third-party claim. It does not answer the questions that engineering and security teams ask every day. Exact exclusions must be read from the terms that apply to your plan.

• Nature of the remedy: Contractual and reactive. It operates after a claim is made, not when code is generated.
• Preventive control: None by itself. It does not stop a suggestion from being accepted or tell you what was accepted.
• Security of accepted code: An IP remedy does not assess vulnerabilities in code that enters a repository.
• Licence compliance: Licence obligations attached to accepted code remain a matter for your own review and tooling.
• Modified or non-assistant code: Terms may treat these differently from unmodified output. Confirm the specific wording.
• Evidence of eligibility: The customer must be able to show which configuration and products applied. The remedy does not produce that record.

Evidence you would need if a claim arose

Because eligibility can depend on configuration and usage, the burden of showing it rests with the customer. That makes three kinds of evidence worth retaining.

Configuration history: which settings were active, at which scope, and when they changed. A screenshot taken at rollout does not show the state on the day a given suggestion was accepted.

Code origin and licence context: where accepted code came from, whether it resembled public code, and what licence signals attached to it. Without this, a team cannot tell whether a claim concerns code the indemnity could reach.

Review decisions: who accepted or modified the code, what checks ran, and what was decided. Pull request records help, but they rarely capture the generation event itself.

None of this is created by the indemnity. It has to come from controls and records inside your own delivery path. The indemnity is one input to the enterprise risk position for coding assistants. Runtime controls and retained evidence are separate inputs, and the indemnity does not stand in for them.

Where Trussed fits

Trussed addresses the part of this problem that a contract cannot. It enforces policy in the execution path for coding assistants, across individual interactions and tool calls, with actions that include allow, redact, block, rate limit and escalate for human approval. Enforcement happens at runtime, not through review after the fact.

Trussed also provides code provenance: the origin, licence and security context of code. The audit-ready evidence is generated by enforcement itself, so the record of what was permitted and what occurred exists without a separate reconstruction exercise. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

Trussed does not provide indemnity and does not replace the vendor's contractual terms or legal review. It supplies the enforcement and evidence layer that sits beside them.