Trust & Security
A single-page reference for studio CTOs and security teams evaluating Spinative. Covers where data lives, who can access it, how it's protected, and what to expect from us during an incident. Last updated: 2026-05-16. Material changes are versioned in our public GitHub repo and announced via in-app notification + email to the workspace owner.
TL;DR
- Data residency: project data is stored in the EU (Supabase region
eu-north-1/ Stockholm). One region today; SOC2-driven multi-region splits are on the roadmap. - Encryption: TLS 1.2+ in transit; AES-256 at rest (Supabase default + Vercel managed). Backups inherit the same encryption.
- Multi-tenancy isolation: every read/write goes through a server-side authorization gate (
assertProjectAccess/assertWorkspaceAccessBySlug). Row-Level Security is enabled on every table; anon + authenticated DB roles have been explicitly revoked. - No AI training on your data: we use OpenAI's API with the standard "no training" terms. Prompts and outputs aren't fed back into model training.
- Right to deletion + export: workspace owners can export every project as a single payload and request full deletion via support — fulfilled within 30 days.
- Security contact:
security@spinative.com. Responsible disclosure welcomed.
Where your data lives
| Category | Storage | Region |
|---|---|---|
| Project payloads, snapshots, audit log | Supabase Postgres | EU — eu-north-1 (Stockholm) |
| Uploaded + AI-generated images | Supabase Storage | EU — eu-north-1 |
| Marketing renders, exports | Supabase Storage (private buckets) | EU — eu-north-1 |
| Authentication identities | Clerk Cloud | Global (Clerk's own infra) |
| Subscriptions, payments | Stripe | Global (Stripe's own infra) |
| Function execution + edge CDN | Vercel | Global (closest edge) |
| Error telemetry (optional) | Sentry (planned) | Configurable (EU/US) |
Vercel serverless functions are stateless — they hold no persistent data. The only stateful systems are Supabase, Clerk, and Stripe.
We will accept reasonable data-residency requests from enterprise customers (e.g., a US-only deployment) by spinning up a dedicated environment. Pricing on request.
Encryption
| Channel | Standard |
|---|---|
| Browser ↔ Spinative | TLS 1.2+, HSTS preload enabled, 1-year HSTS max-age |
| Spinative ↔ Supabase | TLS 1.2+ |
| Spinative ↔ Clerk / Stripe / OpenAI | TLS 1.2+ |
| Postgres data at rest | AES-256 (Supabase default) |
| Storage objects at rest | AES-256 (Supabase default) |
| Backups | AES-256 (Supabase default) |
API keys, webhook secrets, and database credentials live in Vercel environment variables and are never persisted to the database or logged to client/server console.
Access controls
Application layer
- Server-side gates: every server action and API route runs
assertProjectAccess(userId, projectId)orassertWorkspaceAccessBySlug(userId, slug, requiredRole)before touching data. The check resolves the user's role in the studio (owner/admin/finance/member) and returns 404 on missing access — never leaks the project's existence to a non-member. - Public preview routes (
/p/<projectId>?token=...): scoped by a 256-bit random share token (24 bytes, base64url). Tokens carry only arolefield (reviewerorpublic_view); they don't grant write access to project content beyond comments (and only for thereviewerrole). Token TTL defaults to 30 days, capped at 365. - Webhook signature verification: Clerk uses
svixsignatures; Stripe uses its native HMAC signature. Webhooks reject requests without a valid signature.
Database layer
- Row-Level Security is enabled on every table in the
publicschema. TheanonandauthenticatedPostgres roles have been explicitly revoked from all tables, sequences, and functions inpublic. An event trigger (rls_auto_enable) auto-enables RLS on any future table to prevent regressions. - Application access uses the service role (server-side only). The service role bypasses RLS by design — the application-layer gates above are the authorization boundary. Service-role credentials are never exposed to the client.
Editor iframe
- The editor loads in an iframe under the same origin (
spinative.com/editor/spinative.html). X-Frame-Options: SAMEORIGINblocks third-party framing.postMessagelisteners verifyevent.origin === window.location.origin(v227+) so a malicious popup can't inject project state into a logged-in session.
Multi-tenant isolation
- Studios are isolated by the
studios.idUUID. A user is only a member of studios listed instudio_members. - Studio-aware reads / writes filter on
studios.deleted_at IS NULLso a deleted studio's data is no longer visible (with a 30-day grace window before background hard-purge). - The
user.createdClerk webhook cross-checks the invited studio_id against our own audit log ofmember.invitedevents before granting membership — Clerk metadata alone is not authoritative.
Sub-processors
Full list at /legal/sub-processors. Summary:
| Sub-processor | Purpose | Data |
|---|---|---|
| Vercel | Hosting + edge CDN | Function logs, request metadata |
| Supabase | Database + Storage + Auth (Postgres role) | Project payloads, assets, audit log |
| Clerk | Authentication + user identity | Email, name, avatar, organization membership |
| Stripe | Subscription + payment processing | Billing email, payment method (tokenised) |
| OpenAI | Image generation (gpt-image-1 / gpt-image-2) + AI Producer chat (gpt-4o-mini) | Asset prompts, project context, chat history |
| Resend | Transactional email | Notification emails |
| Upstash (Redis) | Rate-limiting counters | User IDs + endpoint hashes (no content) |
| Sentry (optional) | Error telemetry | Stack traces, breadcrumbs (PII scrubbed) |
We notify the studio owner via email + in-app announcement at least 30 days before adding any new sub-processor.
AI provider terms
- OpenAI: every AI feature on Spinative runs through the OpenAI API under the standard "Business Terms" — image generation (
gpt-image-1/gpt-image-2), the AI Producer chat (gpt-4o-mini), vision describe (typography / reference analysis). Prompts and outputs are not used to train OpenAI models. OpenAI retains data for up to 30 days for abuse monitoring, then deletes. OpenAI's enterprise privacy commitments. - We do not use any AI feature with consumer-grade ToS that train on customer data. If we add a new model or provider (e.g. an Anthropic chat experiment, Runway video), this page is updated and a sub-processor announcement is sent before the model goes live.
Backups & retention
- Backups: Supabase Pro tier provides daily backups with 7-day rolling retention. Enterprise tier (which we move to on signup of our first enterprise customer) provides 14-day PITR.
- Project snapshots: every 15 minutes, the editor takes an automatic snapshot of the active project payload. Manual snapshots are unlimited. Both persist in
project_snapshotsand survive accidental edits. - Soft-delete: deleting a studio via the Clerk dashboard flips
studios.deleted_atinstead of cascading a hard delete. The studio's projects, assets, and audit log remain recoverable for 30 days, after which a background sweep performs the hard purge. - Deletion on request: account / workspace deletion fulfilled within 30 days. Backups containing deleted data are aged out within the backup retention window above.
Authentication
- Clerk-managed identities. Email + password, OAuth (Google, Microsoft, GitHub), and magic-link supported out of the box.
- 2FA: TOTP supported via Clerk; enforceable per-studio on Studio + Enterprise plans.
- SSO (SAML / OIDC): supported for Enterprise plans via Clerk's SSO connection.
- Session management: Clerk-managed session tokens; configurable session length and refresh policy per environment.
- Webhook secrets (Clerk + Stripe): rotated independently; never persisted to the database.
Data portability
- Project export: from the editor, "Export" produces a single JSON payload of every layer, asset reference, and metadata field — sufficient to reconstruct the project in another tool. Workspace-level bulk export (all projects in one zip) is on the roadmap (Q3 2026).
- Audit log export: studio admins can pull the
studio_audit_logtable as CSV via support; self-serve export is planned. - Asset download: AI-generated and uploaded assets remain available as direct URLs; users can right-click → Save or download in bulk via the Export menu.
Security operations
| Practice | Status |
|---|---|
| Per-user rate limits on AI endpoints | ✅ Live (Upstash backend, in-memory fallback) |
| Server-side audit log for destructive mutations | ✅ Live (member changes, project deletes, settings updates, share-link create/revoke, plan changes) |
| Content Security Policy | ✅ Report-only today; enforcement after 30-day reporting window |
| Strict transport (HSTS preload) | ✅ Live |
| X-Frame-Options + frame-ancestors | ✅ Live |
| Error monitoring (Sentry) | ✅ Configured; activates when DSN provided |
| Health probes for uptime monitoring | ✅ /api/health + token-gated /api/health/deep |
| Penetration test | Q4 2026 (planned) |
| SOC 2 Type I | Q1 2027 (planned) |
| SOC 2 Type II | Q3 2027 (planned) |
| ISO 27001 | Not committed |
Incident response
- We commit to acknowledging a confirmed security incident affecting customer data within 24 hours of discovery and disclosing details + remediation steps within 72 hours.
- Acknowledgement + disclosure go to the workspace owner email registered with Clerk and via an in-app banner.
- Post-incident reports are published at
/legal/incidents(planned) and stay available indefinitely.
Reporting a vulnerability
- Email
security@spinative.com. We respond within 2 business days. - For high-severity issues (RCE, auth bypass, mass PII exposure), please include a working PoC and a suggested CVSS score.
- We don't currently run a bounty program. We thank coordinated disclosure in the post-fix changelog with the researcher's name + a link of their choice (or remain anonymous if preferred).
- In scope:
spinative.com,www.spinative.com, our public APIs, our Clerk-hosted auth pages. - Out of scope: third-party services we depend on (please report directly to Vercel / Supabase / Clerk / Stripe / OpenAI), the AI Producer's generated text content (we cannot guarantee output safety beyond what the upstream provider commits to).
Compliance posture
Spinative is a EU-domiciled service operated by Ediciones Candel SL (España). We act as a data processor for project content uploaded by your studio members; you remain the data controller.
| Framework | Status |
|---|---|
| GDPR | Operating model is GDPR-aligned. DPA available at /legal/dpa — counter-sign on request. |
| UK GDPR | Same posture as GDPR; UK customers covered by the same DPA. |
| CCPA / CPRA | We respond to verifiable consumer requests. Email privacy@spinative.com. |
| HIPAA | Spinative is not HIPAA-compliant. Don't upload PHI. |
| PCI DSS | Card data is handled exclusively by Stripe (PCI Level 1). We never see card numbers. |
| SOC 2 | Type I planned Q1 2027. See "Security operations" above for the interim. |
If your procurement process requires our SIG-Lite, custom security questionnaire, or vendor assessment, email security@spinative.com with the document — we typically turn around in 5 business days.
Contact
| Topic | |
|---|---|
| Security disclosure | security@spinative.com |
| Privacy / DSAR | privacy@spinative.com |
| Procurement / vendor assessment | security@spinative.com |
| General support | support@spinative.com |
| DPA / contract sign-off | legal@spinative.com |
PGP key for security@spinative.com available on request.
This document is a public-facing summary. It is not a contract; the binding agreement is the Terms of Service and Data Processing Agreement linked above.
