Agentic compliance runs on immutable evidence
Agentic compliance is the ability to prove, after the fact, that an AI agent did only what it was allowed to do. That proof has to be written at the moment the agent acts, and stored so that any later edit is detectable. A log that someone can quietly change is a story about what happened. An append-only, hash-chained record is evidence.
This post explains why ordinary logs fall short once agents take real actions, what immutable evidence is made of, and the questions to ask before you trust an agent platform with anything an auditor will care about.
The new audit question
When a person changes a record in a system, there is usually an obvious trail: a ticket, an approval, a name. When an agent does the same thing, the questions an auditor asks do not change, but the answers get harder to find:
What was requested, and by whom or what?
Which policy applied, and what did it decide: allow, block or send for review?
Who approved it, if approval was required?
What actually happened in the target system, in its own words?
Has this record changed since the day it was written?
The last question is the one most tooling cannot answer. Everything before it is a matter of recording more. Only the last is a matter of recording differently.
Why logs are not evidence
Application logs, traces and dashboards are built to help engineers debug. They are useful, and they are not designed to be relied on in an audit, for four reasons.
They describe state, not decisions. A log line says a call returned 200. It rarely says which policy allowed the call, or who signed off on it.
They are written around the action, not as part of it. If logging fails, the action still happens. The gap is invisible until someone needs the record.
They are mutable. Anyone with write access to the store can edit or delete a line, and nothing marks the change.
They are scattered. One agent run can touch five systems, each with its own partial record and its own retention rules.
None of this is negligence. Logs simply answer a different question.
What immutable evidence is made of
"Immutable" is a strong word, so it is worth being exact. A hash chain does not physically stop anyone from writing to a database. What it does is make any change detectable, which is the property an auditor needs.
It works in three steps:
Every action produces a record, written before the system reflects the result.
Each record contains a cryptographic hash (SHA-256) of the record before it.
To verify, you recompute the hashes from the start. If one record was altered, removed or reordered, every hash after it stops matching.
Because each record depends on all the ones before it, an edit cannot be hidden by changing one line. It would require rewriting the entire chain from that point, and the mismatch with any copy held elsewhere would show.
What a receipt should contain
Field | Why an auditor wants it |
The request | What the agent was asked to do, and the source of the request |
The policy decision | Allowed, blocked or sent for review, and which rule decided |
The approver | A named person, when a human had to say yes |
The raw response | What the target system actually returned, not a summary of it |
The previous hash | The link that makes the record tamper-evident |
A timestamp | When the record was written |
A record missing the policy decision or the raw response can still be useful to an engineer. It will not close an audit question.
Policy has to be readable
Evidence is only as good as the rule it proves was followed. If the rule lives inside a system prompt, a reviewer can read what the model was told, but not what it was constrained to do.
The stronger pattern is a policy that is an artifact in its own right: a plain list of conditions that decide allow, block or review, which a security reviewer can read, sign off on and change without touching code. Each receipt then points to the rule that applied, so the question "was this permitted?" has a stored answer. We make the broader case in why guardrails are the essential shield for AI agents.
Replay is the other half
Evidence you can only read is half useful. Evidence you can replay lets you re-run verification and walk the chain step by step to see precisely where a run went wrong, or to confirm that a fix prevents it from going wrong again.
For compliance work this changes the shape of audit preparation. Instead of reconstructing what happened in March from five systems and a chat thread, you hand over the chain for the March runs and let the reviewer verify it themselves.
Five questions to ask any agent platform
Use these in a vendor review. A clear answer to each is a good sign; a vague one is worth pressing on.
Is a record written before the action takes effect, or after?
Can a record be edited or deleted, and if so, would anyone know?
Does each record capture the policy decision and the approver, not just the call?
Is the raw response from the target system kept?
Can I verify the whole chain myself, without asking you to vouch for it?
Where Kentron fits
Kentron is built around this model. Every action an agent takes produces a tamper-evident, SHA-256 hash-chained receipt with the raw response attached and the approver named, and runs can be replayed. The aim is that the evidence exists on day one, instead of being assembled in a hurry when someone asks for it. To see what a receipt looks like, start at the Kentron AI home page.
FAQ
What is agentic compliance?
It is the practice of proving that AI agents acted within policy: what they were asked, what was allowed, who approved it and what happened. The proof is generated as the agent works, not reconstructed later.
What does "immutable evidence" mean for AI agents?
It means records that are append-only and chained together cryptographically, so any edit, deletion or reordering becomes detectable. It does not mean the storage is physically unwritable; it means tampering cannot go unnoticed.
Why aren't normal logs enough for an audit?
Logs usually describe system state rather than decisions, can be edited without a trace and are spread across several tools. They help engineers debug but do not prove that a rule was followed.
Does a hash chain replace access controls?
No. Access controls limit who can act and who can write. A hash chain adds a second property: if the record is changed anyway, the change shows. You want both.