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, and the credentials of the other services your organisation connects: the Slack workspace, the Jira, Linear or GitHub account an issue-tracker integration uses, and the account behind each connector (section 4). All of them are held the same way.

How. Encrypted at rest, held separately from transcripts, and readable only by the systems that use them: the one that assembles a runtime session and, for an integration or connector, the one that calls that vendor. 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. Integration and connector credentials belong to the organisation: an org admin connects them and decides which workspaces may use them.

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. Slack, issue-tracker and connector credentials are the exception: they are never delivered into a runtime. Our servers use them to call the vendor. A decrypted copy is kept only in memory, never on disk, and for no longer than the vendor’s own access token stays valid, or ten minutes for a key that does not expire.

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, integration or connector 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.
• Connectors and aggregators you connect under Organization settings let the coding agent call a vendor’s tools through our cloud: the call’s arguments and results pass through us in transit, never stored, and the vendor processes them under your own account and agreement with it. An aggregator additionally holds the tokens of the apps you connect inside it, which an org admin acknowledges when connecting. The sub-processors page sets this out under “Connectors and aggregators you connect”.
• AI apps you connect to your account, such as Claude, Claude Code or ChatGPT, work the other way round: the app calls PlatformSmith from its provider’s infrastructure, acting as you, after you approve it on a consent screen. Whatever its tools return, which can include session transcripts, source code and work items, goes to that provider under your own account with it. You send it there, not us, so the provider is not our sub-processor for this surface. You can disconnect any app at any time from Account → Connected apps. The sub-processors page sets this out under “AI apps you connect”.

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, which holds the account data, session transcripts and stored credentials described above, runs in Amazon Web Services’ Ireland region (eu-west-1), in the European Union.

Traffic you elect to send through a connector or an aggregator (section 4) leaves the European Union in transit to that vendor’s region and is not stored by us; the connector names the region before you connect it.

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.

What an AI app you connect reads leaves the EU. When an app you connect (section 4) calls PlatformSmith, the results go to that app’s provider, which for every app we support today is US-based. You start that transfer, under your own agreement with the provider.

Error metadata leaves the EU in transit. The error reporting described in section 10 is provided by a US-based vendor, so that metadata (page pattern, browser type, error details) travels to the United States. That transfer relies on the provider’s standard contractual clauses. Analytics does not leave: we run it ourselves, in Ireland. The transcripts, credentials and account data described above do not leave either: they stay in Ireland, and section 10 lists what analytics and error reporting 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 set only the cookies needed to sign you in and to protect security-sensitive steps. There are three, all set by us (first-party) and all marked HttpOnly, so scripts running in the page cannot read them:

• a sign-in state cookie while you sign in with Google or GitHub, which stops anyone else from completing that sign-in on your behalf;
• a short-lived sign-in handoff cookie that finishes signing you in after your provider sends you back to us;
• a single-use re-authentication confirmation, valid for five minutes, when you confirm it is you before linking a sign-in provider, connecting an AI app, or creating a personal access token.

Your signed-in session itself, and interface preferences such as your theme, are kept in browser storage. We use no tracking, analytics or advertising cookies, and we do not track you across other websites. The cookies above are strictly necessary for the Service to work, so they need no consent: there is no consent banner, and nothing here to opt out of.

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. We run Umami ourselves, on our own infrastructure in Ireland, so this data is not shared with any third party.

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.