Skip to content

Darktrace MCP v1.1.0

Choose a tag to compare

View all tags
@nuoframework nuoframework released this 06 Oct 16:51
· 104 commits to main since this release
v1.1.0
f95e798
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

darktrace-mcp 1.1.0

  • Public distribution. The package is @nuoframework/darktrace-mcp on the public npm registry (published from CI with npm trusted publishing and provenance), the image is ghcr.io/nuoframework/darktrace-mcp:<version> (linux/amd64 and linux/arm64, pinned by digest), and the server is described for the MCP Registry as io.github.nuoframework/darktrace-mcp (mcpName in package.json, server.json). Bootstrap: npx -y @nuoframework/darktrace-mcp@1.1.0 setup. When run from the npx cache, setup copies the verified package tree to ~/.local/share/darktrace-mcp/<version>/ and writes absolute node + dist/src/index.js paths, so clients never launch npx. These channels are live only after the owner's publication steps (releases).
  • Full API surface with profiles. 77 of the 79 catalogue operations are executable, as 50 tools. One operation is excluded (the Darktrace/Email action, below) and one is deprecated (GET /aianalyst/incidents). DARKTRACE_PROFILES selects read (default), sensitive, write, critical or all. Every Darktrace/Email read needs sensitive. 56 operations have evidence from one Darktrace 7.1.0 lab, 11 of them only partial; the others are marked "not lab-validated" (tool reference).
  • Write controls. Ordinary writes accept dryRun:true for a value-free preview; without it they run, relying on the host's tool-permission prompt (DARKTRACE_WRITE_APPROVAL=host, the default). Critical actions need a dryRun:true preview, then confirm:true with its single-use previewId (5 minutes) and, by default, an accepted server confirmation dialog (approved:true, at most one per session and four per process, 30-second deadline); a call without confirm:true is refused with confirmation_required. DARKTRACE_CRITICAL_APPROVAL=host needs DARKTRACE_ACKNOWLEDGE_HOST_APPROVAL=true. Writes are rate-limited (at most 10 per minute), a breaker stops all writes after three failed or unknown outcomes in a row until restart, optional protected targets and fixed per-call target caps apply, and every preview, refusal and write is written to a hash-chained audit line on stderr.
  • Sensitive and write together. Any profile list with both sensitive and write, including all, starts only with DARKTRACE_ACKNOWLEDGE_SENSITIVE_WRITE=true.
  • Darktrace/Email action excluded. darktrace_email_action is not registered in any profile: its signing and request schema are unvalidated and the lab token got 403.
  • Older variables. DARKTRACE_SENSITIVE_READ and DARKTRACE_WRITE_CRITICAL still work on their own. When DARKTRACE_PROFILES is set they may only agree with it or narrow it; a value that would add an unlisted capability stops startup.
  • Easier installation. New darktrace-mcp setup wizard (hidden token entry, 0600 token files under ~/.config/darktrace-mcp/, permission preset, automatic configuration of Claude Desktop, Claude Code, Codex, Cursor, VS Code, Windsurf, OpenCode and Gemini CLI with backups), plus config <client>, remove and test. One-line installers scripts/install.sh and scripts/install.ps1.
  • Claude Desktop extension. npm run pack:mcpb builds a .mcpb bundle; Claude Desktop stores the tokens in the OS keychain.
  • Documentation restructure. Short bilingual READMEs; task-oriented guides (getting started, clients, configuration, troubleshooting, security overview) with Spanish versions in docs/es/; generated tool reference (npm run docs:tools); past review and release reports moved to docs/history/.

Known limitations in 1.1.0

