# Sample pentest prompts

> Ready flow inputs from examples/prompts: base web pentest checklist and scope-of-work style engagement prompts with expected report-oriented outcomes.

- Repository: vxcontrol/pentagi
- GitHub: https://github.com/vxcontrol/pentagi
- Human docs: https://grok-wiki.com/public/docs/vxcontrol-pentagi-eca0cf4de5f5
- Complete Markdown: https://grok-wiki.com/public/docs/vxcontrol-pentagi-eca0cf4de5f5/llms-full.txt

## Source Files

- `examples/prompts/base_web_pentest.md`
- `examples/prompts/scope_of_work_pentest.md`
- `examples/reports/openai_base_web_pentest.md`
- `examples/reports/ollama_qwen3_32b_fp16_base_web_pentest.md`
- `frontend/src/pages/flows/new-flow.tsx`
- `README.md`

---

---
title: "Sample pentest prompts"
description: "Ready flow inputs from examples/prompts: base web pentest checklist and scope-of-work style engagement prompts with expected report-oriented outcomes."
---

`examples/prompts/` ships two ready-to-paste flow inputs: a web vulnerability checklist (`base_web_pentest.md`) and an engagement scope boundary template (`scope_of_work_pentest.md`). Both become the free-text `input` on `createFlow` (UI, GraphQL, or REST). Sample Markdown reports under `examples/reports/` show how the base checklist expands into task/subtask results and a final findings summary across different LLM providers.

:::files
examples/
├── prompts/
│   ├── base_web_pentest.md          # Web OWASP-style action plan ({{YOUR_TARGET_URL}})
│   └── scope_of_work_pentest.md     # Authorization + scope XML template
└── reports/
    ├── openai_base_web_pentest.md   # Structured Input/Result report (OpenAI run)
    ├── openai_base_web_pentest.pdf
    ├── ollama_qwen3_32b_fp16_base_web_pentest.md  # Nested task tree report (Ollama Qwen3 32B)
    └── ollama_qwen3_32b_fp16_base_web_pentest.pdf
:::

<Warning>
Only assess systems you own or are explicitly authorized to test. The scope template is guidance for agent instructions; it does not replace legal authorization, customer approval, or runtime enforcement of target allowlists.
</Warning>

## Prompt inventory

| File | Role | Placeholder(s) | Typical use |
| --- | --- | --- | --- |
| `examples/prompts/base_web_pentest.md` | Endpoint mapping + per-input vuln checks | `{{YOUR_TARGET_URL}}` | First automation flow for a single web app |
| `examples/prompts/scope_of_work_pentest.md` | Engagement boundaries + pre-action scope protocol | `{{WHO_AUTHORIZED_THE_TEST}}`, targets, rates, credentials, windows | Prefix or wrap any methodology prompt before recon |

These are **user flow inputs**, not agent system templates. System/agent templates (`.tmpl`, `PromptType`, Settings → Prompts) live on a separate surface; see [Prompts and templates](/prompts-reference).

## Base web pentest checklist

`base_web_pentest.md` opens with a single objective, then a two-phase action plan the generator can decompose into tasks and subtasks.

**Objective line**

```text
You need to find critical or valuable vulnerability in a Web Application {{YOUR_TARGET_URL}}
```

Replace `{{YOUR_TARGET_URL}}` with a concrete host (for example `http://10.10.10.10:8080` as in the sample reports).

### Phase 1 — Collect all endpoints

| Step | Agent focus |
| --- | --- |
| Application exploration | Navigate pages, exercise features, include authenticated paths |
| Identify scenarios | Map user journeys and trust boundaries |
| Document endpoints | URLs, inputs, parameters; prioritize file upload features |

### Phase 2 — Per-endpoint checks

| Check | Tools / techniques called out in the prompt |
| --- | --- |
| Path traversal | Linux assumption; read sensitive files such as `/etc/passwd`; focus download/view paths |
| CSRF | Token presence; token-less requests; POST→GET; bypass techniques |
| XSS | Front-end stack; marker `XSS_TEST_123`; reflection context; unusual tags/handlers |
| SQL injection | Login/search/URL params; `sqlmap` with cookies/tamper scripts as needed |
| Command injection | Time-based detection; `${IFS}` / backtick syntax; `commix` |
| SSRF | OOB via Interactsh-class tools; uploads, PDF, webhooks, import/export |
| XXE | XML forms; `.xml` / `.svg` / `.docx` uploads; Office document rezip path |
| Unsafe file download/upload | Executable extensions; double extension / null byte; `Content-Type` and filename params; path prediction under `/uploads/` |

