Identity & access · Integrations
Connect anything. Your agents never touch the keys.
External services connect to Quox through the vault. An agent calls the tool it needs; the credential behind it stays server-side, and every use leaves a receipt.
What it is
One connection, made once, used everywhere.
An external service is connected once, through the vault, not pasted into every agent that needs it. Agents call it through a governed tool, and the secret behind that tool never reaches the agent, the model, or the browser: only the platform's server-side layer ever holds the raw value.
How it works
Store it once. Resolve it just-in-time. Receipt every use.
Store the credential
A secret is written to the vault once, encrypted with keys scoped to your own organisation, never a shared key across tenants.
Resolve it just-in-time
When a governed tool call needs the credential, the platform resolves it at the moment of use. It is never handed to the agent or the model ahead of time.
The call runs, and lands as a receipt
The external call executes server-side, and its use of the credential is written to the evidence trail: who, when, which tool, no secret value in the record.
Three properties
What holding the secret this way buys you.
Server-side only
Secrets never return to the frontend or the model. A prompt, a log, or a transcript never carries the raw value.
Per-organisation keys
Each organisation’s credentials are encrypted under its own key, so one tenant’s vault gives another nothing to read.
Every use receipted
Each integration call leaves an evidence entry: which credential, which tool, when, and the outcome.
Wired today
11 executable connectors your agents can drive today.
More land each release. The rest of the catalogue below is credential types the vault already stores and tests, waiting on a connector.
See it
Where you add one.
The vault's browse view inside the dashboard: search the catalogue, pick a service, and connect it. The credential is written to the vault, and from then on agents reach the service through a governed tool, never the raw secret.
The full catalogue
413 integration types, 11 executable connectors.
The vault stores and tests credentials for 413 named providers. 11 of those have a registered connector an agent can run a tool against today; the rest are credential types the vault can hold, with no agent tool wired to them yet. The full 413 live in one place, not repeated here.
Honest status
What is live, and what is still on the way.
The vault, per-organisation encryption, just-in-time resolution and receipted use are shipped and in use today. Named external connectors are the next layer on top, and are not claimed as shipped until they are.
- The vault itself: credentials stored server-side, never returned to the frontend or the model
- Per-organisation encryption keys, so one tenant’s secrets are unreadable to another
- Just-in-time resolution: a credential is fetched at the moment a governed tool call needs it, not handed out ahead of time
- Governed tool calls that use a stored credential to reach an external service
- A receipt on every use: which credential, which tool, when
- Further named external connectors (Google Drive, Gmail among them) beyond the 11 wired today
- A guided connect flow per named service, rather than storing a raw credential by hand
See it in place
Read how the vault holds the secret.
Integrations sit on top of the vault, which sits inside identity and access: one credential store, per-organisation keys, and a receipt on every use.