Arnica began a controlled rollout of Agentic Pen Testing on November 5, 2026. Its company-issued announcement describes comprehensive assessments and incremental tests informed by code changes. That distinction matters when a team reads a result: a change-focused run needs a record of what it covered before anyone turns its outcome into a statement about the whole application.

Conceptual illustration of five component cards, with two grouped beside a build-and-results notebook.
Conceptual illustration of five component cards, with two grouped beside a build-and-results notebook.

Keep the change beside the result

Arnica’s product page says its development-aware testing can use code changes to avoid retesting unchanged code. The company describes this as part of a workflow connecting live-application findings with proposed fixes and retesting. These are vendor descriptions, rather than an independent evaluation of detection accuracy or coverage.

For a pilot, ask how the selected changes map to the work actually performed. A change list is an input; a completed-run record should establish which build and environment were examined and which checks finished. If that information is unavailable, keep the coverage question unresolved.

Use a small coverage worksheet

  • Build: record the tested revision and environment so results can be tied to a specific deployment.
  • Selection: retain the change set and the reason for choosing an incremental or broader assessment.
  • Execution: identify the components and checks actually covered, including anything skipped or interrupted.
  • Conclusion: describe the observed result within that coverage, and record who will decide whether additional work is needed.

These fields are a suggested review worksheet, not a claim about Arnica’s interface or exported reports. Ask the vendor to demonstrate the evidence available in the configuration being evaluated.

Try a fictional five-component example

Imagine a staging application with five components. A team changes two, and its test record shows completed checks for those two components with no issues observed. The narrow conclusion is that those checks found no issues in the recorded build. The worksheet still has three components outside that run’s documented coverage.

Two out of five is 40% of the component count in this fictional example. It is not a measured percentage of security risk, code paths or attack surface. Components can differ in size and importance, and interactions can cross component boundaries. A component count alone cannot establish how much risk an assessment examined.

Review the retained evidence before deciding whether to run a broader assessment. This article proposes a reporting exercise; no account was enrolled, application tested or security result measured.

When a finding leads to a fix, use the CrowdStrike retest example to distinguish an explicitly blocked route from an inconclusive timeout.

Read the incremental result

Sources

Arnica’s November 5 company-issued launch announcement

Arnica product page: development-aware testing and rollout FAQ