Trust Centre
Your agents operate inside boundaries you define.
Written for whoever has been asked to sign off on letting software act on your company's behalf. Every section below says what is not true as well as what is, because a trust page listing only reassurances is the one nobody believes.
Identity
Every agent acts under its own machine identity rather than a shared credential. Without that there is nothing to permission, nothing to audit and nothing to revoke without breaking everything else using the same key.
- One identity per agent, recorded on every action with the agent's version
- No agent shares a credential with another agent or with a person
- Revoking one agent affects only that agent
- Every consequential action records whether a human or an agent did it
Capability authorisation
An agent can call the capabilities it was granted and has no other route into a connected system. Authorisation happens at the capability, in the platform, after the model has decided to attempt something — not as an instruction in a prompt.
- Default deny: a new agent can do nothing at all
- Three states per capability — allowed, needs approval, never
- Capabilities that move money or change access are refused on every plan
- Record-level scoping, so an agent reads its own accounts rather than all of them
- Refusals are enforced at the call, never requested in a system prompt
Secrets
Credentials for connected systems are held in a vault, scoped by agent, environment and tool, and injected at call time. They never enter an agent's context, which is what stops them being repeated by a model or read out of a log.
- Never placed in a prompt, a manifest or agent code
- Scoped three ways: by agent, by environment, by tool
- Rotation updates the vault and redeploys nothing
- Redacted from logs, traces and error messages
- Card data is held by our payment processor and never by us
Network and isolation
Each run executes in an isolated environment with its own resource limits and a default-deny outbound network policy. One agent's execution cannot observe or affect another's, and isolation between organisations is enforced at the record level.
- Nothing reachable on the network until a granted tool makes it reachable
- Four network modes, from connected tools only to no outbound access at all
- Blocked connection attempts recorded against the agent and its version
- Nothing carries between runs except memory scopes you configured
- Cross-organisation reads are not a permission anybody can be granted, including us
Audit
Every consequential action records its actor, the agent version, what triggered it, the capabilities called, the inputs, the approvals obtained, the policies applied and the result — written as it happens rather than reconstructed afterwards.
- Append-only for its retention period, including for administrators
- Automated actions record the rule as their actor
- Approvals record who decided, when, and what they were shown
- Filterable by agent, person, customer, capability, risk level and date
- Simulated and local runs are marked as such and cannot be mistaken for real ones
Data and retention
Retention is set per category, because the obligations genuinely differ between run data, audit records, agent memory and business data reached through a capability. Nothing is retained indefinitely by default.
- Per-category retention, configured by you
- Memory scopes each carry their own period; task and temporary scopes are destroyed at the end of a run
- Export of agents, manifests, run history and audit records on every plan
- Return or deletion on termination, at your election
- Records under legal hold are retained regardless, and the hold is visible and attributed
Models, and what we will not do with your data
Model providers are engaged per task and under terms that prohibit training on account content. Which provider handles which task is a platform decision; on some plans you can supply your own.
- Your agents' work, records and knowledge are not used to train models available outside your account
- That is a contractual commitment, not a setting, and it binds our providers
- Categories you mark sensitive are excluded from model requests by default
- Content from outside — messages, attachments, imported pages, event payloads — is data and cannot instruct an agent
- No product output scores or characterises an individual, and no team-monitoring tooling exists
What this does not do.
It does not make you compliant with anything. No configuration of any software does that. What it produces is evidence that may be useful to a compliance process — who granted an agent what, when, why, what it did and who approved it — recorded as a by-product of working rather than assembled afterwards.
It does not make an agent safe to point at anything. A correctly permissioned agent with a badly chosen job will do the wrong thing reliably and within its limits. Which jobs are appropriate is your decision, and the defaults here are conservative rather than correct.
It cannot judge content. An agent permitted to email customers can send a badly worded email, and no boundary catches that. Nor can it undo what it already did: stopping an agent stops the agent, and a sent message stays sent — which is why the boundaries and budgets exist ahead of the emergency stop rather than instead of it.
It does not vouch for the systems you connect. An action taken in a connected system is recorded as one we requested, and as whatever that system chose to record on its side.
Reporting something.
If you believe you have found a vulnerability, write to [email protected] and we will acknowledge it. Testing against your own workspace and its sandbox is welcome; testing against another organisation’s data is not, and is a breach of the acceptable use policy rather than research.
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]