Security
Security, stated plainly
Every statement on this page is checked by an automated test that runs on every change. Your IT team can ask for the evidence pack: the design documents and the list of tests behind each claim, shared under NDA.
Last reviewed 2026-10-21.
Your data stays separate
Each workspace is kept apart in three layers, and the database is the last line of defence.
Membership is checked on every workspace request
Someone who isn't a member of a workspace gets “not found” for everything in it, they can't even tell it exists.
The database enforces separation too
PostgreSQL row-level security applies to every table that holds workspace data. The app connects as a database role that cannot bypass it, and the API checks this when it starts.
It fails closed
If a request reaches the database without a workspace set, the database returns nothing rather than everything.
New tables can't skip the rules
A guard test fails if any table with workspace data is added without a row-level security policy. Writes into another workspace are rejected by the database.
The database checks the rules as well
The database itself rejects invalid records, such as an unknown role, and the latest schema change is tested to upgrade and roll back cleanly.
Tested against a real database
These tests run against real PostgreSQL as the same non-owner role the app uses in production. The CI workflow is set up to run them on every pull request.
Your keys and secrets
AI provider keys and app sign-ins are the most sensitive things you give us. Here is how they are handled.
Keys are checked before they're saved
We make a small real call to your AI provider. A key that doesn't work is not stored.
Encrypted with a key of their own
Each secret is encrypted with its own random data key (AES-256-GCM), and that data key is itself encrypted. Both are bound to your workspace and the record, so an encrypted value copied anywhere else can't be decrypted.
Never shown again
After you save a key, no part of AQL Cloud returns it, you only see its last 4 characters.
Removing a key really removes it
The encrypted copy is deleted straight away, and agents that relied on the key stop until you add a new one.
App connections get the same care
Sign-ins for apps such as Gmail and Slack are stored encrypted, refreshed automatically, and revoked and deleted when you disconnect.
Secrets stay out of logs
Logs and the activity log mask keys, tokens and passwords before anything is written.
Encryption keys can be rotated
Operators can add a new encryption key without losing access to existing secrets. In the AWS reference deployment, secrets live in AWS Secrets Manager, encrypted with a KMS key.
People stay in control of actions
Agents can only do what you allow, and sensitive actions wait for a person.
Only the actions you grant
An agent can't do anything you haven't allowed. Every action is checked again on our servers, the grant, the permission level and the exact inputs, before it runs, and a browser can't skip the check.
Approvals run exactly what was reviewed
A sensitive action, such as posting to Slack, is frozen and waits for an admin. Approving it runs the stored action exactly as reviewed, once. Members can't approve, and declined actions never run.
Outside content is treated as data
Text from emails, documents and messages is labelled as untrusted before the agent sees it. Safety doesn't rely on that label: writing and sending still need a grant and, where you choose, an approval.
Apps can only reach their own services
Each app connection may only call its provider's listed web addresses, and requests to private or internal network addresses are refused.
Limits on every request
Each request has limits on steps, time and usage, and agents that are paused or archived never run.
A record of who changed what
The activity log records changes to agents, apps, people and approvals.
Entries can't be edited or deleted by the app
The database role the app uses can add to the activity log but cannot change or delete entries.
Secrets are masked before they're recorded
Details are cleaned of keys and tokens before an entry is stored. Approval decisions and their outcomes are recorded.
Kept for 400 days
Activity log entries are kept for 400 days, including after a workspace is deleted, for security investigations. Older entries are removed by a daily job.
Your data, on your terms
Export, deletion and automatic clean-up are built in, useful when you answer to GDPR.
Download a copy of your data
Admins can download everything in a workspace as one file. Keys, app sign-ins and other secrets are never included.
Delete a workspace or an account
Admins can delete a workspace after typing its web address to confirm. People can delete their own account; the only admin of a shared workspace is asked to make someone else admin first.
History is cleaned up automatically
Conversations and runs older than the period you set (30 to 3,650 days; 365 by default) are deleted by a daily job, for your workspace only.
Sign-in and sessions
Standard, well-reviewed building blocks, no home-made security protocols.
Passwords are hashed with argon2id
We never store passwords, only argon2id hashes. Failed sign-ins are recorded without the password.
Short sessions that rotate
Access lasts 15 minutes. The longer-lived sign-in cookie can't be read by page scripts and changes every time it's used; if an old one is reused, every session from that sign-in is ended.
Sign-in attempts are rate limited
Sign-in attempts are limited per email address and per network address.
Works with your identity provider's tokens
AQL Cloud can verify sign-in tokens from an OpenID Connect identity provider such as Keycloak, Auth0 or Zitadel. A “Continue with SSO” sign-in page is not available yet, see below.
Production refuses unsafe settings
In production the API refuses to start with insecure default settings, or if the database would let it bypass row-level security.
Where it runs
Use our hosted service, or run AQL Cloud yourself, in your own cloud account and region. Self-hosting comes with an installation guide and support; ask us to get started.
Docker Compose
The full stack on one machine, database, cache, file storage, API, background worker and console.
Helm chart
For an existing Kubernetes cluster.
Terraform for AWS
A reference setup in your own AWS account and region: private networks, encrypted database and storage, TLS-only connections and least-privilege access. Nothing is created until an operator reviews and applies it.
What we don't have yet
Being clear about the gaps is part of being trustworthy. We update this list as they close.
No SOC 2 report or ISO 27001 certification
AQL Cloud doesn't claim any formal compliance certification. A SOC 2 readiness review is planned.
No single sign-on page yet, and no SAML
“Continue with SSO” using OpenID Connect is planned. SAML isn't planned directly; most identity providers offer an OpenID Connect option instead.
No third-party penetration test yet
The protections above are checked by our own automated tests. An independent test hasn't been done.
Live AI calls proven with Anthropic only
As of 2026-10-21, Anthropic is proven against the live service. OpenAI and Google Gemini are tested against recorded provider responses.
Some things haven't been run end to end yet
The Docker Compose stack and the CI workflow are written but haven't been run end to end yet. App connections (Gmail, Google Drive, Slack) are tested against faithful copies of those services, not real accounts.
Shared runtime
In our hosted service, workspaces share the same servers and are separated as described above. A dedicated runtime per workspace isn't built, self-hosting is the way to get your own.
A known limit of AI agents
An agent that's allowed to read something could repeat it in a chat. We label outside content as untrusted and gate writing and sending, but can't fully prevent this, so give agents only the access they need.
Found a security problem?
See it for yourself
Create a workspace, or ask us for the security evidence pack.