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

# How a pentest runs

> The phases, what is tested, and why nothing is reported without proof.

A penetration test is run by a team of agents working the way a human tester does: map the surface, form a hypothesis, then try to prove it. The defining rule is that a result becomes a finding only after it has been exploited.

## The four phases

<Steps>
  <Step title="Surface mapping">
    An agent maps the attack surface: routes, parameters, authentication flows, roles, technologies and trust boundaries. In a black box run, any API documentation you attach seeds this. In a white box run, your source provides it. The result is a list pairing each component with the vulnerability classes worth testing against it, sized to the package you chose.
  </Step>

  <Step title="Discovery">
    One agent per item on that list, all running in parallel, each proposing concrete candidates. Nothing here is reported. A candidate is a hypothesis, not a finding.
  </Step>

  <Step title="Validation">
    Each candidate goes to a fresh agent that does not know why it was proposed, which is what stops a plausible story surviving on its own momentum. To become a finding, the candidate must yield a working, minimal and non destructive proof of concept. A known vulnerable dependency instead needs its vulnerable version independently confirmed as present.
  </Step>

  <Step title="Fix, white box only">
    An agent patches the root cause in source and re-runs the proof of concept to prove the issue is gone.
  </Step>
</Steps>

Confirmed results are deduplicated and written up as findings.

## Vulnerability classes

<CardGroup cols={2}>
  <Card title="Injection and execution" icon="terminal">
    SQL and NoSQL injection, command execution, server side template injection, XML external entities, insecure deserialization, prototype pollution.
  </Card>

  <Card title="Access control" icon="user-lock">
    Insecure direct object references, broken function level authorization, mass assignment, authentication and token handling, cross site request forgery.
  </Card>

  <Card title="Server side" icon="server">
    Server side request forgery, path traversal, request smuggling, header injection, open redirect, subdomain takeover, information disclosure.
  </Card>

  <Card title="Client and content" icon="globe">
    Cross site scripting, insecure file upload and download handling.
  </Card>

  <Card title="Logic" icon="sitemap">
    Business logic abuse and race conditions, including multi step attack paths that chain smaller issues.
  </Card>

  <Card title="AI surfaces and supply chain" icon="brain">
    Prompt injection against AI features, and known vulnerable components confirmed present.
  </Card>
</CardGroup>

## Engagement types

The engagement is derived from what you configured, and is cumulative.

| Engagement | Amnify has                          | Consequence                                     |
| ---------- | ----------------------------------- | ----------------------------------------------- |
| Black box  | Host and endpoints                  | Tests what an outsider can reach                |
| Gray box   | The above, plus a credential        | Tests authenticated surface and per role access |
| White box  | The above, plus source repositories | Findings trace to code, and the fix phase runs  |

Every finding records the engagement and package that produced it, so a target tested black box once and white box later keeps both results distinguishable.

## Authorization and safety

<Warning>
  A target cannot run until domain ownership is verified with an organization specific value you publish by DNS record or hosted file. The verification value is unique per organization, so proof of control cannot be transferred. A run against an unverified target is refused.
</Warning>

Every proof of concept must be minimal and non destructive. The package you choose bounds both how deep the testing goes and how much traffic it generates.

## Evidence on a finding

Vulnerability class, affected endpoint or package, CVSS vector and derived score, CWE, the proof of concept, supporting evidence, and the engagement and package. For a white box finding traced to source, the repository, commit and file are recorded as well.

## Scheduling

Daily, weekly or monthly, per target and per engagement and package combination. Configuration changes apply to future occurrences. Runs already in flight keep the configuration they started with. See [Set up a pentest](/pentest/overview).