Industries
Ship AI features without sending customer data to the model.
The developer profile swaps customer details, keys and connection strings for placeholders before the model call, then restores the reply.
The task
Developers paste a lot into AI chats: a failing webhook payload, a stack trace, a config file. That text often carries a customer's email, an IP address and a live API key.
Hushbridge swaps those values before the text goes to the model. In the browser extension you see the protected text first. In your own app, the SDK does the same swap inside your process before the call and restores the reply, streamed replies included. Your model provider still bills you for the call as usual.
Secrets and labelled values
The developer profile looks for keys from OpenAI, Anthropic, Stripe, AWS, GitHub and other providers. It also finds JWTs, private keys, bearer tokens, connection strings and password= assignments. Values that follow a label, such as a serial number or an employee ID, are swapped too.
The security questionnaire question
Customer security reviews now ask some form of "does customer PII go to the model?" With Hushbridge in the request path, the values it detects are swapped inside your process before the call. That lets you describe exactly what the model receives. Values it does not detect still go through, so give that answer with its scope.
Read the developer overviewBefore and after
Fictional example
What you paste
Why does this webhook fail with a 401? Customer: Ingrid Fallowfield, ingrid.f@example.com, IP 203.0.113.57. STRIPE_KEY=sk_test_FAKEexampleKEY0000000000 DATABASE_URL=postgres://admin:hunter2@db.example.com:5432/orders
What the AI gets
Why does this webhook fail with a 401? Customer: [PERSON_1], [EMAIL_1], IP [IP_ADDRESS_1]. STRIPE_KEY=[SECRET_1] DATABASE_URL=[SECRET_2]
5 details swapped: 1 name, 1 email, 1 IP address, 2 secrets. When the reply comes back, the real values are restored on your device. Run with the developer profile. The key is fake and the IP is from a documentation range. All names, numbers and addresses are made up.
What you review before sending
Known formats are swapped. Read for these before you send a log or config.
- Internal hostnames, service names and paths that reveal a customer.
- Order, ticket and session IDs. Plain system IDs are left alone on purpose.
- Custom tokens in your own format with no known prefix.
- Customer names inside log lines with no label or role nearby.
- CSV exports and other files. The extension does not read them.
Limits
- Detection uses rules, checksums and name lists. It can miss a name that has no title, role or label next to it. A unique error message or account detail can still point to one customer.
- The extension does not scan attachments. Files you upload to a chat site go as they are.
- A chat site's page can read text while you type. Paste logs that you have already protected, or use the SDK in your own app.
- Addresses are found in US style only. Names in non-Latin scripts are not covered.
- Review before sending stays necessary, and so do tests on your own data before you rely on it in production.
Paste a log line or config block into the free check to see what the engine finds. Nothing is sent to an AI model.
Try it with your own text