The checklist is methodology-first (map → systematic checks → evidence), not a flat payload dump. That matches the repo’s pentesting prompt methodology: scope, map, prioritize, validate, report.

## Scope-of-work engagement template

`scope_of_work_pentest.md` defines an XML-shaped instruction block you paste **before or around** a methodology prompt when the engagement needs hard boundaries.

### Structure

| Block | Purpose |
| --- | --- |
| `<authorization_summary>` | Who authorized, date, engagement/ticket name |
| `<allowed_targets>` | Exact hostnames, URLs, CIDRs, approved subdomain patterns |
| `<out_of_scope_targets>` | Third parties, production systems, shared infrastructure |
| `<allowed_actions>` | Passive recon, auth testing, validation, evidence for the report |
| `<forbidden_actions>` | Off-scope testing, broad mass scans, third-party exploit, persistence/exfil beyond plan |
| `<rate_limits_and_windows>` | Request rate, approved test window, blackout periods |
| `<credentials_and_test_accounts>` | Test roles and credential handling rules |
| `<stop_conditions>` | Stop on ambiguous/out-of-scope destinations; stop before disruption |
| `<evidence_expectations>` | Intent, target, timestamp, result; artifacts under `/work`; redact secrets |
| `<scope_check_protocol>` | Eight pre-action rules: extract destinations, match allowlist, strip multi-target out-of-scope entries, validate generated scripts/exploits, record newly discovered hosts without testing them, ask when ambiguous |

### Backend validation ideas (not implemented)

The template file also documents **future** validation ideas only: normalize allow/deny targets, validate tool target flags, per-tool mass-scanner policy, block ambiguous destinations, re-inject scope after a blocked attempt. Treat these as design notes, not current runtime behavior.

### Minimal filled example

```text
You are operating inside an authorized security assessment. Stay strictly within the scope below.

<engagement_scope>
  <authorization_summary>
  Security team ticket SEC-2048, 2026-04-01, staging web app assessment
  </authorization_summary>

  <allowed_targets>
  - https://app.staging.example.com
  - 10.10.10.0/28
  </allowed_targets>

  <out_of_scope_targets>
  - *.production.example.com
  - payment-gateway.vendor.example
  </out_of_scope_targets>

  <allowed_actions>
  - Passive reconnaissance against allowed targets
  - Vulnerability validation against allowed targets only
  - Evidence collection needed for the final report
  </allowed_actions>

  <forbidden_actions>
  - Do not test any target that is not listed or clearly derived from the allowed scope.
  - Do not persist access, exfiltrate sensitive data, or modify data beyond the approved test plan.
  </forbidden_actions>

  <rate_limits_and_windows>
  - Max 10 rps; weekdays 09:00–18:00 UTC only
  </rate_limits_and_windows>

  <credentials_and_test_accounts>
  - Role: standard user; credentials via /work/uploads/creds.txt; do not store secrets in the final report
  </credentials_and_test_accounts>

  <stop_conditions>
  - Stop before interacting with a target that is not provably in scope.
  - Stop and ask for clarification when the scope cannot be determined from the current evidence.
  </stop_conditions>

  <evidence_expectations>
  - Record command intent, target, timestamp, and result summary for each meaningful action.
  - Save screenshots, request/response excerpts, and reproduction notes under /work.
  </evidence_expectations>
</engagement_scope>

You need to find critical or valuable vulnerability in a Web Application https://app.staging.example.com
...paste remainder of base_web_pentest.md checklist...
```

## Run a sample prompt as a flow

### Prerequisites

- At least one configured LLM provider (BYOK keys or local/custom endpoint)
- Stack reachable (typically `https://localhost:8443` after compose up)
- Authorized target reachable from the agent Docker sandbox network
- Optional: search engines, Graphiti, or attached resources under `/work` for richer context

### UI path

