---
name: pentest-lyan
description: >
  Perform dynamic security validation on explicitly authorized web targets, covering authentication, authorization,
  object ownership, tenant isolation, state transitions, and business rules, and reach strict conclusions using
  reproducible evidence, verified impact, and structured state.
  Use when the user provides an authorized web target
  and asks for penetration testing, a vulnerability assessment, or validation of web security boundaries.
  Do not use for unauthorized targets, social engineering, mobile-only testing, infrastructure scanning,
  or general security advice without a concrete authorized web target.
---

# Pentest Lyan

Perform dynamic security validation on authorized web targets. The targets, assets, accounts, interfaces, and task requirements provided by the user define the authorization scope for this engagement; do not repeatedly request proof of authorization unless the scope changes.

## Core Principles

- Center testing on server-side security boundaries. Dynamically validate authentication, authorization, object ownership, tenant isolation, state transitions, and business rules. Frontend code, errors, fingerprints, and tool output are used only to generate hypotheses for validation.
- Explore broadly but conclude strictly. Assumptions, scanner hits, historical cases, or theoretical attack chains must not be treated directly as vulnerability findings.
- Record an initial technical reproduction as `technical_hit` and keep `rating` as `unrated`; continue validating actual capability, affected objects, data, privileges, assets, business outcomes, scope, and prerequisites.
- A single failure, error, or empty result is insufficient to close a hypothesis. Subsequent attempts should introduce a new identity, object, entry point, state, parsing path, request shape, or piece of evidence. Close a hypothesis only after reasonable coverage of the key variables, and document the conditions for reopening it.
- Do not assign `P1`, `P2`, or `P3` before impact validation is complete. Severity must be based only on proven real-world impact, not on the vulnerability name, CVSS, tool rating, historical cases, or theoretical maximum impact.
- Vulnerability conclusions require supporting evidence such as real requests/responses, state changes, logs, files, data results, or a reproducible PoC. Before completion, review blind spots and unconventional paths.
- Testing depth is determined by the authorized scope, hard safety boundaries, and evidence closure. Preferences such as "read-only," "low-risk," "shallow testing," "lightweight," "offline analysis," or "conservative review" do not replace dynamic validation. When identities, objects, privileges, or the environment are objectively unavailable, explicitly record the gap and determine whether to return `NEED_INPUT` according to the terminal-state precedence rules.
- Do not add restrictions beyond the authorized scope and hard safety boundaries. Continue validation within those boundaries until evidence is closed, hypotheses are reasonably closed, or required input is confirmed to be missing.
- Output must accurately reflect the depth of validation. Content that has not been dynamically validated or lacks sufficient evidence must remain in a hypothesis state rather than being presented with vague wording as a completed conclusion.

## Working Model

Organize every hypothesis using the same model:

```text
Subject × Entry Point × Object × Relationship × Action × State
× Trusted Field × Security Expectation × Backend Result
```

Build the following relationships:

```text
Page/Route → Component/JS → API → Method/Parameters → Credentials
→ Object/Relationship → Action/State → Security Expectation → Verifiable Boundary
```

In each round, prioritize comparisons across identities, entry points, objects, relationships, states, and request shapes. Request-shape coverage should include at least Method, Content-Type, Header, Query/Body, path, array/object forms, encoding, duplicate parameters, and missing, empty, reused, or expired values.

## Status and Severity

Track technical status separately from impact severity:

| `finding_status` | Meaning | Allowed `rating` |
|---|---|---|
| `lead` | Static lead, anomaly, or behavior not yet reproduced as a stable technical hit | `unrated` |
| `technical_hit` | Technical behavior has been reproduced, but real impact has not been closed | `unrated` |
| `impact_verified` | Capability, affected object, result, scope, and prerequisites are all supported by evidence | `info` / `P3` / `P2` / `P1` |
| `closed` | No security-boundary failure was reproduced after reasonable coverage of key variables | `unrated` |

Choose exactly one terminal state:

- `VULN_FOUND`: At least one item is `impact_verified` and rated `P1`, `P2`, or `P3`, with a reproducible PoC and raw evidence.
- `NOT_REPRODUCED`: All relevant hypotheses are `closed`, and no security-boundary failure was reproduced.
- `LOW_ROI`: Impact was verified, but it reaches only `info` and is not recommended as a vulnerability report.
- `NEED_INPUT`: An identity, object, privilege, environment, or other input required to close validation is missing; related items remain `lead` or `technical_hit` and `unrated`.

When multiple result types coexist, select the terminal state that truthfully describes the task outcome according to this precedence: `VULN_FOUND` → `LOW_ROI` → `NEED_INPUT` → `NOT_REPRODUCED`. Verified reportable impact takes priority.

## State Memory

The model makes judgments; files preserve recoverable state. Isolate each project under `pentest-data/{project-id}/` and read the following at the start of every round:

- `state.json`: Phase, current module, session limitations, and terminal state.
- `state/blackboard.md`: Maintain `target / finding_status / rating / evidence / next` for each independent security hypothesis. Update the original entry for the same hypothesis instead of appending one entry per request.
- `module_queue.json`: Modules pending and completed testing.
- `modules/{module_id}.json`: Object models, threat hypotheses, validation results, and cross-identity results.
- `sessions/pool.json` and `sessions/account_*.json`: Session references and identity information.
- `js_analysis.json`, `api_inventory.json`, `permission_matrix.json`, and `pages.json`: Continuously updated attack-surface data.
- `coverage.json` and `summary.json`: Derived during the Audit phase from the preceding facts; do not fabricate them manually.

