@pensar/apex 2.1.3-canary.fff17bfd → 2.2.0

package/build/{cli-a1acedxf.js → cli-7e5ad5js.js}

@@ -1,15 +1,17 @@
 import {
+  EndpointTransportEnum,
+  GrpcEndpointMetadataSchema,
   OffensiveSecurityAgent
-} from "./cli-akhax3yn.js";
+} from "./cli-xbdn034b.js";
 import {
   hasToolCall,
   init_dist
-} from "./cli-v34r5t8t.js";
+} from "./cli-6kx46ck0.js";
 import {
   exports_external,
   init_zod,
   tool
-} from "./cli-29yqhrjq.js";
+} from "./cli-3k1x5rn3.js";
 
 // src/core/agents/specialized/whiteboxAttackSurface/agent.ts
 init_dist();
@@ -209,6 +211,7 @@ Your primary search tool. Use it to find route definitions, middleware, controll
 - **Always set \`routePath\`** to the HTTP route (e.g., \`/api/users\`). This is the URL path a client requests — NOT a source-file path.
 - **Always set \`file\`** to the source-code file (e.g., \`src/routes/users.ts\`). This is NOT the HTTP route.
 - **Always set \`handler\`** to the function name, and \`authRequired\` to indicate auth requirements.
+- **gRPC methods:** when an endpoint is a gRPC RPC rather than a plain HTTP route, set \`routePath\` to the wire path \`/package.Service/Method\`, set \`transport\` to \`"grpc"\` (or \`"grpc_web"\`/\`"connect"\`), and populate the \`grpc\` object (\`serviceFqn\`, \`method\`, \`streamingType\`). Carry these same \`transport\`/\`grpc\` fields into the matching endpoint entry in \`submit_results\` — without them the swarm tests the wire path as HTTP instead of running the gRPC methodology.
 
 Call these tools throughout your analysis as you discover apps and endpoints — don't wait until the end.
 
@@ -251,8 +254,9 @@ For each app you identified, spawn a coding agent with a detailed objective. The
    - Source-code file in \`file\` (e.g., \`src/routes/users.ts\`) — this is NOT the route
    - Line number in \`line\`
    - Auth requirement in \`authRequired\`
+   - For gRPC RPCs: \`transport\` (\`"grpc"\`/\`"grpc_web"\`/\`"connect"\`) and a \`grpc\` object (\`serviceFqn\`, \`method\`, \`streamingType\`), with \`routePath\` set to the wire path \`/package.Service/Method\`
 
-**IMPORTANT:** Tell each coding agent to set \`appName\` on every \`document_endpoint\` call so endpoints are organized by application.
+**IMPORTANT:** Tell each coding agent to set \`appName\` on every \`document_endpoint\` call so endpoints are organized by application. Preserve any \`transport\`/\`grpc\` fields the coding agents report on gRPC endpoints when you assemble the final \`submit_results\` payload — dropping them makes the swarm test gRPC wire paths as HTTP.
 
 ## Phase 3: COVERAGE DOUBLE-CHECK (do this yourself — DO NOT SKIP)
 
@@ -328,7 +332,9 @@ var EndpointSchema = exports_external.object({
   description: exports_external.string().optional().describe("Brief description of what this endpoint does"),
   pentestObjectives: exports_external.array(exports_external.string()).default([]).describe("Pentest objectives for this endpoint, derived from the threat model when available " + "(e.g. 'Test for IDOR by enumerating user IDs', 'Test for SQL injection in search parameter')"),
   riskScore: RiskScoreSchema.optional().describe("AI-calculated risk score for prioritizing pentest efforts"),
-  threatModel: exports_external.string().optional().describe("Endpoint-specific threat model describing attack vectors, data sensitivity, and testing priorities")
+  threatModel: exports_external.string().optional().describe("Endpoint-specific threat model describing attack vectors, data sensitivity, and testing priorities"),
+  transport: EndpointTransportEnum.optional().describe("Wire transport; 'grpc'/'grpc_web'/'connect' for gRPC methods, else http"),
+  grpc: GrpcEndpointMetadataSchema.optional().describe("gRPC service/method/streaming metadata when transport is a gRPC variant")
 });
 var AppSchema = exports_external.object({
   name: exports_external.string().describe("Application or service name"),
@@ -400,6 +406,7 @@ class WhiteboxAttackSurfaceAgent extends OffensiveSecurityAgent {
       attackSurfaceRegistry,
       domains,
       enableThinking,
+      thinkingEffort,
       openAIReasoningEffort
     } = opts;
     let capturedResult = null;
@@ -424,8 +431,10 @@ This ends the agent run — make sure all data is included.`,
       abortSignal,
       eventBus,
       subagentId,
+      subagentName: opts.subagentName,
       attackSurfaceRegistry,
       enableThinking,
