> ## Documentation Index
> Fetch the complete documentation index at: https://aspex.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Score and blast radius

> What the 0–100 score measures, why an attack path caps it, and what the blast radius factors are.

## The score

Every scan produces a 0–100 score (100 = safe) with a per-server breakdown and four category scores: **Prompt Security**, **Tool Security**, **Data Protection**, **Supply Chain**.

```
  ╭─────────────────────────────────────────────────────────────╮
  │   39 / 100  █████████░░░░░░░░░░░░░░░  HIGH RISK (100 = safe)  │
  │  7 servers · 8 findings · 2 critical  5 high  1 medium       │
  ╰─────────────────────────────────────────────────────────────╯
```

## Paths cap the score

An environment of individually clean servers can still be dangerous together, so attack paths cap the overall score regardless of per-server results:

| Path present          | Score capped at |
| --------------------- | --------------- |
| one **critical** path | 39              |
| one **high** path     | 69              |

The report always says why: `Score capped at 39: critical attack path: AP001 …`. `--fail-on` counts paths too, so CI fails on a critical composition even when every server passes alone.

## Blast radius

Not a number. A list of factors, each shown present or absent in `aspex scan`, `bom`, `diff` and the lockfile:

```
  Blast radius HIGH  ✓ reads credentials or sensitive files · ✓ arbitrary external network egress
                     ✓ command execution · ✓ can rewrite agent config or hooks that run at next start
```

| Level      | When                                                                                                                                                                       |
| ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **HIGH**   | A critical path exists; or execution meets open egress; or credential/sensitive reads meet open egress; or persistent executable state is writable while content can enter |
| **MEDIUM** | Any one of those factors alone; or destructive database capability; or a fixed channel next to sensitive reads                                                             |
| **LOW**    | Otherwise                                                                                                                                                                  |
| **NONE**   | An empty environment                                                                                                                                                       |

## History

Each scan writes a JSON log and, when the environment changed, a lockfile-shaped snapshot to your user cache directory. On later runs the score box shows the delta and the report ends with the highest-impact fixes, ranked by the risk each one retires. Real output:

```
  │  ↓ -21 pts since last scan (was 39/100)                     │

  Highest-impact fixes
  → Fix Dangerous capability: arbitrary filesystem write  clears 3 high across 2 servers
  → Fix Dangerous capability: shell/exec (schema pattern)  clears 1 critical across 1 server
  → Fix Server can write agent-trusted state  clears 3 high across 3 servers
```

Fixes are ranked by the criticals and highs they clear, not by a "+N points" estimate: the score is pulled toward the worst server and capped by any attack path, so a per-fix point number would be misleading. The list tells you what each fix actually removes.

`aspex history` replays the snapshots: servers, tools, attack paths and blast radius per point, and the security-relevant changes between them.

## Accepting risk

Accept a path or rule in `.aspex.yaml` by ID, with a reason and an expiry. `--save-baseline` records current findings; `--baseline` hides the ones that were already there so CI only fails on new ones. [Policy & baselines →](/guides/policy)