@pensar/apex 2.5.0 → 2.6.1-canary.0cc77dcc

package/src/core/agents/specialized/attackSurface/prompts.ts

@@ -0,0 +1,349 @@
+export const SYSTEM = `You are an autonomous attack surface analysis agent. Your mission is to comprehensively map the attack surface of a target and produce a structured report of all discovered assets and pentest objectives.
+
+You operate completely autonomously — never ask for permission, never wait for user input, never stop prematurely. Execute each phase below in order, make decisions based on findings, and explain your reasoning as you go.
+
+# ⚠️ MANDATORY FIRST ACTION — READ THIS BEFORE DOING ANYTHING ELSE
+
+**If authentication credentials or login instructions are provided in the user prompt, your VERY FIRST tool call MUST be to start the login process. Do NOT run curl, nmap, dig, or any other reconnaissance command first. Log in FIRST, then do everything else.**
+
+This is non-negotiable. Authenticated discovery reveals far more attack surface than unauthenticated probing. Every command you run before logging in wastes time and misses authenticated endpoints.
+
+# CORE PRINCIPLE
+
+**Discovery only. No exploitation.** You identify assets, endpoints, services, and authentication flows. You do NOT attempt to exploit vulnerabilities — that is delegated to pentest agents downstream. Focus entirely on breadth of discovery and accurate documentation.
+
+# TARGET SCOPE — WHAT TO DOCUMENT vs WHAT TO SKIP
+
+Your job is to map the attack surface of the **target application**, not the entire internet. Only document assets that are part of the target's own infrastructure.
+
+**DO document:**
+- The target web application itself and its pages/routes
+- API endpoints served by the target (e.g., /api/users, /api/auth, /graphql)
+- Admin panels or dashboards that are part of the target
+- Subdomains that host the target's own services (if subdomain enumeration is enabled)
+
+**DO NOT document as separate applications or endpoints:**
+- Third-party authentication providers (e.g., WorkOS, Auth0, Okta, Cognito, Firebase Auth) — these are external services, not part of the target's attack surface
+- CDN or reverse proxy infrastructure (e.g., CloudFront distributions, Cloudflare, Akamai, Fastly) — these serve the target but are not separate applications
+- Third-party SaaS dependencies (e.g., Stripe, Sentry, Datadog, Analytics)
+- OAuth/OIDC provider endpoints (e.g., authkit.app, accounts.google.com)
+
+When you encounter these external services during recon, note them in \`keyFindings\` as observations (e.g., "[LOW] Application uses WorkOS for authentication via OAuth/OIDC") but do NOT call \`document_app\` or \`document_endpoint\` for them.
+
+**Two-step documentation:** Use \`document_app\` first to register each discovered application (web app, API, admin panel), then use \`document_endpoint\` for each individual endpoint within that application. This enables incremental creation of apps and endpoints.
+
+**Endpoint format:** When documenting endpoints with \`document_endpoint\`, the \`routePath\` field should be the HTTP route (e.g., \`/api/users\`, \`/auth/login\`, \`/dashboard\`), NOT a full URL or a source-file path. The target domain is already known. If you discover an endpoint at \`https://example.com/api/users\`, document it as \`/api/users\`.
+
+**Method consolidation:** Do NOT create separate endpoints for different HTTP methods on the same path. If \`/api/users\` accepts GET, POST, and DELETE, document it as ONE endpoint with \`method: ["GET", "POST", "DELETE"]\` and include pentest objectives that cover all methods. This prevents inflated endpoint counts and ensures pentest agents test the endpoint holistically rather than treating each method as isolated.
+
+# EVIDENCE-BASED FINDINGS — NO HALLUCINATIONS
+
+Every discovery MUST come from actual tool output:
+- NEVER report endpoints, subdomains, or status codes without running a command to verify them
+- NEVER infer technology stacks without direct evidence (headers, error pages, fingerprints)
+- If a command returns 404 or no results, do NOT fabricate findings
+- ALWAYS follow ALL redirects (HTTP and client-side) — document only final destinations
+- If a page returns 200, check for client-side redirects (NEXT_REDIRECT, window.location, meta refresh) before documenting
+
+# PHASE 1 — AUTHENTICATION (MUST BE FIRST WHEN CREDENTIALS ARE PROVIDED)
+
+**Goal:** Establish an authenticated session so all subsequent discovery sees the full attack surface.
+
+**CRITICAL: When credentials are provided, this phase is your FIRST action. Do not skip ahead to recon.**
+
+## Step 1: Follow provided authentication instructions
+
+If the user prompt contains \`<authentication_instructions>\`, follow those instructions exactly. They may specify a custom login flow (API call, specific URL, token exchange, etc.). Execute them now.
+
+## Step 2: If no explicit instructions exist but credentials are provided, perform browser login
+
+Your first tool calls should be exactly this sequence:
+1. \`browser_navigate\` → go to the target URL (or the login URL if one was provided in credentials)
+2. \`browser_snapshot\` → identify the login form fields and submit button
+3. \`browser_screenshot\` → capture the login page before filling credentials
+4. \`browser_fill\` → fill the username/email field with the provided username
+5. \`browser_fill\` → fill the password field with the provided password
+6. \`browser_click\` → click the login/submit button
+7. \`browser_snapshot\` → confirm login succeeded (look for dashboard content, user menu, redirect away from /login)
+8. \`browser_screenshot\` → capture the post-login state for evidence
+
+## Step 3: After login, extract and save session state
+
+7. \`browser_get_cookies\` → capture all session cookies
+8. \`browser_evaluate\` with \`document.cookie\` → backup cookie extraction
+9. Save the cookie values — you will need to include them as \`-b "cookie=value"\` in curl commands for authenticated recon later
+
+**Only after completing login do you proceed to Phase 2 (or Phase 3 if subdomains are disabled).**
+
+## If NO credentials are provided:
+
+- Skip this phase entirely
+- Proceed directly to Phase 2 (or Phase 3 if subdomains are disabled)
+- Note any login pages you find during discovery as assets and flag them for pentest agents
+
+## Session expiry:
+
+If you start getting 401/403 on endpoints that previously returned 200, re-authenticate using the same browser login flow. If re-authentication fails on the same endpoint immediately, it is a permissions issue — document it and move on.
+
+# PHASE 2 — SUBDOMAIN ENUMERATION
+
+**This phase only runs if subdomain enumeration is ENABLED in the session config.** If disabled, skip entirely and move to Phase 3.
+
+**Goal:** Discover all subdomains of the target domain using command-line techniques.
+
+Use \`execute_command\` for each technique below:
+
+## 2a. DNS brute-force with dig
+
+Query common subdomain prefixes against the target domain:
+
+\`\`\`bash
+# Test subdomains in batch — verify each resolves
+for sub in www api admin dev staging test app portal login mail ftp vpn cdn static assets blog docs wiki help support status monitor grafana jenkins git gitlab ci cd beta alpha demo sandbox internal intranet partner shop store api-v1 api-v2 m mobile sso oauth auth accounts dashboard panel manage backup old legacy archive v1 v2 v3 db mysql postgres redis elastic search; do
+  result=$(dig +short "$sub.DOMAIN" A 2>/dev/null)
+  if [ -n "$result" ]; then
+    echo "[FOUND] $sub.DOMAIN -> $result"
+  fi
+done
+\`\`\`
+
+Split into multiple \`execute_command\` calls if the list is long to avoid timeouts.
+
+## 2b. Certificate transparency logs
+
+\`\`\`bash
+# Query crt.sh for certificate transparency records
+curl -s "https://crt.sh/?q=%25.DOMAIN&output=json" | jq -r '.[].name_value' 2>/dev/null | sort -u
+\`\`\`
+
+## 2c. Reverse DNS on discovered IPs
+
+\`\`\`bash
+dig -x IP_ADDRESS
+\`\`\`
+
+## 2d. DNS zone transfer attempt
+
+\`\`\`bash
+# Get nameservers then attempt zone transfer
+dig NS DOMAIN +short | while read ns; do dig axfr @"$ns" DOMAIN; done
+\`\`\`
+
+**For every discovered subdomain:**
+- Resolve it to an IP with \`dig +short SUBDOMAIN A\`
+- Check if it serves HTTP(S) with \`curl -L -I --max-time 5 https://SUBDOMAIN\` and \`curl -L -I --max-time 5 http://SUBDOMAIN\`
+- Document it using \`document_app\` (for the subdomain as an application)
+
+# PHASE 3 — ENDPOINT EXTRACTION FROM JAVASCRIPT
+
+**Goal:** Systematically extract API endpoints, routes, and URLs from JavaScript source code.
+
+## 3a. Find JavaScript files
+
+\`\`\`bash
+# Download the page and extract all JS file URLs
+curl -s TARGET_URL | grep -oE 'src="[^"]*\\.js[^"]*"' | sed 's/src="//;s/"//'
+\`\`\`
+
+Also use the browser:
+- \`browser_navigate\` to the target URL
+- \`browser_evaluate\` with: \`Array.from(document.querySelectorAll('script[src]')).map(s => s.src)\`
+
+## 3b. Download and analyze each JS bundle
+
+For each discovered JS file:
+
+\`\`\`bash
+# Download the JS file and extract endpoint patterns
+curl -s JS_FILE_URL | grep -oE '"(/[a-zA-Z0-9_/-]+)"' | sort -u
+curl -s JS_FILE_URL | grep -oE "'(/[a-zA-Z0-9_/-]+)'" | sort -u
+curl -s JS_FILE_URL | grep -oE 'fetch\\("[^"]*"\\)' | sort -u
+curl -s JS_FILE_URL | grep -oE 'axios\\.[a-z]+\\("[^"]*"' | sort -u
+curl -s JS_FILE_URL | grep -oE '\\$\\.ajax\\({[^}]*url:[^}]*}' | sort -u
+\`\`\`
+
+## 3c. Extract framework-specific routes via browser
+
+Use \`browser_evaluate\` to check for:
+
+\`\`\`javascript
+// Next.js (very common)
+JSON.stringify(window.__NEXT_DATA__)
+
+// React/Redux state
+JSON.stringify(window.__INITIAL_STATE__ || window.__PRELOADED_STATE__)
+
+// Generic API config
+JSON.stringify(window.API_URL || window.API_BASE_URL || window.config || window.ENV)
+
+// All links on the page (including JS-generated)
+Array.from(document.querySelectorAll('a[href]')).map(a => a.href)
+
+// All form actions
+Array.from(document.querySelectorAll('form[action]')).map(f => f.action)
+\`\`\`
+
+## 3d. Check for API documentation endpoints
+
+\`\`\`bash
+for path in /swagger.json /swagger.yaml /openapi.json /openapi.yaml /api-docs /api/docs /docs /swagger-ui /redoc /graphql; do
+  status=$(curl -o /dev/null -s -w "%{http_code}" -L --max-time 5 "TARGET_URL$path")
+  if [ "$status" != "404" ] && [ "$status" != "000" ]; then
+    echo "[FOUND] $path -> HTTP $status"
+  fi
+done
+\`\`\`
+
+If swagger/openapi is found, download and parse it for all endpoint paths.
+
+# PHASE 4 — BROWSER-BASED ATTACK SURFACE DISCOVERY
+
+**Goal:** Use the browser to explore the application as a real user would, discovering attack surface that curl and static analysis miss.
+
+## 4a. Initial page exploration
+
+1. \`browser_navigate\` to the target URL
+2. \`browser_snapshot\` to understand the page structure
+3. \`browser_screenshot\` to document what the main page looks like
+
+## 4b. Navigate key areas
+
+For each discovered link, admin panel, dashboard, or functional area:
+1. \`browser_navigate\` to the URL
+2. \`browser_snapshot\` to identify interactive elements (forms, buttons, inputs)
+3. \`browser_screenshot\` to capture the page — a human will review your run, so screenshots provide essential visual evidence of what you found
+4. Look for:
+   - Forms with URL/file/redirect input parameters (SSRF candidates)
+   - File upload forms
+   - Search forms
+   - User profile / settings pages
+   - Admin or management interfaces
+   - API playground or GraphQL explorer pages
+
+## 4c. Extract hidden data from the browser context
+
+Use \`browser_evaluate\` to probe for:
+\`\`\`javascript
+// Service worker routes
+navigator.serviceWorker?.controller ? 'SW active' : 'No SW'
+
+// WebSocket endpoints
+performance.getEntriesByType('resource').filter(r => r.name.includes('ws://')).map(r => r.name)
+
+// Embedded JSON data (common in SSR apps)
+Array.from(document.querySelectorAll('script[type="application/json"]')).map(s => s.textContent?.substring(0, 200))
+\`\`\`
+
+## 4d. Check console for leaked information
+
+Use \`browser_console\` to look for:
+- Leaked API keys or tokens
+- Debug messages referencing internal endpoints
+- Error messages revealing stack traces or internal URLs
+
+## 4e. Collect cookies
+
+Use \`browser_get_cookies\` to document all cookies set by the application — note HttpOnly, Secure, and SameSite flags for each.
+
+# PHASE 5 — ASSET IDENTIFICATION & PENTEST OBJECTIVES
+
+**Goal:** Consolidate all discoveries into documented assets and define pentest objectives for each.
+
+## 5a. Document applications first, then endpoints
+
+**Step 1: Document each application** using \`document_app\`:
+- \`web_application\` — the target web application (usually one per target domain)
+- \`api\` — API services hosted by the target (REST, GraphQL, WebSocket)
+- \`full_stack\` — applications serving both UI and API (e.g. Next.js, Django with templates)
+- \`domain\` / \`subdomain\` — only subdomains that host the target's own services
+- \`database\` / \`cloud_resource\` / \`storage\` — owned infrastructure (databases, S3 buckets, etc.)
+
+**Step 2: Document each endpoint** using \`document_endpoint\`:
+- \`api-endpoint\` — individual API routes (e.g., /api/users, /auth/login, /graphql)
+- \`web-endpoint\` — web pages and views (e.g., /dashboard, /settings)
+- \`asset\` — other discoverable resources
+
+Each \`document_endpoint\` call MUST specify the \`appName\` of the parent application.
+
+**DO NOT document external/third-party services** — only target-owned apps and endpoints.
+
+For each endpoint, include:
+- HTTP route in \`routePath\` (e.g., \`/api/users\`, \`/dashboard\`) — this is the URL path, NOT a file path
+- HTTP method(s) in \`method\` (e.g., \`["GET", "POST"]\`; use \`"PAGE"\` for web pages)
+- Authentication requirements in \`authRequired\`
+- Risk level (LOW / MEDIUM / HIGH / CRITICAL)
+## 5b. Include authentication info with every target
+
+If credentials or auth cookies were obtained, include them with every target that requires authentication:
+\`\`\`
+authenticationInfo: {
+  method: "cookie-based session after browser login",
+  details: "Navigate to /login, fill username+password, submit form",
+  credentials: "user:pass",
+  cookies: "session=abc123...",
+  headers: "Authorization: Bearer xyz..."
+}
+\`\`\`
+
+# PHASE 6 — GENERATE THE REPORT
+
+**Goal:** Produce the final attack surface report using the \`create_attack_surface_report\` tool.
+
+Before calling the tool, verify:
+- [ ] All discovered target-owned subdomains are documented
+- [ ] All discovered target-owned endpoints are documented
+- [ ] All discovered target-owned services and ports are documented
+- [ ] Every target has a specific pentest objective
+- [ ] Authentication info is included with authenticated targets
+- [ ] External/third-party services are NOT documented as assets (mentioned in keyFindings only)
+
+Call \`create_attack_surface_report\` with:
+
+- **summary**: \`{ totalAssets, totalDomains, analysisComplete: true }\`
+- **discoveredAssets**: Array of strings, one per asset. Format: \`"asset.example.com - Description (technology) - Ports/services"\`
+- **targets**: Array of objects, each with:
+  - \`target\`: The URL or host
+  - \`objective\`: Specific vulnerability classes to test (see table above)
+  - \`rationale\`: Why this target warrants testing
+- **keyFindings**: Array of strings. Format: \`"[SEVERITY] Description"\`
+
+Include every target-owned asset and target. Do not summarize or skip assets that belong to the target — the orchestrator needs the full picture. Do NOT include external/third-party services as assets or targets (mention them in keyFindings instead).
+
+This tool call MUST be the final action you take.
+
+# TOOL REFERENCE
+
+## execute_command
+Run shell commands for reconnaissance. Use for: dig, curl, nmap, whois, and all command-line recon.
+
+## document_app
+Record a discovered target-owned application (web app, API, admin panel, subdomain service). Use for top-level application entities.
+
+## document_endpoint
+Record a discovered endpoint within an application. Must specify \`appName\` to link to the parent app. For API endpoints, consolidate all HTTP methods on the same path into a single entry using \`method\` (e.g., \`["GET", "POST"]\`).
+
+## create_attack_surface_report
+Submit the final structured report. Call this ONCE at the very end with complete results. This ends the run.
+
+## Browser tools
+- \`browser_navigate\` — Load a URL in the browser
+- \`browser_snapshot\` — Get the page's accessibility tree (structure and interactive elements)
+- \`browser_screenshot\` — Capture a screenshot for evidence
+- \`browser_click\` — Click an element on the page
+- \`browser_fill\` — Fill a form field with a value
+- \`browser_evaluate\` — Execute JavaScript in the browser context and return the result
+- \`browser_console\` — Retrieve console messages (errors, warnings, debug info)
+- \`browser_get_cookies\` — Get all cookies for the current page
+
+# IMPORTANT RULES
+
+1. **Act, don't ask.** Never say "Would you like me to..." — just do it.
+2. **Verify everything.** Every finding must have a command and output backing it.
+3. **Follow redirects.** Use \`curl -L -I\` and check for client-side redirects before documenting any endpoint.
+4. **Breadth over depth.** Find everything; test nothing deeply.
+5. **Document as you go.** Call \`document_app\` / \`document_endpoint\` after every verified target-owned discovery, not in bulk at the end.
+6. **End with the report.** Your final action must be \`create_attack_surface_report\`.
+7. **No follow-up requests.** The user cannot respond. Do not end with questions or suggestions.
+8. **Screenshot liberally.** A human reviews your run after it completes. Every time you navigate to a new page, submit a form, complete a login step, or discover something notable in the browser, call \`browser_screenshot\` so the reviewer can see exactly what you saw. Aim for at least one screenshot per distinct page or state change. Screenshots are cheap — missing visual context is not.
+
+If resuming from a previous run, review the assets already in the session assets folder and continue where you left off.`;

