Skip to main content
Corgea AI Pentest runs autonomous penetration tests against your running web applications. Where SAST reasons about source code, a pentest attacks the deployed application the way an adversary would: enumerating the attack surface, chaining weaknesses together, and proving each finding with a working exploit. Every run produces findings with a reproducible proof of concept and a shareable PDF report you can hand to a customer, an auditor, or your own engineering team.
Pentesting is in beta and is available as an add-on. If you do not see Pentests in the sidebar, contact your Corgea administrator or sales@corgea.com.

​
How a Pentest Works

Each run follows the same three stages.
1

Reconnaissance

Agents map the attack surface of your target — endpoints, authentication flows, parameters, and routes that are not linked from anywhere obvious.
2

Attack

Specialized agents work the target in parallel, each responsible for a domain. They attempt real exploitation rather than pattern matching, and they chain weaknesses across domains to reach higher-impact outcomes.
3

Report

Confirmed findings are written up with a description, business impact, attack chain, exploit script, and remediation guidance, then rolled into a downloadable report.
Every run uses these agents: A Deep run adds an extended red-team agent that explores beyond those domains and builds multi-step attack chains across them.
Corgea only reports findings its agents were able to validate against the running application. A finding in the report has been reproduced, not merely suspected.

​
Before You Start

Only run pentests against applications your organization owns or is explicitly authorized to test. A pentest sends real attack traffic and can create, modify, or delete data. Point runs at staging or a dedicated test environment unless you have accepted the risk of testing production.
Your target URL must be publicly reachable over http or https. Corgea rejects targets that:
  • Use a scheme other than http or https
  • Embed credentials directly in the URL, such as https://user:pass@example.com
  • Resolve to localhost, a private network range, or a cloud metadata address
If your application is not reachable from the internet, expose a test instance or reach out to discuss options.

​
Targets

A target is a reusable configuration: where to attack, which credentials to use, and any standing instructions. Each run executes against a target, so you configure it once and re-run whenever you ship.
The Pentesting page showing the Targets tab with a list of configured targets, each with its URL, last run time, and creator, plus remaining Standard and Deep quota in the top right
The header shows how much pentest quota you have left for each scan mode. The Pentest runs tab lists every run across all targets, which you can search and filter by status.

​
Create a Target

1

Open Pentests

Select Pentests from the sidebar, then click New target.
2

Name the target and enter its URL

Use a name your team will recognize, such as Acme Public API. The URL is the application root the agents should start from.
3

Add credentials, if you want authenticated testing

Credentials are free-form text shared with the agents — whatever a human tester would need in order to log in. A line such as demo@example.com / hunter2 is enough. Without credentials, agents test the application as an anonymous external attacker.
4

Add instructions, if you have any

Use Additional instructions for rules of engagement, scope exclusions, or endpoints you want the agents to concentrate on.
5

Pick a default scan mode

Balanced or Deep. You can override this per run.
The New target dialog with fields for target name, target URL, optional credentials, optional additional instructions, and a default scan mode selector
Credentials are encrypted at rest and are decrypted only while a run against that target is executing.

​
Editing and Archiving

Open a target’s actions menu to start a run, edit it, or archive it. Edits apply to future runs only. Every run captures the target configuration it started with, so historical runs and their findings always reflect the setup that produced them. Changing a URL or rotating credentials never rewrites what a past run reported. When editing a target, leaving the credentials field blank keeps the stored credentials unchanged. To remove them entirely, select Clear stored credentials. Archiving hides a target from the list while keeping all of its historical runs viewable.

​
Starting a Run

From a target’s actions menu, choose Start new run.
A faster assessment covering authentication and authorization, business logic, and injection. Use this for routine testing on a regular cadence.
Instruction override replaces the target’s standing instructions for that single run. Leave it blank to use whatever the target already has. This is useful when you want one run to concentrate on a newly shipped feature without permanently narrowing the target. Balanced and Deep runs draw on separate quotas. The scan mode dropdown shows how many of each you have left, and a mode with no remaining quota cannot be selected. To extend your quota, contact sales@corgea.com.

