> ## Documentation Index
> Fetch the complete documentation index at: https://docs.corgea.app/llms.txt
> Use this file to discover all available pages before exploring further.
# Pentesting
> Run AI-driven penetration tests against your web applications and get an auditor-ready report
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](mailto:sales@corgea.com).
## How a Pentest Works
Each run follows the same three stages.
Agents map the attack surface of your target — endpoints, authentication flows, parameters, and routes that are not linked from anywhere obvious.
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.
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:
| Agent | Focus areas |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------- |
| Authentication / Authorization | Session management, privilege boundaries, IDOR and BOLA, MFA, JWT, OAuth and OIDC misconfigurations |
| Business Logic | Workflow bypass, price and quantity manipulation, race conditions, account-flow abuse, transaction integrity |
| Injection | SQL and NoSQL injection, command and template injection, XSS, SSRF, XXE, deserialization, path traversal, mass assignment |
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 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
Select **Pentests** from the sidebar, then click **New target**.
Use a name your team will recognize, such as `Acme Public API`. The URL is the application root the agents should start from.
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.
Use **Additional instructions** for rules of engagement, scope exclusions, or endpoints you want the agents to concentrate on.
**Balanced** or **Deep**. You can override this per run.
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.
A more thorough assessment that adds a red-team agent for extended exploration and multi-step attack chaining. Use this before a release, an audit, or a customer security review.
**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](mailto: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 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.
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.
### 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.
### 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.
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.
### 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:
| Status | Meaning |
| -------------- | ------------------------------------------------------------ |
| Open | Unresolved and awaiting work |
| Fixed | You believe it is resolved — confirm with a revalidation run |
| Accepted Risk | Acknowledged and accepted, optionally with an expiry date |
| False Positive | Not a real issue |
| Duplicate | Already tracked by another finding |
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.
The complete assessment, including technical analysis, proof of concept, exploit code, and remediation guidance for every finding. For your engineering team.
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
Work through the remediation steps, marking findings **Fixed** as you go.
From the completed run, choose **New run** then **Revalidate Findings**.
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](/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](mailto: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.
## Related
AI-native SAST for finding vulnerabilities in source code before deployment.
Receive pentest completion events in your own systems.
Track security posture across your organization over time.
Define how issues are prioritized and handled.
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
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.
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.
### 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.
### 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.
### 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:
| Status | Meaning |
| -------------- | ------------------------------------------------------------ |
| Open | Unresolved and awaiting work |
| Fixed | You believe it is resolved — confirm with a revalidation run |
| Accepted Risk | Acknowledged and accepted, optionally with an expiry date |
| False Positive | Not a real issue |
| Duplicate | Already tracked by another finding |
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.