How risk is calculated
Where the 0 to 10 risk score comes from, what the levels mean, and how scores from each endpoint combine into a company-wide score.
Every AI asset has a risk level, and every assessed asset has a risk score from 0 to 10. The score comes from one thing only: the policies the asset breaks. No guesswork, no hidden reputation list. You can always click an asset and see the exact failed policies behind its number.
The 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 |
| Unknown | No score | Not assessed yet. You can still allow, warn, or block it |
An asset that breaks no policy is Low with a score of 0, but only when the scanner could check at least half of the policies for its kind. If it checked fewer, or its kind has no policies yet, the asset is Unknown: it has no score, and the console shows a dash where the number would be. Unknown means “not assessed”, which is not the same as “checked and found safe”.
How the score is built
Matching policies become failed policies
Each policy is a condition Surface checks for in a kind of asset, and carries a score for how serious it is. When an asset meets the condition, that policy is a failed policy for the asset. The asset panel lists them under Violations. See Asset Policies.
Similar failed policies count once
When several failed policies describe the same underlying problem, only the worst of them counts, so an asset is not punished three times for one problem.
The worst problem matters most
Failed policies 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. An asset can get close to 10 but never above it.
A worked example
An MCP server breaks three policies:
| Policy | Score |
|---|---|
| Project MCP servers are auto-approved | 9.0 |
| MCP server uses a shell wrapper (sh -c) | 7.0 |
| MCP server uses npx -c / –call (shell execution) | 7.0 |
The two shell policies describe the same problem, so only one 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 problem and the score drops to about 5.0, Medium.
What does not change the score
- Your action. Allowing an asset marks it Governed. It does not lower the score. The score describes the asset; the action is yours.
- Who made the asset. Surface uses its knowledge of known assets to identify them and pick the right policies, not to add or remove points.
- Tags and Framework badges on policies. These help you filter and report.
Which assets get a score
Policies exist for the Agent, MCP Server, Skill, Browser Extension, IDE Extension, Memory, and Tool asset types. Two gaps to know about:
- Model assets and some agent kinds (SaaS agents, local model runners, browser agents, autonomous agents) have no policies yet, so they are Unknown. You can still allow, warn, or block them.
- Memory and Tool assets have policies, but the scanner does not yet collect the details those policies need, so they are Unknown.
Severity versus risk level
Severity belongs to a policy: how bad that one situation is. Risk level belongs to an asset: the result of every policy it breaks, combined. Use severity to pick which failed policy to fix first, and risk level to pick which asset to deal with first.
Next steps
- Risk across endpoints for how endpoint scores combine into company-wide numbers, and the exact formula
- Asset Policies to read every policy assets are checked against