ISNAD Equips Multi-Agent Systems with a Chain of Trust

Stop Asking Only “Who Said It”—Ask “How Did This Claim Come About?”

Recently, the authors of ISNAD released a preprint and accompanying code that attempt to add a layer of “claim-level trust chains” to multi-agent LLM systems. Every factual conclusion in a final answer should be traceable to its original evidence, extraction process, transformation nodes, and verification path, rather than merely accompanied by a few seemingly relevant links.

The authors explicitly state that the work is still at the stage of seeking criticism and validation, and that some design choices have not yet been thoroughly tested. At this point, ISNAD is therefore better viewed as a trusted data structure and engineering methodology than as a mature “hallucination killer.”

But it targets the right problem.

In today’s multi-agent pipelines, an answer may pass through a search engine, web scraper, structured extraction model, domain agent, synthesis model, and formatting node. Every node may return normally, the entire chain may throw no exceptions, and yet the final answer can still quietly diverge from the source material.

These errors are particularly difficult to handle because the system often appears “green” at the observability layer: HTTP status codes are normal, tool calls succeed, agent identities are valid, and the workflow finishes as expected. What is wrong is a specific claim in the answer, while existing tracing systems can usually tell developers only “which agent called what and when,” not “what exactly this statement was based on.”

That is the missing layer ISNAD aims to provide.

From Chains of Transmission to LLM Trust Chains

The name ISNAD comes from the classical isnād–rijāl method of validating transmitted reports. According to the authors’ summary, this method includes several key principles:

• Every report retains its complete chain of transmission, rather than recording only the final narrator;
• Each transmitter in the chain is evaluated separately for reliability and accuracy;
• A chain’s trustworthiness is constrained by its weakest link;
• Mutually independent chains of transmission can increase confidence;
• A complete chain does not mean the content is necessarily correct—the information itself must still be examined separately.

When mapped onto multi-agent systems, a “transmitter” is no longer limited to a person. It may also be a webpage, database, search API, scraper, OCR system, parsing script, model, verifier, or human review node.

For example, suppose a system outputs:

A company’s second-quarter revenue increased by 27% year over year.

Traditional RAG might place a source link at the end of the sentence. ISNAD tracks much finer-grained information: which table the number came from, which parser read the table, whether the parser misaligned the quarterly columns, whether the synthesis model changed quarter-over-quarter growth into year-over-year growth, whether a verifier recalculated the figure, and whether a second corroborating chain is genuinely independent.

This turns trustworthiness from a vague score into an inspectable evidence graph.

The Smallest Unit of Record Should Be a “Claim,” Not an Entire Answer

One of ISNAD’s most commendable features is that it pushes verification granularity down to the claim level.

A model response typically mixes several kinds of content: verifiable facts, inferences, recommendations, predictions, and rhetoric. Assigning the entire text a confidence score of 0.86 has very limited engineering value. What developers actually need to know is which sentence lacks evidence, which number was transformed, and which conclusion comes from only a single source.

A simplified claim record might look like this:

claim_id: revenue-growth-q2
text: A company’s second-quarter revenue increased by 27% year over year
claim_type: factual
source_evidence:
  - source_id: filing-table-3
    locator: Table 3, row 2
    evidence_hash: sha256:...
transmission_chain:
  - node: web-fetcher
    operation: fetch
  - node: table-parser
    operation: extract
  - node: finance-agent
    operation: normalize
  - node: synthesis-agent
    operation: compose
verification:
  entailment: passed
  arithmetic_check: passed
  independent_chains: 1
  conflict_status: none
trust_status: weakly_supported

Several easily overlooked details matter here.

First, the system should record evidence locations and transformation operations, rather than broadly storing a model’s hidden chain of thought. The former facilitates auditing; the latter is unstable and may also introduce privacy risks, prompt leakage, and storage costs.

Second, claims should be made as atomic as possible. “Revenue increased by 27%, exceeding market expectations and demonstrating that the transformation was successful” actually contains at least three claims: the growth figure, the comparison with expectations, and the causal judgment about the success of the transformation. Each requires entirely different evidence.

