BuildNot yet confirmed elsewhere1 publisher2 min readPublished Updated
ProvenanceGuard checks whether an agent's claim came from the tool it cited
Multiverse Computing published ProvenanceGuard on September 29, 2026, a layer that checks which MCP tool each of an agent's claims came from. It flags facts that are true somewhere in the pooled evidence but credited to the wrong tool.
The Engineer · Build desk
Finance, healthcare, compliance: source authority decides if an answer is actionable. Trading agents: may cite Bloomberg but pull from a Reddit scrape. RAGAS, MiniCheck, AlignScore: don't track which tool supplied which sentence. MCP servers: no built-in provenance.
- exposure Finance, healthcare, compliance Source authority decides whether an answer is actionable, so a fact credited to the wrong tool matters most here, claim 5
- exposure Trading agents Can cite Bloomberg terminal data while actually pulling from a Reddit scrape, claim 6
- constraint RAGAS, MiniCheck, AlignScore Pool all evidence into one context and do not track which tool supplied which sentence, claim 11
- constraint MCP tool servers No built-in provenance: no signed responses, data lineage attestation or confidence scores, claim 9
| Who | How | Kind | Claim |
|---|---|---|---|
| Finance, healthcare, compliance | Source authority decides whether an answer is actionable, so a fact credited to the wrong tool matters most here | exposure | 5 |
| Trading agents | Can cite Bloomberg terminal data while actually pulling from a Reddit scrape | exposure | 6 |
| RAGAS, MiniCheck, AlignScore | Pool all evidence into one context and do not track which tool supplied which sentence | constraint | 11 |
| MCP tool servers | No built-in provenance: no signed responses, data lineage attestation or confidence scores | constraint | 9 |
What happened
- Multiverse Computing's own example: an agent cites the account record for a 30-day refund window, but the policy came from a scraped FAQ, and a source-blind checker approves the misattributed fact.
- ProvenanceGuard breaks an answer into atomic claims, maps each one to the specific tool the agent cited, and flags any claim that is supported only by a different tool.
- A claim that fails is either blocked before it reaches the user or sent to a repair step that re-queries the tool the agent should have used.
- Existing fact-checkers such as RAGAS, MiniCheck, AlignScore and SummaC pool every tool's output into one context and never track which tool supplied which sentence.
Why it matters
- cost The check runs one entailment pass per claim at 50 to 200 milliseconds each, so a 10-claim answer carries 0.5 to 2 seconds; the article says a support bot can absorb that and a high-frequency trading agent cannot.
- exposure The gap bites hardest in finance, healthcare and compliance, where source authority decides whether an answer is actionable; the article's case is a trading agent that cites Bloomberg data but pulled from a Reddit scrape.
- constraint Ordinary fact-checkers answer only whether a claim is supported, so source authority becomes a separate verification layer teams have to add on top of the agent.
Nothing in the stack forces the agent to be honest about where a fact came from. The Model Context Protocol lets an agent call several tools in a single turn, and each returns a structured chunk [8]. The orchestration layer can log which tool returned which chunk. The prompt the model works from does not carry that record, so the agent can write "According to the database" and quote the PDF [10].
MCP has no provenance primitives of its own. It does not require a server to sign its responses, attest to data lineage, or declare a confidence score [9]. Multiverse Computing calls the resulting failure cross-source conflation [4].
ProvenanceGuard sits between the agent's output and the user and takes three inputs: the final answer, the tool outputs each tagged with its name and metadata, and the agent's citations, explicit or inferred [12]. A citation mapper pulls phrases such as "According to the account record" with regex or an LLM and matches them to the tool that produced them. A source-scoped entailment model, often a fine-tuned DeBERTa, then checks each claim only inside that tool's evidence [15].
That per-claim figure depends on which entailment model you run and on the hardware you run it on, neither of which the article specifies, so you cannot carry it onto your own stack without measuring. To shrink the cost, the design batches claims and verifies them in parallel, or verifies only the claims that cite high-stakes sources such as account records and compliance documents [16].
What to watch
- Whether Multiverse Computing publishes measured latency on named entailment models and hardware, since the 50 to 200 millisecond figure is unqualified.
- Whether MCP itself gains provenance primitives such as response signing, lineage attestation or confidence scores that would move this check into the protocol.
- Whether anyone benchmarks ProvenanceGuard against RAGAS, MiniCheck, AlignScore or SummaC on cross-source conflation specifically.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence30
- Adoption
- Insufficient
- Hype gap+10
- Incentives
- Insufficient
- Confidence30
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Most fact-checking systems for LLM agents check whether a claim is supported by the evidence, but not whether the claim came from the source the agent cited.
- [2]
A source-blind verifier passes any claim that appears somewhere in the pooled evidence.
- [3]
In the article's example an agent says 'According to the account record, this plan includes a 30-day refund window,' but the refund policy came from a scraped FAQ rather than the structured account record, and the verifier approves it.
- [5]
Cross-source conflation matters most in financial, healthcare and compliance contexts, where the authority of the source determines whether the answer is actionable.
- [6]
The article's other example is a trading agent that cites Bloomberg terminal data but actually pulled from a Reddit scrape, which it describes as dangerously misattributed.
- [7]
Multiverse Computing published ProvenanceGuard on September 29, 2026, a verification layer that checks source lineage and not just factual support, introducing source-aware verification as a separate concern from fact verification.
- [8]
The Model Context Protocol lets agents call multiple tools in a single turn, and each tool returns structured data.
- [9]
MCP has no built-in provenance primitives: it does not require servers to sign their responses, attest to data lineage, or declare confidence scores.
- [10]
The orchestration layer may log which tool returned which chunk, but the LLM prompt does not enforce citation discipline, so the agent can say 'According to the database' and pull facts from the PDF.
- [11]
Traditional fact-checkers RAGAS, MiniCheck, AlignScore and SummaC concatenate all evidence into a single context and ask whether each claim is entailed; they do not track which tool provided which sentence and do not penalize cross-source conflation.
- [12]
ProvenanceGuard sits between the agent's output and the user and receives the agent's final answer, the set of MCP tool outputs each tagged with tool name and metadata, and the agent's citations, explicit or inferred.
- [13]
ProvenanceGuard decomposes the answer into atomic claims using an LLM or dependency parser, maps each claim to the cited source, verifies entailment within that specific source using a fine-grained NLI model, and flags cross-source conflation when a claim is supported by evidence from a different tool than the one cited.
- [14]
If a claim fails source-aware verification, ProvenanceGuard can either block the answer or trigger a repair step that re-queries the correct tool.
- [15]
The citation mapper uses regex patterns or an LLM to extract phrases like 'According to X' and match them to tool names; the source-scoped NLI model, often a fine-tuned DeBERTa, checks entailment only within the evidence from the cited tool.
- [16]
Options to reduce latency include batch verification, collecting all claims and verifying in parallel, and selective verification, only verifying claims that cite high-stakes sources such as account records or compliance documents.
- [17]
Running an NLI model on every claim adds 50 to 200 milliseconds per claim, and for a 10-claim answer that is 500 to 2000 milliseconds.
- [18]
The article says this latency may be acceptable for a customer support chatbot but not for a high-frequency trading agent.
Sources
1 independent publisher whose own reporting we read for this story.
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- LLM agent verificationFollow
- Model Context ProtocolFollow
- Source provenance and attributionFollow
Entities
- Multiverse ComputingFollow
- ProvenanceGuardFollow
- Model Context ProtocolFollow
- RAGASFollow
- MiniCheckFollow
- AlignScoreFollow
- SummaCFollow
- DeBERTaFollow