Data encryption
- Encryption at rest. Customer data lives in Supabase Postgres, which encrypts the database volume at rest using AES-256.
- Encryption in transit. TLS 1.3 is enforced on every public endpoint (the marketing site, the app, and the API). Older TLS versions are rejected at the Cloudflare edge.
- Backups. Automated daily backups via Supabase, encrypted at rest with the same key envelope as the live database.
Authentication
- Provider. Supabase Auth (GoTrue), running against our Supabase project. Passwords are hashed with bcrypt before storage; no password ever lands in plain text.
- Password rules. Minimum 8 characters, must contain at least one letter and one number. Common-password protection via the Have I Been Pwned k-anonymity check is enabled.
- Sessions. Access tokens are 1-hour JWTs. Refresh tokens rotate on use — a refresh token can be redeemed exactly once, which limits the blast radius of a leaked token.
- OAuth on data sources. Every third-party integration (AppsFlyer, Google Ads, Meta Ads, RevenueCat, Stripe, Iyzico) connects via OAuth. We never see, store, or log your source-account passwords.
Authorization
- Row Level Security on every table. Supabase RLS is enabled across the schema. There is no table where an authenticated user can read or write a row that doesn't belong to their organization.
- Organization-scoped policies. RLS policies match against `organization_id` on every read and every write. A user's JWT carries their `organization_id`; the database enforces it.
- No service-role bypass from end-user JWTs. The service-role key is held only by trusted server-side workers, never exposed to a browser or to a user-issued JWT. End-user requests cannot escalate to service-role access.
API keys and secrets
- Storage. All third-party API keys (Anthropic, Google Ads, Meta Ads, AppsFlyer, RevenueCat, Stripe, Iyzico) are stored in environment variables — secret bindings in Cloudflare Workers for the marketing surface and in our backend secret store for the app.
- No logs. API keys are never written to application logs, never serialised into error messages, never embedded in URLs.
- Rotation. Keys are rotated periodically. Any suspected exposure triggers immediate rotation outside the normal cycle.
Data residency
Customer data is stored in Supabase's EU region by default (Frankfurt). For PDPL-sensitive customers (KSA, UAE) who require in-region storage, we can configure a Supabase project in the appropriate region on request — this is part of the Enterprise tier onboarding.
We do not move customer data between regions without an explicit data-processing-agreement addendum that names the new region.
Audit logging
Every action taken inside Madar that touches customer data is recorded in an audit log. Three tables carry the trail:
- `agent_activities` — every action taken by one of the AI agents (Oracle, Forge, Sentinel, Curator, Scout, Drafter): user_id, organization_id, agent name, action, parameters, result, timestamp.
- `audits` — every audit run, who requested it, what data sources were ingested, what findings were produced, when.
- `briefings` — every weekly and monthly briefing generated, who received it, when it was delivered.
These tables can be provided to your organization for compliance review on request. We do not delete audit records on customer request — they are retained for the lifetime of the account plus the legally required retention window.
Vulnerability disclosure
Found something? Email security@madarai.co with as much detail as you can share — affected URL, reproduction steps, the impact you observed.
We acknowledge every report within 48 hours and follow up with a remediation timeline once we have triaged the issue. We do not currently offer monetary rewards, but we credit researchers who consent to being named in our security page once their report is fixed.
What we don't do yet
Security claims are only useful if they are honest about what is missing. Here is the explicit list:
- No SOC 2 certification. We are working toward SOC 2 Type II with an external auditor; we do not claim to be certified until the report is signed. See /trust for the current status.
- No third-party penetration testing. Planned for Q3 2026, once the multi-agent system is stable enough that a pen-test would test the real attack surface rather than a moving target.
- No bug bounty program. Planned post-50 customers, when we have enough surface area and enough revenue to fund payouts that researchers will take seriously. Until then, vulnerability disclosure via security@madarai.co is the only path.
- No formal ISMS or ISO 27001 alignment. Not on the roadmap before SOC 2. We do not claim any certification we have not earned.
If any of these gaps are a blocker for your security review, talk to us — we can usually share more detail under NDA than what is published here.
