What happens to the code you show us.

The takeover scan works from the shape of a repository: file and directory layout, import and dependency edges, module boundaries, and the counts that fall out of them. That structural map is what gets analysed. The bodies of your functions are not sent to a language model.

The architecture pack is generated from what you tell us about the system in prose — the project description you write, not a dump of the repository.

This is the design we are building to, and the reason the scan is worth running on a client codebase you do not own outright. If any part of the product ever needs to send source to a model, it will say so at the point where you would be agreeing to it, not in a footnote here.

• Passwords are stored as bcrypt hashes at cost factor 12. Nobody here can read your password, including us.
• Your session lives in an httpOnly cookie, so no script on the page can read it. It expires after 7 days.
• You can see every active session — browser, approximate location, when it started — and revoke any of them from your settings.
• Sign-in, password reset, and verification endpoints are rate limited, and reset codes are encrypted at rest.
• Signing in with Google is optional; choosing it means we never handle a password for you at all.

Tenant separation is enforced in the database itself with row-level security, not only in application code. A query that forgets to filter by account returns nothing rather than someone else's project. That is deliberate: the class of bug that leaks one customer's data into another customer's screen is usually a missing WHERE clause, and we did not want to be one refactor away from it.

The waitlist table is the one unauthenticated write surface on the service, and it is locked down accordingly: the application may insert and read, but has no ability to update or delete rows. A second submission cannot overwrite the first, and the API cannot be talked into erasing what it collected.

If you bring your own model API key, it is encrypted with AES-GCM before it is stored, and decrypted only to make the call you asked for.

• All traffic is HTTPS, with certificates managed by our hosts. There is no plain-HTTP path into the API.
• The site runs on Vercel; the API and PostgreSQL database run on Railway.
• Secrets live in the host’s environment configuration, never in the repository.
• The database roles used at runtime hold the narrowest privileges each job needs — the email worker, for instance, cannot read your projects.

A security page that lists only strengths is a marketing page. As of today:

• No SOC 2, ISO 27001, or comparable audit. We are a small team in early access and will not pretend otherwise.
• No published penetration test.
• No formal bug bounty — but see below, because we still want the report.
• No signed DPA offered as standard yet. If your client needs one before you can run Spire on their code, write to us and we will work it out with you.

If you have found a vulnerability, email privacy@getspire.co with enough detail to reproduce it. We aim to acknowledge within 2 business days and to tell you what we did about it.

Please do not run automated scanners against the production service, access data that is not yours, or degrade it for other people while testing. Report it in good faith and we will not come after you for it.

What we store and who else can see it is in the privacy policy.