@pensar/apex 2.5.0 → 2.6.1-canary.025b1ecf

package/build/lib/core/agents/specialized/findingJudge/agent.js

@@ -0,0 +1,224 @@
+import"../../../../chunk-7gjdygcx.js";
+import"../../../../chunk-kfvq4m1s.js";
+import"../../../../chunk-jdjagvgr.js";
+import"../../../../chunk-2njv7wz3.js";
+import"../../../../chunk-sgd2126b.js";
+import"../../../../chunk-8vhr65w3.js";
+import"../../../../chunk-cx7yrzh1.js";
+import"../../../../chunk-fy3bbbqy.js";
+import"../../../../chunk-mv74mq5n.js";
+import"../../../../chunk-c2b0hxs7.js";
+import"../../../../chunk-b8eq85d2.js";
+import"../../../../chunk-8d8w07a9.js";
+import"../../../../chunk-ve7m90fb.js";
+import"../../../../chunk-t5bt5vn1.js";
+import"../../../../chunk-gdrv2h1p.js";
+import"../../../../chunk-eb4h4k1f.js";
+import"../../../../chunk-vx228eeq.js";
+import"../../../../chunk-bx94rwt5.js";
+import"../../../../chunk-ja7j565c.js";
+import"../../../../chunk-3q89v4xv.js";
+import"../../../../chunk-zrbqn62x.js";
+import"../../../../chunk-q5e23acz.js";
+import {
+  AgentRuntime,
+  defineAgent
+} from "../../../../chunk-4p2n69vn.js";
+
+// src/core/agents/specialized/findingJudge/agent.ts
+import { stepCountIs } from "ai";
+
+// src/core/agents/specialized/findingJudge/prompts.ts
+var MAX_POC_SCRIPT_CHARS = 12000;
+var MAX_OUTPUT_CHARS = 16000;
+var MAX_EVIDENCE_CHARS = 8000;
+var MAX_DESCRIPTION_CHARS = 4000;
+function truncate(value, limit) {
+  if (value.length <= limit)
+    return value;
+  return `${value.substring(0, limit)}
+... [truncated]`;
+}
+var FINDING_JUDGE_SYSTEM_PROMPT = `You are a security finding validation specialist running as an agentic verifier inside an automated penetration testing pipeline.
+
+You are the last line of defense against false positives, hallucinated findings, fabricated evidence, and overstated impact. Your job is to independently verify whether a submitted proof-of-concept and its output support the claimed finding.
+
+## Operating Rules
+
+- Use tools before accepting a finding. At minimum, rerun or inspect the PoC with execute_command, compare behavior with http_request, read saved artifacts, or research the relevant technology with web_search/get_page.
+- Stay in scope. Only interact with the target endpoint/host and artifacts from this session.
+- Do not create, edit, delete, or document findings. You only validate and call the response tool.
+- Do not run destructive payloads or broaden exploitation. Verification should be enough to confirm or refute the claim.
+- Distinguish "the PoC exited 0" from "the vulnerability is proven." A successful exit code is only supporting evidence.
+- If your investigation completes and the evidence does not support the claim, reject it with actionable concerns.
+- If tools fail or the environment blocks verification, report the limitation honestly in your response. Infrastructure failure fallback is handled by the caller, not by you.
+- Cite concrete observations from tool output, HTTP responses, or web research in reasoning, concerns, and toolEvidence.
+
+## Evaluation Criteria
+
+### Materiality
+- A finding is a vulnerability only when the observed behavior is exploitable now in a way that creates a concrete security risk for the assessed target and threat model.
+- Do not reward theoretical "missing control" findings unless the PoC shows a realistic abuse path, affected security boundary, and material consequence.
+- Evaluate behavior in context: application purpose, deployment model, data sensitivity, exposed trust boundaries, and whether the observed behavior is intended for that environment. Expected, documented, demo, sandbox, or training behavior is usually expected-behavior or informational unless the claim demonstrates impact outside that intended use.
+- Reject CVSS 0.0 findings rather than downgrading them. A non-zero LOW severity can still be valid when the PoC demonstrates real exploitability and security risk.
+- If a PoC only proves that input is accepted, an error is returned, a public endpoint is reachable, or a control is absent, reject when it does not show an exploitable security risk.
+
+### Correctness
+- SQL injection: output should show inaccessible data, query errors, or behavioral differences indicating injection success.
+- XSS: output should show payload reflection/execution in a browser-executable context.
+- Command injection / RCE: output should show execution on the target system, not only local command execution.
+- SSRF: output should show responses from internal or otherwise protected services.
+- Path traversal: output should show file contents outside the intended path.
+- IDOR: output should show access to another user's/account's resource while authentication exists.
+- Authorization / access-control boundary bypass (RSC/prefetch/redirect-body leaks, missing per-route checks): the evidence must establish the access-model delta — which identity/role was used, and proof that the returned data is genuinely out of scope for that identity (cross-tenant, another user's, or admin-only data a member should not see). A 200 response, a leaked RSC payload, or a skipped redirect alone does NOT prove sensitive exposure. If the bypass is real but the returned data is non-sensitive or plausibly same-tenant/expected-visible, classify as a valid lower-impact finding and require the claim's impact/severity to match — do NOT accept it as high-confidence sensitive/cross-tenant exposure.
+- Authentication bypass: output should show protected access without valid credentials.
+- Email/HTML injection: ideally verify delivery and rendering. If only server acceptance is shown, confidence must stay below 0.7 and limitations must state rendering was not independently verified.
+- Missing rate limiting / anti-automation: a modest burst (~20 requests) with no observed throttling, delays, or 429s is sufficient to demonstrate the gap. For endpoints with real-world side effects (sending email/SMS/push, creating tickets/notifications, contact/support/feedback forms, payments), as few as 2–3 attempts plus the observed response is sufficient — do NOT require volume-testing that would spam real recipients. Evidence must state exact request count, timing/distribution, and observed statuses.
+
+### Common Low-Signal Patterns
+Reject these unless the submitted evidence demonstrates concrete harm:
+- Missing rate limiting on non-sensitive, low-value, intentionally public, or low-abuse-potential endpoints.
+- Verbose errors, stack traces, framework versions, or internal paths without secrets, protected data, or a working exploit chain.
+- Missing input validation that only permits nulls, empty strings, negative values, long text, type coercion, or malformed JSON with no security boundary crossed.
+- Missing authentication on public, non-sensitive, catalog, status, listener, metadata, demo, or intentionally unauthenticated endpoints.
+- Client-side validation bypasses where direct API calls produce no server-side security impact.
+- User enumeration, timing differences, weak pseudonymization, and email masking weaknesses without credible account takeover, sensitive data exposure, or targeting impact.
+- Unhandled type errors, method confusion, and 500 responses that only prove fragile error handling.
+
+### Hallucination and Hardcoding
+Reject or lower confidence when:
+- The script prints "evidence" with echo/print/console.log that was never received from the target.
+- The script constructs fake HTTP responses or error messages.
+- The success condition is hardcoded or independent of target response content.
+- The script always exits 0.
+- Evidence text does not match live responses or the claimed endpoint.
+
+### Severity and Classification
+- Accept as vulnerability only when real target interaction demonstrates unintended, exploitable behavior that creates security risk.
+- Classify as informational when the observation is real but not currently exploitable or not security-impacting.
+- Classify as expected-behavior when the behavior is clearly by design.
+- Reject when the PoC fabricates evidence, does not demonstrate the claim, or the demonstrated impact fundamentally mismatches the finding.
+- Guard against overstated confidentiality impact: when the demonstrated result is weaker than the claimed impact (e.g. a boundary was bypassed but no sensitive/cross-tenant data was shown, or only an identifier's existence — not its contents — was proven), keep confidence below 0.7 and raise a concern that the impact/severity should be reduced to match the evidence.
+
+## Response Requirements
+
+Call the response tool exactly once. Include:
+- valid: true only when the finding should be persisted as an exploitable vulnerability. Use valid: false for informational, expected-behavior, CVSS 0.0, non-exploitable, or merely best-practice observations.
+- findingType: vulnerability, informational, or expected-behavior.
+- confidence: calibrated 0.0 to 1.0. Below 0.7 requires concerns.
+- reasoning: concise explanation grounded in concrete observations.
+- concerns: actionable concerns; empty only for valid high-confidence results.
+- verificationSteps: actions you performed.
+- toolEvidence: concrete observations from provided artifacts or tool outputs.
+- reproducedPoc: whether you reran or independently reproduced the PoC.
+- webResearchUsed: whether web research materially informed the judgment.
+- limitations: remaining gaps.`;
+function buildFindingJudgePrompt(input) {
+  const { pocScript, pocType, pocOutput, claim } = input;
+  return `# Finding Validation Request
+
+## Target
+
+**Target:** ${input.target || "Unknown"}
+**Claimed Endpoint:** ${claim.endpoint}
+**POC Path:** ${input.pocPath || "Not provided"}
+
+## Claimed Vulnerability
+
+**Title:** ${claim.title}
+**Vulnerability Class:** ${claim.vulnerabilityClass || "Unknown"}
+
+### Description
+${truncate(claim.description, MAX_DESCRIPTION_CHARS)}
+
+### Claimed Impact
+${truncate(claim.impact, MAX_DESCRIPTION_CHARS)}
+
+### Evidence Provided by Agent
+\`\`\`
+${truncate(claim.evidence, MAX_EVIDENCE_CHARS)}
+\`\`\`
+
+## Previously Executed POC (${pocType})
+
+\`\`\`${pocType === "javascript" ? "js" : pocType === "python" ? "python" : "bash"}
+${truncate(pocScript, MAX_POC_SCRIPT_CHARS)}
+\`\`\`
+
+## Previous POC Execution Output
+
+**Exit Code:** ${pocOutput.exitCode}
+
+### stdout
+\`\`\`
+${truncate(pocOutput.stdout || "(empty)", MAX_OUTPUT_CHARS)}
+\`\`\`
+
+### stderr
+\`\`\`
+${truncate(pocOutput.stderr || "(empty)", MAX_OUTPUT_CHARS / 2)}
+\`\`\`
+
+## Task
+
+Independently validate whether the submitted POC and observed behavior support the claimed finding. Use the available minimal tools to rerun or inspect the POC, compare live target behavior, read saved artifacts, or research public documentation/CVEs as needed.
+
+Do not document or mutate anything. When done, call response with your structured judgment.`;
+}
+
+// src/core/agents/specialized/findingJudge/types.ts
+import { z } from "zod";
+var FINDING_TYPES = [
+  "vulnerability",
+  "informational",
+  "expected-behavior"
+];
+var FindingJudgeOutputSchema = z.object({
+  valid: z.boolean().describe("Whether the POC demonstrates a currently exploitable vulnerability that should be persisted"),
+  findingType: z.enum(FINDING_TYPES).describe("Classification: 'vulnerability' for genuine security issues, 'informational' for low-risk observations worth noting, 'expected-behavior' for findings that describe intentional design decisions"),
+  confidence: z.number().min(0).max(1).describe("Confidence in the judgment, a decimal between 0.0 (no confidence) and 1.0 (certain)"),
+  reasoning: z.string().describe("Brief explanation of the key tool observations and analysis that led to this judgment"),
+  concerns: z.array(z.string()).describe("Specific concerns identified. Empty array only when the finding is a valid high-confidence vulnerability."),
+  verificationSteps: z.array(z.string()).describe("Concrete verification actions performed before deciding."),
+  toolEvidence: z.array(z.string()).describe("Specific observations from tool output or provided artifacts."),
+  reproducedPoc: z.boolean().describe("Whether the judge reran or independently reproduced the POC."),
+  webResearchUsed: z.boolean().describe("Whether web_search/get_page materially informed the judgment."),
+  limitations: z.array(z.string()).describe("Remaining verification gaps or environmental limitations.")
+});
+
+// src/core/agents/specialized/findingJudge/agent.ts
+var FINDING_JUDGE_ACTIVE_TOOLS = [
+  "execute_command",
+  "http_request",
+  "read_file",
+  "list_files",
+  "grep",
+  "web_search",
+  "get_page",
+  "response"
+];
+function resolveTarget(opts) {
+  return opts.finding.target ?? opts.target ?? opts.session.targets[0];
+}
+var findingJudgeDefinition = defineAgent({
+  name: "finding-judge",
+  role: "judge",
+  system: () => FINDING_JUDGE_SYSTEM_PROMPT,
+  activeTools: () => [...FINDING_JUDGE_ACTIVE_TOOLS],
+  responseSchema: () => FindingJudgeOutputSchema,
+  stopWhen: () => stepCountIs(60),
+  target: resolveTarget,
+  prompt: (opts) => buildFindingJudgePrompt({ ...opts.finding, target: resolveTarget(opts) }),
+  subagentId: (opts) => opts.subagentId ?? "finding-judge",
+  subagentName: (opts) => opts.subagentName ?? "Finding Judge"
+});
+
+class FindingJudgeAgent extends AgentRuntime {
+  constructor(opts) {
+    super(findingJudgeDefinition, opts);
+  }
+}
+export {
+  FindingJudgeAgent,
+  findingJudgeDefinition
+};

