Implementation Guide

    How to Map Developer Seats to the AI Coding Tool Plan and Indemnity Tier They Used

    Treat the mapping as a time-bound data model, not a spreadsheet of licences. Reconcile identity provider records, vendor admin data, IDE and extension telemetry, and repository metadata into one record that links each developer seat to a plan, its configuration and the indemnity conditions in effect on the date code was generated. Inventory shows what you bought. Evidence captured in the execution path shows what was actually used.

    Talk to an Expert See How Evidence Is Produced
    1. {"title":"Identity","description":"A developer or service account, resolved across identity provider and vendor account identifiers."}
    2. {"title":"Seat","description":"An assignment of an assistant to an identity, with start and end dates."}
    3. {"title":"Plan and configuration period","description":"The plan, plus settings such as public-code filtering, with effective dates for each change."}
    4. {"title":"Indemnity condition version","description":"A reference to the vendor terms version and the conditions recorded from it, reviewed by legal."}
    5. {"title":"Contribution record","description":"Commit or change reference, timestamp, tool, modification context and source, joined to the seat and periods above."}
    6. Build a canonical list of sanctioned assistants, plans and required settings from policy.
    7. Join identity provider users to vendor seat assignments and flag users with a seat but no identity match, and the reverse.
    8. Compare telemetry from managed devices against assigned seats to find installed assistants with no sanctioned seat.
    9. Flag seats whose configuration differs from the required setting for the indemnity condition you are relying on.
    10. Review commits from identities with unmanaged or mismatched assistant activity and route them to the owning team.
    11. Record each resolution, including exceptions, as dated evidence rather than closing the finding silently.

    Retaining evidence that holds up to audit

    • Keep plan, configuration and indemnity-condition history append-only, with effective dates.
    • Preserve the version of vendor terms you recorded conditions from, with the date it was captured.
    • Link each contribution record to its commit, timestamp, tool and modification context.
    • Retain reconciliation findings and exception approvals alongside the data they concern.
    • Store runtime enforcement evidence for coding assistants in a form that can be queried by seat and date.
    • Test retrieval with a sample request: pick a commit and reproduce its seat, plan and configuration end to end.

    What the mapping has to prove

    The question legal, security and audit teams ask is narrow: for this piece of code, which contractual protection applied when it was generated? Answering it requires three links. The first is from the code to a person or service identity. The second is from that identity to a seat on a specific plan. The third is from that plan, with its configuration, to the indemnity conditions in force at that moment.

    Vendors apply different indemnity terms by plan or tier, and conditions can depend on settings such as public-code filtering. The specific conditions differ by vendor and change over time, so they belong in your records as versioned data taken from current vendor terms, with legal review. This guide does not interpret any vendor's terms and is not legal advice.

    A current-state licence list cannot answer the question. Seats move between plans, developers use personal or unsanctioned accounts, and several assistants often run side by side. The mapping has to be reconstructable for any past date.

    Data sources to reconcile, and what each one cannot tell you

    No single system holds the full picture, so the design work is reconciliation. Each source answers one part of the question and leaves a gap that another source has to cover.

    • Identity provider: Authoritative for who a developer is, their group membership and when they joined or left. It does not show which assistant account they actually signed in with, particularly if that account is personal.
    • Vendor admin and licensing records: Show assigned seats, plans and enrolment dates for managed accounts. They say little about usage outside the managed tenant, and the detail they expose varies by vendor.
    • IDE and extension telemetry: Can show which assistant extensions are installed and active on a managed device. Coverage depends on device management and on what the extension reports.
    • Repository and commit metadata: Ties code to authors, timestamps and branches, and gives a place to attach provenance. By default it does not record whether a given change was AI-assisted.

    Where inventory stops and runtime evidence starts

    Even a well-reconciled inventory is inferential. It shows that a seat existed on a plan and that a commit was made by that developer. It cannot show that a given suggestion was generated under that configuration, or that the developer was not using a second assistant at the time. Treating generated code as something to verify, as some practitioners do, depends on knowing where it came from.

    Enforcement in the execution path supplies attribution at the moment of interaction. Trussed enforces policy in the execution path for coding assistants, allowing, redacting or blocking individual interactions, and produces audit-ready evidence from that enforcement. Its code provenance capability records the origin, licence and security context of code. That evidence can be joined to the seat and plan history above, so a contribution carries both what was contractually in place and what was observed at runtime.

    This complements the inventory rather than replacing it. Trussed does not determine indemnity eligibility. Legal teams still own the reading of vendor terms. What the runtime evidence adds is a durable record of what was allowed and what happened. Trussed can be self-managed in the customer cloud, with configurable retention and data residency, which matters when the evidence set is itself sensitive.

    Seat-to-indemnity mapping at a glance

    Identity

    Who the developer is, and which accounts they are entitled to use.

    Plan history

    Which plan and settings applied to the seat, and for what period.

    Usage

    Which assistant, account and configuration were actually in use.

    Contribution

    Which commits carry AI-assisted code, with timestamp and origin context.

    Add runtime attribution to your seat inventory

    See how policy enforcement in the execution path for coding assistants produces audit-ready evidence tied to code origin, licence and security context.

    See How Evidence Is Produced