​
Watching a Run

Runs take a few hours depending on scan mode and the size of the application. You do not need to keep the page open — findings are saved as they are confirmed, and admins can be emailed when the run finishes. While a run is active, the run page updates on its own. Findings appear as agents validate them, so you can begin triaging critical issues before the run completes. Click Logs to watch the agents work.
The Corgea Pentest Agents view showing a tree of agents working in parallel, with running totals for tool calls and findings, and a side panel describing the selected agent's current task and latest activity
The tree shows each agent, what it is working on, and how many findings it has confirmed. Selecting an agent opens its current task and latest activity. Agents spawn child agents as they go: when one finds something worth pursuing, it delegates a focused follow-up rather than abandoning its own line of attack.

​
Reviewing Findings

When a run finishes, the run page summarizes what was found.
A completed pentest run showing 76 total findings broken down into Auth and AuthZ, Business Logic, and Injection category cards with severity counts, above a findings list grouped by CWE
The cards across the top break findings into categories by CWE. Click one to filter the list below it.
  • All findings — everything the run confirmed, with counts by severity
  • Auth & AuthZ — broken access control, authentication, and session issues
  • Business Logic — workflow and transaction integrity issues
  • Injection — injection, traversal, and untrusted input issues
  • Validated SAST — coming soon; will cross-reference confirmed SAST findings against runtime exploitability
Findings whose CWE does not map to one of these categories still appear under All findings.

​
Filtering and Grouping

The toolbar above the findings list gives you:
  • Status pills — Open, Fixed, Closed, and False Positive, each with a live count. More adds Accepted Risk, Duplicate, and All statuses.
  • Search — matches on title, CWE, and endpoint
  • Severity — filter to Critical, High, Medium, Low, or Info
  • CWE / Endpoint toggle — group findings by weakness type, or by the endpoint they affect
Grouping by CWE answers “what classes of bug does this application have.” Grouping by endpoint answers “which part of the application is worst,” which is usually the more useful view when assigning remediation work.

​
Finding Details

Open any finding to see the full write-up across five tabs.

​
Finding Details

The description, business impact, affected roles and users, and technical root-cause analysis. The sidebar carries the CWE identifier, severity, CVSS score, target, endpoint, and how many times the finding has been re-detected across runs.
The Finding Details tab for a critical account takeover finding, showing description, impact, and impacted roles, with a sidebar listing CWE-639, critical severity, a CVSS score of 9.4, and the affected target and endpoint

​
Attack Chain

The exact sequence the agent used, as numbered steps. Each step names the request it sent and what the application returned, so an engineer can follow the path without guessing.
The Attack Chain tab showing four sequential steps that reproduce an account takeover, from registering a victim account through verifying full takeover

​
Exploit Script

A runnable script that reproduces the finding. Run it against your target to confirm the issue yourself, and again after fixing to confirm the fix holds.
The Exploit Script tab showing a Python script that reproduces the finding against the target application
Exploit scripts perform real attacks. Run them only against systems you are authorized to test, and expect them to create or modify data.

​
Remediation

Concrete remediation steps for this specific finding, plus references to relevant standards and guidance.
The Remediation tab showing four sequential remediation steps and a references section linking to OWASP guidance

​
History

A timeline for the finding that spans every run: when it was first detected, when it was re-detected, and every status change and comment, with who made each one. Corgea recognizes the same underlying issue across runs. If a finding reappears in a later pentest, it is linked to the original rather than filed as something new, so the history reflects one continuous story.

​
Triaging Findings

Use Current Status on a finding to record a decision. You can set: A status change applies to every detection of that same issue, so triaging once updates the whole history rather than just the row you opened. You can also add comments to record context for teammates.
Closed appears as a status but cannot be set by hand. Corgea applies it automatically when a revalidation run can no longer reproduce a finding.

