Legal
DPA
Last updated 24 September 2026
This document is a working draft published for transparency about how the product is built. It has not completed legal review and is not a contract. The executed agreement for your account is the one you sign.
Roles
For the business data your agents read and act on, you are the controller and we are the processor. For account data about your own developers and administrators, we are the controller.
Instructions
We process data on your documented instructions, which are the configuration of your account: the systems you connect, the capabilities you grant, the limits you set, the approval rules you choose and the agents you deploy.
An agent's manifest is part of those instructions. It is a declarative record of what you authorised, which is why we enforce it rather than a prompt.
We do not process your data for any other purpose, and we do not use it to train models made available outside your account.
Security measures
Encryption in transit and at rest. Isolation between organisations enforced at the record level — cross-organisation reads are not a permission anybody can be granted.
Each agent holds its own machine identity. No agent shares a credential with another, so revoking one affects only that one.
Credentials for connected systems held in a vault, scoped by agent, environment and tool, injected at call time and never placed in an agent's context. Redacted from logs, traces and error messages.
Default-deny outbound network policy per agent. Blocked connection attempts are recorded against the agent and its version.
Isolated execution per run, with resource limits and a clean environment. Nothing carries between runs except memory scopes you configured.
Access to production restricted, time-bound, logged and reviewed. Every consequential action recorded with its actor, version, inputs, policies applied and result — including actions taken by automation.
The agent layer
An agent executes with only the capabilities granted to it. There is no separate, broader path for agent access, because a second permission model would eventually diverge from the first and the divergence would be a breach.
Capabilities that move money or change access are refused to every agent on every plan. This is enforced at the capability rather than left as configuration.
Content held in or reaching the system — message bodies, attachments, imported documents, event payloads — is treated as data and cannot act as an instruction to an agent.
Categories you mark sensitive are excluded from agent processing and from model requests by default.
An approval cannot be granted by another agent or by an API key. The point of an approval is that a person decided.
Sub-processing
We use the sub-processors listed on the subprocessors page. We give notice before adding one, and each is engaged under terms no weaker than these, including the prohibition on training.
Assistance and audit
We assist with data subject requests, impact assessments and incident notification within the timelines your agreement sets. Because your customers' requests come to you, that assistance is oriented towards helping you answer them.
Because grants, approvals, versions and actions are all recorded with their actor when they happen, most audit questions about a specific action can be answered from the record rather than by investigation.
Deletion and return
On termination, data is returned or deleted at your election within the period your agreement sets. Export of agents, manifests, run history and audit records remains available throughout the term and during any wind-down period.
Give AI a job.
Build an agent, choose what it can access, define what it may do, and deploy it to work safely across your business.
No code required · Full SDKs and API · Stop any agent instantly · [email protected]