Authenticate to Vault using an appropriate auth method (AppRole, Kubernetes, or AWS IAM) and obtain a client token; avoid using the root token in production
Enable the KV v2 secrets engine at a chosen mount path if not already enabled: vault secrets enable -version=2 -path=YOUR_PATH kv
Write a secret with vault kv put YOUR_PATH/secret-name key=value, or via the API with a POST to /v1/YOUR_PATH/data/secret-name with a JSON body containing a data object and optional options.cas for check-and-set
Read the secret with vault kv get YOUR_PATH/secret-name or via GET to /v1/YOUR_PATH/data/secret-name; the actual values are nested under data.data in the API response
List available secret names with vault kv list YOUR_PATH/ or GET to /v1/YOUR_PATH/metadata/; enumerate only what the calling identity's policy permits
Rotate secrets by writing a new version; the previous version is retained and accessible by specifying the version query parameter; delete old versions explicitly when no longer needed
Known gotchas
KV v2 wraps responses in an extra data envelope compared to KV v1; libraries and scripts written for v1 will silently read the wrong field
A Vault token with a short TTL will cause intermittent failures if not renewed; implement token renewal or use a token with an appropriate lease tied to the application lifecycle
Soft-deleted versions still consume storage; call vault kv destroy to permanently remove version data when secrets have been rotated out
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp