Security

Watari processes customer support data and source code on behalf of our customers. The following describes the technical and organisational measures we use to protect that data. For contractual security commitments, see Exhibit C of our Data Processing Agreement.

Encryption

• In transit: TLS 1.3 minimum on every customer-facing endpoint. HSTS enabled with a 2-year max-age,includeSubDomains, preload-eligible. Inter-service calls between Watari and its subprocessors use HTTPS exclusively.
• At rest: sensitive secrets (OAuth access tokens, refresh tokens, per-tenant webhook signing secrets, integration credentials) are encrypted with AES-256-GCM before being written to the database. The encryption key (INTEGRATION_SECRET_KEY) is held in a Vercel Sensitive Environment Variable and is rotated on a defined cadence.
• Storage layer: all customer data is stored on Supabase managed Postgres, with disk-level AES-256 encryption provided by the underlying AWS infrastructure (United States, us-east-1).

Tenant isolation

Every customer-data table carries an organization_id column and a Postgres row-level security (RLS) policy that restricts SELECT, INSERT, UPDATE, and DELETE to rows owned by the authenticated organisation. Every new migration that introduces a customer-data table is required to ship with a paired RLS policy; we treat a missing policy as a release-blocking bug.

A service-role “admin” client that bypasses RLS is used for flows that intentionally cannot rely on the user-bound RLS client: OAuth callbacks that run before a session exists, background jobs (Inngest) operating on a pre-resolved organisation, and admin-gated server actions that have already validated the caller's organisation membership. Every admin-client call site is reviewable in the source repository.

Source code access & handling

Connecting a repository is the step customers scrutinise most, so here is exactly how Watari reaches your code and what happens to it.

How we access your code

• You scope it, repository by repository. Access is granted through a GitHub Appyou install, not through a personal token on your account. During installation GitHub asks you to choose exactly which repositories Watari may see. Watari cannot read repositories you do not select. The authoritative permission set is shown on GitHub's own installation screen.
• Least-privilege permissions.The App requests only what the product needs: read & write to repository contents(to read your code and to push the branch that backs a draft pull request) and read & write to pull requests. It never auto-merges — every pull request is a draft a human on your team reviews, edits, and merges (see AI Disclosures §6).
• We never store your GitHub credentials. Watari persists only the numeric installation ID. Access tokens are minted on demand, are valid for one hour, are refreshed automatically by GitHub, and are never written to our database or passed between pipeline steps.
• Revocation is yours and immediate.Remove the App at any time from your GitHub organization settings → Installed GitHub Apps, without involving Watari. Because tokens are ephemeral, no standing key to your code survives revocation.

What happens to your code

• Indexed in memory, never written to disk. When a repository is indexed, it is streamed into memory as a compressed archive and parsed there. The archive is not written to disk on our servers.
• We retain a mathematical index, not your source. What we store is vector embeddingsplus structure (file paths, line ranges, symbol names) — not the text of your code. When the system needs the actual source — to map a bug or draft a fix — it fetches the relevant lines from GitHub at the exact indexed commit and discards them after use. The index lives in the same organization_id-scoped, row-level-security-isolated database described above, encrypted at rest (disk-level AES-256, United States).
• Pull-request drafting reads from GitHub live. When Watari drafts or validates a fix, it fetches the relevant files fresh from GitHub at that moment rather than from a stored copy. Validation runs type-checkers only (for example tsc, pyright, go build) in an isolated sandbox — Watari does not execute your application.
• Root-cause analyses never quote your code.The customer-facing RCA is generated from the merged change's diff and commit messages; it contains no source code, file paths, or function names.
• Deletion is real. Remove a repository or your organization and its indexed data is deleted (enforced by database cascade). Provider-side AI handling, retention, and our no-training commitment are detailed in AI Disclosures; the third parties involved are listed in Subprocessors.

Authentication

• Customer authentication runs on Supabase Auth: email + password with strong password requirements, plus OAuth login with GitHub and Google.
• Sessions are protected with HTTP-only, Secure, SameSite=Lax cookies.
• Server-side code uses getUser() (not getSession()) to verify the session against the Supabase auth server on every request — defending against forged cookies.
• Webhook endpoints verify HMAC signatures before any side effects. Zendesk uses a per-tenant signing secret auto-provisioned during the OAuth callback and stored encrypted in the integration row. Intercom uses the app-wide signing secret (Intercom does not provide per-install secrets). GitHub and Razorpay use app-wide secrets per their respective conventions.

Personnel access & audit

Watari personnel access to production systems is least- privilege and audit-logged. Administrative actions on the database are restricted to a small group of named engineers and require single sign-on. Customer-content access by Watari personnel is prohibited except as described in §6.2 below.

6. Operational controls

6.1 Monitoring & alerting

• Application logging via structured pino logger.
• Error monitoring via Sentry with PII scrubbing before transmission.
• Uptime and synthetic monitoring via Better Stack, with on-call alerting.

6.2 Customer-content access

Watari personnel are prohibited from viewing Customer Content, except when (a) instructed by the Customer; (b) necessary to resolve a support issue the Customer has raised; (c) necessary for security, Service integrity, or legal purposes (incident response, abuse investigation, lawful process).

6.3 Backups

Automated daily backups with a rolling 30-day retention window. Backups are encrypted at rest and stored in the same region as the primary database (United States). Periodic restore drills validate recoverability.

6.4 Change management

Production deployments run through Vercel and require a passing CI pipeline (lint, type-check, unit and integration tests). Database migrations are reviewed and applied via the Supabase MCP migrate command; destructive migrations require explicit approval.

7. Incident response

We maintain a documented incident-response runbook covering detection, triage, containment, communication, eradication, and post-incident review. For confirmed personal data breaches affecting customer data, we notify the affected Customer (Controller) within 72 hours of becoming aware of the breach, with the information required by GDPR Article 33(3) where applicable. See DPA §8 for the full commitment.

8. Compliance posture

• SOC 2 Type II:in progress — observation window engaged with a Vanta-supported audit programme; the certification target date will be published here once locked.
• GDPR: in scope as Processor for EEA Customer Personal Data, with SCC Module 2/3 transfers and supplementary measures.
• UK GDPR + DPA 2018: in scope; UK Addendum to SCCs incorporated by reference for UK transfers.
• DPDP Act 2023 (India): in scope as Data Fiduciary for direct collection and Data Processor for Customer Content; Grievance Officer published at Privacy §9.
• HIPAA: the Service is not configured for handling Protected Health Information and we do not sign Business Associate Agreements.

10. Subprocessors & supply chain

The third parties Watari relies on to operate the Service are listed at watari.ai/legal/subprocessors. We provide 30 days' advance notice of new or replaced subprocessors via email subscription; see DPA §5.

11. Contact

For security questions, vulnerability reports, or audit requests, email security@watari.ai.