Your agent uses your keys.
It never holds them.

One launcher.
Your agent, minus the plaintext.

You keep running the agent you already use. You run it through Akasha, and you say what it may use. One command, four parts:

So akasha run claude --with aws:default -- claude starts Claude Code in a sandbox that grants exactly the one thing you named. Underneath, the vault itself: here it finds two plaintext credentials, vaults them on your say-so, runs a real command with one it never prints, and writes the access to the log.

akasha discover · list · exec · logsreal output, synthetic credentials

You do not pick between them. The provider plugin says which it supports, and the policy says which an agent may use.

One vault. Three jobs.

A secrets vault your applications use, a sandbox and broker your agents run under, and one log that says what each of them did with every secret.

$ akasha put env:stripe STRIPE_API_KEY
$ akasha exec --with env:stripe -- ./charge.sh

$ akasha run claude --with aws:default -- claude
$ akasha exec --with env:github -- github-mcp-server

// an MCP-tool record; broker records carry the tool and a derived task
"tool_name": "send_email",
"task": "Process refund for order #8821",
"reasoning_trace": "User requested refund. Order verified."

• The vault stays on the machine. A local SQLite file encrypted with XChaCha20-Poly1305. The vault file alone cannot be opened: half the key material lives in your OS keychain. What a brokered credential does on the network is the run's business, open by default and said so, or closed with --network none.
• Brokered per operation. Git, GitHub and AWS call back through akasha helper each time. Where no broker exists, vault_session hands back a short-lived file: mode 0600, RAM-backed where the platform allows, one-hour TTL.
• MCP tools too. akasha setup writes the MCP config for Claude Code, Codex, Cursor, VS Code and Windsurf. Inside a run, they act as the run's identity.
• Every touch audited. Every broker call, wrap, retrieve and session goes to a hash-chained JSON-lines log, ~/.akasha/audit.log, with the tool and, when the agent supplied them, the task and reasoning. akasha logs --verify walks the chain. Tamper-evident, not tamper-proof.
• Beneath the MCP stack. akasha exec injects vaulted credentials into other MCP servers at launch, so your GitHub or database server (through env:) holds no plaintext token in its config.
• Cross-agent grants. Delegate over A2A with only tokens on the wire. Grants are single-use, bindable to one named tool, and expire when given a TTL.

Under the launcher:
MCP, CLI and policy.

// Instead of a hardcoded token in your MCP config:
"github": {
  "command": "akasha",
  "args": ["exec", "--with", "env:github",
           "--", "github-mcp-server"]
}

default: allow
rules:
  # raw read of any vaulted entry
  - {action: retrieve, effect: deny}
  # agents take the per-operation route
  - {action: session, caller: agent, brokerable: true, effect: deny}
  # delegating a high-risk secret onward: a human decides
  - {action: grant, min_risk: high, effect: ask}
  - {action: grant, effect: allow}

What is under the hood.