AI security

You don’t need trust when you can verify

That is Quox’s approach to AI security. You hand an agent platform your vault credentials, fleet access, plans and agent memory; promises are not enough. Quox is self-hosted, evidence-first, and every claim here states how to check it.

See the evidence chain Report a vulnerability

A single activity log entry opened out into its full trace

protocols4aocl layers11enforcing gatesL3 + L8deploymentself-hostedverifyevery claim

QuoxTrust

v1.8 Resource & Abuse Bounds: PASS

Passed 2 Oct 2026 · release blockers deployed and resolved

What we proved

T10 bounded resource consumption (spend, concurrency/rate, exec-time/output/payload, queue depth, loop triad)

What we have not proved

Hostile third-party plugin isolation -> v2.0 (design).
Network-layer DDoS / edge rate limiting (infra concern).
Load/throughput benchmarking (bar is bound-existence + durability, not perf).

3 findings raised · release blockers resolved · remaining debt published below

See exactly what passed Recompute the evidence Audit us yourself See all nine bars

Explore the full evidence wiki

In plain words

What it is, where it lives, when to reach for it

What is it: The security reference for QuoxCORE: how the platform holds secrets, sessions, credentials and agent permissions.
Where do I use it: On every self-hosted instance; the controls described here ship in the default install.
When would I use it: When your security team asks what running self-hosted AI agents actually exposes.
How do I use it: Read the controls below, then check each one on your own install; none needs a vendor account.

QuoxCORE is the free, self-hosted platform underneath this. What is QuoxCORE

Trust surface

What you entrust to your Quox server

A control plane holds the most sensitive things you own, and with Quox it holds them on your own hardware. Naming that surface plainly is where AI security starts: here is what your Quox server holds, where it lives, and how you check what happens to it. None of these entries asks for your confidence; each one says how to verify it.

Infrastructure

What never leaves your box

Quox runs on hardware you own. There is no shared cloud tenancy, no data exfiltration to third-party analytics, and no vendor lock-in. The entire platform deploys as Docker containers on your servers.

Self-hosted architecture. Docker Compose deployment on your own servers, no cloud account required. Data, models and configuration remain within your network perimeter.
Network isolation. The SSH bastion, QuoxBastion, provides the only external entry point to your fleet. Internal services communicate over private networks with no public exposure.
No vendor lock-in. Open protocols and standard formats throughout. Your data lives in SQLite, PostgreSQL and Qdrant with documented schemas. Export everything at any time.

self-hosted

It all stays in your building.

The agents, the memory, the keys and the evidence run on hardware you own, behind your own door. Nothing is shipped to a shared cloud to make it work.

Protocols

Cryptographic evidence at every step

Every agent action is hashed with SHA-256 and appended to a chain where each record binds the hash of the one before it. Any modification to historical records breaks the chain and is immediately detectable. This is AI accountability in practice: you reconstruct what an agent did from the record instead of taking anyone’s word for it. Try it below.

evidence chain · recreationverified

each block binds prev · SHA-256 · Ed25519 signatures · RFC 3161 timestamps

This is a recreation of the evidence surface, not a screenshot. The real ledger, VOLT, is an append-only, hash-chained event log using SHA-256, with Ed25519 digital signatures and RFC 3161 timestamps. WARD adds content-free witness receipts for external attestation without exposing operational data.

Self-audit

We audit ourselves and publish the log

Anyone can claim to take security seriously. We run an adversarial audit against our own repositories, file every finding in the same engagement store our customers use, fix what it proves, and publish the log here, witnessed on the production WARD chain. Open findings are published too: a log that only ever shows green is indistinguishable from no audit at all.

cycles4findings49fixed44open5

Every cycle, every finding (fixed and still open), the controls that held, and the WARD receipt for each, published in full on the evidence wiki.

The full per-cycle audit log

Witnessed SEO

Witnessed SEO on real production deployments

Every crawl of every site we run is captured as a signed, hash-chained WARD receipt. This band is recompute-gated (it only appears because each chain re-verified at build time) and every business below is visitor-recomputable: download the bundle and check any chain yourself, offline, no trust required.

generated 2026-09-28T13:15:21Z

8 businesses, 226 witnessed crawls, every one recomputable

Verify any business yourself, offlineverified

One bundle covers every site below. Download it, run the recompute command for any business, and the chain rebuilds its hashes and checks its signature on your own machine: no trust required, and no call back to us.

recompute command (general form)

node recompute-chain.mjs <site>-chain.json quox-seo-pubkey.pem

Download the verification bundleverifier commit 5415009

quox.aiverified

entries69signatures1

