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.
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.
Vault credentials
Fleet SSH and bastion
Plans and roadmap
Agent memory
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.
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.
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.
First witnessed self-audit, and the fix sweep it forced. Findings were filed by nine parallel hostile audit lanes, with several more uncovered during the fix work itself, including two the fixes exposed: our HITL approve path dropped the very grant it existed to mint, and the trust page overclaimed 'no external telemetry'. The counts above are read live from the engagement store; every finding marked fixed was remediated test-first and verified on the running system before being resolved. The rest are published open, on purpose. An audit log that only ever shows green is indistinguishable from no audit at all.
Fixed, and verified on the running systems
Still open. Published anyway
Controls that held
An honest audit also records what it failed to break. Each of these was attacked and held.
- Vault envelope encryption held end to end; no secret values in logs or API responses
- Tenant scoping held on vault, memory, HITL and admin paths (queries traced, not assumed)
- Privilege-escalation guards held on both role paths
- Job-envelope signing fails closed; delimiter injection previously found is fixed
- No phone-home beyond the disclosed heartbeat and license check, and the heartbeat is now strictly opt-in
- Agent RBAC held during the fix sweep itself: the builder-role agent session was refused allowlist changes and could not approve its own gated actions
The WARD receipt
A real entry on the production WARD chain, not an illustration. Recompute it yourself: chain hash = SHA-256 of prev|chain|seq|entry|witnessed|source kind|source id|payload joined with pipes. The build fails if this page ever carries a receipt that does not recompute.
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.
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 asquoxai/aoclthe governance / control-layer specquoxai/voltthe hash-chained evidence log formatquoxai/wardthe tamper-evident witness receiptsquoxai/quoxmcpthe MCP bridge agents call tools throughquoxai/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.
Structured 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.
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.
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.
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.
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.
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.membership_revoked. Owner identity cannot be modified via SCIM under any circumstance.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 |
Security
Questions about security?
Read the detailed safety documentation, or get in touch with the security team directly.