Section 03

The toolchain at a glance

Before installing anything, hold the architecture in your head. The workflow is four parts: VS Code as the workspace, GitHub Copilot Chat as the AI client, the official Kali MCP server as the tool seam, and a Kali Linux Docker container as the execution environment. Two trust boundaries hold the whole thing together.

The four parts

┌──────────────────────────────────────────────────────────────┐ │ YOUR WORKSTATION │ │ │ │ ┌────────────────────┐ ┌────────────────────┐ │ │ │ VS Code │ ──────▶ │ Copilot Chat │ │ │ │ (workspace) │ │ (agent mode) │ │ │ └────────────────────┘ └─────────┬──────────┘ │ │ │ │ │ propose tool call │ │ │ │ │ ▼ │ │ ┌─────────────────────┐ │ │ │ OPERATOR APPROVAL │ ◀── trust boundary #1 │ └─────────┬───────────┘ │ │ │ │ │ approved JSON-RPC │ │ │ │ │ ┌──────────────────────────────────────▼─────────────┐ │ │ │ Kali container (Docker) │ │ │ │ │ │ │ │ ┌──────────────────┐ spawns ┌────────────┐ │ │ │ │ │ mcp-kali-server │ ─────────▶ │ Kali tool │ │ │ │ │ │ on 127.0.0.1:5000│ │ (nmap...) │ │ │ │ │ └──────────────────┘ └─────┬──────┘ │ │ │ │ │ │ │ │ └─────────────────────────────────────────┼──────────┘ │ │ │ │ │ ◀── trust boundary #2 ── │ │ │ │ └─────────────────────────────────────────────┼────────────────┘ ▼ target on your LAN

1 · VS Code — the workspace

VS Code is where the engagement lives. The authorisation file, the prompt history, the notes file, the report draft, the mcp.json configuration, and the rendered conversation with the assistant all sit in one folder. Treat that folder as the engagement record — when the audit is finished, it is the artifact you keep.

2 · GitHub Copilot Chat — the AI client

Copilot Chat in agent mode is the driver. Agent mode is the capability that lets the assistant propose tool calls to an attached MCP server, observe the output, and reason about what to do next. Without agent mode, Copilot can only write code — it cannot run anything against a target.

The phrase to internalise: the assistant proposes, the operator approves, the MCP server executes, the assistant reads the output back. Never "the AI ran a scan". The grammar matters because it tracks the legal reality.

3 · The MCP server — the tool seam

The Model Context Protocol is an open JSON-RPC protocol for giving language models structured access to tools. The official mcp-kali-server package exposes the Kali toolset — Nmap, Hydra, Nikto, the Metasploit modules, cURL, OpenSSL and friends — as MCP tools that an agent can call.

The server binds to 127.0.0.1:5000 on the container's network namespace. On Linux with host networking, that is the host's loopback. On Windows and macOS, that loopback is exposed to the host by Docker Desktop's port mapping. It does not bind to the network interface. An attacker on your LAN cannot reach the MCP server.

4 · The Kali container — the execution environment

The container is a stock Kali Linux image with the default toolset, the MCP server package, and systemd booted as PID 1 so that the MCP server runs as a managed service. Section 04 walks the manual setup; Section 05 wraps the same steps in Docker Compose. By the end of either, you can stop and start the lab from Docker Desktop with one click.

The two trust boundaries

Two things hold the workflow safe. Both are worth understanding before you install anything, because they are the answer to "what if the model misbehaves?".

Boundary 1 — Operator approval

Every tool call agent mode proposes appears in the chat as a card with the tool name, the arguments, and an approve / deny control. The MCP server does not execute the call until you approve. There is no auto-approve setting in this guide's configuration; if you find one, leave it off.

This boundary is what makes the assistant's proposing distinct from doing. The model can be confidently wrong about what a command does, or be steered by something in a returned banner; the approval gate gives you the moment to read the proposed command against the scope file and refuse.

Boundary 2 — Container isolation

