Privacy Policy

This policy explains what personal data and customer content PlatformSmith collects, why, how long we keep it, and what rights you have.

The most important things in this document are sections 2 and 2A. We store a complete transcript of every agent session. Those transcripts contain your source code, and can contain credentials. If you read only one section, read that one. Section 2A covers the provider credentials we hold.

1. Account data

When you create an account we collect your email address and name, and — if you sign in with Google or GitHub — the identity your provider returns to us. We use this to authenticate you, to associate your work with your account, and to contact you about the Service.

We also collect ordinary technical data: IP address, browser type, and timestamps of requests, used to operate and secure the Service.

2. Session transcripts — please read this

PlatformSmith stores a complete, unredacted transcript of every agent session. That includes:

• the prompts you write,
• everything the agent writes back,
• and the output of the files it read and the commands it ran.

These transcripts routinely contain your source code. They can also contain credentials and other secrets — not only ones you type into a session, but ones the agent surfaces by itself while doing ordinary work. An agent that reads a .env file to debug a configuration problem, or prints a stack trace containing a connection string, has put that secret into the transcript. This is normal agent behaviour, not misuse, and it is why we are telling you plainly rather than asking you to be careful.

We currently apply no automated redaction to transcripts. We intend to add it, and we will say so here when we do.

Transcripts are stored on our infrastructure, separately from the runtimes, which run on yours. We use them to show you your session history, to let you resume sessions, and to debug the Service — see section 5 on who can read them.

Treat a PlatformSmith session as a place where secrets may end up. Prefer short-lived and narrowly scoped credentials, and rotate anything you believe has been exposed.

2A. Provider credentials

To run a session we need the credential that authorises it, so we store it.

What we store. Either an API key you supply, or a long-lived setup token you generate with your provider’s own CLI and paste in. We also store the Git credentials you connect.

How. Encrypted at rest, held separately from transcripts, and readable only by the systems that assemble a runtime session. Credentials are never written to application logs and never appear in a transcript by our doing. (An agent that reads a credential out of your own files during a session can still put it in a transcript — see section 2.)

Scope. A credential is bound to the individual who connected it. Where you connect a personal provider subscription, other members of your workspace cannot use it to run their own sessions; they connect their own credential, or the workspace uses a shared organisation key.

Delivery. At session start the credential is resolved into the runtime on your infrastructure so the agent can call the provider. From that moment it sits inside the agent’s blast radius — see the shared responsibility model.

The Assistant is different. The in-product Assistant runs on our infrastructure, so when you use it the credential is used by our servers to call the provider, and your conversation goes out from us. Section 4 and the sub-processors page explain what that means. If you want the coding agent but not this, do not connect a credential for the Assistant — they are configured separately.

Removal. Disconnect a provider at any time and we delete the stored credential from live systems immediately; it may persist in encrypted backups until those rotate. If you believe a credential has been exposed, revoke it at the provider — that takes effect regardless of what we hold.

What this means. A compromise of our control plane would put stored credentials at risk. We would rather you weigh that than have it be a surprise, so it is listed on our known limitations page too. Prefer narrowly scoped, short-lived credentials.

A note on provider subscription credentials

Some providers restrict how third-party tools may handle credentials tied to a personal subscription. We do not offer “sign in with your provider account” and we never intercept a provider login: where a setup token is used, you generate it yourself with the provider’s own CLI, and it is only ever handed to that provider’s own agent binary running in your runtime. It is never used to call a provider API from our servers.

Providers may change these rules or restrict third-party access without notice. If that happens, sessions using an affected connection stop working and you can reconnect with an API key. For team-wide use and for scheduled or unattended runs, connect an API key rather than a personal subscription credential.

3. How long we keep it

During beta we retain session transcripts for the life of your workspace. We intend to introduce a defined retention period and will publish it here, with notice, before it takes effect.

Account data is kept while your account is open.

You can ask us to delete your data at any time, including your transcripts, by writing to privacy@platformsmith.com. We will do it and confirm when it is done. Note that data may persist in encrypted backups for a period after deletion from the live system, as backups rotate.

4. Who we share it with

We do not sell your data and we do not use your code or prompts to train models.

We use a small number of service providers to run the Service. They are listed, with what each one receives, on our sub-processors page.

Where model providers are concerned, the answer differs by surface, and the sub-processors page sets it out in full:

• The coding agent runs on your infrastructure and calls the provider directly from there. That request does not pass through us, so for that surface the provider is not our sub-processor and your relationship with them is direct.
• The in-product Assistant runs on our infrastructure. When you chat with it, our servers call the provider using the credential you connected — so your conversation, and the workspace context assembled with it, is sent to that provider by us. Anthropic and Groq are listed as sub-processors for this reason.