<Steps>
  <Step title="Open New flow">
    Sidebar → **Flows** → **New Flow**. Mode tabs: **Automation** (end-to-end goal) or **Assistant** (interactive; optional **Use Agents**).
  </Step>
  <Step title="Select provider and paste input">
    Choose the provider. Paste the substituted prompt into the message box. Placeholder in automation mode: `Describe what you would like PentAGI to test...`. Form requires non-empty `message` and `providerName`.
  </Step>
  <Step title="Optional: template or resources">
    Use the form’s template picker to prefill a saved **FlowTemplate** (`title` + `text`). Attach user resources so they appear under `/work/resources/` and in the `{{.UserFiles}}` task-files block.
  </Step>
  <Step title="Submit and monitor">
    Submit creates the flow and navigates to `/flows/{id}`. Watch tasks/subtasks, toolcalls, and terminal logs. When results accumulate, use **Report** to open, copy, or download Markdown/PDF.
  </Step>
</Steps>

Save repeatable text via **Templates** (`createFlowTemplate` with `title` and `text`), then reapply on New Flow. Example files under `examples/prompts/` are not auto-seeded; copy them into a template or paste once.

### API path

GraphQL mutation surface:

```graphql
mutation CreateFlow($provider: String!, $input: String!) {
  createFlow(modelProvider: $provider, input: $input) {
    id
    title
    status
    createdAt
  }
}
```

REST create payload (`POST /api/v1/flows/`):

| Field | Type | Required | Notes |
| --- | --- | --- | --- |
| `input` | string | yes | Full prompt text (scope + checklist after substitution) |
| `provider` | string | yes | Provider name (for example `openai`, or a custom profile name) |
| `resource_ids` | uint64[] | no | Attached user resource IDs |
| `functions` | object | no | Optional tool function overrides |

Follow-up input on a waiting flow uses GraphQL `putUserInput` or REST `PUT /api/v1/flows/{flowID}` with `action: "input"`.

<RequestExample>
```bash
# REST create (Bearer token from Settings → API Tokens)
curl -sS -X POST "https://localhost:8443/api/v1/flows/" \
  -H "Authorization: Bearer $PENTAGI_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "provider": "openai",
    "input": "You need to find critical or valuable vulnerability in a Web Application http://10.10.10.10:8080\n\nYou have to use the following action plan:\n..."
  }'
```
</RequestExample>

Provider choice is BYOK/BYOC: the same prompt text works with cloud providers, Ollama, vLLM, or OpenAI-compatible endpoints once configured. Outcomes vary with model capability and sandbox reachability, not with a hard-coded vendor path.

## Expected report-oriented outcomes

### What a successful base-web run produces

| Artifact | Where | Content pattern |
| --- | --- | --- |
| Flow title / primary task | Flow page | Goal derived from the prompt (often includes host and check themes) |
| Subtasks | Tasks tree | Mapping, then per-check or exploit follow-ons |
| Tool activity | Toolcalls / terminal | `sqlmap`, `commix`, curl, crawlers, etc., as the checklist suggests |
| Intermediate results | Task `result` | Input plan + Result narrative per step |
| Final report | Report menu (MD/PDF) | Confirmed findings, non-findings, recommendations |
| Evidence files | Flow Files / `/work` | Screenshots, request excerpts, downloaded artifacts when the agent saves them |

### Sample report shapes (same checklist, different providers)

Both sample reports use the base checklist against `http://10.10.10.10:8080`. They illustrate **format and depth variance**, not a guaranteed finding set for your target.

| Sample | Path | Structure | Outcome sketch |
| --- | --- | --- | --- |
| OpenAI run | `examples/reports/openai_base_web_pentest.md` (+ PDF) | Numbered steps with **Input** / **Result** pairs; closes with identified vs non-vulnerable features | Focus on sorting `order` parameter: boolean/error/time-based SQLi, CSRF on sort form; XSS/path traversal/command injection/SSRF/XXE/file handling reported as not found; some steps hit connectivity issues mid-run |
| Ollama Qwen3 32B FP16 | `examples/reports/ollama_qwen3_32b_fp16_base_web_pentest.md` (+ PDF) | Nested checked task tree (flow → assessment → subtasks) | Checklist mirrored in TOC, then exploit chain narrative: XXE on `/registration`, backup `db.sql.gz` credentials, privilege escalation, reverse shell — deeper exploitation path than the OpenAI sample |

Report sections typically include:

