Self-Destruct Records

Self-Destruct lets you set a time-to-live (TTL) on any record in your vault. When the timer expires, the record and all associated encryption keys are permanently destroyed. This is ideal for temporary credentials, contractor access, and time-limited API keys that should not outlive their intended use.

How It Works

1. You enable self-destruct on a record and specify a duration in hours.
2. The server computes a deletion timestamp (now + hours) and persists it alongside the record.
3. A background job runs every 60 seconds, scanning for records whose deletion timestamp has passed.
4. Matching records are permanently deleted: the encrypted payload is removed from the database and all Data Encryption Keys (DEKs) associated with the record are destroyed.
5. Deletion is irreversible. There is no recycle bin or undo for self-destructed records.

Use Cases

• Contractor credentials. Give a contractor database access for 48 hours. The record self-destructs, and you never have to remember to revoke it.
• Temporary API keys. Create a short-lived API key for a deployment pipeline and set a 4-hour self-destruct. The key disappears after the deploy window closes.
• Conference or demo passwords. Share a Wi-Fi password or demo account that automatically cleans itself up after the event.
• Incident response. During a security incident, create a temporary elevated-access credential that auto-expires once the response window ends.

Setting Up Self-Destruct

From the Web Vault

1. Open the record you want to configure.
2. Click the More menu (three dots) in the top-right corner of the record view.
3. Select Self-Destruct.
4. Toggle Enable Self-Destruct on.
5. Enter the duration in hours (minimum 1, maximum 8760 -- one year).
6. Click Save. A countdown badge appears on the record card.

To disable self-destruct before the timer expires, open the same menu and toggle it off.

Via the API

PUT /api/vaults/{vault_id}/records/{record_id}/self-destruct

Enable Self-Destruct

curl -X PUT https://vault.example.com/api/vaults/vault-uuid-1/records/rec-uuid-1/self-destruct \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "enabled": true,
    "hours": 24
  }'

Response (200):

{
  "record_id": "rec-uuid-1",
  "self_destruct": {
    "enabled": true,
    "hours": 24,
    "scheduled_at": "2026-04-06T12:00:00Z",
    "destroys_at": "2026-04-07T12:00:00Z"
  }
}

Disable Self-Destruct

curl -X PUT https://vault.example.com/api/vaults/vault-uuid-1/records/rec-uuid-1/self-destruct \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "enabled": false
  }'

Response (200):

{
  "record_id": "rec-uuid-1",
  "self_destruct": {
    "enabled": false
  }
}

Check Self-Destruct Status

The self-destruct status is included in the standard record response when you fetch a record:

curl https://vault.example.com/api/vaults/vault-uuid-1/records/rec-uuid-1 \
  -H "Authorization: Bearer $TOKEN"

The response includes a self_destruct field if it has been configured:

{
  "id": "rec-uuid-1",
  "vault_id": "vault-uuid-1",
  "data_encrypted": "base64-encrypted-data",
  "self_destruct": {
    "enabled": true,
    "destroys_at": "2026-04-07T12:00:00Z"
  }
}

Security Considerations

• Deletion is permanent. Once the background job executes, the record cannot be recovered. Ensure you have alternative access to the underlying resource before the record self-destructs.
• DEK destruction. When a record self-destructs, its Data Encryption Key is deleted from the server. Even if encrypted blobs exist in database backups, they cannot be decrypted.
• Shared records. If a self-destructing record has been shared (one-time share or organization sharing), all share links are invalidated at destruction time. Grantees lose access.
• Audit trail. Self-destruct events are logged in the activity log with the record.self_destructed event type. The log entry records the record ID and destruction timestamp but not the record contents.
• Clock skew tolerance. The server allows up to 60 seconds of drift between the scheduled destruction time and actual deletion due to the background job interval.
• Minimum TTL. The minimum self-destruct duration is 1 hour. This prevents accidental immediate deletion.