CISO Analysis: Automation Persistence and Chain-Level Temporal Tracking

Role: CISO, SecurityV0 Automation-Analysis Team (Round 3) Date: 2026-02-13 Classification: Internal -- Security and Compliance Advisory Scope: Whether the platform needs a separate execution_chains collection (or equivalent first-class entity) to track autonomous execution chains over time, analyzed through the lens of security governance, compliance controls, incident response, and audit readiness.

---

Executive Summary

The CEO/founder's instinct is correct: the current data model cannot durably track autonomous execution chains as first-class, listable, temporally-versioned entities. The model tracks the components of chains (identities, roles, permissions, resources) with full temporal machinery, but it does not track the chain itself -- the composite execution flow that a CISO sees as a single "automation" in their environment.

This is not an academic distinction. It is a compliance-critical gap that becomes visible the moment an auditor asks: "Show me how this automation's access changed over the last 90 days." The current model can answer "how did entity X's roles change?" but it cannot answer "how did the AzureGraphRouter chain's effective blast radius change?" without reconstructing 6-8 entities at the target point in time and re-deriving the chain composition. That reconstruction is expensive, fragile (it requires knowing which entities were in the chain at time T, not which entities are in it now), and -- critically -- it has never been tested or validated as a query path.

Bottom line: The platform needs a lightweight execution_chains collection that provides stable chain identity, chain-level temporal snapshots, and a foundation for chain-level findings. This is not optional for audit readiness. The question is not whether but how much -- and the answer is "the minimum that makes chains listable, versionable, and findable."

This analysis maps the gap to specific compliance controls, walks through a concrete incident response scenario, evaluates four implementation options from a security governance perspective, and recommends a phased approach that delivers audit readiness without introducing consistency risks.

---

1. Compliance Requirements Mapping

1.1 SOC2 Trust Service Criteria

CC6.1 -- Logical and Physical Access Controls

Requirement: "The entity implements logical access security measures to protect against unauthorized access to information assets."

The question: Can the current model attest to "what could this automation do at time T"?

Current capability:

The model stores execution_paths on each identity entity, and entity_versions captures point-in-time snapshots. In theory, one could retrieve an entity version for each component of the chain at time T and reconstruct the chain's effective blast radius.

The gap:

The reconstruction requires knowing the chain's composition at time T. Consider the AzureGraphRouter chain:

incident table -> BR: Auto-route -> SI: AzureGraphRouter -> REST: graph.microsoft.com -> OAuth Client -> SP: sn-ticket-router

If at time T, the chain used a different OAuth client (e.g., during a credential rotation), the current model would reconstruct the chain using today's composition and yesterday's entity states -- producing a historically inaccurate chain. The composition itself is not versioned.

Specifically:

Temporal question	Can the model answer it?	Mechanism	Gap
"What roles did SP X have at time T?"	Yes	entity_versions for SP X	None
"What resources could SP X reach at time T?"	Partially	Reconstruct from entity_versions of SP + roles + permissions at T	Requires 4-5 entity version lookups, never tested
"What was the AzureGraphRouter chain's blast radius at time T?"	No	Would require (a) knowing chain composition at T, (b) reconstructing all component entity versions	Chain composition is not versioned
"Which chains included SP X at time T?"	No	No chain-to-entity membership record	Cannot answer without scanning all entities
"Did the chain's access expand between T1 and T2?"	No	No chain-level diff	Must diff N entity versions and re-derive chain, untested

CC6.1 attestation status: PARTIAL. Entity-level access at time T is theoretically reconstructable (via baseline + event replay). Chain-level access at time T is not, because chain composition is ephemeral (computed at query time from current-state relationships, never persisted or versioned).

CC7.1 -- System Monitoring

Requirement: "The entity uses monitoring activities to detect anomalies that could indicate compromise, service disruptions, or other issues."

The question: Can the current model detect "this automation's access expanded"?

Current capability:

The evaluator runs five rules against individual entities: orphaned_ownership, ownership_degraded, scope_drift, dormant_authority, and privilege_justification_gap. The scope_drift rule compares current HAS_ROLE count against baseline HAS_ROLE count on a single identity entity. If roles increased, it fires.

The gap:

Chain-level access expansion is invisible to the current evaluator. Consider:

1. SP sn-ticket-router has 2 roles. A third role (hr_admin) is added. The scope_drift rule fires on the SP. This works.

2. The chain adds a new entity -- a second SP that authenticates to a different target system. The existing SP is unchanged. No scope_drift fires because no individual entity's roles changed. But the chain's blast radius doubled. This is a miss.

3. A role's permissions change (the itil role gains access to a new table hr_case). The role entity is updated but no identity entity changes. scope_drift does not fire because it only checks HAS_ROLE counts, not the permissions those roles grant. This is a miss.

4. A permission's resource changes (the resource hr_case is reclassified from internal to confidential). Nothing in the identity or role chain changes. The chain now has access to confidential data that was previously internal. No finding fires. This is a miss.

Scenarios 2, 3, and 4 are all chain-level access expansions that are invisible to entity-level findings. They require comparing the chain's effective blast radius across time, which requires chain-level tracking.

CC7.1 attestation status: PARTIAL. Entity-level anomaly detection works. Chain-level access expansion detection does not exist.

CC8.1 -- Change Management

Requirement: "The entity authorizes, designs, develops, configures, documents, tests, approves, and implements changes to infrastructure and software."

The question: Can the current model show "who approved this change to the automation's chain"?

Current capability:

The events collection records changes with actor attribution. If bob.chen@corp.com adds a role to the SP, the event records: actor: bob.chen@corp.com, event_type: role_assigned, entity_id: uuid-sp, change_details: {role: hr_admin}.

