Reachability Ratio measures how much of a defined environment an identity, workload, integration, workflow, or agent can affect if its authority is misused.
The basic formula
The simple form is reachable impact surface divided by the defined impact surface. If a CI/CD runner can materially affect 100 production assets in a defined universe of 1,000, its Reachability Ratio is 10 percent.
Lower is generally better for high-impact identities and workflows because it means compromise or misuse has a narrower reachable future.
What counts as reachable
Reachability is broader than network connectivity. It includes identity reach, data reach, deployment reach, control-plane reach, workflow influence, and external effects such as messages, refunds, entitlement changes, or security-control modification.
Mature versions of the metric weight assets and actions by sensitivity, environment, authority type, and consequence. The first version can remain simple as long as it exposes concentrated blast radius that an inventory view hides.
Do not average away the risk
A single organization-wide average can hide dangerous outliers. Report Reachability Ratio as a distribution, heatmap, or set of domain-specific views for humans, workloads, suppliers, pipelines, and agents.
The useful question is not the average reach of all identities. It is which few identities or workflows can influence an outsized share of the environment and which trust edges make that reach possible.
How the metric drives action
A high ratio should lead directly to a design question: which unsafe trajectory remains reachable, which authority path created it, and what constraint patch would narrow it?
The answer may be a task-scoped token, a curated action, a split role, a removed trust edge, a purpose-bound export path, or automatic collapse. The metric matters when it changes the system—not when it becomes another dashboard number.