W1 Gap Analysis & Sprint Priorities
Date: 2026-02-25 Context: Post-demo strategic alignment — Sergey's email outlining 2-3 week priorities Status: Draft
Strategic Context
Where We Are
Wedge 1 (Exposure Discovery & Assessment) is demoable end-to-end. The job to be done: help a CISO answer "Where does autonomous AI execution exist, and what risk does it create?"
Buyer pain points:
- I don't know what automations/agents exist
- I don't know what they can reach (identities, data, external/LLM egress)
- My identity dashboards look green, but I don't trust them
- I can't explain this risk clearly to leadership
Market Signal
- TPx + Quiron — confirmed value from demo, product feedback received
- Deloitte — scheduled for March (GSI validation)
- VCs — 6-10 targeted meetings planned with strong demo in hand
Email Priorities (next 2-3 weeks)
| Track | Goal |
|---|---|
| Pilots | Convert TPx + Quiron from demo interest to read-only evaluation |
| Product | Finish W1 journey across Foundry + Azure + ServiceNow |
| Fundraising | Re-engage 6-10 funds with strong demo |
| Pipeline | Stand up repeatable "pilot factory" motion |
Product Sequence (maps to CISO buying journey)
triage → containment → fix path → prevent recurrence
↓ ↓ ↓ ↓
"So what?" scope drift remediation (future wedges)
Strategic Lenses
GSI Lens (Deloitte, March)
GSIs care about:
- Scalable deployment model — Can they sell this into existing CISO advisory engagements? The "pilot factory" motion is exactly this: a repeatable insertion playbook a GSI partner could run.
- Risk narrative alignment — Deloitte's cybersecurity practice already tells CISOs "you have blind spots in non-human identity." SV0 gives them a tool to prove it.
- Integration breadth — GSIs want coverage across Azure + ServiceNow + Entra (what enterprises actually run). This is why the connector journey across Foundry + Azure + ServiceNow is product priority #1.
GTM Lens
Classic enterprise sales motion:
- Phase 1 (NOW): Convert demo interest to read-only pilots (TPx, Quiron). Discovery motion — learn insertion friction, not close a deal.
- Phase 2 (Fundraise): 6-10 targeted VC meetings. The demo IS the fundraise asset.
- Phase 3 (Scale): "Pilot factory" = repeatable template: ingest → findings → evidence → review meeting. Becomes the GSI playbook too.
VC Lens
VCs want: (a) a wedge that's tight and demoable, (b) proof of insertion (pilots), (c) a path to expand. The email is structured to show all three.
Platform Implementation Status
What's DONE (strong foundation)
| Capability | Status |
|---|---|
| All 13 evaluator rules including scope_drift | Implemented and operational |
| Evidence packs (9 sections, SHA256 integrity) | Fully working |
| Connectors — entra-servicenow + azure-foundry | Both producing NormalizedGraph |
| Authority path computation (workload → identity → role → resource) | Working |
| UI page skeletons — Overview, Clusters, Exposures, Authority Paths, Identities, Data Domains | Exist in codebase |
| Scope drift rule | Detects role count increase over time, MEDIUM severity |
Demo seed data (seed-demo-w1.ts) | 8 workloads, 30+ findings, 6 risk clusters |
Evaluator Rules: Complete Inventory
Core Rules (Phase 1-6, stable)
| Rule | Severity | Description |
|---|---|---|
orphaned_ownership | critical | No OWNED_BY or CREATED_BY edges |
dormant_authority | high | Execution paths exist but no evidence >90 days |
scope_drift | medium | Role count increased vs earliest version |
privilege_justification_gap | medium | Elevated resource access with no matching activity |
W1 Rules (all implemented)
| Rule | Severity | Description |
|---|---|---|
unproven_execution | high | Workload can execute autonomously but no execution evidence linked |
unknown_identity_binding | high | Workload has no deterministic RUNS_AS |
reachable_sensitive_domain | medium/high | Execution paths to confidential/restricted resources |
llm_egress | high | Workload has egress_category: "llm" |
external_egress | medium | Workload has egress_category: "external" |
ownership_ambiguous | medium | Only group/team owners, never had individual owner |
ownership_unknown | medium | Insufficient metadata to determine ownership |
unresolved_cross_system_auth | medium | oauth_app with unlinked binding_status |
What's MISSING (the gaps that matter for pilots)
Each gap has a detailed implementation plan linked below. Plans include problem description, architectural analysis, demo data requirements, and step-by-step implementation details.
Gap 1: Exposure Aggregation APIs
Impact: W1 UI pages exist but backend APIs diverge from spec. Overview/Clusters/Exposures pages need identity-level and workload-level aggregations, enriched exposure computation, and full 6-panel detail view.
Detailed plan: 2026-02-25-exposure-aggregation-apis.md
Key deliverables:
- Enhance
posture/summarywith identity_counts and workload_counts - Add identity_count, workload_count, sensitive_domains, priority to risk clusters
- Rewrite exposures list to authority-path-based computation with deterministic EXP-{hash} IDs
- Add 5 panels to exposure detail (ownership_breakdown, workload_metadata, identity_binding, execution_evidence_summary, path_summary)
Effort: 8-12 hours
Gap 2: Remediation Content Generation
Impact: CISOs see findings but get generic boilerplate instead of context-aware guidance. Evidence packs have a RemediationSection type but it's populated with static, one-size-fits-all strings that never mention entity names, source systems, or specific risks.
Detailed plan: 2026-02-25-remediation-content-generation.md
Key deliverables:
- Context-aware remediation templates for all 13 finding types (referencing entity names, roles, resources, sensitivity)
- Structured actions with priority (immediate/short_term/ongoing) and rationale
- New RemediationPanel UI component with priority badges
- "Recommended Actions" card on Finding Detail page
Effort: 1-2 days
Gap 3: Scope Drift UX
Impact: Rule fires correctly but the "so what" is missing — no visual showing WHAT roles were added, WHEN they were added, and WHAT they now grant access to.
Detailed plan: 2026-02-25-scope-drift-ux.md
Key deliverables:
- New
scope_drift_detailevidence pack section with per-role resource attribution - Drift timeline visualization (vertical timeline showing role additions at each sync)
- Before/after blast radius comparison
- Expose
evidence_refsin finding detail API - Intermediate seed sync for 3-point drift timeline
Effort: 1-2 days
Gap 4: Azure Foundry ARM Role Normalization Bug
Impact: azure-foundry incorrectly normalizes ARM roles ("use" instead of "admin"/"execute"), missing write-level findings. 360 lines of duplicated Azure code across connectors.
Detailed plan: 2026-02-25-shared-azure-modules.md (Draft v2, peer-reviewed, 8 findings resolved)
Key deliverables:
- Shared
sv0_azurepackage with unified arm_roles, arm, arm_scope, entra, auth, node_ids modules - Bug fix: azure-foundry ARM action normalization (substring matching → explicit role mapping)
- 4-phase migration (arm_roles first to fix bug, then arm_scope+arm, auth+entra, node_ids+platform_client)
- CI workflow updates for shared code triggers
Effort: 2-3 days
Gap 5: Function Key Authority Paths
Impact: Function key-authenticated scheduled jobs produce no authority paths. Two independent gaps: (1) ARM API can't find Function App (infrastructure), (2) ARM role modeling skips Permission node (connector code).
Detailed plan: 2026-02-25-function-key-authority-paths.md (Draft v2.1, peer-reviewed, 5 findings resolved)
Key deliverables:
- Grant ARM Reader access on subscription (infrastructure)
- Fix ARM role authority chain: Role → GRANTS → Permission → APPLIES_TO → Resource (matching OAuth pattern)
- ARM role-aware action semantics with privilege precedence
- All three ARM scope levels (resource, resource group, subscription)
- 6 new tests (unit + integration)
Effort: 1-2 days
Gap 6: Pilot Readiness (not covered by engineering plans)
Impact: All 5 gaps above are product/engineering internals. The email's #1 priority is converting TPx + Quiron to read-only evaluations — that requires operational readiness that no plan currently addresses.
What's Needed
| Item | Description | Owner |
|---|---|---|
| Tenant onboarding checklist | Step-by-step: create tenant → configure connector credentials → run first scan → verify findings → share read-only access | TBD |
| Permissions matrix | What read-only access means: which API endpoints, which UI pages, what data is visible. Document explicitly for pilot customers. | TBD |
| Time-to-first-finding KPI | From "customer says yes" to "they see their first finding" — target < 1 day. Measure and optimize. | TBD |
| Rollback path | If a pilot goes wrong: how to wipe a tenant's data, revoke access, decommission connector credentials. Must be documented before sharing access. | TBD |
| Read-only validation | Verify the platform truly cannot modify source systems. Document the read-only constraint with evidence (connector permissions audit, API key scopes). | TBD |
| Pilot evaluation template | Structured outcome document: what was found, what it means, next steps. This is the "review meeting" artifact for the pilot factory. | TBD |
This should be a separate plan document — not an engineering implementation plan, but an operational readiness checklist. Target: ready before first pilot deployment.
Priority Map (aligned to email)
Priority 1: "So what / what do I do now?"
- Enhance 4 exposure aggregation APIs (identity-level counts, multi-identity exposures)
- Populate remediation actions per finding type
- Wire UI pages to real endpoints (including cluster cards and exposure detail panels)
- Update snapshot writer to persist new posture fields
- This is what makes the demo land for pilots
Priority 2: Scope drift
- Rule: DONE
- Missing: drift timeline visualization, "N roles added since [date]" narrative, blast radius of new roles
- This is the "containment" step in the CISO buying sequence
Priority 3: Remediation guidance
- Define action templates per finding type
- Populate during evidence pack assembly
- Surface prominently in Finding Detail UI
- This is the "fix path" step — earliest start, not full implementation
Priority 4: Connector journey completion (single critical path)
Gaps 4 and 5 overlap on the same ARM role normalization/modeling code and must be sequenced as one workstream to avoid rework:
- First: Shared Azure modules Phase 1 (
arm_roles.py) — fixes the active normalization bug - Then: Function key authority paths (Task 2) — uses the now-correct shared
arm_rolesfor Permission node creation - Then: Shared Azure modules Phases 2-4 — extract remaining shared code
The function-key authority path plan's ARM_ROLE_ACTIONS dict and normalize_arm_action() should import from the shared module rather than defining them inline in transformer.py. This avoids creating a third copy of the same constants.
Canonical sequence:
shared-azure-modules Phase 1 (arm_roles.py)
→ function-key-authority-paths Task 1 (ARM Reader access)
→ function-key-authority-paths Task 2 (code fix, imports from sv0_azure.arm_roles)
→ shared-azure-modules Phases 2-4 (remaining extraction)
Implementation Sequencing
File Collision Map
Several plans touch the same files. This is the canonical merge order:
| File | Gap 1 (APIs) | Gap 2 (Remediation) | Gap 3 (Scope Drift) |
|---|---|---|---|
src/evidence/sections.ts | — | Replaces buildRemediation | Adds buildScopeDriftDetail |
src/domain/evidence-packs/types.ts | — | Expands RemediationSection | Adds ScopeDriftDetailSection |
ui/src/components/findings/EvidencePackViewer.tsx | — | Adds RemediationPanel rendering | Adds ScopeDriftDetail rendering |
ui/src/pages/FindingDetail.tsx | — | Adds "Recommended Actions" card | Adds ScopeDriftDetail panel |
ui/src/api/api-types.ts | Updates posture/cluster/exposure types | Adds RemediationAction type | Adds scope_drift_detail type |
src/workers/handlers/evaluate-findings.ts | Updates snapshot writer | — | — |
src/workers/handlers/build-evidence-pack.ts | — | — | Adds historical role loading |
Merge order: Gap 1 backend → Gap 2 backend → Gap 3 backend → Gap 2 frontend → Gap 3 frontend → Gap 1 frontend
Backend phases are largely independent (different files). Frontend phases must merge sequentially because Gap 2 and Gap 3 both modify EvidencePackViewer.tsx and FindingDetail.tsx.
Estimated Effort (with ownership and target dates)
| Work Item | Days | Owner | Target | Blocks |
|---|---|---|---|---|
| Exposure aggregation APIs | 2-3 | TBD | Week 1 (Mar 4) | Pilots (UI needs real data) |
| Remediation content generation | 1-2 | TBD | Week 1-2 (Mar 7) | "So what" experience |
| Scope drift UX enhancements | 1-2 | TBD | Week 2 (Mar 11) | Demo narrative |
| Connector critical path (shared modules + function key) | 2-3 | TBD | Week 1-2 (Mar 7) | Connector coverage |
| Pilot readiness checklist | 1 | TBD | Week 1 (Mar 4) | First pilot deployment |
| Total | 7-11 days | Mar 4-11 |
Week 1 (Feb 25 - Mar 4): Foundation
- Gap 1: Exposure aggregation APIs (backend + snapshot writer)
- Gap 4/5: Shared Azure modules Phase 1 + function key authority paths
- Gap 6: Pilot readiness checklist (parallel, non-engineering)
Week 2 (Mar 4 - Mar 11): Polish
- Gap 2: Remediation content generation (backend + frontend)
- Gap 3: Scope drift UX (backend + frontend, merges after remediation)
- Gap 1: Exposure aggregation APIs (frontend — uses finalized backend shapes)
- Gap 4/5: Shared Azure modules Phases 2-4 (cleanup, non-blocking)