Sprint: 2026-02-25 - 2026-03-12

The purpose of this roadmap sprint is to address the following key requirements to continue to de-risk the business:

1. Finish wedge 1 support across Foundry + Azure + ServiceNow, ensuring that
2. All data is deterministically reconstructed
3. Everything is correctly displayed on the dashboards
4. Strengthen the app ahead of pilots + meeting with Deloitte, in this order:
5. “so what / what do i do now?”
6. scope drift
7. remediation guidance

What we are NOT doing right now:

• Adding more surfaces. We will win on depth, not coverage. In the conversations we had so far, coverage hasn’t come up once. Depth is always what’s discussed.

Details:

Clarity: so what?/ what do i do now?

Document date: 2026-02-27

Strategic Context

CISOs today:

• Feel pressure to say yes to AI.
• Do not want to be the headline.
• Lack visibility into what autonomous agents are actually doing.

If Securityv0 disappeared tomorrow, CISOs would lose the only canonical map of autonomous execution authority in their environment.

We double down on:

• Deterministic authority graph
• Execution lineage
• Ownership decay
• Approval workflows
• Evidence for audit

We do not drift into:

• Risk scoring gimmicks
• Behavior detection arms race
• Alerting-first positioning

Securityv0 is the control-plane system of record for autonomous execution authority.

Objective

Restructure the cluster experience to:

• Remove cognitive load.
• Anchor on observed execution authority (evidence-based).
• Provide prevention-oriented governance guidance.

CISO sees verdict and risk posture.

Analyst sees traceable evidence.

The experience must pass a <5 second comprehension test.

This will strengthen our moat. Most security tools focus on potential authority. We anchor on observed authority. By doing that, we eliminate 90% of the noise that forces a CISO to think.

Core Principle

We distinguish between the strategic layer in ( CISO) and the analyst layer ( technical lead or security operations analyst ) while offloading the thinking and correlation to the product itself.

All CISO-facing views must be execution-determined and evidence-backed.

We describe:

• What authority was exercised
• Against which domain
• How often
• Under what governance condition

We do not describe:

• Theoretical access
• Unused roles
• Hypothetical blast radius

Observed authority is primary. Standing authority and blind spots are surfaced explicitly.

Mental Model

Overview → Cluster Exposure Brief → Authority Paths → Path Evidence

Each layer progressively increases technical depth. Remediation guidance remains advisory; details are in Actionability and remediation guidance (W1).

Step 1: Authority Prioritization (The “I Didn’t Know This Was Running” Layer)

UX Details: Overview page (Authority Prioritization)

Document date: 2026-02-27

This page maps to Step 1: Authority Prioritization (The “I Didn’t Know This Was Running” Layer)

Task

Modify to:

• Functional cluster name (not attribute-based)

Current	Cluster Title
Orphaned + Sensitive	Unowned Sensitive Access
Orphaned + Sensitive + LLM	Unowned Sensitive Access with LLM
Unbound + Sensitive	Unbound Sensitive Access
LLM Egress	LLM Data Egress
Orphaned + External Egress	Unowned External Egress
Dormant + External	Dormant External Access

• 5-second verdict sentence (execution-determined). The verdict summarizes observed activity, not telemetry details. Format:

<N> autonomous identities accessed <scope> <X> times in the last 30 days.

If a governance failure exists, append a short clause: — <governance condition>.

Examples:

Unowned Sensitive Access

13 autonomous identities accessed sensitive systems 681 times in the last 30 days — none have an assigned owner.

Unowned Sensitive Access with LLM

6 autonomous identities sent sensitive data to an LLM 142 times in the last 30 days — none have an assigned owner.

Unbound Sensitive Access

9 autonomous identities accessed sensitive systems 214 times in the last 30 days without a bound automation.

LLM Data Egress

4 autonomous identities sent data to LLM endpoints 87 times in the last 30 days.

Unowned External Egress