From the 1.1.0 final gate review §4. None is an exploitable defect found in the server, and none is an owner acceptance of risk.

  1. Email. The email action is excluded. Email reads are not lab-validated (the lab token got 403). Their schemas come from darktrace-sdk 0.10.1, and responses may be sparse.
  2. Lab scope. One 7.1.0 appliance and one broad token. Partial tests: Antigena manual block and clear only; subnets label only; intel feed add and remove only; models, components and enums only with responsedata (full lists return too_large). Appliance errors: get_cves returns 500 and get_filtertypes returns 302. Most write evidence predates the final write controls; after them, only the intel-feed critical flow, the post_tags preview, the confirmation_required refusal and POST Advanced Search were checked live. The GET Advanced Search forms passed live only before their path encoding changed; the current encoding has probe evidence for = only.
  3. PCAP. A download is returned whole or fails with output_limit_exceeded. Captures above about 45 KB do not fit the 60,000-character output budget. The current contract was never tested live.
  4. DELETE and the write breaker. The lab gateway answers 502 to every DELETE after applying it, which the server records as outcome:"unknown". Three in a row open the write breaker until restart.
  5. Sensitive and write together. There is no taint control. Once acknowledged, ordinary free-text writes (comments, tag descriptions, labels) can carry sensitive data out of the appliance. Comments cannot be deleted and every appliance user can see them.
  6. Approval. Ordinary writes default to writeApproval=host: no server prompt. host mode delegates critical consent to the host. Auto-answering clients or "always allow" rules remove the human; the server cannot verify that a human answered.
  7. Per-process state. Rate limits, the breaker, previews and the audit chain are per process; several host processes multiply the budgets. Audit chains share one genesis and carry no boot identifier. The audit goes to stderr only, with no external anchor. A restart resets the breaker.
  8. Sensitive reads are not audited.
  9. Protected targets are opt-in and match literal values only. For post_antigena they match the action codeid, not the device. maxTargets is owner policy.
  10. Token scope. There is no least-privilege token mapping per profile. Appliance token permissions remain the real ceiling.
  11. Data egress. Every result, including Base64 PCAP data and email metadata, reaches the MCP host and its model provider.
  12. Signing. GET Advanced Search depends on proxies keeping percent-encoding byte-exact. A combined query and JSON body is refused.
  13. Distribution. No image attestation; the SBOMs are inventories, not clearances. The ghcr image is rebuilt in release.yml; it is not the CI-tested image. For 1.1.0, the linux/arm64 image passed the local Docker gates; linux/amd64 is verified only by CI on the release commit, and there is no vulnerability scan of the 1.1.0 runtime yet. Docker Desktop needs DARKTRACE_TOKEN_FILE_OWNER=root-or-current. The server.json OCI launch passes tokens as container environment variables, readable by anyone with Docker access. Native Windows cannot protect token files.
  14. Previews. The preview store evicts the oldest live critical preview once it holds 256 (availability only).
  15. Lab residue. Undeletable [mcp-test] and [mcp-ux] comments remain on the lab appliance.

Install

npx -y @nuoframework/darktrace-mcp@1.1.0 setup

Claude Desktop: download darktrace-mcp-1.1.0.mcpb below and open it. Docker: pin the digest.

ghcr.io

ghcr.io/nuoframework/darktrace-mcp:1.1.0
ghcr.io/nuoframework/darktrace-mcp@sha256:dd79adb2dfe78134fa9721508a1f46776ed1736158dcf0b7f54e1dd0bca2d511
linux/amd64 sha256:4828a4782695127a759f281e6786b24d5bd9b785ab4c56d64a965888e9a5df84
linux/arm64 sha256:e4317b8ee34d8342498590279ca868b6691733bef9562f2a9071af318925a978

Pin clients to the digest: darktrace-mcp setup --runtime docker --image ghcr.io/nuoframework/darktrace-mcp@sha256:dd79adb2dfe78134fa9721508a1f46776ed1736158dcf0b7f54e1dd0bca2d511

Docker gates (ci.yml at f95e798)

npm

@nuoframework/darktrace-mcp@1.1.0 is live on the public npm registry with a signed provenance statement (Sigstore log index 3112942967; tarball SHA-256 1b36cc9f65d9dbdd9558f1dfc2e5aa96041a1fdbc0a3f6ab33ceb4862f257c49, shasum 98bb85d46b286fc89822b2524f5ad2e6a9d58b41). The attached tarball is the identical, verified artifact.

Verify

shasum -a 256 --ignore-missing -c SHA256SUMS

Evidence: security-receipt.json, verification.json, build-evidence.json, runtime-sbom.cdx.json, mcp-tool-contracts.json. Disclosed residual risks: see CHANGELOG 'Known limitations in 1.1.0' and docs/security/final-gate-review-1.1.0.md.

Assets 13
Loading