Most AI observability tools store your agent's logs and assure you they're intact. That assurance is a promise, not evidence. The difference matters the moment a regulator, a customer, or a court asks you to prove what your agent did — and trusting the vendor's word is exactly the trust an audit is meant to remove.
When a SaaS observability platform holds your traces, the integrity of those traces rests on one assumption: that the platform — and everyone with privileged access to it — neither altered them nor could be compelled to. You cannot check that assumption. You take it on faith. For day-to-day debugging that is fine. For an audit, it is the whole problem.
An auditor's job is to verify facts without relying on the audited party's honesty. If the only thing standing between the log and a quiet edit is "the vendor says so," the log is not independent evidence. It is hearsay with good uptime.
| Claim | What it actually means |
|---|---|
| Vendor attestation | "We promise we didn't change your logs." Rests on trusting the vendor. Not independently checkable. |
| Tamper-evidence | "Any change to the log is detectable." Rests on cryptography, not trust. Checkable by anyone. |
| Independent verification | "You can confirm integrity yourself, offline, without the vendor's systems or cooperation." The property that actually survives an adversarial review. |
The first is the industry default. The third is what compliance actually needs. Tamper-evidence is the mechanism; independent verification is the property it buys you.
A log is independently verifiable when a third party can confirm its integrity using only:
No call to the vendor's API. No login to the vendor's dashboard. No "trust us." SteelSpine signs each event with HMAC-SHA256, chains events by hash, and seals the chain with an Ed25519 signature. The public key is published; the verification is a few lines of standard-library code. An auditor verifies offline:
steelspine pack-verify decision_0042.spine.tgz
# → VERIFIED ✓ (or TAMPERED ! if a single byte changed)If they prefer not to install anything, they run a ~20-line Python snippet against the published public key. Either way, the verdict comes from math they control, not from us.
The right test of a log's integrity claim is: can someone who distrusts you confirm it without your help? If the answer needs your cooperation, it isn't verification — it's a request for trust.
Independent verification of a tamper-evident chain proves no one altered the log after capture without the signing key. It does not, by itself, prove the operator who holds that key could not have produced a different log in the first place. That is non-repudiation against the operator, and it is a key-custody problem — solved with hardware security modules, a KMS, or third-party timestamping, not with a logging format. The classical cryptography here (HMAC-SHA256 + Ed25519) is also not quantum-resistant.
We draw that line in the open because the value of verification is that it survives scrutiny. A claim that quietly overreaches gets caught by the first competent reviewer, and then the genuine, defensible claim gets thrown out with it. The defensible claim is strong enough on its own: detectable tampering plus offline, vendor-independent verification is a property that almost no agent observability tool offers today.
If the honest answers are "no, you have to trust us," you have attestation, not evidence.
Download a sample signed run and confirm its integrity yourself, offline, with the published public key. Then flip one byte and watch verification fail. The free tier produces the same signed records for your own agents, locally.
Start free See the verification model →