> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloudthinker.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Deep Dive Pentest

> Run Cyber's most thorough pentest mode to find role, tenant, and multi-step flaws, with an optional credit limit for the run.

**Deep dive** is the highest of the four testing intensities in a [pentest](https://docs.cloudthinker.io/guide/security/pentest.md), the mode that finds flaws a single pass misses: one user reaching another tenant's data, a checkout step that can be skipped, or two small weaknesses that chain into a takeover. It keeps investigating after the first findings, across several passes in one run, and uses the most time and credits.

## Choose the right intensity

You pick the intensity each time you run a pentest, and Deep dive is the top one. It does everything **Full** does, then keeps going over several passes that reuse earlier evidence to follow connected attack paths. It costs the most time and credits, so point it at staging with disposable data only. The other three levels are compared in the [intensity table](https://docs.cloudthinker.io/guide/security/pentest.md#choose-access-and-intensity).

Pick Deep dive when:

* Your app has several user roles or tenants and you need to know if one can reach another's data.
* A workflow spans several steps (checkout, approvals, invites) where order and state matter.
* A Full run found something that hints at a bigger attack path.
* A release changed authentication, permissions, or billing logic.

For a first look at a new app, start with a **Safe** run limited to include paths, then **Aggressive**. Move to Deep dive once scope and test logins are confirmed.

> [!WARNING]
>
> Deep dive sends destructive requests, including `DELETE`, to your target. Data inside the saved scope can be changed or removed. Run it against a staging or test environment with disposable data, or narrow the scope first.

## Prerequisites

* An app registered in Cyber with a verified domain. See [Run a pentest](https://docs.cloudthinker.io/guide/security/pentest.md).
* The workspace **Admin** or **Developer** role. Either role can launch any intensity, including Deep dive. There's no separate Admin-only setting or Approvals step for destructive runs: the confirm dialog is the only extra gate. See [Roles](https://docs.cloudthinker.io/guide/security/roles.md).
* Enough credits for a long run. If the app has past runs, open one: its activity feed shows the credits used by each completed pass. With no baseline, set a credit limit on your first Deep dive. See [Usage](https://docs.cloudthinker.io/guide/billing/usage.md).
* Your WAF, IDS and on-call team know the run is coming, and you have approval to test any assets you don't host yourself. See [Before your first run](https://docs.cloudthinker.io/guide/security/cyber-overview.md#before-your-first-run) for traffic source, private targets and rate limits.

## Prepare the app

Deep dive can only test what it can reach. Inputs you skip leave those areas untested, and the run reports them as limitations, not as clean.

| Input | Where to add it | Why it matters for Deep dive |
| - | - | - |
| Scope | App **Settings** | Sets the paths the run may touch, including with destructive requests. Exclude anything that must stay off-limits |
| Test logins (gray-box) | **Add auth** in the run dialog, or **Add authentication** in the app's **Settings** | Needed to test anything behind a login. Add one test user per role or tenant, and describe each one so the run can check what that user should and shouldn't reach |
| Repository (white-box) | **Attach repository** in the run dialog | Lets CloudThinker read source code to explain behavior and test deeper |
| Context | **Attach context** in the run dialog | OpenAPI specs, Postman collections, runbooks, or architecture notes steer the test. They don't change how deep it goes |
| Test data | Your environment | Use disposable records and have a way to restore anything the run changes |

Logins and repositories you add from the run dialog are saved to the app, the same as adding them in **Settings**. A saved login isn't proof of signed-in testing: a password is saved without signing in, and is first tried when the run starts. A failed sign-in ends the run as **Failed**. Check the report's limitations before you treat protected areas as tested.

> [!NOTE]
>
> Saved passwords are stored encrypted and passed to the run privately. The agent never sees them as text. Each run uses the login version saved at launch, so editing a login later doesn't change a run in progress. Use dedicated test accounts with no access to real customer data, since captured responses are kept as finding evidence. See [Data protection](https://docs.cloudthinker.io/guide/security/data-protection.md).

## Start a Deep dive run

**1. Open the app**

Open your app from the **Apps** list in the Cyber sidebar, or go to **Cyber → Overview** and select it. Check its **Settings** link in the app header for scope and saved logins.

**2. Pick Deep dive**

Click **Run pentest** in the app header. Under the testing intensity cards, select **Deep dive**. A warning appears: **Deep dive includes destructive testing**.

![The Run pentest dialog with testing intensity, access level, and context controls.](https://mintcdn.com/cloudthinker/_u5eRuTpYujlERGZ/images/security/cyber/07-run-pentest.png?fit=max\&auto=format\&n=_u5eRuTpYujlERGZ\&q=85\&s=187b29a900a3d042c49df00003947434)

**3. Add logins or a repository (optional)**

Skip this if the app's **Settings** already has them. Otherwise, under **Access level**, click **Go deeper**, then **Add auth** for a test user or **Attach repository** for source code.

**4. Set a credit limit (optional)**

Enter a whole number in **Credit limit · Optional**, or leave it blank (**No run limit**). Read [How the credit limit works](#how-the-credit-limit-works) before you rely on it.

**5. Launch and confirm**

Click **Run Deep dive pentest**. In the **Run a Deep dive pentest?** dialog, check the target, then click **Run Deep dive**. Click **Keep editing** to go back.

**Success state:** the run opens with live progress as CloudThinker works. You can find it later in the app's **Runs** tab.

## Stop a run

Open the run from the app's **Runs** tab, click **Stop run**, then **Stop run** again in the **Stop this run?** dialog. The run is cancelled and can't be resumed. Findings collected so far are kept. Requests already sent to your app aren't undone, so check the test data afterwards.

If nobody stops it, a run ends when CloudThinker has no more useful work, a limit is reached, or three hours pass.

## Schedule Deep dive

Click **Schedule…** instead of running now, set the recurrence, and confirm **Schedule Deep dive**. Scheduled runs can't carry a credit limit. The only spending control for them is the workspace's monthly [credit limit](https://docs.cloudthinker.io/guide/billing/credit-limits.md). Scheduled runs also sign in only with **Long-lived token** test users. With other login methods, a scheduled Deep dive doesn't sign in as your test users, so it can't test anything behind the login (see [Add test users](https://docs.cloudthinker.io/guide/security/pentest.md#add-test-users)).

> [!WARNING]
>
> Every scheduled occurrence sends destructive requests with nobody confirming it, and there's no per-run credit limit. Schedule Deep dive only against a staging target with disposable data and a tight scope.

Each launch and stop is recorded in [Audit logs](https://docs.cloudthinker.io/guide/security/audit-logs.md) under the **Cyber** category, so you can see who started a destructive run.

## How the credit limit works

The credit limit is a soft stop for one manual Deep dive run, not a hard spending cap.

| Situation | What happens |
| - | - |
| Field left blank | No per-run limit. The run ends when CloudThinker has no more useful work, or another run limit is reached |
| Usage reaches 90% of the limit | CloudThinker finishes the current pass, starts no new one, and writes the report |
| Final usage | Can go above the limit, because the current pass and the report still complete |
| Limit entered, then **Schedule…** | Scheduling is disabled. Clear the limit to schedule |

Valid values are whole numbers from 1 to 1,000,000,000. While the run is going, its **Credit usage** panel shows usage as a percentage of your limit, and switches to **Writing your report** once testing stops.

## What happens during the run

1. CloudThinker maps the app and tests it the way a Full run does, within your scope.
2. At the end of each pass, it reviews saved findings, coverage, and logins, then picks the next question worth testing, such as "can a user in tenant A open tenant B's invoice?"
3. Each new pass keeps the evidence and notes from earlier passes.
4. The run closes when CloudThinker finds no more useful work or a limit is reached. It then writes a report that lists what it couldn't test.

A long stretch with no new findings is normal. A pass can rule out an attack path without producing a finding.

## Read the results

Open the run from the app's **Runs** tab to see its timeline, findings, and report.

![A completed run in the Runs tab, with its findings and report.](https://mintcdn.com/cloudthinker/_u5eRuTpYujlERGZ/images/security/cyber/08-run-workbench.png?fit=max\&auto=format\&n=_u5eRuTpYujlERGZ\&q=85\&s=f6006424c4888f08190fe3e16f2e3de2)

Read three things together:

* **Findings:** each one carries the attack flow, request and response evidence, impact, and a fix. Triage them in [Findings](https://docs.cloudthinker.io/guide/security/cyber-findings.md).
* **Logins:** the report names areas behind a failed login. Those weren't tested.
* **Limitations in the report:** blocked paths, missing access, and checks that didn't finish.

A run with no findings doesn't mean the app is secure. It means CloudThinker found nothing it could prove within the access and scope you gave it.

## Troubleshooting

For every Cyber problem in one place, see [Cyber troubleshooting](https://docs.cloudthinker.io/guide/security/cyber-troubleshooting.md).

> **Deep dive shows Coming soon and can't be selected**
>
> Deep dive is on by default, but it can be turned off for a whole CloudThinker; it isn't tied to your plan. While it's off you can't start or schedule it, so choose **Full** for destructive testing. To get it turned on, ask CloudThinker support, or whoever runs CloudThinker for your company.

> **Schedule… is disabled**
>
> You entered a credit limit. Clear **Credit limit · Optional** to schedule. Credit limits apply to manual runs only.

> **The run button is blocked with Domain verification required**
>
> The target's domain isn't verified yet. Finish the DNS proof described in [Run a pentest](https://docs.cloudthinker.io/guide/security/pentest.md), then reopen **Run pentest**.

> **A saved login no longer works**
>
> The run dialog tests saved session tokens before launch. Click **Update login** to replace the credentials, or **Test again** after fixing the account. The run can't start until the session token works.

> **Usage went past my credit limit**
>
> Expected. The limit stops new passes at 90%, but the pass in progress and the report still finish. Set a lower limit next time if you need more headroom.

## Next steps

> **[Triage security findings](https://docs.cloudthinker.io/guide/security/cyber-findings.md)**
>
> Read each finding's proof and move it through your fix workflow

> **[Create Cyber reports](https://docs.cloudthinker.io/guide/security/cyber-reports.md)**
>
> Download the run report or export selected findings


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.