Governance · self-hosted
Self-hosted AI agent governance.
If the vendor went dark tomorrow, would the governance still run and the evidence still verify? That test is the whole subject of this page.
The definition
What self-hosted AI agent governance is.
Self-hosted AI agent governance means running the controls over your AI agents (policy checks, approval gates, credential issuance and the audit record) on infrastructure you own and operate, rather than on a vendor’s platform. Every decision about what an agent may do is taken inside your boundary, and every record of what it did is stored inside it. The test is simple: if the vendor went dark tomorrow, the governance would still run and the evidence would still verify.
That definition matters because the phrase is used loosely. A search for the term today returns mostly articles about self-hosting models and coding agents, which is a different problem: where inference runs, not where control and accountability live. You can run an open-weight model on your own GPUs and still have every policy decision, approval and audit log pass through somebody else’s SaaS.
In plain words
What it is, where it lives, when to reach for it
- What is it
- A complete guide to running AI agent governance (policy, approvals, credentials, audit) on infrastructure you own.
- Where do I use it
- On your own servers or an air-gapped estate; nothing here depends on a vendor staying reachable.
- When would I use it
- When regulation, sovereignty or evidence custody rules out putting the control layer in someone else’s cloud.
- How do I use it
- Read the definition above and the 8-point checklist below, then test any vendor against them, including us.
Why self-host
Why self-host the governance layer.
Four reasons hold up under scrutiny.
- Data residency and sovereignty
- Governance logs are not metadata. They contain prompts, tool arguments, file paths, ticket contents and the identity of the people who approved things. If your regulator has an opinion about where customer data sits, it has an opinion about your audit trail.
- Evidence custody
- Under the EU AI Act, deployers of high-risk systems must keep automatically generated logs for at least six months where those logs are under their control (Article 26(6)), with the same minimum applying to providers (Article 19), and the systems themselves must technically allow automatic recording of events over their lifetime (Article 12). Evidence you cannot export, or that only proves anything while you hold a subscription, is a weak position in an audit.
- Disconnected and restricted estates
- Defence, energy, manufacturing and classified environments have networks that do not reach the internet by policy. A governance layer that needs a licence check or a policy fetch to start is not deployable there.
- Blast radius
- The UK NCSC’s guidance on managing the cyber risk of agentic AI recommends denying inbound and outbound network traffic to an agent’s environment by default and allowing only what is required. That posture is easier to hold when the control plane is a local service rather than an external dependency you must punch through the firewall for.
The honest cost
You own the operations.
Self-hosting moves work onto your team, and the marketing rarely says so.
- Patching
- You own patching, including security patches for the governance service itself.
- The database
- You own the database, its backups and its restore drills, and an unrestorable audit trail is not an audit trail.
- Key management
- You own key management: signing keys for evidence, encryption keys for secrets, and the rotation and escrow procedures around both.
- Capacity
- You own capacity, because policy evaluation and log write volume grow with agent activity, not headcount.
- Upgrades
- You own upgrades in an air-gapped estate, which means a manual artefact transfer process with signature verification, not an automatic update channel.
- The on-call rota
- And you own the on-call rota, because a governance layer that is down either blocks all agent work or, worse, is configured to fail open.
Budget for a named owner. If nobody owns it, the deployment drifts and the evidence gaps appear exactly where they hurt.
The decision checklist
Demand these in writing, and test them.
Do not just accept the datasheet.
- 1It runs fully inside your boundary. All of it: policy evaluation, approval workflows, secret storage, log write path and any dashboard. Ask which components have no on-premises equivalent.
- 2No phone-home. No telemetry, licence heartbeat, update check or model routing that leaves the network. This is verifiable: run the system under packet capture for a working day and read the egress.
- 3Evidence verifies offline. You should be able to hand an auditor an evidence file and a verification tool, on a laptop with no network, and have them confirm integrity without a vendor account and without calling an API.
- 4Human approval gates. Specific actions should be held pending a named human decision, and the decision, the approver and the timing should land in the record. The EU AI Act requires deployers to assign oversight to people with the competence and authority to exercise it (Article 26(2)).
- 5Scoped, short-lived credentials. One identity per agent, task-scoped permissions, no shared service accounts. OWASP’s agentic work repeatedly flags privilege inheritance and credential reuse across agents as a primary failure path (OWASP GenAI Security Project).
- 6A working kill switch. Halt one agent, one class of tool, or everything, and be able to prove it took effect. Test it in production conditions before you need it. See our deeper look at kill switch design for the three scopes and the halt semantics that get missed.
- 7Air-gap capability, demonstrated. Installation, licensing, operation and upgrade with zero outbound connections, documented as a procedure you can rehearse.
- 8Key custody. You hold the private keys that sign your evidence. Ask directly, and ask what happens to verification if you leave.
Air-gapped operation
Air-gapped AI agent governance.
Take the network away and the whole shape of governance changes: there is no vendor telemetry to lean on, no licence server to check in with, and no cloud dashboard quietly confirming that policy is being enforced.
Everything the control plane needs to prove about itself, it has to prove using only what is stored on the isolated network, which is why the evidence trail stops being a nice-to-have and becomes the only witness there is.
What air-gapped actually means here
For an agent control plane, air-gapped is not just “no internet.” It means the platform cannot phone home for licensing, cannot report usage or telemetry to a vendor, and cannot reach out to pull the latest model weights or a software update on its own schedule.
Every model, plugin, and update has to arrive through a controlled import process instead: someone on the outside stages the artefact, it crosses the gap on removable media or through a one-way transfer mechanism, and someone on the inside verifies it before it touches the running system.
A self-hosted platform built for this has to assume that path is the normal one, not an exception bolted on for a rare deployment.
Why evidence matters more, not less
On a connected system, a lot of trust is borrowed: a cloud vendor’s uptime dashboard, a support engineer who can pull live logs, an outside auditor who can query the API directly. None of that exists behind an air gap.
Nobody outside the network can observe what an agent did, so the only account of what happened is whatever the platform itself recorded at the time. If that record can be edited after the fact, it is not evidence, it is a claim.
This is the argument for building the audit trail as tamper-evident from the start rather than treating it as a log that gets shipped somewhere for safekeeping, because there is nowhere else to ship it to.
Offline verification, in principle
A hash-chained, signed record does not need a network to be checked. Each entry links to the one before it through a hash, so altering or deleting a past entry breaks the chain in a way that is detectable by recomputing hashes locally.
Signatures over the chain’s tips mean a verifier only needs the public key and the data itself, not a connection to a signing service, to confirm the record has not been altered since it was written.
That is what makes offline verification realistic rather than aspirational: an auditor can sit at a terminal with no outside connectivity at all and still walk the chain end to end. Quox’s WARD receipts are built on this principle; see how offline verification works for the underlying mechanics.
The costs nobody should hide
Air-gapped operation is not free, and it is worth saying plainly what it costs.
- Updates
- Updates lag behind whatever the vendor ships, because every patch has to be staged, transferred, and verified before it can be applied, and that process is measured in the organisation’s own change windows, not a vendor’s release cadence.
- Model refreshes
- Refreshing models is a logistics exercise, not a download: someone has to move potentially large weights across the gap, validate them, and roll them out.
- Managed services
- There is no managed anything: no managed database, no managed backups, no vendor on-call rotation to escalate to at 2am. Every one of those functions has to be staffed and run by the organisation itself.
Who this is actually for
This level of isolation is not a default posture for most teams; it is a requirement that follows from the sensitivity of the environment. Defence programmes, operators of critical infrastructure, and some healthcare and government systems are the buyers who need it, typically because policy or regulation rules out any outbound connection at all, not because they prefer the extra operational burden.
For everyone else, self-hosting without a full air gap usually gets most of the control with less of the cost. These are exactly the deployments the wider Quox enterprise platform is built to serve.
Common failure modes
Where "self-hosted" quietly stops being true.
A SaaS control plane with an on-premises agent is not self-hosted.
This is the most common substitution. The runner sits in your VPC, but policy decisions, approvals and the audit store sit in the vendor’s cloud. Your data plane is local; your governance is not, and governance is the thing you were trying to keep.
Logs that leave the boundary.
Crash reporting, usage analytics, "anonymised" prompt telemetry and hosted observability all quietly export exactly the content that made you self-host. Enumerate every outbound destination, including the ones the vendor considers infrastructure rather than product.
Vendor-held signing keys.
If the vendor signs your evidence, its integrity claim is a claim about the vendor, not about you, and it becomes unverifiable the day the relationship ends. Related: evidence formats that only the vendor’s own tool can read.
Fail-open policy enforcement.
Ask what happens when the policy service is unreachable. If the answer is that actions proceed, you have monitoring, not control.
Undocumented autonomy creep.
Agents accumulate tools and permissions over months. Without periodic review, the scoped credential you provisioned in January governs an agent with a much larger reach by June.
When not to
When not to self-host.
Self-hosting is a cost you should only take on for a reason. Do not take it on if none of these apply to you.
- If you have no data residency, sovereignty or air-gap requirement
- If your agents touch only low-sensitivity data
- If you have no dedicated platform or security engineering capacity to operate another service
- If your organisation already accepts SaaS for systems of record such as your source control, ticketing and identity provider
Then a managed governance service is likely a better use of your people.
The NCSC’s advice to start small and confine agents to low-risk tasks applies here too. A well-run managed deployment beats a neglected self-hosted one, and an unpatched governance service you own is worse than a maintained one you rent.
Where Quox sits
Stated plainly, and without comparison.
Quox is self-hosted first. It installs and runs on your hardware, including disconnected estates, and a vendor-managed instance is available as an option rather than the default. Governance decisions, approvals and evidence stay on the instance you run.
Three mechanisms are relevant to the checklist above. AOCL gates hold actions pending human approval before they execute. VOLT evidence bundles verify offline: an auditor with the bundle and the verification tool needs no network and no Quox account. WARD publishes signed hash-chain tips to external stores, so the integrity of your record can be witnessed outside the system that produced it.
The four protocols behind this are AEE, AOCL, VOLT and WARD, filed as IETF Internet-Drafts. Per-protocol IETF status. AEE, AOCL and VOLT are live Internet-Drafts at revision -01 (draft-cowles-<name>-01, refreshed 2026-08-31); WARD was filed for the first time on 2026-08-31 as draft-cowles-ward-00. All four are current through 2027-03-04.
These are individual submissions: they carry no IETF endorsement and no standing in the standards process. Published as drafts so the formats can be read, implemented and criticised by people who do not use Quox.
Test the boundary claim yourself.
Ask which components have no on-premises equivalent, run the system under packet capture, and hand an auditor an evidence file with no network. That is the whole test, and it is one you can run before you buy.