An active scan is an attack against a real system, so the interesting design decisions are the limits: scoped tokens, policy dry runs before rule changes, rate limits and an audit trail. The findings diff is the operationally useful piece - it answers whether this release made things worse, which a raw scan report never does.
A self-hosted server that exposes ZAP over streamable HTTP with an operator in charge. Rather than handing a scanner to a model, it offers guided workflows with defaults, tool scopes, policy bundles, rate limits and audit events around them.
- Crawl and active-scan lifecycles that can each be started, polled and stopped, plus passive-scan status and a wait
- Findings as a summary, in detail, as a snapshot, or as a diff between two runs - so a scan can be compared with the previous one
- Reports generated and read back, with the available templates listable
- Target import from an OpenAPI spec, a GraphQL schema or a SOAP WSDL, each from a file or a URL
- Scan policies listed and viewed, individual rules set, and a dry run that shows what a policy change would do before it is applied
- Authenticated scanning: prepare and validate a session, and test a user
- Scan history listed, retrieved, exported, and packaged as a customer handoff or a release evidence bundle
- The site, host and URL inventory ZAP has built up
Docker 20.10 or newer with Compose v2, and an MCP-capable client - a bundled Open WebUI client is included. Three scripts are the supported path: one generates the local API keys and prepares the ZAP workspace, one starts the stack, and a doctor script checks authentication, the handshake, the tool listing and a harmless call. Access is by API key or JWT, with per-tool scopes. Kubernetes deployment goes through Helm.
Run a container — pull the image and point your client at it