Burp AT: Everything It Can Do, in One Hands-On Run

A hands-on look at PortSwigger's new agentic AI inside Burp Suite Professional — what it is, what it can actually do, and how it behaves when you set it loose on a live site.

What Burp AT is (in one paragraph)

On 23 July 2026, PortSwigger shipped Burp AT in Burp Suite Professional 2026.7.1, and opened it as a public beta a few days later. "AT" is agentic AI: instead of you clicking through Burp tool by tool, you hand an agent a goal in plain English, and it pursues that goal using Burp's own tools — the same battle-tested Scanner, scope engine, and request tooling you already trust — while you stay in control of scope, approvals, and conclusions. It doesn't invent its own hacking tools. It drives Burp's.

I gave it a deliberately vulnerable target (PortSwigger's own ginandjuice.shop) and one instruction: find SQL injection. What follows is exactly what happened.

1. Where Burp AT lives

Burp AT sits at the top of PortSwigger's product lineup now, above DAST, Professional, and Community Edition — "Agentic AI that extends human-led pentesting."

Burp AT is its own product tier, layered on top of Burp Suite Professional.

Inside Burp itself, you launch it from the Burp AT button in the top-right corner of the main window. If you're on Professional and updated to the latest release, it's already there.

One click, top-right — this is the door into the agent.

2. The interface: "What are we working on?"

Open it and you get a clean, chat-style workspace. A Tasks panel on the left, a prompt box on the bottom ("Ask anything"), and an autonomy selector — here set to Smart mode. Note the honest disclaimer PortSwigger bakes right into the screen: AI can make mistakes. Please double-check its findings.

3. Under the hood: Tools, Skills, and Usage

Before turning it loose, it's worth knowing what the agent is allowed to touch. Open Settings and you get three things that matter: Tools, Skills, and Usage.

Under Tools, you control exactly which capabilities the agent can use — and these settings apply across all autonomy modes. You can see it grouped into categories like Requests & Responses (compare HTTP messages, inspect a message, grep your captured traffic, send a single request) and Scan Checks (create, edit, or delete custom scan checks).

This is the boundary layer. If you don't want the agent doing something, switch it off here — it can't be prompted around it. The tool permissions live in Burp's layer, architecturally separate from the model. The agent can propose an action, but it can't execute anything you've disabled. Agents propose, Burp enforces, you decide.

4. What Burp AT can actually do — the full toolbox

Running a crawl-and-audit is the headline, but it's a fraction of what the agent can reach. Burp AT doesn't bolt on its own hacking tools — it's wired directly into Burp's, grouped so it can call just the slice it needs and so you can permission each group separately. The full set spans scanning and auditing (crawl a site, audit requests, pause or resume a scan), scope and site map (add to or remove from scope, inspect scope, add site map entries, import API definitions, list issues for a URL), and requests and responses (send and replay requests, inspect them, search captured traffic, and diff two messages).

It also reaches issues (raise, inspect, edit, delete scanner issues), custom scan checks (create, update, delete, and list checks — it can literally write a new check mid-test), datasets (retrieve, search, and summarize proxy history, site map, issues, and scan results), configuration (view, create, and edit named scan configurations), and scripting (run custom or packaged skill scripts, update a saved script, inspect a script's result).

The heavy hitters are fuzzing (fuzz a request with Burp Intruder and manage payload lists), Collaborator (generate Burp Collaborator payloads and poll or inspect interactions — which means the agent can catch blind and out-of-band bugs like blind SSRF, blind XSS, and asynchronous OS command injection, not just the reflected stuff), and utilities (encode, decode, or hash data, look up the Montoya API, and pass messages to another Burp tool). Put together, that's most of a human tester's kit — a long way past "add to scope and press scan."

Skills: PortSwigger Research, baked in

On top of the tools sit skills — focused techniques written by PortSwigger's Research team, each a bundle of a prompt plus code that tells the agent how to approach a specific problem reliably and repeatably. Burp AT invokes them automatically, deciding when a skill fits your goal with no manual selection. A single skill can chain multiple Burp tools (say, Repeater and Intruder) as one technique, and because they're published and updated server-side, you get new research techniques without updating Burp. When a skill runs, a banner appears under the response — expand it to see exactly which skills fired and what tools they called.

This is what separates it from a generic LLM bolted onto Burp: it applies PortSwigger's actual methodology instead of improvising one from general knowledge.

Autonomy: three modes, and a hard floor

The single most important control is the Mode dropdown — the "Smart" you saw in every screenshot. There are three levels. Manual uses the per-tool permission you've set, where in Tool settings you mark each tool Ask (always check first) or Act (go ahead). Smart, the default, approves routine actions itself and stops to ask about anything it judges risky — which is exactly why the crawl-and-audit in my run showed "Escalated by Smart mode." Autonomous runs without asking, except for a handful of high-impact tools that always need sign-off.

And that hard floor is the reassuring bit: a few high-impact actions always require approval no matter the mode — running a script, adding a target to scope, and creating a custom scan check among them. You literally cannot set those to run unattended. Combine that with the fact that a disabled tool is never used in any mode, and that Burp AT always checks scope before it acts, and the boundaries are enforced by Burp's tooling rather than trusted to the model's goodwill.

It costs credits

One practical note for budgeting: Burp AT runs on AI credits, deducted from your balance as it works. The Usage panel (Settings → Usage) is where you watch the burn. Broad autonomous runs across a big site cost more than a tight, targeted task — another reason precise prompts pay off.

5. What it replaces from your manual workflow

Here's the mental shift, and it's the whole point of this post. In classic Burp Suite Professional, you are the orchestrator. A normal test means going to Target → Scope and adding the target URL so the rest of the suite behaves, clicking New scan and choosing your scan type (Crawl and audit, Crawl, or Audit), tuning the scan configuration (which audit checks, how aggressive, what's in scope), and then watching the dashboard, reading the issues, and manually pivoting — sending the interesting request to Repeater, isolating the vulnerable parameter, crafting payloads. Every one of those decisions is yours to make, click by click.

Burp AT collapses that orchestration into a conversation. You state the goal, and the agent makes those same choices itself — it scopes the target, decides whether to run a full crawl-and-audit or a narrow targeted audit, picks which parameters to hammer, and reads the results back — all through Burp's real tooling, pausing for your approval on the steps that matter.

So it's not a new scanner. It's an agent driving the scanner (and the rest of Burp) the way an experienced tester would. That distinction is what makes it trustworthy: every request it fires still shows up in your Logger, every scan on your Dashboard, every confirmed bug in your Issues panel — reproducible, exactly as if you'd done it by hand. Now watch it happen.

6. The hunt: "find SQL injection in this target"

I created a task and typed one line: find sql injection in this target "https://ginandjuice.shop/". The agent immediately laid out its plan: "I'll start by scoping the target and searching for the tools I need to map the attack surface and test for SQL injection." No config screens. Just the goal, in English.

It asks before it acts

The first thing it wanted to do was add the target to scope — and it stopped and asked. This is the human-in-the-loop mechanism: consequential actions surface an approval prompt (Reject / Approve) instead of just running.

I approved, and here's the tell that this is real Burp underneath: the target appeared in the actual Target → Scope list, exactly where it would if I'd typed it in myself. The agent's action and Burp's own scope config are the same thing — no black box.

It chooses the scan type for you

This is the moment that maps directly to the manual "New scan" decision. The agent reasoned: "I'll take a two-pronged approach: launch a full crawl-and-audit to discover and test the entire site, and also directly probe a likely SQL injection entry point on the catalog page with a targeted audit." Notice the approval banner: "Escalated by Smart mode." In Smart mode, low-risk steps run automatically, but launching a full crawl-and-audit is significant enough that it gets bumped up for your sign-off.

The scan runs as a normal Burp task

Once approved, the crawl-and-audit spins up as a standard Burp scan task on the dashboard — "3. SQLi hunt — ginandjuice.shop", Crawl & audit, live issues populating in real time (reflected XSS, DOM-based XSS, client-side template injection, external service interaction). Meanwhile the agent monitors its own scan: "No SQL injection issues reported yet — the scan is still running. Let me check what's been discovered so far."

It narrows to the exact parameters

This is where it stops feeling like a scanner and starts feeling like a tester. Rather than just letting the broad scan grind, the agent reasoned about the app and pulled out specific candidates: "I've identified four strong SQL injection candidates: productId, postId, searchTerm, and search. Let me launch targeted SQLi-only audits against each." It then ran the broad crawl-and-audit and the targeted SQLi audits in parallel — and SQL injection surfaced in the issues list.

7. Taking it to a real target: a full end-to-end test

The ginandjuice.shop run was a controlled demo on PortSwigger's own vulnerable app. To see how Burp AT behaves against something real and unfamiliar, I pointed it at a live site and gave it a deliberately open-ended goal — "we are testing starbucks.co.uk end-to-end" — instead of naming a single vulnerability class. What it did next is the clearest demonstration of the agentic difference I've seen.

A note on authorization first. Only run automated, agentic testing against targets you own or are explicitly authorized to test — your own lab, a deliberately vulnerable app like ginandjuice.shop, or a live site strictly within the rules of its bug bounty / VDP program. Many programs restrict or outright forbid automated scanners, and an agent sends a lot of traffic fast, so always check scope and program rules before pointing one at a production site. Treat an "end-to-end" prompt with the same care you'd treat a scanner.

It scoped and fingerprinted itself

I gave it one sentence. It replied: "Starting an end-to-end test of starbucks.co.uk. I'll set up scope, then kick off reconnaissance and enumeration in parallel." Then it asked to add the domain to scope (I approved) and sent an initial request to fingerprint the site.

It pulled the stack, then sitemap.xml and robots.txt — unprompted

No instruction to do any of this. It parsed the response headers and HTML body for technology indicators, worked out the site runs on Next.js, and went after Next.js build data, API routes, and authentication endpoints while probing common discovery paths at the same time. Then it went and fetched the site's sitemap and robots.txt to map the attack surface properly, rather than guessing.

It built a categorized attack surface

The output wasn't a raw URL dump — it was a structured attack surface assembled from the sitemap and robots.txt, with the interesting bits flagged: authentication paths (/account/login/, /account/create/, /account/forgot-password/), ordering and payments (/order, /card/), rewards (/rewards/), the store locator (/store-locator/), and numeric product IDs (/menu/product/{id}/) flagged as a potential enumeration target. It also noted /api/ and /refer-a-friend as disallowed in robots.txt — and therefore worth exploring.

That robots.txt reasoning is the giveaway that this is more than pattern-matching: disallowed paths are often the interesting ones, and it called them out on its own.

It spawned sub-agents and split the work

This is the headline. Instead of grinding through everything in one thread, it announced it was "spinning up parallel sub-tasks to cover the major test areas concurrently while the background crawl-and-audit continues" — and after I approved Spawn subtask agent, it launched four specialized sub-agents, each owning a different area: Authentication Testing, API Discovery, Content Discovery, and Business Logic Testing.

All four ran in parallel on top of the background scan. The agent had taken a vague, one-line brief and decomposed it into a coordinated, multi-agent test plan by itself — deciding what the major test areas were, and delegating each to its own worker.

Why this run matters

On the controlled SQLi demo, Burp AT was impressive. On a real, unfamiliar target it's genuinely different from a scanner: it fingerprinted the stack, read robots.txt like a tester, prioritized an enumeration target, and parallelized the whole engagement across specialized sub-agents — all from one sentence. This is the closest I've seen an automated tool get to how a person actually approaches recon.

And the honest caveat matters more here, not less: everything it surfaces is a lead to verify, and on a real engagement you are accountable for every request it sends — which is exactly why the scope approval gate and the full Logger trail earn their keep.

8. Who's actually in control

It's easy to read "agentic AI" as "it goes off and does whatever." The screenshots tell a different story, and it's the reassuring one. Scope, tools, and approvals are enforced by Burp, not the model — disable a tool and the agent literally cannot use it. Autonomy is a dial: Smart mode auto-runs the safe stuff and escalates the risky stuff (adding scope, launching a full audit) for your explicit approval, so you choose how much leash it gets. And every action is auditable — the requests, scans, and issues all land in the Burp tools you already know, so you can reproduce any finding and stand behind it in a report, instead of trusting the model's account of what it did.

9. My honest take

The genuinely useful thing here isn't "AI finds bugs." Scanners have found bugs for years. It's that Burp AT compresses the slow, judgment-heavy orchestration — scoping, deciding scan strategy, isolating the right parameters, chasing a lead you'd normally run out of time for — into something you can delegate while keeping your hands on the wheel.

A few honest caveats are worth putting in front of your readers. It's Professional-only and in public beta — Community Edition doesn't get it. It runs on AI credits, so it has a real per-task cost; check the Usage panel. And the disclaimer is not decoration: AI can make mistakes, so double-check its findings and treat its output as a strong lead to verify, not a signed-off vulnerability.

And if you're earlier in your journey: this is a force multiplier for people who already know what good looks like, not a shortcut around learning. The tester who benefits most from Burp AT is the one who could have found that SQLi by hand — they're just letting the agent chase ten leads while they focus on the one that needs a human brain. Learn the manual craft first; delegate it second.