From “Trust the AI” to Verifiable Agent Execution
An ActionBoard.ai White Paper on Execution Provenance, Tool Receipts, Evidence Chains, Authorization, Verification, Auditability, and Proof-Oriented Agent Architecture
Abstract
Generative AI introduced a familiar trust problem:
Is this answer true?
Agentic AI introduces a more consequential question:
Did this action actually happen?
An AI agent may state:
“The payment was processed.”
“The report was sent.”
“The production environment was updated.”
“The database was checked.”
“The policy requirement was satisfied.”
Each statement sounds like a normal language-model output.
But in an execution system, these are claims about external reality.
Recent research shows that agent hallucination can occur throughout multi-step execution trajectories. AgentHallu evaluates 693 agent trajectories and finds that even strong systems struggle to locate the step responsible for hallucination; tool-use hallucinations are particularly difficult to identify.
Research is therefore moving beyond final-answer evaluation toward execution provenance. A 2026 survey frames provenance as a typed graph connecting retrieved evidence, tool outputs, memory, observations, intermediate claims, actions and final answers.
Other work proposes tool receipts, proof-carrying agent actions and provenance graphs that allow actions to be verified through runtime evidence rather than relying solely on the agent’s narrative.
This paper uses the term Evidence-Carrying Agent as an ActionBoard architectural framing for this broader emerging direction.
An Evidence-Carrying Agent does not merely produce an action.
It produces enough structured evidence to answer:
What goal justified the action?
Which evidence supported it?
Which agent proposed it?
Who authorized it?
Which tool executed it?
What did the environment return?
How do we know the stated outcome occurred?
The central thesis is:
Trustworthy agentic AI should progressively move from model assertions toward independently verifiable execution evidence.
1. Narrative Trust
Consider a chatbot that says:
“Your request has been completed.”
A human may believe it.
But what does that sentence prove?
Nothing.
The model generated a sequence of words.
It may accurately describe reality.
It may misunderstand a tool output.
It may incorrectly infer success.
It may hallucinate an action that never occurred.
This is:
Narrative Trust
We trust the agent because its explanation sounds credible.
Agentic systems need something stronger.
2. Execution Trust
Suppose instead the system shows:
Action
Report sent.
Tool
Enterprise mail service.
Recipient
Authorized address.
Execution ID
X7842.
Tool Result
Accepted.
Timestamp
Recorded.
Human Approval
H-193.
Source Document
Report v4.2.
This is a different category of evidence.
The language model does not need to convince us that the action occurred.
The execution environment proves it.
3. Tool Hallucination
Tool-using agents are vulnerable to several forms of hallucination.
An agent may:
claim a tool was called when it was not;
misreport the result;
confuse observation and inference;
state that an update succeeded without checking.
AgentHallu’s 2026 evaluation shows how difficult step-level hallucination attribution remains and reports especially weak localization performance for tool-use hallucinations.
Practical Hallucination Detection for AI Agents focuses specifically on agents that fabricate tool execution or misstate tool results and proposes tool receipts as a practical verification mechanism.
This leads to a simple rule:
If a tool can produce the evidence of execution, prefer the tool’s evidence over the model’s description.
4. Evidence Versus Explanation
These should be treated separately.
Explanation
Why the agent says it acted.
Evidence
What demonstrates the action occurred.
An explanation can help humans understand.
Evidence helps humans verify.
A trustworthy system needs both.
5. The Execution Provenance Graph
Recent research on execution provenance formalizes agent trajectories as connected structures containing:
retrieval;
evidence;
memory;
tools;
observations;
claims;
actions;
outputs.
This maps naturally onto ActionBoard’s Action Graph.
ActionBoard describes each goal as connected to queried sources, agent actions, timestamps and compliance information.
The graph can therefore become more than memory.
It can become an evidence structure.
6. Evidence-Carrying Action
We propose the following conceptual object:
ECA — Evidence-Carrying Action
ECA = {G, I, E, A, P, T, X, O, V}
Where:
G = Goal
I = Intent
E = Evidence
A = Agent
P = Permission
T = Tool
X = Execution record
O = Outcome
V = Verification
The action is no longer simply:
send_email()
It is a structured operation with context and evidence.
7. Goal
Every consequential action should trace back to a goal.
ActionBoard’s current Action Graph documentation states that nodes are goal-linked and that orphaned actions are not intended to exist in the formation.
This creates the first provenance question:
Why did this action exist?
Without a goal, actions become difficult to justify.
8. Intent
The goal may be broad.
The action needs explicit intent.
Example:
Goal
Prepare monthly programme reporting.
Action
Send report.
Intent
Deliver approved report to donor reporting contact.
This allows reviewers to determine whether the action remained aligned with the original objective.
Research on intent-to-execution integrity argues that securing agents requires maintaining correctness from natural-language intent through concrete tool operation.
9. Evidence
Before acting, the system should know:
Which information supports this action?
Example:
Claim: Invoice is overdue.
Evidence:
invoice record;
payment database;
contract terms.
The agent should not simply say:
“I believe the invoice is overdue.”
The evidence should be connected.
10. Permission
Even correct evidence does not create authority.
The action must carry:
who authorized it;
what scope applies;
whether authorization remains valid.
This is where Evidence-Carrying Agents connect directly to Governed Autonomy.
A technically correct action can still be unauthorized.
11. Tool Identity
The evidence package should record:
which tool executed;
which version;
which endpoint;
which agent invoked it.
This becomes especially important in heterogeneous agent ecosystems.
An action performed through the wrong system may produce an apparently correct result with inappropriate data access.
12. Tool Receipt
A receipt is a machine-generated confirmation of an operation.
Examples include:
API response;
transaction identifier;
database mutation count;
deployment hash;
message ID;
file checksum;
test result.
The strongest receipt is generated by the system where the external change occurred.
This creates:
Environmental Evidence
rather than:
Model-Generated Evidence.
13. Proof-Carrying Agent Actions
A 2026 research paper explicitly proposes Proof-Carrying Agent Actions, organized around action certificates, approval receipts and replay-ready proof.
The overlap with the Evidence-Carrying Agent concept is important and should be acknowledged.
The ActionBoard framing is broader:
the agent and its Action Graph maintain evidence across the full trajectory,
while PCAA formalizes portable proof structures around actions.
The concepts are complementary rather than interchangeable.
14. Pre-Execution Evidence
Evidence is useful before the action happens.
Before Red Lion executes, Yellow Lion could evaluate:
Does the goal justify the action?
Is the evidence sufficient?
Is the agent authorized?
Is the tool allowed?
Is the resource in scope?
If not:
BLOCK
or
REVIEW.
This prevents unsupported actions from reaching the environment.
15. Post-Execution Evidence
After execution:
Did the expected change occur?
For example:
Agent request:
Add user to approved group.
Tool response:
200 OK.
But does 200 necessarily mean the user is now a member?
The system can perform a verification read:
Retrieve group membership.
The result provides stronger evidence.
This is:
Outcome Closure.
16. Action Closure
A reliable action should not finish at:
Request sent.
It should finish at:
Expected state verified.
Therefore:
Requested
≠
Executed
≠
Verified
These are separate states.
17. The Verification Ladder
Evidence strength can be represented as:
Level 0
Agent assertion.
“I did it.”
Level 1
Tool call generated.
Level 2
Tool accepted call.
Level 3
Tool returned success result.
Level 4
External state independently verified.
Level 5
Evidence signed/attested where required.
The appropriate level depends on risk.
18. Evidence Quality
Not all evidence has equal reliability.
A useful model could score evidence using:
Source Reliability
Where did it come from?
Directness
Does it directly demonstrate the claim?
Freshness
Is it current?
Integrity
Has it changed?
Independence
Was it generated by a different system than the claimant?
This creates an:
Evidence Confidence Score
for consequential actions.
19. Provenance-Bearing Memory
Long-term memory should also retain provenance.
Suppose ActionBoard remembers:
Supplier X is high risk.
Why?
A trustworthy memory item should link to:
three previous delays;
a compliance review;
the dates involved.
Execution-provenance research explicitly includes memory lineage as part of the broader accountability problem.
Therefore:
Memory without provenance can become institutional rumor.
20. Hallucination Localization
If an agentic workflow fails, the system needs to answer:
Where did reality diverge from the agent’s internal story?
Possible locations:
goal interpretation;
retrieval;
reasoning;
delegation;
tool parameter;
tool response interpretation;
final synthesis.
AgentHallu demonstrates that automatically identifying that origin remains difficult.
A detailed Action Graph may make localization easier because each stage is explicitly recorded.
21. Trajectory-Level Auditing
Recent industrial-workflow research argues that evaluating only final output can miss hallucinations originating in intermediate Thought–Action–Observation trajectories.
This is critical.
A workflow can produce the correct final answer for the wrong reason.
That may be acceptable in trivia.
It is not acceptable in regulated execution.
22. The Audit Trail as a Product of Execution
Most software creates logs.
An evidence-oriented agent should create:
Audit Artifacts
automatically.
For every consequential operation:
goal;
evidence;
authority;
tool;
result;
verification.
ActionBoard currently describes audit-ready execution traces as a structural output of the Action Graph.
This could become an important enterprise differentiator if independently demonstrated.
23. Evidence-Carrying Handoffs
Evidence should travel between agents.
If Green Lion gives Blue Lion a fact, Blue should receive:
the fact;
the source;
confidence;
time validity.
Not simply:
“Green says this is true.”
This reduces provenance loss during multi-agent coordination.
24. Evidence-Carrying Delegation
Likewise:
Black Lion → Red Lion
should not be:
“Deploy this.”
It should be:
Goal
Production update.
Artifact
Build 493.
Verification
Tests passed.
Security
Yellow approved.
Human Authority
Approval ID H-838.
Rollback
Defined.
Target
Production environment A.
Red Lion then receives both the request and the evidence required to justify execution.
25. Evidence-Carrying Decisions
The same principle applies before action.
Suppose an agent recommends:
Reject this supplier.
The decision package should contain:
policy requirement;
supplier data;
missing condition;
risk classification;
confidence;
human decision where required.
For high-impact decisions, the AI recommendation should remain distinguishable from the human authority responsible for the final outcome.
26. Evidence Should Be Minimal
Evidence architecture introduces a new privacy risk.
If every action carries every piece of context, the proof package can become a data leak.
Therefore Evidence-Carrying Agents need:
Minimum Necessary Evidence.
Only information required to justify and verify the action should travel with it.
This is similar to least-privilege access.
But applied to proof.
27. Evidence Expiration
Some evidence is time-sensitive.
Example:
Security scan passed yesterday.
That may not justify deployment next month.
Evidence packages should therefore carry:
timestamp;
validity period;
source version.
Old evidence may remain useful historically.
But should not necessarily authorize current execution.
28. Evidence and Human Oversight
Evidence improves human approval.
Instead of presenting:
“Approve this action?”
ActionBoard can present:
Goal
Proposed Action
Why
Evidence
Risk
Previous authorization
Expected result
Then:
Approve
Modify
Reject
Human approval becomes informed rather than symbolic.
29. The Evidence View
A future ActionBoard enterprise interface could allow an auditor to click:
WHY?
for any action.
The system returns:
Goal
Evidence
Decision
Agent
Permission
Tool
Result
Verification
This is substantially more useful than raw logs.
30. Evidence-Carrying Agent Benchmark
ActionBoard could compare:
System A
Agent final answer only.
System B
Agent + standard logs.
System C
Agent + tool receipts.
System D
ActionBoard + structured execution provenance.
Run workflows containing:
successful actions;
silent failures;
tool hallucinations;
incorrect parameters;
stale evidence;
authorization violations.
31. Key Metrics
Evidence Coverage
Verified claims / consequential claims
Provenance Completeness
Actions with complete source-to-outcome chain / actions
Execution Truth Rate
Correct claims about external action state / all action-state claims
Verification Depth
Average level on the verification ladder
Failure Localization Accuracy
Correctly identified failure origin / failures
Audit Reconstruction Time
Time required for an independent reviewer to reconstruct what happened
That final metric would be particularly useful for enterprise adoption.
32. Evidence-Carrying Agents and the UN
The UN ethical AI principles emphasize:
transparency;
explainability;
responsibility;
accountability;
human oversight.
Evidence-carrying execution provides one technical route for operationalizing these principles.
Instead of saying:
“The AI was transparent,”
the system demonstrates:
what influenced the action;
what authority existed;
what happened.
33. What This Does Not Solve
Evidence does not guarantee that:
the original goal was ethical;
the policy was fair;
the human approval was wise;
the evidence source was unbiased.
Evidence makes the process more inspectable.
It does not automatically make the process correct.
That distinction is important.
34. From Explainable AI to Verifiable AI Operations
Explainable AI asks:
Why did the model produce this result?
Agentic systems add:
What did the system actually do?
Therefore enterprise AI needs both:
Explanation
and
Verification.
The first concerns reasoning.
The second concerns reality.
35. The Larger ActionBoard Thesis
The first generation of AI asked organizations to trust outputs.
The second generation should increasingly allow organizations to inspect execution.
ActionBoard’s Action Graph creates a possible foundation for this transition because goals, sources, decisions and actions already exist as connected execution objects in the platform’s public architecture.
The opportunity is to make those objects evidence-bearing.
Conclusion
Agentic AI creates a fundamental shift in the meaning of trust.
When AI generates text, we ask:
Is the answer correct?
When AI acts, we must also ask:
Did the system do what it claims?
Was it authorized?
Which evidence justified it?
What changed in the external environment?
Can another person verify the result?
Recent research on agent provenance, hallucination localization, tool receipts and proof-carrying actions shows that these questions are becoming central to reliable agent systems.
ActionBoard can build on this direction through the combination of:
Voltron roles;
Action Graph;
Consent Ledger;
security gating;
execution traceability;
long-term memory.
The research proposition is:
Every consequential agent action should carry enough structured evidence for another system—or another human—to determine why it was allowed, what occurred, and whether the claimed outcome is real.
That changes the trust model from:
“Believe the agent.”
to:
“Verify the execution.”
And that may become one of the defining architectural requirements of enterprise agentic AI.
Selected References — White Paper 08
- Wang, Y., et al. From Agent Traces to Trust: Evidence Tracing and Execution Provenance in LLM Agents. 2026.
- Liu, X., et al. AgentHallu: Benchmarking Automated Hallucination Attribution of LLM-Based Agents. 2026.
- Basu, A. Tool Receipts, Not Zero-Knowledge Proofs: Practical Hallucination Detection for AI Agents. 2026.
- Wang, Z. Proof-Carrying Agent Actions: Model-Agnostic Runtime Governance for Heterogeneous Agent Systems. 2026.
- Agent-Sentry. Bounding LLM Agents via Execution Provenance. 2026.
- Badave, H., et al. Beyond Final Answers: Auditing Trajectory-Level Hallucinations in Multi-Agent Industrial Workflows. 2026.
- Securing LLM Agents Need Intent-to-Execution Integrity. 2026.
- UN CEB. Principles for the Ethical Use of AI in the UN System.
- ActionBoard.ai. Action Graph, Consent Ledger, Voltron formation and execution-