package/build/lib/core/agents/specialized/findingJudge/index.d.ts

@@ -0,0 +1,31 @@
+/**
+ * Finding Judge
+ *
+ * Agentic validation for submitted findings. The judge runs after the POC
+ * exits successfully and before persistence to catch hallucinated findings,
+ * hardcoded evidence, and mismatched claims.
+ */
+import type { AIModel } from "../../../ai";
+import type { ToolContext } from "../../offSecAgent/tools";
+import type { FindingJudgeInput, FindingJudgeResult } from "./types";
+export type { FindingJudgeAgentOutput, FindingJudgeInput, FindingJudgeResult, FindingType, } from "./types";
+export type FindingJudgeRuntimeContext = Pick<ToolContext, "session" | "authConfig" | "abortSignal" | "eventBus" | "sandbox" | "backends" | "target" | "enableThinking" | "thinkingEffort" | "openAIReasoningEffort" | "languageModelMiddleware" | "usageRecorder" | "streamIdFactory"> & {
+    model: AIModel;
+    /**
+     * Subagent id used to tag the judge's own stream events. Callers that
+     * spawn the judge as a nested subagent must pass the same id they
+     * emitted in the `subagent-spawn` lifecycle event so the live UI and
+     * persisted logs line up. Defaults to `"finding-judge"`.
+     */
+    subagentId?: string;
+    /** Human-readable label for readable OTel span names. Defaults to "Finding Judge". */
+    subagentName?: string;
+};
+/**
+ * Validate a vulnerability finding by running a bounded verifier agent.
+ *
+ * Infrastructure failures reject the finding as unverified rather than
+ * preserving it as a vulnerability.
+ */
+export declare function judgeFinding(input: FindingJudgeInput, ctx: FindingJudgeRuntimeContext): Promise<FindingJudgeResult>;
+export declare function createJudgeFailureResult(err: unknown, model: AIModel): FindingJudgeResult;

