Tokenization
Speedwave automatically replaces detected sensitive data with secure placeholder tokens before requests reach the model provider, allowing Claude to operate exclusively on tokenized values. Tokenization is available under beta features, while security policies enforced across your organization via managed configuration (MDM) apply even when beta features are disabled.
Detection rules and formats
Section titled “Detection rules and formats”Speedwave includes seven built-in detection rules. Four of these rules also validate checksums, ensuring that text matching the general pattern but lacking a valid check digit is preserved as plain text.
| Rule | Detection scope | Validator |
|---|---|---|
EMAIL | E-mail address | none |
PHONE_PL | Polish phone number (+48 formats) | none |
PESEL | PESEL national identification number | checksum |
NIP | NIP tax identification number | checksum |
IBAN | IBAN bank account number | mod-97 |
CARD | Payment card number | Luhn algorithm |
API_KEY | API keys with prefixes sk-, AIza, xoxb-, xoxp-, or ghp_ | none |
You can also define custom regex-based rules and keyword substitutions (replacing designated terms with aliases) on a per-project basis. Neither is active by default. Values that do not match any configured rule pass through unchanged.
Token encryption mechanism
Section titled “Token encryption mechanism”Speedwave does not maintain a centralized database or lookup table. Instead, detected values are encrypted with AES-128-SIV using a project-specific key and inserted into the text as structured tokens (such as [EMAIL:TOKEN_…]). The same input value always produces an identical token within a project. Any modification to a token or attempt to decode it with an invalid rule causes decryption to fail. The encryption key is generated automatically on first use at ~/.speedwave/policies/<project>/key.
Enforcement points
Section titled “Enforcement points”Tokenization is enforced at two distinct boundaries powered by the same underlying engine. A local per-project proxy inspects all outbound requests sent to the model provider, including system prompts and conversation history. In addition, the Tool Gateway tokenizes data returned from integrations as well as sandbox command outputs. Detection events are recorded in ~/.speedwave/audit/<project>/ as aggregated count metrics without storing original values.
Security policies
Section titled “Security policies”Three policy templates are available out of the box: strict (all seven built-in rules active), gdpr-art32 (API_KEY disabled), and eu-ai-act-art5 (NIP and API_KEY disabled). If no template is explicitly selected, the default application configuration applies, enabling tokenization for all seven built-in rules. The effective project policy represents the union of user-selected rules and mandatory MDM profiles. Each rule can also run in a log-only mode that counts occurrences without modifying content.
Configuration
Section titled “Configuration”- Enable beta features.
- Open Settings → Security.
- Select a policy template or define custom rules. Settings enforced by MDM appear locked against modification.
Value restoration
Section titled “Value restoration”The Tool Gateway restores original values into tool call parameters when dispatching requests to target integrations, and nowhere else in the execution path. User interface rendering is the single exception: the Desktop application detokenizes transcripts locally for host display, while files stored on disk remain tokenized. The model provider never receives the unmasked values.
Policy templates reference specific regulatory articles as practical starting points rather than formal certifications. See Data and privacy for full details on data transmission boundaries.