TokenPad

5 tools

AI Safety and Privacy Tools

Check what you are about to send, and what came back.

The most common way secrets and personal data leak into an LLM is not a breach. It is an engineer pasting a config file, a stack trace or a customer record into a model to ask what is wrong.

Every tool in this category runs locally. A redaction tool that uploaded your text in order to scan it would defeat its own purpose, and a secret scanner that did so would be actively harmful.

Which one you need

Scan for secrets first, because it takes seconds and the consequence of skipping it is unbounded. Prompts get logged by you, retained by the provider and quoted in error messages — anything inside one should be safe to read.

Run the injection scanner on any prompt that mixes your instructions with text you did not write. That covers retrieved documents, user uploads, support tickets, scraped pages — anywhere a third party can write into the context.

The redaction tools address the question a privacy review asks first: exactly which personal data reaches the provider. "The whole record, it was easier" is a common answer and a failing one.

None of these are a substitute for enforcing limits in code. A rule written into a prompt is a request; the same rule validated before a tool executes is a rule.

Questions

Can prompt injection be fully prevented?

No. Delimiting untrusted content substantially reduces it and is the cheapest mitigation available, but the durable defence is architectural: permissions enforced in code, tool arguments validated against a schema, and irreversible actions gated behind human confirmation.

Is it safe to send customer data to a model provider?

It is a disclosure to a third party, with everything that follows from that. It can be done properly — a signed data processing agreement, training disabled and verified, retention documented, and only the fields the task genuinely needs. Skipping any of those is the part that fails a review.

Other categories