package/build/lib/core/agents/specialized/findingJudge/index.js

@@ -0,0 +1,13 @@
+import {
+  judgeFinding2,
+  createJudgeFailureResult2
+} from "../../../../chunk-0y40tebt.js";
+import"../../../../chunk-sgd2126b.js";
+import"../../../../chunk-8vhr65w3.js";
+import"../../../../chunk-2njv7wz3.js";
+import"../../../../chunk-jdjagvgr.js";
+import"../../../../chunk-kfvq4m1s.js";
+export {
+  createJudgeFailureResult2 as createJudgeFailureResult,
+  judgeFinding2 as judgeFinding
+};

package/build/lib/core/agents/specialized/findingJudge/prompts.d.ts

@@ -0,0 +1,3 @@
+import type { FindingJudgeInput } from "./types";
+export declare const FINDING_JUDGE_SYSTEM_PROMPT = "You are a security finding validation specialist running as an agentic verifier inside an automated penetration testing pipeline.\n\nYou are the last line of defense against false positives, hallucinated findings, fabricated evidence, and overstated impact. Your job is to independently verify whether a submitted proof-of-concept and its output support the claimed finding.\n\n## Operating Rules\n\n- Use tools before accepting a finding. At minimum, rerun or inspect the PoC with execute_command, compare behavior with http_request, read saved artifacts, or research the relevant technology with web_search/get_page.\n- Stay in scope. Only interact with the target endpoint/host and artifacts from this session.\n- Do not create, edit, delete, or document findings. You only validate and call the response tool.\n- Do not run destructive payloads or broaden exploitation. Verification should be enough to confirm or refute the claim.\n- Distinguish \"the PoC exited 0\" from \"the vulnerability is proven.\" A successful exit code is only supporting evidence.\n- If your investigation completes and the evidence does not support the claim, reject it with actionable concerns.\n- If tools fail or the environment blocks verification, report the limitation honestly in your response. Infrastructure failure fallback is handled by the caller, not by you.\n- Cite concrete observations from tool output, HTTP responses, or web research in reasoning, concerns, and toolEvidence.\n\n## Evaluation Criteria\n\n### Materiality\n- A finding is a vulnerability only when the observed behavior is exploitable now in a way that creates a concrete security risk for the assessed target and threat model.\n- Do not reward theoretical \"missing control\" findings unless the PoC shows a realistic abuse path, affected security boundary, and material consequence.\n- Evaluate behavior in context: application purpose, deployment model, data sensitivity, exposed trust boundaries, and whether the observed behavior is intended for that environment. Expected, documented, demo, sandbox, or training behavior is usually expected-behavior or informational unless the claim demonstrates impact outside that intended use.\n- Reject CVSS 0.0 findings rather than downgrading them. A non-zero LOW severity can still be valid when the PoC demonstrates real exploitability and security risk.\n- If a PoC only proves that input is accepted, an error is returned, a public endpoint is reachable, or a control is absent, reject when it does not show an exploitable security risk.\n\n### Correctness\n- SQL injection: output should show inaccessible data, query errors, or behavioral differences indicating injection success.\n- XSS: output should show payload reflection/execution in a browser-executable context.\n- Command injection / RCE: output should show execution on the target system, not only local command execution.\n- SSRF: output should show responses from internal or otherwise protected services.\n- Path traversal: output should show file contents outside the intended path.\n- IDOR: output should show access to another user's/account's resource while authentication exists.\n- Authorization / access-control boundary bypass (RSC/prefetch/redirect-body leaks, missing per-route checks): the evidence must establish the access-model delta \u2014 which identity/role was used, and proof that the returned data is genuinely out of scope for that identity (cross-tenant, another user's, or admin-only data a member should not see). A 200 response, a leaked RSC payload, or a skipped redirect alone does NOT prove sensitive exposure. If the bypass is real but the returned data is non-sensitive or plausibly same-tenant/expected-visible, classify as a valid lower-impact finding and require the claim's impact/severity to match \u2014 do NOT accept it as high-confidence sensitive/cross-tenant exposure.\n- Authentication bypass: output should show protected access without valid credentials.\n- Email/HTML injection: ideally verify delivery and rendering. If only server acceptance is shown, confidence must stay below 0.7 and limitations must state rendering was not independently verified.\n- Missing rate limiting / anti-automation: a modest burst (~20 requests) with no observed throttling, delays, or 429s is sufficient to demonstrate the gap. For endpoints with real-world side effects (sending email/SMS/push, creating tickets/notifications, contact/support/feedback forms, payments), as few as 2\u20133 attempts plus the observed response is sufficient \u2014 do NOT require volume-testing that would spam real recipients. Evidence must state exact request count, timing/distribution, and observed statuses.\n\n### Common Low-Signal Patterns\nReject these unless the submitted evidence demonstrates concrete harm:\n- Missing rate limiting on non-sensitive, low-value, intentionally public, or low-abuse-potential endpoints.\n- Verbose errors, stack traces, framework versions, or internal paths without secrets, protected data, or a working exploit chain.\n- Missing input validation that only permits nulls, empty strings, negative values, long text, type coercion, or malformed JSON with no security boundary crossed.\n- Missing authentication on public, non-sensitive, catalog, status, listener, metadata, demo, or intentionally unauthenticated endpoints.\n- Client-side validation bypasses where direct API calls produce no server-side security impact.\n- User enumeration, timing differences, weak pseudonymization, and email masking weaknesses without credible account takeover, sensitive data exposure, or targeting impact.\n- Unhandled type errors, method confusion, and 500 responses that only prove fragile error handling.\n\n### Hallucination and Hardcoding\nReject or lower confidence when:\n- The script prints \"evidence\" with echo/print/console.log that was never received from the target.\n- The script constructs fake HTTP responses or error messages.\n- The success condition is hardcoded or independent of target response content.\n- The script always exits 0.\n- Evidence text does not match live responses or the claimed endpoint.\n\n### Severity and Classification\n- Accept as vulnerability only when real target interaction demonstrates unintended, exploitable behavior that creates security risk.\n- Classify as informational when the observation is real but not currently exploitable or not security-impacting.\n- Classify as expected-behavior when the behavior is clearly by design.\n- Reject when the PoC fabricates evidence, does not demonstrate the claim, or the demonstrated impact fundamentally mismatches the finding.\n- Guard against overstated confidentiality impact: when the demonstrated result is weaker than the claimed impact (e.g. a boundary was bypassed but no sensitive/cross-tenant data was shown, or only an identifier's existence \u2014 not its contents \u2014 was proven), keep confidence below 0.7 and raise a concern that the impact/severity should be reduced to match the evidence.\n\n## Response Requirements\n\nCall the response tool exactly once. Include:\n- valid: true only when the finding should be persisted as an exploitable vulnerability. Use valid: false for informational, expected-behavior, CVSS 0.0, non-exploitable, or merely best-practice observations.\n- findingType: vulnerability, informational, or expected-behavior.\n- confidence: calibrated 0.0 to 1.0. Below 0.7 requires concerns.\n- reasoning: concise explanation grounded in concrete observations.\n- concerns: actionable concerns; empty only for valid high-confidence results.\n- verificationSteps: actions you performed.\n- toolEvidence: concrete observations from provided artifacts or tool outputs.\n- reproducedPoc: whether you reran or independently reproduced the PoC.\n- webResearchUsed: whether web research materially informed the judgment.\n- limitations: remaining gaps.";
+export declare function buildFindingJudgePrompt(input: FindingJudgeInput): string;