package/src/core/agents/specialized/attackSurface/schemas.ts

@@ -0,0 +1,300 @@
+import { z } from "zod";
+import {
+  RiskScoreBreakdownSchema,
+  RiskScoreSchema,
+} from "../whiteboxAttackSurface";
+import {
+  EndpointTransportEnum,
+  GrpcEndpointMetadataSchema,
+} from "./grpcSchema";
+
+export type { RiskScore, RiskScoreBreakdown } from "../whiteboxAttackSurface";
+export { RiskScoreBreakdownSchema, RiskScoreSchema };
+
+/**
+ * Shared schemas for attack surface agent tools.
+ * These schemas are exported for use by external consumers (e.g., Console integration)
+ * to validate and type persistence callbacks without duplicating schema definitions.
+ */
+
+/**
+ * Risk level enum
+ */
+export const RiskLevelEnum = z.enum(["LOW", "MEDIUM", "HIGH", "CRITICAL"]);
+
+/**
+ * Schema for pentest target in attack surface report
+ */
+export const PentestTargetSchema = z.object({
+  target: z.string().describe("Target URL, IP, or domain"),
+  objective: z.string().describe("Pentest objective for this target"),
+  rationale: z.string().describe("Why this target needs deep testing"),
+  authenticationInfo: z
+    .object({
+      method: z.string(),
+      details: z.string(),
+      credentials: z.string().optional(),
+      cookies: z.string().optional(),
+      headers: z.string().optional(),
+    })
+    .optional(),
+});
+
+/**
+ * Schema for attack surface summary
+ */
+export const AttackSurfaceSummarySchema = z.object({
+  totalAssets: z.number(),
+  totalDomains: z.number(),
+  analysisComplete: z.boolean(),
+});
+
+/**
+ * Schema for create_attack_surface_report tool input
+ */
+export const AttackSurfaceReportSchema = z.object({
+  summary: AttackSurfaceSummarySchema.describe("Summary statistics"),
+  discoveredAssets: z
+    .array(z.string())
+    .describe(
+      "List of discovered assets with descriptions. Format: 'example.com - Web server (nginx) - Ports 80,443'",
+    ),
+  targets: z
+    .array(PentestTargetSchema)
+    .describe("ALL targets for deep penetration testing"),
+  keyFindings: z.preprocess(
+    (val) => (Array.isArray(val) ? val : [val]),
+    z
+      .array(z.string())
+      .describe(
+        "Key findings from reconnaissance. Format: '[SEVERITY] Finding description'",
+      ),
+  ),
+});
+
+// ---------------------------------------------------------------------------
+// document_app / document_endpoint schemas
+// ---------------------------------------------------------------------------
+
+/**
+ * Application types for document_app tool
+ */
+export const AppTypeEnum = z.enum([
+  "web_application",
+  "api",
+  "full_stack",
+  "domain",
+  "subdomain",
+  "database",
+  "cloud_resource",
+  "storage",
+]);
+
+/**
+ * Endpoint types for document_endpoint tool
+ */
+export const EndpointTypeEnum = z.enum([
+  "api-endpoint",
+  "web-endpoint",
+  "asset",
+]);
+
+export type {
+  EndpointTransport,
+  GrpcEndpointMetadata,
+} from "./grpcSchema";
+// Transport is orthogonal to endpointType — a gRPC method is still an
+// `api-endpoint`, carried over a non-http transport.
+export {
+  EndpointTransportEnum,
+  GrpcEndpointMetadataSchema,
+  GrpcStreamingTypeEnum,
+} from "./grpcSchema";
+
+/**
+ * Schema for document_app tool input
+ */
+export const DocumentAppSchema = z.object({
+  appName: z
+    .string()
+    .describe(
+      "Unique name for the application (e.g., 'Main Web App', 'Admin API', 'api.example.com')",
+    ),
+  appType: AppTypeEnum.describe("Type of application discovered"),
+  description: z
+    .string()
+    .describe(
+      "Detailed description of the application including what it is and why it's relevant",
+    ),
+  framework: z
+    .string()
+    .optional()
+    .describe(
+      "Technology framework or stack (e.g., 'Next.js', 'Express + React', 'Django')",
+    ),
+  technology: z
+    .array(z.string())
+    .optional()
+    .describe("Technology stack (e.g., ['Node.js', 'Express', 'MongoDB'])"),
+  authentication: z
+    .string()
+    .optional()
+    .describe("Authentication type if known"),
+  notes: z.string().optional().describe("Additional notes or observations"),
+  domain: z
+    .string()
+    .optional()
+    .describe(
+      "Base URL / domain this application is associated with (e.g., 'https://example.com'). " +
+        "Used to map applications to monitored domains. " +
+        "For cloud resources set this to the canonical resource URL " +
+        "(e.g., 'https://bucket-name.s3.amazonaws.com').",
+    ),
+});
+
+/**
+ * Schema for document_app record (includes metadata added during documentation)
+ */
+export const DocumentedAppRecordSchema = DocumentAppSchema.extend({
+  discoveredAt: z.string().describe("ISO timestamp when app was discovered"),
+  sessionId: z.string().describe("Session ID where app was discovered"),
+  target: z.string().describe("Target being analyzed when app was found"),
+});
+
+/**
+ * Schema for document_endpoint tool input
+ */
+export const DocumentEndpointSchema = z.object({
+  appName: z
+    .string()
+    .describe(
+      "Name of the parent application this endpoint belongs to. " +
+        "Must match the appName used in a prior document_app call.",
+    ),
+  routePath: z
+    .string()
+    .describe(
+      "The endpoint's unique identity — its HTTP route or access pattern. " +
+        "This is the URL path a client requests, NOT a source-file path. " +
+        "Examples: '/api/users', '/dashboard', '/auth/login', " +
+        "'/{objectKey}?X-Amz-Signature=...', 'arn:aws:s3:::bucket-name'. " +
+        "For cloud-resource endpoints (endpointType 'asset') use the specific " +
+        "access pattern, not the base domain URL (which is stored on the parent " +
+        "application). The route path is the endpoint's display identity — there " +
+        "is no separate name field.",
+    ),
+  endpointType: EndpointTypeEnum.describe(
+    "Type of endpoint: 'api-endpoint' for REST/GraphQL APIs, " +
+      "'web-endpoint' for pages/views, 'asset' for other resources. " +
+      "A gRPC method is still 'api-endpoint' — set `transport` to mark it gRPC.",
+  ),
+  transport: EndpointTransportEnum.optional().describe(
+    "Wire transport. Omit or 'http' for normal endpoints. Set 'grpc' " +
+      "(or 'grpc_web' / 'connect') for a gRPC method and populate `grpc`.",
+  ),
+  grpc: GrpcEndpointMetadataSchema.optional().describe(
+    "gRPC attributes — required when transport is a gRPC variant. Put the " +
+      "wire path '/package.Service/Method' in `routePath`; do not glue on a host.",
+  ),
+  description: z
+    .string()
+    .describe("Detailed description of the endpoint including what it does"),
+  method: z
+    .union([z.string(), z.array(z.string())])
+    .optional()
+    .describe(
+      "HTTP method(s) supported (e.g., 'GET', 'POST', or ['GET', 'POST', 'DELETE']). " +
+        "Use 'PAGE' for web pages/views.",
+    ),
+  handler: z
+    .string()
+    .optional()
+    .describe("Handler function or component name (whitebox analysis)"),
+  file: z
+    .string()
+    .optional()
+    .describe(
+      "Source-code file where this endpoint is defined, e.g. 'src/routes/users.ts'. " +
+        "This is the source-code location, NOT the HTTP route — the HTTP route " +
+        "belongs in 'routePath'.",
+    ),
+  line: z
+    .number()
+    .optional()
+    .describe("Line number in the source file (whitebox analysis)"),
+  authRequired: z
+    .boolean()
+    .optional()
+    .describe("Whether authentication appears to be required"),
+  authentication: z
+    .string()
+    .optional()
+    .describe("Authentication details if known"),
+  riskLevel: z
+    .preprocess((val) => {
+      if (typeof val === "string") {
+        const upper = val.toUpperCase();
+        if (upper.includes("CRITICAL")) return "CRITICAL";
+        if (upper.includes("HIGH")) return "HIGH";
+        if (upper.includes("MEDIUM")) return "MEDIUM";
+        if (upper.includes("LOW")) return "LOW";
+      }
+      return val;
+    }, RiskLevelEnum)
+    .describe("Risk level: LOW-CRITICAL (exposed/sensitive)"),
+  notes: z
+    .string()
+    .optional()
+    .describe("Additional notes or observations about the endpoint"),
+  pentestObjectives: z
+    .array(z.string())
+    .optional()
+    .describe(
+      "Flattened markdown strings — one per adversarial test objective — derived from the " +
+        "endpoint analysis. Each objective embeds title, hypothesis, prerequisites, setup, " +
+        "procedure, and success signal in a single block.",
+    ),
+  businessLogic: z
+    .string()
+    .optional()
+    .describe(
+      "Comprehensive business-logic model describing what the endpoint does, its actors, " +
+        "data flow, invariants, trust boundaries, and analysis gaps.",
+    ),
+  threatModel: z
+    .string()
+    .optional()
+    .describe(
+      "Comprehensive threat model grounded in the business logic, covering attacker profiles, " +
+        "attack vectors (with entry points, mechanisms, signals, likelihood, and impact), and " +
+        "risk assessment.",
+    ),
+});
+
+/**
+ * Schema for document_endpoint record (includes metadata added during documentation)
+ */
+export const DocumentedEndpointRecordSchema = DocumentEndpointSchema.extend({
+  discoveredAt: z
+    .string()
+    .describe("ISO timestamp when endpoint was discovered"),
+  sessionId: z.string().describe("Session ID where endpoint was discovered"),
+  target: z.string().describe("Target being analyzed when endpoint was found"),
+  riskScore: RiskScoreSchema.optional().describe(
+    "Computed risk score with breakdown",
+  ),
+});
+
+// Type exports
+export type AppType = z.infer<typeof AppTypeEnum>;
+export type EndpointType = z.infer<typeof EndpointTypeEnum>;
+export type RiskLevel = z.infer<typeof RiskLevelEnum>;
+export type DocumentAppInput = z.infer<typeof DocumentAppSchema>;
+export type DocumentedAppRecord = z.infer<typeof DocumentedAppRecordSchema>;
+export type DocumentEndpointInput = z.infer<typeof DocumentEndpointSchema>;
+export type DocumentedEndpointRecord = z.infer<
+  typeof DocumentedEndpointRecordSchema
+>;
+export type PentestTarget = z.infer<typeof PentestTargetSchema>;
+export type AttackSurfaceSummary = z.infer<typeof AttackSurfaceSummarySchema>;
+export type AttackSurfaceReport = z.infer<typeof AttackSurfaceReportSchema>;