Security Policy

• Workspace content is stored in Supabase (Postgres + object storage). Tenant isolation is enforced by row-level security on every workspace table and by owner-prefixed paths in object storage.
• Server-side data mutations re-check project ownership before touching artifacts, so a tampered or stale identifier returns a friendly 404 rather than a server error.
• Cross-tenant requests are blocked at the database layer (RLS) and again at the application layer (explicit owner_id checks in server actions).
• Generated artifacts are written to short-lived signed URLs (60-second expiry) and never exposed via a long-lived public link.

• Sign-in is delivered through Supabase Auth using either magic links (single-use OTP tokens) or OAuth with Google and GitHub.
• Magic-link requests are rate-limited at our edge per IP and per email to defend against email-cost and reputation abuse.
• Session cookies are HTTP-only, Secure, and SameSite=Lax. Sign-out clears the session server-side via a POST-only route to prevent CSRF via image tags.
• Service-role credentials are scoped to server-only contexts and never exposed to the browser.

• All traffic to the production domain is served over HTTPS (TLS 1.2+) with HSTS, including subdomain preload.
• Strict security response headers are applied to every response: Content-Security-Policy with a per-request nonce, frame-ancestors 'none', Referrer-Policy strict-origin-when-cross-origin, Permissions-Policy minimizations, X-Content-Type-Options nosniff, and Cross-Origin-Opener-Policy same-origin.
• URL ingestion enforces an SSRF-resistant fetcher: hostnames are DNS-resolved and every returned address is checked against private and reserved ranges; redirects are followed manually and re-validated at each hop.
• Outbound fetches stream and size-cap responses to defend against zip-bomb-style payloads.

• Database and object storage are encrypted at rest by Supabase using AES-256.
• Backups follow Supabase’s managed schedule and are encrypted at rest.
• Secrets are provided to the runtime via Vercel environment variables; we do not commit credentials to source control.
• Customer-side encryption keys are not currently supported. Highly sensitive specs should be sanitized of secrets before upload.

• Server-side errors are forwarded to Sentry with PII scrubbing applied at ingestion. Application logs are retained for at most 90 days.
• Rate-limit counters and abuse signals are stored in Upstash Redis with short TTLs.
• Suspected security incidents are triaged, contained, and remediated as quickly as the severity warrants. Customers materially affected by a confirmed incident will be notified without undue delay and given the information they need to assess the impact.
• Post-incident, we document the root cause and the corrective action and apply the change to prevent recurrence.

• Dependencies are tracked through the npm lockfile and reviewed regularly for known advisories.
• Production deploys go through automated typecheck, lint, and build verification before they reach users.
• Security-relevant changes to authentication, storage, or network boundaries are reviewed with elevated scrutiny.

• Use a unique, strong password on the email account or OAuth provider used to sign in to Ajolla.
• Treat any spec that contained a live credential as compromised and rotate the credential immediately.
• Apply human review on every generated SDK, docs site, and MCP server before deploying it in production or exposing it to autonomous agents.
• Apply least-privilege when configuring generated MCP servers; do not enable destructive or admin tools by default.

• Email security@ajolla.dev with the affected route or workflow, reproduction steps, expected and observed behavior, and any logs or screenshots that help us assess impact.
• Acknowledgement target: within 3 business days. Initial triage: within 7 business days. Fix timeline depends on severity; critical issues are prioritized over feature work.
• Please do not publicly disclose a vulnerability until it has been investigated and remediated. We will credit researchers who follow this process in the resolution notice if they wish.

• In scope: ajolla.dev and www.ajolla.dev application surfaces, server actions, authentication flows, ingestion endpoints, and the safety classification logic of generated MCP servers.
• Out of scope (without an exception agreed in writing): denial-of-service testing, automated scanner output without a working proof-of-concept, social-engineering attacks against Ajolla staff, and findings in third-party services that we operate via sub-processor (Supabase, Vercel, Upstash, Sentry, Resend, Cloudflare) — please report those to the relevant vendor.

For security disclosures, email security@ajolla.dev. For general security questions, you may also use hello@ajolla.dev.