5 autonomous identities sent data outside the organization 63 times in the last 30 days — none have an assigned owner.

Dormant External Access

3 autonomous identities retain external access but have not executed in the last 30 days.

• Risk badge (clear, deterministic)

Critical

Sensitive domain + active execution + governance failure

High

Sensitive domain + active execution

Moderate

Governance failure but limited or no execution

Low

Dormant authority

• Keep paths + execution count

Remove:

• Attribute-style framing as primary label
• Anything that feels like a filter category instead of a threat definition

This page becomes: “Which autonomous authority is actively unstable?”

Purpose

Surface actively exercised autonomous authority touching sensitive domains.

Rules

• Rank by observed execution (Grade A).
• Activity required for prominence.
• Sensitivity + governance failure determine severity.
• Dormant authority remains visible but deprioritized.
• No probabilistic scoring.
• Surface standing authority without runtime evidence (Grade C) as governance gaps.
• Do not prioritize based on theoretical access.

Per Cluster Display

• Functional authority label (not attribute labels like “Orphaned + Sensitive”).
• Verdict sentence (execution-determined)
• Deterministic risk badge.

Outcome

Display

• What is actively running.
• What is unaudited.
• Where governance is decaying.

Step 2: Authority Exposure Brief (What Happened?)

UX Details: Authority Exposure Brief

Document date 2026-02-27

This replaces the current “header + table” flow. The table must appear below the narrative. The page is scrollable, structured top-to-bottom.

Section A — What Happened (Observed Authority)

One short execution-determined narrative.

Section B — Am I Exposed?

• paths
• Executions (30d)
• Domains exercised
• Endpoint type
• Active vs dormant

Section C — Governance Condition

• Orphaned?
• Drift?
• Identity reuse?
• Long-lived?

Section D — How Do I Fix It?

1–3 remediation guidance bullets.

Section Table

Button: “View Authority Paths (N)”

Then show filtered out authority path table. This prevents cognitive overload.

This replaces the current “header + table” flow.

Section A — What Happened (Observed Authority)

Describe:

• Authority exercised
• Domain touched
• Endpoint type invoked
• Execution frequency (30d)
• Evidence source.

Only exercised authority. No potential permissions. No hypothetical language.

Section B — Am I Exposed? (scale & activity)

Display:

• of authority paths

• Total executions (30d)
• Sensitive domains exercised
• Endpoint types invoked
• Active vs dormant state

Purpose: quantify scale and velocity.

Section C — Governance Condition (why this is unstable)

Display instability drivers:

• Orphaned identities
• Scope drift
• Long-lived tokens
• Identity reuse across multiple paths
• Lack of runtime telemetry (if applicable).

This section explains structural amplification.

Blind spots are first-class findings.

Section D — How Do I Fix It? (remediation guidance)

Provide 1–3 recommended actions tied directly to exercised authority.

Examples:

• Restore ownership and revalidate approval
• Convert long-lived token to JIT
• Restrict external endpoint invocation
• Reduce scope to exercised domain
• Enable required runtime logging (if Grade C).

No enforcement logic. Advisory only.

After Section D

“View Authority Paths (N)” → table.

Step 3: Authority Evidence (execution lineage)

UX Details: Authority Path Detail (Authority Evidence)

Only minor refinement to the current page:

• Current view = observed authority only.
• Add collapsed panel: “Additional Standing Authority (Not Exercised)”

Audience: Analyst / Technical Lead.

Purpose

Provide deterministic traceability of exercised authority.

Rules

• Default view shows observed execution lineage only.
• Show only exercised branches.
• Collapse potential/latent authority separately.
• Always show evidence basis:
• Source system
• Timestamp
• Log reference (if available)

Outcome

• Verifiable execution proof.
• Clear separation between exercised and potential authority.
• Audit-ready defensibility.

Implementation Notes for Claude

