Arnica Agentic Pen Testing: Verify SAST Findings Without Losing Runtime Context

Arnica’s Agentic Pen Testing page describes turning SAST and reachability signals into attack hypotheses and runtime validation, with evidence returned for remediation. Its FAQ says the feature enters a controlled rollout to selected organizations on November 5, 2026. Treat access as a qualification question; a generic trial offer does not establish that this feature is enabled for every trial account.

The useful purchase question is narrower than “can AI pentest this application?” Ask whether the workflow can connect one specific source finding to the deployed code, reach the intended behavior under an approved identity, and show whether the hypothesized issue is actually present. A code warning, a reachable endpoint and an exploitable path are different pieces of evidence.

Confirm the deployment boundary before supplying access

إن current product page needs clarification on connectivity: the main copy describes testing without a VPN, while the onboarding FAQ describes VPN access to specified environments, subject to supported configurations. Do not resolve that difference by guessing. Ask the vendor which configuration applies to your account, where execution occurs, which destinations are reachable and how access is revoked.

Before starting a pilot, document the approved code source, running service, environment, identities and data-handling path. Confirm the setup through the approved onboarding process. Do not paste long-lived secrets into a hypothesis description or broaden network access just because a runtime check cannot reach its target. A product demonstration is not the access design for your environment.

Make one code finding testable

Choose a single existing SAST finding in an owned staging application. The engineer responsible for that service should explain the alleged source-to-sink path and identify the source revision, built artifact and deployed instance. Verify that the flagged path is included in that build. If the application has changed since scanning, update the association before interpreting a failed reproduction.

Prepare a harmless synthetic fixture for the disputed path. For example, a report-selection function might be flagged because user-controlled input reaches a sensitive read operation. The pilot should test the authorization or validation property through the intended application workflow, using evaluator-owned records. It should not require real customer files, database writes or payloads that execute commands or extract secrets.

Agree on the smallest evidence that would distinguish the outcomes. A harmless marker in a known protected record can establish which content was returned; an application request ID can associate the operation with the acting identity and deployed build. Define those controls before the tool produces a result so that an attractive report cannot move the acceptance threshold afterward.

Keep three validation outcomes separate

The following triage model is an editorial acceptance framework, not a statement that Arnica uses these exact interface labels. It prevents missing access or stale code from being mistaken for proof that a SAST warning is harmless.

Review the actual causal path. If an agent discovers a different issue while investigating the assigned warning, that may deserve separate triage, but it does not validate the original source finding. Likewise, a failure in an upstream gateway does not prove the application sink is safe. Preserve those distinctions in both ticket status and executive summaries.

Run a bounded source-to-runtime pilot

1. Freeze the association. Record the SAST finding ID, source revision, artifact identifier, deployment version and allowed runtime operation. The source owner confirms the relationship rather than relying on a service name alone.
2. Prepare a least-privileged test identity. Use a disposable account and known synthetic object. Keep any owner control separate from the runner credentials so that accidental privileged reuse cannot create a false result.
3. Enforce the allowed route. Permit only the named environment and harmless operation; exclude production, writes, unrelated records and other services. Check the cancellation owner, request budget, data retention and credential-revocation procedure.
4. Observe the intended boundary. Retain sanitized requests and responses, the relevant marker or state, and a server observation when available. An HTTP 200, a generated exploit description, or the absence of an error is insufficient by itself.
5. Stop and classify uncertainty. Stop on real data, an unplanned destination, identity changes or instability. Record what was not tested. Do not keep retrying with more privilege until a desired narrative appears.
6. Have the engineer review the conclusion. The engineer should be able to reproduce the relevant observation and identify the condition that made it possible or prevented it. The result remains provisional when that explanation is missing.

Close the loop on the deployed fix

Use the validated condition to choose remediation; do not let a generic issue title determine a patch. The developer may need to repair an authorization decision, constrain an input, remove an unsafe operation or correct deployment configuration. Track the approved change and the build in which it is actually released. A closed code-review request is not evidence that the runtime changed.

Repeat the same bounded check on the repaired build, then repeat the permitted workflow as a positive control. If the feature fails for every account, the security requirement has not been met. If a cache or stale instance explains the observation, resolve that deployment issue and record it rather than marking the source fix ineffective without evidence.

For a purchase decision, count accepted findings, cases not reproduced, blocked cases, identity/setup failures, and time spent by the reviewer. Keep the full denominator. Lower ticket volume can come from better validation, narrower coverage or missing access; your pilot must show which explanation is supported.

A separate way to evaluate the evidence workflow is a single authorized Penligent task. Installation and registration are required. Bring one staging target, a disposable identity, a known fixture and a clear pass condition; confirm supported authentication and scope controls before granting access. This does not claim Arnica integration, SAST ingestion or equivalent code-to-runtime mapping. The Penligent product demonstration supplies general context, not a completed validation result.

Method: AI-assisted review of the vendor’s public material and an original source-to-runtime acceptance plan, checked November 6, 2026. No Arnica or Penligent execution, SAST finding reproduction, or target test was performed.