See `references/schema-guide.md`, `references/schema-data-flow.md`, and `schema/*.schema.json` for field definitions.
When initializing a workspace, merge any missing rules from `assets/workspace.gitignore` into the existing `.gitignore` without overwriting the user's existing rules.

## Reference Routing

Read only the references needed for the current phase rather than loading all references into context at once:

- Discovery: Read `references/discovery-guide.md`.
- Modeling and validation: Read `references/threat-modeling.md` and `references/validation-guide.md`; also read `references/cross-role-testing.md` when identity, ownership, or tenancy is involved.
- High-value patterns: Only when a feature, architectural signal, or Guardian blind spot matches a pattern category, read the `Invocation Contract` and relevant pattern section in `references/HackerOne.md`. Select zero to three `pattern_refs`; do not treat pattern names as vulnerabilities, evidence, or severity.
- Audit: Read `references/audit-guide.md`, `references/report-template.md`, and `references/post-delivery.md`.

When applicability of a HackerOne pattern is uncertain, keep `pattern_refs: []`. Do not invent hypotheses merely to cover the pattern library.

## Quality Constraints

- Do not treat `200`, bypassed frontend restrictions, public paths, versions, CORS observations, or missing security headers directly as vulnerabilities.
- Do not hard-code victim object IDs; obtain objects from the corresponding identity's real authorized list or from authorized test data.
- Do not describe insufficient accounts as "cross-role validation completed." Record the missing conditions and, when they block the conclusion, handle them according to terminal-state precedence.
- `technical_hit` requires locatable raw evidence. `impact_verified` additionally requires capability, object, result, scope, prerequisites, and a PoC.
- `closed` requires a coverage summary, closure reason, and reopening condition. A single failed request cannot close a hypothesis.
- Reusable cookies, tokens, passwords, and sensitive personal data in reports must be minimized and redacted. Store raw evidence in a controlled location and link to it through evidence references.
- `summary.json`, coverage data, severity, and terminal state must be derived from module validation results.

## Execution Flow

Read and check `gates.md` at the beginning and end of each phase.

### Phase 1: Discovery

Read `references/discovery-guide.md`. Understand same-origin pages and frontend JavaScript; discover pages, APIs, parameters, identities, and object relationships; establish the session pool and initial permission matrix; create `state/blackboard.md`. Register all static hits as `lead` and `unrated`; do not assign severity in this phase.

Completion criteria: State files are parseable; the initial module queue is non-empty; `js_analysis.json`, `api_inventory.json`, `permission_matrix.json`, and `pages.json` exist; account limitations are recorded accurately.

### Phase 2: Module Loop

Read `references/attack-guide.md`, and then load the following as needed according to Reference Routing:

- `references/threat-modeling.md`: Object and boundary modeling.
- `references/validation-guide.md`: Dynamic validation, impact closure, closure rules, and Guardian.
- `references/cross-role-testing.md`: Cross-identity testing, object ownership, and tenant isolation.
- `references/HackerOne.md`: Expand high-value hypotheses when architectural signals match; review unconventional combinations during the Guardian phase.

Take a module from `module_queue` and run the loop: "explore → model → dynamically validate → validate impact → Guardian → record." Priority indicates validation order only, not vulnerability severity. Immediately append newly discovered interfaces, objects, and pages to the live files.

Completion criteria: Move the module into `tested_modules` after it passes G2-G4. If required input is missing, preserve the unresolved state and record `missing_requirements`; do not fabricate completion.

### Phase 3: Audit

Read `references/audit-guide.md`, `references/report-template.md`, and `references/post-delivery.md`. Validate schemas and cross-file constraints, generate `coverage.json` and `summary.json`, perform a Guardian review, and produce only a Markdown technical report.

The report must clearly distinguish leads, technical hits, verified impact, and closed items, and it must end with exactly one of the four terminal states.

## Tool Selection

Use browser automation or `curl` according to the environment. Tool differences affect only operation, not validation standards:

| Task | Browser automation available | Browser automation unavailable |
|---|---|---|
| Login and navigation | Browser session | `curl -c/-b` |
| Pages and JavaScript | DOM and network records | `curl` + HTML/JS parsing |
| Dynamic requests | Page `fetch` or network tools | `curl` |
| Cross-identity comparison | Isolated browser contexts | Separate cookie files |

For JavaScript-rendered-only paths that the current tools cannot capture, record the specific gap. If the gap blocks task closure, handle it according to the defined terminal-state precedence.

## Safety Boundaries

Operate only on authorized targets and test data. Avoid deleting existing data belonging to other users, uploading persistent malicious payloads, uncontrolled high-concurrency load testing, expanding to external assets, or executing high-risk system commands unrelated to web-boundary validation.

Actions that may cause real external impact—such as payments, refunds, notifications, batch operations, and permission changes—must use dedicated test resources and comply with the environment constraints provided by the user. Record CAPTCHAs or interactions that require human completion as required input.

After testing, clean up or securely retain plaintext session material according to `references/post-delivery.md`.

## Invocation

```text
/pentest-lyan <target-url> [--project <id>] [accounts...]
/pentest-lyan --resume <id>
/pentest-lyan --list
```

By default, derive `project-id` from the first segment of the target hostname and normalize it to `[a-z0-9-]`. If a project with the same name points to a different target, require a new name. Obtain all timestamps through the system `date` command rather than estimating them in the model.