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 with a per-workspace key — there is no reverse-lookup database of your customers to breach. The exact linkability boundary: within your workspace the same value always gets the same tag (so the model can correlate rows); the same value in any other customer’s workspace derives a different tag, so redacted outputs can never be linked across customers. |
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. So the miss behaviour is configurable, and we name it: by default free-text fields are open with structured detection running inside them (fail-open on prose, because reading messages is why teams connect these tools). Strict mode flips a connector to fail-closed: every free-text field is hidden from the model wholesale unless you consciously re-open it, so a detection miss cannot leak what the model never receives. Either way the audit log shows what was caught per call — and to be fully explicit, it records what was caught, not what was missed. A local NER (name-detection) tier is on the roadmap as the real fix for open prose — we publish it when it ships, not before.
How do I know I'm talking to the real Waqi?
Waqi is a hosted service: there is no locally installed bridge to be swapped or tampered with. Your MCP URL is a per-member token on our TLS-served domain — treat the URL as a credential, revoke it from the dashboard at any time, and every call it makes appears in your audit log, so an unexpected caller is visible rather than silent. If we ever ship a locally-run bridge, each release will carry published checksums so you can verify the binary before trusting it — that commitment is made now, ahead of the code.
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