You still bring the credential in both cases, and the provider still bills you. What differs is who makes the request.

We may disclose data where we are legally required to, and will tell you unless we are prohibited from doing so.

5. Who at PlatformSmith can read your sessions

Our staff access policy sets this out in full. In short: our staff can routinely see session metadata — what kind of event occurred, when, and whether it errored — because that is what diagnosing a stuck session requires. Reading the content of a transcript requires a specific reason and your consent.

6. Your rights

Depending on where you live you may have the right to access, correct, export, or delete your personal data, to object to or restrict processing, and to complain to your local data protection authority.

To exercise any of these, write to privacy@platformsmith.com. We will respond within 30 days. We will not charge you or make the Service worse for asking.

7. Where your data is held

Our control plane — the account data, session transcripts, and stored credentials described above — runs in Amazon Web Services’ Ireland region (eu-west-1), in the European Union.

PlatformSmith is operated from India, and our staff access that data from there under the controls described in our staff access policy.

Your runtimes run on infrastructure you choose, in a location you choose. We do not control that infrastructure and cannot make representations about where data sits while a session executes on it. The runtime software is ours; the machine it runs on is yours, and the shared responsibility model sets out the division.

Assistant conversations leave the EU in transit. The Assistant runs on our infrastructure in Ireland, but the model providers it calls are US-based, so your conversation and the context sent with it travel to the United States. Those transfers rely on the providers’ standard contractual clauses.

Usage and error metadata leaves the EU in transit. The analytics and error reporting described in section 10 are provided by US-based vendors, so that metadata — page patterns, browser type, error details — travels to the United States. Those transfers rely on the providers’ standard contractual clauses. The transcripts, credentials and account data described above do not: they stay in Ireland, and section 10 lists what the telemetry vendors never receive.

8. Security

We use encryption in transit, encrypt credentials you store with us, and scope every query to your account. No system is perfectly secure, and we do not claim ours is. We maintain a list of known limitations and would rather you judge us on that than on an assurance.

If we discover a breach affecting your personal data we will notify you and the relevant authority as required by law. Report a suspected security problem or a compromised account to security@platformsmith.com.

9. Cookies and local storage

We use browser storage only to keep you signed in and to remember interface preferences. We do not use advertising cookies, we do not use analytics cookies, and we do not track you across other websites. There is nothing here to opt out of, and no consent banner, because there is no cookie to consent to.

We do measure how the product and this website are used, and that measurement is cookieless — it sets nothing in your browser and does not follow you between sites. Section 10 says exactly what it collects. If we ever adopt anything that sets a tracking cookie, this section changes first.

10. Product analytics and error reporting

Two things measure how the product behaves. Both are deliberately narrow, and what they exclude matters more than what they collect, so that is stated first.

Neither ever receives your session-transcript content. Specifically, we do not send:

• the content of any agent session — your prompts, the agent’s output, your source code, or the output of commands it ran;
• session replay or any recording of your screen — we do not use replay technology at all, from any vendor;
• screenshots, including with feedback you send us;
• browser console output, or the body of any request or response;
• your workspace, project or session identifiers.

That last point is worth explaining, because it is easy to get wrong. The address of a page inside the product contains identifiers for the workspace and project you are looking at. We do not send the address. We send the page’s pattern — for example /workspaces/:id/projects/:id/sessions — which tells us that someone looked at a sessions list without telling anyone whose it was.

Analytics (Umami) records a page view: the page pattern, the site that referred you, your browser and device type, an approximate country, and timing. It sets no cookie and does not identify you or link visits together across sessions.

Error reporting (Sentry) records a crash: the error type and message, the stack frames in our code, the release version, and the page pattern. Browser console output and network request bodies are stripped before anything is sent, and identifiers are removed from URLs and messages.

Feedback you send us is different in one specific way, and it is the difference that governs this whole section: what you type, you chose to type. If you send feedback through the product, the words you wrote reach us and are read by a person. Nothing is captured around them — no screenshot, no recording of what was on screen. Please avoid pasting source code or credentials into a feedback message.

11. Children

The Service is not intended for anyone under 18, and we do not knowingly collect their data. Model providers set their own minimum ages, which may be higher than any minimum we set; you are responsible for meeting the requirements of the provider account you connect.

12. Changes

We may update this policy. The version and effective date above identify the current version, and we will make reasonable efforts to tell account holders about material changes before they take effect.

13. Contact

privacy@platformsmith.com — for any question about this policy, or to exercise any right in section 6.

feedback@platformsmith.com — for product feedback, bug reports, and anything you would like the Service to do differently. It reaches a person, not a model.