The trust model,
on one inspectable page.
A middlebox that sits between your AI and your business tools should not ask for blind trust. This page is the complete picture — data flow, retention, detection scope, and an honest account of where detection can fail — written to be checked, not believed.
What happens to one request.
1. Your AI client asks
Claude/ChatGPT/Cursor sends a tool request to your private Waqi URL. Each team member has their own URL, so every request carries an identity.
2. Waqi calls the tool
Using your stored connector credential (read-only OAuth token or restricted key), Waqi fetches the response from Stripe, Xero, Slack, etc. Read-only: no write scopes are ever requested.
3. Detection runs in memory
The raw response exists in memory only. Detection rules scan it for personal and sensitive data. Free-text fields you have chosen to mask are removed entirely before detection.
4. Redaction, then the model
Detected values are replaced with typed placeholders (EMAIL:f4b1, CARD:aa46…) that stay stable per value, so the model can reason about "the same customer" without identities. Only this redacted version leaves the pipeline.
5. The audit log is written — after redaction
Which tool, which member, what categories were caught, the outcome. The log never contains the raw values.
6. The raw response is gone
It was never written to disk. Memory for one request, then nothing.
What we hold. What we never hold.
| Data | Stored? | Why / for how long |
|---|---|---|
| Connector credentials | Stored, AES-256-GCM encrypted | Needed to make your next request. Deleted when you disconnect the tool. |
| Audit log | Stored — written after redaction | Your proof of what was caught. Never contains raw personal data. |
| Account & billing data | Stored | Your email, plan, team membership. Payments are held by Paddle (merchant of record), not us. |
| Business data from your tools | NEVER stored | Exists in memory for the single request that needed it. |
| Redacted responses | NEVER stored | Delivered to your AI client, not retained. |
| Placeholder mappings | NEVER stored as a lookup table | Placeholders are derived deterministically — there is no reverse-lookup database of your customers to breach. |
What gets caught — and the honest part: what can get through.
Detected and redacted in every response, with EU/UK/US/UAE format coverage:
- ✓ Email addresses
- ✓ Phone numbers
- ✓ Payment card numbers
- ✓ IBANs and bank details
- ✓ Government ID patterns
- ✓ API keys and secrets
Known limitation: names inside free prose
Detection is rules-based today. Structured data — the list above — is caught reliably. A person's name sitting inside a free-text sentence can get past pattern matching; no regex can do that job. Two mitigations exist now: any free-text field can be masked entirely with one click (so prose never reaches the model at all), and the audit log shows you what was caught per call. To be fully explicit: the log records what was caught, not what was missed. A local NER (name-detection) tier is on the roadmap as the real fix — we publish it when it ships, not before.
What Waqi does not defend against
Waqi is not a data-loss-prevention platform, an endpoint agent, or a prompt-injection firewall. It does one job: personal data in tool responses never reaches the model, provably. If a team member types a customer's details into a chat by hand, that path never touches Waqi. Scope stated plainly so you can judge the fit.
Access & blast radius
Connections are read-only by design — Waqi never requests write scopes, so even a full compromise of a credential could not modify, send, or delete anything in your tools. Credentials are encrypted at rest (AES-256-GCM); business data is never at rest at all, which keeps the breach surface to: encrypted tokens and a redacted log.
Questions or holes to poke? info@bilazann.com — security feedback is answered by the person who built it. DPA · Privacy · Live tester