Skip to content
quoxsecurity

AI security · self-hosted · evidence first

You don’t need trust when you can verify

You hand an agent platform your vault credentials, fleet access, plans and agent memory. Promises are not enough, so every claim here states how to check it.

Governed, witnessed, checkable, yours.

Agents are only useful if you can let them act. Quox lets them act, and keeps the proof.

  • Governed.

    Every tool, route and agent action is permission checked before it runs. Risky steps stop and wait for a human yes.

    See how
  • Witnessed.

    Each governed action lands as a signed receipt in a tamper-evident hash chain, as it happens.

    See how
  • Checkable.

    You can verify the chain yourself, offline, years later. You never have to take it on trust.

    See how
  • Yours.

    It runs on your own machine. Your keys and your data stay inside your network.

    See how
Latest QuoxTrust barv1.8 Resource & Abuse Bounds: PASS

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 in this bar. 5 still open across the 4 self-audit cycles, published in full. See all nine bars

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. None of these asks for your confidence; each says how to verify it.

  • Vault credentials

    envelope-encrypted

    API keys, tokens and passwords for your integrations live in the vault on your own instance: envelope-encrypted with AES-256-GCM, scoped to your organisation, and leased to agents just in time rather than handed out wholesale.

    How to verify. Every reveal, rotation and lease lands in the witnessed audit trail. Export the chain and check it against what you expected to happen.

  • Governed command execution on your own servers goes through QuoxBastion under scoped operator tokens. High-risk agent actions queue for human approval in the HITL inbox before they are dispatched.

    How to verify. Each execution carries a receipt in the evidence chain. Replay the log and see every command, who authorised it, and what it returned.

  • Plans and roadmap

    witnessed writes

    What your business intends to do next lives in QuoxPlan, on your infrastructure. Changes made through the governed surfaces emit AEE envelopes and are WARD-witnessed, so the planning record cannot be quietly edited.

    How to verify. Pull the event log and walk the witness receipts; a missing or broken link in the chain is visible, not deniable.

  • Agent memory

    stays local

    Everything your agents learn is stored in your own memory and vector stores, per-organisation, on your hardware. There is no shared cloud index, and the only off-box signal is a health heartbeat that stays off unless you explicitly opt in.

    How to verify. Watch egress at your own network edge: nothing leaves your infrastructure unless you wired an integration that sends it.

Break it and watch.

Every action is hashed and chained to the one before it. Change history and the chain says so.

evidence chain · recreationverified
  1. block 1c7a452deprev 96868d19sealed
  2. block 2ba6d0d2fprev c7a452desealed
  3. block 30bcb2860prev ba6d0d2fsealed
  4. block 42fcd6a2bprev 0bcb2860sealed
  5. block 55824f45cprev 2fcd6a2bsealed
  6. block 6e82cab1dprev 5824f45csealed
Each block binds the hash of the one before it.

This is a recreation, not a screenshot. The real ledger, VOLT, is an append-only hash-chained log using SHA-256, with Ed25519 signatures and RFC 3161 timestamps. WARD adds content-free witness receipts for external attestation.

The substance, one line each.

Pick a thread. Each one opens onto the detail and how to check it.

Explore the full evidence wiki

The full detail

Everything above, with the working shown.

The 11-layer governance pipeline.

Every agent interaction passes through the same 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.
  • Scheduled run limits.Teams can cap how many scheduled runs start each day; the limit is checked when a run is triggered.
  • 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.
  1. L0Ingress & normalizeNormalize incoming events (chat/webhook/email/alert), create run IDs, basic parsing.
  2. L1Identity & scopeApply identity, permissions, secret scope, and redaction rules.
  3. L2Smart routeDeterministic fast-path router (pattern match, cached answers, known commands).
  4. L3Policy gateenforcingSafety/compliance checks, tool/model restrictions, HITL requirements.
  5. L4Plan & decomposeConvert intent into structured objectives, decide if multi-step/multi-agent.
  6. L5Context retrieveRetrieve memory/files/RAG context; produce refs + bounded summaries.
  7. L6Shape & rewriteRewrite/structure into operational form (e.g. AEE tasks, tool plans, schemas).
  8. L7Delegate & executeDelegate to agents/tools, manage dependencies/concurrency (runtime-specific).
  9. L8Verify & checkenforcingVerification/evals/consistency checks; evidence requirements.
  10. L9Assemble & respondAssemble final response; redact; apply tone/formatting constraints.
  11. L10Audit writebackPersist trace summaries and permitted memory writeback.

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.

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

Built-in RBAC plus custom role overlays.

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