package/build/lib/core/agents/specialized/findingJudge/types.d.ts

@@ -0,0 +1,77 @@
+import { z } from "zod";
+export declare const FINDING_TYPES: readonly ["vulnerability", "informational", "expected-behavior"];
+export type FindingType = (typeof FINDING_TYPES)[number];
+export interface FindingJudgeInput {
+    /** The full POC script content */
+    pocScript: string;
+    /** Script language */
+    pocType: "bash" | "python" | "javascript";
+    /** Relative path to the persisted POC file, when available */
+    pocPath?: string;
+    /** Target URL/host being assessed */
+    target?: string;
+    /** POC execution output */
+    pocOutput: {
+        stdout: string;
+        stderr: string;
+        exitCode: number;
+    };
+    /** The vulnerability claim to validate against */
+    claim: {
+        title: string;
+        description: string;
+        impact: string;
+        evidence: string;
+        endpoint: string;
+        vulnerabilityClass?: string;
+    };
+}
+interface FindingJudgeVerificationDetails {
+    /** Concrete actions the judge took before deciding */
+    verificationSteps?: string[];
+    /** Specific observations from tools or provided artifacts */
+    toolEvidence?: string[];
+    /** Whether the judge independently reran or otherwise reproduced the POC */
+    reproducedPoc?: boolean;
+    /** Whether public web research influenced the decision */
+    webResearchUsed?: boolean;
+    /** Known gaps in verification */
+    limitations?: string[];
+}
+export interface FindingJudgeResult extends FindingJudgeVerificationDetails {
+    /** Whether the finding should be persisted as an exploitable vulnerability */
+    valid: boolean;
+    /** Classification of the finding */
+    findingType: FindingType;
+    /** Confidence in the judgment (0.0-1.0) */
+    confidence: number;
+    /** Explanation of the judgment */
+    reasoning: string;
+    /** Specific concerns identified (empty if valid) */
+    concerns: string[];
+    /** Present when the judge fell back due to an error — contains diagnostics */
+    error?: {
+        message: string;
+        type: string;
+        model: string;
+        stack?: string;
+    };
+}
+export declare const FindingJudgeOutputSchema: z.ZodObject<{
+    valid: z.ZodBoolean;
+    findingType: z.ZodEnum<{
+        informational: "informational";
+        vulnerability: "vulnerability";
+        "expected-behavior": "expected-behavior";
+    }>;
+    confidence: z.ZodNumber;
+    reasoning: z.ZodString;
+    concerns: z.ZodArray<z.ZodString>;
+    verificationSteps: z.ZodArray<z.ZodString>;
+    toolEvidence: z.ZodArray<z.ZodString>;
+    reproducedPoc: z.ZodBoolean;
+    webResearchUsed: z.ZodBoolean;
+    limitations: z.ZodArray<z.ZodString>;
+}, z.core.$strip>;
+export type FindingJudgeAgentOutput = z.infer<typeof FindingJudgeOutputSchema>;
+export {};

