Let “Claude Code” Do Your Pentesting!

I want to walk through something concrete instead of just talking in the abstract about "AI-assisted security testing," because I think that phrase has gotten kind of meaningless at this point. Everyone says it. Almost nobody shows you the actual mechanics of what it looks like when it works. So here's a real example: taking a manual test case you'd normally run by hand in Burp Suite, and handing the exact same methodology to Claude Code, then comparing notes on what changed.

The short version of where this lands: it's not magic, it's not going to replace your judgment, but wired up correctly it turns a repeatable manual test into something you can execute in a fraction of the time — with a bonus you don't get from Burp alone, which is that it can point you straight to the line of code responsible for the result.

Let's get into it.

The setup: a simple IDOR test case

Say you're testing a snippet-sharing app — think a stripped-down Pastebin clone. The core access-control rule is dead simple: users can create, edit, and delete their own snippets, but not anyone else's. That rule is the whole ballgame from a security standpoint. Everything else is UI polish.

The UI enforces this by just not showing an edit button on other people's snippets. Cute, but meaningless from a security perspective — the browser isn't the security boundary, the backend is. So the actual test is: what happens if you skip the UI entirely and send the request by hand?

This is a textbook IDOR (Insecure Direct Object Reference) check. You craft a PUT /snippets/:id request using an ID that belongs to someone else, and see whether the server actually checks ownership before honoring it, or just trusts whatever ID shows up in the URL.

Doing it manually first

Before you ever hand this off to an AI assistant, you run it yourself, because you need a validated baseline to compare against. With Burp's browser sitting in front of the app:

1. Log in, create a snippet, then edit it. That edit action fires a PUT /snippets/:id request — grab it from Burp's HTTP history and send it to Repeater.
2. Pull a snippet ID that belongs to a different user (your GET /snippets response will usually flag ownership somewhere, like an is_owner field).
3. In Repeater, swap the snippet ID in your PUT request for the other user's ID, and fire it.

If access control is implemented correctly, you get a 403 Forbidden. Try the same swap on the DELETE endpoint and you'd expect similar treatment — a 401 or 403, not a successful deletion of someone else's data.

While you're already in Repeater, it costs nothing to run two more quick checks on the same mutating endpoint:

• Auth check — swap the session cookie for garbage. You should get bounced, not let through.
• CSRF check — tamper with the CSRF token header on the same request. Same expectation: rejected.

One thing that's easy to miss if you're only looking for pass/fail: read the actual error bodies. A lot of apps leak framework names, internal file paths, or library versions in verbose error responses. That's not a broken-access-control finding, but it's a real information-disclosure issue — free recon for an attacker, and an easy thing to flag in a report even when the "real" vulnerabilities come back clean.

Now hand the same methodology to Claude Code

Here's where it gets interesting. The goal isn't "let the AI go find bugs." It's "can the AI execute the exact methodology I already validated by hand, faster, and with less clicking around."

To make that possible you need two things wired into Claude Code:

A Burp MCP server, which gives Claude Code the ability to read Burp's HTTP history and send crafted requests through Burp's tooling — basically API access to the parts of Burp you were just doing by hand.

A Playwright MCP server, which gives Claude Code an actual browser it can drive — log in, click around, submit forms — the same way you did manually. The detail that matters here: point that browser's traffic through Burp's proxy port, so every action it takes shows up in Burp's history exactly like manual testing would. Skip that step and you lose the whole point of the exercise, because now Claude's browsing and Burp's history are two disconnected worlds.

There's also a smaller setup detail worth calling out: open the Claude Code session from inside the application's source directory, not just pointed at the running app. That one choice is what turns this from a black-box exercise into a white-box one — Claude can correlate an HTTP response with the actual line of code that produced it, instead of just reporting a status code back to you.

The part that actually matters: how you prompt it

This is the bit people get wrong when they try this and walk away unimpressed. If you prompt something vague like "test my app for IDOR," you're basically asking an intern with no context to freelance a pentest methodology on the fly, and you'll get inconsistent, shallow results.

