Your CLI agent can review suspicious code. Can it trace the vulnerability?

Security debt is one of the hardest parts of cleaning up AI-generated, legacy, or inherited code because a warning title does not show whether untrusted data really reaches a sensitive sink or whether a plausible patch removes the path. A CLI agent can inspect selected files or consume a separately configured scanner report, but it may have to reconstruct the flow and remediation context by hand. For supported Java and Kotlin patterns, Explyt traces the path across the JetBrains project, opens every reported step in code, passes the finding to the agent, and rescans after the reviewed fix. This gives the cleanup team a locally verifiable remediation before PR while corporate SAST policies and security owners remain the authority for release decisions.

For supported vulnerability patterns, the local loop is:

build available project sources → finding and source-to-sink trace → editor navigation → finding and related code in agent context → reviewed fix → tests → rescan

What a CLI code review can and cannot establish

A terminal agent is good at reading a diff, searching for related code, following obvious callers, and proposing a project-shaped patch. It may spot an unsafe query, an unvalidated URL, or output that needs encoding. It can also run shell commands when the task requires them.

What it does not receive automatically is a whole-project security analysis. The model must decide where to search, which path matters, whether validation interrupts the flow, and what to verify after the edit. It can miss a distant source or sanitizer because neither appeared in the files it selected.

Some companies separately operate Semgrep, CodeQL, Sonar, or another corporate SAST system. Those scanners, their custom rules, suppressions, and CI gates remain an additional authoritative layer. Explyt's current Vulnerability Search does not replace that infrastructure or its governance.

Explyt connects a local detection and remediation path inside the IDE.

From a scanner report to the exact code path

Explyt's Vulnerability Search analyzes the available source code of a built JVM project under its supported rules. The plugin first tries to build the project with Maven or Gradle. Results can include interprocedural data-flow traces: a sequence showing how data moves from a source, such as an HTTP parameter, to a sensitive sink, such as a database query or outbound URL request.

The documented categories include SQL injection, cross-site scripting (XSS), and server-side request forgery (SSRF), among others. This is not complete coverage of every vulnerability or every execution path. Reflection, framework behavior, project-specific sanitizers, and unsupported patterns can affect the result.

In Explyt, clicking a trace step opens the corresponding location in the JetBrains editor. The developer can move through the reported path, inspect nearby symbols, and decide whether the flow is plausible without asking the model to reconstruct the route from whichever files it happened to find.

A company scanner may also produce a trace, for example in SARIF or its own report format. Using that result with a CLI agent is a separate workflow: the team must expose the report, preserve the relevant path and locations, and carry that context into remediation.

This matters when a finding crosses controllers, DTOs, services, and helper methods. The final sink may look obviously dangerous while an earlier sanitizer makes the path safe. The reverse also happens: a clean-looking helper receives untrusted data from a distant caller. The trace does not decide exploitability by itself. It gives the developer and security engineer a concrete path to challenge.

Put the finding into the agent's working context

A scanner title such as "possible SSRF" is not enough to choose a safe remediation. The agent needs the reported locations and related code, then it may need to inspect callers, established validation patterns, or the exact library version connected to the project. That investigation uses the same indexed facts as building a working model of an unfamiliar repository.

Explyt can attach a finding to chat or start an agent-assisted fix from the result. That avoids copying a report excerpt into a new prompt and asking the agent to rediscover the path. JetBrains symbol navigation and connected dependency sources remain available during the investigation.

Explyt's advantage is that the finding, trace navigation, related code, and agent handoff are already part of one JetBrains-native workflow. The developer does not first have to obtain an external report and translate it into the agent's working context.

The proposed edit still needs review. For SQL injection, the right change may be a parameterized query or an existing repository API. SSRF remediation depends on allowed destinations and URL parsing rules. XSS requires encoding for the actual output context. A plausible patch can silence a pattern while weakening validation elsewhere, so review the full diff rather than accepting the Fix action as a verdict.

AgentLens does not score vulnerability detection, but its change-and-verification tasks expose the same remediation risk. Six trajectory reviews found real behavior or API drift, including broadened validation contracts and route changes, while others flagged unsupported root-cause or success claims. That is why the source-to-sink finding must survive a full-diff review, tests, and another scan after the agent's patch.

Close the loop with tests and another scan

Security remediation is not finished when the agent writes code.

Run the relevant tests, inspect the changed callers, and repeat the scan. Explyt can use IDE Run Configurations and structured test results where supported, which is useful when the working SDK, module, profile, environment variables, or VM options already live in the IDE. For difficult regression fixtures, test generation from execution can preserve the observed security-relevant behavior.

A CLI agent can run relevant tests when explicitly directed. Repeating a security scan requires a scanner to be installed, configured, and invoked as a separate step. Explyt keeps the local finding, fix, tests, and rescan in one visible workflow; it does not replace the CI run or any corporate scanner your organization treats as authoritative.

Treat severity and false positives as security decisions

A reported flow is a starting point. Authentication, network exposure, privileges, reachable data, and deployment context determine practical severity. If exploitability depends on runtime dispatch or live values, debugger evidence can test assumptions that static analysis cannot settle.

Explyt can ask the agent to estimate a CVSS score. CVSS, the Common Vulnerability Scoring System, describes severity through factors such as attack vector and required privileges. Treat the generated score as a draft with explicit assumptions. A security owner must validate those assumptions against the real deployment and business impact.

The results window also lets a developer mark a finding as a false positive. That removes it from the active list, but the public documentation does not describe a centralized suppression, approval, or audit workflow. If your company requires reviewed exceptions, durable suppressions, ownership, or evidence for auditors, continue to use the established security process.

The same rule applies to fixes: the agent proposes; the responsible developer or security engineer decides. Review the diff, run tests, rescan, and record the decision where the team normally tracks security risk.

Where Explyt fits beside an enterprise security stack

Vulnerability Search is a local detection and remediation layer for supported Java and Kotlin JVM projects. It is useful when a developer wants to inspect and fix a supported source-to-sink finding before opening a pull request, including security debt found while cleaning up an inherited AI-built project.

It does not replace enterprise SAST, threat modeling, software-composition analysis, secret scanning, dynamic testing, penetration testing, or CI controls. Preventive controls around new AI-generated changes can reduce accidental scope, but they do not establish security either. Vulnerability Search also does not currently support custom rules. That is a substantial limitation for organizations with internal security APIs, project-specific sources and sinks, or a mature rule and suppression ecosystem.

The current documented boundaries are:

• Java and Kotlin JVM projects in IntelliJ IDEA, OpenIDE, GigaIDE, and Android Studio;
• an attempted Maven or Gradle build before analysis;
• an offline static scan;
• rules delivered with plugin updates rather than team-authored custom rules.

The offline claim applies to the static scan itself. Sending a finding to an AI agent is a separate operation that may use an external connection. Apply your organization's code and data policies to that step; an offline scanner does not establish the privacy or compliance properties of the entire remediation workflow.

As a code cleanup harness, Explyt turns a supported JVM security finding into a checkable maintenance trail: the reported source-to-sink path, the code at every trace step, the reviewed remediation, passing relevant tests, and the rescan result. The team can repair security debt in AI-generated or inherited code without losing the finding's context between scanner, agent, and editor. Corporate scanners, custom rules, and security approval still decide what may ship; Explyt closes the local gap between detection and a verifiable fix.

Read the Vulnerability Search guide, check the current feature matrix, or install Explyt from JetBrains Marketplace.