> For the complete documentation index, see [llms.txt](https://docs.bountysecurity.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bountysecurity.ai/burp-bounty-server/approvals-and-scope.md).

# 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:

```bash
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.