Every sentence on this page is one we can stand behind today.
Security questionnaires ask the same questions in a different order. This page answers them once. When something changes, this page changes the same day.
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 sends AgentValet a signed request.
AgentValet checks the agent’s status, its grant for that tool and scope, your organisation’s guardrails and policy, the grant’s expiry, the circuit breaker and, for a child agent, its parent’s standing. If a person must agree, the call waits while the owner approves on another device. Only then is the credential decrypted in memory, attached to the real request, and dropped. Every decision, whether allowed, held or refused, writes an audit row.
- Control plane
- The broker API, the OAuth token broker and the dashboard, hosted by us in Australia. Credentials, grants and audit records are stored and processed there. Sign-in, email and billing use the overseas providers named below. Need data held in another region? We can stand one up for you.
- On your side
- The MCP server, the command-line tool, the client SDKs and the adapters run on your machines under the MIT licence. They hold the agent’s signing key and nothing else. The 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 without reading our code. Read the docs.
Where your credentials physically live.
In Australia, in two encrypted stores that we run. Never on your machines, and never in the agent.
Our PostgreSQL database
Most credentials: OAuth tokens, connection secrets and app keys. Each is encrypted with its own key, and that key is locked with your organisation’s key, which sits in Key Vault.
The OAuth token broker’s store
The software that refreshes OAuth tokens runs in our own infrastructure in Australia and keeps its own encrypted copy. A small number of API-key connections are still held only here while we move them onto per-organisation encryption.
If this matters for your risk assessment, the security pack sets out exactly how that store is protected and our timeline for the move. We share it under NDA.
What we hold, and how.
Everything is encrypted in transit with TLS, including between our own components. We don’t claim end-to-end encryption in the messaging sense: the broker has to see a request to attach the credential to it.
| Data | How it is handled |
|---|---|
| Platform credentials | Encrypted at rest, decrypted in broker memory for one call, never logged, never returned to the agent, and deleted when you disconnect the tool. Where they are stored is set out above. |
| Agent signing keys | Generated on your machine by the installer; we store the public half only. Two setup paths generate the key on our side instead: adding a Claude Desktop agent from the dashboard, and accepting a teammate invite. There we hand the private key over once and keep no copy. Published as a did:web document if your organisation opts in. |
| Request and response payloads | Pass through the broker in memory and are not stored. Requests are screened for secrets and unsafe destinations before any credential is touched. If your organisation turns it on, responses on scopes you tag as personal data have fields redacted by name and pattern. |
| Audit rows | Who called, which agent, tool, action and scope, the decision, the policy version that made it, a request id, and a session id when the client sends one. The table accepts new rows only; nothing in the product edits or deletes a past row. IP address, user agent and location are recorded only on Enterprise, and only after a second opt-in. |
| Owner accounts | Name, email and sign-in events are held by our identity provider. Billing details are held by our payment processor. We never see card numbers. |
The key hierarchy is set out in detail in the security architecture.
Who else touches the data.
Named, 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-processor | Purpose | Data it can see |
|---|---|---|
| Vultr (Australia) | The host that runs the broker API and the OAuth token broker | Request bodies in transit, and the token broker’s encrypted credential store |
| Cloudflare (global network) | The encrypted tunnel into the broker; hosting for the dashboard, this site and the docs; DNS and caching | Request metadata and cached public files |
| Supabase (Australia) | PostgreSQL for the audit log, encrypted credentials and per-organisation isolation; file storage for installers; background functions | All stored application data |
| Microsoft Azure Key Vault (Australia) | Organisation keys: held in hardware on paid plans, derived per organisation on Free | Keys only, never a credential |
| Clerk (United States) | Owner sign-in, sessions, multi-factor authentication and single sign-on | Owner email and sign-in events |
| Stripe (global, including the United States) | Subscriptions and payments | Billing email and payment metadata, never a platform credential |
| Resend (Tokyo, Japan) | Transactional email: approvals, sign-in links, onboarding | Owner email addresses and notification subjects |
| The platforms you connect | Each tool you authorise receives the calls your agents make to it | Whatever an agent sends to that tool |
The OAuth token broker is software we run on our own host, not a third party. We’ll email you before adding a sub-processor that can see customer data.
How long things are kept.
- Audit log
- Visible for your plan’s window: 3 days on Free, 30 on Solo, 90 on Studio and 365 on Team, and a custom period on Enterprise. A daily job deletes rows older than both your window and a 90-day floor, so nothing under 90 days old is ever deleted. Export as CSV or JSON, or print a PDF report from the dashboard, on Team and above.
- Credentials
- Deleted when you disconnect the tool. Suspending or revoking an agent voids its grants at once and revokes the refresh tokens we issued it.
- Accounts
- To close an organisation and remove its owner data, email [email protected]. Audit rows follow the rule above, and we confirm in writing when the deletion is done.
- Anonymous trials
- The no-signup trial is the exception to all of the above: unless you claim it into an account, the whole trial organisation is deleted after 24 hours. Trial organisations can’t store credentials at all.
Found something? Tell us first.
Email [email protected]. Every report is read by a person, not a bot.
Include a clear description of the issue, steps to reproduce or a proof of concept, and any test credentials we should rotate afterwards.
- 2business days to acknowledge your report
- 10business days to a triage decision
Critical issues, such as a credential exposed remotely, audit-log tampering or a way around authentication, are treated as page-out events.
Safe harbour. Good-faith research that respects user privacy, avoids taking data and reports privately to the address above is welcome, and we won’t pursue it legally or report it to law enforcement. A machine-readable copy of this policy is at /.well-known/security.txt on each of our hosts.
What is checked, and by whom.
Automated checks
Every push runs the full test suite before it can land, including contract tests that hold the published API document to the live routes. The deploy job confirms the build being served is the commit that was pushed.
Third-party penetration test
Planned, not yet booked. When a report exists it will be available under NDA, and this line will say so.
Availability
A canary exercises a real governed call every five minutes and raises a banner in the dashboard when something degrades. The API, dashboard, website, docs and receipt keys are checked independently every five minutes, and the results are public. See live system status.
Where we stand on each framework.
Where a competitor claims certification and we claim alignment, the difference is deliberate. Alignment is our own assessment, not a certificate.
| Framework | Status today | Notes |
|---|---|---|
| SOC 2 | Not started | Type I is the first target. The controls that exist as code and CI are documented; an auditor, a compliance platform and the people-and-process controls are the remaining work. |
| Independent penetration test | Planned, not yet booked | When a report exists it will be available under NDA, and this row will say so. |
| ISO/IEC 27001 | Not certified | Not currently planned. |
| Privacy: GDPR and the Australian Privacy Principles | Designed for it | We hold credentials and decision records, not request contents. A data-processing agreement is available on request. Data stays in Australia for every customer; there is no EU region. |
| ISO/IEC 42001 (AI management) | Self-assessed | Our own mapping of controls, not a certificate. |
| NIST AI Risk Management Framework | Self-assessed | Mapped to the Govern and Manage functions. Our own assessment. |
| OWASP Top 10 for LLM, Agentic and API security | Self-assessed | A written control mapping, sent on request. |
| OWASP Non-Human Identity Top 10 | In progress | Mapping under way. |
Need the long form?
Security questionnaires, a data-processing agreement, or a walkthrough of the key hierarchy with your security team. Email and you’ll get a direct answer, usually the same day.
Email [email protected] and a real person reads it and writes back. No ticket queue.