Third, the trust chain should ideally be a graph rather than a simple linked list. Real-world synthesized answers often merge multiple sources, while a single source may support multiple conclusions. Only a directed graph can properly represent branches, merges, conflicts, and cyclic calls.

Most “Independent Verification” Is Not Actually Independent

Multi-agent systems often use self-consistency, majority voting, or debate to reduce error rates: several agents answer separately, and the majority conclusion is selected. The problem is that multiple agents may call the same model, find the same set of webpages, or even cite the same press release.

Agreement among three agents does not automatically equal three pieces of evidence.

This is precisely where ISNAD’s concept of “independent chains” becomes valuable. Independence cannot be calculated by counting agents; it must be checked upstream through source lineage:

• Were two media reports both rewritten from the same corporate announcement?
• Do two databases share the same upstream data provider?
• Are two models merely paraphrasing the same search snippet?
• Did the supposed secondary verification read the answer generated during the first pass?
• Did two paths use the same webpage content contaminated by prompt injection?

If the evidence ultimately converges on the same root node, the paths count only as same-source repetition, not independent corroboration.

Making this determination is far harder than “calling the model again,” but it is much closer to trustworthy verification in the real world. Model consensus shows only that generation distributions have converged; it does not prove that a fact is correct. If five models all read the same erroneous material, they will often simply produce the same wrong answer with greater confidence.

How It Differs from RAG Citations and Agent Tracing

ISNAD is not intended to replace existing observability tools, but to supplement them at the semantic layer.

RAG Citations Answer “What Sources Are Near the Answer?”

Common citation systems attach documents to a passage, but the existence of a link does not mean that the link supports the sentence. A model may cite a real webpage while misstating its year, subject, or conditions.

A claim-level trust chain also requires entailment checking: does the evidence actually support the conclusion, rather than merely being topically related?

Distributed Tracing Answers “Where Did the Request Go?”

Spans, traces, and tool logs are well suited to locating latency, failed nodes, and call relationships. But a successful span means only that a node completed its operation, not that the content it generated was correct.

What ISNAD aims to record is semantic lineage: how a conclusion was produced from evidence, and what extraction, normalization, calculation, and rewriting operations were performed along the way.

Agent Authentication Answers “Who Is Authorized to Do What?”

Identity, permissions, and tool access controls can prevent unauthorized operations, but they cannot determine whether an authorized agent read incorrect material. Trusted identity and trusted content are two separate problems.

Taint Tracking Answers “Where Does Untrusted Data Flow?”

Security systems can label data from external webpages as untrusted and prevent it from flowing directly into sensitive tools that make payments, delete databases, or perform similar operations. ISNAD naturally complements this approach: taint tracking focuses on controlling risk propagation, while trust chains focus on the evidence and verification behind specific claims.

The Real Challenge Is Not Storing the Chain, but Rating It

Writing sources and agent IDs to a database is not difficult. Whether ISNAD is useful depends on how it handles the following engineering challenges.

1. How Should the Weakest Link Be Calculated?

“The entire chain is no stronger than its weakest node” is an intuitive principle, but simply taking the lowest score can be misleading.

A webpage with an average reputation may contain a directly verifiable official document, while a highly reputable media outlet may make an error when relaying a figure. Source reputation, evidence relevance, extraction accuracy, and content consistency cannot be compressed into a single opaque aggregate score.

A more reasonable approach is to retain multidimensional statuses, such as:

• Source identity and historical reliability;
• Whether the original evidence is accessible and precisely locatable;
• Whether fetching and parsing were complete;
• The strength with which the evidence entails the claim;
• Whether numbers, dates, and entities passed deterministic checks;
• Whether genuinely independent corroborating chains exist;
• Whether conflicts between sources were detected.

The final system can then output statuses such as “publishable,” “wording must be qualified,” or “human review required,” rather than a spuriously precise score of 87.3.

2. Claim Segmentation Can Itself Fail

If claims are split too coarsely, different facts are bundled together for verification. If they are split too finely, record volume and verification costs explode. In a long report, a single execution may produce hundreds of claims and thousands of evidence edges—far beyond the scale of ordinary request tracing.

