Skip to main content
abadge is a small, explicit system. One Postgres database, one REST API, one local daemon for zero-knowledge crypto, and a thin set of clients.

​
System overview

​
Component map

​
Trust tiers

abadge has four explicit trust tiers, ordered from strongest to weakest. The trust model determines which capabilities are allowed:
  • Local agents (CLI, MCP) can read and use on any item.
  • Remote agents can only read on server-managed items. They can never access zero-knowledge items.
See Trust boundaries for the full breakdown of what each tier protects against.

​
The four-layer model

Every operation in abadge maps to one of four layers:
1

Store

Encrypt-at-rest with the storage mode chosen at item creation. Zero-knowledge items use client-side XChaCha20-Poly1305 with an Argon2id-derived KEK. Server-managed items use server-side AES-256-GCM with the Worker’s ENCRYPTION_KEY.
2

Permission

Explicit grants only. Every access requires a row in the permissions table linking (agent, item, capability). Permissions can carry an expiresAt. Remote-agent access is restricted at creation time.
3

Deliver

The capability determines the delivery mode. read returns the secret’s value — the encrypted blob for local + ZK items, or plaintext over HTTPS for server-managed items. use reserves a mount handle and returns data for local injection (delivery: env or delivery: file).
4

Audit

Every attempt — allowed, denied, expired, revoked, cascade — is appended to audit_logs. The table has no foreign-key constraints so entries survive entity deletion.

​
Tech stack

​
What abadge does not have

To keep the surface small and reviewable, abadge intentionally does not run:
  • background jobs, queues, or workflows
  • service-mesh sidecars
  • alternate auth systems
  • ORM bypasses
  • generic plugin systems
  • HSM integration (planned post-v1)