Architecture

A broker between your agents and the systems they act on.

Your agent registers once and holds a signing key, never a platform credential. When it wants to act, it calls the broker with a signed request. The broker checks the agent's status, its grant for that platform and scope, your organisation's guardrails and policy, the grant's expiry, the circuit breaker and, for child agents, the parent's standing. If the rule says a human must agree, the call pauses and the owner approves out of band. Only then is the credential unwrapped in memory, attached to the real request, and dropped. Every decision, allowed, held or refused, writes an audit row.

Control plane
The broker API, the OAuth token broker and the dashboard. Hosted by us in Sydney, Australia. All customer data is stored and processed in that region; there is no customer-selectable region today.
On your side
The MCP server, the CLI, the client SDKs and the broker library run on your machines under the MIT licence. They hold the agent's signing key and nothing else. Source is public.
The gate contract
What a governed call is, what a refusal looks like, and what an approval hold means are written down as a public contract, so a client can be built against it without reading our code. Read the docs.
Data handling

What we hold, and how.

DataHow it is handled
Platform credentialsEnvelope encryption: one data key per credential, wrapped by a per-tenant key. On paid plans the tenant key lives in a hardware security module and never leaves it. On the Free plan the tenant key is derived from a master secret held in the same module; it is isolated per tenant but not a dedicated hardware key. Credentials are decrypted in broker memory at call time only, never logged, never returned to the agent, and deleted when you disconnect the platform.
Agent signing keysGenerated on your device. We store the public half only. Published as a did:web document when your organisation opts in.
Request and response payloadsPass through the broker in memory and are not persisted. Requests are screened at the boundary for secrets and unsafe destinations before any credential is touched. On scopes you tag as handling personal data, field-name and pattern-based redaction is applied to responses when your organisation turns it on.
Audit rowsWho called, which agent, platform, action and scope, the decision, the policy version that decided it, and a request id. The table accepts inserts only; no path in the product edits or deletes a past row. IP address, user agent and geolocation are recorded only on Enterprise and only after a second opt-in; the agent's session id is recorded on every plan.
Owner accountsName, email and login events are held by our identity provider. Billing details are held by our payment processor. We never see card numbers.

Encryption in transit is TLS everywhere, including between our own components. We do not claim end-to-end encryption in the messaging sense: the broker must see the plaintext request to attach the credential to it. The security overview has the key hierarchy in detail.

Sub-processors

Who else touches the data.

This is the one place on our site that names vendors, because you need the real names to assess them. Each sub-processor's standard data-processing terms apply. We share customer data with no other party.

Sub-processorPurposeData it can see
Vultr (Sydney)Compute for the broker API and the OAuth token brokerRequest bodies in transit; wrapped credentials at rest on the broker's database volume
CloudflareIngress to the broker, static hosting for the dashboard, this site and the docs, DNS, edge cachingRequest metadata, cached static assets
Supabase (Sydney)PostgreSQL for the audit log, credential metadata and row-level tenant isolation; storage for installer distribution; edge functionsAll persisted application data
ClerkOwner identity, sessions, multi-factor authentication, single sign-on federationOwner email, login events
Microsoft Azure Key VaultHardware-backed key-encryption keys for paid organisations, and the master secret that Free-plan tenant keys are derived fromWrapped keys only; never a credential
StripeSubscription billing and paymentsBilling email and payment metadata; no platform credentials
ResendTransactional email: approval notifications, sign-in links, onboardingOwner email addresses and notification subjects
The platforms you connectEach platform you authorise an agent for receives the calls that agent makes through the brokerWhatever the agent sends to that platform

The OAuth token broker runs on our own host and is not a third party. We will notify you by email before adding a sub-processor that can see customer data.

Retention

How long things are kept.

Audit log
Visible for your plan's window: 3 days on Free, 30 on Solo, 90 on Studio, 365 on Team, multi-year on Enterprise. A daily job purges rows older than both the plan window and a 90-day floor, so nothing under 90 days old is ever deleted. Export in CSV, JSON or PDF on Team and above.
Credentials
Deleted when you disconnect the platform or revoke the agent. Upstream refresh-token chains are revoked with the provider where the provider supports it, so access cannot be quietly resumed.
Accounts
Revoking an agent voids its grants and deletes its credentials immediately. To close an organisation and remove its owner data, email [email protected]; audit rows follow the retention rule above and we confirm in writing when the deletion is done.
Vulnerability disclosure

Found something? Tell us first.

Email [email protected] with a clear description of the issue, steps to reproduce or a proof of concept, and any test credentials we should rotate after the report. We acknowledge receipt within two business days and give a triage decision within ten. Critical issues (remote credential exposure, audit-log tampering, authentication bypass) are treated as page-out events.

Safe harbour. Good-faith research that respects user privacy, avoids data exfiltration and reports privately to the address above is welcome and will not be pursued legally or reported to law enforcement. A machine-readable copy of this policy is at /.well-known/security.txt on each of our hosts.

Testing and assurance

What is checked, by whom.

Automated
Every push runs the full test suite before it can land, including contract tests that hold the published API document to the live route table. The deploy job verifies that the build being served is the commit that was pushed.
Third-party penetration test
Not yet performed. Scheduled ahead of the SOC 2 Type I assessment. When the report exists it will be available under NDA and this tile will say so.
Availability
A canary probes the governed path continuously and raises an in-app degraded banner. There is no public status page yet; one is planned. Uptime figures will be published when we have twelve months to show.
Compliance status

Three lines, each true.

FrameworkStatus today
SOC 2Programme not yet started. The controls that exist as code and CI are documented; the people-and-process controls, an auditor and a platform are the remaining work. Type I is the first target.
ISO 27001Not certified and not currently planned.
GDPR and Australian Privacy PrinciplesPrivacy-by-default design: credentials only, payloads not persisted, personal-data fields opt-in per organisation. A data-processing agreement is available on request. Data residency is Australia for all customers; there is no EU region today.
ISO 42001, OWASP NHI and LLM Top 10, NIST AI RMFAligned, with a published control mapping. Alignment is our own assessment, not a certification.

If a competitor's page says "certified" and ours says "aligned", that is deliberate. We would rather you find out here than in the questionnaire.

Need the long form?

Security questionnaires, a data-processing agreement, or a walkthrough of the key hierarchy with your security team. Email and we will answer directly, usually the same day.