AUDITUS: the all-seeing eye of AI governance

The policy you created is not the policy that runs

Every AI governance platform has a policies page. You create rules. You set conditions. You feel responsible and diligent. Then you go back to your day job, confident that the system is enforcing what you configured.

It is not.

Most AI platforms store policies in one database and enforce hardcoded rules in another. The page where you create policies has zero connection to the runtime that evaluates requests. Three systems exist in silos with no shared data. The user interface gives you the confidence of control without the reality of enforcement.

We built Quox with this same architecture. Then we fixed it.

One store, one evaluator, one truth

The Governance Policy Center is built on a simple principle: the policy you create is the policy that runs. Every policy lives in a single server-side store. Every chat message, tool execution, and LLM request evaluates against those policies in real time. There is no secondary system. There is no "sync" step. The store is the enforcement engine.

Four categories cover the full governance surface:

• Safety. SQL injection, credential exposure, dangerous commands. The floor that never moves.
• Execution. Rate limits, token budgets, model routing, timeouts. Operational guardrails.
• Governance. Approval chains, tool access tiers, team-scoped restrictions. Organisational rules.
• Compliance. PII detection, data residency, framework mapping. Regulatory controls.

Each policy has a condition tree (AND/OR logic with 10 operators), an effect (allow, deny, require approval, redact, or log only), a priority, and optional framework mappings to standards like HIPAA, SOC 2, or GDPR. The condition evaluator is the same code on both the server and the browser. No translation layer. No drift.

PII detection that actually blocks

Every query is scanned for personally identifiable information before it reaches any LLM. Social security numbers, email addresses, phone numbers, credit card numbers, IP addresses, API keys. Six pattern categories, evaluated in both the browser-side L3 policy gate and the server-side chat handler.

The default configuration logs PII detections for audit. One toggle in the policy library activates hard blocking. When enabled, a message containing Patient SSN is 123-45-6789 returns a 403 with the matched framework references (HIPAA 164.312.a.1, GDPR Art.32.1.a) and the policy name that triggered the block.

This is not a report that tells you PII was sent last week. This is enforcement that prevents it from being sent at all.

Execution policies: the operational control surface

Compliance is one dimension. Operations is another. Execution policies let administrators set token budgets, rate limits, model restrictions, and timeout thresholds that are enforced before any LLM call resolves.

Create a policy that says "deny if daily token usage exceeds 500,000." The next time the LLM execution planner resolves a request for an organisation that has burned through its budget, the request is rejected with a clear reason and the matched policy name. Not throttled. Not degraded. Denied, with an audit trail.

The same mechanism gates tool execution. Before any tool runs, the governance store is checked. Previously, only two tools (Proxmox VM actions and Docker container operations) had approval gates. Now every tool in the system can be gated by governance policies. Create a policy, define the conditions, and the gate exists. No code changes. No deployments.

AOCL: the 11-layer enforcement architecture

Behind all of this is AOCL: the Agent Orchestration Control Layers protocol. Eleven layers that every request passes through, from identity verification (L1) to audit logging (L10). The policy gate sits at L3. Every decision it makes is emitted as an AEE envelope, timestamped, correlated, and stored in the VOLT evidence ledger.

This is what makes Quox governance different from a settings page with checkboxes. When a policy blocks a request, the block is an observable event in an 11-layer pipeline. The decision is traceable from the user's query through the policy evaluation to the final response. An auditor can follow the chain. An incident responder can replay it. A compliance officer can prove it happened.

No competitor in the AI governance space offers traceable policy enforcement through a structured, protocol-defined pipeline. They offer dashboards. We offer evidence.

One-click compliance bootstrapping

Writing governance policies from scratch is not how most organisations want to start. Template packs solve this. Four pre-built packs cover common compliance starting points:

Click "Enable Pack." Conflict detection warns you if any existing policies overlap. All policies from the pack are created in your organisation's store, active immediately, enforced on the next request. Five seconds from zero to SOC 2 baseline.

Meet AUDITUS

AUDITUS is the governance intelligence agent. It sits in the sidebar of the Governance Policy Center, watching the same enforcement pipeline it helps you configure. It has direct access to the policy store, the AEE audit trail, the VOLT evidence ledger, and the WARD witness chain. It can generate compliance reports, verify hash chains, create evidence bundles, and deliver findings to your HITL inbox.

Ask it "what policies are currently enforced?" and it queries the store, not a cache. Ask it "generate a SOC 2 report" and it pulls live data from all four governance protocols, scores your posture against SOC 2 controls, and delivers a framework-mapped assessment. Ask it "send this to my inbox" and the compliance briefing lands in your approval queue.

AUDITUS does not guess. It does not estimate. It verifies. Every answer it gives is tagged with a confidence level: VERIFIED (chain-checked), REPORTED (from a generated report), ESTIMATED (partial data), or UNKNOWN (no data). If the evidence does not exist, it says NOT_MEASURED. That honesty is the feature.

Why this matters for enterprise AI

Enterprise AI adoption stalls on governance. IT leaders know the value of AI agents operating across their infrastructure. They also know that an uncontrolled AI agent with SSH access is a compliance nightmare. The question is not whether to adopt AI operations. The question is whether the governance framework can keep up.

Traditional GRC platforms (Vanta, Drata, IBM OpenPages) treat policy as documents. They audit after the fact. AI-native governance platforms (Acuvity, Zenity) are closer, operating as API gateways. But none of them offer what AOCL provides: an 11-layer pipeline where every enforcement decision is an observable, traceable, evidence-producing event.

The policies page is no longer decorative. It is the control surface. And AUDITUS is the eye that never blinks.