The short version
This page describes the security of code-anything.com as it is built today, not as we would like it to read. Everything below is something you could verify by looking at what the service does. Where a protection is partial, or absent, it says so rather than being left out and implied. We hold no security certifications, we run no analytics or tracking software of any kind, and we do not train models on your code.
How your data is isolated
Isolation is enforced in the database itself, not only in application code. Every table that holds your data — projects, files and their version history, chat transcripts, prompts, build records and traces, the code index, generated documentation, billing ledgers, the lot, some thirty-nine tables — has row-level security switched on, with a policy that scopes each row to the account that owns it. A query made with your session can only return rows belonging to you. A bug in a route handler cannot widen that, because the constraint is below the handler.
On top of that, the API deliberately does not distinguish “this project does not exist” from “this project is not yours”. Both return not found, never forbidden, so the API cannot be used to discover whether a given project identifier is real. Ownership is resolved through the same row-scoped database client that serves your reads, so there is one answer rather than two that could disagree.
One consequence worth stating plainly: a project has exactly one owner account. There are no organisations, no member lists and no roles in the product today, so there is no way to grant someone else scoped access to a project. Sharing a project means sharing an account, which we would rather you did not do.
Credentials you connect
API keys and environment secrets you paste in are encrypted with AES-256-GCM in the application before they are written anywhere. The 256-bit key lives only in the server environment and never in the database, so a copy of the database on its own yields no usable credential — only ciphertext. If that key is not configured, the service keeps your secrets in memory for the session instead of persisting them; it never falls back to writing them in the clear.
The table those encrypted blobs live in has row-level security enabled with no policies at all. That is not an oversight — it means every request that arrives with a user session is denied outright, and only the service role can read it. Encryption and the access rule are two independent barriers, and neither one is load-bearing on its own.
Secrets are decrypted for one purpose: to be placed into your own project’s sandbox environment so your app can use them. They are not sent to model providers and they are not written into your generated source.
How builds run, and how they are contained
Building and editing an app means running an agent and real commands against real code. That work happens in a container dedicated to a single project, addressed by that project’s own key — one workspace, one project, never shared, and disposable. The durable copy of your code lives in the database; the container is scratch space that can be destroyed and rebuilt from it. Nothing in one project’s workspace is reachable from another’s.
When we connect a repository, the agent works on a clone inside that workspace. Your actual repository is never the thing being edited.
The network boundary
A workspace runs in two phases. During setup it needs open network access to install dependencies and clone code. Before the model is given the ability to edit anything, the workspace is flipped to a deny-by-default rule set: loopback, DNS, and an allowlist of package and source hosts — the npm and Yarn registries, github.com and its download hosts, PyPI and its file host. Everything else is dropped.
The honest caveat. Those rules are applied inside the container with its own firewall, which requires a network capability the container host has to grant. Where the host does not grant it, the rules are a no-op and the workspace keeps open egress. We treat this as defence in depth rather than a hard boundary, and the correct long-term place to enforce it is an outbound gateway in front of the container. We would rather tell you that than let you assume a guarantee we cannot currently prove.
Authentication
Sign-in is delegated to Supabase Auth: a one-time link sent to your email address, or Google, or GitHub. We store no passwords, because there are none to store — there is no password field in this product and therefore no password database to breach. Signing in with Google gives us your email address, name and profile-picture URL and nothing else; the Privacy Policy sets out exactly what is received.
Connecting GitHub is optional and only needed to import or push to a repository. That access token is held in an HTTP-only cookie in your browser, sent over HTTPS only, expiring after eight hours and cleared when you disconnect — it is not stored in our database.
Transport and response headers
All traffic is over HTTPS. Every response from the application carries a fixed set of hardening headers: nosniff to block MIME-type guessing, a strict-origin-when-cross-origin referrer policy so full URLs do not leak to third parties, SAMEORIGIN framing so our pages cannot be embedded elsewhere, HSTS for a year including subdomains, and a permissions policy that switches off ambient access to the camera, geolocation and features the control plane does not use.
There is no Content-Security-Policy. We are not going to claim one. The interface embeds a cross-origin preview of your running app in an iframe and the framework injects inline bootstrap script and style, so a policy strict enough to be worth having would silently break the streaming build interface. The right place for it is the edge layer, where it can be tuned per route; until it is there, it is not there.
Rate limiting
Every route under /api/ is throttled — keyed to your account when you are signed in, and to the client IP otherwise. The endpoint that starts a build gets a much stricter budget than ordinary reads, because a build spends real money and real compute.
Described accurately, this is a soft cap: the counters are held in the memory of each running server instance, so the true ceiling is the per-instance limit multiplied by however many instances are live. It is enough to stop a runaway client or a careless script. It is not a hard, globally coordinated guarantee against a distributed flood, and we do not present it as one. The volumetric and denial-of-service layer in front of the application is our hosting provider’s.
Changes to a connected repository
When a project is linked to one of your GitHub repositories, changes reach it as a pull request you review and merge. The flow clones the repository, overlays the current project files so the diff is against real history, commits to a fresh branch, pushes that branch and opens a pull request against the default branch. It does not force-push, and it does not write to your default branch. The background sync that keeps a linked project current is deliberately non-destructive too: it proposes writes only, never deletions, because a file it does not know about is not a file it should remove.
The one case where we create rather than propose is when you explicitly ask us to export a project into a new repository — that repository is created for that purpose at your request.
What we log, and what we do not
We write one structured line per server request: a correlation id, the route name, the method, the response status and how long it took. Errors add the exception. That correlation id follows a request through the build so a failure can be traced end to end, and you can quote it to us.
We do not log request bodies, we do not log browser user-agent strings, and we keep no server-side profile of visitors. Your IP address is used in memory for rate limiting and is not written to any database; it can appear in an operational log line if a request is throttled. There is no analytics package, no advertising script, no session-replay or heatmap tool and no third-party tag anywhere on this site — the application’s whole runtime dependency list is nine packages, and none of them is a tracker.
Who is in the path
The complete list, with what each one receives, is in the Privacy Policy; this is the summary. Model providers, reached through our own gateway, receive your prompt, the relevant source files, attached document text, reference images and preview screenshots — this is the significant transfer and it is inherent to the product. A separate review and research service receives the prompt, the diff and preview screenshots with anonymous identifiers rather than your name or email. A screenshot service receives the public preview URL of your app. Supabase holds the database, authentication and file storage. Cloudflare provides hosting, edge compute, the build sandboxes, object storage and log retention. GitHub is involved only if you connect it. Stripe handles payments, and card details are entered on Stripe’s own checkout and never reach our servers. Resend sends transactional email.
Data at rest in the database is protected by our infrastructure providers’ own encryption, on their terms — that is theirs to guarantee, not ours, so we describe it as what it is. The layer we operate ourselves is the credential vault above.
What we do not have
Stated directly, because a vague answer here is a misleading one:
- No certifications. No SOC 2, no ISO 27001, no HIPAA attestation or BAA, no PCI attestation. No independent security audit of this service has been performed. If that changes, it will be named and dated on this page, and until it is named here it has not happened.
- No Content-Security-Policy, for the reason given above.
- No uptime SLA. The service is provided as is and as available. We publish no availability commitment on self-serve plans.
- No third-party penetration test and no bug-bounty programme. We have not commissioned one and we do not pay for reports. We will still read and act on anything you send us.
- No customer-managed encryption keys, no private networking, no SSO or SAML, and no audit-log export. These are not configured-off; they do not exist in the product.
Reporting a vulnerability
If you think you have found a security problem, please tell us before telling anyone else. Email security@code-anything.com with what you found, how to reproduce it, and what you think the impact is.
What you can expect from us:
- an acknowledgement from a person within five working days;
- an assessment of whether we can reproduce it, and our view of the severity, with the reasoning;
- progress updates until it is resolved, and word from us when the fix is live;
- credit in the fix notes if you want it, and no legal action against good-faith research that stays within your own account, does not access or modify anyone else’s data, does not degrade the service for others, and gives us reasonable time to fix the issue before publication.
Please do not run automated scanners against the production service, do not attempt denial-of-service, and do not use another customer’s data to demonstrate a finding — describe the path instead and we will reproduce it ourselves.
Your side of the line
The apps you build here are yours, and their security is yours. We isolate the build and we do the things described above, but we do not review your generated application for vulnerabilities on your behalf, and running it in front of real users is your decision. Before you do, look at what it stores, who can read it, and what happens if a request arrives that you did not expect.
The same goes for what you paste in. Give a connected key the narrowest scope that works, prefer a test or restricted key while you are building, and rotate anything you have shared more widely than you meant to. And keep confidential material off the design canvas: images uploaded there and preview screenshots are served from long, unguessable addresses that work without signing in, so anyone holding the link can open them.
No service is perfectly secure, including this one. This page is our account of what is actually in place, and it changes when the code changes.