Security

How pomela protects your data, your apps, and your end‑users.

Last updated 2026‑05‑27 · Transparency about the engineering choices that defend the platform.

01 · Transport

Every byte between you and pomela travels over TLS 1.3. We send Strict-Transport-Security: max-age=63072000; includeSubDomains; preload. The domain is submitted to the HSTS preload list, so even a first visit from a clean browser is encrypted. Mixed‑content requests are blocked by an upgrade-insecure-requests directive.

02 · Identity

Authentication is handled by Clerk. Magic links, Sign in with Apple, Sign in with Google, and Passkeys (WebAuthn) are all supported. We do not store passwords; we never see them. JWTs are RS256‑signed by Clerk and verified against their JWKS in our edge workers using Web Crypto. Sessions auto‑rotate; absolute lifetime caps prevent indefinite session theft.

03 · Data isolation

Data lives in Supabase Postgres with Row‑Level Security on every table. Policies follow four golden rules:

• Every USING clause wraps function calls in (select …) for initPlan caching at scale.
• Every column referenced in a policy is indexed.
• Every policy explicitly specifies TO authenticated or TO anon.
• Client queries add explicit .eq() filters in addition to RLS, so the planner can use indexes.

End‑user data inside a Maya‑built app is double‑isolated: the JWT carries (app_id, end_user_id) claims, and every policy on app_state enforces both.

04 · Secrets

No secrets in source. Every secret is held by Cloudflare Worker Secret Storage. The internal worker‑to‑worker shared secret is required in production — both callers refuse to operate without it. Founder bypass credentials are read from Worker secrets only; without them, the bypass paths fail closed.

05 · Code integrity

The platform ships strict response headers everywhere:

• Content-Security-Policy with no unsafe-eval on API responses; allow‑listed origins only on the Pages host.
• X-Frame-Options: DENY + frame-ancestors 'none' — clickjacking blocked.
• Permissions-Policy blocks every powerful capability by default and grants self only where the runtime SDK explicitly requires it.
• X-Content-Type-Options: nosniff — MIME‑type confusion blocked.
• Cross-Origin-Opener-Policy: same-origin — Spectre‑class isolation.

Generated apps run in their own sandboxed iframes with the strictest allowlist that still lets the runtime work, and only when the origin truly differs from the creator.

06 · Supply chain

Dependencies are pinned. The runtime SDK has zero runtime npm dependencies (only Preact + workspace packages). Auth verification on the worker side uses Web Crypto API directly — no @clerk/backend, no svix, no jose — keeping the supply‑chain attack surface minimal.

07 · Audit & monitoring

Spend caps on the Anthropic API limit blast radius. Every admin action is logged. PostHog provides product analytics from the EU. Sentry catches runtime errors with PII scrubbing on. Anomaly heuristics flag accounts whose generation rate spikes 100× baseline within an hour.

08 · Incident response

A documented runbook covers triage, communication, and post‑mortem. Status updates are posted to status.pomela.app for any production incident affecting > 1% of users. Postmortems are published within 14 days of resolution and never blame individuals.

09 · Responsible disclosure

Found a vulnerability? Please email [email protected]. We acknowledge reports within 48 hours and aim to remediate critical issues within 7 days. We do not pursue researchers who:

• Stay within the scope of public surfaces and their own accounts.
• Don't access or modify other users' data.
• Give us reasonable time to fix before disclosure.

A formal bug bounty program is in planning. Until then, we offer public acknowledgement and the deepest gratitude to anyone who helps us stay honest.