The problem with a log
Almost every system writes a log. Almost none of those logs would survive an adversarial reading. The person who runs the system can edit it, and the person asking the question has to take the operator’s word that they did not. When the question is “did this agent move money after it was told to stop”, the operator’s word is not what a regulator, an insurer or a counterparty wants.
That is the standard KPATH sets for the Prove step of the Verify-Enforce-Stop-Prove test: a record a third party can check without trusting the party that produced it, including without trusting KPATH.
What KPATH records
Every call that passes through KPATH lands in the record, allowed or refused. So does every approval, captured as it happened, and every guardrail verdict. Stopping a chain writes a containment proof showing that nothing in the chain was authorised afterwards.
The record holds who acted and what was decided: agent identity, owner, risk tier, verified principal where one exists, target, action, decision, approval and outcome. It never holds a secret or a message body, because it is built from the request envelope. The record cannot leak what KPATH never saw.
What the auditor gets
| Property | What it gives the auditor |
|---|---|
| Tamper-evident | Any edit, deletion or insertion shows up |
| Authentic | The record was produced where the decision was made, not reconstructed later |
| Independently checkable | It verifies without KPATH’s say-so |
| Durable | Held on write-once storage, a retained record cannot be rewritten |
| Verifiable offline | A third party proves the record on their own machine, with no KPATH console |
Together these mean an auditor can establish that the record has not been altered without taking our word for it. That is the difference between a log and evidence.
Verifying without trusting KPATH
Verification is deliberately outside the product. A third party can take an exported record and satisfy themselves that every entry is authentic and that nothing has been added, altered or removed, on their own machine, without calling KPATH and without KPATH’s console. A third party can also generate a known sequence of calls, stops and approvals and confirm that the record reflects exactly that sequence.
KPATH’s own console is not the source of trust. If KPATH disappeared tomorrow, the exported record would still prove what happened.
Streaming to your SIEM
Evidence you cannot find is not much use either. Every record streams to your SIEM as it happens, so it lands where your auditors and your security operations team already read, ready for write-once retention.
Because the record contains no payload and no secrets, streaming it outside the enforcement boundary creates no new exposure.
Answering the auditor
Supervisors hold an agent that moves data or money to the same standard as the person who used to do the job. Their questions arrive in the same order every time.
| Question | What the record shows |
|---|---|
| Who is this agent? | The verified identity, its named owner and its risk tier on every call |
| What is it allowed to do? | The policy decision on every call, including refusals |
| What did it actually do? | Every call, approval and outcome, in order |
| How did you stop it? | The stop, and a containment proof that nothing was authorised afterwards |
Why it is built this way
An audit trail inside the agent, or inside the framework the agent runs on, is written by the thing under investigation. A log in a console the vendor controls is written by a party with an interest. KPATH sits outside the agent, records at the point the decision is enforced, and then hands you the means to check the record without KPATH. A log you control is not evidence. A record anyone can verify is.