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
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.
The rest of the gap is what the table below makes explicit: no offline third-party verification, no cryptographic attribution of who acted, no capture of intent before the work, and no cross-organization proof. AGLedger records verify against published Ed25519 keys offline, with no account and no AGLedger code (verification), and federation lets each side verify the other's signed records without sharing the business data behind them (federation).
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 - signed 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
What a tamper-evident, attributable, offline-verifiable trail for agent work captures in practice.
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.