Skip to main content

Oos Check User

Task to Evaluate​

Description: {task_description}

Done Definition: {done_definition}

Known Services ({service_count} total)​

{services_context}

Known Endpoints ({endpoint_count} total)​

{endpoints_context}

Allowed Domains​

{allowed_domains}

Out-of-Scope Exclusions​

The following vulnerability types, activities, and methodologies are NOT authorized for this engagement. Any task that matches an item on this list is out of scope.

{out_of_scope_items}

Your Analysis​

Work through these 4 steps IN ORDER. Write out your reasoning for EACH step completely — do not skip ahead or combine steps.

Step 1: Understand the Task​

Read the task description and done definition carefully. Answer these questions in your reasoning:

  • What is this task asking the tester to do? Describe the activity in your own words.
  • What type of vulnerability or security test is involved? (e.g., SQL injection, XSS, IDOR, authentication bypass, reconnaissance, certificate pinning check, rate limit testing, etc.)
  • What is the goal of the task? (e.g., gain unauthorized access, exfiltrate data, cause service disruption, enumerate resources, etc.)

This step establishes WHAT work is being proposed before we check WHERE it targets and WHETHER it's allowed.

Step 2: Identify the Target​

Now determine WHAT the task is targeting by cross-referencing the task description with the services and endpoints provided above.

  • Look at the task description: does it mention a specific URL, domain, hostname, service name, or endpoint?
  • Look at the Known Services list: which service does this task relate to? Extract the service name, URL, and ID.
  • Look at the Known Endpoints list: which specific endpoint does this task target? Extract the method, URL, and ID.
  • If the task doesn't name a specific target but describes a methodology (e.g., "test for XSS"), the services and endpoints context tells you what infrastructure the task is implicitly targeting. Use that.

Extract and list every domain and hostname that appears in:

  1. The task description and done definition
  2. The target service URL
  3. The target endpoint URL

Classify each domain as either:

  • Target — the tester will send HTTP requests TO this domain (curl, browse, scan, fetch headers from)
  • Referenced — the domain is mentioned in the attack scenario but the tester does NOT interact with it directly (e.g., attacker-controlled origins in CORS/CSP tests, typosquatting domains described hypothetically, SSRF payload destinations, open redirect targets)

Ask for each domain: "Will the tester send HTTP requests TO this domain?" If yes → Target. If it only appears as a value sent to an in-scope server or as part of the attack narrative → Referenced.

Only Target domains will be checked against the allowed domains list in the next step.

Step 3: Domain Scope Check​

Before matching: Extract the hostname from any URL (strip protocol, port, path, query string). Domain matching operates on hostnames only — /api/v1/users is a path, not part of the domain.

For EACH Target domain you identified in Step 2, compare it against the Allowed Domains list above. Write out the comparison explicitly — one domain at a time. Skip Referenced domains (note them as "Referenced — SKIP").

For each Target domain, answer:

  1. Is there an exact match in the allowed list? If yes → in scope.
  2. Does the www. equivalence rule apply? www.example.com and example.com are the same site — if either is allowed, the other is too. If yes → in scope.
  3. Is there a wildcard entry (*.parent.com) in the allowed list where this domain is a subdomain of parent.com? If yes → in scope.
  4. Is there only a bare entry (parent.com, no wildcard) and this domain is a non-www subdomain like api.parent.com? If so → OUT OF SCOPE. Bare entries do NOT cover subdomains other than www..
  5. Does the domain differ by only 1-2 characters from an allowed domain (obvious typo from LLM-generated text)? If yes → treat as a match, IN SCOPE.
  6. Is this domain completely absent from the allowed list? → Check if it is a cloud infrastructure domain (see Rule 2 in the system prompt). If the domain belongs to a cloud provider (AWS, GCP, Azure, CDN, hosting platform) and serves content for an in-scope service, it IS in scope. If it is a third-party SaaS platform the target merely uses as a customer, it is OUT OF SCOPE. If it is neither cloud infrastructure nor SaaS, it is OUT OF SCOPE.

You must write this comparison for every single Target domain. Do not say "all domains are in scope" without showing the match for each one.

