Known Limitations

We would rather you learn our limitations here than discover them in your own repository. This page lists what PlatformSmith does not do well yet. It is not exhaustive, and we will keep it current as things change — including by removing entries once they are genuinely fixed.

Prompt injection is unsolved, here and everywhere

Coding agents read untrusted content as a matter of routine: repository files, issue and pull-request comments, dependency documentation, command output, web pages. Any of that can carry instructions aimed at the agent rather than at you.

An agent that follows such an instruction does so holding the credentials you connected. It might commit code you did not ask for, read files you did not intend to expose, or use a connected token in a way you would not have chosen.

This is a property of how current coding agents work. It is an active research problem across the industry and nobody has solved it, ourselves included. Our honest position:

• We cannot promise an agent will not be manipulated.
• The most effective control available today is credential scope — see the shared responsibility model.
• Review what the agent produces before it matters. Do not connect production systems you are not prepared to see changed.

Agent output is not reliable

Agents write incorrect code, misunderstand requirements, and occasionally do something confidently wrong. Everything an agent produces needs human review before you rely on it.

Transcripts are stored unredacted

We keep a complete transcript of every session, and we do not currently filter secrets out of it. Section 2 of the privacy policy explains this in full. Automated redaction is planned; it does not exist today.

We hold your provider credentials

The credential you connect — a model provider key or token, a Git credential — is stored on our infrastructure so we can start sessions with it. It is encrypted, but a compromise of our control plane would put it at risk, and we have no certification attesting to how well we protect it (see below).

Two mitigations are entirely in your hands and both are more effective than anything we can offer: scope credentials narrowly, and rotate them if you have any reason for doubt. Section 2A of the privacy policy covers custody in detail.

There is no defined retention period yet

During beta, transcripts are kept for the life of your workspace. We intend to introduce a retention period and will publish it with notice. Until then, deletion happens when you ask for it.

We set no resource limits on your runtimes

Runtimes execute on your infrastructure, and we do not currently cap the CPU, memory, or disk a session can consume there. A heavy session competes with whatever else runs on that host. Size accordingly, and prefer a host that is not doing anything critical.

We do not isolate your runtimes on your network

What a runtime can reach on your network is determined by your network, not by us. If your runtimes should not reach production, place that control on your side.

Availability

This is a free beta running in a single region with no redundancy and no service level agreement. Expect downtime, expect it during working hours, and do not make PlatformSmith the only copy of anything.

Authentication

We support email-and-password and OAuth sign-in with Google and GitHub. We do not support multi-factor authentication or SSO/SAML yet. If your organisation requires either, PlatformSmith is not ready for you.

We hold no security certification

We are pre-certification. We have not completed a SOC 2 audit or an ISO 27001 certification, and we have not had an external penetration test. We run an internal security review process and prioritise what it finds. If a certification is a requirement for you, we do not meet it today, and we would rather say so now.

Telling us

If you hit a limitation that is not on this page, we would like to know: security@platformsmith.com for anything with a security dimension.