Security

AI Transform Studio is built for business teams who connect their own systems and model providers. This page describes how we handle security and data in plain language. It is not a certification claim.

Operator: AI Transform Studio Ltd (registered in England and Wales). Contact: support@aitransformstudio.com.

The product is a multi-tenant SaaS application. Customer data is separated logically by organization in the application layer, and on the runtime host each organization’s agent runs execute in a process of their own, with a folder of their own, under an unprivileged system user. We do not claim dedicated databases or dedicated infrastructure for every customer.

Production application data and authentication run on Convex in the EU (eu-west-1, Ireland). The web app’s serverless functions run on Vercel in Dublin; Vercel’s global edge network serves pages and runs a short routing step close to each visitor, which checks sign-in tokens and passes sign-in requests on to Convex. Agent runs in chat execute on our runtime host on Fly.io in Frankfurt (fra), reached through its attach gateway there over Fly.io’s private, encrypted network (the runtime host accepts no connections from the internet); the collaboration and visual rendering infrastructure run there too. Assessments run in the web app’s functions on Vercel, which call your decision model and the systems you connect. Some subprocessors (for example email and web search) may process data outside the UK/EU, and Fly.io keeps its platform logs in the United States — see the list below.

Application data — threads, messages, tool results, artifacts, and assessments — is stored in Convex, which encrypts its disks. Model API keys, connection tokens, and custom headers you enter in their own fields are also encrypted by the application before they are stored (AES-256-GCM, with a key per organization; those keys are in turn encrypted under a master key we can rotate, and only the application database’s own functions can open them); a key written into a server’s address is stored as part of that address.

So that a long agent run can carry on after a restart or a deploy, the runtime host keeps each agent session’s log on an encrypted Fly.io volume in Frankfurt: messages, the model’s reasoning, the instructions sent to the model, and tool calls and tool results in full. A tool result too large for the model’s context is kept in full in a file beside the log, and when an answer is regenerated the earlier log is kept too. This copy is fuller than the one in the application database, which keeps only the start, or only the size, of a large tool call or result. All organizations’ sessions share the volume, in a separate folder per organization. Model keys and connection tokens are sent with each run and kept only in the runtime’s memory, until that organization’s runtime process stops; they are not written to the volume.

Session files on the runtime host, including the full text of large results, are deleted automatically once a session has not changed for 30 days; the cleanup runs twice a day, and a session it cannot check is left for a later run. Two kinds of session may be kept past that mark, for as long as that lasts: one whose goal is still open (active, paused or blocked), so that the chat’s Resume can continue it, and one the runtime still holds in memory, for example while it waits for someone’s approval. Once neither applies, the same 30 days apply, counted from the session’s last change. Reading a thread in the app does not count as a change.

Deleting a thread, or the workbench it belongs to, removes the thread from the application database straight away, and its messages, events, and artifacts shortly after. It also has the runtime host delete its copy, including its subagents’ sessions, whatever state its goal is in. If the host cannot do that yet (it is unreachable, or an older version of the runtime is still running), the request is kept and sent again until the host has done it; until then, the cleanup above applies. Some deleted threads may be left to that cleanup instead, and so kept for as long as their goal stays open: one deleted before we began sending deletes to the runtime host, and one whose agent has not run since early October 2026. Clearing all of an organization’s chats keeps the artifacts they made. A record of each tool call that could change data in a connected system (which tool, who decided, and the outcome, never what was sent) is kept for 365 days, even after its thread is deleted. Fly.io takes daily snapshots of the volume and keeps each one for 14 days, so a deleted session can remain in a snapshot for up to 14 days longer.

Deleting an organization deletes all of its data from the application database: its threads, artifacts, workbenches, assessments, Decision briefs, connections, encrypted keys and their encryption keys, uploaded files, invitations, and the tool-call records above. It also has the runtime host stop that organization’s process and delete its whole folder at once, rather than waiting for the cleanup above; if the host cannot do that straight away, the request is sent again until it has. Fly.io’s volume snapshots can hold that folder for up to 14 days longer.

The attach gateway, also on Fly.io in Frankfurt, passes messages and run events between the app, the runtime host, and the application database, and writes nothing to disk. It holds model keys and connection tokens in memory only, and may call your model provider for small tasks, such as writing a card’s name and brief from the conversation. Service logs on Vercel, Convex, and Fly.io record errors and run status. They include identifiers and error messages, which can quote what a model or a connected system sent back; Fly.io keeps its platform logs in the United States.

Users sign in with email/password (verification codes via email) or Google OAuth. Verification and reset codes expire after 15 minutes, and sign-in, sign-up and password reset answer the same way whether or not an email address has an account. Signing out ends that session at once, including sign-in tokens already issued for it. Authorization for product data is enforced server-side using organization membership and roles. Platform operators may access systems for support and abuse response under internal controls.

Every connection to the product uses HTTPS (TLS), and our domain and all its subdomains tell browsers to use HTTPS only (HSTS). The attach gateway reaches the runtime host over Fly.io’s private network, which is encrypted between machines. Connections the product makes for you that carry keys or tokens, to model providers and to the systems you connect, must use HTTPS; plain HTTP is refused except to your own machine during local development.

You bring your own model API keys or endpoints. Inference is performed by those providers under your arrangement with them. Sensitive writes to connected systems can be held for human approval in-product.

Web search is on by default. While it is on, the search queries the agent writes are sent to Tavily, and pages the agent opens are fetched from our runtime host. To turn it off, open Plugins in the chat composer and switch off Web search: from the next message you send, the agent neither searches nor opens web pages, in every chat in that browser. A workbench has its own Web search switch in its setup.

Prompt injection and tool output are treated as security issues: least-privilege tools and approval gates matter more than prompt wording alone. Model output is untrusted until a person reviews it.

We use the following categories of subprocessors. Details may change; material changes will be reflected here.

• Convex — Application database, authentication sessions, and backend functions (European Union (AWS eu-west-1, Ireland))
• Vercel — Web application hosting, edge delivery, and cookieless site analytics (European Union (Dublin); global edge network)
• Fly.io — Agent runtime host (keeps agent session logs and full tool results on an encrypted volume until a session has not changed for 30 days; one whose goal is still open, or that the runtime still holds in memory, may be kept longer, for as long as that lasts; volume snapshots can hold a copy for up to 14 days after that) and its attach gateway; collaboration sidecar, visual MCP rendering, and the MCP connector servers Studio hosts (European Union (Frankfurt, fra); platform logs in the United States)
• Stripe — Subscription billing and payment processing (United States / European Economic Area (as applicable))
• Resend — Transactional email (sign-in and sign-up codes, welcome, access requests, invitations, password reset, agent run notices that name the thread and may say in a sentence or two why a run stopped, and alerts to our operators that name the organizations and threads affected), and the EA-Bench mailing list's emails (United States)
• Tavily — Web search for agent runs while web search is on (receives the search queries the agent writes, which can include words from your chat) (United States)
• Google — Optional sign-in via Google OAuth (when you choose Google), and the optional YouTube film player (Global)
• Customer-chosen LLM providers — Model inference using API keys you connect (OpenAI, Anthropic, etc.), including the decision models that grade assessments and check goals (Per your provider contract and region settings)
• Customer-connected systems (MCP) — Architecture, delivery, ITSM, and knowledge sources you connect (Per each system you authorize)

We do not currently claim SOC 2, ISO 27001, a completed third-party penetration test report, or customer-managed encryption keys. We will update this page when that changes. Mid-market buyers who need a DPA can request one at support@aitransformstudio.com.

If you believe you have found a vulnerability, email support@aitransformstudio.com with details (our security.txt, at /.well-known/security.txt, says the same). Please do not access other customers’ data or disrupt the Service while testing.