Example of how to write domain checks (with a hypothetical allowed list of example.com, *.acme.org):

  • example.com [Target] → exact match with example.com → IN SCOPE
  • www.example.com [Target] → www. equivalence: example.com is allowed, so www.example.com is too → IN SCOPE
  • api.example.com [Target] → not an exact match. Check www equivalence: not a www prefix. Check wildcards: no *.example.com in allowed list. Only bare example.com exists, which does NOT cover non-www subdomains → OUT OF SCOPE
  • staging.acme.org [Target] → not exact match. Check wildcards: *.acme.org is in allowed list, and staging.acme.org is a subdomain of acme.org → IN SCOPE
  • evil-acme.org [Referenced] → attacker domain in CORS/CSP scenario → SKIP (not a target)

If ANY Target domain is out of scope, stop here — the task is out of scope. Set category to "domain" and violated_rule to a precise description like "api.example.com is not covered by the bare entry example.com (no wildcard *.example.com in allowed list)".

If all Target domains pass, continue to Step 4.

Step 4: Exclusion List Check​

Now check whether the task's primary purpose matches any item in the Out-of-Scope Exclusions list provided above.

CRITICAL: The allowed domains list always takes precedence over the exclusion list. The exclusion list restricts WHAT you can test (vulnerability types, activities). The allowed domains list controls WHERE you can test. If a domain is explicitly in the allowed domains list (exact match or covered by a wildcard), it CANNOT be made out of scope by anything in the exclusion list. Even if the exclusion list contains a domain pattern, that domain pattern does not override an explicit entry in the allowed domains list.

CRITICAL: Primary purpose rule. Only flag a task if its primary purpose or main objective matches an exclusion. Multi-step pentest tasks often include incidental sub-steps (e.g., "also check rate limiting", "note cookie flags", "verify versions") that touch excluded categories but are NOT the task's main goal. These incidental steps do NOT make the task out of scope.

First, identify the task's primary purpose from Step 1. Then go through the exclusion list item by item. For each exclusion, ask: "Is this the task's main objective, or is it just an incidental sub-step?"

Remember:

  • Match on meaning, not exact wording. A task about "resource exhaustion via concurrent requests" matches an exclusion for "Rate limiting / DoS testing".
  • Do NOT over-match. An exclusion for "Self-XSS" does not exclude reflected or stored XSS. An exclusion for "Crashes due to malformed URL Schemes" does not exclude all crash testing.
  • When an exclusion is ambiguous, consider the task's primary goal. Brute forcing a login to gain access is NOT rate limiting — even if it involves many requests. But flooding an endpoint to cause degradation IS.
  • Proving access control vulnerabilities is not data exfiltration. Reading another user's record to demonstrate IDOR/auth bypass is standard PoC methodology, not "exfiltrating PII."
  • Using an intercepting proxy is not a MITM attack. Burp Suite/ZAP on the tester's own traffic is standard practice, not an attack on other users' connections.
  • Incidental sub-steps do not trigger exclusions. If a task mentions an excluded activity as one step among many but the overall goal is a different legitimate test, the task is IN SCOPE.
  • The exclusion list may contain domain patterns (e.g., *.target.com). These restrict vulnerability types or activities — they do NOT override the allowed domains list. If a domain passes the allowed domains check in Step 3, it cannot be excluded here.

Write out your check against the exclusion list. For each item that seems potentially relevant, explain why it does or does not match the task's primary purpose.

Here is the exclusion list again for reference:

{out_of_scope_items}

CRITICAL: Read each exclusion CAREFULLY, including qualifiers. An exclusion like "Clickjacking on non-sensitive pages" has two parts: the vulnerability (clickjacking) and the qualifier (non-sensitive pages). BOTH must match. If the task targets a sensitive page (login, payment, admin, settings), the exclusion does NOT apply.

Partial match — modify instead of reject: If the task contains multiple activities and only SOME match an exclusion:

  1. Do NOT reject the entire task
  2. Set is_out_of_scope to false
  3. Set category to "partially_out_of_scope"
  4. Populate scope_modification:
    • removed_sections: list each removed item (e.g., "Rate limiting test on /api/login")
    • modified_description: rewrite the full task description with the OOS parts removed
    • modified_done_definition: rewrite done criteria removing OOS success conditions
    • modification_reasoning: explain which exclusion each removed section matched

Final decision:

  • If the ENTIRE task's primary purpose is OOS (domain or all activities excluded): is_out_of_scope=true, category="domain" or "explicit_exclusion"
  • If PARTS of the task are OOS but the core is in scope: is_out_of_scope=false, category="partially_out_of_scope", populate scope_modification
  • If nothing is OOS: is_out_of_scope=false, category="in_scope", scope_modification=null

Now perform your analysis. Write out all 4 steps with your full reasoning, then provide the structured output.