ProvenanceGuard checks that an AI answer cites the right source
Multiverse Computing's verification layer checks not only whether a claim appears somewhere in an agent's evidence, but whether it came from the source the answer names.

An AI agent that reads a patient record, a policy document and a database can produce an answer that is true somewhere in that pile and still wrong about where it came from. Multiverse Computing calls that failure cross-source conflation, and in an article published on 29 September it sets out ProvenanceGuard, a verification layer that keeps source identity attached to every claim instead of collapsing the evidence into one anonymous context.
Supported somewhere is not the same as supported here
Existing faithfulness checks, from RAGAS through to MiniCheck, AlignScore and SummaC, generally ask whether a claim is supported by the evidence once that evidence has been pooled. They do not report which tool output supports each claim, or whether it is the source the answer names. The company's own example is an agent that says, "According to the account record, this plan includes a 30-day refund window." The window may be perfectly real and written in a policy document rather than the account record, in which case a pooled check passes and the attribution is still wrong.
Five steps and no retraining
ProvenanceGuard runs after a black-box agent has answered, reading the captured MCP trace with its tool outputs and source IDs. It breaks the answer into claims, finds the source most relevant to each one, checks whether that source supports it, compares that source with the one the answer names or implies, and then issues a per-claim verdict alongside an answer-level allow or block. The configuration the company evaluated runs locally, with MiniLM routing claims to sources, a DeBERTa NLI model checking support and a local language model handling the splitting. Numbers, dates and identifiers are checked literally, so a figure that is absent from the source cannot pass on the strength of a plausible sentence, and a blocked answer can be sent through a repair step and checked again.
What the test found
The evaluation drew on 281 real traces from a medical agent working across patient records, research articles and other tools, then asked human experts to check 361 claims taken from 40 answers held back from development. The experts judged 139 of those claims unsupported and ProvenanceGuard caught 138 of them, letting one through. It also held 67 claims that the experts considered supported for review or repair, which the company attributes to a deliberately cautious setting that prefers a second look to a false pass. Where a source was identifiable it picked the right one about 86 per cent of the time, and it finished highest of the five checkers tested on the paper's own measure.
Our opinion
Attribution errors are the kind of mistake that survives review precisely because everyone checks the fact and nobody checks the footnote, which makes the interesting claim here structural rather than numerical. Keeping source identity intact through the pipeline is what allows the miss to be caught at all, and 138 out of 139 is a consequence of that design rather than a lucky threshold. The caveats are real. A medical agent reading patient records is close to the easiest possible case for the argument, because conflating a chart with a journal article is exactly the error a clinician already fears, and the whole method rests on an agent that keeps a clean trace of its tool outputs and source IDs, an assumption that quietly excludes plenty of deployed systems. Sending roughly a fifth of the supported claims back for a human look is also a cost rather than a footnote: a verifier buys that recall with somebody's afternoon.