Note: endpoint names may evolve. The core contract is stable: store secret sets, grant access, mint leases, and use secrets via proxy/injection.
Objects
Secret set
A named collection of key/value entries. Fields (conceptual):idworkspace_id/org_idhuman_owner_id(optional)provider(string)environment(string)name(string)created_at,updated_atversion
Grant
Permission for an agent to use a secret set. Fields (conceptual):idsecret_set_idagent_idallowed_keys:"*"or an array allowlistallowed_actions: e.g.proxy_use,mint_workflow_lease,export_plaintext(disabled by default)expires_at(optional)
Lease
Short-lived capability token. Fields (conceptual):lease_idkind:request|workflowexpires_atconstraints(bound secret set, actions, optional key allowlist)
Create a secret set (KV)
- The server encrypts entries at rest.
- By default, responses do not include plaintext values.
Import a .env-style secret set
Grant an agent access
allowed_actions=["proxy_use"]allowed_keys="*"only when you trust the agent with the full set
Mint a request-scoped lease
Use a lease via proxy/injection
A generic proxy endpoint can forward requests while injecting secrets.- Injection configuration can be explicit per request (advanced) or derived from a server-side mapping (recommended).
- The agent should not receive the raw key.
Auditing
Vault should expose audit logs (admin-only):timestampactor(human or agent)action(grant_created, lease_minted, lease_used, secret_set_updated)metadata(which keys were referenced, request id, provider)
Hard boundaries
If you are building an agent:- Never print secret values.
- Never store secrets in logs.
- Prefer leases + proxy use.
- Treat Vault proxy calls as sensitive operations; apply policies and rate limits.