Agent Citation Attribution Specification: Verifiable Source Tracking for Autonomous AI Agents

TL;DR: Autonomous agents make multi-step decisions that touch many sources. The output that reaches a user or another system needs to carry which sources were consulted, which claims came from which source, and how the chain of tool calls produced the final answer. This spec defines an HTTP header, a manifest format, and a chain-of-citation envelope that together make outbound agent citations machine-verifiable.

Why outbound agent citations need a spec

Most citation infrastructure is inbound: how engines attribute the sources they cite. Agents are different. An autonomous agent can call ten tools, read three documents, and emit one final answer. Without explicit attribution, the consumer of that answer has no way to verify which claim came from which source, whether a source was paraphrased correctly, or whether the agent fabricated a citation.

The gap is operational, not academic. Without a spec, every agent platform invents its own format, and downstream systems cannot interoperate. This document defines the minimum interoperable surface.

Specification overview

A conformant agent citation attribution implementation has three components.

Component 1: Citation-Source HTTP header

When an agent emits a response over HTTP, it MUST include a Citation-Source header listing every source URL consulted by the response. The header value is a comma-separated list of ; manifest="" tuples.

Example:

Citation-Source: ; manifest="https://agent.example/runs/123/cite/a",

; manifest="https://agent.example/runs/123/cite/b"

The header is the cheap interop layer: any consumer can extract the source list without parsing the body.

Component 2: Per-claim provenance manifest

Each manifest URL resolves to a JSON document that maps individual claims in the response to their sources.

{
  "run_id": "123",
  "agent_id": "agent.example/v1",
  "emitted_at": "2026-04-28T10:00:00Z",
  "claims": [
    {
      "claim_id": "c1",
      "text": "Programmatic GEO templates emit at most one canonical question per page.",
      "sources": [
        {
          "url": "https://geodocs.dev/strategy/programmatic-geo-framework",
          "retrieved_at": "2026-04-28T09:55:00Z",
          "hash": "sha256:...",
          "excerpt_offset": [1234, 1380]
        }
      ],
      "confidence": "high"
    }
  ]
}

The manifest is the verification surface. A consumer (downstream agent, audit system, end user UI) can re-fetch the source URL and verify the excerpt at the named offsets against the recorded hash.

Component 3: Chain-of-citation envelope

When an agent's response was produced by chaining multiple tool calls, the manifest includes a chain array that records the tool call DAG.

"chain": [
  {
    "step": 1,
    "tool": "search",
    "inputs": {...},
    "outputs_ref": "runs/123/step/1",
    "sources": ["https://example.com/article-a"]
  },
  {
    "step": 2,
    "tool": "summarize",
    "inputs_ref": "runs/123/step/1",
    "outputs_ref": "runs/123/step/2",
    "sources": ["https://example.com/article-a"]
  }
]

The chain lets a downstream system reconstruct how a claim made it from a raw source through transformations into the final answer.

Verification flow

A consumer that wants to verify an agent's output performs four steps:

1. Read Citation-Source to get the source list.
2. Fetch the manifest URL for each tuple.
3. Re-fetch the source URL and compare the recorded hash.
4. Walk the claims array and check that each claim text is supported by the recorded excerpt.

When any step fails, the verifier flags the response and records a verification incident.

Discovery

Agent platforms expose /.well-known/agent-citation-attribution listing supported header version, manifest schema URL, signing algorithm, and a contact for verification disputes.

A minimum discovery document:

{
  "version": "1.0",
  "manifest_schema": "https://agent.example/schema/manifest-v1.json",
  "supported_signing": ["http-message-signatures"],
  "contact": "attribution@agent.example"
}

Conformance levels

• Level 1 (header only). Citation-Source header present; no per-claim manifest. Useful for legacy agents.
• Level 2 (manifest). Per-claim manifest with sources, hashes, and excerpt offsets.
• Level 3 (chain + signed). Manifest plus chain-of-citation envelope plus an HTTP Message Signature on the manifest.

Level 3 is the target for agents publishing into regulated environments.

Pairing with verified agent identity

Citation attribution and verified agent identity are separate but complementary. Verified identity establishes who is making the request to a publisher. Citation attribution establishes how the agent attributed its outputs back to those sources. A consumer that trusts both can audit an agent's behavior end to end.

Implementation pitfalls

• Reusing a single manifest across runs. Manifests are per-run; reuse breaks verification.
• Skipping the hash. Without a hash, source mutation cannot be detected.
• Free-text claim ids. Use stable claim_ids so downstream systems can dedupe and reference.
• Unsigned manifests at Level 3. A manifest without a signature can be rewritten in transit.
• Logging only the final claim list. Without the chain, you cannot defend a claim that was rewritten in step 2.

FAQ

Q: Why a header instead of only a JSON envelope?

The header is a lightweight interop layer. Many consumers read headers without parsing the body, so the header makes basic source discovery trivial.

Q: Should every claim have its own manifest entry?

Yes for verifiable claims. Stylistic and connecting prose does not need entries; treat the manifest as the citation index, not a sentence map.

Q: What about agents that use proprietary tools?

The chain entries can omit private inputs; record the tool name, source list, and a hash of the inputs without revealing them. Verification still works because the hash is part of the chain.

Q: Does this require IETF standardization?

No. The spec is designed to operate before standardization. The header name is intentionally specific so it does not collide with future IANA registration.

Q: Can I implement Level 1 first and upgrade?

Yes. Level 1 is the on-ramp. Move to Level 2 once your agent runtime has stable claim ids, then to Level 3 when you sign manifests as part of identity onboarding.