Findings

​

What a finding is

A finding is a vulnerability an agent has confirmed and recorded. It’s the durable output of agent work — what survives after the conversation or run is over. Every finding carries:

• Where — the affected file, and the symbol it’s anchored to
• What — the vulnerability, its classification, and severity
• Why — the agent’s reasoning for believing it’s genuinely exploitable
• The fix — a suggested patch, when one was generated
• Provenance — the run that produced it, and the detection behind it if there was one

The reasoning is the part worth reading. A pattern match tells you a shape appeared; a finding tells you why the agent believes an attacker can actually reach it. That’s what makes it triageable.

​

Where findings come from

​

Deduplication

Findings are deduplicated per project by identity. The same issue rediscovered on a later run updates the existing finding rather than creating a second one, so a long-lived issue doesn’t inflate your counts and run history stays readable. Findings are anchored to a symbol rather than only a line number, so a finding survives edits that shift line numbers around it.

​

Closing the loop

Two actions on a finding detail page turn a report into progress.

​

Accepting a fix

When a finding has a generated patch, the suggested fix section can open a pull request with that patch applied. You review it like any other pull request. Patches aren’t guesses. The agent that generated one edited the file, re-ran the detection to confirm the match was gone, and captured the resulting diff — for policy detections, an independent read-only verifier judged the result. You’re reviewing a change that has already been checked, not a proposal.

​

Starting a chat

Start a chat opens a session with the finding’s context already loaded — the affected code, the agent’s reasoning, and the generated patch if there is one. You type your question in the same step. Use it to ask the things a report can’t anticipate: is this actually reachable in production?, what else in this codebase has the same problem?, why is this the right fix? The session is titled after the finding’s file and line, so it’s easy to find later.

​

From finding to detection

The highest-leverage move on a finding is turning it into a rule. A finding is one instance; a detection catches the whole class from then on, in every repository, without an agent re-deriving it. Ask in chat, or add detection-author as a workflow step to do it automatically for every finding a scan produces.

​

Delivering findings automatically

Findings don’t have to be pulled — a workflow can push them where your team already works:

• Comment on the triggering pull request, with links back to the full finding.
• Gate merging until review passes or a human approves.

​

Next steps