> ## Documentation Index
> Fetch the complete documentation index at: https://docs.switchagents.ai/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> These docs moved from docs.flintai.dev to docs.switchagents.ai. Use docs.switchagents.ai for every link and request.
> To search these docs from an AI tool, connect the MCP server at https://docs.switchagents.ai/mcp. The page index is at https://docs.switchagents.ai/llms.txt.
# Discovery results
> Triage findings, confirm they're real, and know when they're resolved
**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. The **Evaluations** tab is where you attack the agent and score how it holds up. Refer to [Evaluate your agents](/switch-trust/evaluation/evaluate-agents).
**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](/switch-trust/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](/switch-trust/evaluation/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.
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.
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.
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.
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](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/). 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](/switch-trust/rules/index) 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.
| What you see | What it's telling you | What to do |
| - | - | - |
| High or Critical, confidence `HIGH` | A serious problem, detected with certainty | Resolve it now — the evidence is only needed to write the patch |
| High or Critical, confidence `MEDIUM` or `LOW` | Serious if it's real, but the detection is uncertain | Confirm it against the evidence before anything changes |
| Medium or Low, confidence `HIGH` | A real issue that isn't urgent | Queue it with related work in that file |
| Medium or Low, confidence `MEDIUM` or `LOW` | Low return on your attention right now | Leave it; revisit if the same rule starts firing across more of your inventory |
| Any severity, **Agents affected** reads 0 | A model or MCP server is at risk, but nothing calls it yet | Resolve it before that dependency is wired into an agent, not after |
**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](/switch-trust/discovery/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.
Start with **Evidence** and **File path** to see exactly what triggered the rule and where.
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](/switch-trust/rules/index), so you can read it in the product or link a teammate to the page.
Make the change in your agent code and push it.
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.
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
Where findings come from, and why one is Critical and another is Low
Detailed guidance on every rule, including the risks and recommended fixes
Install the SDK to capture live traces and enforce guardrails