An agent that changes its mind
A scanner sends its payloads and records what came back. It does not behave differently because of what it learned two requests ago.
The AI Agent reads the response and decides what to try next. That single difference is why business logic and access control testing are possible here and structurally impossible with pattern matching.
Exploits to confirm, never to damage · Scope verified before any test runs · Destructive actions off by default
Overview
The word "AI" is doing very little work on most security websites. Here is the specific thing it does here.
Conventional automated testing executes a predetermined sequence. It has a list of payloads, it sends them, it records which produced a suspicious response. The sequence is the same for your application as it was for the last one, because the tool has no model of your application, only of vulnerabilities in general.
That approach works for one category of flaw: the kind with a signature. An unpatched version, a known injection pattern, a missing header. Those are real and worth finding, and pattern matching finds them efficiently.
It cannot reach the other category. There is no payload that detects this user can approve their own refund, or this endpoint returns another tenant's records, or this workflow completes if you skip the third step. Those flaws are not patterns. They are violations of intent, and finding them requires understanding what the application is supposed to do before you can work out how to do something else.
The AI Agent is built for the second category. It maps the application, forms hypotheses about how it might be abused, tests them, and keeps only what it can demonstrate, adjusting as it learns. The first category is covered along the way, because it is the easier problem.
How It Works
The agent works through five documented phases. Each is informed by what the previous one established.
- Step 01
Phase 1: Reconnaissance
Before testing anything, the agent maps what exists: endpoint discovery, technology fingerprinting, authentication flow mapping, API schema analysis and asset discovery. The output identifies endpoints, technology stacks, authentication methods, API versions and subdomains.
This phase decides the quality of everything after it. You cannot form a useful hypothesis about an attack surface you have not understood, and most automated testing is weak here precisely because mapping is unglamorous.
See Asset Discovery - Step 02
Phase 2: Vulnerability discovery
Working from that map, the agent tests systematically using intelligent fuzzing and attack patterns across injection, authentication and session weaknesses, access control bypasses including IDOR and privilege escalation, and business logic flaws.
Findings at this stage are hypotheses. The agent has reason to believe something is wrong; it has not yet established that it is.
- Step 03
Phase 3: Exploit validation
This is where the agent departs from pattern-based tooling. Candidate findings are exploited to confirm them. Each confirmed finding carries the exact HTTP request, the response evidence proving exploitation worked, an impact assessment describing what an attacker gains, and a CVSS 3.1 severity rating.
What cannot be exploited safely is not dressed up as though it were.
- Step 04
Phase 4: Intelligent prioritisation
Validated findings are ranked by weighted factors: exploitability at 40 percent, impact at 30, asset value at 20 and exposure at 10.
The weights are published rather than implied, so a finding's position in the queue is arithmetic that can be followed, and argued with on specifics, instead of a number taken on trust. Ranking also happens after validation rather than before it, which is what keeps the top of the list short: only findings the agent actually proved are competing for it.
See Risk Prioritization - Step 05
Phase 5: Reporting
Findings are written up with executive summary, technical detail, remediation guidance including code examples, compliance mapping and trend analysis against previous scans.
See Smart Reporting
What "adaptive" means concretely
Three documented behaviours make the sequence above more than a checklist:
- Contextual payload generation.
- Payloads are shaped by what the agent observed: the framework in use, how a parameter is handled, what the last response revealed about the parser behind it. An input that rejected one encoding is a hint about what to try next rather than a closed door.
- Behavioural analysis.
- Not every vulnerability announces itself with an error. The agent looks for responses that are subtly wrong: a timing difference, an inconsistent status code across roles, an object returned that should not exist for this identity.
- Anomaly detection.
- Deviation from the application's own established behaviour, which is a more useful signal than deviation from a generic expectation, because it is calibrated to your application rather than to applications in general.
Capabilities
Five-phase methodology
Reconnaissance, vulnerability discovery, exploit validation, intelligent prioritisation, reporting.
Reconnaissance depth
Endpoint discovery, technology fingerprinting, authentication flow mapping, API schema analysis, subdomain and asset discovery, JavaScript bundle analysis.
Detection across three methods
Static analysis including pattern matching, code structure review and dependency scanning; dynamic analysis with intelligent fuzzing and behavioural analysis; AI-powered detection with contextual payload generation and anomaly detection.
Seven vulnerability classes, 245+ active tests
Injection (50+), configuration (45+), authentication (40+), access control (35+), business logic (30+), client-side (25+), cryptography (20+), with full OWASP Top 10 2021 category coverage.
Exploit validation
The exact HTTP request, the response proving exploitation, an impact assessment and a CVSS 3.1 rating on every confirmed finding, plus a reproducible curl command.
Multi-role reasoning
Identities held simultaneously and cross-tested, which is what makes horizontal and vertical access control failures observable.
Technical capabilities
Browser automation, HTTP proxy interception, dynamic payload analysis and native API testing support.
Depth by mode
Quick (15–30 min) surface-level; Standard (1–4 hrs) comprehensive with business logic and cryptographic analysis; Deep (4–24 hrs) exhaustive, adding race conditions, extended fuzzing across thousands of payloads, advanced injection techniques and complex multi-step attack chains.
Safety controls
Scope verified before execution, destructive actions off by default, configurable request rate, declared out-of-scope paths respected.
Benefits
- 01
Vulnerability classes that were previously out of reach.
Business logic, access control and workflow abuse are testable because the agent reasons about intent rather than matching signatures.
- 02
Testing shaped by your application.
Coverage follows what reconnaissance actually found, not a template written for applications in general.
- 03
Findings arrive already checked.
The expensive triage question (is this real) is answered before the finding reaches anyone.
- 04
Coverage that does not run out of hours.
No phase gets cut short because an engagement window closed, which is a common and rarely discussed reason human tests miss things.
- 05
Consistency across runs.
The same methodology every time, which is what makes comparing this quarter to last quarter a meaningful exercise.
- 06
Depth is a decision, not an assumption.
Knowing that Quick mode does not attempt business logic is what lets you schedule Standard and Deep runs deliberately.
- 07
Your specialists keep the interesting work.
Breadth-first testing moves off expensive hours; architectural reasoning and novel abuse cases stay with people.
- 08
Security testing that scales with change.
New features, APIs and workflows can be reassessed continuously, so coverage grows with the application instead of being reset every time the product evolves.
The endpoint nobody meant to ship.
Illustrative example. Not a customer account.
An engineering team builds a customer data export feature. It is not ready for release, so it goes out behind a feature flag: the button is hidden in the interface for everyone outside the pilot group.
The flag gates the interface. It does not gate the API.
POST /api/v2/exports is live in production and accepts an account_id in the request body. No front end calls it for most users, so no front-end test touches it. It is not in the QA plan, because from the product's point of view the feature has not launched.
- 01
Reconnaissance finds the endpoint in the API schema, not in the interface, which never exposes it.
- 02
Discovery notes that the endpoint accepts an object identifier and flags it as a candidate for broken object-level authorisation. At this point it is a hypothesis, not a finding.
- 03
Validation tests the hypothesis directly: authenticate as a low-privilege pilot user, request an export for an account that user has no relationship to, observe the response.
- 04
The export is returned.
- 05
The finding records the endpoint with method, path and parameter; the authenticated role used; the exact request; the response confirming unauthorised data access; a reproducible curl command; a CVSS 3.1 score and vector; the CWE class; and remediation guidance pointing at the missing authorisation check rather than at the feature flag.
Why this is the right example.
Nobody made a mistake that looks like a mistake. The feature flag worked exactly as designed. The gap was an assumption: that hiding a button hides the capability behind it. No signature database contains that, and no crawler would have reached the endpoint to try.
FAQ
Frequently Asked Questions
What does the agent actually do that a scanner does not?
It forms a hypothesis, tests it and lets the result shape the next request, which is what makes the flaws that have no signature — business logic, access control, workflow abuse — findable at all.
Does it actually exploit things, or just detect them?
It exploits, so a finding is confirmed only once the attack has been performed and the evidence captured as the exact HTTP request, the response proving it worked and a reproducible curl command.
Can it damage our systems?
Destructive actions are off by default, the request rate is configurable, scope is verified before execution and exploitation demonstrates access rather than causing damage.
Does the agent make mistakes?
Yes, but because every finding arrives with the request, the response and the reproduction, confirming or dismissing one takes minutes and anything dismissed is recorded as false_positive with a name and a date.
Does it replace human penetration testers?
For recurring, breadth-first work largely, but novel business logic, social engineering and physical assessment still belong to people, so the agent extends what a team can cover rather than removing its judgment.
How does it handle authentication?
Bearer tokens, basic auth, cookies with session and CSRF handling, custom header schemes, OAuth2/OIDC authorisation code flow and scripted login with JSON-path token extraction, with sessions re-established when they expire and multiple roles held simultaneously for cross-testing.
Can we see what it decided and why?
Each validated finding carries the reasoning path that produced it alongside the evidence, so the result can be reviewed rather than trusted.
How long does an assessment take?
Quick runs 15–30 minutes at surface level, Standard 1–4 hours adding business logic and cryptographic analysis, and Deep 4–24 hours adding race conditions, extended fuzzing and multi-step attack chains, on the same five-phase methodology throughout.
The platform capabilities behind this feature
Features that work with this one
Nothing here is a separate product. One assessment feeds all of them, which is why the output is a single ranked plan instead of nine disconnected tools.
The fix arrives with the finding
Every finding arrives with the fix: a summary, the vulnerable and secure code side by side, and references. Not a link to a generic advisory.
Sixty criticals is not a plan
Findings ranked by exploitability, impact, asset value and exposure, with the weights published, so the order can be defended.
You cannot test what you have not found
Subdomains, ports, services, endpoints, JavaScript bundles and API schemas, mapped from live behaviour rather than from an inventory that drifted.
Watch it work
Point the agent at a target and follow the assessment, reconnaissance through to a finding you can hand to an engineer.
Scope verified before any test runs · No credit card required