When an AI agent acts, what should you be able to prove?

Imagine an AI agent proposes a payment.

Before the payment proceeds, your organisation needs to know whether it meets policy, whether the agent has the authority to propose it, and whether a person needs to approve it.

Six months later, someone may ask why the payment was made.

At that point, a general statement about your AI governance process will not answer the question. Neither will a test showing that the agent usually behaves as expected. You need the evidence behind this particular decision.

Which policy applied? What information was considered? What did the checks return? Who approved the outcome?

These are practical questions. A useful governance system should make them easier to answer.

Start with the action

An AI agent can perform many kinds of work. It might retrieve information, update a customer record, approve an expense or initiate a payment.

The consequences differ. Reading a public document is different from transferring money. Your controls should reflect that difference.

For an important action, there should be a clear point at which the proposed action is checked against policy. The result might allow it to proceed, require a human review or indicate that it should stop.

That check also creates an opportunity to record what supported the decision.

If you preserve the proposed action, the policy used, the result and the recorded responsibility together, a later reviewer has somewhere concrete to begin. If those details remain scattered across logs, messages and documents, someone will have to assemble them afterwards.

The purpose of a Decision Receipt is to preserve that connection.

Testing an agent does not explain every later decision

Testing matters. You should understand how an agent behaves before giving it consequential work.

But an agent’s behaviour can change when you change the information it receives. That includes its instructions, the examples it retrieves and the policy text it is asked to follow.

Our research on public UK procurement records illustrates this.

In one experiment, an AI agent and a policy engine assessed the same 283 decisions. The policy engine returned 144 allows and 139 denials. The agent returned seven allows, 276 requests for review and no denials.

That difference does not establish that the policy engine was right. Changing one overly strict rule substantially increased agreement. The wording of the policy was part of the problem.

In a second experiment, we gave an agent progressively more information. Its behaviour did not change steadily as the context increased. Showing it previous decisions prompted a sharp increase in denials. Adding the full policy text then caused it to withdraw some of those denials.

In a third experiment, two models produced similar patterns of reasoning but differed substantially in their willingness to reach a verdict.

These studies used public procurement records. They are research previews with stated limitations, and they have not been peer-reviewed. They do not establish how every model will behave in every workflow.

They do illustrate a practical concern: an explanation that sounds consistent does not necessarily produce a consistent decision.

A test performed before a change cannot fully describe behaviour after that change. Recording important assessments lets you examine the policy, information and result used in the actual workflow.

What MeshQu does at that point

Suppose an agent proposes a payment that exceeds a policy threshold.

Your application sends the proposed action and relevant information to MeshQu. MeshQu assesses that information against the selected policy and returns a result.

Your application then acts on the result. It might proceed, stop or send the payment for human review.

When the assessment is recorded, MeshQu creates a signed Decision Receipt connecting the result to the policy version and information used.

The responsibilities are straightforward:

1. MeshQu assesses the proposed action against policy.
2. Your application controls what happens next.
3. The receipt preserves the recorded assessment for later inspection.

This distinction matters. If MeshQu returns a denial and your application makes the payment anyway, the receipt still records the denial. It does not establish that the application obeyed it.

To account for the whole event, you also need evidence of what happened after the assessment.

The integration guide (opens in a new tab) explains how applications can connect policy results to their controls.

Decide which assessments need a lasting record

A policy check and a recorded assessment serve different purposes.

A routine evaluation can return a result without retaining a decision record. A recorded assessment preserves the information and result and produces a signed receipt.

Your workflow should make that choice deliberately.

For consequential actions, consider what another person may reasonably need to inspect later. A production change, sensitive data export or payment approval may warrant a lasting record even when the policy check passes.

Human review also needs to be captured. If an assessment calls for review and someone subsequently approves the action, the reviewer’s decision and reasons should be recorded alongside the supporting assessment.

The earlier policy result and the later human judgement answer different questions. Both may be necessary to explain the final outcome.

A recorded name needs a basis

Knowing who or what was responsible is part of accountability. But recording a name does not, by itself, establish that the name is accurate or that the named party had authority.

For an API integration that supplies an actor identifier, the calling application is responsible for supplying reliable identity information. The receipt can preserve that identifier without independently establishing who was behind it.

Authority is another question again.

A system may correctly identify an agent while still giving it permissions it should not have. A person may be correctly identified while lacking the authority to approve a particular exception.

Your identity and permission controls therefore remain important. A decision record helps preserve their relevant outputs; it does not make those controls unnecessary.

The actor-attribution documentation (opens in a new tab) describes the API’s treatment of identity and the fields included in integrity checks.

Be precise about what proof means

A signed receipt supports specific checks. With the appropriate verification material and trusted keys, another party can check the signature and whether the signed content has changed. Policy replay can also check the assessment against the recorded policy and information.

Those are valuable properties. They give a reviewer a way to examine the record independently.

They do not establish that every input was true, that the policy was well designed or that the final decision was correct.

The same applies to an agent’s explanation. Preserving its rationale records what it said. Assessing whether that rationale is sound requires further examination.

Good governance needs both a reliable record and people capable of questioning what it contains.

Make the later question easier to answer

Someone reviewing a decision months later was probably not present when it happened. They may not know the agent, the application or the people involved.

They should still be able to follow the evidence.

The aim is to show what was proposed, which policy was applied, what the assessment returned and how the final decision followed. Where the evidence is incomplete, that should be visible too.

That is a practical standard for accountable AI: important decisions should leave a record that another person can inspect and question.

Start with one consequential action. Define the policy check, establish who controls the outcome, and preserve the evidence needed to explain it later.