| name | aivault |
| description | Complete guide for using aivault as a zero-trust local vault and proxy for API secrets. Use this skill when initializing/configuring aivault, managing secrets and credentials, invoking capability-backed API calls, setting workspace/group isolation, adding custom providers, or troubleshooting daemon and policy issues. |
aivault Runtime and Integration
This skill covers secure setup and day-to-day use of aivault for agent workflows.
Install
Install aivault if it is not already available:
curl -fsSL https://aivault.moldable.sh/install.sh | sh
Quick Reference
| Resource | Path |
|---|
| CLI binary | aivault |
| Daemon binary | aivaultd |
| Vault root (default) | ~/.aivault/data/vault/ |
| Daemon socket (default) | ~/.aivault/run/aivaultd.sock |
| Registry definitions | ~/aivault/registry/*.json |
| Registry schema | ~/aivault/registry/schemas/registry-provider.schema.json |
| Upstream docs source | ~/aivault/docs/ |
Default Workflow
- Check status and provider setup:
- Create provider secret (auto-provisions registry credential + capabilities when names match):
aivault secrets create --name OPENAI_API_KEY --value "sk-..." --scope global
- Inspect available capabilities:
aivault capability list
aivault capability describe openai/chat-completions
- Invoke through policy boundary:
aivault invoke openai/chat-completions --body '{"model":"gpt-5.2","messages":[{"role":"user","content":"hello"}]}'
- For long-running streamed calls, add a millisecond timeout such as
--timeout-ms 420000.
- Verify audit trail:
Detailed References
Read these as needed:
Core Usage
Security and Isolation
Provider and Capability Design
Operations and Debugging
Essential Patterns
1. Registry-backed secret provisioning
Use canonical secret names (for example OPENAI_API_KEY) so aivault can pin to a provider and auto-enable capabilities.
2. Capability-first invocation
Always call aivault invoke <capability-id> (or json / markdown) instead of direct upstream calls with raw keys.
3. Scoped tenancy controls
Use --scope workspace and --scope group for tenant isolation, then pass --workspace-id / --group-id on invoke.
4. Custom provider fallback
Only create manual credentials and capabilities when a provider is not in the built-in registry.
Common Mistakes to Avoid
- Storing API keys in
.env for untrusted agent code
- Invoking raw URLs instead of declared capabilities
- Forgetting scope context when debugging credential resolution
- Assuming caller-provided auth headers are allowed (broker owns auth headers)
- Treating custom providers as equally tamper-resistant as compiled registry providers
Source of Truth
When behavior is unclear, verify against local docs and runtime artifacts:
~/aivault/docs/
~/aivault/registry/
~/aivault/src/