• Do not change the number of top-level screens.
• Modify Overview and Cluster Detail.
• Path Detail requires minor refinement (observed vs potential separation).
• Remove attribute-based cluster naming as primary framing.
• Remove any probabilistic scoring.
• Always display evidence basis for execution-confirmed authority.
• Do not introduce new terminology.
• Keep CISO-facing sections compact (no dense paragraphs).

Acceptance Criteria

The product must clearly answer:

1. What happened? (Execution-confirmed authority exercised.)
2. Am I exposed? (Scale, activity, governance condition, blind spots.)
3. What should I do? (Clear prevention-oriented remediation guidance.)

Without requiring the user to interpret a table.

Drift intelligence (W1)

Date 2026-03-04

This spec is related to

Drift UX

This spec explains the user experience changes that need to be made to incorporate drift intelligence.

Drift signals appear in two UX layers: the Authority Path, where evidence is shown, and the Cluster, where drift is summarized as a governance instability driver.

Authority Path Level Drift

• Drift is path specific
• Drift is surfaced as a governance condition, not as a historical event log.
• The evidence is tied to this authority chain
• The change must be explainable with execution evidence

Changes to make to the Authority Path UX:

1. Rename “Active risk conditions” to “Active Governance Conditions”
2. Improve the Scope Drift Card: change the current card to
3. Status: “Since 30d”
4. Condition: “This authority path gained an additional role. The automation now executes with broader privileges than previously observed on this authority path.”
5. Evidence:
   1. Privilege added: sql_admin_reader
   2. Previously observed roles: sql_clinical_reader
   3. Detected: 1d ago
6. Remove the “intervals” part.

Cluster Level Drift

This specifically links to Section C — Governance Condition (why this is unstable)

Cluster level will never show drift explanations or evidence. It only displays the presence of drift as a governance driver (e.g., “Scope drift present across 3 authority paths”).

Why now

Drift intelligence is strong because:

• It’s execution-driven
• It reinforces your “deterministic” positioning
• It makes the graph feel alive
• It’s enterprise-relevant
• It’s differentiated

But scope drift must not feel academic. It must be tied to:

“This execution authority expanded beyond its previously observed scope.”

Which means scope drift comes hand in hand with Actionability and remediation guidance (W1) to be useful.

What “Drift” Means for Securityv0

Drift for Securityv0 is:

Change in autonomous execution authority or its reachable surface over time.

Specifically:

• Identity privilege expansion
• New external tool/API reach
• New sensitive domain reachable
• Ownership becoming invalid

If it doesn’t relate to autonomous execution paths, it’s out of scope.

Scope

Drift does not require real-time monitoring. Securityv0 isn’t a runtime security tool. Drift detection is based on deterministic comparison of the current execution authority graph against previously observed state.

Drift Explanation

State:

• Every drift condition must include a security explanation
• Explanations describe how execution authority changed
• Explanations are authority path specific
• Explanations are derived from deterministic evidence

Then the UX spec defines how it appears in the card.

Authority Drift

Track changes in:

1. Service principal role assignments
2. App registration permission grants
3. OAuth scopes
4. API credentials linked to automation
5. Automation identity replaced
6. Automation identity gains additional roles
7. New identity introduced into an execution chain

Surface as:

• “Authority expansion detected”
• “New privilege added”

This is deterministic and metadata-based.

Reachability Drift

Compare previous reachable graph vs current reachable graph. Reachability drift is identified by comparing the previously observed execution graph with the current graph.

This represents deterministic graph delta detection. We are showing deterministic net-new exposure surface.

Reachability is derived from the computed authority path graph and reflects the set of systems, APIs, and data domains reachable from an automation identity.

For example,

Agent A → ServiceNow API → Internal DB

… now becomes this:

Agent A → ServiceNow API → Internal DB → Azure OpenAI

In this example, nothing about the identity changed, but reachability changed. This is reachability drift.

Ownership Drift

Track:

• Owner removed
• Owner disabled

They do not require HR integration.

Drift UX

Actionability and remediation guidance (W1)

