Start an agent and it inherits everything you can reach. Akasha starts it in a sandbox instead, where your credential files and the keychain are not there, and lets its own tools borrow a key one operation at a time through a local broker. Akasha writes nothing to disk, records every use against a token rather than the value, and none of it leaves the machine.
01 — The premise
The agent runs as your user. Everything else has to be honest about that.
It has your shell, your filesystem and your keys. Any mechanism installed by writing configuration — an MCP entry, an environment variable, a harness hook — can in principle be un-configured by a process holding the same privileges. Tools that promise to intercept their way to safety are quietly relying on the agent’s cooperation.
Akasha does not make that claim. Its strongest guarantee is possession, not interception: a secret that exists only inside the vault has no plaintext left anywhere to steal. Getting around the interception layers wins nothing, because there is nothing on disk to find. The weaker tiers above that — owning the agent’s environment, gating each operation — are labelled as what they are, drift protection rather than a cage.
That distinction is the whole design, and the threat model states plainly what each tier does and does not buy you.
02 — How it works
Four moves, in order.
01
akasha protect ~/.aws/credentialsSetup scans the machine for the credentials that are already lying around — AWS profiles, SSH keys, Git tokens — and vaults them. Escrow the originals with akasha protect and the plaintext is gone entirely, replaced by a stub. What is not on disk cannot be read off it.
02
akasha run claude --with aws:default -- claudeakasha run starts the agent you already use inside an OS sandbox — seatbelt on macOS, bubblewrap on Linux — where ~/.aws, ~/.ssh, the vault and the keychain are not there. Its own tools still work: aws fetches the credential through credential_process and git through a credential helper, one operation at a time, with nothing in the environment and nothing on disk. The run has its own identity, revoked when it ends. The sandbox confines what the agent can read, not what it does with a credential you granted it.
03
~/.akasha/policy.yamlEvery request passes a policy engine before anything is unsealed: first-match rules over action, agent, tool, provider, instance, category, risk, caller and brokerable, resolving to allow, deny or ask. Ask prompts you and fails closed. Three verbs are gated separately: broker (one operation, allowed by default), session (a whole session file, denied to agents where a broker exists) and retrieve (a raw read of any entry, denied). setup installs that starter policy on a machine that has none.
04
akasha logs --verifyEach access goes to a local, hash-chained audit log keyed on a token digest, not the secret. You get a complete account of what every agent touched and when, with nothing sensitive in the record itself. The chain is tamper-evident, not tamper-proof.
03 — In practice
Akasha finds credentials sitting in plaintext, vaults them on your confirmation, then runs a real command with one it never reveals — and records the access against a token digest.
04 — Integration
MCP tools too
After setup, any MCP client gets vault_session, vault_wrap, vault_put, vault_store, vault_retrieve, vault_grant, vault_inspect, vault_describe, vault_identity and vault_status, there when you ask for them. Inside akasha run they act as the run’s identity. We measured why they are not the default path: in 175 agent runs, models never once chose them unprompted.vault_assume remains as an alias.
Everything else via the CLI
akasha exec draws a vaulted credential into any process, runs it, and cleans up on exit — which is also how you keep other MCP servers’ keys out of plaintext config.
Providers are data, not code
Integrations are signed YAML that select from a closed set of Go primitives. There is no command field, no shell and no expression language anywhere in the format, so there is no slot to inject one. Write your own and it stays inert until you approve it — and the approval is bound to that file’s hash, so editing it revokes trust.
Encryption
SQLite sealed with XChaCha20-Poly1305. The key is wrapped with ML-KEM-768 and held in the OS keychain rather than in the vault file. Optional passphrase-protected backup for recovery.
Works with
05 — What it does not do
You shouldn’t trust it on assertion. Here is what to check.
A process running as you can read the key
The daemon runs as your user, and so does the agent. By default the vault key is an OS keychain entry plus a row in vault.db. Any process running as you can read both without going through Akasha, so no policy runs and Akasha audits nothing. Two things narrow that: a vault passphrase, set when you create the vault, and akasha run, which sandboxes the agent away from the keychain and the vault. If you do only one, do the second.
Discovery alone vaults copies
The originals stay exactly where they are until you escrow them with akasha protect. Until then an agent can still read the file directly. Restoring is byte-for-byte, and uninstalling restores automatically.
Data born in the session was never vaultable
A secret you paste into a conversation is not something possession can protect. Payload classification helps and is advisory — we do not market it as a guarantee.
It is alpha
Pre-1.0. Do not use it to protect secrets you cannot rotate. The threat model keeps a running list of known limitations we would rather you read than discover.
Nothing phones home
The audit log is local and there is no telemetry to disable. The trust boundary is one file, the policy engine one package, and the plugin format one file. The parts that matter are small enough to read, which is the point.
Free, local, and open source.