Authority Path — Concept Review
Date: 2026-02-27 Trigger: Notion "Authority Paths Primer" — synced 2026-02-27 Status: Strategic review with critical feasibility analysis
The Primer's Core Thesis
From authority-paths-primer.md (Notion, synced today):
We must model authority paths as execution-determined, not configuration-determined.
Three distinct layers:
| Layer | What it captures | Example |
|---|---|---|
| 1. Potential | All possible permissions/roles that could execute | SP has Contributor + Reader roles on 5 resources |
| 2. Actual execution | What did execute — APIs called, tokens used, scopes invoked, resources touched | SP used Reader role to call GET /users on Microsoft Graph |
| 3. Standing authority / risk posture | The delta between 1 and 2 | SP has Contributor but only ever used Reader — latent write authority exists |
Default display rule: Only show what was exercised. Latent authority is a separate "could also do" view.
This creates two abstractions:
- Observed Authority Path — what actually executed (default view)
- Potential Authority Path — what could execute (future addition)
The differentiation lives in (2) — actual execution with provenance and execution lineage.
1. SEO Perspective — Strengthened by Execution Focus
The execution-determined framing sharpens the competitive differentiation:
| Competitor | Their framing | SecurityV0 after Primer |
|---|---|---|
| SpecterOps/BloodHound | "What an attacker COULD exploit" (potential) | "What autonomous systems DID execute" (observed) |
| Veza | "Who CAN access what" (potential) | "What DID access what, under what authority" (observed) |
| Wiz | "What toxic combinations EXIST" (potential) | "Which toxic combinations EXECUTED" (observed) |
| CrowdStrike | "What threats are DETECTED" (reactive) | "What authority was EXERCISED" (proactive) |
Key SEO angle: Every competitor shows potential. SecurityV0 shows actual. This is the "did access" vs "could access" positioning from the Clarity doc.
New content opportunities:
- "Observed Authority vs Potential Authority: Why Most Security Tools Show the Wrong Thing"
- "Execution-Determined Security: Moving Beyond Configuration Scanning"
- "The 90% Noise Problem: Why Potential Authority Paths Are Misleading"
Category-creation angle: "Execution-Determined Exposure Management" — nobody owns this.
2. Platform Perspective — Concept Is Sound, Execution Evidence Is the Bottleneck
The Primer aligns well with recent product thinking
The Clarity doc (clarity-so-what-what-do-i-do-now.md) reinforces: "Everything in the CISO view must be execution-determined, not configuration-determined."
The Sprint doc confirms this is the current focus: finish W1 integration + add clarity narratives.
What changes from the current architecture
| Current (glossary) | After Primer |
|---|---|
| Authority Path = 4-node projection (Workload → Identity → Destination → Data Domain) | Authority Path splits into Observed (execution-derived) and Potential (configuration-derived) |
Computed from execution_paths[] (which are role → permission → resource chains) | Observed path must be computed from execution evidence, not just role assignments |
| Single view | Two views: exercised branch only (default) vs full potential (secondary) |
The 4-node model survives but needs qualification
The Workload → Identity → Destination → Data Domain projection still works, but now:
- Observed path: Only includes the identity/role/destination that was actually used in execution
- Potential path: Shows all possible routes through all assigned roles
Example: If a SP has roles Contributor and Reader but only exercised Reader to reach Microsoft Graph:
Observed: Workload → SP (via Reader) → Microsoft Graph → Identity Platform
Potential: Workload → SP (via Reader + Contributor) → Microsoft Graph + Key Vault + Storage
3. Customer / CSR Perspective — Execution Focus Resonates Strongly
The Clarity doc captures the customer voice perfectly:
"I understand what you're doing, but you're making me think too much."
The execution-determined framing solves this by eliminating noise:
| Problem | How execution-focus fixes it |
|---|---|
| Too many paths shown (potential authority creates noise) | Show only paths that actually executed — 90% noise reduction |
| "So what?" — configuration doesn't prove risk | Execution evidence proves risk is real, not theoretical |
| CISOs don't trust "could" analysis | "This DID happen 14,000 times this week" is undeniable |
The risk narrative from the Clarity doc maps perfectly:
- What happened — Standing autonomous authority exists + X executions + sensitive domain touched
- Why it matters — Orphaned owner + scope drift + LLM egress
- What reduces risk — Assign owner, reduce RBAC scope, restrict endpoint
Market positioning upgrade: "Most NHI tools show you what your identities COULD do. SecurityV0 shows you what they DID do — with deterministic proof."
4. Documentation Perspective — Term Validation Updated
The Primer doesn't change the term "Authority Path" — it sharpens what it means. The key documentation update needed:
Current glossary definition:
Authority Path: A 4-node linear projection: Workload → Identity → Destination → Data Domain
Proposed update:
Authority Path: A 4-node linear projection showing execution authority from Workload → Identity → Destination → Data Domain. Two forms: Observed (derived from execution evidence — what actually executed) and Potential (derived from configuration — what could execute). The default view is Observed. The structural backbone of an Exposure.
5. Competitive Positioning (Updated One-Liners)
| Against | Updated positioning |
|---|---|
| SpecterOps | "They simulate what attackers COULD do. We show what autonomous systems DID do — with provenance." |
| Veza | "They map who CAN access what. We map what DID access what, how often, and under whose authority." |
| Wiz | "They find toxic combinations that COULD be exploited. We find authority that WAS exercised — without an owner." |
| All competitors | "Every tool shows potential authority. We show observed authority. That eliminates 90% of the noise." |
6. Action Items (Updated)
| Priority | Action |
|---|---|
| P0 | Update glossary: split Authority Path into Observed vs Potential |
| P0 | Validate execution evidence feasibility (see companion review) |
| P1 | Update path detail UX: default to observed (exercised branches only) |
| P1 | Define "Potential Authority" as secondary view with clear "could also do" framing |
| P2 | Create public concept page: "Observed vs Potential Authority Paths" |
| P2 | Map to OWASP NHI Top 10 with execution-determined framing |
Sources
- Authority Paths Primer (Notion, synced 2026-02-27)
- Clarity: So What? / What Do I Do Now? (Notion, synced 2026-02-27)
- Sprint: 2026-02-25 – 2026-03-12 (Notion, synced 2026-02-27)
- [DRAFT] Drift Intelligence W1 (Notion, synced 2026-02-27)
- [DRAFT] Actionability / Remediation Guidance W1 (Notion, synced 2026-02-27)
- SEO/competitive research (web, 2026-02-27)
- Connector execution evidence analysis (codebase, 2026-02-27)