LLM Output Provenance Attestations: Prove Which Model, Prompt, and Sources Produced an Answer

“Generated by AI” is a disclosure, not provenance. It does not tell an auditor which model version ran, which prompt template was used, which documents were retrieved, which safety policy applied, or whether the displayed answer is the same output the system originally produced.

A provenance attestation answers those questions with a structured, tamper-evident record. The record binds an output digest to the execution identity and the material inputs that produced it. It supports incident response, reproducibility, policy enforcement, and downstream trust without requiring every consumer to access private prompts or raw user data.

The design resembles software supply-chain provenance. Inputs become materials, the model pipeline becomes the builder, and the answer becomes the artifact.

Define the trust claim precisely

An attestation cannot prove that an answer is true. It can prove a narrower statement: a specific trusted service observed a specific pipeline produce bytes with a specific digest under recorded conditions.

Start with claims your verifier can test:

• the output hash matches the artifact;
• the signer was an approved execution service;
• the model identifier and deployment revision were allowed at execution time;
• prompt, tool, retrieval, and policy digests are present;
• sensitive raw inputs were not exposed in the public envelope;
• the timestamp and nonce satisfy freshness rules.

Do not market provenance as fact-checking, authorship detection, or proof that no hidden influence existed. A compromised builder can sign a false record, and a faithful model run can produce an inaccurate answer. Trust depends on both cryptography and the integrity of the runtime.

Build a canonical statement

Use a stable serialization format before hashing and signing. JSON with unspecified key ordering is risky; adopt a canonical JSON scheme or a signed envelope format with well-defined bytes.

{
  "predicateType": "https://egoistai.com/schemas/llm-provenance/v1",
  "subject": [{
    "name": "answer.md",
    "digest": { "sha256": "..." }
  }],
  "predicate": {
    "builder": "prod-answer-service@sha256:...",
    "model": "provider/model@deployment-revision",
    "promptDigest": "sha256:...",
    "policyDigest": "sha256:...",
    "retrievalManifestDigest": "sha256:...",
    "toolReceiptsDigest": "sha256:...",
    "startedAt": "2026-09-08T11:00:00Z",
    "finishedAt": "2026-09-08T11:00:04Z"
  }
}

The model name alone is insufficient. Providers may update behavior behind an alias. Record the most specific deployment or snapshot identifier available, the API surface, decoding parameters, and any system fingerprint returned by the provider. If exact weights are not exposed, state that limitation rather than inventing precision.

Hash prompts without leaking them

Raw prompts may contain personal data, trade secrets, or attack instructions. Do not put them in a public attestation. Store sensitive evidence in a protected audit system and publish only digests or opaque references.

Hash each logical layer separately: system policy, application template, developer additions, user input, retrieved context, and tool results. This helps investigators identify which layer changed without disclosing its content.

Plain hashes are vulnerable when the hidden input has low entropy. An attacker can guess common prompts and compare hashes. Use keyed hashes for sensitive values, or commit to a salted Merkle tree where the salt remains in the protected audit store.

const digest = hmacSha256(auditKey, canonicalize(promptLayer));

Keyed commitments reduce public guessability but require the auditor to trust key custody. Document who can reveal or verify each layer and under what authorization.

Attest retrieval and tools as first-class inputs

Retrieval-augmented generation changes whenever the index, ranking model, document version, or query changes. Record a manifest containing document IDs, immutable content digests, source URLs when appropriate, timestamps, chunk ranges, retrieval scores, and index revision.

Do not sign only the URLs. Web content can change after the answer is produced. A digest of the exact bytes or normalized excerpt lets an authorized auditor distinguish source drift from model behavior.

Tool calls need receipts that bind the tool name, schema version, validated arguments, authorization context, result digest, and external correlation ID. Secret values should be redacted before canonicalization, with a separate protected record if full reconstruction is required.

The attestation should also identify the orchestration code. Otherwise the same prompt and model could be wrapped by different tool-selection logic, retry behavior, output repair, or moderation stages and still appear identical.

Sign in a protected execution boundary

The application process that asks the model should not hold a long-lived exportable signing key. Prefer a cloud key-management service, hardware security module, workload identity, or short-lived keyless signing flow. Bind signing authorization to the production workload identity and reviewed deployment digest.

Sign only after output validation and normalization. If a formatter changes whitespace after signing, the subject digest will no longer match. Either sign the exact delivered bytes or define and publish a canonicalization profile for the artifact.

Separate roles:

• the builder runs the model pipeline;
• the attester observes approved evidence and signs the statement;
• the transparency store makes issuance discoverable;
• the verifier applies consumer policy.

These roles can share infrastructure, but their identities and permissions should remain distinct. A transparency log can make deletion or backdating harder to conceal, although it may be inappropriate for private workloads unless entries reveal only safe metadata.

Verify policy, not just signatures

A valid signature only means an expected key signed something. The verifier must check the predicate type, trusted issuer, subject digest, time window, builder identity, model allowlist, policy revision, and required evidence fields.

const result = verifyEnvelope(envelope, trustRoots);
assert(result.subject.sha256 === sha256(deliveredBytes));
assert(allowedBuilders.has(result.predicate.builder));
assert(allowedModels.has(result.predicate.model));
assert(result.predicate.policyDigest === requiredPolicyDigest);

Define downgrade behavior. A missing or invalid attestation might block a regulated report, show a warning on internal analysis, or simply reduce confidence for low-risk content. Never silently treat “unsigned” as “verified.”

Revocation and key rotation matter. Retain enough historical trust metadata to verify old attestations while preventing a compromised key from signing new ones. Include schema versions so verifiers reject unknown semantics rather than misreading them.

Handle streaming and edited outputs

Streaming produces bytes before the final digest exists. Mark the stream as provisional, then issue an attestation after completion. If consumers need chunk-level integrity, use a hash chain or Merkle tree and sign the final root.

Human edits create a new artifact. Preserve the model-output attestation, record the transformation, and issue a second statement binding the edited result to its parent. Do not keep the original signature attached to modified text.

The same applies to automated safety rewrites, localization, summarization, and formatting. Provenance is a graph of transformations, not a single badge copied forward.

Test the evidence chain

Create negative tests for altered output bytes, swapped retrieval manifests, unknown model revisions, expired signers, missing policy digests, replayed nonces, and valid signatures from unapproved builders. Test that redaction cannot change the meaning of signed fields.

Measure attestation issuance failures and verification rejection reasons. If the signing service is unavailable, decide explicitly whether the pipeline stops or produces clearly unverified output. Quietly skipping provenance during an outage destroys the control when it is most needed.

Good provenance makes AI output traceable, not infallible. It gives teams a defensible chain from artifact to execution evidence and makes later changes visible. That is a concrete security property—far stronger than a generic “AI-generated” label and far narrower than a promise of truth.