Sub-processors
Version 1.2 · Effective 2026-09-07
A sub-processor is a third party that processes data on our behalf in order to deliver the Service. This page lists ours. It forms part of our privacy policy.
Current sub-processors
| Provider | What it does | What it receives | Where |
|---|---|---|---|
| Amazon Web Services | Hosting, databases, storage, backups | All data we store: account data, session transcripts, and stored credentials | Ireland (eu-west-1) |
| Resend | Transactional email — address verification, notifications | Your email address and the content of those messages | United States |
| GitHub | Source control integration | Repository metadata and the scope of the access you grant; we mint short-lived tokens against your installation | United States |
| Google (Workspace) | Handling mail you send to our published contact addresses | Whatever you choose to put in that correspondence | United States / global |
| Anthropic | Model inference for the Assistant only — see below | Your Assistant conversation and the workspace context assembled with it | United States |
| Groq | Model inference for the Assistant only, where configured | Your Assistant conversation and the workspace context assembled with it | United States |
| Umami | Cookieless product and website analytics | Page patterns, referrer, browser and device type, approximate country, timing — no cookie, no identifiers | European Union |
| Sentry | Error reporting and in-product feedback | Error type and stack frames in our code, release version, page pattern; and the text of any feedback you choose to send | United States |
We will update this page before adding a new sub-processor, and material changes are notified to account holders.
A note on transfers. The data we store sits in the European Union, but most of the providers above are US-based, so some data leaves the EU — your email address, the content of any correspondence, Assistant conversations, and the usage and error metadata described below. Those transfers rely on the providers’ standard contractual clauses. If you need the detail for a compliance review, ask us.
Measurement vendors — a third kind of entry
Umami and Sentry are on the list above, but they are not like the others, and lumping them in without saying so would be misleading. Every other provider on this page holds something of yours: your data, your correspondence, your conversation. These two hold none of it.
They see how the product is navigated and how it fails. They do not see prompts, they do not see model output, they do not see anything we store. Concretely, they never receive:
- session-transcript content — your prompts, the agent’s output, your source code, or command output;
- session replay or any recording of your screen. We do not use replay technology at all, from any vendor. On a product that renders your source code on screen, a replay is a copy of that source code, so this is not a setting we tuned — it is a capability we will not adopt;
- screenshots, including with feedback;
- browser console output, or the body of any request or response;
- your workspace, project or session identifiers. The address of a product page contains
them, so we send the page’s pattern instead —
/workspaces/:id/projects/:id/sessionsrather than the real one.
The one thing that does reach a vendor in your words is feedback you type and send, because you chose to write it. That distinction — what you deliberately send us, versus what is captured around you — is the whole design of that path.
Both are cookieless, so neither requires a consent banner. The privacy policy’s section 10 says the same thing in the same terms.
Two surfaces, two different answers
PlatformSmith has two places an AI model gets used, and the honest answer about model providers is different for each. This is the distinction that matters most on this page, so it is worth reading rather than skimming.
The coding agent — we are not in the path
The coding agent runs in a runtime on your infrastructure, not ours. You connect your own model credential, and the agent calls the provider directly from your own container.
The request never traverses our systems. We are not processing that data and the provider is not processing it on our behalf, so for this surface the model provider is not our sub-processor. Your relationship with them is direct: their terms on retention, training, and residency apply to you under your own account, and you can read your own agreement rather than take our word for it.
But we do store the credential. That distinction is about the request path, not custody. The credential authorising those calls is stored by us and delivered into your runtime when a session starts — an API key you paste, or a setup token you generate with your provider’s own CLI. Section 2A of the privacy policy sets out how it is stored, who can reach it, and how to remove it.
The Assistant — we are in the path
The in-product Assistant is different, and we list Anthropic and Groq above because of it.
The Assistant runs on our infrastructure. When you chat with it, our servers call the model provider, using the credential you connected. So although you still bring the key and the provider still bills you, the request goes out from us, carrying your conversation and the workspace context assembled with it — which can include details about your projects, runtimes, and sessions.
That makes the model provider a sub-processor for this surface, and we would rather list them than lean on the fact that it is your key. Two practical consequences:
- Assistant conversations leave the European Union, because both providers are US-based.
- What reaches the provider is more than what you typed. If you would not want a piece of information sent to your model provider, do not put it in an Assistant conversation.
If you want the coding agent but not this, do not connect a credential for the Assistant — the two are configured separately.
What we hold either way
Whichever surface you use, we hold the record of it. The coding agent streams its session back to our control plane so you can watch, resume, and review it, and we store that transcript; Assistant conversations are stored too. Section 2 of the privacy policy explains what transcripts contain and how long we keep them.
So the coding agent’s carve-out above is narrower than it may first appear: the model traffic does not pass through us, but a full record of it does.