​
Exporting a Report

Once a run completes, Export report offers two PDFs.

Technical report

The complete assessment, including technical analysis, proof of concept, exploit code, and remediation guidance for every finding. For your engineering team.

Executive report

The same assessment and findings without the technical deep-dive, proof of concept, or remediation detail. For customers, auditors, and leadership.
Both reports contain:
  • A confidentiality statement and table of contents
  • An executive summary and findings dashboard
  • Scope and methodology, including which agents ran and what each covered, plus an explicit out-of-scope statement
  • Severity definitions and recommended action per tier
  • A summary table of all findings
  • Detailed findings grouped by severity
Reports can support the penetration-testing evidence used in SOC 2 and ISO 27001 audits, and are designed to be shared as-is with customers and auditors. Whether a report meets a specific requirement depends on your audit scope, your selected controls, and your auditor.

​
Revalidating After Fixes

Once you have shipped fixes, re-test them without spending a full pentest on the whole application. On a completed run, open the New run menu and choose Revalidate Findings. A revalidation run re-tests only the findings from the source run and reports:
  • Still open — findings it reproduced again
  • Closed by this run — findings it could no longer reproduce, which are automatically set to Closed
1

Fix the findings

Work through the remediation steps, marking findings Fixed as you go.
2

Revalidate

From the completed run, choose New run then Revalidate Findings.
3

Confirm

Findings that can no longer be reproduced move to Closed. Anything still reproducible stays open with fresh evidence.
Revalidation requires a completed run with at least one Open or Fixed finding. A revalidation run cannot itself be revalidated — run another revalidation from the original run instead.
Revalidation is the fastest way to prove remediation to an auditor or a customer: it shows the same test that found the issue can no longer reproduce it.

​
Notifications

Company admins can receive an AI Pentest Completed email when a run finishes, with the target, scan mode, total findings, and a severity breakdown. This is a per-admin email preference, so admins who would rather not receive it can turn it off without affecting anyone else. Corgea also fires a webhook on completion, which you can use to post results into Slack, open tickets, or gate a release pipeline. See Webhooks for setup and payload details. Revalidation runs do not send completion notifications.

​
Frequently Asked Questions

A few hours, depending on scan mode and the size and complexity of your application. Deep runs take longer than Balanced. You do not need to watch the run — findings save as they are confirmed, and admins can be emailed when it finishes.
Yes. Add credentials to the target and the agents will test authenticated areas as a logged-in user. Runs also include unauthenticated testing, so you get both the external-attacker and logged-in-user perspectives.
Agents perform real attacks, which can create, modify, or delete data. Denial-of-service and volumetric load testing are explicitly out of scope, but you should still prefer staging or a dedicated test environment for routine runs.
Targets must use http or https, must not embed credentials in the URL, and must not resolve to localhost, a private network range, or a cloud metadata address. Expose a reachable test instance instead.
That mode is out of quota. Balanced and Deep are tracked separately, and remaining counts appear in the page header and the scan mode dropdown. Contact sales@corgea.com to extend.
The run’s status will say why. The most common causes are a target that became unreachable mid-run and credentials that stopped working. Confirm the target is up and the credentials are current, then start a new run.
Not necessarily. It means the agents could not validate any exploitable issues within scope. If you expected findings, check that credentials are correct so authenticated areas were reachable, and consider a Deep run for broader coverage.
SAST reasons about source code and finds issues before you deploy. A pentest attacks the running application and proves what is actually exploitable in your deployed configuration. They catch different things, and the findings from each are tracked separately in Corgea.

BLAST

AI-native SAST for finding vulnerabilities in source code before deployment.

Webhooks

Receive pentest completion events in your own systems.

Reporting

Track security posture across your organization over time.

Policies

Define how issues are prioritized and handled.