Logs Are Not Lineage: The Accountability Layer AI Agents Are Missing

TL;DR for operators

The paper argues that trustworthy AI agents need more than accurate final answers. Once an agent can retrieve documents, call APIs, write memory, modify databases, send messages, or coordinate with other agents, trust depends on whether the organisation can reconstruct how the output or action happened.

The useful mechanism is:

raw trace → typed provenance relation → trust function → operational control

A raw trace says: the agent retrieved a document, called a tool, used a memory, then produced an answer. Provenance says something stronger: this passage supported that claim; this tool output contradicted that memory; this untrusted webpage influenced that email recipient; this failed API call invalidated the next planned action. That difference matters. Logs tell you what happened. Provenance tells you what depended on what. Small distinction. Large lawsuit-shaped shadow.

For businesses, the paper is most relevant when agents touch high-impact workflows: customer operations, finance, legal review, healthcare administration, internal knowledge systems, compliance workflows, code execution, CRM updates, procurement, HR, and any tool chain where a model can create external consequences. The paper does not prove that provenance systems produce a specific return on investment. It does, however, make a strong case that without evidence tracing and execution provenance, enterprise agents will be difficult to debug, audit, secure, or recover.

The practical takeaway is not “store everything”. That is how observability becomes a privacy incident wearing a dashboard. The takeaway is to store the right relationships: source, transformation, support, contradiction, dependency, update, invalidation, trigger, and downstream use.

A correct answer can still be an unsafe execution

Imagine an AI operations assistant preparing a supplier-payment memo. It retrieves a contract, checks an invoice through an accounting API, consults prior memory about preferred vendors, and produces a clean answer: “Approved for payment.”

The answer may even be correct.

That does not mean the execution was trustworthy.

Perhaps the agent called the wrong vendor API first, exposing invoice details it did not need to expose. Perhaps the payment amount came from a tool output, while the justification came from an old memory summary created three months ago. Perhaps a retrieved email contained a hidden instruction that influenced the bank-account field. Perhaps the final memo cited the contract, while the actual payment recommendation depended on an unverified spreadsheet. The board sees a plausible answer. The system has a small provenance swamp underneath it.

This is the problem addressed by Wang et al. in From Agent Traces to Trust: Evidence Tracing and Execution Provenance in LLM Agents.¹ The paper is a survey, but not the decorative kind that politely collects papers into categories and then leaves everyone where they started. Its argument is sharper: LLM agents are becoming execution systems, and execution systems need provenance.

The misconception the paper corrects is common and commercially convenient. Many teams assume that agent trust can be solved with better model accuracy, nicer citations, generic logging, or a safety classifier bolted somewhere around the prompt. That was already thin for retrieval-augmented generation. It becomes inadequate for agents.

A generated answer can cite a document without the document supporting the specific claim. A tool call can be legitimate in general but unsafe with the wrong argument source. A memory can be useful yesterday and stale today. A multi-agent workflow can fail because one agent introduced a bad assumption and another agent repeated it with confidence, as if confidence were evidence. It is not. It is merely typography with posture.

The paper’s contribution is to bring these problems under one lens: evidence tracing and execution provenance.

The mechanism: traces become trust only when relationships are typed

The paper distinguishes ordinary traces from provenance. This distinction carries most of the business value.

A trace is a recorded sequence of events: prompt, retrieval query, retrieved document, tool call, tool output, memory read, memory write, final answer. Useful, certainly. But a flat trace mostly answers “what happened next?” That is not enough when the operator needs to know “what caused this?”, “what supported this?”, “what contradicted this?”, or “what should be rolled back?”

Provenance adds typed relationships among the trace elements. In the paper’s taxonomy, those relationships include:

This is the article’s central mechanism:

A raw trace is a diary. A provenance graph is a dependency map.

The difference is not academic neatness. In business systems, diagnosis depends on dependency. If a compliance agent produces an unsupported statement, the operator needs to know whether the failure came from bad retrieval, bad summarisation, stale memory, an unreliable tool output, a missing policy, or a downstream synthesis step. “The model hallucinated” is not a diagnosis. It is a shrug with a GPU bill.

The paper’s taxonomy is therefore best read as an infrastructure map. It asks five practical questions:

1. Where do trace artefacts come from? Reasoning, retrieval, tools, memory, environment interaction, or other agents.
2. What units should be recorded? Evidence units such as documents, passages, observations, policies, memory items, tool outputs, and claims; execution units such as tool calls, parameters, memory operations, actions, and messages.
3. How are those units related? Through support, contradiction, dependency, derivation, update, invalidation, and triggering.
4. At what granularity and timing should tracing happen? Run-level, step-level, tool-call-level, parameter-level, claim-level, or span-level; before execution, during execution, after execution, or continuously.
5. What trust function does the trace serve? Verification, attribution, debugging, safety enforcement, audit, or recovery.

The important point is not that every agent needs maximal tracing. That would be expensive, invasive, and magnificently annoying. The paper is clearer than that. Granularity should follow risk. A low-impact FAQ bot may only need answer-level evidence checks and post-hoc review. A financial, medical, legal, or enterprise tool-using agent may need runtime checks at the tool-argument level. A persistent personalisation agent may need continuous memory provenance.

In other words, provenance is not one setting. It is a risk design.

The paper contributes a wiring diagram, not another leaderboard

This paper does not introduce a new model, benchmark score, ablation table, or dramatic “we beat baseline X by Y%” claim. Good. Not every useful AI paper needs to arrive wearing a leaderboard sash.

Its main contribution is a unified taxonomy and review across research areas that are usually discussed separately:

• retrieval grounding and citation support;
• claim-level attribution;
• tool-use safety;
• prompt-injection and information-flow control;
• runtime guardrails;
• long-term memory;
• agent observability;
• trace-based debugging;
• multi-agent failure analysis;
• benchmark and metric design.

The paper’s point is that these are not separate islands. They are all fragments of the same systems problem: how evidence, tools, memory, messages, observations, claims, and actions jointly shape an agent’s behaviour.

That unification matters because businesses rarely deploy the academic components separately. A practical enterprise agent may retrieve policy documents, summarise them, write a memory, call a CRM tool, send an email draft, and coordinate with another specialist agent. It does not care that the literature separates RAG evaluation, tool-use safety, memory poisoning, and observability. The deployed system combines them anyway. Reality has poor respect for conference taxonomy.

The paper’s framing is useful because it moves the trust question from:

“Was the final answer correct?”

to:

“Can we trace the evidence and execution chain that produced the answer or action?”

That is the shift from output evaluation to process accountability.

The figures and tables are maps, not empirical proof

Because this is a survey, its figures and tables should be interpreted as conceptual and comparative artefacts. They are not experiments, ablations, or robustness tests. This matters because readers sometimes mistake a dense taxonomy table for evidence that a field is mature. A colourful heatmap can look official. So can a restaurant menu. Neither guarantees dinner.

The paper is careful on this point by implication, though business readers should make it explicit: the evidence is a structured review of the field, not a controlled demonstration. Its value is architectural and diagnostic. It tells operators what a trustworthy agent system must be able to represent, not that a finished enterprise-grade provenance stack now exists on a shelf, gently glowing and waiting for procurement.

Tool-use safety is where provenance becomes operational

The strongest practical part of the paper concerns tool-using agents.

A tool call is not just a model output. It is a bridge into another system. It may query a database, send an email, update a calendar, execute code, move money, change a ticket status, or expose private data. That turns “AI safety” from content moderation into execution governance.

The paper’s tool-use discussion makes a clean distinction: tool permission is not enough. A tool may be allowed, while a specific argument is unsafe.

A customer-support agent may be allowed to draft emails. That does not mean it should copy a recipient address from an untrusted webpage. A procurement agent may be allowed to update vendor records. That does not mean it should accept a vendor bank-account change from an unauthenticated attachment. A code agent may be allowed to run tests. That does not mean it should execute commands injected through a README file.

The problem is influence.

The paper connects this to indirect prompt injection, information-flow control, semantic taint tracking, runtime enforcement, argument provenance, and execution boundaries. These threads all point to the same operational principle:

Sensitive actions should depend only on trusted sources, authorised intent, and verified intermediate values.

That principle sounds obvious. Implementing it is not. LLMs can paraphrase, summarise, infer, and transform information. Unsafe influence may not appear as copied text. It may pass through an agent’s reasoning, a memory update, a tool output summary, or another agent’s message. String matching will miss much of this. A hidden instruction does not need to survive as a sentence if it survives as a decision.

This is why the paper’s mechanism-first view matters. A provenance-aware system should ask:

• Which source produced this tool argument?
• Was that source trusted for this purpose?
• Did user intent authorise this action?
• Did any untrusted external content influence a privileged field?
• Did the action update external state?
• If the action was wrong, which downstream states, memories, or decisions now need repair?

That is not “logging”. That is runtime control.

