Privacy
Plain-language summary. Not legal advice.
What StoneCode stores
Your account, workspaces, projects, and the operating data you create: slices, evidence links, reviews, decisions, receipts, policies, roles, artifacts, and register entries.
Secrets: what the guarantee actually covers
Automated Secrets registry imports store names, environments, owners, rotation notes, and a link to your secret manager. That import path rejects anything that looks like a credential value. Manual registry entry uses a separate server-side check and is outside this automated import guarantee. Free-text fields elsewhere, evidence notes, artifact bodies, imported documents, and agent chat are stored as written. Do not paste a credential into them.
AI model providers
If a model provider is configured on the server, the in-app agent chat sends that project’s context to it so the agent can answer about your work. That context is broad: the north star, slices, acceptance criteria, policies, roles, research notes, requirements, architecture, and the Secrets registry metadata described above (names and links, never values). The call is made with StoneCode’s server-side API key, not yours. Today that provider is OpenAI or Anthropic, depending on which key the deployment has configured. On the OpenAI path StoneCode sets
store: false so the request is not retained for training or history. If you do not want project context leaving your deployment, do not use the in-app chat: connecting your own coding agent over MCP keeps the model relationship between you and your agent vendor.Other services StoneCode relies on
Managed StoneCode authentication is handled by Clerk, which receives the sign-in identity and email. Local development can instead use one fixed, unauthenticated development identity; that mode has no Clerk sign-in and is refused in production. The application and database are hosted infrastructure (Vercel and Neon in the managed deployment), which means those providers hold your data at rest and in transit on StoneCode’s behalf. Payments are handled by Stripe, below.
GitHub access
The GitHub integration is read-only: StoneCode reads pull requests, checks, and changed files to build evidence, and never writes, merges, or deploys. Access credentials live in server environment configuration, not in the product database. Disconnecting a repository removes the stored repository reference from your project. The current build is oriented to public repositories; private-repository reads depend on server-configured credentials and are being moved to per-workspace GitHub App installations.
Payments
Subscriptions are processed by Stripe. StoneCode never sees or stores your card details. Stripe handles payment security and compliance.
Deletion and what it takes with it
You can delete any project, and any slice that has not been accepted. Deleting a project is not immediate: it is kept for 30 days and restorable from Settings, then permanently erased along with its slices, evidence and receipts. Deleting a slice that has not been accepted happens right away and cannot be undone. Either way, the audit log, the record of what was decided and by whom, is kept even after the deletion: it is built to outlive the thing it describes, deliberately, so the record of a deletion cannot itself be deleted. Settings also offers deleting every project at once, on the same 30-day terms.
You can also close your entire account from Your account. Whether closing is self-serve there depends on your identity provider: where it allows account deletion, the option appears on that page; where it does not, this deployment’s support contact, or your workspace administrator if none is configured, closes it for you instead. Either way, StoneCode is told as soon as your sign-in account is deleted, and closes your side automatically: a workspace only you own follows the same 30-day terms; a workspace with other people in it is handed to the most senior remaining member instead. What does not exist yet, stated plainly: there is no way to delete a workspace on its own while keeping the account.
You can also close your entire account from Your account. Whether closing is self-serve there depends on your identity provider: where it allows account deletion, the option appears on that page; where it does not, this deployment’s support contact, or your workspace administrator if none is configured, closes it for you instead. Either way, StoneCode is told as soon as your sign-in account is deleted, and closes your side automatically: a workspace only you own follows the same 30-day terms; a workspace with other people in it is handed to the most senior remaining member instead. What does not exist yet, stated plainly: there is no way to delete a workspace on its own while keeping the account.
Taking your record with you
Settings offers a complete export of the workspace governance record as JSON: every project, slice, evidence item, review, decision, receipt, policy, role, membership and audit event. Credential material is deliberately left out so the file cannot widen the blast radius of a leak. It is an export, not a restore: there is no import path that reconstructs a workspace from one.
What is not settled yet
Stated plainly rather than left for you to discover: there is no retention schedule, so data is kept until you delete it. There is no breach-notification commitment and no third-party security certification. These are being worked on, and this page will say so when they change.
Contact
Questions about your data:
No support address is configured for this deployment, so everything here is self-serve for now.