Ambry
In progressSecrets your agents can manage but never see.
About Ambry
Ambry exists because agents decrypting a vault in a shell printed its values into their transcripts, and a redaction pipe is not a control. So the rule it is built around is that an agent never holds a credential that can return plaintext at all. Its MCP server has no reveal tool, and the server refuses an agent token on reveal and inject whichever client sends it. An agent that needs a secret used triggers a pipeline, and a runner holding a token scoped to one namespace injects the value into the step.
Each version of each secret is sealed under its own key with XChaCha20-Poly1305, bound to its namespace, path and version, and every key is wrapped by a key-encryption key that lives in one file on the host and never enters the database or a backup. Every write and every open is recorded in the same transaction as the change, on a chain MACed under that key, and nightly backups are restored and checked before they are sealed to a key kept offline.
It is a C++ server on libsodium and Postgres, with a command-line client, an MCP server for agents, a web dashboard where values stay masked until a person clicks, and an Ansible lookup that deploys read by name. Ansible + systemd, no Docker.
What it is not, named here rather than implied: it is not offered for download or as a service. It runs on Spergs' own private network, and its mobile app, KEK rotation and finer reveal permissions are not built yet.
At a glance
- Agents list, create, rotate and request — and can never reveal
- Deploy runners inject, scoped to one namespace each
- A per-value key under one host-held KEK, libsodium only
- Every open audited in the same transaction, on a MACed chain
- Backups restored and verified before they are sealed
- Values masked in the dashboard until a person clicks
More from Spergs
Other independent software we ship, or are working on.