AI Swarm Pentest

A scoped, authorized engagement

AI Swarm Pentest is the Validate step of Proof-Driven AppSec. Before Plexicus helps you understand a weakness in code (Deep Code Analysis, module 5) or fix it (Remediation, module 7), it shows you which attack paths are real in a running application. In the product, AI Swarm Pentest appears as AI Pentest, under its own Pentest entry in the sidebar.

A pentest sends real traffic to a real system, so everything starts with authorization.

Rules of engagement

An AI Swarm Pentest covers an authorized application, API, source code or test environment. Before work starts, the target, test access and rules of engagement are agreed in writing, and Plexicus does not act outside that scope. In practice, your rules of engagement answer four questions:

What is in scope: the exact application URL or domain, and which environment (staging or production).
What test access you provide, if any: none, a dedicated test account, or test API keys or headers (lesson 4 explains why you should not assume they are used).
What is off limits: for example account deletion, sending email or SMS, or capturing payments.
Who decides what happens with the results.

When your team runs AI Pentest in the platform, you write and approve these rules internally. The wizard captures part of them: the target, the authentication settings, the out-of-scope items and the brief.

What it is, and what it is not

AI Swarm Pentest uses coordinated AI checks that map your application, form hypotheses, test attack paths and attach evidence to what they find. It automates repetitive exploration, correlation and reproduction. Your team keeps the context, the supervision and the final decision.

It is not:

a signature scanner that matches known patterns,
a security chatbot that suggests answers,
a check run without a signed scope,
a classic multi-day, on-site human pentest,
an endless list of unprioritized “potential issues”,
a tool that changes production automatically.

If nothing can be confirmed, the results are not padded with theoretical alerts. Plexicus does not promise zero vulnerabilities. It promises that anything presented as verified can be demonstrated.

The four guardrails

The four guardrails from module 1 (scope agreed in writing, traceable evidence, engagement limits and human decision) apply to every run. In practice, the wizard applies them like this:

The wizard passes a narrow scope to the agent: the target URL’s own host, with no extra domains, on ports 80 and 443 plus any port written in the URL. Destructive actions is preselected as out of scope in the last wizard step. Every out-of-scope item you select reaches the agent as a written instruction not to perform it. It is an instruction, not a technical block, so pair it with a staging target and test payment methods. Every depth, Quick included, sends real requests to the target.

How the swarm works

A signature scanner compares your application against known patterns and tells you where to look. A security chatbot answers questions from the context you give it. AI Swarm Pentest does neither. It explores paths, tests hypotheses and attaches evidence, so you can prioritize what deserves attention.

The work is split across coordinated AI checks. They map the surface, form hypotheses and test attack paths inside the agreed scope, and a second pass independently confirms each finding before it is marked verified. In the product, the Plexicus pentest agent runs against your target URL, guided by the brief you write in the wizard (lesson 4). Deeper scan modes allow longer runs and more agent effort. While a run is active, the War room (live board) on the run page shows the swarm’s activity.

From signal to verified finding

The engagement is designed so that one check is never enough to call something verified. A result moves through three stages:

Candidate finding. A hypothesis produces a signal with technical context.
Independent verification. A second pass tries to confirm the observed behavior on its own.
Verified finding. Only a confirmed result is presented as verified, with its impact and a priority based on real risk (severity plus context), not on order of arrival.

Under the evidence standard, a result that a second pass cannot reproduce is not presented as a verified finding. It is marked unverified or discarded. That is the rule from module 1: no reproducible proof, no verified finding.

In the product, the Unverified badge on the Pentest list refers to target ownership (lesson 3), not to findings. Do not read it as a verdict on any finding.

What this means when you read results

Two practical consequences follow from this design.

Few findings is a result, not a failure. A run that stops because it reached its time or AI budget is still marked Completed. A Completed run with few or no findings tells you what the swarm could and could not confirm in that window. It does not prove that the target was tested exhaustively. Give the next run more direction: a deeper scan, specific focus areas, a clearer brief.

Human review still applies. Pentest findings go through the same AI validation as other Plexicus findings, including the AI verdict and false-positive analysis covered in modules 4 and 5. If you disagree with a verdict, use Mark as false positive. It takes no written reason, so record your reasoning in your ticket or team notes. Nothing reaches production without a decision from your team.

If your organization has configured its own AI provider, the pentest agent uses that provider. Otherwise it uses a Plexicus-managed model. Customer code is not used to train AI models.

Proving you own the target

Before the agent sends a single request, Plexicus requires proof that you control the target. Launch AI Pentest stays disabled until ownership is verified, and the server rejects unproven targets even if someone bypasses the interface.

