Technical Guide

    AGPL-3.0 AI-Generated Code in a SaaS Backend: When Source Disclosure Duties Can Arise

    AGPL-3.0 section 13 extends source-offer obligations to users who interact remotely over a network with a modified version of AGPL-licensed software, so hosting a backend can matter even without distributing binaries. An AI-suggested snippet creates that risk only if it reproduces copyrightable AGPL code and ends up in a program you run as a network service. Similarity alone is not enough. The practical difficulty is that accepted suggestions rarely carry a record of origin or licence, so the question is hard to answer later. Capturing provenance and enforcing policy at the point of acceptance addresses that.

    Controls to evaluate at the point of acceptance

    • Snippet-level matching against known licensed code at suggestion or acceptance time, not only dependency scanning after merge.
    • A recorded origin for each accepted assistant suggestion: which assistant, which repository and service, and when.
    • Licence context attached to that record, including a flag for strong copyleft licences such as AGPL-3.0.
    • A defined action when a match is found: allow, redact, block, or escalate for human approval, with a named reviewer role.
    • Records that separate assistant-suggested code from human-authored code, which also supports copyright disclosure duties where you register work containing AI-generated material.
    • A retention period for those records that matches how long the affected backend service stays in production.

    What AGPL-3.0 section 13 adds for hosted software

    Most open source licences attach their main obligations to distribution. If you ship a binary, you owe source. A company that runs software only on its own servers often never triggers that condition. AGPL-3.0 section 13 is written to close that gap. It addresses the case where users interact with a modified version of the program remotely through a computer network, and it requires that those users be offered the corresponding source of that modified version.

    Three terms carry most of the analysis. "Modify" asks whether your program is a work based on the AGPL-licensed program, for example because you changed it or incorporated its code into your own. "Convey" is the licence's term for the activity that triggers the ordinary distribution obligations, and section 13 is a separate network-based duty that does not depend on conveying. "Interact remotely through a computer network" asks whether people, directly or through a front end, use the running program over a network. A multi-tenant SaaS API used by customers is a plausible example, but how those terms apply to a specific architecture is a question for counsel reading the licence text.

    The common overstatements are worth avoiding. Section 13 does not make every service that calls an AGPL component open source. It does not apply because a snippet looks familiar. It concerns modified AGPL-derived software and the users who interact with it.

    When AI-suggested code could create a source-offer question

    For a suggestion to matter under section 13, several conditions would generally need to hold together. The suggested code would have to reproduce expression from an AGPL-3.0 work, not just implement the same idea. It would have to be incorporated into your backend so that the backend can reasonably be characterised as a modified version or work based on that AGPL program. And users would have to interact with that backend over a network. If any link fails, the section 13 question may not arise.

    The distinction between copyright-relevant reproduction and unprotectable similarity does most of the work. Short snippets, standard idioms, boilerplate, and code dictated by an interface or a functional constraint are often similar across unrelated codebases without any copying of protectable expression. A long, distinctive passage that matches an AGPL file, including its structure, naming and comments, is a different kind of signal. Where the line falls is a legal judgement that depends on the facts. It should not be reduced to a similarity score.

    No assistant is certain to reproduce licensed code, and most suggestions will not. The risk is low-frequency and hard to see, which is why it is better handled as an evidence and process problem than as a reason to ban assistants outright.

    What is settled, and what is not

    It helps to be precise about what existing guidance does and does not say. As of November 2026, the US Copyright Office registration guidance published in March 2023 states that where an AI technology determines the expressive elements of its output, that material is not the product of human authorship and is not protected by copyright. It also says a work can combine AI-generated material with enough human authorship, such as creative selection, arrangement or modification, to support a claim over the human-authored aspects. A later notice in August 2023 sought public comment on the legal status of AI-generated outputs, among other questions.

    That guidance concerns copyright registration. It does not decide whether an AI suggestion that reproduces third-party licensed code carries the licence obligations of that code. The FTC has likewise posed open questions about how liability should be apportioned among users, AI tool developers and training dataset developers. These are questions, not answers.

    For governance documents, the safe position is not to assume a settled outcome in either direction. Treat the human-authorship principle as relevant to what your own company can claim to own, and treat licence exposure as a separate question that depends on the origin of the code you accepted.

    Why licence questions are hard to answer after the fact

    Suppose counsel asks which files in a backend service came from an assistant, whether any matched public code, and under what licence. In most environments the honest answer is that nobody recorded it. A suggestion is accepted with a keystroke, merged into a commit, and indistinguishable from human-written code in the repository history.

    Vendor features can help at the moment of suggestion, such as filters that compare output to public code or reference features that surface a match. Their documentation and contract terms, including any indemnity, should be read for what they cover and exclude. Even where such features exist, they act in the editor session. They do not by themselves leave your organisation with a durable record tying a specific accepted block to an origin and licence.

    Software composition analysis has a related limit. These tools are strong at declared dependencies in manifests and lockfiles. A snippet pasted or suggested into your own source file is not a declared dependency, so it can pass through unless a tool specifically performs snippet-level matching. Scans after merge also find problems after the code is already in a deployed service, when remediation means rewriting live code.

    Where Trussed fits, and what it does not decide

    Trussed provides code provenance, meaning the origin, licence and security context of code, and enforces policy in the execution path of coding assistants. For a licence-bearing suggestion, policy can allow it, redact it, block it, or escalate it for human approval. This is enforced at runtime, not reviewed after the fact, and it applies to individual interactions and tool calls. Enforcement generates audit-ready evidence, so the record of what was suggested, what policy applied and what action was taken exists when counsel or an auditor asks for it.

    Trussed can be self-managed in the customer cloud, with configurable retention and data residency, which matters when provenance records need to outlive the services they describe. It has run in continuous production in a regulated enterprise for more than 18 months.

    These controls do not determine whether a given piece of code triggers AGPL-3.0 section 13. That remains a legal assessment of the code, the architecture and the licence text. What the controls change is whether you can bring facts to that assessment: what was accepted, where it came from, and what was done about it.

    From suggestion to source-offer question

    Suggestion

    An assistant proposes code that may resemble licensed source.

    Acceptance

    A developer accepts it into a backend service, usually with no origin record.

    Deployment

    The service runs as a network-accessible SaaS backend.

    Licence question

    Section 13 analysis depends on what the code is, whether it is modified, and how users interact with it.

    Establish provenance before the licence question is asked

    Talk to an expert about recording code origin and licence context and enforcing policy over coding assistants in your SaaS backend development.

    Talk to an Expert