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.
• Workspace requests use row-level security and application ownership checks. Hosted module APIs use a server-only service-role client with explicit app-scoped queries; those privileged requests rely on application tenant checks rather than end-user RLS alone.
• Private artifact downloads use short-lived signed URLs (currently 60 or 120 seconds, depending on the download route). Documentation or endpoints that you publish are public by design.

• Sign-in uses Supabase Auth magic links. OAuth buttons are shown only for providers enabled on the deployment and in Supabase; Google and GitHub sign-in are not currently enabled in production.
• Magic-link requests are rate-limited at our edge per IP and per email to defend against email-cost and reputation abuse.
• Supabase session cookies are used by both the browser client and server rendering; they are not HTTP-only. Sign-out clears the session through a POST-only route.
• Service-role credentials are scoped to server-only contexts and never exposed to the browser.

• The production application is served over HTTPS and sends an HSTS header. Sending a preload directive is not proof that the domain is included in browser preload lists.
• 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.
• Beta backups do not currently carry an availability, retention, or recovery guarantee. A manual database snapshot is not a verified end-to-end recovery service. Database snapshots also do not contain Storage file bytes. Keep independent copies of your data.
• 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.

• Sentry captures configured error and performance diagnostics; Vercel provides hosting logs, and Wandamark records product and availability events. Provider retention and scrubbing settings are still being verified. We do not claim a universal 90-day deletion period or complete removal of personal data from every log.
• 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 — 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.