Security
Treated like an engineering requirement.
Maritime, energy, and the businesses that serve them operate under rising cyber scrutiny. Here's what is actually in place today — no buzzwords, no overclaiming.
Read-only Google access
We request permission to read Search Console and Analytics data only. The OAuth scopes we use do not allow modifying or deleting anything in your Google account.
Credentials encrypted before storage
Refresh tokens are encrypted with AES-256-GCM at the application layer before they reach the database. The encryption key lives outside the database — a SQL leak alone does not yield usable tokens.
Tenant isolation at the database layer
Each client's rows are gated by database policy (RLS), not by application convention alone. Your metrics, content, and connected properties are visible only to your account and platform operators.
Sessions and server-side access control
Authentication uses Supabase Auth with sessions in httpOnly cookies — not browser localStorage. Admin vs client permissions are enforced in server components and server actions; hiding a nav link is cosmetic, not security.
Headers, validation, and public rate limits
Every response carries a strict Content-Security-Policy (nonce-based scripts), HSTS, and frame blocking. Public forms and the free audit tool are schema-validated and rate-limited per IP via distributed rate limiting (Upstash Redis). Invite-only accounts — no public sign-up.
Data stays in Singapore
Our database (Supabase) is hosted in Singapore and our compute functions are pinned to the Singapore region. Client data is stored in-country and core processing runs in-country — see the subprocessor list below for the exceptions.
Card details never touch our servers
Payments are processed entirely by Stripe, a PCI DSS Level 1 certified provider. We store only your subscription status and Stripe customer reference — never card numbers.
Operator and account hygiene
- Platform operator accounts require multi-factor authentication.
- Invited user passwords must be at least 12 characters and are checked against known breach lists (via Supabase Auth).
- Google OAuth callbacks verify a CSRF
statetoken before any token is stored. - AI generation receives topic briefs and metrics — never your Google refresh tokens, payment details, or other clients' data. Prompts are not used to train AI models: requests go to Anthropic (whose API does not train on customer data) via Vercel AI Gateway, which does not retain prompt contents.
- Found a vulnerability? Email hello@jarvia.io — we also publish security.txt. We'll acknowledge within 3 business days and won't pursue good-faith researchers.
- Singapore PDPA: we publish a privacy policy and will remove client data on request, including revoking Google access.
No system is perfectly secure. We design for containment: read-only Google access, encrypted credentials, tenant isolation, and server-side authorization so a single failure does not expose another client's data.
Subprocessors
These are the services that may process client data on our behalf, and what each one sees.
| Service | Purpose | Location |
|---|---|---|
| Vercel | Application hosting and compute | Singapore (functions) |
| Supabase | Database, authentication, encrypted credential storage | Singapore |
| Stripe | Payment processing (card data never reaches our servers) | Global (PCI DSS L1) |
| Anthropic (via Vercel AI Gateway) | AI content generation — receives topic briefs and metrics only | United States |
| Upstash | Distributed rate limiting (IP addresses only) | Global |
| Resend | Transactional email delivery | United States |
Want the full breakdown — scopes, storage, AI boundaries, and what happens when you disconnect? Read the article, or talk to us for a procurement review.