A target is something you want to pentest (a URL, an API base, a codebase). A scan config is the parameters you’d run against it (scope, max duration, budget, auth). Both are reusable, saved per-org, and authored entirely from the dashboard. Running a scan is a (target, scan config) pair — manual or scheduled.
Authoring is dashboard-only. Targets and scan configs are created, edited, and deleted from the UI; there is no public REST or CLI surface for create/edit. Triggering a scan run is also UI-or-scheduled — no curl, no API, no CLI flag to fire one off externally.

​
End-to-end flow

  1. Create a target.
  2. Create a scan config.
  3. Pair a target with a config and start a scan.
  4. Watch the live view as the agent runs.
  5. Findings land in the Pentest → Findings inbox.
The same (target, config) pair can be reused for nightly scheduled runs, ad-hoc manual runs, and pre-release deep dives. Findings flow into the unified inbox at Pentest → Findings regardless of how the scan was triggered.

​
Step 1 — Create a target

Pentest → Targets → New.
FieldRequiredNotes
NameYesHuman-friendly identifier — e.g. staging-app, api-public-v2. Used everywhere the target is referenced.
TypeYesWeb app / API / Codebase / Mobile backend. Drives which probe families are eligible.
Base URL or pathYesPublic URL, internal URL/IP your worker can reach, or /var/lib/tigerstrike/codebase/<name> for codebases mounted on a self-hosted worker.
DescriptionoptionalFree-text. Typically used for change-control links and primary contact.
Allowed pathsoptionalPath allow-list — restrict the agent to specific routes. Glob-style: /api/v2/**, /webhooks/**. Leave empty to scan everything.
Forbidden pathsoptionalHard exclude — agent never discovers or probes these. Use for destructive endpoints (/admin/destroy-tenant, /api/users/*/delete, /payments/refund).
AuthconditionalNone / Basic / Bearer token / Form login / OAuth2 / Cookie. See the auth field walkthrough in Hosted scan → Authenticating.
WorkerYesHosted (TigerGate-side) / <self-hosted-worker-name> / any-self-hosted. See Worker pinning.
TagsoptionalFree-form labels — team:platform, env:staging, release-blocker. Searchable across findings.
NotesoptionalFree-text.
Targets are reusable — most teams end up with one target per environment (prod-readonly, staging-full, dev-full). Edit by clicking the row in Pentest → Targets; delete from the same view.

​
Step 2 — Create a scan config

Pentest → Scan Configs → New.
FieldRequiredDefaultNotes
NameYes—e.g. nightly-full, pr-quick-auth.
ScopeYesauth+apiauth / api / auth+api / full. See Picking a scope for time / cost trade-offs.
Max duration (minutes)Yes60Wall-clock cap. Scan stops cleanly at the limit and returns whatever it found.
Per-scan budget (USD)Yes10Hard cap on LLM spend for one run. Scan aborts when reached.
ConcurrencyYes21–4 parallel agents. Higher = faster but burns budget faster.
Reasoning modelYesclaude-opus-4-7Primary planner — picks the next action.
Tool-use modelYesclaude-sonnet-4-6Used for tool calls (HTTP probes, payload mutations).
Cheap modelYesclaude-haiku-4-5Used for repetitive sub-steps (parsing responses, summarising). See LLM providers for the picker.
CategoriesoptionalAllMulti-select — XSS / SQLi / IDOR / SSRF / SSTI / Auth bypass / CSRF / Open redirect / Path traversal / Command injection / Deserialization / Prototype pollution / JWT / CORS / Rate limiting / Business logic.
Stop on first CRITICALoptionalOffAbort the scan as soon as one CRITICAL is confirmed — useful for “any finding fails the gate” flows.
Notify on finishoptionalOffPre-wire a Slack / email / webhook notification for this config.
Retain transcriptoptionalOn (30 days)Keep the full agent transcript for reproduction. Off = only findings retained.
Tagsoptional—Same tag vocabulary as targets.
A (target, config) pair is one scan; a single target can be paired with multiple configs (a nightly-full and a pr-quick-auth, e.g.).

​
Step 3 — Run a scan

