Agent Output License Disclosure Specification

TL;DR

• An output-rights statement declares who owns each agent response (operator, end user, or model vendor) and is rendered in the run metadata, the response payload, or both.
• Training-data provenance disclosure names the model family and points readers to the vendor's published data sources or model card so claims about data origin remain verifiable.
• Attribution requirements describe what downstream commercial reusers must surface (model name, vendor, run timestamp) and reference SPDX-style identifiers when the output bundles licensable assets.
• OpenAI, Anthropic, Meta's Llama family, and Google's Gemini differ on output-rights assignment and attribution defaults; the disclosure must reference the specific vendor terms in force at run time.

Definition

An agent output license disclosure is a structured statement—typically a small JSON object or a short prose block—attached to AI agent responses that names the licensing posture for that response. It covers three axes: (1) output-rights ownership (who may reuse the response and under what conditions), (2) training-data provenance (which model produced the response and what its public data-sourcing posture is), and (3) attribution requirements (what downstream consumers must display or pass through).

The disclosure is distinct from the agent's overall terms of service. ToS governs the agent product; the disclosure governs a specific response artifact. Both can coexist: an agent's ToS may say "output rights assigned to user" while the per-response disclosure adds vendor-required attribution because the underlying model vendor's usage policy demands it.

Disclosure formats range from minimal (a one-line output-license header) to verbose (a full payload with SPDX identifiers for any licensable embedded assets, model name, run ID, and the in-force vendor policy URL). The right level depends on the downstream reuse risk: outputs fed into a public publication carry higher disclosure obligations than ephemeral chat replies.

Why this matters

Without a per-response disclosure, downstream commercial reusers must reverse-engineer the licensing posture from the agent's ToS, the underlying model vendor's usage policy, and any embedded asset licenses. That work is brittle and tends to fail in three ways: (1) the vendor changes terms after the response is generated, (2) the response embeds third-party licensable content (open-source code, CC-licensed text) without a passthrough license declaration, and (3) the agent operator's contract with the end user is silent on output ownership, leaving the downstream reuser to guess.

Procurement and legal teams now treat AI agent output as a supply-chain artifact. Enterprise buyers ask for evidence that outputs are licensed for the buyer's intended use; without a disclosure, the procurement gate stalls. EU AI Act provisions on transparency for general-purpose AI models add a regulatory dimension: providers that integrate a foundation model owe disclosure obligations downstream that propagate through the agent layer.

Per-response disclosure also supports incident response. If a vendor revokes or restricts an output's license retroactively, downstream users can identify affected artifacts by querying their disclosure store rather than auditing every saved response by hand.

How it works

A disclosure has three structural choices: placement, format, and reference layer.

Placement options. The disclosure can ride in the response envelope (a sibling field to the response body), in HTTP headers (e.g. X-Output-License: ...), or appended to the response body as a footer block. Envelope placement is most robust because it survives serialization. Header placement is invisible to the model and useful when the agent runtime adds the disclosure post-hoc. Footer placement is human-readable but easily stripped by downstream consumers.

Format options. The disclosure may be free-text, structured JSON, or SPDX-formatted. Structured JSON with a known schema (model, model_version, output_rights, attribution_required, training_data_doc_url, vendor_policy_url, run_id, run_timestamp) is the practical sweet spot: machine-parseable for downstream tooling, human-readable when serialized. SPDX identifiers apply when the response embeds licensable assets (open-source code, CC-licensed content) and let downstream consumers run their existing license-compliance tooling against the response.

Reference-layer variation. Vendor differences are material. OpenAI's usage policy generally assigns output rights to the user subject to product-specific carve-outs (per current OpenAI Usage Policies). Anthropic's terms similarly grant output rights to the customer with use-case restrictions (per the Anthropic Usage Policy). Meta's Llama family is governed by the Llama Community License with downstream-distribution constraints based on monthly active users. Google's Gemini terms vary by tier (consumer, Workspace, Vertex AI) and per-tier output-rights language differs. The disclosure must reference the specific vendor terms in force at run time and link the canonical policy URL—not a paraphrase—so downstream readers can verify.

A minimal disclosure block in JSON form would carry: model, model_version, output_rights (string: "assigned-to-user" / "shared" / "vendor-restricted"), attribution_required (boolean), attribution_template (string), training_data_doc_url (URL to the model card or data-sourcing doc), vendor_policy_url (URL to the policy in force at run time), run_id, run_timestamp, and optional embedded_asset_licenses (array of SPDX identifiers).

