How your business context is protected.

AskRITZ holds the accumulated understanding of your business. The protections below are built into the database and the server, not into the interface — an interface can be bypassed, and a control that depends on the client behaving correctly is not a control.

Every table holding customer information has row-level security enabled, with policies keyed to the workspace of the signed-in user. A query for another workspace's rows returns nothing — not because the application filtered it out, but because the database refused.

This is verified by an automated suite that opens a genuine authenticated session as one workspace and tries to read and write another's records. Those attempts must fail, and the workspace must still see its own data, for the suite to pass.

The interface shows a specialist as working only when a real pipeline run is executing. That claim is only as trustworthy as the ability to write the record behind it, so customers hold no write permission on the activity log or the runtime record at all.

Those tables are written exclusively by server-side code holding a privileged key that never reaches the browser, and by database triggers. Even then, the server establishes who you are and which workspace you belong to using your ordinary session first, and takes the workspace from that verified session rather than from whatever the request claimed.

The automated suite includes an attempt to fabricate a convincing “work started” record from a normal signed-in session. It must be rejected.

Sign-in is handled by Supabase Auth. Passwords are hashed by the provider; we never see or store them. Sessions are held in HTTP-only cookies that browser scripts cannot read.

While AskRITZ is pre-launch there is an additional access gate in front of the product. It stores a keyed signature rather than a simple flag, so it cannot be forged by editing a cookie, and it compares in constant time so that response timing reveals nothing. It sits in front of real authentication and does not replace it.

All traffic is served over HTTPS. Data is stored in managed Postgres with encryption at rest and access restricted to the application's own service credentials. Those credentials are held as server environment variables and are never included in anything sent to a browser.

AskRITZ is pre-launch. These are known and planned, and are listed because a security page that lists only strengths is not informative:

• No multi-factor authentication. Email and password only, for now.
• No session management interface. You cannot yet review or revoke active sessions on other devices.
• No self-service export or deletion. Both are handled manually on request.
• No independent security audit or penetration test. The verification described above is our own automated testing, not a third-party assessment.
• No formal certification. We do not hold SOC 2, ISO 27001 or equivalent, and we will not imply otherwise.

Producing work requires sending the relevant parts of your business context to Anthropic. Only what that piece of work needs is sent. Your context is not used to train third-party models. See Privacy for the full picture.

If you find a security problem, email hello@askritz.aiwith enough detail to reproduce it. We will acknowledge within three working days and keep you updated until it is resolved. Please give us a reasonable chance to fix it before disclosing it publicly. We will not pursue anyone who reports a genuine issue in good faith and does not access or alter other customers' data.