Skip to main content
Your first scan is in. Now work out what needs attention — or confirm your agents are already clean.

​
Where your results land

Results land in the left navigation, where each view answers a different question:
  • Agents - Which agents do I have, and which need attention first?
  • Assets - What do those agents depend on, across models, MCP servers, and tools?
  • Insights - What’s wrong across my whole workspace, and which rule found it?
The Agents and Assets views scope findings to a single agent or a single dependency. The Issues table under Insights shows the same findings across your whole workspace.

​
What needs attention first?

Open the Agents view and sort the Highest severity column with Sort by DESC. The agents carrying your most serious issues move to the top. Two columns carry the signal:
  • Highest severity - The most serious issue open against that agent
  • Issues - How many distinct issues it carries. One issue is one rule at one severity level, however many places it turned up
An agent with nothing outstanding shows a dash in both.
Search the table by name to jump straight to a specific agent.

​
What an agent record shows

Select Agents in the left navigation, then select an agent to open its record. The record opens on its Overview tab, with Sessions, Issues, Assets, and Evaluations beside it. Overview covers what the agent costs and what discovery found. The cost cards are Cost by month, $ per session, Burn rate, and Monthly cap. The discovery record is:
  • An Issues card — the total count, with Critical and High as chips above a severity bar, so one Critical issue is easy to tell apart from a long tail of low-severity ones. An agent with neither reads “No critical or high issues”
  • A Details card — Library, Supplier, Manufacturer, Locations, Instructions, Models, Tools, MCP servers, Sub-agents, Input guardrails, Output guardrails, Last seen, and Created
  • A connections graph of the models, tools, MCP servers, and sub-agents it calls, next to a Connections & data sources card
Open the Issues tab to reach the findings themselves. Each one opens the workspace-wide record for that rule, so you can see everywhere else it landed before deciding whether this is a one-agent fix.

​
Assets carry severity too

Go to Assets and switch between the Models, MCP servers, and Tools tabs. Every tab carries Highest severity and Issues, which is how you spot one risky dependency shared across several agents. Models and MCP servers each add a column that matters for triage:
  • Models - A Health score from 0 to 100, how the model held up under evaluation. Higher is better here, the opposite of severity — see Evaluation results
  • MCP servers - A Type that separates servers you built from third-party ones

​
Issues group findings by rule

To see findings across every agent at once, go to Insights, then Issues. Each row is one rule at one severity level. Every agent and asset that triggers the rule carries that rule’s severity level, and each one becomes an occurrence on the row. Each row shows:
  • Name - The rule that produced the finding
  • Assets analyzed - The asset type the rule ran against, as a chip: Agent, Model, or MCP server
  • Severity - The level shared by every occurrence in the row
  • Occurrences - How many agents and assets triggered the rule
  • Agents affected - How many of your agents are involved
Three agents that trigger the same rule give you one row with three occurrences, not three rows. Agents affected can read zero while Occurrences does not. That means the rule triggered on a model or an MCP server none of your agents currently call. The finding is real — it just isn’t reaching an agent yet.
Search the table by rule name to jump straight to a specific rule.

​
When one rule fills more than one row

Most rules declare a single severity level, so every occurrence they produce shares it. A handful of rules band by score instead — they rate a model on where its score falls, so one rule can produce rows at more than one severity level. Model toxicity risk is an example, and its Specifications list the bands. These are not duplicates. Each row holds only the assets at that same severity level, so a badly failing model sits at Critical severity while a mediocre one sits at High. Those scores come from evaluation, a separate scan — see How evaluation works.

​
Is this finding real?

Before you rewrite any code, decide whether to trust the finding. Agent confidence — the scanner’s self-assessed certainty that its detection is correct — is the fastest signal: HIGH means act on it, MEDIUM or LOW means verify against the evidence first. Select a row in the Issues table to open the issue panel. Everything from the rule down to the line of code that triggered it lives in this one panel.
1

Read the summary

The panel opens on its Overview tab: Severity, Assets analyzed, a Description of what the rule looks for, and How to resolve. Description and How to resolve both clip to a few lines — select Show more for the rest.
2

See what it affected

Below the summary, a table lists one row per affected agent or asset under Asset name. Its Occurrences column counts the matches inside that single agent or asset, so it reads differently from the Occurrences column on the Issues table, which counts how many agents and assets the rule hit.
3

Expand a row to find the code

Expand a row to list each place the rule triggered, labeled with its file path and line number, such as agent_framework_mcp_github.py:28. Where there is surrounding code, select Show to reveal it in place. A Load more button appears at the bottom of the list when there are more rows.
4

Open the occurrence details

Select any one of them to open Occurrence details, the full record for that single finding. Use the back arrow to return to the list.
Occurrence details answers three questions. Every field always appears — the ones that don’t apply show a dash. What’s wrong:
  • Rule description - What the rule looks for
  • Result description - What it found in this particular place
  • Evidence - The code or configuration that triggered the rule
  • Category - The published taxonomy entry the finding maps to
How severe:
  • Severity - Critical, High, Medium, Low, or Informational
  • CVSS score - Industry-standard score, 0.0 to 10.0
  • Likelihood - How likely the issue is to be exploited in practice
  • Agent confidence - How certain the scanner is of its own detection
  • Impact - What an attacker gains if the issue is exploited
Where to fix it:
  • File path - The file and line it was found on
  • Asset evaluated - The agent, model, MCP server, or tool the rule ran against
  • Affected components - The files a fix needs to touch
  • Remediations - How to fix this specific finding
Long values are cut off at one line. Rule description, Result description, Remediations, and Impact all truncate with an ellipsis. Hover over any of them to read the full text.

​
Categories map to published standards

Agent findings use the OWASP ASI Top 10 for Agentic Applications. MCP server findings use a separate MCP vulnerability taxonomy. Category names the entry directly, such as ASI01 AGENT GOAL HIJACK, and References on the Details tab links out to the standards behind the rule. See the Rules reference for what each rule checks and why it matters.

​
Reading severity and confidence together

Severity tells you how much the finding matters. Agent confidence tells you how much to trust that it’s there at all. Reading them as a pair is what turns a list of findings into a plan. Likelihood describes how likely the issue is to be exploited in practice, which matters most when you are choosing between two findings at the same severity. For where a severity level comes from in the first place, see How discovery works.

​
How do I know it’s resolved?

Every finding carries the guidance to resolve it. The next scan is what confirms it’s gone.
1

Read the occurrence

Start with Evidence and File path to see exactly what triggered the rule and where.
2

Read the remediation

Every occurrence carries a Remediations field written against the code that triggered it.For background on the rule itself, open the Details tab on the issue panel — How to resolve, Specifications (the trigger, the patterns the scanner looks for, the severity, and the asset types the rule applies to), Risk factors, Explanation, and References. This is the same guidance published on the rule’s page in the Rules reference, so you can read it in the product or link a teammate to the page.
3

Apply the fix

Make the change in your agent code and push it.
4

Re-scan to verify

The next run of the GitHub Action refreshes your findings and updates Last seen on the agents and assets it touched. Confirm the occurrence is gone.
5

Ship the fix

Merge with the finding resolved and the scan to show for it.
Already clean? Agents and assets with nothing outstanding show a dash in both the Highest severity and Issues columns.
Run the GitHub Action on a schedule so new agent code is covered as you write it, rather than only when someone triggers a scan.

​
Next steps

How discovery works

Where findings come from, and why one is Critical and another is Low

Rules reference

Detailed guidance on every rule, including the risks and recommended fixes

Monitor agents at runtime

Install the SDK to capture live traces and enforce guardrails