I Spent $8 to Mass-Pentest My SaaS. A Human Would Have Cost $15,000.

Your tests pass. Your app is not secure.

I had a multi-tenant SaaS with role-based access control, data isolation between organisations, and serverless functions handling sensitive operations. I had a test suite. It all passed. I felt good about it.

Then I let Claude Code attack it.

Not "review the code." Not "suggest improvements." I gave it one instruction: try to break this application. I launched five parallel AI agents, each acting as an independent penetration tester with a specific attack mandate. They generated roughly 1,100 adversarial test cases in about three minutes.

Around 50 of them failed on the first run. Every failure was a real vulnerability or a real gap in my defences.

Then I connected Burp Suite through an MCP server and let the same AI fire live HTTP requests at the actual running database. It found that seven tables accepted DELETE requests from anonymous users.

The whole thing cost me about a million tokens. Roughly eight dollars.

A professional penetration test costs $10,000–$30,000 and takes weeks to schedule. This took one afternoon and found bugs the test suite couldn't.

Claude Code as a pentester, not a code reviewer

The difference matters. Code review asks: does this code look correct? Pentesting asks: can I break this application? The mindset is adversarial. The agent is not trying to understand your architecture. It is trying to destroy it.

I used Claude Code's subagent system to launch five specialised attackers in parallel. Each one got a different attack mandate, full context about the application's architecture, and zero prior exposure to the source code. They were attackers, not maintainers.

Each agent ran for about three minutes. They produced roughly 1,100 test cases total. I ran them. Around 50 failed. Those were not false positives.

The sanitiser was the security boundary. It was also the weakest point.

My existing test suite checked that sanitizeInput() stripped <script> tags. It never tested what happened with SVG payloads, unquoted event handlers, javascript: URIs, or Base64-encoded data URIs. The adversarial suite tested all 123 of them.

The agent also documented 16 security gaps: places where a defence layer was missing entirely. SSRF validation that accepted internal IPs. Session checks with no NaN guard. File upload validators that only checked the last extension. Every gap is now a tracked test.

My test suite had 15 XSS payloads. Claude Code generated 123, sourced from OWASP, PortSwigger research, and real CTF competitions. The difference between 15 and 123 was four critical vulnerabilities.

Not <script>alert(1)</script>

These are the kinds of payloads the agent generated. They are not textbook examples. They are real-world evasion techniques that bypass naive sanitisers.

The SQL injection suite contained 44 vectors: classic injection, auth bypass, UNION-based extraction, blind boolean injection, time-based injection, stacked queries, and PostgreSQL-specific privilege escalation. Every payload was a string literal in a test assertion: never rendered, never executed.

Then I pointed Burp Suite at the live database

Phase one tested the application code. Phase two tested the running infrastructure. Because here is the thing about unit tests: they never send a real HTTP request to a real database. They test your functions in isolation. They do not test what happens when someone sends a raw DELETE to your API.

Burp Suite has an MCP server. This means Claude Code can use it as a tool: craft HTTP requests, send them through Burp's request engine, read the response, and decide what to attack next.

How it works

MCP (Model Context Protocol) lets AI agents call external tools. Burp Suite exposes tools like send_http1_request and get_proxy_http_history. The agent sends an attack, reads the response, and chains the next attack based on what it learned.

That 204 is the moment you stop feeling good about your test suite.

What Burp Suite MCP found

The root cause every Supabase project should check

When you create a table in Supabase with RLS enabled, the anon role still has full DML grants: SELECT, INSERT, UPDATE, DELETE. RLS policies filter which rows are visible. But the verbs are still routed. Defence in depth means blocking the verb at the grant level, not just the policy level.

One SQL migration. REVOKE ALL from anon on every table. Re-grant only what public-facing features actually need. Done.

Run this against your own Supabase project right now:

If that returns rows, you have the same vulnerability.

RLS tells PostgreSQL which rows you can see. Grants tell PostgREST which verbs to route. Both layers have to say yes. Most Supabase projects are only checking one.

$8 versus $15,000

A professional penetration test costs $10,000–$30,000 depending on scope. It takes weeks to schedule, days to execute, and the report arrives as a PDF you read once and file somewhere. The findings are frozen in time.

This entire exercise, ~1,100 adversarial unit tests plus 40+ live HTTP attacks against running infrastructure, used about one million tokens. At current API pricing, that is roughly eight dollars.

I have now run this same approach across two different projects. Different architectures. Different tech stacks. Different attack surfaces.

This does not replace a formal pentest. You still need a human expert for threat modelling, social engineering, and the kind of creative lateral thinking that AI cannot replicate. But for the 90% of testing that is methodical, pattern-based, and exhaustive,this is a 1,000x improvement in cost-efficiency.

You need both

Phase one (Claude Code writing adversarial tests) finds application-layer bugs: broken sanitisers, missing validation, incomplete RBAC. These are bugs in your code.

Phase two (Burp Suite MCP attacking live infrastructure) finds configuration-layer bugs: overly permissive grants, exposed endpoints, verb routing that should not exist.

Neither finds the other's bugs. Unit tests do not send real HTTP requests to real databases. Proxy-based testing does not analyse source code for sanitisation gaps.

The setup takes five minutes

1. Install Burp Suite (Community Edition is free) and enable the MCP server extension.
2. Connect Claude Code to Burp's MCP server via your .mcp.json configuration.
3. Start your local dev environment: your app, your database, your API. Everything running on localhost.
4. Tell Claude Code to attack it. Give it the base URL, the anon API key, and say: "You are a penetration tester. Find vulnerabilities."

For the unit test phase, launch five subagents in parallel with different attack mandates. Give each one your application's architecture context and tell it to write adversarial tests. Compile the output, run it, fix the failures.

If you are not ready for a thousand tests, start with five:

1. Cross-tenant isolation: Authenticate as Org A. Request Org B's data by ID.
2. Privilege escalation: Authenticate as your lowest role. Call your most privileged endpoint.
3. XSS in the richest field: Put <svg onload=alert(1)> in a text area.
4. DELETE from anon: Send DELETE /rest/v1/your_table?id=gt.0 with no auth.
5. Schema exposure: Hit your REST API root with no auth.

If any of those five fails, you have found a real vulnerability. The ratchet only moves in one direction.

The best time to pentest your application was before you launched. The second best time is right now, and it costs eight dollars.

These models can read your entire codebase, understand your architecture, generate hundreds of attack vectors, fire them at your live infrastructure, adapt based on responses, and produce a detailed report, all in the time it takes to make a coffee.

The question is not whether AI pentesting works. I have the 10 fixed vulnerabilities across two projects to prove it does. The question is why are you not running this against your own product today?