English · 简体中文
Investigations grounded in evidence. Responses checked against outcomes.
CyberGuard provides investigation and response-governance infrastructure for Agents. Your existing Agent submits materials through a Skill; AgentTeams plans native tasks, investigates and independently reviews the findings, then returns a report with source quotations. Security teams can also use proposal-bound approvals, execution and outcome probes to distinguish a successful command from a resolved incident.
New walkthrough video · Finals walkthrough · Capabilities and evidence · Deploy and connect · Documentation
Latest runs: the same synthetic cryptomining case completed twice on the same configuration: Skill → native AgentTeams tasks → investigation → independent review → report delivery, in 5m 7s / 3m 52s. Both reports identified that stopping the process did not establish clearance, and limited the later successful checks to the observed window. Original reports, workflow records and review →
| Your task | CyberGuard provides | Start here |
|---|---|---|
| Delegate an investigation from your existing Agent | Connection instructions, material submission and backend reports | Connect your Agent |
| Review a proposed response | A console for targets, reasons, approval decisions and incident history | Operations console |
| Check whether a response worked | Run-linked observations, execution records and verification results | Real process laboratory |
| Bring existing security telemetry | Suricata file ingest and configurable read-only HTTP connectors | Ingest · Connectors |
Start with the web setup wizard. On Linux / WSL2 with Git, Python 3.12+ and Docker Compose, run from the repository checkout:
sudo python3 deploy/onboarding/bootstrap.pyOpen http://127.0.0.1:18120/setup. Create an administrator, enter your model endpoint, model name and API key, test the connection, initialize AgentTeams and enable investigations. Existing administrators can open Settings → Deployment wizard. Credentials remain on the deployment host. Setup guide (Chinese) · Chinese documentation
For manually managed deployments, follow the native backend installation guide. The following commands start the base console separately.
For analysts and teams who need an incident queue, approval screens, roles, API keys and an audit history.
With Git, Python 3.12+ and Docker Compose, run the following in Linux / WSL2 Bash:
git clone https://github.com/elsechord/CyberGuard.git
cd CyberGuard
python deploy/init_secrets.py
docker network inspect agentteams-net >/dev/null 2>&1 || docker network create agentteams-net
CYBERGUARD_COOKIE_SECURE=false docker compose up -d --buildThis command uses local HTTP sessions. For public deployment, keep secure cookies enabled and configure HTTPS as described in the deployment guide.
| Local entry | Purpose | Next step |
|---|---|---|
http://127.0.0.1:18120 |
Multi-user operations console | Create the first administrator and configure HTTPS/sessions |
http://127.0.0.1:18100/console |
Read-only evidence audit view | Collect the first fixture evidence |
The base deployment includes the console and a simulation response backend. Configure the administrator and HTTPS sessions, then follow the fresh-install guide to connect AgentTeams and your model for live investigations.
Then connect your Agent: open /connect, generate Skill v0.2.0 instructions and an investigation API key, and save the key in a private file on the Agent host. The Agent installs the Skill and checks its connection; you can then ask it to submit materials, follow tasks and retrieve reports. Connection guide →
You can also submit text or multi-source JSON directly in /investigations. Logs, financial records, audit reports and judicial documents share one material envelope, supporting plain text, JSON, CSV and Markdown. Source text and submitter interpretation stay separate. Material formats and domain adaptation →
The SQLite queue and stage checkpoints keep the investigation moving after the calling Agent disconnects. The Console shows waiting, running, failure and delivery states. Runtime configuration and task controls →
Keep your current Agent as the interaction entry point. The Skill's main role is backend delegation: submit authorized materials, inspect task status and retrieve the report. It requires file access and Python 3.10+, while the deployment supplies the AgentTeams runtime and model configuration.
Copy this into your coding Agent:
Set up CyberGuard Skill v0.2.0 in my current project and verify the configured
console connection. Obtain the source from https://github.com/elsechord/CyberGuard
in a separate directory, record the checked-out commit, and read
docs/EXTERNAL_AGENT_SKILL.md and integrations/agent-skills/cyberguard/SKILL.md.
Inspect scripts/install-agent-skill.py before using it. Choose --agent codex,
--agent claude or --agent generic for this host and --project for this project.
Reuse a compatible installation; do not overwrite existing files.
Use the console origin and private key-file path supplied by /connect.
Run check --investigations and report the actual result. If configuration is
missing, explain what is needed. This setup request does not authorize uploading
materials, starting an investigation, deploying services or taking response actions.
Or install from a checkout:
python scripts/install-agent-skill.py --agent codex --project /absolute/path/to/project
# For Claude Code, use --agent claude. The project must already exist.No console yet? Try the synthetic offline exercise, then connect the online backend for native tasks. Existing incident packages remain available through check / fetch.
One live case now runs end to end: fresh process evidence enters native AgentTeams investigation; the report is converted into a bounded proposal. After approval and execution, independent probes detect recurrence. The new evidence triggers another native investigation, proposal, approval and verification. One 11m 18s run passed 20 checks, with separate investigation and review Workers in each round. Original records and how to run it →
The Linux process lab demonstrates why an execution receipt is not an outcome check:
| Step | What happens |
|---|---|
| Observe | Collect a harmless experiment process and its persistence configuration. |
| Propose and approve | Bind approval to a specific process target. |
| Execute | The executor terminates that process successfully. |
| Verify | The supervisor restarts it. Independent observations return failed. |
| Propose again | A new proposal targets the persistence configuration and receives a new approval. |
| Verify again | The experiment process and persistence are absent during the observation window; the control workload continues. Result: verified. |
The demonstration operates harmless processes and real files in an isolated Linux environment. Published validation uses test approval; operators can choose interactive approval for a live demonstration. Run the dynamic proposal demo →
Earlier exercises and component checks
- Fixed-flow process lab: scripted decisions for approval and outcome-check regression.
- Account lab: disable access, probe independently and restore.
- Earlier native task record: supply-chain collaboration and target correction.
- v0.14.1 service walkthrough and evidence.
Start with the interface that matches your workflow:
| Integration | Input → output | Available today |
|---|---|---|
| Existing Agent / internal application | Authorized materials + objective → durable task → backend report | Skill v0.2.0 · Task API |
| Existing incident package | Incident JSON / read-only API → evidence for local review | Legacy check / fetch |
| IDS export | Suricata EVE JSON/JSONL → normalized evidence | File ingest adapter |
| SIEM / EDR / NDR / CMDB | Configured upstream HTTP response → incident evidence | Server-owned connector configuration; vendor mappings need adaptation |
| Internal application | Scoped API request → incident, evidence and proposal data | Console API v1 |
| SOAR / device execution | Approved proposal → response action → outcome observation | Executor extension work; production vendor-specific mutating integrations are not included |
For example, read incidents from a deployed console using a key with incidents:read scope:
# Bash. Configure these environment variables locally; do not put keys in source.
curl --fail --silent --show-error \
-H "Authorization: Bearer ${CYBERGUARD_CONSOLE_API_KEY}" \
"${CYBERGUARD_CONSOLE_URL}/api/v1/incidents?limit=5"List responses use data, has_more and next_cursor. Read one incident at /api/v1/incidents/{incident_id}. API key scopes control endpoint permissions. Endpoints, authentication and errors →
flowchart TD
S[Source text / external Agent] --> K[Skill or console submission]
K --> T[Investigation task service / SQLite checkpoints]
T --> P[AgentTeams Leader / Project DAG]
P --> I[Investigation Task / Worker]
I --> V[Independent verification Task / Worker]
V --> R[Report with material references]
R --> C[Console / calling Agent]
L[Fresh security observations] --> K
R --> O[Bounded proposal converter]
O --> H[Specific proposal approval]
H --> E[Response executor]
E --> Q[Independent outcome probes / audit]
Q -->|Failed: new evidence| K
Q -->|Verified: observed window| C
AgentTeams handles native investigation and independent review. A bounded converter maps the report and fresh targets to allowed executor proposals. Approval precedes execution; new outcome observations determine whether investigation should continue. The recorded case uses harmless processes in an isolated Linux environment and test approvals, with interactive operator approval available. Complete workflow →
-
Adaptive collaboration: Workers can create temporary specialists, exchange directed questions and clean them up through native WorkerFlow. Research · Validation
-
Evidence: normalization, source metadata, identifiers and citation checks. Observation model · Contracts
-
Controlled actions: allowlisted dispatch, proposal-bound approvals, idempotency and action audit records. Executor · Threat model
-
Outcome checks: account-access and process-state probes, run correlation and evidence export. Run example
-
Agent integration: ten AgentTeams role Skills, the portable Skill, and local AgentTeams setup.
-
Optional model admission guard: per-run budget reservations and role-bound routes. Guard documentation
Security is the first application domain. Financial, legal and other text can reuse the intake and review pipeline, with specialized interpretation, policies and outcome checks supplied through domain adaptation.
| Goal | Guide |
|---|---|
| Install or troubleshoot | Quickstart · Console deployment |
| Delegate from your Agent | Skill setup and connection · Tasks and materials · Backend configuration |
| Run a multi-Agent task | AgentTeams bootstrap · Local setup |
| Inspect the trust boundaries | Threat model · Live connectors |
| Reproduce and evaluate | Judge service checks · Investigation evaluation |
| Find releases and competition material | Releases · Competition guide |
Useful contributions include sanitized integration examples, connector mappings, independent outcome probes and reproducible failure cases. Start with an issue describing the input, expected result and reproduction steps. Do not include credentials or private telemetry.
For local tests, follow the development instructions. Run each test file in its own interpreter: several services use the same Python package name. CI is linked above. Upstream integration work includes the AgentTeams Worker console-binding PR #1287.
Apache-2.0. Third-party assets retain their respective licenses; typography notices for the README artwork are in brand assets.