---
title: How risk is calculated
description: 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.

```mermaid
flowchart LR
  T[AI tool on a laptop] --> P["Checked against ~200 policies"]
  P --> F[Failed policies]
  F --> S[Score 0 to 10]
  S --> L[Low / Medium / High / Critical]
```

## 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

1. **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](/surface/risk/policies).

2. **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.

3. **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.

4. **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](/surface/risk/rollups) for how laptop scores combine into company-wide numbers, and the exact formula
- [Policies](/surface/risk/policies) to read the rules behind the findings