The gap:

The event references a single entity. There is no way to query "all changes to the AzureGraphRouter chain" because there is no chain identifier. An auditor reviewing change management for this automation would need to:

1. Identify all entities in the chain (today's composition)
2. Query events for each entity
3. Manually correlate which events are relevant to the chain's security posture
4. Determine whether step 1 was the same composition at the time of the events

Step 4 is the critical failure. If the chain's composition changed (an entity was added or removed), the event history for the current chain members may be incomplete -- events for entities that used to be in the chain but no longer are would be missed.

CC8.1 attestation status: CANNOT ATTEST. Change management requires tracking changes to a defined scope. Without chain identity, the scope cannot be defined, and changes cannot be exhaustively enumerated.

1.2 ISO 27001:2022 Controls

A.8.1 -- User Endpoint Devices / Asset Inventory

ISO 27001:2022 replaced A.8.1 with updated asset management requirements, but the principle persists in A.5.9 (Inventory of information and other associated assets): organizations must maintain an inventory of assets including "information processing facilities."

The question: Is an "automation" an information asset that needs lifecycle tracking?

Answer: Yes. An autonomous execution chain is an information processing facility. It ingests data (trigger records), processes it (business logic in script includes), transmits it across system boundaries (REST calls to Microsoft Graph), and modifies records (write-back to incident table). Under ISO 27001, this qualifies as an information processing asset that must be:

1. Identified -- given a unique identifier in the asset inventory
2. Classified -- assigned a classification based on the sensitivity of data it processes
3. Owned -- assigned to an accountable party
4. Reviewed -- subject to periodic review to ensure continued appropriateness

The current model fails criterion 1 (no stable chain identifier), criterion 2 (no chain-level classification -- only component-level sensitivity), and criterion 4 (no mechanism to review a chain as a unit, only individual components).

A.5.9 attestation status: CANNOT ATTEST. The chain is not identifiable as an asset.

A.5.23 -- Information Security for Use of Cloud Services

When execution chains span system boundaries (Entra ID -> ServiceNow, ServiceNow -> Azure Graph API), the cross-system chain constitutes use of a cloud service. A.5.23 requires that "risks related to the use of cloud services are identified and managed."

The gap: The chain's cross-system traversal is represented by AUTHENTICATES_TO edges on individual entity documents. There is no aggregate "this chain uses these external services" view. An auditor assessing cloud service usage cannot enumerate chains that traverse to external systems without performing a graph traversal from every automation identity.

1.3 SOX IT General Controls

SOX ITGC -- If Automations Touch Financial Data

The question: If automations touch financial data, can auditors reconstruct the access chain at any past date?

Analysis: SOX ITGC requires that access to financial reporting systems be controlled, documented, and auditable. If a chain's blast radius includes financial data (e.g., a role grants access to gl_journal or payroll_export), the auditor must be able to determine:

1. Who had access via this chain at any date in the prior fiscal year
2. When access was granted or revoked
3. Who approved the access
4. Whether access was appropriate for the business function

The current model can address questions 1-3 at the entity level (with significant reconstruction effort). It cannot address them at the chain level because:

• "Who had access via this chain" requires knowing the chain's composition at the target date
• The chain composition is ephemeral -- not stored, not versioned
• If the chain changed composition mid-year (e.g., a new SP was added), the auditor would need to reconstruct two different chains and merge their access histories

SOX ITGC attestation status: HIGH RISK. An auditor following the "access chain" from an identity through roles to financial resources can reconstruct entity-level access. But if they ask "show me this automation end-to-end at date X," the platform cannot comply without significant manual work, and that work is error-prone because chain composition is not versioned.

---

2. Incident Response Scenario: The 90-Day Breach

Setup

• Day 0: AzureGraphRouter chain runs normally. Reads incidents, queries Microsoft Graph for user department, writes assignment_group back to incident.
• Day 30: Someone adds hr_admin role to the SP sn-ticket-router in the chain.
• Day 60: The chain now reads HR cases (PII) via the expanded role. The chain itself did not change -- the SP's authority expanded, and the chain inherits that authority.
• Day 90: Data breach discovered. HR data (employee PII) was exfiltrated via the Azure Graph API call, which now has access to HR data through the expanded role.
• Day 91: CISO opens SecurityV0.

Question (a): "What automation was involved?"

Can the current model answer this?

Partially. The CISO would need to:

1. Search for findings related to HR data resources
2. Find a scope_drift finding on SP sn-ticket-router (if the evaluator detected the role addition)
3. From the SP, use the subgraph API to discover upstream automations (reverse RUNS_AS, reverse CALLS)
4. Piece together the chain manually

What's missing: There is no "automation" entity to search for. The CISO cannot type "AzureGraphRouter" into a search box and get a result that shows the full chain. They must know to start from the SP (or a finding on the SP) and navigate backward. If the finding was acknowledged or if no finding fired (scenarios 2-4 from Section 1.1), the CISO has no starting point.

With chain tracking: The CISO searches for "AzureGraphRouter" and gets a chain entity. The chain entity links to all component entities, all chain-level findings, and all temporal versions. Time to answer: seconds instead of minutes.

Question (b): "When did its access change?"

Can the current model answer this?

Yes, at the entity level. The events collection records:

{
  entity_id: "uuid-sp-sn-ticket-router",
  event_type: "role_assigned",
  timestamp: ISODate("2026-01-30"),
  change_details: {
    operation: "Add member to role",
    field_changes: [{ field_name: "relationships", new_value: { role_name: "hr_admin" } }]
  },
  actor: { actor_display_name: "bob.chen@corp.com" }
}

What's missing: The event is on the SP, not on the chain. There is no way to query "all events that affected the AzureGraphRouter chain's access" without knowing the chain's composition and querying events for every component. More critically, the CISO cannot determine from this event alone that the role change affected the AzureGraphRouter chain. The SP might participate in multiple chains. The CISO must manually trace backward from the SP to determine which chains were affected.

With chain tracking: The chain version history shows: "Chain blast radius expanded from [incident, task] to [incident, task, hr_case] on 2026-01-30 due to hr_admin role addition on SP sn-ticket-router." The link from event to chain impact is explicit.

Question (c): "Who approved the role change?"

Can the current model answer this?

Yes, if the event includes actor information. The event's actor field records bob.chen@corp.com. The change_details.additional_details may include an approval ticket if one was present in the audit log.

What's missing: The approval question at the chain level. The role was approved for the SP, but was the impact on the chain approved? Did anyone assess that adding hr_admin to the SP would give the AzureGraphRouter chain access to PII? This is the gap between entity-level change management and chain-level impact assessment.

With chain tracking: A chain-level finding (chain_blast_radius_expanded) fires when a component change expands the chain's effective access. The finding includes: which entity changed, what the chain's blast radius was before and after, and whether the change introduced access to a higher sensitivity tier.

Question (d): "What data was accessible after the change?"

Can the current model answer this?

Yes, but only for the current state. The SP's current execution_paths show access to hr_case (confidential). But answering "what was accessible after the change at Day 30" requires reconstructing the SP's execution paths at Day 30.

What's missing: Materialized execution paths are computed on the current entity state and stored directly on the entity document. They are not versioned independently. When the entity is versioned (via baseline or entity_versions), the execution_paths array is included in the snapshot, but only if a baseline happened to be taken at that exact time.

The entity_versions collection stores snapshots "from baselines" and "on significant changes" (per the database architecture doc). Whether a role addition triggers a snapshot depends on whether the change triggers a finding (it would, via scope_drift). But the snapshot captures the SP's state after the change -- the CISO also needs the state before the change to compute the delta.

With chain tracking: Chain versions capture the chain's aggregate blast radius at each sync. The delta between version N and version N+1 shows exactly which resources were added, removed, or reclassified. No reconstruction needed.

Question (e): "Was the automation actively executing during the exposure window?"

Can the current model answer this?

Yes. The execution_evidence collection records proof of actual execution with timestamps. Query:

db.execution_evidence.find({
  entity_id: "uuid-sp-sn-ticket-router",
  source_timestamp: { $gte: ISODate("2026-01-30"), $lte: ISODate("2026-03-30") }
})

What's missing: This shows the SP executed, but not whether the chain executed. The SP might authenticate to ServiceNow for purposes other than the AzureGraphRouter chain. To confirm chain-level execution, the CISO would need execution evidence for the BR (which may not exist -- BRs lack deterministic execution logs) and would need to correlate the BR's trigger with the SP's sign-in timestamps.

With chain tracking: Execution evidence linked to the chain (not just to individual entities) would show: "The AzureGraphRouter chain executed 847 times during the 60-day exposure window, processing incident records and routing them based on Microsoft Graph API responses."

Incident Response Summary

Question	Entity-Level Answer	Chain-Level Answer	Gap
(a) What automation?	Navigate backward from SP finding	Search by chain name	Discovery path is indirect
(b) When did access change?	Event on SP entity	Chain version diff	No chain-level event aggregation
(c) Who approved?	Event actor on SP	Chain impact assessment	No chain impact evaluation
(d) What was accessible after?	Reconstruct from entity versions	Chain version blast radius	Execution paths not versioned per-change
(e) Was it executing?	Execution evidence on SP	Chain-level execution timeline	No chain-to-execution correlation

Assessment: The current model can answer all five questions, but the answers require manual reconstruction, multi-entity correlation, and assumptions about chain composition stability. In a real incident response, the time cost of this reconstruction is measured in hours, not seconds. Chain-level tracking reduces all five answers to direct lookups.

---

3. Chain-Level vs Entity-Level Findings

Current Finding Types (Entity-Level)

All five current finding rules operate on individual entities:

Finding	Entity Scope	Trigger
orphaned_ownership	Single identity	All owners decayed
ownership_degraded	Single identity	Primary owner decayed, secondary active
scope_drift	Single identity	HAS_ROLE count increased vs baseline
dormant_authority	Single identity	Elevated permissions, no recent activity
privilege_justification_gap	Single identity	Elevated permissions, no evidence of need

What Entity-Level Findings Miss

Scenario 1: Chain blast radius expansion via permission change

The itil role gains access to a new table hr_case (classified confidential). No identity's roles change. No entity-level finding fires. But every chain that includes the itil role now has access to PII.

A chain-level finding would detect: "Chain AzureGraphRouter's blast radius now includes confidential resource hr_case (previously internal-only). Cause: itil role permission scope expanded."

Scenario 2: Chain ownership decay

The AzureGraphRouter chain has 6 entities. 3 have orphaned ownership, 2 have degraded ownership, 1 has active ownership. The current model fires orphaned_ownership on 3 entities and ownership_degraded on 2 entities. But there is no aggregate view that says: "The AzureGraphRouter chain as a whole has 50% orphaned components and 83% degraded-or-orphaned components."

This matters because the chain's effective ownership is the weakest link. If any component in the chain is orphaned, the chain's execution is unaccountable at that link. The chain-level finding aggregates individual findings into an actionable assessment: "This automation chain cannot be governed because 5 of 6 components lack full ownership."

Scenario 3: Chain sensitivity escalation

A resource in the chain's blast radius is reclassified from internal to confidential. No identity or role changes. No entity-level finding fires. But the chain now processes confidential data.

Scenario 4: Chain credential exposure

A credential in the chain (the OAuth client secret) expires but the chain continues executing via a different credential. Entity-level findings track credential state on individual entities. Chain-level tracking would detect: "Chain AzureGraphRouter's authentication method changed from OAuth client A (expired) to OAuth client B (unknown provenance)."

Scenario 5: Cross-system chain degradation

The AUTHENTICATES_TO edge in the chain becomes unresolvable (the target ServiceNow user is disabled). The unresolved_cross_system_auth finding fires on the edge. But the chain-level impact -- "the entire AzureGraphRouter chain is broken because its cross-system link is severed" -- is not surfaced.

Proposed Chain-Level Finding Types

Finding Type	Trigger	What It Detects
chain_blast_radius_expanded	Chain version diff shows new confidential/restricted resources	Automation gained access to sensitive data it did not previously reach
chain_ownership_degraded	>50% of chain components have orphaned or degraded ownership	Aggregate ownership decay makes the chain ungovernable
chain_fully_orphaned	100% of chain components with ownership tracking have decayed owners	No human is accountable for any part of this automation
chain_sensitivity_escalation	Resource reclassification increases chain blast radius sensitivity	Data governance change affects automation access tier
chain_credential_rotation_gap	Credentials in chain have not been rotated per policy	Chain relies on stale authentication material
chain_cross_system_broken	AUTHENTICATES_TO edge in chain is unresolvable	Cross-system automation is severed or degraded
chain_composition_changed	Chain membership differs from previous version	Entities were added to or removed from the automation

These findings require chain-level tracking. They cannot be derived from entity-level findings alone because they depend on the aggregate composition and effective blast radius of the chain, not on individual entity properties.

---

4. Audit Trail Requirements

What an Auditor Needs for a Specific Automation at a Specific Date

An auditor performing a SOC2 Type II examination for the period January 1 - June 30 will request:

1. Chain identity: "Show me the automation called 'AzureGraphRouter' and its unique identifier."
2. Chain composition at period start: "What entities were in this chain on January 1?"
3. Chain composition at period end: "What entities are in this chain on June 30?"
4. Chain changes during period: "What changed in this chain between January 1 and June 30? Who made each change? Was each change approved?"
5. Chain blast radius at any date: "On March 15, what data could this chain access?"
6. Chain execution evidence: "Was this chain actively executing during the period?"
7. Chain ownership at any date: "Who was accountable for this chain on April 1?"
8. Chain findings history: "What security findings were raised against this chain during the period? How were they resolved?"

Can Baseline + Event Replay Reconstruct the Full Chain at Time T?

In theory: The baseline captures all entity states at a point in time. Events between baseline and time T record changes. Replaying events onto baseline entities produces entity states at T. Deriving the chain from those entities produces the chain at T.

In practice: This reconstruction has five failure modes:

Failure mode 1: Chain composition change. If an entity was added to the chain after the baseline but before time T, the baseline does not include it. The reconstruction would miss the entity and produce an incomplete chain.

Failure mode 2: Relationship change. If the RUNS_AS or AUTHENTICATES_TO edge linking two chain components was modified between baseline and T, the reconstruction must replay the relationship change. The events collection records relationship changes, but replaying them onto baseline entities to reconstruct the chain graph is a complex operation that has never been implemented or tested.

Failure mode 3: Cross-system timing. The chain spans Entra ID and ServiceNow. Baselines may be taken at different times for each system. Reconstructing the chain at T requires finding the closest baselines for each system and accounting for the time skew between them.

Failure mode 4: Event retention. Events have a 2-year TTL. If an auditor needs a chain state from >2 years ago, the events may have been purged. Baselines are retained for 1 year by default. If both events and baselines have been purged for the period in question, reconstruction is impossible.

Failure mode 5: Execution path recomputation. The execution_paths array on entity documents is computed at sync time, not stored in events. Reconstructing the chain's blast radius at T requires recomputing execution paths from the reconstructed entity states -- a computation that involves traversing roles, permissions, and resources, all of which must also be reconstructed at T.

What's Missing from the Current Temporal Model for Chain-Level Reconstruction

Missing Element	Why It Matters	How Chain Tracking Fixes It
Stable chain identifier	Cannot search for or reference a chain	Chain document with _id
Chain composition history	Cannot determine which entities were in the chain at T	chain_versions with member list
Chain-level blast radius snapshot	Must recompute from entity states (expensive, fragile)	Pre-computed blast radius in chain version
Chain-level events	Must correlate entity events manually	Chain events that reference chain + component
Chain-level findings	Cannot fire findings on chain properties	entity_id on findings can reference chain

---

5. Options Evaluation (Security Perspective)

Option A: Computed View (No Schema Change)

Description: Reconstruct chains from entity relationships at query time. No new collections.

Security assessment:

Dimension	Rating	Analysis
Data integrity	LOW RISK	No new data surface to become stale or inconsistent
Audit completeness	HIGH RISK	Cannot answer "what did this chain look like 90 days ago" without reconstructing ALL entities in the chain at that point in time. Reconstruction untested, complex, and fragile.
False negative	HIGH RISK	No chain-level findings. Scenarios 1-5 from Section 3 are all false negatives.
False positive	LOW RISK	No chain-level findings means no chain-level false positives
Forensic readiness	POOR	Incident response requires manual multi-entity reconstruction (Section 2)
Compliance	NOT AUDIT-READY	Cannot satisfy CC6.1 (chain-level access at T), CC8.1 (chain-level change history), or A.5.9 (asset inventory)

Verdict: This is the status quo. It fails the audit readiness test. It is acceptable for a prototype but not for a product that claims evidence-grade output.

Option B: Lightweight execution_chains Collection

Description: A new collection with stable chain identity, composition list, and summary metadata. Updated on each sync. No separate versioning collection.

{
  _id: "chain-azuregraphrouter-001",
  tenant_id: "uuid-...",
  chain_name: "AzureGraphRouter",
  chain_type: "cross_system_automation",

  // Composition: ordered list of entity IDs in the chain
  member_entities: [
    { entity_id: "uuid-br-autoroute", role_in_chain: "trigger", entity_type: "identity", subtype: "business_rule" },
    { entity_id: "uuid-si-azuregraph", role_in_chain: "executor", entity_type: "identity", subtype: "system_execution" },
    { entity_id: "uuid-rest-graph", role_in_chain: "target", entity_type: "resource", subtype: "rest_message" },
    { entity_id: "uuid-oauth-client", role_in_chain: "auth", entity_type: "credential" },
    { entity_id: "uuid-sp-sn-ticket", role_in_chain: "identity", entity_type: "identity", subtype: "service_principal" }
  ],

  // Aggregate properties (derived from component entities)
  aggregate_ownership_status: "degraded",  // worst-case across all members
  aggregate_blast_radius: {
    resource_count: 4,
    max_sensitivity: "confidential",
    business_domains: ["it_ops", "hr"],
    contains_pii: true
  },

  // Metadata
  first_observed_at: ISODate("2025-03-10"),
  last_synced_at: ISODate("2026-01-22"),
  composition_hash: "sha256:...",  // hash of member_entities for change detection

  // Finding summary (denormalized for fast listing)
  active_finding_count: 3,
  finding_types: ["orphaned_ownership", "scope_drift"]
}

Security assessment:

Dimension	Rating	Analysis
Data integrity	MEDIUM RISK	Chain document must be kept in sync with entity changes. If an entity's role changes but the chain is not recomputed, the aggregate fields are stale. Staleness window = time between syncs.
Audit completeness	PARTIAL	Chain identity and composition are stable and queryable. But no temporal versioning -- cannot answer "chain state at T" directly. Must still reconstruct from entity versions.
False negative	MEDIUM RISK	Chain-level findings can fire on aggregate properties (ownership status, blast radius sensitivity). But temporal chain findings (blast radius expanded) require diff between chain states, which requires versions.
False positive	LOW RISK	Aggregate properties are derived deterministically from component entities
Forensic readiness	IMPROVED	Chain is searchable. Composition is known. But temporal reconstruction still required for past states.
Compliance	PARTIAL	Satisfies A.5.9 (asset identity), CC8.1 (scope definition). Does not satisfy CC6.1 (chain state at T) without temporal capability.

Verdict: Significant improvement over Option A. Provides chain identity, listability, and aggregate findings. Falls short on temporal queries. Acceptable as Phase 1 if temporal capability is planned for Phase 2.

Option C: Rich execution_chains + execution_chain_versions

Description: Full temporal chain snapshots. Chain versions capture composition and aggregate blast radius at each sync (or on significant change).

// execution_chain_versions
{
  _id: ObjectId,
  chain_id: "chain-azuregraphrouter-001",
  tenant_id: "uuid-...",
  valid_at: ISODate("2026-01-22"),
  expired_at: null,
  sync_version: 42,

  member_entities: [ /* full composition at this point in time */ ],
  aggregate_blast_radius: {
    resource_count: 4,
    max_sensitivity: "confidential",
    business_domains: ["it_ops", "hr"],
    resources: [
      { resource_id: "uuid-res-incident", sensitivity: "internal" },
      { resource_id: "uuid-res-task", sensitivity: "internal" },
      { resource_id: "uuid-res-hr-case", sensitivity: "confidential" },
      { resource_id: "uuid-res-sys-user", sensitivity: "confidential" }
    ]
  },
  aggregate_ownership_status: "degraded",
  composition_hash: "sha256:...",

  // Delta from previous version
  changes_from_previous: {
    entities_added: [],
    entities_removed: [],
    blast_radius_added: ["uuid-res-hr-case"],
    blast_radius_removed: [],
    sensitivity_changed: { from: "internal", to: "confidential" },
    ownership_changed: { from: "active", to: "degraded" }
  }
}

Security assessment:

Dimension	Rating	Analysis
Data integrity	MEDIUM-HIGH RISK	Two sources of truth: entity-level state and chain-level snapshots. If chain version is not updated when a component entity changes, the snapshot diverges from reality. Mitigation: chain recompute must be part of the sync pipeline, same as path materialization.
Audit completeness	EXCELLENT	Chain state at any T is a direct lookup. No reconstruction needed. Blast radius history is pre-computed. Diff is pre-computed.
False negative	LOW RISK	All chain-level findings from Section 3 can fire, including temporal findings (blast radius expanded, sensitivity escalated).
False positive	LOW-MEDIUM RISK	Pre-computed diffs could produce false positives if chain composition is incorrectly derived. Mitigation: deterministic chain derivation from graph relationships.
Forensic readiness	EXCELLENT	Incident response questions from Section 2 are direct lookups. "Chain state at Day 30" is a query, not a reconstruction.
Compliance	AUDIT-READY	Satisfies CC6.1 (chain state at T), CC7.1 (chain-level monitoring), CC8.1 (chain-level change history), A.5.9 (asset lifecycle), SOX ITGC (chain access at any date).

Consistency risk mitigation:

The primary concern is stale chain versions. This is the same class of risk as materialized execution_paths (which are already computed and stored on entity documents). The mitigation is identical:

1. Chain recomputation runs as part of the sync pipeline, after entity updates and before evaluator rules.
2. Chain versions are created only when composition or aggregate blast radius changes (composition_hash comparison).
3. Integrity checks verify chain version consistency against component entity states.

Verdict: Full audit readiness. The consistency risk is real but is the same risk the platform already manages for materialized execution paths. Recommended as the target state.

Option D: Virtual Entity (Chain as entity_type in existing collection)

Description: Add entity_type: "execution_chain" to the entities collection. Use existing entity_versions for temporal tracking.

Security assessment:

Dimension	Rating	Analysis
Data integrity	MEDIUM RISK	Uses existing temporal machinery, so consistency mechanisms are proven. But semantic confusion: the entities collection now contains both source-system entities (things that exist in Entra/ServiceNow) and platform-computed composites (chains derived by the platform).
Audit completeness	GOOD	Leverages entity_versions for point-in-time snapshots. Existing baseline mechanism captures chain state.
False negative	LOW RISK	Evaluator rules can operate on chain entities the same way they operate on identity entities.
False positive	MEDIUM RISK	Chain entity is in the same collection as real entities. Queries that enumerate "all identities" or "all entities" will include chains unless explicitly filtered. This creates confusion in counts, exports, and SCIM endpoints.
Forensic readiness	GOOD	Same temporal query patterns as other entities.
Compliance	GOOD	Asset identity, temporal tracking, change history all available through existing mechanisms.

The semantic confusion problem:

The entities collection currently contains entities that are discovered from source systems: every document has a source_system and source_id. A chain entity has no source system -- it is computed by the platform. This breaks the invariant that (tenant_id, source_system, source_id) is unique, which is enforced by a unique index.

Workaround: Use source_system: "sv0_platform" and source_id: "chain-azuregraphrouter-001". This is technically valid but semantically wrong -- the platform is not a "source system" in the connector sense.

More problematically, the SCIM API (which exports Users from the entities collection) and the OAA exporter (which exports applications from entities) would need to filter out chain entities. The entity_type !== "execution_chain" filter would need to be added to every export query. Missing this filter in one endpoint would leak implementation details into standards-based exports.

Verdict: Workable but creates ongoing maintenance burden from semantic confusion. Every new feature that queries the entities collection must remember to filter chains. The risk of leaking chain entities into SCIM/OAA exports is a compliance issue in itself. Not recommended unless the engineering cost of a separate collection is prohibitive.

---

6. Risk Analysis Summary

Risk Dimension	Option A (Computed)	Option B (Lightweight)	Option C (Rich + Versions)	Option D (Virtual Entity)
Data integrity	None (no data)	Medium (stale aggregate)	Medium-High (stale versions)	Medium (semantic confusion)
Audit completeness	HIGH GAP	Partial	Complete	Good
False negative	HIGH (no chain findings)	Medium (no temporal findings)	Low	Low
False positive	None	Low	Low-Medium	Medium (collection confusion)
Implementation complexity	None	Low	Medium	Low-Medium
Ongoing maintenance	None	Low	Medium (recompute pipeline)	High (filter discipline)
Compliance readiness	NOT READY	Partial	AUDIT-READY	Good

---

7. The "Zombie NHI" Scenario Revisited

SecurityV0's Core Value Proposition

SecurityV0 exists to detect "zombie NHIs" -- autonomous identities that outlive their human owners, accumulate authority, and continue executing without accountability. The platform's five finding types are all variations on this theme:

• orphaned_ownership: The zombie's human controller is gone
• ownership_degraded: The zombie's primary controller is gone, backup exists
• scope_drift: The zombie accumulated more power over time
• dormant_authority: The zombie has power but appears to be sleeping
• privilege_justification_gap: The zombie has power it never uses

How Chain Tracking Enriches Zombie Analysis

With entity-level tracking, the platform detects: "SP sn-ticket-router has no active owner."

With chain-level tracking, the platform detects: "The AzureGraphRouter chain has 6 entities. 3 have orphaned ownership. The chain as a whole processes identity data across 2 systems (ServiceNow + Entra ID), accesses 4 resources including confidential HR cases, executes 847 times per month, and has no fully accountable human at any point in its execution path. The chain is a zombie."

The chain-level finding is qualitatively different from the entity-level finding:

Dimension	Entity-Level Finding	Chain-Level Finding
Scope	"This SP is orphaned"	"This entire automation pipeline is orphaned"
Impact	"SP has 4 execution paths"	"The pipeline processes PII across 2 systems 847 times/month"
Remediation	"Assign an owner to SP X"	"The pipeline needs end-to-end ownership review: BR creator, SI maintainer, REST config owner, OAuth credential owner, SP owner"
Priority	Based on single entity's blast radius	Based on aggregate chain blast radius and cross-system exposure
Governance	"Review SP X's roles"	"Review the entire pipeline: is it still needed? Are all components current? Is the cross-system auth chain valid?"

What's Missing from the Current Model for Chain-Level Zombie Detection

1. No aggregate ownership status. The platform fires orphaned_ownership on 3 entities and ownership_degraded on 2. It does not aggregate: "83% of this chain's components have decayed ownership."

2. No chain-level dormancy detection. A chain can be "dormant" even if individual components are active. If the BR no longer triggers (because the trigger table was deprecated), the chain is dormant even though the SP still has active sign-ins from other uses. This requires chain-level execution evidence.

3. No chain-level scope drift. Individual entities may have stable roles, but the chain's effective blast radius can expand through permission changes, resource reclassification, or composition changes. None of these trigger entity-level scope_drift.

4. No chain-level privilege justification. The chain executes against 4 resources, but only ever writes to 1 (incident table). The chain's access to hr_case, sys_user, and task tables may be unjustified privilege at the chain level, even if each individual role assignment is justified at the entity level.

---

8. Recommendation

The Minimum for Audit Readiness

From a CISO/governance perspective, the following MUST be true for the platform to be audit-ready:

1. Chains must be identifiable. An auditor must be able to enumerate all execution chains in the environment, each with a stable identifier and a human-readable name.

2. Chain composition must be tracked. For each chain, the platform must know which entities compose the chain and their role in it (trigger, executor, auth, target).

3. Chain blast radius must be computable at any date in the retention window. For any date within the baseline + event retention window, the platform must be able to answer: "What resources could this chain access?"

4. Chain-level findings must exist. At minimum: chain ownership aggregate, chain blast radius expansion, chain sensitivity escalation. These cannot be derived from entity-level findings alone.

5. Chain changes must be auditable. All changes to chain composition, blast radius, and ownership must be queryable with actor attribution and timestamps.

Recommended Approach: Phased Option B -> Option C

Phase 1: Lightweight execution_chains (Option B) -- Ship with next release

• New execution_chains collection with stable chain identity
• Chain composition (member_entities list)
• Aggregate properties (ownership status, blast radius summary, finding count)
• Chain recomputation as part of sync pipeline (after path materialization)
• Chain listable in API and UI
• No separate versioning collection yet

This provides: chain identity (requirement 1), composition tracking (requirement 2), chain-level findings foundation (requirement 4).

Estimated security risk: Low. The chain document is a computed aggregate, like execution_paths. Staleness risk is mitigated by recomputing on each sync.

Phase 2: execution_chain_versions (Option C) -- Ship within 30 days

• New execution_chain_versions collection
• Chain versions created on composition or blast radius change
• Pre-computed deltas between versions
• Chain-level temporal findings (blast radius expanded, sensitivity escalated)

This provides: chain state at any date (requirement 3), chain change auditability (requirement 5), full temporal chain findings.

Estimated security risk: Medium. Consistency between chain versions and entity versions must be maintained. The sync pipeline must be atomic: entity updates -> path materialization -> chain recomputation -> chain versioning -> evaluator rules. A failure partway through could produce inconsistent chain versions. Mitigation: transactional chain recompute with rollback on failure.

Why Not Option D (Virtual Entity)

The semantic confusion risk is ongoing and scales with team size. Every new developer who writes a query against the entities collection must remember that entity_type: "execution_chain" exists and must be filtered. In my experience, this filter will be forgotten in at least one endpoint, leading to chains appearing in SCIM exports, OAA payloads, or entity count dashboards. The separate collection approach makes chains invisible to entity queries by default, which is the correct security posture.

Why Not Option A (Status Quo)

The status quo fails the audit readiness test. The CEO/founder's instinct is confirmed by the compliance analysis: the platform cannot attest to chain-level access at time T, cannot fire chain-level findings, and cannot provide a listable automation inventory to auditors. This is not a "nice to have" -- it is a gap that will be discovered in the first SOC2 examination.

---

9. Chain Derivation: How to Compute Chain Membership

A chain is not a user-defined grouping -- it is derived deterministically from the graph. The derivation algorithm:

1. Start from each identity entity with identitySubtype in TRIGGER_AUTOMATION_SUBTYPES (business_rule, scheduled_job, flow_designer_flow).
2. Follow forward edges: CALLS -> EXECUTES_ON -> AUTHENTICATES_VIA -> AUTHENTICATES_TO.
3. Follow RUNS_AS edges to "borrow" the target identity's forward chain.
4. Collect all entities encountered. This is the chain's composition.
5. Compute aggregate blast radius from the terminal identity's (SP's) execution_paths.
6. Compute aggregate ownership from OWNED_BY edges on all chain members.
7. Hash the composition (sorted entity IDs) to produce a composition_hash for change detection.

