docs: the UI the engagement split actually shipped
A deep check of every hand-written page against the branch found six gaps. The
two generated pages (Project Settings Registry, MCP API Reference) were already
current; every gap was in prose nobody regenerates.
Rules of Engagement
- `roeForbiddenCategories` listed four tokens. There are five: `exploitation`
was missing.
- `roeForbiddenTools` read as free text. Both lists are now closed vocabularies
ticked from the registry, and the page says why that is a safety property
rather than tidiness: the gate matches these strings EXACTLY, so a near-miss
is not partially enforced, it is not enforced at all. A live project held
`execute_sqlmap`, which is not a tool, beside categories reading "Denial of
Service" and "Brute Forcing", which the gate does not know.
- The parse section did not mention that an oversized proposal is refused with
422 and writes nothing, nor that a policy's identification header now reaches
`engagementIdentityHeader` - the single most common concrete instruction such
documents carry, in 28 of 60 sampled.
- The authorization history panel was undocumented: append-only, digest only,
and a failed fetch is not the same as "no record".
Project Settings Reference
- The page told readers the agent's limits were in Agent Behaviour and then
never listed them. All six are documented there now.
- The "Advanced" block was undocumented. It is in seventeen module sections and
exists because sixty-five columns were writable over the API with an input
nowhere in the form.
MCP Server
- "The thirty tools" is thirty-four. `create_project`,
`attach_engagement_authorization` and `list_engagement_authorizations` were
missing from the table, and `project:create` and `engagement:authorize` from
the permissions.
- "Not exposed, deliberately" still listed the scope fields. Scope is now a
create-only exception with a stricter rule, and the page states it.
- "Only about 126 tuning fields are settable" is 648 of 714.
Screenshots retaken (the old ones predate the split by six months) and two
added: the engagement limits in Agent Behaviour showing the tool checkboxes, and
the registry-generated Advanced block.
Checked and clean: no stated default or numeric bound on any hand-written page
disagrees with the registry; no page still names `tighten_engagement_roe` or
`roeEnabled` as a switch.
docs: split Rules of Engagement into limits and record
The engagement is two unrelated things, and the wiki described it as one.
Rules-of-Engagement.md is rewritten around the split: the LIMITS are ordinary
settings, reachable from the form and the API alike and enforced at scan start,
and the RECORD is the contract a person writes and no token can touch. The
"set once at creation, read-only afterwards" claim is gone; only the record is
creation-time.
Also updated:
- Recon-Presets: a preset never carries the engagement, at capture or at apply,
and the exclusion is a registry query rather than a name-prefix match
- MCP-Server: update_recon_settings reaches the limits in either direction, and
what keeps that safe is enforcement at scan start, not a write-time rule
- Creating-a-Project: tab 1 is the Engagement Record; the limits live elsewhere
and stay editable
- Origin-Discovery: the mechanism is unchanged, the field classification is not
- AI-Gauntlet: its RoE checkbox is a per-launch confirmation, distinct from the
project's engagement limits
- Project-Settings-Reference: an Engagement Limits section, and two checked
counts instead of one wrong one. "714 configurable parameters" overstated the
surface exactly as the "245+" it replaced understated it
- Project-Settings-Registry and MCP-API-Reference: regenerated
A test fails any page that still names tighten_engagement_roe, the tighten_only
disposition, or a roe* field as MCP-settable.
docs: refresh the MCP Server tab screenshot for the row actions menu
The image still showed Edit | Revoke spelled out per row, which predates both
the Onboard action and the menu. Reshot with the same demo tokens and the same
framing, with one row's menu open so the page shows what the kebab contains.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
docs: the token row's actions are a menu, and Revoke is now Delete
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
docs(mcp): agent onboarding, and kali:exec described as the shell it is
The API reference is regenerated from the live tools/list, so the kali:exec
permission row and the kali_exec tool now describe a shell rather than the
allowlist that no longer exists.
MCP-Server.md gains the Agent Profile table and the onboarding-pack section,
with screenshots for the profile picker, a profile change and the export.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
docs: the inbound MCP surface at thirty tools, and kali_exec
MCP-API-Reference is generated by `npm run docs:mcp` from the server's own
tools/list; a unit test compares it byte for byte, so it is never edited by
hand.
MCP-Server gains the kali_exec section: the four switches that gate it, the
per-tool flag allowlist and what it refuses, the 300s sandbox cap, and the
rate limits. Plus the Agent Profiles and onboarding screenshots.
docs(mcp): sections for the seventeen new tools, and refreshed screenshots
The page documented thirty tools in its table but explained only the original
handful. Eight new sections cover what the rest actually mean:
- findings, and the triageState trap: on a project no triage run has completed
NOTHING is scored, so an unscored finding is not an unimportant one
- list_muted_findings, and the false negative it closes: "zero open findings"
and "somebody suppressed thirty criticals" otherwise look identical
- what changed since the last scan, including which versions survive retention
and why comparing two saved versions beats comparing against the live graph
- the three precomputed views, and why blast radius answers a different
question from "what is the worst finding"
- saved views, and why a view that works in the app can still be refused here
- the queue, including the two residuals: a queued job outlives the token, and
it appears in the operator's own queue attributed to them
- verdicts, and why the surface can rank a finding but never hide or reveal one
- the settings manual and why presets are read-only: a half-applied stealth
preset is LOUDER than not applying it
Also a section on withdrawing a single tool, which had no user-facing
documentation at all, and three corrections where the page still described the
old boundary: the token-limits list now covers mute/unmute, the refusals list
covers comparing across a state change and writing a verdict under a triage
run, and the audit table lists the verdict and queue records.
Screenshots regenerated: the tab and the new-token form now show all nine
permissions rather than six.
docs(mcp): get_project_activity is metered as a question, not a cheap read
docs(mcp): the verdict tool, the scanner status read, and triage:write
Tool table, permissions row, the write rate-limit row, and the permission count
(now nine). The "not exposed" paragraph now draws the distinction that matters:
an agent can record a VERDICT, which ranks a finding, and can never MUTE or
unmute one, which hides or reveals it.
MCP-API-Reference.md regenerated.
docs(mcp): seven more tools and the recon:queue permission
Tool table and heading, a permissions row, the rate-limit table (queue_recon
takes the per-project start window, not the write budget; run_graph_view and
the analytics views take the query one), and the permission count in the alt
text and in Global-Settings, now eight.
MCP-API-Reference.md regenerated from the live tools/list.
docs(mcp): eight new tools, the triage:read permission, regenerated reference
MCP-API-Reference.md is regenerated from the live tools/list, never hand-edited.
MCP-Server.md: the tool table and its heading, a permissions row, the
rate-limit table (its "Applies to" column enumerates tools per bucket, so every
row was wrong), the concurrency paragraph now that the findings path takes the
same ceiling, and the "not exposed" paragraph - the other scanners' findings
are readable while starting them is not.
Global-Settings.md and the MCP-Server alt text both said "five permissions",
which was already stale at six before this and is now seven.
docs(mcp): the liveGraphState table was missing two states and overpromising
`stable` claimed the counts are trustworthy in cases where they were not:
five of the seven scan kinds never moved the state off it. Document the two
new states (`agent_writing`, `unknown`), say that `scan_running` now covers
all seven kinds, and describe `hiddenFromCounts.stale` including why the key
is absent rather than 0 when it cannot be read.
docs: document the MCP Server surface, incl. kali_exec
Rename MCP-Access-Tokens to MCP-Server and cover the whole inbound
surface rather than just the token screen.
- MCP-Server: thirteen tools, the four switches guarding kali_exec, the
per-tool flag allowlist and what it refuses, rate limits and audit rows.
- MCP-API-Reference: generated by `npm run docs:mcp` from the server's own
tools/list. Never hand-edit; a unit test compares it byte for byte.
- Sidebar, Home and Global-Settings point at the new page name.