When AI agents talk to each other: the provenance problem in multi-agent chains

For years, enterprises treated a single AI model like a sealed box: a question goes in, an answer comes out. That model is changing fast. Today's enterprise systems are chains of AI agents that exchange data, instructions, and results autonomously: one agent extracts, another enriches, a third decides. Every handoff adds information, but no one keeps track of who produced what, and when.

This is where a problem most organizations have not yet confronted begins: data provenance in AI agent chains. When one agent acts on another's output, a wrong, manipulated, or fabricated data point propagates down the chain with no trace of where it came from. The governing answer of this article is straightforward: the only way to defend decisions and accountability in multi-agent chains is to certify data at the source, sealing every data point and output the moment it is produced, so each link stays verifiable backward. This is a question of provenance, not of compliance: regulatory obligations are handled separately, while what matters here is attribution and chain traceability. It sits within the broader picture of Digital Provenance, of which AI agent pipelines are the hardest proving ground.

Why no one in an AI agent chain knows where a data point came from

In a multi-agent chain, no one knows the origin of a data point because each agent receives the previous agent's output as if it were a fact, not a claim to be verified. Information changes hands, gets reworked, and progressively loses its link to whoever generated it.

The problem compounds with scale. According to Gartner forecasts cited by IBM, by 2028 a single Fortune 500 company could run as many as 150,000 AI agents, while today only 13% of organizations consider themselves ready to govern them. When thousands of agents exchange data with no shared record of origin, the company loses the ability to answer a trivial question: this number, where did it come from? The proliferation of agents, what analysts call agentic AI sprawl, turns every chain into a black box where the final result is the sum of undocumented steps. Agentic AI governance becomes impossible not because logs are missing, but because logs tell you what happened, not who produced the underlying data.

What data provenance means in a multi-agent system

Data provenance in a multi-agent system is the traceable, attributed record of the origin, history, and every transformation a data point undergoes as it moves from one agent to another. For each piece of information it answers three questions: who produced it, when, and what data it was based on.

Data provenance in a multi-agent system refers to the ability to reconstruct, for every piece of information circulating in the chain, its point of origin and the sequence of steps that modified it. It is not a simple chronological list of events: under the modeling adopted by standards such as W3C PROV, provenance is a directed, attributed graph, where nodes are data and agents and edges represent relationships of the kind "this output was generated by that agent from those inputs". In a multi-agent system this structure is essential, because a single final result may depend on dozens of intermediate transformations. Research efforts like PROV-AGENT, which extends W3C PROV to the Model Context Protocol, formalize exactly this need. Without a provenance graph, reconstructing the origin of a data point means querying, after the fact, systems that were never designed to remember. With a provenance graph, origin is a property of the data itself, available at any time and for any link in the chain.

How an error propagates down the chain without leaving a trace

An error propagates because each agent treats the input it receives as reliable by definition: it does not distinguish a verified data point from one fabricated by the previous agent. Communication between AI agents works by passing value, and value does not carry its own history.

From one agent's output to another's input

When an AI agent produces a result and hands it to the next, that result instantly becomes a "factual" input. Agent communication protocols, from the emerging agent-to-agent (A2A) standard to interoperability handled via MCP (Model Context Protocol), are designed to move information smoothly, not to certify its origin. If the extraction agent misreads a value in a document, the analysis agent processes it as correct, and the reporting agent presents it to the client as a fact. The error goes uncorrected because no link in the chain has reason to doubt the previous one. The same applies to hallucinated data: information invented by a model, once injected into the chain, is indistinguishable from a real data point for every downstream agent.

The loss of attribution and accountability

When an AI agent acts on another's output, the audit log shows the identity of the user or service that ran the operation, but not that of the agent that actually produced the upstream data. This is the "Who Did That?" problem of attribution in autonomous pipelines: the log says your name, not the producing agent's. It creates an attribution gap that becomes an accountability gap. If a wrong data point passes through five agents before generating a flawed decision, reconstructing who introduced the error requires manually analyzing heterogeneous systems, often with no common step identifier. The difference between an audit trail and data provenance is exactly this: the audit trail records actions, provenance reconstructs origins. For the logging side of the problem, see the audit of communications between agents.

Traceability and record-keeping: what changes with the AI Act

