The system
How the harness runs a swarm of agents to defend a company, step by step
This page describes the planned system in plain language. It is the readable version of the fourteen-chapter presentation. Everything on it is a design in engineering preparation; nothing is a measured product result.
Begin with a bounded customer estate
An operator identifies a repository, its built image or software inventory and an owned Linux environment. The operator sets the permitted reads, any permitted changes, the data-processing route and the investigation budget. Credentials are issued to the execution service rather than placed inside the agents’ prompts or working folders.
A small service map becomes concrete as evidence arrives. Empty space stays labelled “not observed”.
Gather deterministic evidence
Inventory and inspection plugins collect repository metadata, a software bill of materials, dependency advisories, static-analysis findings and redacted secret indicators. Every observation records the input revision, tool version, time, result and coverage. A parser failure is an error or a partial result, never an empty clean scan.
Each observation becomes an evidence card with a source and a freshness badge.
Coordinate investigation
The coordinator decomposes work into bounded tasks with dependencies and budgets. Prime executes the reasoning and tool-facing procedures. An analyzer considers deterministic findings alongside exposure and business context. A separate challenger tests important assumptions. The scheduler limits fan-out and validates outputs before dependent work; more agents is not itself a quality metric.
Three or four meaningful lines of inquiry emerge, with their conclusions and their missing evidence.
Turn a finding into a proposed response
A finding may be confirmed, rejected or marked as needing validation. If a fix is appropriate, a repair worker creates a plan: exact asset and revision, intended change, expected impact, checks, expiry and compensation approach. For the first engineering slice the change is a scratch-branch repair, not a silent production write. Changing the target or patch changes what must be authorised.
A compact before/after panel with why, scope, risk and verification.
Execute through a separate boundary
The execution broker authenticates the grant, checks the target and preconditions, records durable intent and invokes the permitted operation. Agents cannot grant themselves credentials by writing persuasive text. If a request times out, the system records uncertainty and checks the destination before retrying. If storage cannot durably acknowledge the action, new effects stop.
A single authorised path opens through the boundary; other paths stay closed.
Verify the result independently
A verifier uses separate evidence and acceptance checks. For software repair: the exact candidate revision, the relevant checks and ordinary behaviour. For deployed remediation: the destination state as well. A branch fix is not a deployment fix. In the future containment scenario both the simulated malicious action and a benign reference transaction matter. Missing telemetry produces incomplete verification, not green status.
“Threat activity blocked” and “business transaction works” appear as separate checks.
Produce the operator record
The final report links the finding, plan, approval, action record and verification evidence. It includes unresolved items, coverage gaps, usage and human intervention. The operator can inspect the evidence behind a conclusion, export the record and decide what to do next.
What was inspected, what matters, what changed, what proves the change helped.
Recover after interruption
The coordinator reconstructs unfinished tasks from durable records, rejects stale workers and reconciles uncertain effects. Worktrees preserve files; external task and action records preserve workflow meaning. Recovery is designed behaviour pending fault tests, not immunity to disk loss or infrastructure failure.
Evidence stays anchored while a worker is replaced.
Two stories, deliberately staged
| Initial engineering story | Later incident story | |
|---|---|---|
| Trigger | Repository or dependency change | Suspicious synthetic service-account activity |
| Evidence | Source, SBOM, advisory, linked host export | Authentication, process, file, service and local-sink observations |
| Response | Exact scratch-branch repair proposal | Bounded account disable and lab-egress containment |
| Independent outcome | Security check and benign tests on the exact revision | Actor probes denied and benign transaction still works |
| Honest limit | Deployment may remain unobserved | An isolated lab does not establish real-world attack coverage |
| Treatment today | Design walkthrough | Clearly labelled future demonstration storyboard |
Component map
All 42 components are specified, not shipped.
| IDs | Responsibility | Why it matters |
|---|---|---|
| 100–102 | Workspace preparation, isolated Prime profile, skill and MCP SDK | Repeatable assembly and a maintainable harness boundary |
| 103 | Versioned contracts | An agent’s response can be checked by ordinary code |
| 104–107 | Redis records, scoped search, write-once evidence, Streams | Evidence and tasks keep their identities across interruption |
| 108 | Task graph, leases and fenced attempts | Duplicate or stale work does not silently take control |
| 109–112 | Grants, broker, confinement and pinned tool runner | Reasoning and permission remain separate |
| 113–114 | Prime internal and Superset worker adapters | Different execution transports can use the same contracts |
| 115–116 | Recovery and budgets, model routing | Failure and resource limits are designed in |
| 117–122 | Repository, SBOM, dependencies, static checks, secrets, source audit | First useful inspection workflow |
| 123–128 | Threat feeds, exposure, host, cloud, network, telemetry | Broader context through qualified adapters |
| 129–133 | Triage, plans, repair, independent verification, lab response | A proposed fix is followed through to an observed result |
| 134–135 | Reporting and independent evaluation | A conclusion needs an inspectable record and a fair test |
| 136–137 | Release and update qualification, development integration | Product evolution can preserve tested behaviour |
| 138 | Isolated lab and observation coverage | Demonstrations can be repeated and judged independently |
| 139–141 | Operational health, plugin supply chain, change triggers | Admission, updates and recurring work stay bounded |
The factory is not the product
The planned development factory has one coordinator, three builders, an independent reviewer and a real-Prime tester. Product roles investigate and respond to security work. The two future lab actors simulate intrusions. These are three different groups, not one permanent eleven-agent swarm. A tester opening Prime at a candidate commit proves only the cases tested; product verification checks a customer or lab outcome.