Who audits the harness?

An agent harness is the runtime layer your agents execute inside: it decides what they can call, what they can see, and what gets written down. Many harnesses are cloud control planes, which means the layer enforcing your governance is a layer you cannot inspect. If you work somewhere that gets audited, that is the question worth asking first — and almost nobody is asking it.

An agent harness is the runtime layer your agents run inside.

Not the model. Not the framework you wrote the agent in. The thing underneath both, that actually executes: it holds the tools an agent may call, the memory it may read, the credentials it may use, and the record of what it did. When an agent decides to query a database, something has to permit that, perform it, and write it down. That something is the harness.

The distinction matters because these three keep getting collapsed:

A framework is how you express an agent — the code you write. It runs wherever you run it.

A harness is where the agent executes — permissions, tools, memory, audit. It is infrastructure, not authorship.

A control plane is where you configure the harness — usually a dashboard, usually somewhere else.

You can write an agent in any framework and run it in any harness. Most teams discover the harness layer exists at the point where they need to answer for what an agent did — which, if you are in a regulated environment, is somewhat later than ideal.

The honest answer is that nearly everyone builds one accidentally first.

You write an agent. It needs a tool, so you wire one in. It needs to remember something, so you add storage. Someone asks who ran it, so you add logging. Six months later you are maintaining a harness you never chose to build, and it enforces exactly the controls someone thought of on the day they were needed.

Buying one is a decision to make those controls a property of the platform instead of a property of your discipline. That is the real argument for it. Not speed.

Here is where the conversation usually stops, and where it should start.

The agent-harness discussion right now is full of vendors offering governance. Policy engines. Guardrails. Approval workflows. Audit dashboards. All of it real, and much of it good.

The question to ask about any of it is where it runs.

Because if the enforcement layer sits in a vendor's cloud, it is a layer you cannot read, cannot host, and cannot show an assessor. You are given a dashboard that reports compliance. Ask yourself whether you have also been given the ability to verify that the report is true.

A governance layer you cannot audit is a promise, not a control.

For most companies that trade is fine. Nobody audits your CRM's internals either. But if you are in defence, government, healthcare, or finance, you will eventually meet someone whose job is to establish not that you have controls but that the controls do what you say. At that point "our vendor's dashboard shows green" is not evidence. It is a citation of someone else's claim.

If you are evaluating this layer, these four separate the ones that survive a security review from the ones that survive a demo.

1. Who can audit the enforcement layer itself?

Not "does it have an audit log" — everyone has an audit log. Can you read the code that decides what an agent is allowed to do?

If the answer is no, your access-control model is a vendor's assertion about their own product. That may be acceptable. It should at least be a decision you made knowingly, rather than one you discover during an assessment.

2. Where does it run, and under whose jurisdiction?

An agent harness touches everything: your documents, your databases, your credentials, your customers' data. So "where does it run" is not an infrastructure question, it is a legal one.

Ask specifically: can it run entirely inside your own perimeter? Not "we have a region in your country" — a region is still their infrastructure under their jurisdiction. Whose legal system can compel access to the environment your agents run in?

3. How much of it depends on the vendor's control plane?

This is the question that quietly reorders most shortlists.

Ask what the product reaches out for, and when: policy decisions, licence validation, telemetry, the model itself. Then ask the sharper version — does it still enforce your policies when it cannot reach the control plane?

A guardrail that stops enforcing the moment the network is unavailable is not a guardrail; it is a guardrail-shaped object. This is worth testing rather than asking about, because the answer is often "we've never tried."

4. What evidence does it produce that an assessor accepts?

Dashboards are for you. Assessors want artefacts.

Ask what it exports, in what format, covering what. The useful shape is: every prompt, every tool call with its arguments, every model response, each attributable to a named human principal — exportable in a format you can hand over and retain on your own schedule.

The test is whether you can answer "who caused this, what did it do, and what did it see" about a specific action from six months ago, without asking the vendor.

We make one of these, so here are our own answers to the four questions.

EpicStaff runs on your own infrastructure — on-premises or in your own cloud tenancy. It is source-available under PolyForm Perimeter 1.0.0: read the code, run it, and modify it for your own use — inspection is exactly what the licence protects. It does restrict competing commercial use, so read the terms before building a product on it. The code enforcing access control is code you can open.

Role-based access control and an audit trail of every prompt, tool call and model response — exportable as JSON or CSV, and because you self-host, the export is yours to keep or delete on your own schedule — are in the source-available tier, not the paid one. Attribution of audit entries to a named principal is on the delivery roadmap for the Enterprise and Defence tiers. Single sign-on and the wider assurance bundle are Enterprise and Defence items, available on request as part of a contract.

For your own audits: audit-log export, access controls, and documented procedures for your SOC 2 / ISO / BIO process.

Source: github.com/EpicStaff/EpicStaff