package/build/lib/core/agents/specialized/googleSignInPrompt.d.ts

@@ -0,0 +1,4 @@
+import type { BrowserEngine } from "../offSecAgent/tools/playwrightMcp";
+export type { BrowserEngine };
+export declare const GOOGLE_SIGNIN_PROMPT_GUIDANCE = "## Sign in with Google\n\nWhen a credential is marked Sign-in: Google:\n1. Open the credential's Login URL on the target. Click the target's Google / Sign in with Google button. Do NOT fill the target's native username or password form.\n2. On accounts.google.com, snapshot, then `browser_fill` the identifier (email) with `credentialId` + `credentialField=\"username\"`. Continue, then fill the password with `credentialId` + `credentialField=\"password\"`. Never type a password or employee ID into the prompt or into `execute_command`.\n3. If Google asks to verify the account, fill **Google employee ID** with `credentialId` + `credentialField=\"Google employee ID\"` (the name is in Additional secret fields).\n4. Fail closed: if Google shows \"this browser or app may not be secure\", a CAPTCHA, or a blocked-app interstitial, call `complete_authentication` with success=false and name the barrier. Do not try account recovery, password reset, or a different browser profile.\n5. After Google returns to the target, snapshot to confirm the session, then `complete_authentication` as usual.";
+export declare function browserEngineForGoogleSignIn(hasGoogleSignIn: boolean): BrowserEngine;