The EU AI Act introduces traceability and record-keeping obligations for high-risk AI systems, in particular the automatic logging of events across the system lifecycle. The traceability the regulation requires is the starting point, but it does not solve the attribution problem in multi-agent chains: recording that an event happened is not the same as proving who generated the data and that it was authentic at that moment.

This article does not reconstruct the regulation in detail: that is the job of the piece dedicated to AI Act certification and compliance obligations, which covers articles, certification levels, and the legal accountability chain. Here it is enough to fix one point: regulatory compliance is the minimum condition, source-level verifiable provenance is what makes it defensible.

How to certify data at the source inside multi-agent pipelines

Certifying data at the source means sealing every data point and output the exact moment it is produced, before it enters the chain, attaching a proof of integrity and origin that follows it through every subsequent step. That way attribution does not have to be reconstructed afterward: it is part of the data from the start.

Sealing at the moment of production

The principle is to move certification from the point of arrival to the point of origin. Instead of trying to reconstruct provenance after the error has propagated, you create proof the moment the data is born: a timestamp that fixes the instant, a hash that captures the exact content, and a reference to the agent or step that generated it. Organizations use TrueScreen to certify at the source the data their agents exchange, before an error propagates. The seal applied at the source turns every step of the chain into a documented link: not just "this data exists", but "this data was produced by this agent, at this instant, with this content, and has not been altered since".

Backward verifiability of every link

Backward verifiability is the direct consequence of sealing at the source. If every link carries its own proof of origin and integrity, reconstructing the provenance chain becomes a simple read operation, not a forensic investigation. You start from the disputed final output and trace back, link by link, to the original data point, distinguishing at every step what was authentically produced from what was manipulated or fabricated. This is the difference between enduring an opaque chain and governing a transparent one. AI output authenticity stops being a matter of trust and becomes a demonstrable property: backward verifiability is what turns a suspicion into proof, and proof into output with legal value.

What TrueScreen is and how it brings provenance into AI agent pipelines

TrueScreen is a Data Authenticity Platform that certifies data and outputs the exact moment they are produced, making every link in a multi-agent chain verifiable backward. TrueScreen certifies every data point and output the moment it is produced, applying the qualified seal of a third-party QTSP, so each link in the chain stays verifiable backward.

The methodology is forensic, not a simple seal applied after the fact: it covers acquisition of the data at the source, verification of its integrity and origin, and certification with a timestamp and qualified seal issued by a third-party QTSP compliant with eIDAS, which TrueScreen integrates via API. For every certified data point, the content hash, the timestamp, and the identity of the producing step are recorded, and a structured report is generated that reconstructs the context. The integration is built for pipelines: the TrueScreen API and SDK let you certify every critical step of the workflow programmatically, while the official MCP enables agent-to-agent interoperability with frameworks like LangChain, AutoGen, or CrewAI; the Web Portal serves verification and review.

In a finance pipeline, an extraction agent passes a value to an analysis agent, which passes it to an agent that generates a client report. With source-level sealing, when the final value is disputed you trace back to the agent and the instant that produced it, distinguishing the original data point from a manipulated or hallucinated one.

Practical cases of propagation and verification in multi-agent chains

The two scenarios below show how source-level provenance changes the outcome when something goes wrong: in the first, an agent decides on documents collected by another; in the second, a data pipeline is enriched by unverified AI sources.

In the first case, an underwriting agent approves an insurance claim based on documents collected and pre-analyzed by an intake agent. If one of the documents was inconsistent, for example a declared date that does not match a photo's metadata, and the inconsistency was not caught at the source, the approval rests on a flawed data point. With certification of the documents at the moment of acquisition, in a dispute the company produces the full chain and proves exactly what was received, when, and in what state.

In the second case, an analysis pipeline is fed by an agent that retrieves information from external, unverified AI sources. A hallucinated data point enters the flow and is treated as real by downstream agents, until it contaminates a decision report. Without provenance, the error is invisible until it causes harm; with source-level provenance, every external data point carries the marker of its uncertified origin, and downstream agents, or human reviewers, can treat it for what it is.

Provenance, audit trail, and logging compared

The three concepts are often confused, but they answer different questions. The table below clarifies what each one does and where it stops.

The key point: logging and audit trail describe system behavior, provenance reconstructs the history of the data. Only the third dimension, if certified at the source, holds up when a decision is challenged.