Chain identity stability: The chain's _id is derived from its "root" trigger entity (the BR or scheduled job). If the BR is renamed, the chain retains its identity. If a new BR is added that calls the same SI, a new chain is created. If the BR is deleted, the chain is marked as deleted but retained for temporal history.

Chain naming: The chain's chain_name is derived from the root trigger entity's display name. For the AzureGraphRouter case: "Auto-route identity tickets via Entra" (from the BR's display name). The CISO can search by this name.

Multiple chains sharing components: The SP sn-ticket-router may participate in multiple chains (if multiple BRs call different SIs that both RUNS_AS the same SP). This is correct -- the SP is a shared component, and each chain has its own identity. Entity-level findings on the SP apply to all chains that include it. Chain-level findings are specific to each chain.

---

10. Implementation Security Requirements

Data Integrity Controls

1. Chain recompute must be idempotent. Running the chain derivation algorithm twice on the same entity state must produce the same chain document. This is enforced by the deterministic derivation algorithm and composition_hash comparison.

2. Chain versions must be immutable. Once created, a chain version document is never updated. New versions are created; old versions have their expired_at set. This mirrors the entity_versions pattern.

3. Chain-to-entity references must be validated. The member_entities list references entity _id values. On chain recompute, verify that all referenced entities exist and are in the expected state. Log warnings for missing or deleted entities.

4. Chain deletion follows soft-delete pattern. When a root trigger entity is deleted, the chain is marked as deleted (with deleted_at timestamp) but not removed. The chain and its versions remain queryable for forensic and audit purposes.

Access Control

1. Chain documents inherit tenant isolation. All chain documents carry tenant_id and are subject to the same compound index scoping as entity documents.

2. Chain API endpoints enforce the same auth as entity endpoints. No new auth model is needed.

3. Chain data is read-only for API consumers. Chains are computed by the platform, not created by users. The API provides GET endpoints only.

Audit Trail

1. Chain creation events. When a new chain is first derived, emit an event: chain_created with chain_id and composition.

2. Chain composition change events. When a chain's composition changes (entities added or removed), emit an event: chain_composition_changed with before/after member lists.

3. Chain blast radius change events. When a chain's aggregate blast radius changes (new resources, sensitivity escalation), emit an event: chain_blast_radius_changed with diff.

These events provide the audit trail required by CC8.1 (change management) and are queryable by chain_id, enabling the "all changes to this chain" query that auditors require.

---

11. Compliance Attestation After Implementation

After Phase 1 (Lightweight Chains)

Control	Status	Evidence
CC6.1	PARTIAL	Chain identity and current-state composition attestable. Point-in-time not yet available.
CC7.1	IMPROVED	Chain-level ownership and blast radius monitoring via aggregate findings. Temporal monitoring deferred.
CC8.1	PARTIAL	Chain scope is defined. Change tracking relies on entity-level events + chain composition hash comparison.
A.5.9	MET	Chains are identifiable, classifiable, ownable, and reviewable as assets.
SOX ITGC	PARTIAL	Chain-level access inventory available for current state. Historical reconstruction still required for past dates.

After Phase 2 (Chain Versions)

Control	Status	Evidence
CC6.1	MET	Chain state at any T is a direct lookup in chain_versions.
CC7.1	MET	Chain-level temporal findings detect blast radius expansion, sensitivity escalation, and composition changes.
CC8.1	MET	Chain change events provide full audit trail with actor attribution.
A.5.9	MET	Full lifecycle tracking: creation, changes, deletion.
SOX ITGC	MET	Chain access at any date within retention window is a direct lookup.

---

12. Dissenting Considerations

Argument Against: "Entity-level temporal tracking is sufficient"

The counterargument: "The platform already has entity_versions, events, and baselines. Any chain state can be reconstructed from these primitives. Adding chain-level tracking creates a redundant data surface that must be kept consistent."

My response: The reconstruction is theoretically possible but has never been implemented, tested, or validated. The five failure modes documented in Section 4 are real. The reconstruction requires knowing chain composition at time T, which is the very thing we do not have. It is like arguing that you can compute a building's structural integrity from the properties of individual bricks -- technically true, but no structural engineer would accept "reconstruct it from the bricks" as a substitute for an actual structural assessment.

The consistency concern is legitimate. But the platform already manages the same class of consistency risk with materialized execution_paths and accessible_by arrays. Chain recomputation is the same pattern: derived data, computed during sync, refreshed on change. The risk is managed, not novel.

Argument Against: "Premature optimization -- we don't have enough chains yet"

The counterargument: "We have one connector pair (Entra + ServiceNow) with a handful of chains. This is an MVP. We can add chain tracking when we have 5+ connectors and hundreds of chains."

My response: The question is not scale but auditability. One chain with 6 entities that processes PII across 2 systems and has orphaned ownership is sufficient to trigger every compliance question documented in this analysis. The auditor will not ask "how many chains do you have?" -- they will ask "show me this chain's history." If we cannot answer that question for chain number 1, we cannot answer it for chain number 100.

Furthermore, chain tracking is easier to implement before the entity population grows. The derivation algorithm is simpler with fewer entities, the versioning volume is lower, and any bugs in the derivation logic are more visible. Adding chain tracking later requires backfilling chain versions from entity versions -- a complex migration that is avoidable if we build it now.

---

13. Summary Position

The CEO/founder is correct that the current data model cannot fit autonomous executions as a separate listable entity long term. The compliance analysis confirms this assessment across SOC2, ISO 27001, and SOX ITGC controls. The incident response scenario demonstrates that chain-level tracking reduces forensic investigation time from hours to seconds. The zombie NHI analysis shows that chain-level findings provide qualitatively richer governance signals than entity-level findings alone.

The recommended approach is:

1. Phase 1 (now): Lightweight execution_chains collection with stable chain identity, composition tracking, and aggregate properties. Enables chain listing, chain-level findings, and asset inventory compliance.

2. Phase 2 (within 30 days): execution_chain_versions collection with temporal snapshots. Enables chain state at any date, temporal chain findings, and full audit trail compliance.

3. Not recommended: Virtual entity in the existing entities collection (semantic confusion risk), computed view with no persistence (audit completeness failure), or deferring chain tracking to a later phase (compliance gap persists).

The engineering cost of Phase 1 is estimated at 2-3 days. The compliance cost of not doing it is an audit finding on every SOC2 examination where ServiceNow automation chains are in scope. The founder's scenario -- "CISO sees automation, SP gets new role, chain gains PII access, breach occurs, CISO needs to trace back" -- is exactly the scenario that chain-level tracking makes answerable.

Build the chains. Version the chains. Find on the chains. This is what makes the platform audit-ready.

---

This analysis was prepared from the CISO perspective for the SecurityV0 automation-analysis team. It is the third in a series of automation analyses, following the initial automation classification advisory (ciso.md) and the execution flow display advisory (02-execution-flow-ciso.md). It addresses the specific question of whether the platform needs persistent, temporal chain tracking and concludes that the answer is yes, with a phased implementation path that balances audit readiness against consistency risk.