Security Architecture

AGLedger is change control for automated work: it gives every change a signed, tamper-evident record - what was intended, on whose authority, what happened, and who accepted it - deployed in your infrastructure and under your control. Under the hood it is a cryptographic notary, signing records, completions, and verdicts into a tamper-evident audit vault. This document is written for the security teams, compliance officers, and procurement decision-makers who must satisfy themselves that the evidence is sound before the product is bought.

1. The signed record - what the signature covers

The most precise claim on this site lives here, so it is stated plainly. The agent reports with its key; the notary signs what it reported.The agent (or any caller) makes the API call that records a stage of the work. The Server - not the caller - assembles the entry, encodes it, and signs it with the instance vault key. The authority being recorded is the principal’s; the signature is the notary’s.

Because the attribution rides inside the signed payload, an attacker cannot re-point an entry at a different principal without invalidating the signature. The accountable principal (principal_agent_id - always an agent identity) and the acting credential are part of what the Ed25519 signature commits to. The protected header carries the actor identity as a CWT private claim ({ key_id, role, owner_id }); any delegation context rides in the in-toto Statement predicate ason_behalf_of. Both are covered by the signature.

Agents are not required to hold signing keys. The default path needs no client-side cryptography from the agent at all - it authenticates and reports, and the notary does the signing. There is an optional, opt-in per-request attestation path (X-Agent-Signature /X-Agent-Signature-Content-Hash), a no-op by default, in which a cert-bound caller co-signs its own request; that co-signature is carried into the COSE_Sign1 envelope aspredicate.on_behalf_of.agent_signatureand is honored only when the caller authenticated with an ephemeral cert. Use it when you want caller-attested provenance on top of notary attribution; ignore it otherwise.

One key per Server instance - never per principal, never per agent. Across orgs, each Server signs its own portion with its own per-instance key.

2. Three readers of the same record

The same signed record is read later by three different parties, with three different trust postures. The cryptography is “wasted” on the first reader and indispensable to the last - which is exactly why an agent-recovery record is already an audit-grade record.

The remainder of this document is written to the auditor’s posture: every claim is something a third party can confirm against the published keys, with no AGLedger account and no network call. Offline verification has its own canonical page - see Verification.

3. Deployment model and trust boundaries

AGLedger is software you deploy, not a service you send data to.

One role: Server. Every install is the same binary - same surface area, same configuration shape. A Server is a sovereign domain: its own database, auth, agents, contracts, signing key, and chain. Whether the deployment participates in federation is a per-record / per-contract / global flag, not a deployment mode.

We do: Record accountability metadata in your infrastructure. We do not:Host your data, proxy your traffic, judge your work, or require outbound connectivity unless a record’s share flag is set.

Where the Server, database, and key material map to the box you actually run - topology, sizing, ownership, and the air-gapped install - is documented on the Deployment page. This section states only the trust boundary.

4. Data classification - zero content inspection

What AGLedger does not store or inspect

All data resides in the PostgreSQL instance you provision. No external data stores, no phone-home. AGLedger collects no usage data or other data from the software and operates no service that receives data from your deployment.

5. Data lifecycle

AGLedger does not impose data retention policies - the customer controls retention as the database operator.

The audit vault is cryptographically append-only by design. This creates a deliberate tension with deletion regulations (GDPR Article 17, CCPA). AGLedger’s position: Signed Statements contain accountability metadata - not business data. Record criteria and completion evidence are stored in separate tables that can be archived or purged.

In encrypted mode, the server stores only the encrypted envelope and an evidence hash. Destroying the encryption key renders content irrecoverable while preserving vault chain integrity - cryptographic erasure.

6. Cryptographic architecture

7. Audit vault integrity - what the envelope holds

The audit vault is AGLedger’s core security primitive - a cryptographically signed, append-only ledger of every accountability event. Each entry surfaces to customers as a Signed Statement: a tagged COSE_Sign1 envelope (RFC 9052, tag 18) over an in-toto v1 Statement payload, deterministically CBOR-encoded per RFC 8949 §4.2.1. The accountable principal and acting credential are named inside that payload, so the Ed25519 signature covers the attribution - not just the event.

