How AI is used in testing.

Two things, used two different ways.

An AI assistant I configured and operate helps me run engagements: reasoning over scan output, drafting findings for my review, keeping methodology on track, and handling the admin load around a test so I can spend more time on the parts that actually need a human. It operates under my direct, continuous supervision. It doesn't decide what's a finding, doesn't set risk ratings, and doesn't touch a report without me reviewing it first.

Burp Suite's AI-Enabled Testing (Burp AT) is a vendor feature from PortSwigger, the company behind the industry-standard tooling I test with. It can autonomously investigate vulnerabilities the way a human tester would - following up on leads, attempting exploits, summarising findings for review. I run it capped at "Smart" autonomy on client work, meaning it asks for my approval before anything higher-impact happens; full autonomy is reserved for my own lab environment, never live client systems.

Who's actually behind the tooling.

My own AI assistant runs on Anthropic's models. Burp AT runs on a mix of models selected by PortSwigger for the task at hand, currently including Anthropic and OpenAI - per PortSwigger's published terms, their contracts prohibit these providers from training on or retaining engagement data. I may also evaluate other providers, including Mistral, as my own tooling develops; this page is kept current as that changes.

What gets redacted before anything leaves this machine.

As standard, before any testing data reaches an AI provider, client names, target hostnames and domains, session tokens, password hashes, and eMail addresses are automatically stripped and replaced with neutral placeholders. This runs as a fixed step in my own tooling, not a manual one. Raw, unprocessed evidence files and completed engagement archives are also kept off any filesystem path the AI assistant can reach - the automated redaction pipeline is the only route that class of data takes to reach it.

The one deliberate exception is Burp AT: because it works by actively following up on findings against the live target, it needs to see real request and response data to function at all - PortSwigger are explicit that it does not redact this data itself. I control this through scope and approval settings, not through hoping it behaves; anything above "Smart" autonomy requires my direct sign-off before it acts.

A human reviews everything, always.

No AI tool used in this work decides what counts as a finding, sets a severity or risk rating, or writes a sentence of a client report unsupervised. I review every piece of AI-assisted output before it influences a result. If every AI tool I use became unavailable tomorrow, every engagement would still be fully testable by hand - the tooling is there to help me move faster and dig deeper, not to replace the testing itself.

Built against CREST's own principles.

This approach is designed around CREST's published 9 Principles for AI in Cybersecurity - the industry body behind my own CPSA accreditation. In short: be accountable for how AI is used, be transparent with clients about it (which is the point of this page), keep it documented and auditable, keep a human in control of its boundaries, handle client data properly, and don't let it become a single point of failure. Questions about any of this are always welcome - get in touch below.