Security & data

Studio treats the model as untrusted. The agent can be misled by what it reads: a web page, a ticket, or a record can contain instructions meant to steer it. So the rules that protect your data are enforced by Studio itself, outside the model, and nothing the model reads or says can change them.

What Studio enforces

• Writes wait for a person. A tool that can change data in a connected system asks for approval first, showing exactly what it would send. An approval covers only that one call. A tool that doesn't say whether it reads or writes is treated as a write. Only an admin can let a connection write without asking. See Agent harness.
• Unattended runs stay in bounds. An admin decides whether anything may change source data while nobody is watching. A goal or a resumed run can't get round that.
• Prompt-injection guard. Even in a chat someone is watching, Studio asks before a write tool whose purpose is unclear, before a goal the agent set for itself, and before opening a web address nobody gave the run. It is on by default, and only an admin can turn it off. See Agent harness.
• Web access follows your policy. Admins choose whether the agent may search, open any page, open pages only on listed domains, or use no web at all. Studio refuses anything else before it runs.
• Sub-agents inherit the rules. A sub-agent works under the same policy as the chat that started it.
• Secrets stay out of the model. Model keys and connection tokens never enter the model's context, and tool results stay inside your organization and the chat that produced them.
• Visuals can't leak data. Studio's visual apps render in a closed frame. Apps from other MCP servers render only after an admin allows them, and only from the hosts the admin ticked. Images from outside sources are shown as links, and raw HTML from the model is never rendered.
• Evidence is checked by Studio. A Decision brief marks a value Verified only when it matches what the named system returned. See Decision brief. Under a chat answer, the Source check says which of its figures Studio found in the records and documents the chat read. See Co-create with agents.
• Files are kept only while a chat needs them. A file added to a chat that nobody read is deleted after a day; one the agent read is deleted shortly after the read. Pictures sent to a picture-reading model go to that model's provider, under your agreement with them.
• Embeds show what a person published. An embedded artifact shows the version a member published, never a draft, and nothing about your organization. See Reopen, present and share.
• Workbench rules hold. A workbench run can use only the connections and tools its manifests allow, and write only its stage's outputs. A workbench script runs only as the exact code that was approved, with no network access.

Your data

• Separate by organization. Each organization's data is kept apart, and every request is checked against your membership and role.
• Your models. Inference runs on the providers your organization connects, under your agreement with them.
• Encrypted. Data is encrypted at rest. Model keys, connection tokens, and custom headers are also encrypted before they are stored.
• Hosted in Europe. Application data is stored in the EU (Ireland), and agent runs execute in Frankfurt.
• Deletion. Deleting a chat or a workbench removes it and its history. Records of tool calls that could change data in a connected system (which tool, who decided, and the outcome, never what was sent) are kept for a year as an audit trail.

For hosting, retention periods, subprocessors, and compliance, see our Security page. To request a data processing agreement or report a vulnerability, email us at the address listed there.