+      thinkingEffort,
       openAIReasoningEffort,
       activeTools: [
         "read_file",
@@ -488,7 +497,7 @@ Analyze this codebase and produce a complete attack surface map:
 1. Identify the repo type and package manager
 2. Discover all apps/services
 3. Discover cloud resources and external infrastructure referenced in the code (S3 buckets, cloud storage, CDN origins, etc.) — document these as apps with the appropriate type
-4. For each app, find all web pages and API endpoints
+4. For each app, find all web pages and API endpoints (including gRPC methods — set \`transport\` and \`grpc\` on those endpoints so downstream testing uses the gRPC methodology instead of treating the wire path as HTTP)
 5. For each endpoint, generate pentest objectives
 6. **Before submitting**, perform the Phase 3 coverage double-check from the system prompt — re-scan workspace roots, framework configs, Dockerfiles, IaC, and CI/deploy configs for apps you may have missed on the first pass, and document any that were missed.
 

package/build/{cli-8qb62k90.js → cli-7n43wz82.js}

@@ -1,7 +1,7 @@
 import {
   getCurrentVersion,
   init_installation
-} from "./cli-f8tgnegf.js";
+} from "./cli-1f636vzd.js";
 import {
   __esm
 } from "./cli-8rxa073f.js";

package/build/{cli-fj04wady.js → cli-knqx15w6.js}

@@ -1,10 +1,10 @@
 import {
   OffensiveSecurityAgent
-} from "./cli-akhax3yn.js";
+} from "./cli-xbdn034b.js";
 import {
   init_dist,
   stepCountIs
-} from "./cli-v34r5t8t.js";
+} from "./cli-6kx46ck0.js";
 
 // src/core/agents/specialized/codeAgent/agent.ts
 init_dist();
@@ -79,6 +79,7 @@ class CodeAgent extends OffensiveSecurityAgent {
       attackSurfaceRegistry,
       excludeTools,
       enableThinking,
+      thinkingEffort,
       openAIReasoningEffort,
       projectThreatModel
     } = opts;
@@ -122,8 +123,10 @@ class CodeAgent extends OffensiveSecurityAgent {
       abortSignal,
       eventBus,
       subagentId,
+      subagentName: opts.subagentName,
       attackSurfaceRegistry,
       enableThinking,
+      thinkingEffort,
       openAIReasoningEffort,
       projectThreatModel,
       stopWhen: stopWhen ?? stepCountIs(1e4),

package/build/{cli-9wd7jy2s.js → cli-n114n8mk.js}

@@ -5,7 +5,7 @@ import {
   createReportErrorTool,
   isMemoryEnabled,
   readPlan
-} from "./cli-akhax3yn.js";
+} from "./cli-xbdn034b.js";
 import {
   createLogger,
   hasToolCall,
@@ -13,11 +13,11 @@ import {
   init_lazyLogger,
   init_structured,
   scopedLogger
-} from "./cli-v34r5t8t.js";
+} from "./cli-6kx46ck0.js";
 import {
   exports_external,
   init_zod
-} from "./cli-29yqhrjq.js";
+} from "./cli-3k1x5rn3.js";
 
 // src/core/agents/specialized/pentest/agent.ts
 init_dist();
@@ -37,6 +37,7 @@ var PentestResponseSchema = exports_external.object({
   findingsDocumented: exports_external.number().describe("Number of vulnerabilities documented via document_vulnerability"),
   objectivesCovered: exports_external.array(exports_external.string()).describe("Which objectives were tested"),
   objectiveResults: exports_external.array(ObjectiveResultSchema).describe("Status of each objective: mark as completed if thoroughly tested (vulnerability confirmed and documented, OR conclusively not vulnerable), or incomplete if further testing is warranted. Include new objectives discovered during testing that should be added for future runs."),
+  newObjectives: exports_external.array(exports_external.string()).optional().describe("Objectives for the NEXT run of this endpoint. Populate this directly from everything you observed: worker outcomes, what was confirmed or conclusively ruled out, recon anomalies nobody investigated, and the technology you fingerprinted. Each entry must be a focused, self-contained objective the next run can act on directly — name a concrete attack class against a concrete parameter, header, or flow. Do NOT restate anything tested this run or already marked completed in your assignment context; find the coverage gaps. Emit a small, high-signal set (typically 2-6), preferring breadth across distinct untested attack classes over payload variants. Empty/omitted when the endpoint is genuinely exhausted."),
   noFindingsReason: exports_external.string().optional().describe("If no findings were documented, explain why (e.g., target not vulnerable, endpoint unreachable)")
 });
 
@@ -45,6 +46,7 @@ class TargetedPentestAgent extends OffensiveSecurityAgent {
     const {
       model,
       target,
+      grpc,
       objectives,
       session,
       authConfig,
@@ -58,7 +60,9 @@ class TargetedPentestAgent extends OffensiveSecurityAgent {
       messages,
       context,
       environmentVariables,
+      secretValues,
       enableThinking,
+      thinkingEffort,
       openAIReasoningEffort,
       role = "orchestrator",
       browserSession,
@@ -67,21 +71,25 @@ class TargetedPentestAgent extends OffensiveSecurityAgent {
     let reportedError = null;
     super({
       system: buildPentestSystemPrompt(session, role),
-      prompt: buildPentestPrompt(target, objectives, session, findingsRegistry, context, environmentVariables ? Object.keys(environmentVariables) : undefined, subagentId, role),
+      prompt: buildPentestPrompt(target, objectives, session, findingsRegistry, context, environmentVariables ? Object.keys(environmentVariables) : undefined, subagentId, role, session.credentialManager?.formatForPrompt(), grpc),
       model,
       session,
       target,
+      grpc,
       authConfig,
       onStepFinish,
       onCacheMetrics,
       abortSignal,
       eventBus,
       subagentId,
+      subagentName: opts.subagentName,
       sandbox,
       findingsRegistry,
       messages,
       environmentVariables,
+      secretValues,
       enableThinking,
+      thinkingEffort,
       openAIReasoningEffort,
       browserSession,
       display,
@@ -98,6 +106,7 @@ class TargetedPentestAgent extends OffensiveSecurityAgent {
           throw new PentestReportedError(reportedError);
         }
         let objectiveResults;
+        let newObjectives;
         try {
           const response = await streamResult.response;
           for (const msg of response.messages ?? []) {
@@ -106,8 +115,11 @@ class TargetedPentestAgent extends OffensiveSecurityAgent {
             for (const part of msg.content) {
               if (part.type === "tool-call" && part.toolName === "response" && part.input) {
                 const input = part.input;
-                if (input.response?.objectiveResults) {
-                  objectiveResults = input.response.objectiveResults;
+                if (input.result?.objectiveResults) {
+                  objectiveResults = input.result.objectiveResults;
+                }
+                if (input.result?.newObjectives) {
+                  newObjectives = input.result.newObjectives;
                 }
               }
             }
@@ -118,7 +130,8 @@ class TargetedPentestAgent extends OffensiveSecurityAgent {
           findings,
           findingsPath: session.findingsPath,
           pocsPath: session.pocsPath,
-          objectiveResults
+          objectiveResults,
+          newObjectives
         };
       }
     });
@@ -164,6 +177,7 @@ var SECTION_POC_PORTABILITY = `POC Script Portability Requirements:
 - Prefer built-in shell features over external commands when possible
 - If a PoC requires a specific non-standard tool, check for it at the start and exit with a clear error message if missing`;
 var SECTION_BROWSER_INTERACTION = `Browser Interaction:
+- Lean on the browser for testing wherever it applies. For anything interactive, stateful, client-side, or auth-gated — login flows, multi-step forms, SPA/JavaScript-driven behavior, DOM-based XSS, CSRF, and any page that only behaves correctly with a rendered, logged-in session — drive the test through the browser (browser_navigate / browser_click / browser_fill / browser_snapshot) rather than raw requests. The browser preserves your authenticated session and executes client-side logic that http_request / curl cannot see. Fall back to http_request / execute_command (curl) for stateless API-level checks, header inspection, and high-volume payload fuzzing.
 - Use browser_navigate to load pages, browser_snapshot to inspect the DOM, and browser_screenshot for visual evidence
 - Use browser_click and browser_fill to interact with forms, buttons, and input fields — essential for testing login flows, search fields, and other interactive elements
 - Screenshot liberally so the user can follow along. Whenever you are driving a browser, treat screenshots as the primary way the user watches your work. Err heavily on the side of more screenshots rather than fewer.
@@ -175,12 +189,24 @@ var SECTION_BROWSER_INTERACTION = `Browser Interaction:
 - Screenshots are cheap — prefer taking one and not needing it over skipping one and losing visibility. Do NOT attempt to conserve tokens by skipping screenshots during browser-driven testing.
 - Screenshots are automatically stored and displayed alongside your tool call logs, so each one directly improves the user's ability to follow the test in real time.`;
 var SECTION_AUTHENTICATION = `Authentication:
-- If the prompt includes an "Existing Authentication Session" section, USE those cookies/headers on every request and do NOT re-authenticate. If such a request returns 401/403, that provided session has expired — note it in your findings (and call report_error if it blocks all further testing). Do NOT try to log in yourself: this run was given a session rather than interactive credentials.
-- Otherwise, if the target requires authentication, log in yourself: drive the login flow in the browser with browser_navigate + browser_fill. Prefer credentialId + credentialField so secrets are resolved securely; injected credential environment variables are also available inside execute_command.
-- After a successful browser login, call browser_get_cookies to extract the session cookies (including httpOnly ones) and reuse them for raw requests — pass them as the Cookie header to http_request, or as -H "Cookie: ..." / -b flags to execute_command (curl). Any worker you spawn automatically inherits a snapshot of your authenticated browser session.
+- If the prompt includes an "Existing Authentication Session" section, USE those cookies/headers on every request and do NOT re-authenticate up front. If such a request returns 401/403, that provided session has expired — note it in your findings (and call report_error if it blocks all further testing). Only log in yourself (following any "Available Credentials" instructions) if that provided session expires mid-run.
+- Otherwise, if the target requires authentication, log in yourself. When an "Available Credentials" section is present, follow the authentication instructions in each credential's Context exactly — use the method it describes (for example, a token/API exchange driven with execute_command or http_request) instead of defaulting to a browser login. Only fall back to driving the login flow in the browser with browser_navigate + browser_fill when the Context does not specify how to authenticate. Prefer credentialId + credentialField so secrets are resolved securely; injected credential environment variables are also available inside execute_command.
+- After a successful login, capture the resulting session credentials and reuse them for raw requests. For a browser login, call browser_get_cookies to extract the session cookies (including httpOnly ones) — pass them as the Cookie header to http_request, or as -H "Cookie: ..." / -b flags to execute_command (curl). Any worker you spawn automatically inherits a snapshot of your authenticated browser session.
 - For http_request: include the captured Cookie and any Authorization headers on every call. For execute_command (curl): include -H "Cookie: ..." and/or -H "Authorization: ..." flags.
-- If a request returns 401/403 after you logged in yourself, your captured session may have expired — re-authenticate in the browser and re-capture cookies.
-- If you cannot authenticate with the available credentials, or another runtime condition blocks all testing, call report_error with a clear, specific message instead of giving up silently or documenting a non-finding.`;
+- If a request returns 401/403 after you logged in yourself, your captured session may have expired — re-authenticate the same way you did originally and refresh your session cookies/tokens.
+- Do NOT spin your wheels on authentication. If you have followed the credential Context instructions and still cannot authenticate, do NOT try to work around it — do NOT register a new account, self-sign-up, or fabricate credentials to authenticate. Those are not the credentials under test and only pollute results. (Registering a throwaway account is acceptable only as a disposable *target* for destructive-flow POCs per the blast-radius rungs below — never as a substitute for authenticating as the credential under test.) Make at most a couple of genuine attempts, then call report_error with reason "authentication_failed" and a specific message describing exactly what you tried and how it failed.
+- If you cannot authenticate with the available credentials, or another runtime condition blocks all testing, call report_error with a clear, specific message instead of giving up silently or documenting a non-finding.
+- Build verifiable POCs, but bound the blast radius. Prove impact with the least-invasive action that still demonstrates the flaw, preferring earlier rungs:
+  1. Prove a broken-authorization / privileged-role / IDOR boundary with a READ, or with a benign, reversible write to a low-impact field (e.g. your own display name). That a privileged call is accepted against an object you should not be able to reach is usually the finding — prefer this over disabling security controls, changing quotas/limits, or mutating another user.
+  2. If a reversible state-changing write is the only convincing proof, capture the current value, make the change, capture evidence (response/screenshot), then immediately restore the original value — and prefer your own account or a throwaway account you registered for this test over a shared or provided account. Do NOT rely on end-of-run cleanup alone; a crash mid-run can strip it before it runs.
+  3. NEVER complete an irreversible or security-weakening mutation against a shared or provided account, against any other user's account reached via broken authorization / IDOR, or against an org- or tenant-wide security setting (e.g. disabling MFA for an entire team): overwriting/resetting, disabling, or otherwise weakening an MFA/TOTP device or any second factor / security control, consuming a single-use reset token, changing the account email, rotating the password, or deleting the account. This hard ban is not limited to the identity you authenticated as — an IDOR or org-level authz flaw does not make it acceptable to actually disable or weaken another user's or the whole team's protections; prove the boundary is crossed without completing the weakening step. Irreversible changes cannot be undone (you never hold the original TOTP secret to restore), and locking an account out, disabling protections for other users, or weakening an org-wide control invalidates or endangers the credentials for every other agent — even a "reversible" toggle like disabling MFA leaves the account or team exposed if a crash strips the restore step. Demonstrate reachability/authorization instead, or perform the destructive step only against a throwaway account you registered for this test.`;
+var SECTION_DESTRUCTIVE_ALLOWED = `Destructive Testing (AUTHORIZED):
+- The client has authorized destructive testing for this engagement. You MAY perform DB deletes/drops/truncates, API write-deletes (HTTP DELETE), and other destructive operations when they are necessary to prove impact.
+- Still prefer the least-invasive proof that convincingly demonstrates the flaw, and follow the blast-radius rungs in the Authentication section — authorization to be destructive is not license to be reckless with shared or provided accounts.`;
+var SECTION_DESTRUCTIVE_BLOCKED = `Destructive Testing (OUT OF SCOPE):
+- The client has NOT authorized destructive testing for this engagement. Destructive operations are BLOCKED at the tool boundary and will return an error, so do not attempt them — they only waste turns.
+- Blocked operations include: destructive SQL (DROP / TRUNCATE / DELETE FROM / ALTER … DROP), destructive NoSQL/cache operations (collection/database drops, deleteMany, FLUSHALL/FLUSHDB), API write-deletes (HTTP DELETE, or writes overriding to DELETE / targeting a delete/destroy/purge route), and catastrophic host operations (rm -rf of a root/home, mkfs, dd to a device, fork bombs, power-state changes).
+- Prove destructive-class flaws WITHOUT completing the destructive step: demonstrate that the authorization boundary is crossed (e.g. the DELETE endpoint accepts your request / returns a pre-flight that would delete) with a read or a benign, reversible action, and describe the impact rather than actually deleting or dropping data.`;
 var SECTION_CREDENTIAL_DISCOVERY = `Credential & Secret Discovery:
 - When you find exposed configuration in client-side code (JS bundles, HTML source, config files), distinguish between:
   - SENSITIVE SECRETS (API keys granting backend access, database credentials, JWT signing keys, private keys, service account tokens) — document as a HIGH/CRITICAL finding
@@ -418,16 +444,25 @@ ${SECTION_SECURITY_HEADERS_CORS}
 ${SECTION_FINDING_QUALITY}
 
 ${SECTION_STATE_CHECKPOINTING}`;
+function destructiveSection(allow) {
+  return allow ? SECTION_DESTRUCTIVE_ALLOWED : SECTION_DESTRUCTIVE_BLOCKED;
+}
 function buildPentestSystemPrompt(session, role = "orchestrator") {
+  const destructive = destructiveSection(session.config?.allowDestructiveActions);
   if (role === "orchestrator") {
-    return PENTEST_SYSTEM_PROMPT_ORCHESTRATOR;
+    return `${PENTEST_SYSTEM_PROMPT_ORCHESTRATOR}
+
+${destructive}`;
   }
   const taskDriven = session.config?.taskDriven ?? false;
   const exfilMode = session.config?.exfilMode ?? false;
   const base = taskDriven ? exfilMode ? PENTEST_SYSTEM_PROMPT_TASK_DRIVEN_EXFIL : PENTEST_SYSTEM_PROMPT_TASK_DRIVEN : exfilMode ? PENTEST_SYSTEM_PROMPT_EXFIL : PENTEST_SYSTEM_PROMPT_BASE;
-  return session.config?.promptInjectionLibrarySource ? `${base}
+  const withDestructive = `${base}
+
+${destructive}`;
+  return session.config?.promptInjectionLibrarySource ? `${withDestructive}
 
-${SECTION_PROMPT_INJECTION}` : base;
+${SECTION_PROMPT_INJECTION}` : withDestructive;
 }
 var SECTION_ORCHESTRATOR_DELEGATION = `Sub-Agent Delegation Rules:
 - You DO NOT call document_vulnerability directly. Findings are documented by the workers you spawn.
@@ -450,14 +485,20 @@ ${SECTION_SOURCE_CODE_PROHIBITION}
 Your methodology:
 1. ORIENT — Call list_memories to review any existing knowledge from previous engagements (target-specific notes, successful techniques, false positive patterns, technology context). Use what you find to shape your plan.
 2. PLAN — State the objectives you have been given and outline your high-level orchestration plan in plain text BEFORE any tool calls. For each objective, briefly state what attack class the worker should focus on (e.g. "Objective 1 → SQL injection, focus on /api/users id parameter"). Output this plan as a text message — not as a tool call.
-3. RECON — Perform LIGHT initial reconnaissance to confirm the target is reachable and understand baseline behavior. Use http_request for a handful of probes, browser_navigate + browser_snapshot to see the surface, and execute_command sparingly. Do NOT begin exploitation here — that is the workers' job. Note any anomalies (unusual error responses, exposed headers, framework fingerprints, surprising endpoint behavior) for the final exploratory worker.
+3. RECON & AUTHENTICATE — Perform LIGHT initial reconnaissance to confirm the target is reachable and understand baseline behavior. Use http_request for a handful of probes, browser_navigate + browser_snapshot to see the surface, and execute_command sparingly. Do NOT begin exploitation here — that is the workers' job. Note any anomalies (unusual error responses, exposed headers, framework fingerprints, surprising endpoint behavior) for the final exploratory worker.
+   - If authentication is required (an "Existing Authentication Session" section is absent and the target / objectives need a logged-in session), you MUST authenticate NOW, in YOUR browser, BEFORE any fan-out. Follow the "Available Credentials" instructions exactly — use the method each credential's Context describes (e.g. a token/API exchange via execute_command or http_request) rather than defaulting to a browser login; only drive the browser login flow (browser_navigate + browser_fill with credentialId/credentialField) when the Context does not specify how.
+   - VERIFY the session before fanning out: request a protected resource and confirm it does NOT return 401/403. Use browser_get_cookies to capture the session cookies for reuse in raw http_request / curl calls.
+   - Authenticating HERE (not in the workers) is critical: each worker you spawn inherits a snapshot of YOUR browser's authenticated cookies + localStorage at spawn time, so ONE successful login up front propagates to every worker. Do NOT instruct workers to re-authenticate.
+   - If you cannot authenticate and the objectives require it, call report_error with reason "authentication_failed" and a specific message BEFORE spawning any workers — do not fan out unauthenticated workers that will all fail, and do not report non-findings.
 4. FAN OUT — For EACH objective, call spawn_pentest_agent EXACTLY ONCE. Each spawn dispatches a focused worker that will perform the full PLAN → VERIFY → PREPARE → TEST → EXPLOIT → DOCUMENT loop on its objective. Workers write findings to the shared findings registry — you do NOT need to forward findings between them.
 5. CHAIN & EXPLORE — After all per-objective workers complete, call spawn_pentest_agent ONE FINAL TIME with a synthesized objective that:
    a. Summarizes what earlier workers confirmed or ruled out (so the exploratory worker doesn't re-do their work).
    b. Calls out any anomalies you noticed during recon that nobody investigated.
    c. Directs the worker to chain confirmed findings into higher-impact attack chains AND probe for additional vulnerabilities outside the original objective list (e.g. business logic flaws, race conditions, secondary injection points).
 6. LEARN — Use add_memory to persist reusable learnings from this engagement (target behaviors, effective techniques, false positive patterns, technology fingerprints).
-7. FINISH — Call the response tool with your final summary. Compile objectiveResults from what each worker reported: mark each objective as completed (vulnerability confirmed and documented by a worker, OR conclusively ruled out by a worker), or incomplete (worker failed or could not finish). Include any new objectives discovered by the exploratory worker.
+7. FINISH — Call the response tool with your final summary. Compile objectiveResults from what each worker reported: mark each objective as completed (vulnerability confirmed and documented by a worker, OR conclusively ruled out by a worker), or incomplete (worker failed or could not finish). Also populate newObjectives directly: using the coverage you just orchestrated (worker outcomes, what was confirmed or ruled out, recon anomalies nobody investigated, technology fingerprints), propose a small focused set of objectives for the NEXT run that are not already tested this run or marked completed in your context — so subsequent runs stay productive instead of re-testing finished work. Return an empty newObjectives array only when the endpoint is genuinely exhausted.
+
+Empty open-objective assignments: if your assignment lists ZERO open objectives to test (every objective in your context is already marked completed), skip the per-objective fan-out and the chain & explore worker, do LIGHT recon only, then go to FINISH and still populate newObjectives so the run produces fresh objectives for next time rather than wasting the run.
 
 ${SECTION_ORCHESTRATOR_DELEGATION}
 
@@ -468,7 +509,7 @@ ${SECTION_MATERIALITY_GUIDANCE}
 ${SECTION_BROWSER_INTERACTION}
 
 ${SECTION_STATE_CHECKPOINTING}`;
-function buildPentestPrompt(target, objectives, session, findingsRegistry, context, envVarNames, subagentId, role = "orchestrator") {
+function buildPentestPrompt(target, objectives, session, findingsRegistry, context, envVarNames, subagentId, role = "orchestrator", credentialContext, grpc) {
   const sessionRootPath = session.rootPath;
   const exfilMode = session.config?.exfilMode ?? false;
   const taskDriven = role === "orchestrator" ? false : session.config?.taskDriven ?? false;
@@ -587,13 +628,16 @@ Do NOT discover or enumerate other endpoints or services. Focus exclusively on t
 1. Call list_memories to review any prior knowledge relevant to this target or engagement.
 2. State the objectives and outline your orchestration plan in plain text BEFORE any tool calls — one bullet per objective, briefly naming the attack class each worker should focus on.
 3. Perform LIGHT initial recon (a handful of http_request probes, browser_navigate + browser_snapshot to see the surface). Do NOT begin exploitation here — that is the workers' job. Note any anomalies you observe for the final exploratory worker.
+   - AUTHENTICATE FIRST if the target/objectives need a logged-in session and no "Existing Authentication Session" is provided: log in ONCE in YOUR browser during this recon step, following the "Available Credentials" instructions exactly (prefer the credential Context's method; use credentialId/credentialField so secrets resolve securely). Verify the session with a protected request (expect NOT 401/403) and capture cookies via browser_get_cookies. Every worker inherits your authenticated browser snapshot, so do this BEFORE fan-out and do NOT have workers re-authenticate. If you cannot authenticate and the objectives require it, call report_error with reason "authentication_failed" instead of fanning out.
 4. Call spawn_pentest_agent EXACTLY ONCE PER OBJECTIVE. For every spawn:
    - Set \`target\` to the FULL URL from the assignment above (domain + endpoint path) — pass it through verbatim. Do not strip the path or rewrite the host. Workers do not perform endpoint discovery; they deeply test the path you hand them.
    - Pass the matching objective in the \`objectives\` array (a single-element array).
    - Use the \`context\` field to forward any recon insights specific to that objective. If your earlier browser actions left state the worker should know about (already logged in as X, certain modal already dismissed), call that out in \`context\` — each worker is seeded with a snapshot of YOUR browser's cookies and localStorage at the moment of the spawn call.
 5. After all per-objective workers complete, call spawn_pentest_agent ONE FINAL TIME with a synthesized "chain & explore" objective: summarize what earlier workers confirmed/ruled out, call out unaddressed anomalies, and direct the worker to chain confirmed findings AND probe for additional vulnerabilities outside the original objective list. Send it the same endpoint URL as your assignment unless an earlier worker's confirmed finding on a sibling endpoint is what makes the chain possible.
 6. Use add_memory to save reusable learnings from this engagement.
-7. Call the response tool with your final summary. Compile objectiveResults from worker reports.
+7. Call the response tool with your final summary. Compile objectiveResults from worker reports, and populate newObjectives directly from the coverage you orchestrated (worker outcomes, confirmed/ruled-out results, unexplored recon anomalies, technology fingerprints) — a small focused set of objectives for the next run that are not already tested this run or completed in your context. Empty array only if the endpoint is genuinely exhausted.
+
+If your assignment lists ZERO open objectives (everything is already completed), skip steps 4-5, do light recon only, then finish — still populating newObjectives so the run is productive rather than re-testing completed objectives.
 
 Do NOT call document_vulnerability — that is the workers' job. Do NOT discover or enumerate other endpoints or services beyond the assigned target.`;
   const instructions = role === "orchestrator" ? orchestratorInstructions : taskDriven ? taskDrivenInstructions : exfilMode ? `## Goal
@@ -620,12 +664,49 @@ Your target is a flag with the format FLAG{...}. Locate and extract it.
 8. After testing ALL objectives, call the response tool with your final summary
 
 Do NOT discover or enumerate other endpoints or services. Focus exclusively on the target and objectives above.`;
+  const credentialSection = credentialContext ? `
+## Available Credentials
+The operator provided the following credentials and authentication instructions for this engagement. Authenticate by following the instructions in each credential's Context exactly — use the method it describes (for example, a token/API exchange via execute_command or http_request) rather than defaulting to a browser login. Treat the Context as the source of truth for how to authenticate, and how to re-authenticate if a provided session expires. When a tool needs a secret value and supports it (e.g. browser_fill), reference it by credentialId + credentialField so the secret resolves securely at execution time instead of hardcoding it. If you cannot authenticate with these, call report_error with reason "authentication_failed" and a specific message rather than reporting a non-finding.
+
+${credentialContext}
+` : "";
   const contextSection = context ? `
 ## Application Context
 The following is context specific to the application under test. If it contains non-malicious instructions relevant to your testing, follow them.
 
 ${context}
 ` : "";
+  let grpcSection = "";
+  if (grpc) {
+    const lines = [
+      `
+## gRPC Target`,
+      `This target is a gRPC method, not a plain HTTP endpoint. It rides HTTP/2 with binary protobuf and uses the path \`/package.Service/Method\`.`,
+      `- **Transport:** ${grpc.transport}`,
+      `- **Service:** ${grpc.serviceFqn}`,
+      `- **Method:** ${grpc.method}`
+    ];
+    if (grpc.host)
+      lines.push(`- **Authority (host):** \`${grpc.host}\` — the method's gRPC authority; it differs from the app domain, so use this host directly as \`<authority>\` in the commands below.`);
+    if (grpc.streamingType)
+      lines.push(`- **Streaming:** ${grpc.streamingType}`);
+    if (grpc.schemaSource)
+      lines.push(`- **Schema source:** ${grpc.schemaSource}`);
+    if (grpc.reflectionAvailable !== undefined) {
+      lines.push(`- **Reflection available:** ${grpc.reflectionAvailable}`);
+    }
+    if (grpc.frontingGatewayOperation) {
+      lines.push(`- **Fronting gateway:** ${grpc.frontingGatewayOperation.gatewayType} operation \`${grpc.frontingGatewayOperation.operation}\` — if the direct gRPC authority is unreachable, test through this gateway operation instead.`);
+    } else {
+      lines.push(`- **Fronting gateway:** none — this method is reachable directly but is NOT exposed through the REST/GraphQL gateway. Treat it as a PRIME missing-authorization target: gateway-fronted methods usually get their authz enforced at the gateway, so a shadow method that bypasses the gateway may bypass that authz entirely.`);
+    }
+    lines.push(`
+### gRPC Test Battery (OWASP gRPC Security Cheat Sheet)`, `Use \`grpcurl\`, \`buf\`, and \`protoc\` via \`execute_command\`. Work through this battery for the method above:`, `1. **Schema recovery.** Try reflection first: \`grpcurl -plaintext <authority> list\` / \`describe <service>\`. If reflection is disabled, recover the schema from a \`.proto\` file or protoset (e.g. via \`buf\` or \`protoc\`) before giving up on schema-dependent tests.`, `2. **Transport/content-type fallback.** Native gRPC, grpc-web, and Connect use different content-types over the same or adjacent paths. If one transport looks dead, retry as grpc-web (\`application/grpc-web\`) and Connect (\`application/connect+...\` or JSON) before declaring the endpoint unreachable.`, `3. **Status-code oracle.** Treat gRPC status codes as signal, not noise: 16 UNAUTHENTICATED, 7 PERMISSION_DENIED, 3 INVALID_ARGUMENT, 12 UNIMPLEMENTED. A flip from UNAUTHENTICATED to a data response after adding/removing metadata is a finding.`, `4. **Missing auth per method.** Call the method with valid credentials/metadata, then again with none and with garbage metadata. A successful response without auth is a critical finding.`, `5. **BOLA / IDOR.** Manipulate ID fields inside the request message (account/user/resource IDs) to access another principal's data.`, `6. **Metadata trust.** Test whether the service trusts client-supplied metadata it shouldn't (e.g. \`x-user-id\`, forwarded auth headers) instead of deriving identity server-side.`, `7. **Non-canonical \`:path\` authz bypass.** If authz is enforced by a proxy matching on \`:path\`, try case variants, trailing slashes, or alternate casing of the service/method path to see if the gRPC path parsing bypasses it.`, `8. **Protobuf/message fuzzing.** Send malformed, truncated, and type-mismatched field values; unknown field numbers; and deeply nested/repeated fields to probe deserialization handling.`, `9. **Streaming IDOR.** For client/server/bidi streaming methods, probe whether a stream opened for one principal's resource can be redirected mid-stream to another's.`, `10. **Decompression / size DoS.** Send oversized or highly compressible payloads to check for missing message-size limits or decompression bombs.`, `11. **Transport security.** Confirm whether the channel is plaintext or TLS/mTLS-enforced; plaintext gRPC in production is a finding on its own.`, `
+If the method is unreachable from your network position (common for internal/in-cluster services), a finding is still valid via whitebox reasoning — schema plus routing/config evidence — even without an executed POC.`);
+    grpcSection = `${lines.join(`
+`)}
+`;
+  }
   const envVarSection = envVarNames && envVarNames.length > 0 ? `
 ## Environment Variables
 The following environment variables are pre-loaded in your shell and available in every \`execute_command\` call. Use them in scripts or commands (e.g. \`$${envVarNames[0]}\`) — do NOT hardcode their values.
@@ -636,7 +717,7 @@ ${envVarNames.map((n) => `- \`${n}\``).join(`
 
 ## Target
 - **URL:** ${target}
-${authSection}
+${grpcSection}${authSection}${credentialSection}
 ${knownFindingsSection}
 ${knowledgeBaseSection}
 ${planSection}${contextSection}${envVarSection}
@@ -697,4 +778,4 @@ function loadFindings(findingsPath) {
     }
   }).filter((f) => f !== null);
 }
-export { TargetedPentestAgent, buildPentestSystemPrompt, buildPentestPrompt, buildPentestActiveTools };
+export { PentestResponseSchema, TargetedPentestAgent, buildPentestSystemPrompt, buildPentestPrompt, buildPentestActiveTools };

package/build/{cli-9h847y2w.js → cli-ptzy9ak5.js}

@@ -1,11 +1,11 @@
 import {
   CweEntrySchema,
   ValidatedCweEntrySchema
-} from "./cli-akhax3yn.js";
+} from "./cli-xbdn034b.js";
 import {
   exports_external,
   init_zod
-} from "./cli-29yqhrjq.js";
+} from "./cli-3k1x5rn3.js";
 
 // src/core/agents/offSecAgent/types.ts
 init_zod();

package/build/{cli-g6cjpbr9.js → cli-s43t5ay0.js}

@@ -3,7 +3,7 @@ import {
   init_lazyLogger,
   init_structured,
   scopedLogger
-} from "./cli-v34r5t8t.js";
+} from "./cli-6kx46ck0.js";
 
 // src/core/agents/specialized/utils.ts
 import { execSync } from "node:child_process";