Practical application

Implement disclosure at the agent runtime layer, not the prompt layer. A prompt-engineered disclosure is unreliable because the model can drop or paraphrase it; a runtime-injected disclosure is deterministic.

Step 1—pick a schema. Define an output_license object in your response envelope with the fields named above. Version the schema so future changes (e.g. adding data_residency) are non-breaking.

Step 2—populate at run time. The runtime knows the model, model version, run ID, and timestamp; it should fetch the operator's output-rights policy and the vendor's policy URL from configuration. Avoid hardcoding policy text into the runtime—link to the canonical URL instead.

Step 3—store the disclosure with the response. Persist the full disclosure object alongside the response in your audit log, even if you only return a subset to the caller. This supports the incident-response use case.

Step 4—pass-through for chained agents. When the output of agent A becomes the input of agent B, B's disclosure must include or reference A's disclosure so the chain remains auditable. The simplest pattern is to store the chain as an ordered list under upstream_disclosures in B's output envelope.

Step 5—surface in the UI for human-facing reuse. If the agent renders output to a UI for copy-paste reuse, expose a "License & attribution" affordance that surfaces the disclosure to the human user. This is the lowest-friction way to satisfy attribution requirements in practice.

Common mistakes

Procedural disclosure only in ToS. The product ToS describes the policy in the abstract but the per-response disclosure is what survives in downstream pipelines; relying on ToS alone fails enterprise procurement gates.

Free-text disclosure. Free-text statements drift across responses, defeat machine parsing, and frequently omit the run ID and vendor policy URL.

No passthrough for chained agents. Multi-agent pipelines that drop upstream disclosures break the audit trail; downstream reusers see only the last agent's posture and miss embedded vendor restrictions from earlier hops.

Hardcoded vendor policy text. Vendor policies change; copies in the runtime go stale. Always link to the canonical vendor URL with a vendor_policy_url field.

Missing SPDX identifiers for embedded assets. When the response includes generated code or quoted CC-licensed text, omitting SPDX identifiers leaves downstream license-compliance tooling blind, which becomes a procurement-stage objection.

FAQ

Q: Who owns the output of an AI agent—the user, the operator, or the model vendor?

It depends on the layered terms in force. The model vendor's usage policy sets the floor (typically assigning output rights to the customer subject to use-case restrictions); the agent operator's terms with the user can narrow or pass through those rights; per-response disclosure clarifies the specific posture for that artifact. The disclosure should name all three layers and link the canonical policy URLs for each.

Q: Are SPDX identifiers applicable to AI agent outputs?

SPDX identifiers apply when the response embeds licensable assets such as open-source code snippets or CC-licensed quotations. The output as a whole is generally not a licensable work in the SPDX sense, but the embedded assets within it are; surfacing those identifiers under embedded_asset_licenses lets downstream license-compliance tooling (FOSSA, Black Duck, ClearlyDefined) process the response.

Q: Do open-weights and closed-weights models have different license obligations?

Yes. Closed-weights models (OpenAI, Anthropic, Gemini paid tiers) are governed by the vendor's usage policy and contract with the operator; output disclosure references those terms by URL. Open-weights models (Llama, Mistral open releases, Gemma) carry an explicit weights license (e.g. Llama Community License) whose downstream-distribution constraints can propagate to outputs depending on use; the disclosure should reference both the vendor policy URL and the weights-license URL when the agent runs an open-weights model.

Q: What must a downstream commercial reuser disclose?

At minimum, the model name, the agent or operator, and any attribution template the disclosure flagged as required. When the response contains embedded licensable assets, the reuser must also pass through those asset licenses (e.g. include the open-source notice). Many enterprise buyers add internal disclosure obligations on top, but the per-response disclosure defines the floor.

Q: How does training-data provenance differ from the output-rights statement?

Training-data provenance answers "where did this model's training data come from"; the output-rights statement answers "who can use this specific response and how". Both belong in the disclosure but serve different audiences: provenance addresses regulatory and ethical-sourcing concerns; output rights addresses commercial-reuse rights.

Q: What changes under the EU AI Act for agent output disclosure?

The EU AI Act introduces transparency obligations for general-purpose AI providers and downstream integrators (Regulation EU 2024/1689). Practically, the disclosure should add a regulatory_disclosures field that names the upstream foundation-model provider, points to that provider's published data-sourcing documentation, and flags any high-risk-system use cases where additional documentation is required. Consult counsel for jurisdiction-specific obligations.