REVIEW 4 major objections 4 minor 2 cited by
Scoring Azure permissions with metric spaces
T0 review · 4 major / 4 minor · reviewed 2026-08-16 · deepseek-v4-flash
Pith's one-line read Azure permissions are scored by two metric distances, one for configuration power and one for data-exfiltration breadth.
desk verdict The blast-radius half of the paper rests on a false ultrametric theorem; the WAR half is a valid but unvalidated scalar embedding — reject the math, not the idea. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
Two constructions carry the argument. The first is the super-increasing weight system for the control plane: sequences $W=\{900,800,\dots,100\}$, $A=\{90,80,\dots,20\}$, and $R=\{9,8,\dots,2\}$ satisfy $\min W>\max A+\max R$ and $\min A>\max R$, which guarantees unique binary decomposition of any weighted sum and therefore unambiguous ranking by the WAR norm. The second is the lowest-common-ancestor ultrametric for the data plane: $D(s_1,s_2)=2^{-(2d+1)}$ for scopes whose LCA sits at depth $d$ is half the square of a standard tree ultrametric, and the blast radius is the diameter of a principal's permission set under the impact-scaled version of $D$. The theorem the paper needs is that scaling $D$ by per-pair impact coefficients preserves the ultrametric inequality.
What would settle it
Grant a principal a Write permission on a management group in branch A at depth 1, a Read permission on a management group in branch B at depth 1, and a Write permission on a subscription nested inside branch A at depth 3. Under the paper's pair-wise impact rule the two top-level permissions get impact 2, so $\delta$ between them is $1$, while each pair involving the nested subscription gets impact 1, giving $\delta=1/8$ for the pair inside branch A and $\delta=1/2$ for the cross-branch pair. That yields $\delta(s_1,s_3)=1>\max(1/8,1/2)$, contradicting the strong triangle inequality and settling the ultrametric claim.
Extended reading notes
Core claim
The central claim is that Azure's two privilege planes admit natural metric structures. For control-plane permissions, each principal is mapped to a tuple $(w,a,r)$ of the highest-weighted Write, Action, and Read permissions it holds at any scope, where the weights come from superincreasing sequences chosen so that any Write weight exceeds all Action and Read weights combined and any Action weight exceeds all Read weights; the WAR distance $d(P_1,P_2)=|(w_1+a_1+r_1)-(w_2+a_2+r_2)|$ is then a true metric, and the norm $\|P\|=w+a+r$ gives a total order of principals from $0$ (no rights) to $999$ (tenant-level superadmin). For data-plane permissions, scopes are arranged in the tenant hierarchy and the distance between two permission scopes is $\delta(s_i,s_j)=\mathrm{impact}\cdot 2^{-(2d+1)}$, where $d$ is the depth of the lowest common ancestor and the impact coefficient reflects whether read and write permissions (or a wildcard) coincide at the shallower scope; the blast radius is the maximum of $\delta$ over all permission pairs, with a separate singleton formula when only one permission exists. The paper asserts that $\delta$ obeys the ultrametric strong triangle inequality, so the blast radius is a single number in $(0,1]$ that captures the widest organizational separation of a principal's data access.
Load-bearing premise
The blast-radius score assumes that the 'shallowest scope' of a permission pair is always well defined and that the impact-weighted distance always satisfies the ultrametric triangle inequality; the paper does not define the equal-depth case and the inequality does not hold for all permitted permission triples.
Editorial extensions
If this is right
- Control-plane principals can be totally ordered by privilege norm, so the most overprivileged identities can be listed without subjective weight choices.
- A de-escalation plan can be quantified as the WAR distance between the current and target privilege tuples.
- Tracking a principal's WAR norm over time turns privilege drift and anomalous escalations into observable signals.
- The blast radius tells whether a principal's data access spans multiple independent organizational zones, flagging exfiltration and forgery exposure.
- Together the two metrics supply a common scale for least-privilege enforcement on Azure.
Reading between the lines
- The same pairing of a superincreasing control score with a tree-depth data score could be transferred to other cloud platforms, but the organizational boundaries encoded in Azure management groups would need local redefinition.
- A natural hardening of the data-plane construction would fold the impact coefficient into the scope label, treating 'read plus write at tenant' as its own hierarchy node, which would make the blast radius a genuine ultrametric and preserve the diameter interpretation.
- For group-inherited permissions, the paper keeps the WAR norm but gives up unique decomposition; a union-based aggregation, which the paper lists as future work, would restore the one-to-one link between a score and the permission set.
- The WAR constants are arbitrary within the superincreasing bounds, so the resulting norms should be treated as ordinal rankings rather than absolute risk quantities.
Signed reviews
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The paper proposes two quantitative measures of privilege risk in Microsoft Azure. In the control plane, it defines the WAR distance as the absolute difference of a scalar sum of hand-picked Write, Action, and Read weights, and claims this yields a total ordering of principals by configuration power. In the data plane, it defines a blast radius distance as an impact-weighted ultrametric over the Azure tenant/management-group/subscription hierarchy, and claims the resulting diameter measures the worst-case breadth of data exfiltration and forgery risk. The paper presents proofs that the WAR distance is a metric and that the blast radius distance satisfies the strong triangle inequality, together with worked examples and an open-source implementation.
Significance. If the mathematical claims were correct, the framework could give security practitioners a principled, computable way to rank principals and monitor data-plane exposure in Azure. The paper is clearly written, the Azure-specific modeling choices are domain-appropriate, and the implementation and worked examples are useful concrete artifacts. However, the central data-plane theorem is false, and the control-plane ranking is a direct restatement of the chosen weights rather than an independently validated risk measure. As it stands, the paper's two main contributions are not supported.
major comments (4)
- [§3.3.3] The proof of the strong triangle inequality for δ is invalid. After assuming κ13D13 > max{κ12D12, κ23D23}, the paper bounds the right-hand side by 2 max{D12, D23} and then proceeds as though κ13D13 > 2 max{D12, D23} had been established. This implication is false: the right-hand side of the assumption can be as small as max{D12, D23}. The theorem itself is false. Take a common ancestor at depth d with three distinct child branches; let s2 be at depth d+1 and s1, s3 at depth d+2. Assign a combined Write+Read permission at s1, a Write-only permission at s2, and a Write-only permission at s3. All pairwise LCAs are at depth d, so D12 = D23 = D13 = 2^{-(2d+1)}. Under the natural interpretation that equal-depth scopes with different permissions are considered together, the pair (s1, s3) has both Write and Read at the shallowest involved scope, so impact = 2 and δ(s1, s3) = 2^{-2d}; the other two pairs have impact = 1 and δ = 2^{-(2d+1)}. Hence δ(s1, s3) > max{δ(s1, s2), δ(s2, s3)}, contradicting the strong triangle inequality. This falsifies the paper's central data-plane claim.
- [§2.2.1 and Eq. (1)] The Unique Decomposition Property is false for the weight sequence in Eq. (1). In the listed descending order, the super-increasing condition fails immediately because 800 is not greater than 900. In ascending order, 300 is not greater than 100 + 200 = 300, and the subsets {700, 300} and {600, 400} have the same sum. Therefore the stated lemma and its proof do not apply to W. The identity-of-indiscernibles proof in §2.3.3 relies directly on this lemma. Although the specific tuple encoding using one element from each of W, A, and R may still be injective, the argument given in the paper is incorrect and must be replaced by a correct proof or by a genuinely super-increasing sequence.
- [§2.4] The WAR distance d(P1, P2) = |∥P1∥ − ∥P2∥| is exactly the absolute difference of a scalar embedding; the metric adds no structure beyond the scalar norm. The total ordering of principals by 'configuration power' therefore reproduces the hand-chosen weights in Eqs. (1)–(3) and the risk ordering in §2.3.1. The paper provides no external benchmark, validation, or sensitivity analysis showing that these weights correspond to actual Azure risk. As a result, the ordering is a restatement of modeling assumptions rather than an independently supported measure of configuration power.
- [§3.3.2] The impact rule is not well-defined for pairs of scopes at equal depth. The text says impact is determined 'at shallowest scope depth,' but when the two scopes have the same depth and carry different permission types, the paper does not specify whether the union of permissions at that depth should be used, or which scope takes precedence. This ambiguity is not a minor edge case: the counterexample above, and several of the Appendix B examples, involve equal-depth scope pairs. Without a precise definition, the blast radius is not a well-defined function.
minor comments (4)
- [§3.3.3] The displayed identity D(s_i, s_j) = 2^{-(2d_{ij}+1)} = (1/2)(1/d_{ij})^2 is incorrect; the rightmost expression should be (1/2)4^{-d_{ij}}.
- [§2.4.1] The reference point '∥P∥ = 690: Tenant-level read-only (900 for wildcard read at tenant level)' is internally inconsistent: 690 is not 900, and 900 is the tenant-level Write weight, not a Read weight. Please correct or clarify.
- [§2.2.1] The order in which the super-increasing property is checked is ambiguous because Eq. (1) lists the W sequence in descending order while the definition uses 'preceding' elements. State the intended order explicitly.
- [Throughout] There are several typos and spacing inconsistencies: 'straightfoward' in §2.5, 'satifies' in §3.3.3, and inconsistent spacing in 'W AR'.
Circularity Check
No substantive circularity: the WAR and blast-radius scores are openly constructed scoring definitions; the paper's main defect is an invalid ultrametric proof, which is a correctness issue, not a circular reduction.
full rationale
The paper does not fit a parameter to a dataset and then relabel the fit as a prediction. The WAR metric is defined explicitly: the authors choose super-increasing weight sequences (Eqs. 1-3) and define the privilege norm as w+a+r; the total ordering is a mathematical consequence of that chosen encoding, not an independently measured quantity smuggled back in. Similarly, the blast-radius distance is a definition built from the Azure scope tree, the standard ultrametric D(s_i,s_j)=2^{-(2d+1)} (cited to [3,5]), and explicitly stated impact coefficients; no fitted input is renamed as an output. The only self-citation, [2], is used to say 'The W AR distance metric is fully implemented in silhouette[2]' and 'The Blast radius is fully implemented in the silhouette[2] tool'; it supports no theorem and is not load-bearing. The absence of external benchmarks is a validation gap, not a circularity. The serious problem in §3.3.3 is a proof error, not circularity: after writing max{κ12D12,κ23D23} ≤ 2 max{D12,D23}, the proof infers that δ13>max{...} implies κ13D13 > 2 max{D12,D23}, which is invalid; with κ12=κ23=1 and κ13=2, δ13 can exceed max{δ12,δ23} even though D remains ultrametric. That invalidates the claimed ultrametric property of δ, but it does not make the derivation equivalent to its inputs by construction. Therefore the circularity score is 0.
Assumptions & free parameters
free parameters (4)
- WAR superincreasing weight table =
W={900,...,100}; A={90,...,20}; R={9,...,2}
- Blast radius impact factors =
1 or 2
- Scope hierarchy mapping =
Tenant=0, MG=1..6, Subscription=7; scopes below subscription collapsed
- Permission exclusion rule =
Action excluded from data-plane scoring
assumptions (3)
- standard math Unique decomposition of sums from a super-increasing sequence
- domain assumption The Azure tenant hierarchy is a rooted tree and LCA depth induces an ultrametric
- ad hoc to paper Relative risk ordering of permission types (Read < Action < Write < Wildcard in the control plane; Read and Write equal in the data plane)
Cite this review
Pith. "Pith review of Scoring Azure permissions with metric spaces." pith.science (2026). https://pith.science/paper/4THQ75AP
@misc{pith2026250413747,
author = {Pith},
title = {Pith review of: Scoring Azure permissions with metric spaces},
year = {2026},
howpublished = {\url{https://pith.science/paper/4THQ75AP}},
note = {Machine review of arXiv:2504.13747}
}
read the original abstract
In this work, we introduce two complementary metrics for quantifying and scoring privilege risk in Microsoft Azure. In the Control Plane, we define the WAR distance, a superincreasing distance over Write, Action, and Read control permissions, which yields a total ordering of principals by their configuration power. In the Data Plane, we present a blast radius distance for measuring the maximum breadth of data exfiltration and forgery, leveraging the natural ultrametry of Azure Tenants clustering hierarchy Together, these metrics offer a unified framework for proactive IAM analysis, ranking, lifecycle monitoring, and least privilege enforcement.
Figures
Forward citations
Cited by 2 Pith papers
-
Quantifying Azure RBAC Wildcard Overreach
Belshazaar expands Azure wildcard permissions into explicit action lists and uses a tree-distance metric to show that roughly half of Azure actions can be paired across resource providers by non-obvious wildcards.
-
A Geometry-Grounded Data Perimeter in Azure
A service principal's data perimeter is the minimal Traveling Salesman tour over Azure's blast-radius ultrametric, proposed as a secondary risk-sorting key.
Reference graph
Works this paper leans on
-
[1]
Microsoft, Azure role-based access control (RBAC) , https://learn.microsoft.com/en-us/azure/ role-based-access-control/overview
-
[2]
Christophe Parisel, Azure Silhouette, a SPN sorter and roles minimizer , https://github.com/ labyrinthinesecurity/silhouette
-
[3]
Etienne Ghys, A Singular Mathematical Promenade, page 37, https://arxiv.org/abs/1612.06373
-
[4]
D. F. Ferraiolo, D. R. Kuhn, Role-Based Access Controls, https://arxiv.org/abs/0903.2171
-
[5]
An introduction to the geometry of ultrametric spaces
S. Semmes, An introduction to the geometry of ultrametric spaces, https://arxiv.org/pdf/0711.0709 12
Reviewed August 16, 2026 · model on record in the stance chip above.
Discussion (0). Continue with ORCID to comment.