Security & Trust

1. Architecture & tenant isolation

• Strict multi-tenancy. Every workspace has a stable tenant_idthat is attached to the user's session at authentication time and propagated through every request.
• Two layers of isolation. The application layer requires tenant_idon every database query; PostgreSQL Row-Level Security (RLS) on Supabase enforces the same boundary as a defence in depth.
• Layered architecture (router → service → integration → core). Business logic cannot bypass authorisation by reaching directly into the database or third-party clients.

2. Authentication & access control

• Identity is provided by Supabase Auth. Passwords are hashed with bcrypt; sessions are signed JWTs.
• Role-based access inside each workspace (owner, dispatcher, accountant, viewer).
• Browser extensions and partner integrations authenticate with a separate, revocable API key (X-KARG-Key).
• Webhook endpoints (Telegram, QStash, HMRC PPNS) validate provider signatures before any side effect.
• Administrative access to production is restricted to a small, named group with hardware-backed MFA.

3. Encryption

• In transit. TLS 1.2+ on every public endpoint, with HSTS preload-eligible configuration.
• At rest. Database, file storage and backups are encrypted by the hosting providers (Supabase, Vercel, Upstash).
• Sensitive integration secrets. Long-lived OAuth tokens (for example HMRC) and connector credentials are encrypted with an application-level key before being stored, on top of the at-rest encryption.

4. Hosting & data residency

Production data lives in the European Union. We host on Supabase (PostgreSQL, authentication, file storage), Vercel (frontend + API), and Upstash (Redis cache and QStash scheduled jobs). The complete list of sub-processors is at karg.to/sub-processors. Where a sub-processor operates outside the EEA we rely on the EU Standard Contractual Clauses.

5. Application security practices

• Input validation on the backend with Pydantic (strict mode) and on the frontend with Zod before submission.
• Output is shaped through DTO schemas; we do not return raw database rows to clients.
• Security headers middleware (CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy) on every response.
• Diagnostic and debug endpoints are disabled in production.
• Errors carry a request ID; sensitive details (stack traces, secrets) are stripped before being returned to the client.
• Identifiers in logs are masked where they are not needed for operations.
• Secrets are read exclusively through pydantic-settings; never from os.environ at the call site.

6. Monitoring & incident response

• Application errors are captured in Sentry with tenant and request tags, scrubbed of secrets via a before_send hook.
• Audit logs record sensitive actions (login, role change, data export, integration connect/disconnect) for at least 12 months.
• We commit to notifying affected customers without undue delay and within 72 hours of becoming aware of a confirmed personal data breach, in line with Art. 33 GDPR.

7. Backups & disaster recovery

• Automatic daily database backups with point-in-time recovery, retained for 35 days.
• Backups are encrypted and inherit the same EU residency as the primary database.
• Restore procedures are exercised at least once per quarter.

8. Engineering practices

• All code changes go through code review and automated checks (type-checks, unit tests, security review for sensitive surfaces).
• Periodic security reviews of the codebase; the most recent internal review was completed on 22 April 2026.
• Dependencies are kept current; we monitor advisories for the libraries we ship.

9. Customer responsibilities

• Use unique, strong passwords and enable available second-factor methods.
• Grant the minimum role each user needs.
• Revoke API keys and integration tokens for users who leave your organisation.
• Review your audit log periodically.

10. Responsible disclosure

If you believe you have found a security vulnerability in KARG, please email security@karg.to. We acknowledge reports within 2 business days and aim to provide a remediation plan within 14 days for confirmed issues. Please do not exploit vulnerabilities beyond what is needed to prove them, do not access data that is not yours, and give us reasonable time to fix before public disclosure.

A machine-readable contact is published at /.well-known/security.txt per RFC 9116.

11. Roadmap

Items we are actively working towards: SOC 2 Type II, customer-facing audit log export, single sign-on for enterprise plans, and a public status page at status.karg.to.