Why accepting terms is not proof

Accepting terms of service is a declaration, not evidence. Anyone can accept terms for a domain they do not control, so Plexicus does not treat it as authorization. Because the agent sends live traffic that can change the target’s state, Plexicus accepts only proofs that require you to change something on the target itself: a token in its HTML, in a file it serves, or in its DNS.

Two scopes, three methods

In the wizard’s Verify ownership step, you choose a scope:

Scope	Method	Covers	Best for
Verify this application	HTML meta tag or a file under /.well-known/	That exact host only	One app, fastest path
Verify the whole domain	DNS TXT record	The domain and every current and future subdomain	Teams testing many apps on one domain

The launch check accepts either proof. A verified domain covers the domain itself and all of its subdomains. A verified application covers that exact host.

Verify this application

The wizard shows a Verification token. Publish it in one of two ways. Either add this meta tag to the target page, copied exactly as shown, with name before content:

<meta name="plexicus-site-verification" content="YOUR-TOKEN">

Or serve a file at /.well-known/plexicus-verification.txt containing the token. Then click Recheck. Plexicus checks both automatically: first the file at the site’s origin, then the meta tag on the exact target URL. Keep three rules in mind:

The response must be HTTP 200.
Redirects are not followed, so a page that redirects to a login screen fails the check.
Each request times out after 10 seconds.

When the check passes, the status reads “Ownership verified · HTML meta tag or file”.

Verify the whole domain

Choose Verify the whole domain and the wizard shows a Host and a TXT record value, a token that starts with verif-. The wizard proposes the parent domain of your target: for app.example.com, that is example.com. Check the Host before you publish anything. You can’t edit it, and the wizard always proposes the last two labels of the host. If that is wrong (for example co.uk for shop.example.co.uk), use Verify this application instead. Otherwise, add the TXT record at your DNS provider, wait for it to propagate, then click Recheck. If the record is not visible yet, you see “Verification token not found yet — DNS changes can take time to propagate”.

When the badge and the launch disagree

The Verification column on the Pentest list only recognizes a domain verified for the exact target host. A target covered by app verification, or by a verified parent domain, can show Unverified. Its row may then offer Verify first instead of View Findings, Rescan or Run. The launch check is what actually decides. If that happens, open the findings from Findings App Pentest , and to test again, start a New AI Pentest for the same URL.

If a run is refused for ownership, the message reads “Target URL is not verified. Please verify this application or the whole domain under Settings → Domain Verification.” In the settings menu, that page is labeled Ownership Verification.

Running an assessment

An assessment is a saved pentest definition (name, target URL, authentication, optional repository, scan guidance) that you can run many times.

The wizard, step by step

Step	What you set
1. Target	Assessment name and Target URL. If you omit the scheme, `https://` is added.
2. Verify ownership	App or whole-domain proof (lesson 3), then Recheck.
3. Authentication	No authentication, Username / Password (Login URL, test username, test password) or API Keys / Headers.
4. Source repository	Optional: Select existing, Connect new, or skip for a black-box run.
5. Scan & launch	Scan depth, focus areas, out-of-scope items, known tech stack, Additional context, then a Summary.

Wizard notes:

Authentication. If you provide access, use a dedicated test account, never a real user’s. Stored passwords and header values are never returned by the API. To use different credentials, create a new assessment. Authenticated testing is not guaranteed: treat a run as unauthenticated unless the live browser view or the recording shows the agent signed in and reached the areas you expected.
Source repository. Linking a repository gives the agent your source code for a white-box run. Share source code with the engine (whitebox scan) is on by default. Turn it off for a black-box test with the repository still linked.
Depth. Quick (“Minutes · CI/CD & smoke checks”), Standard (“30 min–1 hr · routine review”, the default) or Deep (“1–4 hr · full audit, chained exploits”). The wizard’s durations are guides. Every run is time-boxed by depth, and a run with no result before its limit is marked Failed.
Guidance. Pick focus areas such as Access control (IDOR), review the out-of-scope list, and write Additional context like a brief to a human pentester: critical flows, issues to re-check, endpoints to avoid. All of it becomes the agent’s brief.

When you click Launch AI Pentest, Plexicus also checks that the AI Pentest connector is enabled, that any linked repository belongs to your organization, and that you have a session left this month. If all checks pass, you see “Scan started.” and land on the run page. If the connector is off, someone with permission to manage connectors can enable it under Pentest Configure .

If a check fails, the wizard shows an error and saves the assessment as a Draft. Fix the cause, then open the Draft from the Pentest list and click Run on its run page. Launching from the wizard again creates a second assessment.

Run statuses

