Skip to content

Use Bravos from an agent

bravos mcp serves thirteen tools over stdio: the threat model, the findings ledger, the advisories and the run history of every repository scanned on this machine, plus the code graph when the optional analyzer is installed. Twelve of them are read-only, and none of them sends traffic at a target.

Register it when an agent working in your codebase should know which threats are already proven, which were ruled out, and which were never tested. None of that is derivable from the source.

  • bravos on your PATH, and at least one run on this machine to read.
  • An MCP client. The example below is Claude Code.
.mcp.json
{
"mcpServers": {
"bravos": {
"command": "bravos",
"args": ["mcp"]
}
}
}

Claude Code picks that up from the project root and asks before using it:

Terminal window
claude mcp list
bravos: bravos mcp - ⏸ Pending approval (run `claude` to approve)

Truncated to the Bravos line; the command lists every server the client knows.

Interrogated over the protocol, the server registers thirteen tools:

Tool Arguments Returns
list_repositories every repository Bravos has scanned, newest activity first
get_repository key one repository’s latest scan: the full guardlink table plus its advisories
get_advisory run_id, key one finding’s write-up, its probe template, and the evidence
list_runs runs on this machine that can still be resumed
get_run run_id one run’s manifest, ledger stats, confirmed and outstanding findings
get_events run_id, since, limit progress events after a cursor
get_report run_id, name one of a run’s markdown reports
get_artifact run_id, kind a model-tier artifact: threat-model report, dashboard, or SARIF
generate_model repo runs something: builds the threat model and dashboard. No traffic
request_verification run_id, key the commands to get findings verified. Starts nothing
codegraph_tools repo what the code graph can answer about a repository, in the graph’s own words
codegraph_query repo, tool, arguments asks the code graph one question
list_environments known environments, and whether their sessions are live

Every tool but generate_model declares readOnlyHint: true, and every tool declares openWorldHint: false: the server reads this machine’s own run directory and reaches nothing else.

request_verification is the tool an agent reaches for when it wants a finding proven, and it deliberately does not run anything. It returns the flow, filled in for that run: the exposures in scope and the exact commands.

That flow is three steps, and the middle one is a person:

  1. bravos intake "<brief>" turns a plain-language description into a reviewable plan and prints a plan id. An agent can compose the brief.
  2. bravos intake --approve <PLAN_ID>. The operator approves. Approving is the authorization, and it is not a decision an agent may make on someone’s behalf.
  3. bravos auto --plan <PLAN_ID> runs the whole loop.

The server says so to the agent that connects, in its own instructions:

Testing exploitability: this server never fires traffic, and you must not assemble your own scan out
of guardlink and cxg. The test loop runs from the bravos CLI — the one action surface every agent
host shares — through a plan the operator approves.

Truncated: the instructions continue with the three steps above and what request_verification hands back.