Skip to Content
SecurityEncryption & Tokenization

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:

  1. The original PII value is extracted from the finding metadata.
  2. A per-tenant encryption key is retrieved from the key management system.
  3. The value is encrypted using authenticated AES-256.
  4. The resulting token replaces the original value in the finding record.
  5. 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:

  1. A new DEK is generated and set as the active encryption key.
  2. Previous DEKs are retained in a key ring for decryption.
  3. Tokens encrypted with old keys are decryptable using the key ring.
  4. 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 tokenize policy 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 mask policy 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

DataProtectionWhere
Scanner identity and credentialsAES-256 encrypted on diskScanner state file (BYOC and hosted)
Scan findings in transitTLS 1.2+ for all control plane communicationBetween scanner workers and the Slim.io API
Buffered findingsAES-256 encrypted in the local write bufferOn the scanner worker’s ephemeral storage
Log outputAutomatic PII scrubbing before any log emissionCloud 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.

Last updated on