← Blog
2026-04-07Security

We Published Our Security Whitepaper

By Michael Cooper · Founder

AGLedger’s security architecture is now public. 18 sections, no gating, no “request access” form. If you’re evaluating AGLedger for enterprise deployment, this is the document your security team will want to read.

We wrote this for the people who actually make security decisions, not marketing. It covers trust boundaries, cryptographic design choices, what we store, what we don’t, what crosses federation boundaries, and what happens when things go wrong.

Why publish this now

Accountability infrastructure lives in the critical path of every automated operation it records. If you’re evaluating whether to put AGLedger between your agents and your audit trail, you need to understand exactly what it does at the security level, not just what the marketing page says.

We believe accountability systems should not require blind trust. That principle applies to our security posture too.

Recent peer-reviewed work validates this architectural approach. The Nitro system — “Rethinking Tamper-Evident Logging: A High-Performance, Co-Designed Auditing System,” ACM CCS 2025 — reports 10x–25x throughput gains in high-stress conditions with near-zero data loss, against a comparison set whose existing tamper-evident logging systems the authors describe as suffering “severe data loss in high-load settings.” Co-designing cryptographic verification with the logging path — rather than retrofitting it — is what makes that gap possible.

What the whitepaper covers

The document is organized into 18 sections. Here are the highlights:

Self-hosted by design

AGLedger runs in your VPC. With federation opt-ins disabled, the application makes zero outbound network connections. No telemetry, no phone-home, no external data stores. Your data stays in the PostgreSQL instance you provision.

Three-layer cryptographic architecture

Customer-facing (HMAC-SHA256, Argon2id), instance-to-instance ( RFC 9421 HTTP Message Signatures + Ed25519), and data-at-rest (SHA-256 hash chain + Ed25519 signatures + AES-256-GCM). Every algorithm maps to a published standard. No bespoke constructions.

Tamper-evident audit chain

Every state change produces a hash-chained, Ed25519-signed Signed Statement — a tagged COSE_Sign1 envelope (RFC 9052) over an in-toto v1 Statement payload, deterministically CBOR-encoded per RFC 8949 §4.2.1 (as of API v0.23.0). Enforcement at four layers: database triggers (REVOKE UPDATE, DELETE), application-level transactional writes, cryptographic hash chain, and operational checkpoints with optional external anchoring to S3-compatible storage.

Zero content inspection

AGLedger records accountability metadata — who notarized what, who delivered, who accepted. It never inspects, stores, or processes your business data, prompts, or model outputs. In encrypted mode, the server stores only the encrypted envelope and an evidence hash. The customer holds the key.

Post-quantum readiness

All cryptographic artifacts record algorithm identifiers. The signing key registry supports unlimited rotation. When NIST’s post-quantum standards (ML-KEM, ML-DSA, SLH-DSA) mature in ecosystem tooling, AGLedger can migrate forward without breaking historical verification or re-signing existing entries.

What the whitepaper does not claim

We are explicit about scope. The threat model section enumerates what AGLedger protects against and what is explicitly out of scope:

The shared responsibility model section (Section 13) draws a clear line between what AGLedger delivers and what the customer must implement.

Security fixes are always free

One point worth highlighting: security patches are distributed regardless of support contract status. If a vulnerability affects your deployment, you get the fix. We don’t gate security behind a renewal. This aligns with CISA’s Secure by Design principle that customer security outcomes are the vendor’s responsibility, not a paid add-on.

Read the full document

The complete whitepaper is at agledger.ai/security. No registration required. If you have questions or find something that needs clarification, reach out at [email protected].

Sources & further reading