PII vault & crypto-shredding

Manage personally identifiable data in Audact calls through encryption and crypto-shredding: encrypt PII spans, decrypt on demand, and permanently erase a data subject's information.

This guide covers the API and dashboard features for managing personally identifiable data in Audact calls through encryption and erasure (crypto-shredding).

Overview

When encryption is enabled for your workspace, Audact detects and encrypts personal data in place within call transcripts and evidence:

Spans are encrypted: BSN, IBAN, card numbers, emails, phone numbers, dates of birth, and postal addresses are replaced by ciphertext tokens, e.g., ⟦pii:v1:EMAIL:…⟧.
Text around them stays readable: You can still see the context; only the private values become encrypted.
You can decrypt it: The "Decrypt personal data" button on any call page shows plaintext.
You can erase it: Via "Erase a data subject" or by calling the API, you destroy the encryption keys and make all instances unrecoverable.

1. Client hash normalization

When you erase a person's data, you provide only a hash of their identifier, never the plaintext value. The hash is computed client-side in your browser (or your SDK), so Audact never receives the original value.

How hashing works

Each identifier type (name, email, phone) is normalized first, then hashed:

Type	Normalization	Example
Email	trim, lowercase, NFC Unicode	`"Jörg@Example.com"` → `"jörg@example.com"`
Phone	E.164 format (digits and `+` only)	`"+31 6 1234 5678"` → `"+31612345678"`
Name	trim, NFC Unicode, lowercase, collapse internal whitespace	`" John Smith "` → `"john smith"`

After normalization, the client hash is SHA-256(normalized_value) as a 64-character hex string.

Worked examples

Example 1: Email hash

Input:         Foo.Bar@Example.COM
Normalized:    foo.bar@example.com
SHA-256:       00a9fee7604744049b5f777d65021e214480af944b16c1580893c5c6eed2d45a

Copy the SHA-256 string above into the "Erase a data subject" form, or supply it to your API client:

bash

curl -X POST https://api.audact.ai/v1/pii/shred \
  -H "Authorization: Bearer ${API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "identifier_type": "email",
    "identifier_hash": "00a9fee7604744049b5f777d65021e214480af944b16c1580893c5c6eed2d45a"
  }'

Example 2: Phone hash

Input:         +31 6 1234 5678
Normalized:    +31612345678
SHA-256:       fab7be8a931d1088a82f6acf9e468aaf6a3accc07d5112ee5d6fca93281e1583

Phone numbers must be in E.164 format (+ followed by digits only). If your input has spaces, dashes, or parentheses, they are stripped before hashing. Invalid formats (e.g., local-only numbers like 0612345678 without the country code) return an error.

Example 3: Name hash

Input:         Émile
Normalized:    émile
SHA-256:       a56b363ca23dd9db9bd117840f28aab076b474f8cbea85416f715281dc809d56

Names are case-insensitive and diacritics are preserved (no "é" → "e" conversion). Multiple spaces collapse to one. Leading/trailing whitespace is trimmed.

Important: Audact does not auto-detect names spoken in calls. Name erasure works only for names you supplied as identifiers at call start or via the identity-link API. If a name was mentioned in passing without being registered, it is not encrypted and cannot be erased by this mechanism.

2. Decrypt and shred flows

Decrypting personal data

The dashboard shows encrypted values as chips (🔒 Email icon). To view the plaintext:

Open the call detail page.
Click "Decrypt personal data" (top right, next to the call status).
One-time batch request: All encrypted values on the page are decrypted in a single request and stay visible for 5 minutes, then automatically clear.
Decryption is audited: The call's evidence chain records who decrypted it and when.

API:

bash

curl -X POST https://api.audact.ai/v1/calls/${CALL_ID}/pii/decrypt \
  -H "Authorization: Bearer ${API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "text": "BSN: ⟦pii:v1:BSN:…⟧, Email: ⟦pii:v1:EMAIL:…⟧"
  }'

Response:

json

{
  "text": "BSN: 123-45-6789, Email: alice@example.com",
  "decrypted": 2,
  "erased": 0
}

If an identity was shredded before you decrypt, you get [ERASED_EMAIL] in place of the plaintext. The response also counts how many were erased.

Shredding personal data

To permanently erase a person's data from your workspace:

Via dashboard ("Erase a data subject" card)

Choose a type: Name, Email, or Phone.
Enter the value (plaintext). It is hashed in your browser; Audact never sees it.
Review the hash before confirming (for your records).
Confirm with ERASE (destructive action).
Result: How many identities were shredded and how many calls are affected.

Via API

bash