package/build/lib/core/agents/specialized/mobileOtpPrompt.d.ts

@@ -0,0 +1 @@
+export declare const MOBILE_OTP_PROMPT_GUIDANCE = "## Mobile OTP credentials\n\nRead each credential's `Authentication method` before starting:\n- `sms-passwordless`: `phoneNumber` is the login identifier, not MFA after a password. Reserve immediately before filling that field, then request the code.\n- `sms-mfa`: fill username and password first. If submitting the password triggers the SMS code, reserve immediately before submitting. If it reveals a separate send-code action, reserve immediately before that action. Fill a destination phone field only if the target asks, using `credentialId` + `credentialField=\"phoneNumber\"`.\n\nNever ask for, write, log, or pass a public phone number. Reserve with `sms_list_messages` and `reserve=true`; the Console chooses the shared number. A 429 means that number is busy: do not wait or poll inside the tool. Make at most two separate reservation attempts (with an `execute_command` sleep between them), then report the authentication block.\n\nAt the action that sends the code, record `Date.now()` as `sinceMs`. Run `execute_command` `sleep 5`, then call `sms_list_messages` with `sinceMs` and `claim=true`. If no message arrives, make one delayed list retry; otherwise report the result rather than waiting indefinitely. Fill the claimed OTP and continue. Do not report `phone_verification` as a barrier for either Mobile OTP flow. TOTP via an environment variable is unchanged.";

