Govern · QuoxVault beta
Grant secrets. Never hand them over.
QuoxVault is a password manager built for AI agents instead of people: it stores your organisation's real secrets and grants agents short-lived, scoped leases to use them, never the secrets themselves, with every access recorded on a tamper-evident chain.
It storesAPI keys·email accounts·web logins·SSH keys·TLS certificates·database credentials·generic secrets
Watch a secret get leasedIn plain words
What it is, where it lives, when to reach for it
- What is it
- A credential store inside QuoxCORE that holds the API keys and passwords your agents use.
- Where do I use it
- On the dashboard's Vault pages, and through the
quox vaultcommands in your terminal. - When would I use it
- Every time an agent or integration needs a secret you do not want pasted into code.
- How do I use it
- Run
quox vault createand follow the prompts, thenquox vault test <id>to prove it connects.
QuoxCORE is the free, self-hosted platform underneath this. What is QuoxCORE
The vault console
Watch a secret get leased.
The whole product in one loop. An agent asks for a credential, the vault issues a short-lived lease bound to that agent, the secret is used server-side, and the lease revokes itself. Every step, including every refusal, lands on the WARD chain below. Grant or deny the next request yourself.
illustrative demo · sample data · the clock runs at 8× speed
stored credentials · typed · envelope-encrypted
values are masked here and sealed at rest · they never leave this panel
requests & leases
incoming request
Agent CIPHER requests stripe-prod
Granted, not handed over. The agent receives the lease, never the secret. The vault resolves the value server-side at the moment of use, and an expired lease resolves to nothing.
What it stores
Seven kinds of secret, all typed.
A secret is not just a string. Each credential kind carries shape validation and its own release policy, and the secret is used server-side, so it never reaches the agent at all.
service_api
API keys and tokens, resolved through the key waterfall at call time: bring your own key, organisation, instance, environment.
web_login
email_account
IMAP read and SMTP send, released server-side. Agents work the mailbox without ever holding the password.
ssh_key
A server-side executor uses the private key in memory only. Host keys are pinned on first use, and a changed host key hard-fails before any command runs.
tls_cert
X.509 parsing with expiry and metadata, no external dependencies.
database
A query executor that runs read-only by default, inside a read-only transaction unless you explicitly allow writes. The password is resolved server-side.
generic
Envelope-encrypted storage for any secret that does not fit a shape yet.
Leases
Leased, not handed over.
You watched it above: CIPHER used stripe-prod and never saw a single character of the key. That is the entire design.
- Short-lived. Every lease carries an expiry, checked at release time in a single fail-closed query. A background job sweeps expired leases every 30 seconds.
- Scoped and agent-bound. One lease covers one credential for one agent. A request from the wrong agent is a structural miss in the query, not a comparison that can drift.
- Use-budgeted. Set a maximum number of uses and the count is consumed atomically. The sixth use of a five-use lease is refused.
- Human-approved. A lease request lands in the approval inbox, so a person grants the access before any agent touches the secret.
the old way
agent.env
STRIPE_KEY=<the real key, in plain text>
held forever
copied anywhere
no record of use
Hand an agent the secret and you have lost custody of it.
the vault way
lease lse_01j8k2
scope read-only · uses 3
expires 90 s · agent-bound
resolved server-side
revokes itself
witnessed on the chain
Grant a lease and custody never leaves the vault.
The audit trail
Every access recorded.
Each release, grant, revocation and refusal is written to the audit trail and witnessed on the WARD chain, an append-only hash chain where every entry binds the hash of the one before it.
- Tamper-evident by construction. Rewrite any entry and
verifyChainreports the break at the exact block. - Denials are evidence too. A refused request appends a block just like a grant does. You saw RELAY refused in the console above, and the chain kept it.
- Readable by an auditor. The chain exports with the rest of the evidence surface, alongside AEE, AOCL and VOLT.
anatomy of a block
Encryption
One envelope per secret.
Every credential gets its own data key, the data key is wrapped by the organisation KEK, and the result seals into an authenticated AES-256-GCM block. Watch the seal close.
the secret
plaintext · 9f3a c21b…Plaintext exists only in memory, at the moment of use. Never at rest, never in a log.
DEK · per credential
One data key for each secret. Compromise of one envelope stays one envelope.
org KEK · versioned
An HKDF-derived key-encryption key, carrying a version so rotation is traceable. It wraps the DEK, never the data.
AES-256-GCM block
9f3a c21b 44e0 8d17 a2c9…sealing…
Authenticated ciphertext. A single flipped bit in data or wrapped key fails loudly on decrypt.
Rotation is a re-wrap.
Rotating the master key re-wraps each credential's data key. The ciphertext itself is never touched, and a dual-key window keeps the previous key valid during the roll.
Coverage by construction.
Every encrypted store is registered in one place, and the test suite fails if a new ciphertext column ships unregistered. Rotation cannot silently miss a table.
Unsealed only at the moment of use.
A secret is decrypted server-side, inside the release path, under the lease check. Plaintext exists in memory for the moment of use and nowhere else, never at rest and never in a log.
The actual console
The same console, running for real.
Not a mock-up of the demo above: credential health, connectors and encryption status, in the QuoxVault console itself. In beta.
- 1See the encryption at a glanceAn AES-256-GCM badge sits right beside the QuoxVault name, not buried in settings.
- 2Read health status as one rowTotal, healthy, failed, untested and stale counts sit as five cards across the top.
- 3Break down credentials by typeA stacked bar shows how the vault's credentials split across browser logins, OpenAI keys and more.
- 4Track connector statusGitHub and Tailscale show ACTIVE while Jira, Notion and Linear wait with no credentials in the vault yet.
- 5Catch stale and failed credentialsThe Health Scan Flags list names every credential that needs a fresh test.
Captured from the real QuoxVault dashboard, not a mockup.
On the roadmapcloud-credential connectors, Gmail and Outlook OAuth, and a standalone Rust vault server. The full status map lives in the docs.
Govern
Grant the secret. Keep the custody.
We are onboarding a small number of teams ahead of wider release. Read how leases, the envelope model and the WARD chain fit together, or talk to us about putting your first credential behind the vault.
leased, never handed over