AI assistant (MCP)
Connect a coding agent (Codex, Claude Code, Kimi Code, GLM) to a Workbench mission through a local, permission-gated MCP bridge.
The Workbench can hand one mission to an external coding-agent CLI such as Codex, Claude Code, Kimi Code or GLM CLI, through an optional, local MCP (Model Context Protocol) bridge. The agent can then read your notes and evidence, draft findings, and (only if you allow it) run commands in the mission’s lab.
In short
- RF Swift does not call a model API, select a model, store provider API keys or charge for AI usage. The coding-agent CLI owns its authentication, subscription, model choice and billing.
- The Workbench itself stays standalone: the agent CLI is optional, installed separately, and runs in the Workbench’s own Agent terminal panel.
- The bridge is off by default, opens no network port, and exposes only the tools you permit.
flowchart LR
U[You] --> C[Codex / Claude Code / Kimi / GLM CLI]
C <-->|stdio MCP| M[RF Swift Workbench MCP]
M --> N[Mission notes]
M --> F[Structured findings]
M --> E[Approved evidence]
M -. optional .-> T[Commands in the mission target]Security model
- The bridge is off by default and uses standard input/output: RF Swift opens no MCP network port.
- Each launch is scoped to one project and one mission.
- Permissions are independent and additive:
| Permission | What the agent gets |
|---|---|
| Read-only | Mission discovery, notes, findings, the audit report and the evidence index |
| Write | Adds write_note and save_finding (and save_secret) |
| Command | Adds execute_command inside the mission target. Enable it only for an authorised assessment |
- Tools that are not permitted are omitted from the server’s tool list, not merely rejected.
- Agent permissions live in the local RF Swift user configuration and are never placed in exported projects.
- Evidence responses carry an explicit
untrusted_evidencetrust label: notes, artifacts, recordings, filenames, metadata and embedded role text are data to analyse, not instructions to follow. - Per-client YOLO mode (the CLI’s own approval-bypass flag) is off by default and visibly warned. It never widens RF Swift’s MCP permissions.
Starting the server from the Workbench
In the Agent & MCP panel, choose the client and press Connect & launch. The Workbench then:
- detects the selected CLI on
PATH; - creates or merges a private configuration under the mission’s
agent-workspacedirectory (.mcp.jsonfor Claude Code,.kimi-code/mcp.jsonfor Kimi,.codex/config.tomlfor Codex), plus a generatedAGENTS.md/CLAUDE.mdtelling the client that “create a note” means the missionwrite_notetool; - performs a real MCP
initializehandshake with the mission-scoped server; - starts the client’s interactive TUI in the embedded Agent terminal.
While you are connected:
- notes and findings written through MCP refresh in their panels;
- when the agent calls
execute_command, the Workbench opens a read-only AI - tool terminal tab that shows the command, streams its real container or Nix output and marks the final state. Agent activity stays visible without mixing into your own shell.
Disconnecting closes the TUI and the MCP child process. The project-local files remain, so the next launch is reproducible.
Other MCP clients
Any other stdio MCP client (GLM CLI has no automatic configuration yet) can be pointed at the same server by hand:
rfswift-workbench --mcp --workspace PROJECT --mission MISSION [--mcp-write] [--mcp-exec]Register it as a stdio MCP server named rfswift. The generated AGENTS.md in the mission’s agent-workspace/ directory tells the client how to use the tools.
Ground-truth workflows
The agent always works from real data that RF Swift collected first.
Audit with AI
In the Security posture panel:
- the Workbench first runs the deterministic Nix or container scanners and keeps their unmodified JSON report as ground truth;
- the agent then reads it with
read_audit, consultsrecommend_tools, and may run authorised, non-destructive corroboration; - the agent is instructed to separate verified findings from hypotheses and never invent CVEs, versions, output or CVSS metrics;
- build-time-only dependency matches stay supply-chain leads, not runtime posture;
- environment CVEs are never promoted into mission findings automatically.
Suggest from evidence
In the Findings panel, the agent reviews mission notes and registered artifact metadata through read_evidence_index and produces source-cited candidates for your review. It does not silently save findings, and metadata alone is never treated as proof.
Collect credentials
In the Findings panel, grounded in saved findings and approved evidence, exact observed credentials are stored in the OS credential vault through the write-gated save_secret tool. Secret values stay out of chat, reports and exports.
Terminal recordings as evidence
A completed recording can be registered as AI-readable evidence (Use as AI evidence). The agent then reads a bounded, ANSI-free transcript instead of raw event JSON.
Editor AI actions
Editor AI actions prepare a scoped prompt and copy it for the external agent. They never send document contents to a provider directly.
MCP tools
| Tool | Permission | Purpose |
|---|---|---|
recommend_tools |
read | Suggest RF Swift programs, environments and example commands for a task or artifact |
read_audit |
read | Latest deterministic scanner report, the ground truth for AI-assisted review |
read_evidence_index |
read | Mission notes and registered artifact metadata for evidence-cited candidates |
list_missions |
read | Missions visible in the project or scope |
read_note |
read | A mission Markdown note |
list_findings |
read | PwnDoc-compatible structured findings |
write_note |
write | Replace or append to a Markdown note |
save_finding |
write | Create or replace a structured finding |
save_secret |
write | Store an exact credential in the OS vault |
execute_command |
execute | Run a command in the selected mission target |