Start an agent and it inherits everything you can reach. Akasha moves the credentials it would otherwise read into an encrypted local vault and puts a broker where they used to be — so an agent uses a key one operation at a time, Akasha writes nothing to disk and 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
vault_session(provider="aws", profile="default")The agent asks the daemon for a credential. Where a broker exists, the tool reads it once per operation through a helper. Where none exists, the agent gets a short-lived 0600 file on RAM-backed storage. Either way, nothing is written to disk and nothing stays in the agent’s environment. That is attribution and drift protection, not containment.
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
Native MCP tools
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 without any integration work.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, never on disk. 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 another, and the plugin format is a few hundred lines of enum validation — small enough to read in an afternoon, which is the point.
Free, local, and open source.