Security

This page describes the security practices behind Spinrun, operated by BirdAI S.R.L. from Romania. It is written for the person filling in a vendor questionnaire, so it names systems and regions rather than principles.

Everything here is a description of what the Service does today. Where a measure is contractual — breach notice, deletion, transfer safeguards — the Data Processing Agreement is the binding text and this page is the plain-language version of it.

1. 01Scope

   The practices below cover the marketing site, the application, the gateway your agents call, and the object storage behind artifacts and large tool results. They do not cover the third-party applications you connect, which run under their own security programmes and their own terms.

   We build to SOC 2 and ISO 27001-grade practices — audit-friendly logging, retention controls, least-privilege defaults — but we do not hold either certification, and nothing on this page should be read as saying we do. Section 10 sets out what we do not claim.

2. 02Where your data lives

   Core data is held in Frankfurt, in the European Union. Not everything is region-pinned, and the table says which is which rather than rounding up to "all in the EU".

   System

   Location

   Database and authentication (Supabase)

   AWS eu-central-1, Frankfurt, Germany. Account data, workspace membership, connection records, activity logs and Brain embeddings.

   Application and gateway functions (Vercel)

   Frankfurt, Germany (Vercel region fra1), beside the database. Requests are routed through Vercel's global network to reach that region; the function that reads and writes your data runs there.

   Agent code execution (Vercel Sandbox)

   Not region-pinned. On plans where sandboxes are enabled, agent-authored code runs wherever Vercel places the sandbox; the provider offers no region setting for it.

   Object storage (Cloudflare R2)

   Jurisdiction not pinned. The bucket is private and every read passes through an authenticated route, but its physical location is chosen by Cloudflare.

   Analytics (PostHog)

   PostHog's European instance. Nothing measured about your visit or your use of the product leaves the EEA.

   Subprocessors

3. 03Encryption and the credential vault

   Traffic is encrypted in transit throughout, and at rest in the primary data stores.

   The OAuth tokens and API keys you grant when you connect an application are held in an encrypted vault, never in configuration files or environment variables. The vault is read only when an agent's call needs the credential, and what you can see in the product is the scopes a credential carries and when it was last used — never the secret itself.

4. 04Tenant isolation and access control

   Every workspace is isolated at the database row level, so one workspace's queries cannot reach another's rows. This is enforced by the database rather than by application code that could forget to filter.

   Inside a workspace, an owner decides who is a member and which connections each team can use. Anyone with access to a connection can direct an agent through it, within the permission rules set for that application — so membership is the control, and removing someone removes their reach.

   On our side, access to production systems is least-privilege and limited to the people who operate the Service. Everyone we authorise to process personal data is under a written confidentiality obligation.

5. 05Gateway policy enforcement

   Read, write and destructive rules are enforced at the gateway, before a call reaches the connected application — in code rather than in a prompt, which an agent can talk itself out of. Each tool is classified from the action it names, and a rule per application decides what an agent may do. Treat the classifier as a broad guardrail rather than a certified inventory: anything it cannot place is treated as a write.

   Destructive actions in the playground wait for a person to approve them. Every gateway call — which tool ran, the action, the outcome, how long it took — is written to the activity log, with payload capture under your control.

6. 06Agent-authored content and sandboxes

   Content an agent writes — an artifact, a page, a generated document — is served sandboxed, from an opaque origin, with no session cookie attached. The routes that serve it are deliberately excluded from the middleware that would otherwise set one, so a document an agent produced cannot become a same-origin page with access to your session.

   Object storage is private. No pre-signed URL is ever minted; every read goes through an authenticated route.

   Agent-authored code runs in an isolated sandbox with short-lived credentials, on plans where sandboxes are enabled. The keys issued to a sandbox are deleted one day after they expire.

7. 07Retention and deletion

   Activity logs and the payloads inside them have separate windows, both set by your plan, and a job at 04:00 UTC each night scrubs payloads past their window and deletes log rows past theirs. The job authenticates with a shared secret and refuses to run without it, so it fails closed rather than open.

   Offloaded tool results are deleted 24 hours after they are stored, on a fixed timer that no plan extends. On termination of the agreement we delete your personal data within 30 days, except where EU or Member State law requires us to keep it, and connected authorisations are revoked at the same time. Backups age out through ordinary rotation rather than being deleted individually.

   Retention windows, by plan

8. 08International transfers

   Some subprocessors operate outside the European Economic Area. Where data leaves the EEA it is transferred under the Standard Contractual Clauses adopted by the European Commission in Decision (EU) 2021/914, with technical measures — encryption in transit and at rest, access control — behind them. Write to us if you want the detail for a particular provider.

   Data Processing Agreement

9. 09Reporting a vulnerability, and breach notice

   If you find a security problem in Spinrun, write to legal@spinrun.ai with enough detail to reproduce it. We will acknowledge the report, keep you informed while we fix it, and not take action against good-faith research that stays within the scope of your own account and does not disrupt other customers. Running security testing against us beyond that needs written permission first.

   If a personal data breach affects data we process for you, we notify you without undue delay, and in any event within 72 hours of becoming aware of it, with what we know: the nature of the breach, the categories and approximate number of data subjects and records involved where we can establish them, the likely consequences, and what we have done or propose to do about it.

10. 10What we do not claim

    We do not hold a SOC 2 attestation or an ISO 27001 certificate. The practices above are ours; the audit is not, yet. Where a customer's DPA audit right is exercised, we make available the information necessary to demonstrate compliance with Article 28 GDPR, as the DPA describes.

    We do not promise that every byte stays in the EU. Core data does — the database and authentication are in Frankfurt — but the object store and the application functions are not pinned to a region, and this page says so rather than implying otherwise.

    We do not offer a bring-your-own-cloud or single-tenant deployment as a standard product. If your procurement needs one, write to legal@spinrun.ai and we will tell you what is possible.

    Data Processing AgreementPrivacy Policy