Cybersec Toolkit

    /\   /\        ______      __              _____

(o ) ( o) / ____/_ __/ /_ _ _/ _/_ ___ \ \_/ / / / / / / / __ \/ _ \/ _/\ \/ _ \/ _/ <==\ /==> / /_/ /_/ / /_/ / / / _/ / / / \ V / \__/\, /_._/\_/_/ /__/\_/\___/ /_ _\ /____/ by 26zl |_| Toolkit

A security toolkit that AI agents can drive, under rules you set. One command installs 670+ security tools on Linux or Termux. An MCP (Model Context Protocol) server lets Claude Code, Codex, Gemini CLI, OpenCode, and other MCP clients discover, recommend, and run those tools through a governed execution path, inside a disposable Kata Containers VM by default. 872 Agent Skills supply the methodology for CTF, pentest, bug bounty, DFIR, and blue-team work.

What makes it different: most toolkits stop at _installing_ tools. Here an AI can also _drive_ them: infer the problem type, pick tools from every module and profile, and work through the problem with you step by step. When you explicitly authorize it, the same toolchain runs an autonomous solver loop. Companion by default; autonomous only when you ask. It complements Kali, Parrot, or BlackArch rather than replacing them: it runs on the machine you already have, Termux included.

Quick start · How it works · Trust & safety · Installer · MCP server · Agent Skills · Development · License

Quick start

1. Install the tools on a supported Linux distro or on Termux:

git clone --depth 1 --branch v1.4.0 https://github.com/26zl/cybersec-toolkit.git && cd cybersec-toolkit

./install.sh --doctor # read-only preflight: distro, prerequisites, MCP server, sandbox sudo ./install.sh --profile ctf # one profile; with no flags, all 18 modules

2. Connect an AI client. The tracked configs for Claude Code (.mcp.json, also read by the GitHub Copilot CLI), Codex, Gemini CLI, and OpenCode start the server through scripts/mcp-launch.sh, with external targets and script execution disabled. Choose where the tools run:

Kata needs KVM: on macOS, on Windows, and in VMs without nested virtualization, use host mode.

3. Restart the client. The 15 tools appear (/mcp in Claude Code). Then ask for what you need, for example "triage this binary" or "map the attack surface of my lab at 10.10.0.0/24".

How it works

Two entry points share one tool registry. An operator runs the bash installer to put tools on disk: on the host, or into the sandbox image at build time. An AI agent talks to the MCP server, which runs inside a Kata VM by default, to discover, recommend, and execute those tools through one governed path. tools_config.json is the single source of truth that the modules define and the MCP advisors read; CI validators keep the Python and bash sides in sync.

Solid arrows are runtime or installation actions; dashed arrows are validation and context relationships. Client configurations enter through the root-aware launcher, which boots the VM through a Sandcastle Kata provider (sandbox/kata.mjs) — or, with --local, starts the server on the host. security.py governs run_tool and run_pipeline through the allowlist, argument checks, and network policy without invoking a shell. run_script is a separate, disabled-by-default capability that runs arbitrary code. Agent Skills stay outside the execution path: .claude/skills/ is canonical, and scripts/sync-skills.sh generates .agents/skills/ for clients that read the portable mirror. Mermaid source: assets/how-it-works.mmd.

Trust & safety

What runs, and what is gated:

• Default-safe MCP. CYBERSEC_MCP_ALLOW_EXTERNAL=0 rejects network targets that do not resolve to private or loopback ranges, and CYBERSEC_MCP_ALLOW_SCRIPTS=0 disables run_script. External scopes and scripting are explicit opt-ins.
• One gate for governed execution (mcp_server/security.py): registry allowlist, no shell (create_subprocess_exec, never shell=True), argument sanitization, a per-tool blocked-flag denylist (e.g. sqlmap --os-shell, nmap -iL, file-list and target-injection flags), target and network policy, rate limiting, output caps, and timeouts. The policy knows enough CLI grammar to tell a target from a header, wordlist, output path, or target-list flag. Tool output reaches the model without terminal escape sequences or LLM control markers, and lines addressed to an AI reader are flagged.
• Tools run in a disposable VM by default. The launcher boots a Kata Containers VM with its own kernel, no host filesystem beyond an optional CYBERSEC_SANDBOX_WORKSPACE mount, no Docker socket, a non-root user with every capability dropped, and memory, CPU, and process limits. It is destroyed when the client disconnects. Startup fails closed instead of falling back to the host; --local is the explicit opt-out.
• Know the limits. The VM is not a network boundary: it reaches whatever its Docker network reaches, and CYBERSEC_MCP_ALLOW_EXTERNAL is a preflight check on resolved addresses, not a firewall (set CYBERSEC_SANDBOX_NETWORK=none or use a filtered network). Inside the VM, and on your host in --local mode, allowed tools run with the server user's permissions, and some of them spawn child processes or load plugins.
• Tool output goes to your model provider. Whatever a tool prints — scan results, page content, and any credential or personal data it finds on a target — is returned to the AI client and sent to the model it uses. By default only the local audit log is redacted; set CYBERSEC_MCP_REDACT_OUTPUT=1 to also redact credential-shaped strings from what the client receives. If an engagement's rules forbid sharing client data with a third party, drive the server from a local model (see AI clients).
• Repository hooks run automatically. Opening this repository in Claude Code runs the tracked hooks in .claude/settings.json: scripts/agent-guard.sh at session start and before each Bash command. They only emit routing context or a deny decision, make no network calls, and fail open; set CYBERSEC_AGENT_GUARD=0 to disable them.
• Audit trail without leaks. Actions are logged as JSON lines to an owner-only (0600), rotating log under the user's state directory (~/.local/state/cybersec-tools-mcp/audit.log by default). Script bodies are never stored, only their SHA256 and length, and credential-shaped strings are redacted from tool arguments. A sandboxed server mirrors its records to the same host log, and records are hash-chained, so an edited or deleted record inside a chain shows up in make audit-verify (limits).
• Least privilege in the installer. It runs as root but drops to the invoking user ($SUDO_USER) for cloned-repo builds, go/cargo/gem builds, and project setup steps (theHarvester, pwndbg); binary releases are SHA256-verified when checksums are published. pipx installs (into the shared /opt/pipx) and global npm installs still run as root, so their build and install scripts execute with root privileges — see the supply chain model. Go binaries are copied into /usr/local/bin as root-owned files; cargo, gem, cloned-repo, source-build, patator and Foundry tools are exposed there as links or wrappers into trees the invoking user owns, so that user can change what those commands run.
• Dual-use tooling is gated. C2 and phishing frameworks (Sliver, Caldera, gophish, evilginx, …) are off by default and install only with --include-c2 (the redteam and full profiles set it); the MCP layer reflects this and never auto-runs them.
• Authorized use only. See SECURITY.md, the supply chain model, and the disclaimer.

Installer

Requirements

A supported Linux distro (Debian/Ubuntu/Kali/Parrot, Fedora/RHEL, Arch, openSUSE) or Termux. Runtimes (Python, Go, Ruby, Java, Rust, Node.js), dev libraries, pipx, and build tools are installed automatically. The installer does not run on macOS or native Windows; use WSL or Docker.

• Docker is needed for --enable-docker (C2 frameworks, MobSF, BeEF, BloodHound, TheHive, Cortex) and for the blueteam, redteam, blockchain, and mobile profiles, which enable Docker images by default (see Profiles). Install it yourself: Docker Engine docs.
• GitHub authentication is recommended. The installer download