Status	Meaning
Draft	Created, not launched. Only a Draft can be changed, and only through the API.
Pending	Launch accepted. The run is starting.
Running	The agent is testing. Cancel it from its run page.
Completed	The run finished and returned results.
Failed	The agent reported an error, or no result arrived before the run’s time limit.
Cancelled	Someone canceled the run.

Watching a run

The run page shows “Scan in progress” with an elapsed timer. After 90 minutes the banner changes to “Scan may be stuck” and offers Cancel.

The Live browser view streams the agent’s browser. The War room (live board) shows the swarm’s activity with a LIVE badge. On completed runs it shows Replay, and Expand switches to full screen. Only your organization can open these live views.

You also get screenshots and, when one exists, a Session recording of the agent’s browser. With the built-in roles, Admin and Cyberoper can launch and cancel runs. Developer is read-only (module 10).

Evidence and results

When a run completes, you have findings, a report, screenshots and, when one was produced, a session recording. Pentest findings normally carry a proof-of-concept artifact.

Findings on the run page

The Findings card lists each finding with a severity badge and a title. Click one to expand its description, the affected URL and the type of its proof-of-concept artifact:

Artifact	What it contains
cURL command	The HTTP request that demonstrated the issue, as a cURL command.
Shell script	The recorded reproduction steps as a script.
HAR capture	A recorded HTTP Archive of the session, shown as pretty-printed JSON.

View PoC opens the artifact in a viewer, and Download saves it under its original file name. Artifacts stay available after the run ends. If a completed run has no findings, the card shows “No findings”.

Findings across runs

Pentest findings are stored as regular Plexicus findings linked to their pentest. Open Findings App Pentest to work with them in the standard findings table, filters and detail panel, or click View Findings on a completed row of the Pentest list.

In the detail panel, a pentest finding shows Evidence & attack path instead of Code & taint trace. It contains the target URL, a chip that says whether a source repository was linked (“White-box run — source repository linked” or “Black-box run — no source repository”), the artifact type (CURL, HAR or SCRIPT) and Download artifact. The panel describes the artifact as a deterministic replay whose command and expected evidence are “shown as recorded; nothing is re-run from your browser.” The viewer displays up to 64 KB of an artifact. For anything larger, download it to see the full capture. If no artifact was stored, the panel says “No stored replay artifact for this finding.”

Report and recording

Download report appears in the run page header once the agent has stored its report, a Markdown (.md) file produced at the end of the run. Download video saves the session recording as a .webm file. For PDF or JSON exports of App Pentest findings, use Findings App Pentest Download (reporting is covered in module 8). Verified findings then move into your normal remediation workflow (module 7). Check with your Plexicus contact that AI fixes are available for pentest findings in your release. Your team always decides whether to merge.

Session allowances

AI Pentest usage is counted in monthly sessions, separate from your AI usage allowance. How many sessions you have depends on your plan. If your plan does not include AI Pentest, New AI Pentest shows an upgrade prompt instead of the wizard.

Each Run or Rescan uses one session.
When usage data is available, your profile menu shows a Pentest meter with the sessions used and this month’s limit (or Unlimited). When billing is shown for your plan, Settings Billing also has a Pentest Sessions card.
A session is returned automatically only if the run fails before the agent starts, for example when setup fails. Once the agent has started, canceling the run or a later failure still uses the session.
When no sessions are left, the launch is refused with the number used, the limit and the reset date.
Session counts reset on the 1st of each calendar month (UTC), not on your billing date.

Plan before you spend a session: verify ownership, review the out-of-scope list, write the brief, and pick the depth that matches the question you are asking.

Key takeaways

AI Swarm Pentest (AI Pentest in the product) is a scoped, authorized engagement bound by the four guardrails from module 1: scope agreed in writing, traceable evidence, engagement limits and a human decision. It makes no automatic production changes.
The swarm maps the surface, forms hypotheses and tests attack paths inside the agreed scope, and a second pass must confirm a result before it is presented as verified. No reproducible proof, no verified finding.
A launch requires proven ownership: a meta tag or /.well-known file for one host, or a DNS TXT record for a whole domain. Accepting terms is not proof, and the Pentest list’s Verification badge is only a hint.
The New AI Pentest wizard has five steps. Prefer staging, remember that out-of-scope items are instructions rather than technical blocks, and write the brief as you would for a human pentester.
Pentest findings normally carry a proof-of-concept artifact (cURL command, shell script or HAR capture), shown exactly as recorded. Nothing is re-run from your browser.
Each Run or Rescan uses one monthly session, which is returned only if the run fails before the agent starts. The 90-minute “Scan may be stuck” banner is not a reason on its own to cancel a Deep run.