Vault response wrapping takes a response and places it in the cubbyhole of a single-use token. The caller receives the wrapping token instead of the underlying value. The intended recipient unwraps the token and receives the original response. The token is temporary and single use; a reused token should fail. This is useful for delivering AppRole SecretIDs, bootstrap credentials, and other values over a channel that should not retain a reusable secret.
The control is often misunderstood as encryption for a secret that can be stored indefinitely. Response wrapping has a short lifetime and a one-time use model. The wrapping token is itself a bearer credential during its lifetime. If it is logged, copied into a ticket, or left in a shell history, someone else can consume it first. The recipient should unwrap promptly and remove the token from local storage.
Verify the wrapping metadata
The wrapping token's metadata describes the creation path, creation time, TTL, and whether the token is renewable. Check the path and TTL against the expected workflow. A generic wrapping endpoint may have a different creation path than a secret read, and Vault's own documentation warns that a path check can fail to distinguish some proxy or multi-sink workflows. Use metadata as a consistency check, not as the only proof that the value came from the intended service.
Unwrap through the documented API rather than reading the cubbyhole directly. Vault's unwrap endpoint performs validation checks and produces audit records. Handle a failed unwrap as an expired, consumed, or invalid delivery token. Do not retry the same token in a loop or replace it with a credential extracted from logs.
Build the delivery channel
Use a recipient identity that is authorized only for the intended unwrap path. Deliver the wrapping token through a channel with access control and a short retention period. If the recipient is a human, avoid command-line arguments that appear in process listings. If the recipient is an automation service, provide the token through a file or environment channel with restrictive permissions and delete it after use.
Confirm that the original secret is not also exposed through logs, crash reports, or telemetry. Response wrapping protects the delivery path, not every surrounding system. The secret's Vault path, access policy, audit device, and lease behavior still determine who can obtain a new value.
Plan for failure
If the token expires, issue a new wrapped response through the authorized service. Do not reuse an old response or cache the unwrapped value in a shared location. If the token was exposed, revoke the underlying credential when the backing system supports it, rotate the secret, and review Vault audit events for the wrapping token and the original read.
For revocation, identify the token accessor where possible and revoke the wrapping token rather than relying on TTL alone. Also review the token that created the response and any child tokens involved in the workflow. A response-wrapping token is a short bridge between two identities. Its value depends on prompt use, one-time consumption, and a clean removal from every intermediate store.