Date: 2026-03-05

Purpose

Drift intelligence explains what changed on an authority path. Security teams still need to know: What structural change would reduce exposure on this path?

Actionability provides deterministic remediation guidance tied to a single authority path. It identifies a small number of structural changes that reduce:

• reachable systems
• sensitive data access
• privilege scope
• governance instability

The feature is advisory only. No workflow automation. No enforcement. No ticketing logic.

Placement in the Authority Path UX

Authority Path page structure:

1. Path header
2. Execution-derived authority graph
3. Active Governance Conditions (renamed from “Active risk conditions” according to the drift ux spec)
4. Top Risk Reducers (new section)
5. Other panels

Remediation guidance appears only in Top Risk Reducers.

Narrative explanation exists only in the cluster-level Authority Exposure Brief.

Top Risk Reducers

Top Risk Reducers lists the highest-impact structural changes that reduce exposure on the authority path.

Characteristics:

• deterministic
• evidence-backed
• tied to specific path elements
• ranked by exposure reduction impact

Reducers represent operator actions, not automated fixes.

Reducer Signals

Reducers are generated when governance conditions or structural signals exist on the path.

Common signals:

• invalid or missing owner
• scope drift
• excessive privilege
• sensitive data access
• external LLM endpoint invocation
• identity reuse across automations
• unnecessary system reachability

Signals explain why a reducer appears. They appear as tags on the reducer entry.

Example:

Invalid owner + Scope drift
Scope drift + LLM egress
LLM egress

Reducer Types

Reducers correspond to structural changes operators can perform in the source system.

Examples:

Ownership governance

• assign valid owner
• restore ownership after departure

Privilege reduction

• remove expanded role
• reduce scope to exercised authority

Integration control

• restrict LLM endpoint access
• remove unused connector

Identity isolation

• dedicate identity to automation
• remove shared execution identity

Reducers must target specific nodes or edges on the authority path graph.

Generic advice is not allowed.

Impact Ranking

Reducers are ranked by expected reduction in authority exposure on this path. Ranking prioritizes actions that:

1. remove access to reachable systems
2. eliminate sensitive domain access
3. reduce privilege scope
4. shrink automation blast radius

Only max top 3 reducers are shown by default. Additional reducers may exist but are hidden unless expanded.

Reducer Entry Structure

Each reducer entry must contain:

Action

The operator action to take.

Example:

Remove role granting LLM endpoint access

Reduction Effect

One sentence explaining the exposure reduction.

Example:

Eliminates highest-risk vector: expanded scope reaching LLM egress.

Signals

Tags explaining the triggering conditions.

Example:

Scope drift + LLM egress

Applies To

Which path element the action targets.

Examples:

Role: sql_admin_reader
Identity: svc-foundry-ascribe-prod
Connection: Billing_Payment_Methods
Endpoint: external LLM

Evidence

Links to graph nodes or evidence objects confirming the condition.

UX Rules

Top Risk Reducers must follow these constraints:

• show maximum 3 reducers by default
• reducers must be unique actions
• duplicate reducers must be merged
• reducers should avoid bundling unrelated fixes
• each reducer must link to graph evidence

Reducers must remain path-specific. They should never describe remediation for the entire cluster.

Cluster-Level Relationship

Cluster view contains the Authority Exposure Brief, which answers:

• What happened?
• Am I exposed?
• Why is this unstable?
• How do I fix it?

Cluster remediation guidance is aggregated from authority path reducers.

Clusters may show:

Top Risk Reducers Across Paths

Each item links to the authority path where the reducer applies. Clusters do not generate new reducers.

Definition of Done (W1)

The system can:

• detect governance conditions on authority paths
• generate deterministic risk reducers from those signals
• rank reducers by exposure reduction impact
• display Top Risk Reducers in the authority path view
• aggregate reducers at the cluster level

Security teams can immediately see which structural change on this path meaningfully reduces exposure.