Tokenization

When an integration returns data, Speedwave runs it through a tokenizer before Claude sees it. The tokenizer finds sensitive values, swaps each one for a placeholder, and restores the real value only when Claude later calls a tool that needs it. This limits the personal and financial data that reaches the model, which matters for regulated work. See Data and privacy for how this fits the wider privacy picture.

What gets tokenized

Some values are recognized by their shape: email addresses, Polish phone numbers (the +48 format), PESEL numbers, NIP numbers, IBANs, card numbers, and API keys starting with sk-, AIza, xoxb-, or xoxp-.

For PESEL, NIP, card numbers, and IBANs, Speedwave also checks a checksum (the PESEL and NIP digit checks, the Luhn check, and the mod-97 check) before masking. A value that matches the shape but fails its checksum is left as plain text, so a random 16-digit number that is not a real card passes through unchanged. Email addresses, phone numbers, and API keys have no checksum, so they are masked on shape alone.

The tokenizer also masks values by the name of the field they sit in. A value stored under a key like password, token, secret, access_token, or api_key is masked whatever the value looks like.

Each detected value becomes a placeholder in the form [TYPE:TOKEN_xxxxxxxx]. The same value gets the same placeholder every time it appears in one run, so Claude sees consistent placeholders rather than a fresh one for each occurrence.

Where the mapping lives

The link between a placeholder and its real value lives only in memory, for one code execution. Speedwave does not write this mapping to disk, and it does not carry placeholders to the next run, the next session, or another chat. When Claude calls a tool that needs the real value, Speedwave swaps each placeholder back just before the call reaches the integration; in between, Claude works with placeholders only. This happens inside the Tool Gateway, the component that routes every integration call.

Caution

Tokenization covers data that an integration returns. It does not cover the text you type into the chat, and it does not cover the files in your project. Those reach the model directly.

Tokenization reduces exposure, it is not a compliance guarantee. A value the patterns do not recognize passes through unmasked, phone detection covers only the Polish +48 format, and the API-key check covers only the four prefixes above. There is also a per-run limit on how many values get masked; once reached, further values in that run pass through unmasked.