node recompute-chain.mjs quox.ai-chain.json quox-seo-pubkey.pem

mountfolly.co.ukverified

entries32signatures1

node recompute-chain.mjs mountfolly.co.uk-chain.json quox-seo-pubkey.pem

hottubshampshire.co.ukverified

entries32signatures1

node recompute-chain.mjs hottubshampshire.co.uk-chain.json quox-seo-pubkey.pem

poolpro.co.ukverified

entries29signatures1

node recompute-chain.mjs poolpro.co.uk-chain.json quox-seo-pubkey.pem

nodevpn.comverified

entries26signatures1

node recompute-chain.mjs nodevpn.com-chain.json quox-seo-pubkey.pem

www.poolpro.co.ukverified

entries23signatures1

node recompute-chain.mjs www.poolpro.co.uk-chain.json quox-seo-pubkey.pem

hostnode.ioverified

entries11signatures1

node recompute-chain.mjs hostnode.io-chain.json quox-seo-pubkey.pem

skillrights.orgverified

entries4signatures1

node recompute-chain.mjs skillrights.org-chain.json quox-seo-pubkey.pem

Governed engagements

The same governed scans, on real production deployments

The self-audit above is us auditing ourselves. This is the platform doing the actual job on real, external production sites: every target proves control before a single scan runs, every scan passes the same governed approval-grant path as any other risky action, and every step is witnessed on the production WARD chain. Customer identities are redacted; the scope, severities and receipts are not. This band grows as more deployments are scanned.

engagements1findings3

Every engagement, finding and receipt

QuoxTrust bars

Raised and passed, one version at a time

A bar is a named set of trust properties, challenged under a real engagement, and only published once it passes. Debt named at pass time is carried forward in the open, not hidden: a bar that excludes something by name is more credible than one that implies nothing was excluded.

bars banked9latestv1.8 PASS

The full trust-ladder story Per-cycle detail and receipts

Audit us

Don't take our audit on faith. Run your own.

The log above is our audit. This is yours. Paste this prompt into the AI coding agent you already trust, point it at our public repositories, and let it hunt. It is written to be hostile on purpose: we would rather you find something than trust that we did.

hostile-auditor prompt

You are a hostile third-party security auditor. Your client is about to hand this platform, Quox, the keys to their kingdom: the secrets in their vault, root SSH to their entire fleet, their roadmap, and their agents' long-term memory. Assume the vendor is lying to you. Your job is to find the knife before it goes into your client's back.

Clone these repositories: github.com/quoxai/aee, github.com/quoxai/aocl, github.com/quoxai/volt, github.com/quoxai/ward, github.com/quoxai/quoxmcp, github.com/quoxai/quoxproof. Read them like you expect to find betrayal, because your reputation is on the line if you miss it.

Hunt, and cite every finding by file and line:
1. Credential theft surface. Where do vault secrets and customer credentials live, how are they encrypted at rest, and is there ANY path (a log line, error handler, debug dump, exception tracker, telemetry) that could print or exfiltrate them in plaintext? Assume any denylist filter leaks and prove it.
2. Phone-home. Does anything leave the customer's box that they never asked to send? Analytics, crash reports, licence pings, model calls, update checks. Name every outbound destination and exactly what rides with it.
3. SSRF and egress. Every server-side fetch of a user-influenced URL. Can you make the server hit a cloud metadata endpoint, the internal network, or its own vault?
4. Auth boundaries. Every route reachable without authentication or across a tenant boundary. Try to read another org's data. Try to escalate.
5. The fleet backdoor. This software executes commands on the customer's own hosts. Show exactly what it can run, who authorises it, and whether that authorisation can be bypassed, forged, or replayed.
6. Supply chain. Dependencies with known CVEs, unpinned versions, curl-pipe-bash installers, postinstall hooks.

Then the part vendors hate: confirm the running artifact matches the source. Does the published image digest correspond to this code, or could the shipped binary do something the source does not?

Be brutal. Separate what you can PROVE from what you merely suspect, rank findings by how badly they betray the customer, and if you find nothing, say why you believe that, because 'looks fine' is not an audit.

Public today

These are live on GitHub now. They are the evidence and protocol layer the rest of the page rests on, so this is where verifying our claims actually starts.

quoxai/aeethe envelope protocol every action is recorded as
quoxai/aoclthe governance / control-layer spec
quoxai/voltthe hash-chained evidence log format
quoxai/wardthe tamper-evident witness receipts
quoxai/quoxmcpthe MCP bridge agents call tools through
quoxai/quoxproofthe offline-verifiable tool-call receipt SDK

