Logs are not evidence
There is a category difference between telemetry and evidence, and it becomes obvious the first time an outcome is challenged. Telemetry is what you keep to debug your own systems. Evidence is what a party who was not present, and who has no particular reason to take your word for anything, will accept as an account of what happened.
Application logs fail that test on three counts. They are written by one party, they are mutable by whoever operates the system, and they record what your software believed rather than what the counterparty agreed. When an agent-negotiated result is disputed months later, “the model decided” is not a defence, and neither is a log line you could have edited.
Supervisors are converging on the same expectation. Financial regulators consistently emphasise auditability, operational resilience and demonstrable human oversight of AI-enabled processes. The unstated premise in all of it is that a record exists which is independent of the party relying on it.
What the record must capture
An exchange between two organisations' agents is only reconstructable later if the record captures the decision, not just the payload:
| Element | Why it is needed |
|---|---|
| Both attested identities | Which verified legal entities were party to this, rather than which hostnames connected. |
| The agent, distinctly | Attribution to a specific agent, so one can be revoked without deprovisioning a whole account. |
| Declared purpose and scope | What the exchange was for, so proportionality can be assessed after the fact. |
| The policy decision | Which rule permitted this, and what minimisation or redaction was applied at the boundary. |
| Data class, not necessarily payload | Enough to prove which category of information moved, without being obliged to retain the content. |
| Delegating authority | The consent token or standing authority the request was made under, where the workflow requires one. |
| Ordering and time | A sealed sequence, so a later entry cannot be presented as an earlier one. |
The element most often missing is the fourth. Systems routinely record what was sent and received but not why it was allowed — which is exactly the question a supervisor asks first.
Tamper-evidence, not just retention
Write-once storage and long retention periods are necessary and insufficient. The property that actually matters is tamper-evidence: any alteration to a past entry must be detectable by someone who does not trust the operator.
Immutable storage means you promise not to change the record. Tamper-evidence means nobody has to take that promise on faith, because entries are hash-chained and signed — altering one invalidates everything after it, verifiably, by a third party.
This is why MCPLayer seals each exchange rather than merely storing it. The ledger is replayable and independently checkable, so its evidentiary value does not rest on trusting the platform that produced it.
The two-sided problem
Inside one company a single audit system is authoritative, because there is one owner. Across an organisational boundary there are two, and both must be able to produce consistent, cross-referenceable records of the same delegation and its scope. When each side keeps its own log, the predictable outcome of a dispute is two plausible and mutually contradictory accounts, with no way to adjudicate between them.
Cross-organisational log interoperability is an acknowledged open problem, and no standard has yet achieved broad adoption. A shared trust plane sidesteps the reconciliation entirely: both parties are recorded against the same sealed entry at the moment of exchange, so there is one account rather than two competing ones.
Replay and dispute resolution
The practical output is an evidence bundle. For a given transaction reference: exactly what was asked, by which attested organisation, under what authority, which policy permitted it, what was returned, and what the counterparty's agent asserted at the time.
That bundle turns a dispute from an argument about system behaviour into a matter of record. It is also, in the fraud context, what inverts the economics — making verification cheap enough to do on every case rather than a sample. That argument is developed on why agent attestation pays.
Retention and minimisation
A tempting reading of all this is “keep everything forever”. That is the wrong conclusion, and in regulated contexts an actively dangerous one: a comprehensive archive of sensitive payloads is a liability that compounds over time.
The separation that resolves it is between the record of the exchange and the content of the exchange. Sensitive data classes can be configured for zero-retention, where the attestation, the policy decision and the outcome are sealed to the ledger while the payload itself is never persisted. You retain provable evidence that a permitted exchange occurred, without retaining the material that made it sensitive. Details on the security posture page.
Do AI agents legally need an audit trail?
It depends on jurisdiction and sector, and this is not legal advice. What is consistent across supervisors is that existing obligations already reach agent behaviour: if a process required auditability when a human performed it, delegating it to an agent does not remove the requirement. Australian entities should read this alongside APRA CPS 230 and AI agents.
Is a blockchain required for this?
No. What is required is tamper-evidence and independent verifiability, which hash-chaining and signing provide without a distributed consensus mechanism. Whether entries are additionally anchored externally is an implementation detail, not the property that makes the record credible.
How long are records kept?
Ledger entries are retained per the policy agreed with your organisation, which should align with the record-keeping obligations of your sector. Payload retention is configured separately and can be set to zero for nominated data classes.