1. **Reproduction of the user action plan** (endpoint map + checks a–h)
2. **Per-subtask Input/Result or exploit write-ups**
3. **Findings summary** with impact and recommendations
4. **Negative results** (what was tested and not vulnerable) when the agent completes the full matrix

<Tip>
Compare your run’s Report export to these samples for structure. Do not expect the same CVEs or exploit chain on a different host or model; treat samples as format references and smoke-test baselines.
</Tip>

## Prompt composition patterns

### Good first inputs (minimal)

README guidance for early flows:

- Target system or URL  
- Assessment type  
- Scope limits  
- Expected deliverable (report, hypothesis validation)

```text
Assess https://target.example for common web application vulnerabilities.
Focus on authentication, file handling, and injection issues.
Stay within the provided target only and summarize confirmed findings with reproduction steps.
```

### Layered composition

| Layer | Source | Order |
| --- | --- | --- |
| 1. Scope + stop protocol | `scope_of_work_pentest.md` (filled) | First |
| 2. Methodology checklist | `base_web_pentest.md` (URL substituted) | Second |
| 3. Stack-specific constraints | Manual notes (auth cookies path, tech stack, no DoS) | Optional third |
| 4. File context | Uploads/resources at `/work/uploads/`, `/work/resources/` | Via form attach, not paste |

### Methodology checklist for custom prompts

When refining beyond the stock files:

1. Explicit scope, authorization, success criteria  
2. Map application first (roles, routes, params, uploads, integrations)  
3. Prioritize surfaces; avoid “test everything at once” without ordering  
4. Validate with reproducible evidence before deep exploit  
5. Finish with report-ready impact, prerequisites, and next steps  

Agent-system prompt engineering (roles, XML protocols, `{{.ExecutionContext}}`) is documented in `backend/docs/prompt_engineering_pentagi.md` and the prompts reference; engagement inputs should stay short, hierarchical Markdown/XML, and tool-aware without duplicating system template boilerplate.

## Constraints and failure modes

| Symptom | Likely cause | Mitigation |
| --- | --- | --- |
| Empty form submit rejected | `message` / `input` required and min length 1 after trim | Paste full substituted prompt |
| Provider errors on create | Missing/invalid provider or keys | Configure and test provider before flows |
| Host unreachable in report steps | Target not routable from sandbox | Fix Docker network/DNS; use worker-node topology if needed |
| Broad off-scope scanning | Scope not in user input; no runtime allowlist | Always prefix with filled scope template; monitor toolcalls |
| Shallow or incomplete report | Weak model, truncated run, or vague goal | Prefer stronger models for pentester/reporter; narrow objective; use Assistant to redirect |
| Findings differ from sample PDFs | Different app/model/network | Expected; use samples only for structure |
| Secrets in final report | Agent dumped credentials | Instruct redaction in scope `evidence_expectations`; review before sharing PDFs |

## Verification

After a sample-prompt run:

1. Flow status progresses and tasks/subtasks appear for map + check themes.  
2. Toolcalls include network and scanner activity against **only** allowed targets.  
3. Report export lists confirmed findings and/or explicit non-findings with remediation notes.  
4. Optional: evidence files under the flow Files tab or `/work` paths referenced in the narrative.

## Related pages

<CardGroup cols={2}>
  <Card title="Quickstart" href="/quickstart">
    First flow: provider key, compose up, create flow, verify UI health.
  </Card>
  <Card title="Flows, tasks, and subtasks" href="/flows-tasks-subtasks">
    Lifecycle, Generator/Refiner plans, putUserInput and finish boundaries.
  </Card>
  <Card title="Agents and supervision" href="/agents-and-supervision">
    Specialist agents including reporter, limits, and planning step.
  </Card>
  <Card title="Tools and sandbox execution" href="/tools-and-sandbox">
    Docker-isolated terminal/file tools used by the checklist.
  </Card>
  <Card title="Prompts and templates" href="/prompts-reference">
    System PromptType templates vs user flow inputs and CRUD.
  </Card>
  <Card title="GraphQL API" href="/graphql-api">
    createFlow, putUserInput, createFlowTemplate, subscriptions.
  </Card>
  <Card title="REST API" href="/rest-api">
    POST /api/v1/flows and patch actions for programmatic runs.
  </Card>
  <Card title="Configure LLM providers" href="/configure-llm-providers">
    BYOK wiring so sample prompts run on your chosen models.
  </Card>
</CardGroup>