Do I still need AGLedger if I already have a SIEM and Object Lock?
A SIEM plus WORM or S3 Object Lock storage proves your logs were retained and not deleted. It does not prove they were authentic when written, does not say who or what authorized the action, and gives an outside auditor no way to verify any of it without trusting your infrastructure. Those are different guarantees: retention, authenticity, and attribution. AGLedger provides the second two and composes with the first — it does not replace your SIEM, it sits underneath it as the accountability layer. If your logs only ever need to satisfy you, a SIEM is enough. If they need to satisfy an auditor, a regulator, a customer, or a counterparty who has no reason to trust your admin, that is the gap AGLedger fills.
Retention · Authenticity · Attribution · Independent verifiability
Last updated: 2026-06-10 · API v1.0.0
The distinction
Different guarantees, different layers
| Guarantee | Question it answers | Who provides it |
|---|---|---|
| Retention | Were the logs kept and not deleted? | SIEM + WORM / Object Lock |
| Authenticity | Did the record really come from the claimed identity at the claimed time, and is it unaltered since — provably? | AGLedger (signed, hash-chained) |
| Attribution | Who or what performed this work, and on whose authority? | AGLedger (Ed25519-signed, principal named in the signed payload) |
| Independent verifiability | Can someone who distrusts our infrastructure confirm all of the above, offline? | AGLedger (offline verification against published keys) |
Credit where due
What a SIEM + Object Lock genuinely does well
Centralized collection and search across every system you run — the thing AGLedger explicitly does not try to be.
Immutability of bytes. S3 Object Lock in COMPLIANCE mode makes stored objects undeletable for their retention period, even by the account root. That is real and strong.
Retention enforcement that satisfies many regulatory “keep the logs for N months” duties on its own.
Alerting, correlation, dashboards — mature operational tooling AGLedger does not replicate.
If your requirement is “collect logs centrally, keep them, alert on them,” a SIEM plus Object Lock is the right tool, and you may not need anything else.
The gap
Where it falls short for AI-agent accountability
It is self-attested. The same operator who runs the SIEM controls what goes into it. Object Lock proves an object was not deleted; it says nothing about whether the object was authentic or complete when written. An auditor has to take your team's word that the log reflects what actually happened.
Its tamper-evidence reduces to self-attestation. Some SIEMs do hash their stores — but the hashes are computed and held by the same operator, so they prove only that the store agrees with itself. The protection underneath is IAM policy, retention configuration, and pipeline integrity all being correct and uncompromised: a misconfiguration or a sufficiently privileged insider can alter a record anywhere in the collection pipeline before it reaches WORM, and nothing in the stored object reveals it. AGLedger signs at the moment the work is reported, so the unsigned window shrinks from the whole pipeline to nothing, and any alteration after signing is mathematically detectable on verification — independent of how the storage is configured. A signature proves who reported what, and when, unaltered since; it does not prove the report's content was correct. That is the scope every notary has — and it is a scope no log store offers at all.
No offline, third-party verification. You cannot hand a regulator a SIEM export and say “verify this yourself, trusting nothing of ours.” AGLedger records verify against published Ed25519 keys — offline, with no account, no connection to AGLedger, and no AGLedger code required. See the verification page.
No cryptographic attribution. A SIEM log line says an action happened; it does not carry a signature naming the accountable principal — which human, agent, or service the work was performed under, provable after the fact.
No intent capture. A SIEM records what was emitted. AGLedger captures what an agent intended and the criteria for “done right” before the work completes — usable both as audit evidence and as durable memory the agent reads back after a context wipe.
No cross-organization verifiability. When agents act across company lines, a SIEM is internal to one party. AGLedger federation lets each side verify the other's signed records without sharing the business data behind them. See the federation page.
Side-by-side
What each layer provides
| Property | SIEM + WORM / Object Lock | AGLedger |
|---|---|---|
| Centralized log search and alerting | Yes — mature | No — not its job; Notify pushes signed events into yours |
| Bytes undeletable during retention window | Yes (Object Lock COMPLIANCE mode) | Partial — anchored checkpoints are undeletable; the records live in your PostgreSQL, where deletion or rewrite becomes detectable against the anchor |
| Record provably unaltered since written | Partial — bytes immutable in storage, but confirming they match what was reported requires trusting the account | Yes — hash-chained, cryptographically |
| Authentic when written | No — self-attested | Yes — signed the moment it happens, naming the accountable principal |
| Attribution (who performed, on whose authority) | No | Yes — Ed25519-signed |
| Auditor verifies without trusting you | No | Yes — offline, against published keys |
| Resists your own privileged operator | Partial — Object Lock resists deletion, not pre-write alteration | Yes, with external anchoring enabled |
| Captures intent before the action | No | Yes — durable intent |
| Cross-company verification | No | Yes — federation |
| Self-hosted, your keys and data | Varies | Yes |
Honest scope
When a SIEM alone is enough
The logs only ever need to satisfy your own operations or internal audit.
No external regulator, customer, or counterparty has to independently verify them.
The automated actions are low-stakes and reversible.
You are solving collection and alerting, not proof of authenticity.
In those cases, adding a cryptographic ledger is overhead you do not need. We would rather tell you that than oversell.
The other side
When you need AGLedger, with or alongside a SIEM
An auditor, regulator, or customer must verify your records without trusting your infrastructure. EU AI Act Article 12 logging and Article 19 retention, NIST AI RMF, and ISO/IEC 42001 evidence a skeptic can verify for themselves.
Agents take consequential or irreversible actions where “trust our admin” is not good enough.
Work crosses company or team boundaries and both sides need a shared, verifiable record of the handoff.
You need attribution — provable who or what performed an action and on whose authority — not just that something occurred.
Complement
They compose — keep your SIEM
AGLedger is designed to sit underneath your existing stack, not replace it.
Anchor AGLedger to the Object Lock bucket you already trust. With external anchoring enabled, AGLedger writes signed checkpoints into S3 Object Lock — so the immutability you have already invested in now backs a chain an auditor can independently verify, and a rewrite by your own operator can no longer reconcile with the anchor.
Feed your SIEM from AGLedger. Notify pushes signed record events into the SIEM, dashboards, or ticketing you already run — your existing alerting keeps working, now over authenticated events. See integrations for SIEM export.
Net: the SIEM stays your collection-and-alerting layer; AGLedger adds the authenticity-and-attribution layer the SIEM was never built to provide.
FAQ
Common questions
Isn't S3 Object Lock already tamper-proof?
Object Lock in COMPLIANCE mode makes a stored object undeletable for its retention period — strong immutability of bytes. It does not prove the object was authentic or complete when it was written, and it gives an outside party no way to verify the record's integrity without trusting your account. AGLedger adds cryptographic proof of integrity and attribution that travels with the record itself.
Can't I just sign my logs myself?
You can, and that is most of the idea — but doing it well means hash-chaining, key custody and rotation, offline verifiers, checkpoint anchoring against your own operators, and cross-organization verification. AGLedger is that layer built and maintained: the agent reports with its key, the engine signs what was reported the moment it happens and names the accountable principal inside the signed payload — not bolted on after the fact.
Does AGLedger replace my SIEM?
No. It is the accountability layer underneath your logging and observability. Keep the SIEM for collection, search, and alerting; AGLedger provides authenticity, attribution, and independent verifiability, and pushes its signed events into the SIEM you already run. The same boundary applies to observability and eval platforms.
Does the “even your own admin can't silently alter it” claim hold on a default install?
The signed hash chain makes any alteration detectable to a verifier who holds the public keys. To also defeat an operator who controls the database and the signing key, enable external anchoring: AGLedger writes signed checkpoints into an S3 Object Lock bucket (or an S3-compatible store with Object Lock, such as MinIO), and a rewrite can no longer reconcile with the immutable anchor. Anchoring is off by default because it needs a customer-supplied Object Lock bucket — ideally in a separately administered account, since an anchor the same admin can delete is not an anchor.
We only need retention for compliance — isn't that just storage?
For pure retention duties, WORM storage may satisfy the letter of the rule. AGLedger matters when the value of the evidence depends on it being unforgeable and independently verifiable — the bar EU AI Act Article 12 logging and Article 19 retention evidence is held to when an auditor asks.
Related
The category definition — integrity, attribution, and independent verifiability as a discipline.
The offline check — genuine signatures, unbroken chain, no account, no AGLedger code required.
The same complement-not-replace boundary, drawn against LangSmith, Langfuse, Arize, and OpenTelemetry.
Cross-organization signed accountability — what no single-tenant log store reaches across.
Key custody, threat model, and where anchoring fits in the protection layers.
Article-by-article mapping, including the Article 12 logging and Article 19 retention rows.
The architectural reason logs and unsigned audit trails are not interchangeable with a signed record chain.