Data handling guarantees

The one-page answer to “do you host my business data?” — written so it can be checked against the actual code, not just asserted. Referenced from our Privacy Policy and Data Processing Agreement.

What is stored persistently (encrypted, in Postgres)

• The connector credential you paste in (e.g. a restricted Stripe key) — encrypted with AES-256-GCM. This has to persist: it's needed to make your next request.
• Redacted audit log entries — which tool, what category was caught, the outcome, and an already-redacted response preview. Written after redaction, never before.

What is never stored anywhere

• The actual business data a connected tool returns — transactions, customer records, anything a tool call returns. It exists in memory only for the duration of that one request.
• Your plaintext credential, once decrypted for a call. It's used immediately to make that one request and isn't kept anywhere it would outlive it.

Why this holds even on shared server infrastructure

Our hosting platform may reuse a warm server process across a few consecutive requests for speed — that's normal and doesn't create a data-leakage path here, because no request's data is ever stored in a place a later request could read from. One request's data is unreachable the moment that request finishes, regardless of whether the underlying process itself gets reused afterward.

What's outside Waqi's control

Once a redacted response reaches your AI client (Claude, ChatGPT, Cursor, or whichever you've connected), what that client does with it — its own context retention, logging, or training-data policy — is governed by that provider's terms, not ours. Since the data reaching that point has already been redacted, this boundary doesn't carry personal-data risk.

The engineering detail behind this page — the actual request handler, tests, and verification — lives in app/api/mcp/[token]/route.js and SECURITY.md in the Waqi codebase.