The vault, fleet control and core platform repositories are private today. They open for public audit at our source-availability release, and this prompt's repo list grows to cover them then. We will not invite you to audit code you cannot yet read.

Open protocols

Four protocols, one trust chain

Structured envelopes, governance layers, tamper-evident audit trails and external witnessing. Specified, published and filed as live IETF Internet-Drafts.

AEEAgent Envelope Exchange

Structured envelope wrapping every agent interaction. 14 typed fields with correlation IDs, timestamps and hash references.

AOCLAgent Orchestration Control Layers

11-layer processing pipeline governing agent behaviour. L3 enforces policy gates, L8 verifies responses before delivery.

VOLTVerifiable Operations Ledger & Trace

Append-only, hash-chained event ledger using SHA-256. Ed25519 digital signatures and RFC 3161 timestamps.

WARDWrite-once Append-only Receipt Digests

Content-free witness receipts providing external attestation without exposing operational data.

Agent safety

The 11-layer governance pipeline

Every agent interaction passes through 11 processing layers before and after execution. L3, the policy gate, and L8, verification, are enforcing layers that can block actions.

Autonomy framework. Three modes per action: ACT, execute autonomously; ESCALATE, request human approval; or DEFER, decline and explain. Configurable per agent, per tool.
Budget limits. Token, cost and time budgets enforced per objective, per agent and per organisation. Agents halt when budgets are exhausted rather than continuing.
Human-in-the-loop. A HITL inbox for approval workflows. High-risk actions queue for human review, with escalation rules based on action type, confidence and scope.

L0Ingress & normalizeNormalize incoming events (chat/webhook/email/alert), create run IDs, basic parsing.

L1Identity & scopeApply identity, permissions, secret scope, and redaction rules.

L2Smart routeDeterministic fast-path router (pattern match, cached answers, known commands).

L3Policy gateSafety/compliance checks, tool/model restrictions, HITL requirements.enforcing

L4Plan & decomposeConvert intent into structured objectives, decide if multi-step/multi-agent.

L5Context retrieveRetrieve memory/files/RAG context; produce refs + bounded summaries.

L6Shape & rewriteRewrite/structure into operational form (e.g. AEE tasks, tool plans, schemas).

L7Delegate & executeDelegate to agents/tools, manage dependencies/concurrency (runtime-specific).

L8Verify & checkVerification/evals/consistency checks; evidence requirements.enforcing

L9Assemble & respondAssemble final response; redact; apply tone/formatting constraints.

L10Audit writebackPersist trace summaries and permitted memory writeback.

LLM security

LLM security is containment, not faith

Prompt injection is a mitigated risk, not a solved one. Quox assumes the model can be fooled, bounds what a fooled model can do, and records what it did.

Policy gate before execution. AOCL L3 evaluates every proposed action against organisation policy before it runs, and L8 verifies responses before delivery. A prompt cannot talk its way past the gate.
Human approval for risky tools. High-risk tool calls queue in the HITL inbox for human review, with escalation rules based on action type, confidence and scope.
Egress control. Server-side fetches of user-influenced URLs pass an egress guard that refuses private-network targets, so a crafted prompt cannot turn an agent into an internal port scanner.
Scoped credentials. Agents receive just-in-time, organisation-scoped credential leases from the vault. A compromised prompt in one organisation cannot reach another organisation’s keys.

A model that can be talked into anything is contained by what the platform lets it do, not by how well it was prompted.

The gate decides what runs. The evidence chain shows what ran. Neither depends on the model behaving.

Data protection

Encryption and storage

AI data security starts with where the data sits. Credentials and sensitive values are encrypted at rest, and all persistent data stays on your infrastructure. The only off-box signal is a health heartbeat that is off unless you explicitly opt in.

AES-256-GCM vault. API keys, tokens and credentials are encrypted before storage. Decryption keys are held locally, never transmitted.
SQLite with FTS5. Structured data in single-file databases with full-text search, straightforward to back up and audit.
Qdrant vector storage. Memory embeddings and semantic search run locally. Vector data never leaves your network, with memory isolation per organisation.

secretplaintext credential→DEKper-credential key→org KEKwraps the DEK · versioned→AES-256-GCMsealed, authenticated block

envelope model · keys held on your infrastructure, never transmitted

Access control

Built-in RBAC plus custom role overlays

Role-based access control governs every user interaction. Five base roles plus a cross-cutting Auditor role cover the common cases; Enterprise organisations layer custom capability bundles on top with org- or team-scoped grants. Organisations are fully isolated: separate data, agents and configuration.

ViewerRead-only access to dashboards, directories and runs

