zgsfsec/Full-Chain-Sentinel-System

If you already run authorized engagements and want an agent to carry a test from recon to written report, this is worth a look; if you expect a hard isolation boundary, the README is unusually upfront that it is not one.

The problem

A pentest spreads across terminals, notes, proxies, device bridges and a folder of screenshots until someone reconstructs a report. Here you create a project, pick a model, and work from a chat console that runs commands in a per-project Kali container. Recon, enumeration and verification all happen in one session tree, and confirmed bugs go through vuln_submit with a CVSS score, a saved raw request and an exportable Markdown report. The changed step is orchestration and evidence capture, not the tools themselves.

What's different

The methodology is baked into the system prompt: recon, enumeration, vulnerability mapping, verification, exploitation, post-exploitation, reporting, with emphasis on scope and minimal intrusion. Three execution modes shape approval: the default gates each bash command for edit/allow/deny, automatic mode runs freely, and AI approval has a separate gate model label commands ALLOW or BLOCK.

That third mode deserves care. The README states that a failed, timed-out or unparseable judgement is allowed through, so it is a convenience filter rather than a guardrail. Approval also covers only bash and the Android/iOS shell tools; read/edit/write, the file panel, MCP tools, codemode, and container-direct tools such as frida, packet capture and APK analysis skip the gate. Android and iOS support are driven by device-side bridges that connect back to the console, with iOS explicitly labeled as still in testing and requiring jailbreak basics from the operator.

Asset mapping is a genuinely useful addition: FOFA, 360 Quake and 360/奇安信 Hunter queries are issued by the console process, and only an enabled, configured and verified platform has its tool mounted, so unconfigured sources never enter the model's context. The trade-off is disclosure: search keywords and API keys go directly to Tavily and those asset platforms, bypassing the approval chain and container.

The container is per project, runs as root, defaults to host networking for realistic reverse shells and internal targets, and has no resource caps or seccomp. The console and agent themselves run as the launching host user, and project directories may load settings.json, .pi/extensions and AGENTS.md without a trust prompt. Treat it as a controlled lab workstation, not as a sandbox.

Who should try it

A good fit is a security consultant with written authorization and a disposable VM who wants a repeatable record of scope, commands and findings across web targets and possibly Android devices. A poor fit is anyone looking for a safe playground for untrusted targets or directories: host networking, root containers and unrestricted file edits make that a poor match. Teams without Docker or Windows users will also face friction, since Docker is a hard dependency and the README discourages Windows and lists extra OpenSSL/PATH setup. A device is not required to use the core console; Android and iOS tools appear only when the corresponding buttons or bridges are configured.

Requirements and limitations

Docker is mandatory, and the project lives in a Kali container with host networking by default and persistent NET_RAW. The console itself uses self-signed HTTPS with a rotating random entry path, so the full URL must be read from logs and certificates accepted or imported. Source runs need Node.js >= 22.19.0 and two separate build steps. Operational care matters more than setup: every session in a project shares one root container, direct-container tools and host file writes escape approval, and changing networks can require reissuing the TLS certificate. Custom MCP stdio servers execute as host subprocesses on first use, so only add servers you trust. Verify the license and GPLv2 exception in THIRD_PARTY_NOTICES if you plan to redistribute; the full setup and security notes are the place to check these boundaries against your own policy.

HotRepo's take

HotRepo first observed this project at 8 days old, with 439 total stars and #20 on the NEW-REPOSITORY board for TypeScript on 2026-10-25; that is a dated snapshot, not daily growth, and there is no comparable daily-board history, so persistence cannot yet be judged. Before committing an engagement, check whether the approval gaps described in the README match your rules of engagement.