An AI security agent can promise to stay in scope. Burp AT is more interesting because the product does not ask the model to enforce that promise by itself.
PortSwigger’s public beta places Burp AT agent permissions in the Burp tooling layer. Scope, available tools, approval rules, and the activity record remain separate from the model. The agent can propose an action, but the surrounding product decides whether that action is allowed, requires review, or is blocked.
That is the correct architectural direction for authorized web testing. It does not prove that Burp AT finds more vulnerabilities, avoids every unsafe action, or is ready for unattended production work. It does show how to build a boundary that does not disappear when a model interprets an instruction creatively.
What Burp AT puts outside the model
The official Burp AT page describes a beta available to Burp Suite Professional users. The agent can use Burp tools, project context, and purpose-built skills, while the tooling layer controls scope, tool access, and approvals. Requests and tool activity are recorded in the Burp project.
Which authorized hosts and paths the test can reach.
Which Burp capabilities are available to the agent.
Which actions proceed, pause for review, or remain blocked.
What the agent requested and what the product executed.
PortSwigger frames the product as human-led pentesting. That wording matters. A useful agent can prepare and execute bounded work without becoming the owner of authorization, risk acceptance, or client communication.
Why prompt-only scope is not a boundary
“Only test example.com” is useful context, but it is not enforcement. A model may follow a redirect, discover a related hostname, reuse a session in the wrong place, misunderstand a wildcard, or decide that a forbidden step is necessary to finish the task. A more persuasive prompt cannot turn probabilistic interpretation into a permission system.
The outer layer must resolve the requested action against an allowlist, the current project, available tools, and approval policy. If the action is outside policy, the tool call should fail even when the model insists it is reasonable. Our analysis of an AI containment incident shows why a model’s explanation cannot substitute for the control itself.
Approval modes work only if the log stays reviewable
Burp AT exposes proceed, review, and blocked behavior. That is a useful start, but approval design can still fail. If every ordinary request pauses, the reviewer becomes a click-through bottleneck. If broad categories proceed automatically, a risky request can hide inside an innocent label.
The approval screen should show the target, requested tool, material effect, relevant evidence, and why the action crossed the threshold. The log should connect the model’s proposal with the exact tool execution and result. Without that chain, a team can see that something happened without being able to reconstruct why.
This resembles the policy-server problem in Claude Inference Hooks: a control is only useful when its inputs, decision, failure mode, and fallback are observable.
A permission matrix before the first test
| Action class | Default | Why | Record |
|---|---|---|---|
| Read in-scope project data | Proceed | Low material effect inside an authorized project | Query and source objects |
| Send a new in-scope request | Review initially | Confirms target, method, and rate before automation | Request, approval, response |
| Change authentication state or data | Review | Can affect accounts or application state | Before/after evidence and approver |
| Reach an out-of-scope target | Block | Outside explicit authorization | Denied request and reason |
| Destructive or disruptive action | Block by default | High consequence and rarely necessary for routine validation | Exception owner if separately authorized |
Adapt the matrix to the signed rules of engagement. Begin with narrower permissions than the human tester has, observe the proposed actions, and expand only after reviewing false blocks and unsafe requests. Do not turn the first successful demo into a permanent policy.
What the public beta does not prove
Questions for an evaluation
- How often does the agent propose an out-of-scope or unnecessarily risky action?
- Can reviewers understand the reason for an approval request without reopening the entire session?
- Are tool arguments, redirects, derived hosts, and state-changing requests visible in the audit trail?
- What happens when the model, service, or approval interface fails midway through a run?
- Can a project be exported, replayed, and reviewed after the model or product version changes?
PortSwigger’s page establishes product design and availability, not comparative efficacy. Musthave.ai has not independently run the beta against a controlled benchmark. Treat vulnerability coverage, false positives, time savings, and safety performance as questions to measure.
Moderation products face the same separation problem. Our Reddit Rules Hub analysis recommends logging, queuing, and human escape hatches when an LLM interprets policy. Security testing raises the stakes because a mistaken interpretation can become network activity.
My verdict: the cage matters as much as the model
Burp AT agent permissions deserve attention because PortSwigger places enforceable scope and approvals in the tool layer. That is stronger than asking a model to remember the rules throughout a long security task.
The beta still needs disciplined evaluation. Start with authorized targets, narrow tools, review-heavy defaults, rate limits, complete logs, and a stop control. Measure what the agent proposes as carefully as what it finds. In security automation, a clever model is useful; a boundary it cannot negotiate away is essential.
Go deeper
- Read PortSwigger’s Burp AT product and public-beta page.
- Map the signed testing scope into explicit target, tool, approval, rate, and logging rules before connecting the agent.
- Review denied actions and approval fatigue alongside vulnerability findings during the pilot.
Which security-agent action would you never allow to proceed without a human?
Checked August 7, 2026. Burp AT is in public beta for Burp Suite Professional users. Product behavior and availability may change. Musthave.ai did not independently benchmark its vulnerability coverage or safety performance.
