Approvals and destination scope

Understand automatic approval, pending requests and destination boundaries.

Automatic approval policy

--mcp-allow-targets controls which MCP scan creations start automatically:

Value	Behavior
Omitted/empty	Every creation waits for operator approval.
example.test,api.example.test	Those exact hosts are automatically approved; other hosts wait.
example.test:8443	Restrict automatic approval to that host and port.
*	Approve every target automatically; disables the gate.

Matching is case-insensitive for hostnames. A hostname entry without a port covers that host's ports; it does not automatically cover subdomains. Patterns such as *.example.test are not supported as subdomain wildcards.

The check uses the request's parsed service destination, not an unrelated Host header. This flag is an auto-approval list, not a network firewall or an instruction that other targets are permanently forbidden.

Pending lifecycle

A pending response contains an approval ID and the proposed scan IDs. Requests expire after 10 minutes. The queue holds at most 32 pending requests and 32 MiB of queued input. Pending approvals are not durable across server restart.

An operator can list, approve or reject using the REST approval routes. These routes exist only when MCP is enabled:

curl --fail --silent --show-error \
  -H "X-BURPBOUNTY-LICENSE: ${BURPBOUNTY_LICENSE_KEY}" \
  http://127.0.0.1:8081/mcp/approvals

curl --fail --silent --show-error -X POST \
  -H "X-BURPBOUNTY-LICENSE: ${BURPBOUNTY_LICENSE_KEY}" \
  http://127.0.0.1:8081/mcp/approvals/appr_REPLACE_WITH_ID/approve

Use /reject instead of /approve to reject. Approval/start errors preserve remaining pending work and expose the error for reconciliation. cancel_scan can remove pending work, and cancel_all_scans discards pending approvals as well as cancelling live work.

Credential model

Approval endpoints use the same license header as REST and MCP. There is no independent operator credential or role boundary. An agent should follow the workflow instruction not to approve its own request, but possession of the credential does not technically prevent a client from calling approval or ordinary REST scan routes.

Where separate operator/agent permissions are required, enforce them in deployment, for example by limiting which routes each authenticated proxy client can reach. Do not treat the MCP approval gate alone as a multi-tenant authorization system.

Destination confinement

For MCP-created work, the engine checks outbound origins, including redirects and profile-generated requests, against the explicitly supplied service origins in that creation batch. A profile's “Always” redirect setting does not override this guard. Paths on an allowed origin can still change according to the profile.

REST-created scans do not install this MCP origin guard and do not pass through the MCP approval queue. Control REST exposure accordingly. Application scope, explicit insertion selection and destination origins are separate concepts; configure each for the intended assessment.