Memory turns yesterday’s context into tomorrow’s liability

The paper’s section on memory is especially important for commercial agents because memory is often sold as personalisation, continuity, and convenience. It is all three. It is also a persistence mechanism for errors.

A memory item may originate from a user statement, a retrieved document, a tool output, an observation, a reflection, a previous failure, or another agent’s message. It may then be summarised, merged, retrieved, and reused later. Each transformation creates a provenance question.

Where did this memory come from? When was it written? Was it derived from evidence or from an unsupported model inference? Is it still valid? Has newer evidence contradicted it? Did it influence a tool call? Should it be invalidated or quarantined?

Most memory systems, as mapped in the paper, focus on recall, update, personalisation, and long-term coherence. Those are useful capability metrics. They are not enough for accountable deployment. A memory that helps the agent remember may still be stale, poisoned, private, overgeneralised, or unsupported.

The business interpretation is uncomfortable but necessary: memory should not be treated as a trusted context reservoir. It should be treated as evidence with lineage.

That changes implementation priorities. Instead of storing “user prefers vendor X”, a provenance-aware memory system should ideally store something closer to:

The paper also connects memory provenance to security. Persistent memory can be poisoned or injected through ordinary interactions or external content. If contaminated content is written into memory, the attack survives beyond the original session. That makes memory poisoning a provenance problem, not merely a prompt-filtering problem.

For businesses, this is where provenance becomes governance. A privacy-sensitive memory cannot simply be useful. It must be inspectable, permissioned, minimised, and revocable.

Citations are not provenance; they are only one relation

A useful correction in the paper is that citation support is only one slice of the problem.

In RAG systems, teams often treat citations as a trust badge. The model retrieved documents, the answer has source links, the UI looks responsible. Wonderful. Now check whether the cited source actually supports the claim. Then check whether the claim was based on that source rather than an unverified memory, another retrieved passage, or a tool output. The citation may be topically relevant but substantively useless. A citation can be decorative. This is why academia invented footnotes and then immediately invented bad footnotes.

The paper places citation and attribution work inside a wider provenance framework. In agent systems, support can come from many sources:

• a retrieved document;
• a database query;
• a tool output;
• a user instruction;
• a policy;
• an environment observation;
• a memory item;
• an inter-agent message;
• an intermediate claim.

The same final answer may contain multiple claims with different provenance statuses. One claim may be supported, another inferred, another contradicted, and another unsupported. Answer-level correctness hides that variation. Claim-level provenance exposes it.

This matters for business review. A legal, medical, financial, or compliance workflow rarely fails only because the entire answer is wrong. It often fails because one operationally significant claim is unsupported, outdated, or overextended. The unsupported sentence is not always the loudest sentence. It is just the one that later becomes expensive.

Benchmarks still grade parts of the elephant

The paper’s benchmark discussion is useful precisely because it is unsatisfying. Existing benchmark families cover pieces of provenance, but not the full chain.

RAG benchmarks evaluate grounding, citation support, faithfulness, and hallucination. Tool-use benchmarks evaluate API selection, argument generation, task success, prompt injection, and risky actions. Memory benchmarks evaluate recall, personalisation, updating, and long-horizon consistency. Multi-agent benchmarks evaluate coordination and failure types. Trace-debugging systems evaluate failure localisation.

Each family is useful. None gives strong end-to-end coverage across evidence labels, tool calls, memory operations, multi-agent communication, safety attacks, provenance relations, and recovery.

The paper’s heatmap is best read as a field diagnostic: the evaluation ecosystem is still component-centric. That creates a gap for businesses. You may have a good RAG score, a useful tool-use benchmark result, and a promising memory demo, while still lacking evidence that your deployed agent can explain, audit, and repair a real execution chain.

The metrics the paper organises are more useful than a single success score:

The missing piece is recovery. Many systems can detect that something went wrong. Fewer can use provenance to repair the execution: invalidate stale memory, quarantine contaminated evidence, retry with corrected parameters, ask for approval, roll back an unsafe state change, or replay from a safe checkpoint.

Detection is useful. Recovery is where operations breathe again.

What the paper directly shows, and what Cognaptus infers for business use

The paper directly shows that the research landscape is fragmented and that provenance provides a unifying abstraction across evidence attribution, tool safety, memory auditing, agent observability, debugging, evaluation, and recovery. It also provides a taxonomy for thinking about what should be traced, how it should be represented, and what trust functions it should serve.

Cognaptus infers a business architecture pattern from that framework: agent provenance should become a first-class infrastructure layer, especially for tool-using and memory-bearing enterprise agents.