A more practical strategy is to prioritize high-risk claims: numbers, dates, legal conditions, medical recommendations, attributions to individuals, and conclusions that trigger external actions. Greetings, stylistic expressions, and low-risk suggestions do not need the same level of verification.

3. Citations Can Be “Laundered” by Models

An attacker can create a webpage containing numerous legitimate-looking citations, inducing an agent to treat it as a high-quality secondary source. A model may also generate a link that genuinely exists but does not support the conclusion.

A trust chain therefore cannot merely check whether a URL exists. It must also preserve a snapshot or content hash of the original evidence, record the exact supporting passage, and verify the relationship between the claim and that passage. For dynamic webpages, the fetch time and version must also be recorded; otherwise, a later audit may see entirely different content.

4. Verifiers Can Also Make Mistakes

Using another LLM to determine whether “the evidence supports the conclusion” merely adds another probabilistic node. It may improve coverage, but it cannot provide formal guarantees.

Tasks such as recalculating figures, converting units, comparing dates, and checking database constraints should be assigned to deterministic programs whenever possible. Model-based verifiers should be reserved for issues that are difficult to formalize, such as semantic entailment and contextual conflicts. A path for escalation to human review should also be retained where necessary.

A More Practical Implementation Sequence

Development teams do not need to build a complete trust graph for every output from the outset. A more robust approach has four steps.

1. Define a claim data contract first. Require key facts to include evidence locations, source versions, upstream nodes, and transformation types.
2. Start with deterministic verification. Prioritize numbers, units, dates, entities, and structured fields rather than assigning all verification work to another model.
3. Set publication thresholds. Downgrade unsupported claims to uncertain wording; stop automated execution when the chain is broken; escalate source conflicts to human review.
4. Add reputation ratings last. Without real failure samples and labeled datasets, complex scoring formulas often merely wrap subjective judgments in numbers.

Evaluation should not focus solely on the accuracy of the final answer. At minimum, it should also measure:

• Claim coverage: how many verifiable conclusions are included in the trust chain;
• Evidence entailment accuracy: whether the cited evidence truly supports the claim;
• Source-lineage completeness: whether claims can be traced back to their original root nodes;
• Independent corroboration detection: whether the system can identify when multiple sources actually share the same origin;
• Silent-error detection rate: whether the system can intercept cases where the workflow succeeds but the content is wrong;
• Added latency and cost: whether the trust layer makes the system impractical to use.

Assessment: A Valuable Direction, but Do Not Mistake “Having a Chain” for “Proof of Truth”

ISNAD’s greatest value is not that it proposes yet another confidence score, but that it emphasizes that accountability in multi-agent systems should be assigned at the level of individual claims.

As agents move beyond simple question answering into research, financial analysis, compliance review, and automated execution, developers need more than complete logs. They need to answer three questions: Where did the conclusion come from? What transformations did it undergo? Who verified it, and how?

However, even a structurally complete trust chain proves at most that the system preserved an auditable transmission path. It cannot, by itself, prove that the conclusion is true. The original source may be wrong, multiple sources may share the same origin, verifiers may misjudge the evidence, and rating rules may introduce bias. The classical method’s insistence on separating chain examination from content examination is precisely the principle that must not be lost here.

At this stage, ISNAD is therefore best positioned as a “semantic software bill of materials” for multi-agent systems. It will not automatically eliminate errors, but it can make it much harder for them to hide inside a fluent answer.

For high-risk agents, that is already highly useful. Whether ISNAD can consistently detect more errors than existing citation validation, process verification, and execution-provenance approaches remains to be seen through public benchmarks, ablation studies, adversarial testing, and real production data. The authors’ candid acknowledgment that parts of the design remain unvalidated is, in fact, a reason to focus discussion on measurable engineering benefits rather than prematurely packaging it as a complete trust standard.

References

• ISNAD authors release a preprint and code and solicit feedback: The authors introduce the motivation and core principles behind claim-level trust chains, along with the aspects that remain to be validated.
• Discussion of process evaluation and execution traces in multi-agent collaboration: An overview of related research directions, including execution provenance, process evaluation, silent failures, and accountability boundaries across nodes.