Identity and chain-linkage live in the signed protected header; delegation context (on_behalf_of) lives in the in-toto predicate. Both are inside the bytes the signature commits to, so neither can be altered without the signature failing.

Enforcement layers

Confirming all of this offline - signatures genuine, chain unbroken, payload undrifted - is the dedicated subject of the Verification page, including export formats and the failing-case transcript. AGLedger publishes the vault signing keys at two unauthenticated endpoints so any party can do it with no account and no connection to us:

Both active and retired keys are returned, enabling full historical chain verification across rotations. Accountability systems should not require blind trust.

8. Key management and rotation

The vault signing key is the trust root of the chain, so its handling is explicit. It is supplied to the Server asVAULT_SIGNING_KEY- required in production, and customer-held: AGLedger LLC never possesses it. The customer protects the private key with their own secrets manager (see the shared-responsibility model, §15).

Zero-downtime rotation

Key loss does not invalidate history.Verification uses the public key recorded in the database, not the private key from the environment. Losing the private key stops you signing new entries; it does not retroactively break the existing chain. The registry supports unlimited rotation, and a post-quantum key (for example ML-DSA) can be activated alongside Ed25519 - see §17.

9. Authentication and access control

Two authentication paths, same protocol on the wire. Enterprise installs lead with OIDC-bound ephemeral signing certificates - agents exchange a JWT from the customer’s own identity provider (Auth0, Okta, Azure AD, Keycloak, GCP WIF, K8s SA tokens) for a short-lived (≤10 min) AGLedger cert via POST /v1/auth/oidc/cert and present it as the Bearer credential. No agent holds a long-lived key; blast radius on credential compromise is ten minutes.

Long-lived API keys remain fully supported for development, the quickstart, and single-operator installs. Keys are never stored in plaintext - the server computes HMAC-SHA256 and looks up the resulting hash. Both credential types produce the same chain envelope, and the actor identity each carries is named inside the signed payload (§1, §7); verifiers see who acted either way.

Trust anchors are configured per-org via POST /v1/admin/trusted-issuers - one row per IdP per purpose with an applies_to discriminator (agent / principal / admin / any). JWKS endpoints are auto-discovered via OIDC well-known. See the Authentication guide for the full exchange flow and IdP recipes.

10. Federation and privacy boundary

Across organizations, federation is peer-to-peer signed-message transport. Each Server signs its own portion with its own per-instance key; there is no shared key and no central coordinator.

Each Server remains sovereign. It records the signed bytes a peer sent and verifies them against the peer’s published public key. It never holds the peer’s underlying business data, and there is no central coordinator that does either. Cross-org transport mechanics live on the Federation page.

11. Application security

12. Infrastructure hardening

13. Threat model

Explicitly out of scope

14. Compliance mapping

AGLedger captures signed records, delegation chains, and cross-org evidence transport regardless of regulation; as a downstream effect these map cleanly to the obligations below. Detailed crosswalks for each framework live on their dedicated pages.

15. Privacy, data protection, and shared responsibility

AGLedger is self-hosted software. In the typical deployment, AGLedger LLC is neither a data processor nor a data controller - we provide software the customer operates in their own infrastructure.

16. Continuity, assurance, and releases

Business continuity

Security assurance

Release and update process

17. Algorithm agility and post-quantum readiness

All algorithms are current NIST-approved. NIST finalized post-quantum standards in August 2024 (ML-KEM / FIPS 203, ML-DSA / FIPS 204, SLH-DSA / FIPS 205).

Hybrid (classical + PQC) signatures expected 2027–2028. AGLedger’s architecture requires no customer action today.

18. Incident response

If vault integrity verification detects tampering, the failure is logged with full context (chain position, expected vs. actual hash, signing key ID). Failed entries are flagged but never modified - the evidence of tampering is itself part of the audit record.