package/build/lib/core/agents/specialized/patching/agent.d.ts

@@ -0,0 +1,64 @@
+import { AgentRuntime } from "../../agentRuntime";
+import { type PatchingAgentInput, type PatchResult } from "./types";
+/**
+ * Tools available to the autonomous patching agent.
+ * Mirrors a Cursor / Claude Code coding loop: explore, research, todo,
+ * multi-file edit, git self-check, verify, structured finalize.
+ */
+export declare const PATCHING_ACTIVE_TOOLS: readonly ["read_file", "list_files", "glob", "grep", "profile_codebase", "run_code_query", "web_search", "get_page", "create_task", "update_task", "list_tasks", "create_file", "update_file", "delete_file", "apply_patch", "git_status", "git_diff", "execute_command", "response"];
+/**
+ * Try to read an AGENTS.md (or similar) file from the repository root.
+ * Returns the file content or undefined if none is found.
+ */
+export declare function readAgentsMd(cwd: string): string | undefined;
+/**
+ * Resolve the project instructions for a patching run.
+ *
+ * Sandbox runs must not import host-side files: the agent reads the repo's own
+ * instructions from the actual runtime via read_file instead.
+ */
+export declare function resolvePatchingAgentsMd(cwd: string, sandboxed: boolean): string | undefined;
+/**
+ * A security patching agent that analyzes vulnerabilities and applies fixes.
+ *
+ * Uses filesystem tools to read, search, and modify code directly, and
+ * `execute_command` to run lint, type-check, and test suites for verification.
+ *
+ * When an optional `sandbox` is provided, tools like `execute_command`,
+ * `create_file`, and `update_file` automatically route operations through
+ * the sandbox instead of the local filesystem, and project instructions are
+ * read from the runtime rather than the host.
+ *
+ * The repository (`cwd`) is the agent's working directory: commands start
+ * there and relative file-tool paths resolve against it — not against the
+ * session root.
+ *
+ * Returns a structured {@link PatchResult} with the list of changed files,
+ * PR title, and PR description.
+ *
+ * @example
+ * ```ts
+ * const agent = new PatchingAgent({
+ *   cwd: "/tmp/cloned-repo",
+ *   vulnerability: { name: "SQL Injection", severity: "critical", description: "..." },
+ *   model: "claude-sonnet-4-20250514",
+ *   session,
+ *   sandbox, // optional — tools route through sandbox when provided
+ * });
+ *
+ * const result = await agent.consume({
+ *   onTextDelta: (d) => process.stdout.write(d.text),
+ * });
+ * ```
+ */
+export declare const patchingAgentDefinition: import("../../defineAgent").AgentDefinition<PatchingAgentInput, {
+    filesChanged: {
+        filePath: string;
+        changesDescription: string;
+    }[];
+    prTitle: string;
+    prDescription: string;
+}, void>;
+export declare class PatchingAgent extends AgentRuntime<PatchingAgentInput, PatchResult> {
+    constructor(opts: PatchingAgentInput);
+}

package/build/lib/core/agents/specialized/patching/index.d.ts

@@ -0,0 +1,4 @@
+export { PATCHING_ACTIVE_TOOLS, PatchingAgent, readAgentsMd, } from "./agent";
+export { buildPatchingPrompt, buildSystemPrompt, PATCHING_SYSTEM_PROMPT, PROJECT_INSTRUCTIONS_TAG, } from "./prompts";
+export type { PatchingAgentInput, PatchResult, VulnerabilityDetails, } from "./types";
+export { PatchResultSchema } from "./types";

package/build/lib/core/agents/specialized/patching/index.js

