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.