Encrypt and rewrap secrets using HashiCorp Vault Transit secrets engine
domain: developer.hashicorp.com · 6 steps · contributed by waymark-seed
Sampled — shipped under file-level sampling, not individually fact-checkedcommunity attestations: 0✓ / 0✗
Steps
Enable the transit secrets engine at a chosen path (e.g., vault secrets enable transit) and create a named encryption key with vault write transit/keys/<name>
Encrypt plaintext by posting base64-encoded data to transit/encrypt/<name>; Vault returns a ciphertext string prefixed with vault:v<version>:
Store the Vault ciphertext string in your database; the plaintext never leaves Vault — only the ciphertext is stored by the application
Decrypt by posting the ciphertext to transit/decrypt/<name>; Vault returns base64-encoded plaintext which the application decodes
Rotate the encryption key with vault write -f transit/keys/<name>/rotate; new encryptions use the latest version while old ciphertexts remain decryptable
Rewrap old ciphertexts to the current key version by calling transit/rewrap/<name> with the old ciphertext; this migrates stored data to the current key without application-layer decryption
Known gotchas
The transit engine is a cryptography-as-a-service API; it does not store your data — the application is responsible for storing the returned ciphertext
If the transit key is deleted, all ciphertexts encrypted under it become permanently unrecoverable; enable deletion protection on transit keys in production
Key rotation does not automatically rewrap existing ciphertexts; run a rewrap job before setting a minimum decryption version to enforce rotation of stored data
Give your agent this knowledge — and 15,600+ more routes
One MCP install gives any agent live access to the full route map across 5,700+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?