Security

Rough runs inside other people's products, so we try to be precise about what it can and can't reach. This page describes how the system works today, and says so where we don't have a published guarantee yet. If you need something specific for a procurement or compliance review, get in touch.

Where the trust boundary sits

A Rough Feature runs in an isolated frame: an iframe served from its own origin, talking to your product through one typed postMessage bridge.

The bridge carries a fixed list of named tools, each with its own input and output schema. A Feature can call those tools and nothing else. There is no eval, no privileged channel, and no implicit access to your cookies, local storage or DOM.

In practice:

• A Feature cannot read host cookies, headers, or session storage.
• A Feature cannot inspect or modify host DOM outside of its own iframe.
• A Feature cannot call host APIs except through tools the host has registered.
• A Feature cannot escalate to other Surfaces or other Features.

Tools are your access control

Every action a Feature can take on your product has to be registered as a tool. You implement tools in your codebase, in your runtime, with your own auth and authorisation. Rough carries the call across the bridge and does not decide whether you should allow it.

So your usual access checks still run. If your createTask mutation already checks that the calling user may create a task, it still checks that when a Feature triggers it. Don't skip that work because the call came from Rough.

Schema validation on every call

You describe tool inputs and outputs with Zod schemas, and both sides of the bridge validate against them. A malformed payload from a Feature gets rejected before it reaches your tool implementation, and a Feature never receives a shape it wasn't prepared for.

The same schemas generate types and mock data, so your engineers read the contract that actually runs.

Authentication

You give the SDK a project ID and a function that fetches a user token from your own server. Your server signs that token with a private signing key that never leaves it, and Rough exchanges the token for a short-lived session for that user. The getting started guide walks through it.

Rough does not authenticate your users. It trusts the token your server signed, so Rough sees whoever your app says the user is, and it never sits in your login flow. When a Feature calls one of your tools, the call lands in your code with whatever session and identity context your app already had.

Data handling

A Feature only ever sees what the host hands to it through tools and context. If a tool returns a redacted record, the Feature only sees the redacted version. If the host doesn't expose a piece of data, the Feature has no way to obtain it.

Some data does flow through our own systems: Feature definitions, build artifacts, and product management content. Our privacy policy covers all of it, including how we use AI providers, and it's the canonical source rather than this page.

The AI provider question

Rough uses third-party AI providers to build Features. Per our privacy policy, we don't permit those providers to train on customer data, and we don't store AI prompts or outputs beyond what we need to deliver the Feature you asked for. If your compliance team needs the specific list of providers, contact us.

Workspace isolation

Rough is multi-tenant, and a workspace is the top-level boundary. We scope everything below it, projects, surfaces, features and members, to a single workspace, and nothing in the product reads across that boundary.

On your side

Most of the risk in an integration sits on your side of the bridge. We recommend you:

• Treat every tool as a public API. Validate inputs, check authorisation, and rate-limit where it matters.
• Be explicit about which Surfaces exist in your product. Embedding a Surface is a deliberate choice, not a default.
• Watch the management dashboard. It shows what's been built, who built it, and which Features are getting used.

Still being added

We'd rather write down what Rough does today than promise something we haven't formalised. As we publish more, independent assessments, standards alignment and regional data residency options, we'll add the detail here.

If you have a specific security question, get in touch.