That inference is not the same as a proven ROI claim. The paper does not show that implementing provenance reduces incidents by a specific percentage or lowers compliance costs by a certain amount. It does not benchmark competing provenance stacks. It does not offer a production migration plan. It is a conceptual survey.

Still, the operational path is clear enough to matter.

This is the sober business message: provenance is not mainly a reporting layer. It is a control layer.

A practical provenance stack starts with decisions, not data hoarding

The paper does not prescribe a product architecture, but it suggests a sensible implementation sequence.

First, define the high-impact actions. These are tool calls or outputs that can change external state, expose private data, commit money, affect customers, modify records, or create compliance exposure. Do not start by tracing everything. Start where the blast radius lives.

Second, define the provenance units. For a customer-support agent, this might include user requests, policy passages, CRM records, tool calls, generated claims, draft replies, approval decisions, and memory updates. For a finance agent, it might include invoices, vendor records, approval policies, API responses, payment instructions, spreadsheet values, and exception notes.

Third, define relation types. At minimum: support, depend-on, derive, contradict, invalidate, update, and trigger. The exact vocabulary can be adapted, but the system needs typed links. Otherwise the trace remains a transcript with ambitions.

Fourth, set tracing granularity by risk:

Fifth, use provenance for runtime gates. Sensitive tool calls should not only ask “is this tool permitted?” but also “where did these arguments come from?” A database update derived from verified user input is different from one derived from scraped external content. Same tool. Different provenance. Different risk.

Sixth, build recovery. If a memory item is found stale or poisoned, the system should identify downstream answers, actions, and memories that depended on it. If a tool output is later invalidated, the system should know which claims and decisions used it. This is the difference between incident response and ritual panic.

The privacy problem: provenance can become the new data leak

The paper rightly identifies privacy and governance as open problems. This should not be treated as a footnote.

Provenance traces can contain user data, confidential documents, credentials, API arguments, tool outputs, memory items, internal reasoning artefacts, and operational metadata. A provenance system that records everything without minimisation, access control, retention rules, anonymisation, encryption, and selective disclosure may become more dangerous than the agent it monitors.

This is the governance paradox: the infrastructure built to make agents accountable can itself become an accountability problem.

The practical boundary is therefore clear. Businesses should not equate provenance with maximal surveillance. They need purpose-limited tracing. Sensitive fields should be redacted or tokenised where possible. Access to traces should be role-based. Retention should differ by workflow risk. Audit views should reveal enough to inspect decisions without casually exposing private context to every person with dashboard access.

The paper does not solve this. It flags it. That is the correct level of ambition for a survey.

Where this applies, and where it does not

The strongest application is not every chatbot. It is agents with tools, memory, persistence, external data, policy constraints, or multi-step workflows.

The business case is strongest when at least one of these is true:

• the agent can change external state;
• the agent can access private or regulated data;
• the agent writes or retrieves long-term memory;
• the agent uses untrusted external content;
• the agent participates in multi-agent workflows;
• the organisation must audit decisions after the fact;
• failures require targeted repair rather than simple retry.

The case is weaker for short-lived, low-risk, read-only assistants where final-answer quality and basic source checking may be enough. Provenance still helps, but the cost may not justify fine-grained instrumentation.

The uncertainty boundary is also important. The paper synthesises a research field. It does not show production scalability, storage economics, annotation reliability, developer ergonomics, or measurable incident reduction in a specific enterprise deployment. Those questions remain open. Anyone selling “full agent provenance” as a solved procurement item is probably doing what enterprise software has always done best: converting research gaps into pricing tiers.

The strategic takeaway: trust follows lineage

The paper’s most useful idea is that agent trust should be understood as lineage.

Where did the evidence come from? How was it transformed? Which claim did it support? Which tool call did it influence? Which memory did it update? Which action depended on it? What contradicted it? What invalidated it? What must be repaired?

These questions are not decorative governance. They are the operational grammar of reliable agents.

The industry has spent plenty of energy making agents more capable. That was necessary. It was also the easy part to demo. The harder part is making agent behaviour inspectable, enforceable, and recoverable after it leaves the comfort of a chat window and starts touching systems that matter.

Final-answer accuracy asks whether the destination looks right. Provenance asks whether the route was defensible.

For enterprise AI, that is the difference between automation and accountability. And accountability, unlike a benchmark score, has a habit of showing up in meetings with legal.

Cognaptus: Automate the Present, Incubate the Future.