curl -X POST https://api.audact.ai/v1/pii/shred \
  -H "Authorization: Bearer ${API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "identifier_type": "email",
    "identifier_hash": "00a9fee7604744049b5f777d65021e214480af944b16c1580893c5c6eed2d45a"
  }'

Response:

json

{
  "shred_id": "12345678-…",
  "identities_shredded": 1,
  "calls_affected": 7,
  "shredded_at": "2026-10-15T14:30:00Z"
}

Per-call shredding

To shred all identities of a single call:

Open the call detail page.
Go to the "Personal data" tab.
Click "Shred all identities in this call" (owner role required).
Confirm with SHRED.

⚠️ Warning: Shredding an email or phone identity erases that value in every call of your workspace where it appears, not only in this one. This is intentional: a caller's email is the same value across all calls, and erasing one protects all.

3. On/off switch: encryption vs. redaction

Your workspace has a "Encryption of personal data" setting under Settings → Privacy & Erasure.

What it does

ON (default): New calls encrypt detected spans. You can decrypt them and shred them later.
OFF: New calls redact detected spans (they appear as [REDACTED_EMAIL] and are irrecoverable). This is today's behavior.

Important notes

The switch is forward-only: Existing calls keep their mode (ON or OFF) from when they started. Flipping the switch affects only new calls.
No plaintext mode: The switch has only two states: encrypted or redacted. There is no plaintext mode where data is stored unencrypted.
Re-sealed configurations: Turning the switch ON or OFF triggers a re-seal of every configuration in your workspace (visible in the change history as "N configurations re-sealed").
Encryption requires keys: If Audact cannot prepare encryption keys when you flip to ON, the error "Encryption keys could not be prepared" is shown, and the setting stays OFF. Contact support if this persists.

4. Roles and permissions

Access to PII features is controlled by workspace roles:

Action	Minimum role	What it does
See encrypted chips (🔒 Email)	Viewer	View encrypted values in calls; cannot decrypt
Decrypt personal data	Viewer	Temporary plaintext view (5 min auto-clear)
Link an identifier	Developer	Register a name/email/phone as a subject identity
Shred a subject (erase data)	Owner	Destroy a person's data across all calls
View erasure log	Viewer	See a history of who shredded what and when
Turn encryption on/off	Owner	Change the workspace mode

Impersonation sessions (org staff acting as a tenant) inherit the token's role and are audited as the org user.

5. Over-erasure: names and subjects

Why name erasure is weaker

Audact has seven span detectors: BSN, IBAN, card, email, phone, date of birth, and postal address. Of these:

Email, phone, postal address, DOB, BSN, IBAN, card are auto-detected in call transcripts.
Names are NOT auto-detected. Names exist only if you supply them at call start or via the identity-link API.

Consequence: A name erasure affects only the identities you registered, not every mention of that name in a call.

Example

Call 123 subject identities:
  - Phone: +31612345678 (auto-detected at call start)
  - Name: "Alice Smith" (supplied at call init)
  - Email: alice@example.com (detected in conversation)

Evidence:
  "Caller information:
   BSN: [Encrypted]
   Phone: +31612345678
   Name: Alice Smith
   Email: [Encrypted]"

If you shred alice@example.com:

That email is erased in every call of your workspace where it appears.
The transcript now shows: Email: [ERASED_EMAIL]
BSN and address remain encrypted (still decryptable).

If you shred alice smith (the name hash):

Only the name identity you registered is erased.
The transcript now shows: Name: [ERASED_NAME]
But if the caller is referred to by name elsewhere in the call (e.g., "Alice called at 2pm"), that mention is NOT encrypted and NOT erased.

Best practice

For strong data protection, register all identifiers you know at call start:

json

{
  "call_type": "inbound",
  "identifiers": [
    {"type": "email", "hash": "<client-hash-of-email>"},
    {"type": "phone", "hash": "<client-hash-of-phone>"},
    {"type": "name", "hash": "<client-hash-of-name>"}
  ]
}

This ensures that every detected span related to that subject is sealed under a keyset that includes the name identity, so a single shred of the name erases everything.

Overview

1. Client hash normalization

How hashing works

Worked examples

Example 1: Email hash

Example 2: Phone hash

Example 3: Name hash

2. Decrypt and shred flows

Decrypting personal data

Shredding personal data

Via dashboard ("Erase a data subject" card)

Via API

Per-call shredding

3. On/off switch: encryption vs. redaction

What it does

Important notes

4. Roles and permissions

5. Over-erasure: names and subjects

Why name erasure is weaker

Example

Best practice

See Also