The practices behind the trust.
No jargon, no certification cosplay. Here is how your data and access are actually handled.
Per-client isolation
Every client's data and credentials live in their own scope. Working on one account never exposes another. No shared inbox, no shared keys.
Encrypted credentials
The API keys and tokens your build needs are stored encrypted, scoped to your build, and never copied into a global account.
Least access, by default
We ask only for the access a workflow actually needs, prefer read-only where we can, and use OAuth rather than long-lived service keys wherever a provider supports it.
Hosted and monitored
Subscription builds run on Studio OS, our own production platform on Supabase and Amazon Web Services, with automated backups and an audit log. One-time builds you own deploy to your own infrastructure.
You own your outputs
Your data, configurations, and results are yours, exportable in full any time. We own the underlying platform; you own everything it produces for you.
Clean exit
Cancel after the six-month minimum and you get a complete data export within 30 days. No hostage data, no exit games.
Where the AI part actually goes.
The honest gap in most AI tools is what happens once your data hits the model. Here is exactly how ours works, including the questions a careful reviewer would ask.
One AI vendor, named
Every AI step in your build runs on Anthropic's Claude models, and only Anthropic. We do not fan your data out to OpenAI, Google, or a rotating cast of providers. One vendor, under commercial API terms, so there is exactly one place your data is processed and exactly one set of terms to read.
Your data is never training data
We use Anthropic through its commercial API, which does not train its models on the inputs or outputs we send. Your documents, prompts, and the content the workflow generates are processed to do your job and are not used to improve anyone's model.
No embeddings, no shadow copies
Some AI tools quietly turn your documents into a permanent vector database that lives on after you delete the original. We do not. There are no embeddings, no vector store, and no second copy of your data sitting in a system you cannot see.
Short, bounded retention
Inside the platform, your data lives in your isolated scope until you delete it or leave. At the AI layer, Anthropic retains API traffic only briefly for abuse monitoring and then discards it. Nothing is kept around indefinitely to mine later.
Deletion that actually deletes
When you ask us to delete a document or your account, it is removed from the database and from file storage, not just hidden. Because there are no embeddings or vector copies, there is no hidden second version to chase down. Backups roll off on their normal cycle.
Locked-down operator access
The only people who can reach your data are you and the operator running your build. Operator logins are protected by app-based two-factor authentication, so a leaked password alone cannot open your account.
The trust questions.
Anthropic's Claude models, and only Anthropic. Depending on the step, your build uses Claude Opus, Sonnet, or Haiku to draft content, synthesize reports, generate blueprints, and route requests. We do not send your data to OpenAI, Google, Perplexity, or any other AI provider. One vendor, one set of terms, accessed over Anthropic's commercial API.
No. We access Claude through Anthropic's commercial API, under terms where the data we send is not used to train Anthropic's models. Your uploads, prompts, and the outputs the workflow produces are used to do your work, not to improve a model. You can read Anthropic's commercial terms at anthropic.com/legal/commercial-terms.
No. Some AI products convert your documents into embeddings stored in a vector database that quietly persists after you delete the original file. Growth House does not do this. There is no vector store and no embedding copy of your data anywhere in the system, which also means there is no hidden copy to worry about when you ask us to delete something.
Inside the platform, your data lives in your isolated scope for as long as your account is active, until you delete it or cancel. At the AI layer, Anthropic retains API traffic only for a short period for abuse monitoring and then discards it; it is not kept to train on or mine later. We do not maintain a separate long-term archive of your prompts and outputs outside your own scope.
The operator running your build can, by design, the same way any agency that does the work for you can see the work. No one else can. We do not browse client accounts for fun, we do not reuse one client's data or credentials for another, and operator access is locked behind two-factor authentication. If you need stricter access controls for a specific build, raise it on the call and we will scope it.
Uploaded files are stored in private, per-client storage buckets on Supabase (on AWS), scoped so that one client's files are not reachable from another client's scope. The only place file contents are sent for processing is Anthropic's API, when a step in your workflow needs to read or act on them. They are not posted to other third-party tools.
When you request deletion, we remove the data from the live database and from file storage. Because there are no embeddings or vector copies, there is no secondary AI store to clear. Encrypted backups age out on their normal rotation rather than being surgically edited, which is standard practice; if you need a hard backup-purge commitment in writing, we can put that in your data processing addendum.
Yes. Every table and every private storage bucket that holds client data has Row Level Security enabled, with policies scoped to your organization. Access is granted through membership and owner checks rather than left open, so a query can only ever return rows that belong to your scope. This is enforced at the database layer, not just in the app.
Yes. Operator logins, the accounts that can reach client data, are protected by app-based (TOTP) two-factor authentication, so a stolen password on its own cannot open an account. Client sign-in uses one-time email magic links, which means there is no reusable client password to phish in the first place.
Yes. Our privacy policy is published at /privacy and covers what we collect, the sub-processors we use (including Supabase and Anthropic), retention, and your rights. For business-sensitive or regulated data, we can sign a data processing addendum that names our sub-processors, commits to the no-training and deletion terms above, and adds breach-notification obligations. Ask for it on the call.
Growth House itself is not, and we will not pretend otherwise. But the platform your data sits in carries the certifications: it is stored in Supabase, which is SOC 2 Type II certified and independently audited every year, and encrypted at rest with AES-256. You can verify that yourself at supabase.com/security. On top of that we run least-access, per-client isolation, and encrypted-credential practices. If your build touches regulated data like health records, say so on the call and we will scope it carefully or tell you we are not the right fit.
Only the people working on your build, and only the access your workflow requires. We do not browse client accounts, and we do not reuse one client's data or credentials for another.
It depends on what you hired us for. Subscription builds run on Studio OS, our production platform built on Supabase (SOC 2 Type II, encrypted at rest with AES-256) and Amazon Web Services, with automated backups and a change audit log. One-time builds that you own are deployed to your own infrastructure under your own credentials, so your data never lives with us in operation at all. Either way, account credentials are stored encrypted and scoped to your build.
You get a full export within 30 days of cancellation. The platform that ran it stays ours; everything it made for you goes with you.