The toolset runs inside Docker, not on your host. Even with --privileged set (which is required for systemd to manage cgroups), the container is a separate process tree, separate filesystem, and separate package universe from your laptop. If the container ends up in a state you do not like, docker stop kali-mcp && docker rm kali-mcp is a five-second reset.

Note that --privileged is not nothing — it grants the container meaningful access to host resources. The mitigation is to run the lab on a machine you treat as a single-purpose audit workstation, not on a shared development laptop. This warning recurs throughout the manual and compose setups in Sections 04 and 05.

What this architecture buys you

  • Repeatability. A scoped audit is a sequence of approved tool calls plus the rendered chat. Anyone with the same lab and the same authorisation file can re-run the session.
  • Auditability. Copilot Chat keeps the conversation. The MCP server logs the calls. Docker logs the container's stdout. Between them you have a record of every command that ran.
  • Cross-platform parity. The same compose file, the same MCP server, the same prompts work on Linux, Windows, and macOS hosts. Only the Docker network plumbing differs.
  • Disposable lab. Method 2's compose file rebuilds the lab from scratch in a few minutes. Treat the container as cattle, not pets.

What this architecture does not buy you

  • Skill replacement. The assistant proposes good commands and bad ones. You still need to know what an Nmap flag does to evaluate the proposal.
  • Authority to act. The architecture cannot tell whether the target IP is in your authorisation file. Only you can.
  • Protection against prompt injection. Banners, HTTP response headers, RTSP descriptions, and CVE write-ups returned by tool calls can carry instructions that hijack the next proposal. Section 08 covers this in detail.
If you read nothing else

The four parts: VS Code, Copilot Chat in agent mode, the MCP server on 127.0.0.1:5000, the Kali container. The two trust boundaries: operator approval on every tool call, and container isolation. With those six things in your head, the rest of the guide is implementation detail.

Check yourself

Three questions on the architecture

The two trust boundaries are the load-bearing safety properties of this entire workflow. If you can't name them and what each protects against, the rest of the guide won't keep you safe — because you won't know when one has been compromised.

Q1 / 3

What is the first trust boundary, and what does it protect against?

TLS between VS Code and the MCP server, protecting against on-LAN sniffing.
No The MCP server in this guide binds to loopback; nothing on the LAN can reach it. TLS would be cosmetic on a localhost socket.
Operator approval on every tool call, protecting against the assistant executing actions you did not intend.
Yes The approve / deny gate is what separates "the assistant proposed a command" from "a command ran". Every other safety property in the workflow assumes this gate is intact.
Authentication against the Kali container, protecting against unauthorised lateral access.
No The container has no remote auth surface — it is reached via Docker's local IPC, not over a network. Authentication isn't the mechanism.
Q2 / 3

What is the second trust boundary, and what does it protect against?

Container isolation, protecting your host filesystem and host package universe from whatever the toolset does.
Yes The Kali toolset lives inside Docker. A misbehaving tool, a compromised binary, or a noisy install affects the container — which can be torn down and rebuilt — not your laptop.
Copilot's content filter, protecting against the model emitting harmful commands.
No Content filters are part of the model provider, not this architecture. They are not the boundary the guide relies on.
A firewall rule restricting the container to your LAN segment.
No Firewall rules aren't part of the lab's default configuration. The boundary is isolation of the container's process tree and filesystem from the host.
Q3 / 3

Why does Section 03 specifically warn against running this lab on a shared development laptop?

Because Docker Desktop is slow on shared machines.
No Performance is not the concern Section 03 raises.
Because --privileged grants the container meaningful access to host resources, so a compromise of the container is closer to a compromise of the host than a non-privileged container would be.
Yes Container isolation is not "nothing", but --privileged weakens it. The mitigation is to keep the lab on a machine whose other contents you would not mind losing.
Because Kali Linux installs malware on the host operating system by default.
No Kali is a distribution like any other; the concern is privilege and host access, not malicious installation.