Brakes on autonomy

  • defconfive organisation-wide levels; green to amber run normally, orange escalates autonomous work to a human, red halts it
  • kill switchhalts agent dispatch for one agent or the whole organisation; running loops stop at their next turn; a call already executing is not interrupted
  • denylistconfigurable prohibited commands, tools and actions; denied operations cannot run regardless of autonomy level

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 policyPer-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 modeOrg 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 deprovisioningDeleting 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 overlaysPrivilege-escalation guard at grant time and assign time: an admin cannot confer a capability they do not hold themselves.
  • Team-scoped secretsSecrets 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-joinDNS-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-acceptExternal 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 logEvery membership change, invited, joined, left or role-changed, appends to team_events. Webhook subscribers and integrations tail the log.

Known limitations, including DNS-rebinding egress and process-local replay sets, are listed in one place: known limitations.

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.

Encryption and storage.

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.
  1. secretplaintext credential
  2. DEKper-credential key
  3. instance KEKwraps the DEK · versioned
  4. AES-256-GCMsealed, authenticated block

Envelope model: keys held on your infrastructure, never transmitted.

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.

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 ExchangeStructured envelope wrapping every agent interaction. 14 typed fields with correlation IDs, timestamps and hash references.
  • AOCLAgent Orchestration Control Layers11-layer processing pipeline governing agent behaviour. L3 enforces policy gates, L8 verifies responses before delivery.
  • VOLTVerifiable Operations Ledger & TraceAppend-only, hash-chained event ledger using SHA-256. Ed25519 digital signatures and RFC 3161 timestamps.
  • WARDWrite-once Append-only Receipt DigestsContent-free witness receipts providing external attestation without exposing operational data.

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

The published log 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 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

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.

Witnessed SEO, recomputable.

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.

8 businesses, 526 witnessed crawls, every one recomputable

recompute command (general form)
node recompute-chain.mjs <site>-chain.json quox-seo-pubkey.pem

Download the verification bundle

One bundle covers every site. Download it, run the recompute command for any business, and the chain rebuilds its hashes and checks its signature on your own machine, with no call back to us. Verifier commit 5415009. Generated 2026-10-24T03:39:47Z.

  • quox.ai118 entries, 1 signatures verified. node recompute-chain.mjs quox.ai-chain.json quox-seo-pubkey.pem
  • hottubshampshire.co.uk83 entries, 1 signatures verified. node recompute-chain.mjs hottubshampshire.co.uk-chain.json quox-seo-pubkey.pem
  • mountfolly.co.uk74 entries, 1 signatures verified. node recompute-chain.mjs mountfolly.co.uk-chain.json quox-seo-pubkey.pem
  • poolpro.co.uk73 entries, 1 signatures verified. node recompute-chain.mjs poolpro.co.uk-chain.json quox-seo-pubkey.pem
  • hostnode.io60 entries, 1 signatures verified. node recompute-chain.mjs hostnode.io-chain.json quox-seo-pubkey.pem
  • www.poolpro.co.uk46 entries, 1 signatures verified. node recompute-chain.mjs www.poolpro.co.uk-chain.json quox-seo-pubkey.pem
  • nodevpn.com43 entries, 1 signatures verified. node recompute-chain.mjs nodevpn.com-chain.json quox-seo-pubkey.pem
  • skillrights.org29 entries, 1 signatures verified. node recompute-chain.mjs skillrights.org-chain.json quox-seo-pubkey.pem

Evidence, not certificates.

Quox does not claim certifications. It provides structured, cryptographic evidence that maps to the controls major frameworks require. Evidence is exportable for auditors, and where a framework is listed below the status describes evidence mapping work, not a certification or attestation.

  • SOC 2 Type IIEvidence mappingVOLT evidence maps directly to trust service criteria. Automated control evidence export.
  • HIPAAEvidence mappingAgent audit trails satisfy access logging requirements. PHI handling controls via AOCL policy gates.
  • GDPREvidence mappingData subject access requests supported via the entity registry. Processing records maintained in VOLT.
  • ISO 27001Evidence mappingInformation security controls documented with cryptographic evidence chains.
  • EU AI ActEvidence mappingHigh-risk AI system requirements addressed through AOCL governance layers and decision evidence capture.
  • Open protocol specsFiledAEE, AOCL, VOLT and WARD protocol specifications, published as open specifications. Specified, published and filed as live IETF Internet-Drafts.

Explore the Compliance Suite For auditors

Questions about security? Or found something?

Write to [email protected], with a clear description, steps to reproduce and any proof of concept. We acknowledge receipt within 48 hours.

  • 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.

Safety documentationGeneral contactEvidenceThe trust ladderThe CLI front door