Skip to content

Using the Harness

Audience: the analyst who reviews what the agents found and decides what happens next.

What works today. All seven screens work. Open http://localhost:8080 once the stack is up (./deploy/bin/harness up) and sign in — nw.analyst / analyst to start.

Unfamiliar word? The glossary defines every term this guide uses, including the ones that mean something different elsewhere in security.

1. What the agents do for you

An alert arrives. Instead of waiting in a queue for someone to pick it up, agents immediately gather the facts, apply your organisation's rules, and put a reasoned recommendation in front of you with the evidence attached.

What you get is not an answer to accept on trust. It is a case file: what was found, which of your rules matched, how severe that makes it, what is proposed, and every step that led there — replayable.

The agents never decide. The verdict comes from your playbook, resolved before any model is asked anything. The model writes the narrative and flags anything suspicious in the data it read. Anything that changes state waits for you.

2. A worked example

A sign-in is flagged at 2:14 a.m. — new country, new device, unusual hour.

Step What happens Tier
1 The alert arrives. —
2 The harness loads your playbook and starts a Triage agent. T0
3 Enrichment — sign-in details, the account's normal pattern, the device, the location, all through read-only tools. T0
4 Your rules are applied. The event is classified and scored by your thresholds. T0
5 Seam check — can this account reach building controls? It can, so severity rises. T0
6 Recommendation, with the evidence your playbook requires. T1
7 Disabling an account changes something, so it waits for you. Nothing has been touched. T2, held
8 You review the evidence in one place and approve. T2
9 The action executes, bounded to that one account. T2
10 Every step is in the immutable log. —

3. The seven screens

Screen What it is for
Alert queue Everything that has arrived, across the width of the page: what your rules concluded, who it is about, which rules matched, and what is holding it. Enough to triage from without opening anything. Also where you inject a test alert.
Incident The reasoning as it builds, live
Approvals Actions waiting for you. Nothing here has happened.
Playbook Your rules, as readable configuration
Audit & replay Any past incident, stepped through
Earned autonomy Which action types have earned trust, and which lost it
Admin Operating the system: the maintenance window, the kill switch, and what this instance is actually talking to. Administrators only for the controls; anyone may look.

A status bar is always visible: who you are signed in as, your organisation, the current model backend, whether air-gap mode is on, whether every dependency is a real service that answered just now, and the kill switch.

A banner appears on every screen while a maintenance window is open. Someone wondering why nothing is acting should not have to go looking for the reason.

Each screen opens with a plain-language line explaining what you are looking at.

Reading the narrative

Steps stream in as they happen rather than appearing complete at the end, so you can see where an investigation has got to. Each says who acted — the harness, a named agent, the policy engine, or a person — and at what autonomy tier.

The step labelled "Applied your rules" is the verdict, and it came from your playbook. The step labelled "Composed the narrative" names the model that wrote the prose. That distinction is the point of the whole system.

4. Approving an action

An action in the approval queue has not happened. Nothing changes state until you approve it.

The evidence you need is already attached — your playbook lists what a recommendation must carry, and the harness refuses to surface one that is missing anything. An incomplete case never reaches you.

When you approve, the action is bounded: scoped to the single target derived from the incident. An approval to disable one account cannot become an approval to disable many.

You can reject. A rejection is recorded with the same weight as an approval.

5. When something is blocked

Every block names the rule that caused it:

You see Meaning
Held by ot-cap The target is physical infrastructure. Recommend only — and there is no approve button.
Held by asset-class-unknown The inventory could not classify the target, so it is treated as physical infrastructure.
Held by maintenance-window Systems are being serviced.
Held by earned-autonomy This action type has not earned the right to run at the requested level.
Held by kill-switch All agent activity is halted.
Not offered at all Your playbook does not permit this response.

That last one is not a malfunction. A response your organisation has not listed can never be proposed — omission is a control.

6. Editing your rules

If you are signed in as a tradecraft owner, the Playbook screen is editable. Change a threshold, save, and re-run the same alert: the verdict changes, with nothing rebuilt and nothing restarted.

An edit that does not validate is refused, and your previous version keeps running. You cannot take your own detection offline with a typo.

Analysts see the playbook read-only. Writing the rules and approving actions against them are different jobs — one person may hold both, but that is your organisation's choice rather than something the platform assumes.

7. Untrusted data

Alerts, logs and device names can contain text written by whoever reached the system — sometimes an attacker who knows an AI will read it. Everything ingested is treated as untrusted and scanned, and you will see content flagged.

The protection does not depend on the model noticing. Even a model that was completely fooled can only propose actions your playbook already permits, and every proposal still passes the policy engine and the approval gate. The defence is structural, which is why it holds against attacks nobody anticipated.

8. Replay

The Audit & replay screen shows the whole record, hash-chained, with a banner confirming it verifies. Step through any incident for a colleague, a reviewer or a post-incident review.

This is how you answer "why did it do that?" with evidence rather than recollection.

The claim is tamper-evident, not tamper-proof: a reader holding a trusted chain head can prove the history was not altered. Worth knowing precisely, because it is the kind of thing an auditor will ask about.