Two ways. There is no CI / curl / CLI trigger — scans are started from the UI or by the scheduler.

​
Manual run

Pentest → New Scan:
1

Pick a target

Dropdown of every target in the org. Type to filter.
2

Pick a scan config

Dropdown of every config. The page shows the config’s scope, max duration, and budget so you can sanity-check before launching.
3

Review the estimate

Below the form: Estimated duration (5–240 min) and Estimated cost (USD, model-dependent). The numbers come from past scans of similar shape.
4

Optional one-off overrides

Toggle Override config for this run to tweak max duration, budget, or concurrency for this run only — the saved config is untouched.
5

Start scan

Click Start scan. You’re redirected to the live view (next section).

​
Scheduled run

Pentest → Schedules → New:
FieldNotes
Target + Scan configSame pickers as the manual run.
CadenceCron expression, or one of the presets: hourly / daily / weekly / monthly.
WindowRestrict to a time-of-day window — e.g. 02:00–06:00 UTC to dodge prod traffic.
Skip if last run < N hours agoAvoid double-firing if a manual run happened recently.
Notify on start / finish / failureWires up Slack / email / webhook from this schedule.
Scheduled runs land in Pentest → Scans alongside manual ones; the row is tagged scheduled so you can filter.

​
Step 4 — Live view

The scan opens at Pentest → Scans → <scan-id> with a live-updating view. What’s on the page:
  • Status banner — Queued → Running → Completed / Stopped / Failed. Elapsed wall-clock time updates every second.
  • Progress bar — agent-reported completion estimate.
  • Spend meter — live LLM cost against the per-scan budget. Turns red at 80 %.
  • Agent transcript — streamed log of planner decisions + tool calls + findings as they’re confirmed. Auto-scrolls; click any line to pin.
  • Findings list — every confirmed finding rendered immediately, sortable by severity / time / category.
  • Controls — Pause (resume later), Stop (end the run; partial findings are kept), Open transcript (full agent log in a new tab).
The transcript is shareable — anyone with org access can open the same URL and watch the run.

​
Step 5 — After the scan

When the status flips to Completed, the page becomes static:
  • Findings roll into the unified Pentest → Findings inbox.
  • Reproduction payloads are attached to each finding — copy/paste-able curl commands or HAR files.
  • Spend report is finalised on the Spend tab.
  • Schedule the next run button appears if this was a manual run that you might want to recur.
To re-run with the same (target, config) pair, click Run again in the top-right.

​
Picking a scope

ScopeTimeCostWhen
auth5–15m$Only the auth surface — login, MFA, password reset, session management
api15–45m$$Static API surface; you provide a token, agent probes endpoints
auth+api30–90m$$$Login flow + everything reachable as the authenticated user
full60–240m$$$$Above + deep crawl; finds the long-tail issues
Start with auth+api for general-purpose scans; reserve full for pre-release deep dives. The estimate on the New Scan page shows minutes + cost before you click Start.

​
Path scoping

For large apps, narrow the agent’s playground using the target’s Allowed paths field. Glob-style, one per line: 
/api/v2/**
/webhooks/**
/healthz
For destructive routes the agent should never touch, use Forbidden paths. These are absolute — the agent won’t even discover them: 
/admin/destroy-tenant
/api/v2/users/*/delete
/payments/refund
Both fields are edited on the target page (not the scan config) so every scan against that target inherits the same scoping.

​
Worker pinning

Each target pins to a worker:
  • hosted — runs on TigerGate’s hosted worker. Default for public targets.
  • <worker-name> — a specific self-hosted worker. Useful when you have multiple isolated networks and need each worker to scan only the network it’s on.
  • any-self-hosted — whichever of your self-hosted workers is free first.
Visible at Pentest → Scanners; the worker name is whatever you set as TIGERSTRIKE_WORKER_NAME in .env on the worker host.

​
Tagging

Tag targets + configs (team:platform, env:staging, release-blocker) — tags are searchable across Findings. Useful when:
  • You want all findings on team:payments-tagged targets routed to a specific Slack channel.
  • A release-gate rule that says “no open release-blocker-tagged HIGH+ findings”.
  • Reporting “what did we find in env:prod this quarter”.