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.

What the whitepaper covers

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

Self-hosted by design

AGLedger runs in your VPC. In Standalone mode, 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 + 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 vault

Every state change produces a hash-chained, Ed25519-signed vault entry. 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 committed 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:

Compromised principals — if the entity creating mandates is malicious, AGLedger faithfully records their mandates. We record accountability, not intent.
Content-level threats — AGLedger validates structure (JSON Schema, tolerance bounds), not business content.
Infrastructure compromise — in the self-hosted model, OS, network, and physical security are the customer’s responsibility.

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.

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 security@agledger.ai.

We Published Our Security Whitepaper