ZAP MCP add-on

The add-on holds no downstream credentials of its own; every tool runs with the full authority of the ZAP process that hosts it. Callers are authenticated with one randomly generated 32-character key compared in constant time and the listener is HTTPS-only by default, but there is no per-tool, per-user or read/write separation: whoever has the key can start scans, change contexts, write report files and read all recorded traffic. The key check can be switched off by an options change or by an empty key in the config job, and the server itself is off until the operator enables it.

The server gives the host no risk signalling to build an approval gate on. Tool listings carry only a name, description and input schema, with no read-only or destructive hints, and there is no dry-run, preview or server-side read-only mode. Read, start and stop operations are at least split into separate, clearly named tools, but a host cannot tell that zap_generate_report writes an arbitrary file or that zap_start_active_scan attacks a live target without reading descriptions.

Argument handling is mostly presence checks and syntax parsing. Scan targets are only parsed as URIs; there is no host allowlist, scope check or internal-address blocking, and the report tool takes any file path. The one tool with real validation is the history reader, which allowlists field names, parses integers and windows large bodies. All 17 tools, including write and active-scan tools, are always registered with no way to enable only a read-only subset.

No model-reachable path in this add-on interprets text as code: there is no shell, process spawn, script engine, dynamic class loading or eval in the main sources, and the tools only build fixed automation jobs (spider, AJAX spider, active scan) and call the report generator. The shipped extender-script templates are run only if the operator enables them in ZAP's scripting add-on. The scanner itself sends test requests to targets, which is outbound traffic scored under tool scoping and untrusted input, not local code execution.

The server returns content that originates from scanned targets, including HTTP bodies and headers from history and alert evidence, as plain text or JSON with no provenance or untrusted marker, and offers no read-only or no-egress mode. A hijacked model reading that content can start spiders or active scans against any URL, which is both an outbound channel and an irreversible action on third parties, and can write report files, all without any server-side approval. The tool descriptions themselves are static and contain no directives.

The add-on does not load instruction files or project config from the working directory, but state the model can change persists inside the ZAP session: zap_create_context and the scan tools create contexts that define scan scope, and an existing context with the same name is deleted and replaced without any check, including contexts the operator set up. Nothing validates or gates these writes and nothing logs them. Persisted contexts affect later scans started by any client.

The add-on does not launch or download any third-party code: it starts no MCP server subprocesses, fetches no remote tools or models, and installs no packages. The importer only connects to an MCP server the operator names, as a test target. The tool registry is public, so other ZAP add-ons or operator-enabled extender scripts in the same process can register tools with full ZAP authority, which is ZAP's own extension model and is not verified or gated by this add-on.

The security key is stored in ZAP's configuration as plaintext and shown and copyable in the options panel; there is no masking or redaction anywhere. Request and response payloads are logged only at debug level, and request recording into ZAP history is off by default. Tool and resource results return target traffic unredacted, including headers that may hold session tokens or credentials of the tested application. No telemetry beyond local counters was found.

Tool calls are not recorded by default beyond debug-level log lines and per-tool success and failure counters that carry no arguments or caller. An optional setting records each MCP HTTP exchange, including rejected requests, into ZAP history with full request and response, which would give a structured record of calls, but it is off by default, has no actor or approver attribution, does not cover the event-stream GET path, and is best-effort. The model has no tool to delete history, but the record lives in the same ZAP session it can read.

The server enforces few bounds on its own work. The history tool defaults to a 4000-character body window but the caller can raise it, scans have no server-side time, concurrency or count limits, and resources are returned in full. Scan start waits at most 10 seconds for an ID, which bounds waiting rather than work. Stop tools exist for spider, AJAX spider and active scan and cancel the running job, which is the main damage-limiting control.