cyber-harness is a Go-based agent harness that assembles model reasoning, tool execution, skills and collaboration into single binaries for authorized pentest, audit and research workflows.
| Tool | chainreactors/cyber-harness — general-purpose agent harness for cyber workflows where everything is an extension |
| Category | AI agent framework / security automation harness written in Go |
| Primary Use | Composing authorized agent tasks: scanning labs with aiscan, model-led code audits with cyber-audit, and embedding agent sessions into your own Go applications |
| Safe Use | The README explicitly restricts use to authorized targets, own labs and explicitly permitted testing environments; all examples in the documentation target 127.0.0.1 or local repositories |
| Telemetry Note | Agent event streams can be saved to JSONL via -o, the cyber-web Hub centralizes sessions, events and artifacts, and scanning traffic originates directly from the operator host — all observable by defenders monitoring source activity |
cyber-harness from the chainreactors organization is best understood not as another AI wrapper CLI but as an architectural bet: a single Go harness in which model reasoning, tool execution, knowledge, observation and collaboration are all assembled through one extension lifecycle. The README's tagline — everything is an extension — is the load-bearing design decision. Tasks and installed extensions determine which tools and workflows are available at runtime, which means the same core can ship as a scanner-focused binary, an audit binary, a minimal local agent, or be embedded wholesale into a third-party Go application. At roughly 291 stars and licensed under AGPL-3.0, it sits in the serious-tooling tier rather than the weekend-project tier, and the copyleft license is worth noting for anyone planning to embed it in proprietary products.
The project offers four distinct entry points, and the differentiation matters operationally. aiscan and aiscan-full cover agent tasks, scanners, proxy routing and IOA (the linked Internet of Agents concept), with the full edition adding Web UI, browser automation, passive recon and crawling. cyber-audit is a separate module under cmd/audit built specifically for model-led source-code and binary audits with evidence collection and reporting. cyber-web is a profile-neutral Web Hub for sessions, events and artifacts, and agent is a deliberately minimal local agent built from source with files, terminal, Skills and local subagents. That separation lets a team adopt only the audit capability without shipping browser and scanner dependencies they do not want.
Model configuration follows a conventional pattern: aiscan init or cyber-web init writes a ~/.cyber/cyber.yaml file holding provider settings, with --project available for per-project overrides and existing files preserved. The documented example configures an OpenAI-compatible provider pointing at deepseek with model deepseek-chat, credentials supplied via the CYBER_API_KEY environment variable, and the README notes equivalent anthropic provider settings. This is a pragmatic choice for operators in regions or budgets where DeepSeek-class models are the accessible option, and the OpenAI-compatible base_url pattern means any conforming gateway — including a self-hosted one for sensitive engagements — will plug in without code changes.
The build system is where the harness philosophy becomes concrete. Standard make produces bin/aiscan with core scanners, proxy, Skills and IOA; make full adds the Web, browser, passive recon and crawling capabilities and requires the frontend toolchain (Node.js 22 in CI, npm --prefix web/frontend ci). make audit and make agent build the leaner binaries from independent modules, and everything compiles with CGO_ENABLED=0 except native recording, which needs make record and its SDK. Build tags are tracked centrally in editions.env, which suggests the edition matrix is treated as a maintained contract rather than an accident of conditional compilation.
For developers, the embedding story is unusually well developed for this category. The README walks through a minimal cmd/my-agent/main.go that constructs a harness via harness.New(harness.Config{...}), disables the model provider with provider.StartupDisabled, loads the app, and executes a Bash tool call directly — no LLM involved. That is a meaningful architectural signal: tool execution is decoupled from model inference, so the same registered tools can be driven deterministically by code, by rules, or by an agent session. Extension points are documented for registering tools and embedding sessions, and a crtm CLI tool package registry exists in the sibling repos, implying a distribution model for third-party tooling.
The collaboration model is where cyber-harness diverges from single-host agent CLIs. The aiscan-full web --token command starts a workbench on 127.0.0.1:8080 guarded by an access key, and Quick Connect generates a one-line command that downloads and starts a scan or audit node on an execution host — effectively a lightweight C2-for-your-own-tooling pattern where --server-url with an embedded token registers a node back to the Hub. For authorized engagements this is distributed task execution across permitted hosts; architecturally it means sessions, events and artifacts from heterogeneous nodes (scan, audit, custom AOP) land in one queryable place, which is exactly the evidence trail an engagement report needs.
The scan pipeline itself distinguishes between two modes of choosing work that the README states plainly: the Agent lets the model choose tool calls, while the scan pipeline chooses work through rules and scan events with optional AI stages. This hybrid determinism-first design is the right instinct for professional use — deterministic crawling and rule-based checks produce reproducible results, and AI verification (--verify is a controllable flag, with the docs showing --verify=off for a purely deterministic run against a local lab) layers model judgment on top rather than replacing the pipeline. Reproducibility is what separates a defensible finding from an unreproducible LLM hallucination.
cyber-audit deserves separate attention because code auditing is an area where model-led agents have genuinely defensible value in authorized contexts. The documented invocation pattern is cyber-audit --workdir /path/to/repository -p "Audit authentication and tenant isolation" — pointing the model at a local checkout with a scoped question. The emphasis on evidence collection and reports in its description suggests the audit module is designed to produce citable output rather than chat transcripts, which is what a security review deliverable actually requires. The same binary can register as a node against the Web Hub with --server-url, so audit and scan findings converge in one workspace.
The disclaimer section is explicit and unusually firm for this genre: the harness supports authorized agent tasks and research only, scanning examples must run in your own lab or another authorized environment, sufficient authorization must be obtained before any scanning, and unauthorized targets are prohibited outright. The README reinforces this operationally — every scan example targets http://127.0.0.1:3000 or a local directory. For an editorial read, this alignment between the legal text and the actual example commands is a good authenticity signal; tools that preach authorization while documenting third-party targets in their quickstarts deserve more scrutiny.
From a defender's telemetry perspective, several artifacts are inherently observable. Agent event streams are serialized to JSONL files via the -o flag, the ~/.cyber/cyber.yaml configuration file identifies the configured provider and model in use, and node-to-Hub traffic flows as authenticated HTTP to the --server-url endpoint. Scanning traffic originates directly from operator or node hosts. None of this is stealth tooling by design — it is a workbench — and blue teams reviewing a host would find the binary names (aiscan, cyber-audit, agent), the config directory, and event logs as clear indicators of an authorized assessment in progress.
The surrounding ecosystem tells you the project is part of a coherent toolchain rather than a standalone artifact: chainreactors/ioa for the Internet of Agents concept, an sdk scanner SDK, proxyclient for multi-protocol proxying, crtm for tool package management, utils with a PTY manager, and parsers for protocol and data parsing. Documentation is maintained primarily in Chinese with a README_CN.md and extensive docs/ guides covering concepts, configuration, architecture, API and client integration — English-speaking operators should budget for some translation overhead, but the structure is professional-grade with per-tag documentation guidance for release pinning.
Where cyber-harness fits in an authorized workflow is ultimately as glue infrastructure: a team that already runs scanners, proxies and manual review can standardize on one harness where AI assistance, deterministic pipelines, distributed nodes and reporting live behind a single extension model. The AGPL license, the Go embedding path, and the edition matrix make it more attractive to internal tooling teams than to product vendors. Anyone evaluating it should read the architecture and data-ownership docs at their target Git tag, test the --verify=off deterministic mode first to validate baseline behavior, and keep every target inside explicitly authorized boundaries — which is, in the maintainers' own words, the only sanctioned mode of operation.
chainreactors/cyber-harness.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.