> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flintai.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# How discovery works
> Where findings come from, and why one is Critical and another is Low
**Findings arrive with a severity level already attached.** This page explains where that level comes from, so you can tell when to trust it and when to look closer.
## What discovery covers
The GitHub Action reads the Python source in each connected repository and reports what it finds back to your workspace. It never modifies your code.
Discovery builds an inventory of the following:
* **Agents** - The agents defined in your source
* **Models** - The models those agents call
* **MCP servers** - The servers they connect to, whether you built them or not
* **Tools** - The functions and integrations they can invoke
Every rule is scoped to the types it applies to, which is why the **Issues** table labels each row with the type it ran against — **Agent**, **Model**, or **MCP server**. No rule targets a tool, and a model rule never fires on an agent.
**Discovery reads Python.** Agent code in other languages is not scanned, so an empty inventory on a polyglot repository means the scanner found no Python agents — not that the repository is clean.
## Why a finding is Critical rather than High
Severity is set by the rule that produced the finding, not calculated from the evidence. To see the reasoning behind any severity level, open the **Details** tab on the issue panel and read **Specifications** — it states the severity and the condition that earns it.
Rules assign severity in one of two ways.
**Most rules declare a single severity.** **Hardcoded credentials** is always Critical: the credential is either in your source or it isn't, so there is no scale to place it on. When a rule works this way, every occurrence it produces carries the same severity level, and the judgment about how bad that condition is was made once, when the rule was written.
**A handful of rules band by score instead.** These are model evaluation rules — they rate a model on where its score falls, so one rule can produce rows at more than one severity level. Evaluation is a separate scan, and the banding is explained in [How evaluation works](/flintai/platform/evaluation/how-evaluation-works).
The full condition for every rule is published in the [Rules reference](/flintai/platform/rules/index), the same text the product shows under **Specifications**. Read it there when you want to know what a rule looks for before it fires.
## Severity and CVSS are not the same number
Because severity comes from the rule, the **CVSS score** on a finding is reported alongside severity rather than being its source. The two can disagree, and neither is wrong.
* **Severity** - The rule's judgment, scoped to agent security. Use it to decide your order of work
* **CVSS score** - An industry-standard rating from 0.0 to 10.0. Use it when a security team asks for a portable number
## How findings map to published standards
Every occurrence carries a **Category** naming the published taxonomy entry it belongs to. Agent findings use the OWASP ASI Top 10 for Agentic Applications, so a category reads as a code and a name, such as `ASI01 AGENT GOAL HIJACK`. MCP server findings use a separate MCP vulnerability taxonomy.
**References**, on the **Details** tab of the issue panel, links out to the standards behind the rule. That's the fastest way to hand a finding to someone who works in that framework rather than in Flint AI.
## Next steps
Triage findings, confirm they're real, and know when they're resolved
What every rule checks, the risk behind it, and how to fix it