RunnerExecute pre-approved workflows and view execution history

BuilderCreate assistants, agents, tools and workflows; share across the org

AdminManage members, roles, SSO, policies, secrets and audit export

OwnerOrganisation settings, billing, delete org, transfer ownership

AuditorCross-cutting, time-bounded read-only access to evidence, audit and the WARD chain, with no write capabilities

Custom roleEnterprise: org-defined capability bundles overlayed on a built-in base role, with scope-bound grants, for example SECRETS_MANAGE on one team only

defconfive readiness levels, 5 to 1, progressively restrict agent autonomy; higher levels require more human approvalskill switchimmediate termination at individual, team or organisation level; running objectives halted, pending actions cancelleddenylistconfigurable prohibited commands, tools and actions; denied operations cannot run regardless of autonomy level

Enterprise enforcement

Every policy is enforced at request time

Quox refuses to ship a control that only looks pretty in the UI. Every org-level security policy below is checked on every authenticated request, on the credential mint paths, and on the deprovision side, not just stored in a settings table.

Session policy

Per-org idle timeout and maximum session lifetime, consulted by the authenticate middleware and the refresh endpoint on every call. Expired sessions are revoked, not just logged.

IP allowlist (CIDR)

Per-org IPv4 CIDR rules enforced at login, on every authenticated request, on token refresh, on switch-org, on SSO callback and on guest signup. Trust-proxy aware.

MFA required mode

Org policy required blocks login until enrolment. Switch-org forces a fresh challenge, so a flag from a lower-security org cannot be reused. Root-admin break-glass preserved for lockout recovery.

SCIM 2.0 deprovisioning

Deleting a user revokes their session rows immediately; pre-existing tokens are rejected with membership_revoked. Owner identity cannot be modified via SCIM under any circumstance.

Custom role overlays

Privilege-escalation guard at grant time and assign time: an admin cannot confer a capability they do not hold themselves.

Team-scoped secrets

Secrets bound to a team scope require active team membership for reveal, rotate, delete and create. Cross-org and non-team scope IDs fall to 403.

Verified domain auto-join

DNS-TXT-verified email domains auto-enrol new signups as viewers in the owning org. Public consumer domains are blocklisted from verification so no single tenant can claim them.

Guest signup-and-accept

External invitees go from email to password form to landing in one atomic transaction. Email is locked to the invite, the IP allowlist applies, and the anonymous endpoint is rate-limited.

Lifecycle event log

Every membership change, invited, joined, left or role-changed, appends to team_events. Webhook subscribers and integrations tail the log.

All of these are evidenced in the open governance claims matrix, docs/GOVERNANCE_CLAIMS_MATRIX.md. Every claim names its enforcement path, evidence source and test coverage, and the same document tracks any claim that is partial.

Vulnerability disclosure

Responsible disclosure policy

Reporting

If you discover a security vulnerability in any Quox product, protocol implementation or infrastructure, please report it to [email protected].

Include a clear description of the vulnerability, steps to reproduce, and any relevant proof-of-concept material. We will acknowledge receipt within 48 hours.

Our commitment

Acknowledge reports within 48 hours
Provide an initial assessment within 5 business days
Work with reporters to understand and validate findings
Issue fixes promptly and credit reporters, with consent
No legal action against good-faith security researchers

We ask that you do not publicly disclose vulnerabilities until we have had a reasonable opportunity to address them. We aim to resolve confirmed issues within 90 days.

Compliance

Quox does not claim certifications. It provides structured, cryptographic evidence that maps to the controls major frameworks require.

Evidence is exportable for auditors. Where a framework is listed below, the status describes evidence mapping work, not a certification or attestation.

Framework	What the evidence covers	Status
SOC 2 Type II	VOLT evidence maps directly to trust service criteria. Automated control evidence export.	Evidence mapping
HIPAA	Agent audit trails satisfy access logging requirements. PHI handling controls via AOCL policy gates.	Evidence mapping
GDPR	Data subject access requests supported via the entity registry. Processing records maintained in VOLT.	Evidence mapping
ISO 27001	Information security controls documented with cryptographic evidence chains.	Evidence mapping
EU AI Act	High-risk AI system requirements addressed through AOCL governance layers and decision evidence capture.	Evidence mapping
Open protocol specs	AEE, AOCL, VOLT and WARD protocol specifications, published as open specifications. Specified, published and filed as live IETF Internet-Drafts.	Filed

Explore the Compliance Suite For auditors

Security

Questions about security?

Read the detailed safety documentation, or get in touch with the security team directly.

Safety documentation Contact the security team General contact