@@ -0,0 +1,44 @@
+import"../../../../chunk-8dqz8cwa.js";
+import {
+  buildSystemPrompt2,
+  PATCHING_SYSTEM_PROMPT2,
+  PROJECT_INSTRUCTIONS_TAG2,
+  buildPatchingPrompt2,
+  PatchResultSchema2,
+  PATCHING_ACTIVE_TOOLS2,
+  readAgentsMd2,
+  PatchingAgent2
+} from "../../../../chunk-a3gxgj9r.js";
+import"../../../../chunk-4p2n69vn.js";
+import"../../../../chunk-cx7yrzh1.js";
+import"../../../../chunk-ve7m90fb.js";
+import"../../../../chunk-c2b0hxs7.js";
+import"../../../../chunk-7gjdygcx.js";
+import"../../../../chunk-b8eq85d2.js";
+import"../../../../chunk-gdrv2h1p.js";
+import"../../../../chunk-ja7j565c.js";
+import"../../../../chunk-3q89v4xv.js";
+import"../../../../chunk-fy3bbbqy.js";
+import"../../../../chunk-8d8w07a9.js";
+import"../../../../chunk-t5bt5vn1.js";
+import"../../../../chunk-eb4h4k1f.js";
+import"../../../../chunk-vx228eeq.js";
+import"../../../../chunk-sgd2126b.js";
+import"../../../../chunk-8vhr65w3.js";
+import"../../../../chunk-2njv7wz3.js";
+import"../../../../chunk-jdjagvgr.js";
+import"../../../../chunk-kfvq4m1s.js";
+import"../../../../chunk-zrbqn62x.js";
+import"../../../../chunk-mv74mq5n.js";
+import"../../../../chunk-q5e23acz.js";
+import"../../../../chunk-bx94rwt5.js";
+export {
+  PATCHING_ACTIVE_TOOLS2 as PATCHING_ACTIVE_TOOLS,
+  PATCHING_SYSTEM_PROMPT2 as PATCHING_SYSTEM_PROMPT,
+  PROJECT_INSTRUCTIONS_TAG2 as PROJECT_INSTRUCTIONS_TAG,
+  PatchResultSchema2 as PatchResultSchema,
+  PatchingAgent2 as PatchingAgent,
+  buildPatchingPrompt2 as buildPatchingPrompt,
+  buildSystemPrompt2 as buildSystemPrompt,
+  readAgentsMd2 as readAgentsMd
+};

package/build/lib/core/agents/specialized/patching/prompts.d.ts

@@ -0,0 +1,17 @@
+import type { VulnerabilityDetails } from "./types";
+/**
+ * Build the patching agent system prompt.
+ */
+export declare function buildSystemPrompt(): string;
+export declare const PATCHING_SYSTEM_PROMPT: string;
+/** Delimiter tag wrapping the repository's own agent instructions file. */
+export declare const PROJECT_INSTRUCTIONS_TAG = "project_instructions";
+export interface BuildPatchingPromptOptions {
+    /**
+     * Sandbox mode: host-read instructions are unavailable, so emit guidance to
+     * read the repo's instructions file with native read_file from the actual
+     * runtime. Only used when `agentsMd` is not inlined.
+     */
+    runtimeInstructions?: boolean;
+}
+export declare function buildPatchingPrompt(vulnerability: VulnerabilityDetails, cwd: string, agentsMd?: string, opts?: BuildPatchingPromptOptions): string;

package/build/lib/core/agents/specialized/patching/types.d.ts

@@ -0,0 +1,40 @@
+import { z } from "zod";
+import type { SpecializedAgentInput } from "../../offSecAgent";
+/**
+ * Structured result returned by the patching agent via the `response` tool.
+ */
+export declare const PatchResultSchema: z.ZodObject<{
+    filesChanged: z.ZodArray<z.ZodObject<{
+        filePath: z.ZodString;
+        changesDescription: z.ZodString;
+    }, z.core.$strip>>;
+    prTitle: z.ZodString;
+    prDescription: z.ZodString;
+}, z.core.$strip>;
+export type PatchResult = z.infer<typeof PatchResultSchema>;
+/**
+ * Vulnerability details passed to the patching agent.
+ */
+export interface VulnerabilityDetails {
+    name: string;
+    severity: string;
+    description: string;
+    location?: string;
+    startLineNumber?: number | null;
+    endLineNumber?: number | null;
+    cweMapping?: string[];
+    dataflowAnalysis?: unknown;
+    poc?: {
+        fileName: string;
+        contents: string;
+    };
+}
+/**
+ * Input for the PatchingAgent constructor.
+ */
+export interface PatchingAgentInput extends SpecializedAgentInput {
+    /** Root path of the cloned repository */
+    cwd: string;
+    /** Vulnerability details to patch */
+    vulnerability: VulnerabilityDetails;
+}