Instead, you hand it the same steps you just validated manually, spelled out as a checklist: log in using the test credentials, create a snippet, edit it, pull the resulting request from Burp's history, find a snippet ID belonging to someone else, build a Repeater tab with the swapped ID, send it, and report back whether the response indicates a vulnerability.

That's the actual unlock. You're not asking the model to invent a security methodology from scratch and hope it's thorough. You're asking it to execute a methodology you already trust, which is a much narrower and much more reliable task for it to do well.

What comes back

When it's wired up right, Claude Code drives the browser through login and snippet creation, pulls the relevant request from Burp's history, identifies a different user's snippet ID from the API response, builds a Repeater tab with the swap (so you can replay it yourself later — nothing is hidden from you), and also fires it directly. Same result as your manual test: 403 Forbidden.

The part that's genuinely more useful than the manual version is the summary that comes back with it — not just "here's the status code," but a trace back into the source, naming the specific file and line where the owner-ID comparison actually happens before an update or delete is allowed. In a real engagement, that closes the gap between "I found something" and "here's exactly what's responsible for it" — whether that's confirming a fix works, or handing a developer the precise location of a bug instead of a stack trace they have to go hunt down themselves.

Turning it into something reusable

Running a good prompt once is a nice demo. Running it the same way every time, on every endpoint, on every engagement, without retyping the whole methodology from memory, is what makes it actually useful. Claude Code supports skills — saved, reusable prompt templates you can invoke by name — so once you've validated a test case, you can ask it to package that session's steps into a skill on the spot.

From then on, testing the same class of bug on a different endpoint, or a completely different app, is a matter of invoking the skill with the new context instead of reconstructing the whole methodology from scratch. That's the difference between "cool AI demo" and "something I actually put in my toolkit."

Where this is genuinely useful — and where it isn't

To be fair about it, this approach shines when:

• You've got a validated methodology you want to run consistently across a lot of endpoints or a lot of apps
• You want findings tied back to source, not just an HTTP status code sitting in isolation
• You're doing regression checks — confirming a control that passed before still holds after a code change

It's a weaker fit when:

• You're doing exploratory testing, where the value comes from a human noticing something odd and pulling on the thread — that instinct isn't something you can specify as a checklist ahead of time
• You're chasing a multi-step attack chain where each move depends on reasoning about what the last response actually meant
• You don't have a methodology yet. You can't hand off a workflow you haven't figured out yourself

Manual testing and AI-assisted execution aren't really competing with each other here — they're doing different jobs. You develop and validate the methodology by hand. The AI is what you use to run it at scale once you trust it.

If you want to actually build this skill set properly

Setting up Burp MCP and Playwright MCP correctly, writing prompts that read like a real methodology instead of a vague wish, and knowing which findings are worth trusting versus double-checking — none of that is intuitive on day one. It's a skill like any other pentesting skill, and right now there's basically no formal material on it, which is exactly the gap AI for Hackers: Red Team Edition is trying to fill.

It's a 312-page, 70-chapter guide from Codelivly that walks through applying AI across the whole offensive security lifecycle — recon, web and API testing, cloud and DevSecOps review, secure code review, detection engineering, automation, and reporting — with 170+ prompt templates and 14 hands-on labs you actually work through instead of just reading about. It leans hard on the same principle this whole post is built on: AI is there to execute and scale a methodology a skilled operator already trusts, not to replace the judgment that built that methodology in the first place. No exploit dumps, no shortcuts around authorization — just the workflows and verification habits that make this stuff hold up in a real report.

If you've been messing around with Claude Code or similar tools during engagements and want something more structured than "type a prompt and hope," it's worth a look:

👉 Grab AI for Hackers: Red Team Edition here

Bottom line

The pattern that makes this work isn't unique to AI tooling — it's the same pattern that makes any tooling effective in security work. Know what you're testing. Define a methodology you actually trust. Then use the tool to execute it faster, not to think for you.

Claude Code with Burp and Playwright wired in is a genuinely solid way to scale a validated test case. It's not a replacement for the part of the job where you figure out what's worth testing in the first place. That part's still on you.