How risk is calculated
Where the 0 to 10 risk score comes from, what the four levels mean, and how scores roll up from laptops to the company.
Every AI tool has a risk score from 0 to 10 and a risk level. The score comes from one thing only: the policies the tool breaks. No guesswork, no hidden reputation list. You can always click a tool and see the exact findings behind its number.
The four levels
| Level | Score | What to do |
|---|---|---|
| Critical | 8.1 to 10 | Act now. Block unless you have a good reason to allow it |
| High | 6.1 to 8 | Review soon. Warn or block |
| Medium | 4.1 to 6 | Keep an eye on it. Warn |
| Low | 0 to 4 | Fine under normal rules. Allow |
A tool that breaks no policy shows a dash instead of a score. That means “no rule applied”, which is not the same as “checked and found safe”.
How the score is built
Policies produce findings
Each policy describes one risky situation for a kind of tool, and carries a score from 1 to 9.5 for how bad that situation is. When a tool matches, that is a finding. The console lists them as Failed Policies. See Policies.
Similar findings count once
Policies that describe the same underlying problem belong to one risk group. Only the worst finding in a group counts, so a tool is not punished three times for one problem.
The worst problem matters most
Findings are sorted from worst to least bad. The worst counts fully, the second 60%, the third 30%, and the rest 10% each. One serious problem gives a high score on its own. Many small ones push it up, but slowly.
The result lands on a 0 to 10 curve
The curve rises fast at first and flattens near 10. A tool can get close to 10 but never above it.
A worked example
An MCP server breaks three policies:
| Policy | Risk group | Score |
|---|---|---|
| Servers are auto-approved for every project | untrusted-server-autoapproval | 9.0 |
| Server command runs through a shell | command-injection | 7.0 |
| Server is started with a shell wrapper | command-injection | 6.5 |
The two command-injection findings share a group, so only 7.0 counts. That leaves 9.0 and 7.0. The worst counts fully and the second at 60%, which lands at 7.3, High. Fix the auto-approval finding and the score drops to about 5.0, Medium.
What does not change the score
- Your decision. Allowing a tool marks it Governed. It does not lower the score. The score describes the tool; the decision is yours.
- Who made the tool. Surface uses its knowledge of known tools to identify them and pick the right policies, not to add or remove points.
- Tags and CWE references on policies. These help you filter and report.
Which tools get a score
Policies exist for agents, MCP servers, skills, browser extensions, IDE extensions, memory stores, and agent tools. Two gaps to know about:
- Models and some agent kinds (SaaS agents, local model runners, browser agents, autonomous agents) have no policies yet and show a dash. You can still allow, warn, or block them.
- Memory stores and agent tools have policies, but the scanner does not yet collect the details those policies need, so they are not scored yet.
Severity versus risk level
Severity belongs to a policy: how bad that one situation is. Risk level belongs to a tool: the result of every policy it breaks, combined. Use severity to pick which finding to fix first, and risk level to pick which tool to deal with first.
Next steps
- Risk rollups for how laptop scores combine into company-wide numbers, and the exact formula
- Policies to read the rules behind the findings