AI governance needs evidence of the data an agent used
Updated: Oct 19
An agent can produce a plausible answer without leaving enough evidence to establish whether it rests on the right data. BearingNode's Lab examines that gap—and what organisations can do about it.
In short: governing AI agents that use enterprise data requires evidence of which governed data an agent's actions used, how that was established, and whether the record survives long enough to matter. Policies, model monitoring and output logs do not supply this on their own. BearingNode has built and published a testable reference implementation using three open standards—MCP, OpenTelemetry and OpenLineage. On our own published scoring against eleven evidence requirements, it meets two and partially meets nine.
A successful answer is not necessarily a dependable answer
Imagine asking an AI agent for the average premium across your commercial insurance customers.
The agent retrieves two datasets, combines them and returns a number. The tool calls succeed. The calculation looks reasonable. Nothing on the monitoring dashboard suggests a problem.
But each retrieval returned only the first few thousand rows.
The arithmetic may be correct for the information supplied. The answer still does not describe the population you asked about.
Before that number informs a decision, can anyone establish which data supported it, whether the inputs were complete and what happened between retrieval and answer?
This illustrative scenario exposes a distinction we explored in *Three tracks, one audit question*: governing an AI system is not the same as having evidence of its interaction with data.
Policy states intent. Evidence shows what happened.
We are not alone in drawing that line. ISACA's *The AI Audit Trail: From AI Policy to AI Proof* argues that review boards and responsible-AI principles express intent but do not prove how a system behaved, and that a log of prompts and answers is a transcript, not an audit trail. It sets out four pillars of proof: who, or what, initiated the request, the data lineage behind it, the control state in force, and temporal integrity.
Our work addresses part of the second pillar—and shows why the first is harder than it looks.
Regulation points the same way. The EU AI Act requires high-risk AI systems to "technically allow for the automatic recording of events (logs)" (Article 12). A log that an agent called a tool is useful. It is not, by itself, evidence of which governed dataset the call read.
The problem crosses products—and responsibilities
Organisations rarely operate a single, self-contained technology estate.
An agent may run on one platform, call tools supplied by another organisation and access data held elsewhere. Monitoring, identity, platform audit and lineage may each sit in different systems, owned by different teams.
Each component can operate as designed whilst the organisation cannot reconstruct the complete interaction.
This is where BearingNode believes practical leadership is needed: not another isolated dashboard, but dependable connections between capabilities, records and responsibilities.
Our interest is not whether the software is proprietary or open source. We strongly support open standards in either case. Clients need technologies to work together without every connection becoming a bespoke dependency.
Standards help establish those connections. Testing establishes what they can actually support.
What BearingNode has built—and shared
Three open standards meet at the point where an agent touches data:
MCP (Model Context Protocol) is how an agent calls a tool—here, a tool that queries a database.
OpenTelemetry records execution: that the call happened, how long it took and whether it failed.
OpenLineage records data lineage: which datasets a piece of work read or wrote.
In the BearingNode Lab, we have built a reference implementation that produces an OpenTelemetry record and an OpenLineage record for each database statement an agent's tool runs, using a synthetic general-insurance dataset. By default, a failure to record is counted rather than allowed to block the call, so completeness is not guaranteed.
These are complementary records, not a conversion pipeline. The implementation produces them at the data-access point and connects them through explicit identifiers.
MCP is how the agent reaches the data. It is not, on its own, an audit trail.
We have also published the material needed to scrutinise the approach:
[Requirements](https://github.com/BearingNode/bearingnode-lab/blob/main/mcp-lineage/REQUIREMENTS.md): the questions the evidence should answer.
Reference implementation: a working design that others can inspect and exercise.
[Evidence matrix](https://github.com/BearingNode/bearingnode-lab/blob/main/mcp-lineage/evidence-matrix.md): the tests supporting our assessment, including partial results, each reproducible from a command.
[RAID register](https://github.com/BearingNode/bearingnode-lab/blob/main/mcp-lineage/Status/RAID.md): the risks, assumptions, issues and decisions behind the work.
Publishing code alone would not explain why we made particular choices or where the argument remains incomplete. Sharing the reasoning and evidence makes the contribution more useful—and more open to challenge.
The Lab is source-available reference work using synthetic data. It is not production software or a demonstration of organisation-wide coverage.
Where an agent's data access enters the Data & Information Observability framework. Core capabilities are claims you cannot make about an event you never collected.
What does a lineage record actually prove?
A lineage graph can look convincing without revealing how its relationships were established.
A producer might parse query text, inspect a database's resolved plan or observe execution. Those methods support different claims.
Our implementation parses SQL. It identifies datasets declared in the statement: parsed intent, not a complete observation of database access.
That qualification matters. A parser may identify a view without resolving its underlying tables, or miss behaviour hidden inside functions. Giving a dataset a consistent name does not remove those limits.
Nor does recording a caller's lineage reference establish the initiating person's identity or the authority under which an agent acted. In ISACA's terms, part of the data-lineage pillar can be addressed today; who or what initiated the request remains a stated gap.
For leadership, the question is therefore not simply "do we have lineage?"
It is: what evidence produced this record, and what conclusions can we reasonably draw from it?
Recording evidence is only the beginning
On BearingNode's own scoring, the implementation meets two of eleven requirements and partially meets nine within its stated scope. The remaining gaps are findings, not details to hide behind a successful demonstration.
Several have direct management implications.
Failure policy must be deliberate.
Should a data operation proceed if its evidence cannot be recorded? The implementation demonstrates fail-open and fail-closed options. The appropriate choice depends on the activity and its obligations.
Sampling protection is not retention.
Preventing a received trace from being sampled away does not establish that it remains available for the required period. Exempting it from sampling also has a cost: one governed call keeps its whole trace for as long as the trace store retains it.
A reference may point to missing evidence.
In one manual test, a lineage START record survived a process being killed, but its referenced execution span never arrived.
Evidence does not automatically establish fitness for use.
The demonstration does not tell a decision-maker whether an AI-produced number is sufficiently complete, current or appropriate to act on.
These are reasons to design the evidence chain carefully—not reasons to abandon useful AI applications.
Why we are contributing through open standards
Clients should not have to depend on one supplier's interpretation of what happened.
Open standards can help different systems exchange records and references. They do not, by themselves, guarantee completeness, authority or compliance.
Our approach is to build against existing standards, test the connections and bring specific findings back to the relevant communities. Where an existing mechanism is sufficient, we should use it. Where our original proposal proves unnecessary, we should change it—as we did on 17 October 2026, withdrawing a request to OpenTelemetry when the proposal it depended on was closed.
That is how we aim to strengthen industry practice: share something testable, expose its limits and help improve the common foundations.
The same principle guides our client work. Dependability comes from understanding how the whole arrangement behaves—including its failures—not simply selecting capable individual products.
What should leaders ask now?
Start with four questions:
Which agent–data interactions require evidence, and who owns the complete chain?
Does our lineage describe intended, planned or observed activity?
What happens when evidence is missing, and how is that detected?
Will the supporting records remain available when we need to reconstruct a decision?
A policy and a healthy dashboard are useful. Neither is the final assurance.
The stronger position is being able to explain what evidence exists, what it proves and where it stops.
Frequently asked questions
What is agentic data lineage? A record of which governed datasets an AI agent's actions read or wrote, captured where the data is accessed and linked to the record of the agent's execution. It answers "what data did this agent use?", not "how did the agent perform?".
Is MCP an audit trail? No. MCP is the protocol an agent uses to call tools. It provides a point at which evidence can be captured, but it does not itself record which datasets were read, on whose authority, or keep that record.
Are OpenTelemetry traces enough to show what data an agent used? Not on their own. Traces are designed for operational questions and are commonly sampled and retained for short periods. A lineage record kept alongside the trace, and linked to it, is better suited to the evidential question.
Does this establish who authorised the agent's action? No. Linking a call to its caller's lineage run is not authentication or delegated authority. That remains an open gap in the standards, and the Lab states it as one.
Is the BearingNode Lab production software? No. It is source-available reference work using synthetic data, scoped to SQL access to Postgres over MCP. It exists so that the approach can be inspected, reproduced and challenged.
Explore the work: BearingNode Lab — MCP lineage
Technical companion: Agentic data lineage: designing evidence controls across MCP, OpenTelemetry and OpenLineage
Reviewed against BearingNode Lab edition 2026.10.2, October 2026.
About the author: Daniel Rolles is CEO and Founder of BearingNode, and one of the key authors of BearingNode's Data and Information Observability Framework. He has spent over 30 years in data, analytics and AI, including leading EY's analytics practice for financial services, and is the author of the OpenLineage proposal on lineage for runtime actor-initiated data interactions referenced in this article.
