Encryption & Tokenization
Slim.io uses authenticated AES-256 encryption to tokenize sensitive data values discovered during scans. Tokenization replaces plaintext PII with encrypted tokens that can be reversed only by authorized parties.
How Tokenization Works
When a governance policy triggers a tokenize action:
- The original PII value is extracted from the finding metadata.
- A per-tenant encryption key is retrieved from the key management system.
- The value is encrypted using authenticated AES-256.
- The resulting token replaces the original value in the finding record.
- The original value is purged from the finding metadata.
Original: "John Smith, SSN: 123-45-6789"
Tokenized: "John Smith, SSN: <encrypted-token>"Encryption Standard
Slim.io uses AES-256 encryption with message authentication to ensure both confidentiality and tamper detection. Tokens are URL-safe encoded for storage and transport, and include embedded timestamps for TTL-based expiry.
Key Management
Key Hierarchy
Root Key (Google Cloud KMS)
→ Tenant Master Key (derived per tenant)
→ Data Encryption Key (rotated periodically)- Root Key — Stored in Google Cloud Key Management Service (KMS), never leaves KMS
- Tenant Master Key — Derived from the root key using the tenant ID as context
- Data Encryption Key (DEK) — The actual key used to encrypt token payloads, rotated on schedule
Key Rotation
Key rotation creates a new DEK while maintaining the ability to decrypt tokens encrypted with previous keys:
- A new DEK is generated and set as the active encryption key.
- Previous DEKs are retained in a key ring for decryption.
- Tokens encrypted with old keys are decryptable using the key ring.
- Optionally, a re-encryption job can migrate old tokens to the new key.
The default key rotation schedule is 90 days. Enterprise customers can configure custom rotation schedules or trigger immediate rotation via the API.
Key Access Control
- Only the backend service account can access encryption keys
- Key operations are logged in Cloud Audit Logs
- Key material never leaves Google Cloud KMS (envelope encryption pattern)
- Tenant isolation ensures one tenant’s keys cannot decrypt another tenant’s tokens
Reversible vs. Irreversible
Slim.io supports two modes of data protection:
Tokenization (Reversible)
- Encrypted tokens can be decrypted back to original values
- Requires access to the tenant’s encryption key
- Use when the original data may be needed later (e.g., incident investigation)
- Implemented via the
tokenizepolicy action
Masking (Irreversible)
- Original values are permanently redacted
- No decryption is possible — the original data is destroyed
- Use for data that should never be recoverable
- Implemented via the
maskpolicy action
# Tokenization (reversible)
actions:
- type: tokenize
config:
algorithm: aes-256
key_scope: tenant
# Masking (irreversible)
actions:
- type: mask
config:
strategy: redact # replace with "[REDACTED]"Decrypting Tokens
Authorized users can decrypt tokens through:
Dashboard
In the Data Catalog, click on a tokenized finding and select Reveal Original Value. This requires the Admin or Editor role.
API
POST /api/v1/tokens/decrypt
Authorization: Bearer $TOKEN
{
"tokens": ["<encrypted-token-1>", "<encrypted-token-2>"]
}Response:
{
"status": "success",
"data": {
"decrypted": [
{ "token": "<encrypted-token-1>", "value": "123-45-6789" },
{ "token": "<encrypted-token-2>", "value": "4111-1111-1111-1111" }
]
}
}Scanner-at-Rest Encryption
In addition to tokenization of discovered PII values, the scanner infrastructure itself encrypts sensitive data at rest:
What Is Encrypted
| Data | Protection | Where |
|---|---|---|
| Scanner identity and credentials | AES-256 encrypted on disk | Scanner state file (BYOC and hosted) |
| Scan findings in transit | TLS 1.2+ for all control plane communication | Between scanner workers and the Slim.io API |
| Buffered findings | AES-256 encrypted in the local write buffer | On the scanner worker’s ephemeral storage |
| Log output | Automatic PII scrubbing before any log emission | Cloud Logging (hosted) or stdout (BYOC) |
Log Scrubbing
All scanner log output is automatically scrubbed before it leaves the process. The scrubber removes:
- Social Security numbers, credit card numbers, phone numbers, email addresses
- Cloud provider access keys and secret keys
- Authentication tokens and bearer credentials
- Connection strings containing passwords
This ensures that no PII is ever written to logs, even if a debug-level log statement accidentally includes sensitive content.
Log scrubbing applies to ALL output — including standard error, exception tracebacks, and structured JSON logs. There is no way to bypass it, even in debug mode.
BYOC Encryption
In BYOC deployments, scanner state encryption uses a key you provide. The scanner never stores credentials or authentication state in plaintext on disk. See BYOC Deployment for key configuration details.
All decryption operations are logged in the audit trail with the requesting user’s identity, timestamp, and token IDs. Excessive decryption requests trigger security alerts.
Encryption at Rest
Beyond tokenization, all platform data is encrypted at rest using cloud-managed encryption (AES-256). This provides a baseline encryption layer for all stored data, independent of the application-layer tokenization applied to specific PII findings.