Sub-processors

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
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 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: one vendor, and one thing we run ourselves

Sentry is on the list above, but it is not like the others, and lumping it in without saying so would be misleading. Every other provider on this page holds something of yours: your data, your correspondence, your conversation. Sentry holds none of it.

Analytics is not on the list at all. We run our own instance of Umami, the open-source analytics tool, on our own infrastructure in Ireland, so the analytics described below never reaches a third party.

Between them 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/sessions rather 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, between what you deliberately send us and 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. (A third, an AI app you connect to your account, is set out under “AI apps you connect” below.) 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.

Integrations you connect

An org admin can connect your organisation to Slack and to an issue tracker, Jira, Linear or GitHub, so work can start where your team already is. Here our servers talk to the vendor directly, on your organisation’s behalf, using the credential the admin connected (section 2A of the privacy policy).

• Slack. Slack sends us every message in the channels our app has been added to, and direct messages to it. We act only on an @mention or /smith command, a reply in a thread we are following, and any message in a channel you bind for alerts; everything else is discarded on arrival, and we keep only Slack’s event id so the same message is never handled twice. We post the agent’s replies, its progress and its questions back into those threads, so session output reaches your Slack workspace.
• Issue trackers. For the projects, repositories or teams you bind, we receive or poll ticket events and turn matching tickets into work items. A work item keeps a copy of the ticket’s title and description, refreshed when the ticket changes, and of the comments people add to it, whether or not any work starts. Unless you turn it off, we post progress comments and ps:* labels back on the ticket. Where an admin opts a binding in, agents can also post their findings there; a ticket can be more widely readable than your workspace, a public GitHub issue for example, so opt in only where that is acceptable.

Ticket and message text that starts or continues a run also becomes part of that session and is stored like the rest of its transcript (section 2 of the privacy policy). What we post goes to the vendor under your account and agreement with it. As with connectors, we do not add these vendors to the table above: you chose each one and your relationship with it is direct. GitHub appears there for source control, which is separate.

Connectors and aggregators you connect

A connector lets the coding agent in your sandbox call a vendor’s tools, Jira, Linear, GitHub, Sentry and others, through PlatformSmith rather than directly. Here we are in the path, in a narrower way than for the Assistant, and we would rather describe it than leave it to inference.

When an agent calls a connector tool, the call goes out from our cloud in Ireland (eu-west-1) to the vendor’s server, carrying the tool’s arguments, and the vendor’s answer comes back the same way. Those arguments and results pass through us in transit and are never stored: what we keep is the record of the call, which connector and tool, which session, what was decided, how long it took, and never its content. The vendor processes the call under your account with it and your agreement with it. We do not add connector vendors to the table above: you chose each one, you authorized it with your own account, and your relationship with it is direct.

An aggregator is a connector whose vendor fronts many apps at once, Composio being the first we offer. Everything above applies, and one more thing: the aggregator holds the sign-in tokens of every app you connect inside it, in its own store, in its own region. For those apps the aggregator is your processor, under your agreement with it, and its per-call pricing is billed to your account there. Because that is a custody decision, an org admin acknowledges it when connecting an aggregator account; we record the acknowledgement on the account. Where the aggregator offers a plan that keeps the key in your own cloud, the connector says so. We will not pool your tokens with other customers’ under an account of ours.

AI apps you connect

You can connect an AI app, such as Claude, Claude Code or ChatGPT, to your PlatformSmith account under Account → Connected apps. This is the reverse of the coding agent: the app calls us, from its provider’s infrastructure, and acts as you, with everything you can do in the company you chose. There are no read-only connections yet, and the consent screen says so before you approve.

Whatever the app’s tools return, which can include session transcripts, source code and work items, goes to that provider under your own account and agreement with it. We answer the request; we do not send your data to the provider on our behalf. So the provider is not our sub-processor for this surface, the consent screen tells you where the results go, and the provider’s terms on retention, training and residency apply to you directly. Every provider we support today is US-based, so those results leave the European Union.

What we keep is the connection itself: which app, when you approved it, and when it was last used, never what it read. You can disconnect any app at any time, and the next call it makes fails. If you would not want a piece of information to reach an AI provider, do not connect an app to an account that can read it.

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.

Contact

privacy@platformsmith.com.