CISO Advisory: Automation Inventory Risk Assessment
Role: CISO Advisor, SecurityV0 Automation Analysis Team Date: 2026-02-12 Classification: Internal -- Security Advisory Scope: ServiceNow automation inventory filtering strategy and compliance implications
Executive Summary
SecurityV0 currently filters 77 of 92 identity entities (84%) from its platform ingestion pipeline, classifying them as internal_inventory -- internal-only Flow Designer flows with zero executions, no external egress, and no identity binding. This analysis challenges the assumption that these entities represent acceptable noise and evaluates the decision against enterprise security posture, compliance requirements, and threat modeling fundamentals.
Hypothesis: Filtering 77 automations pre-ingest is a defensible engineering optimization for the Phase 1 pilot, but it is NOT acceptable as a permanent architecture decision for a product that claims to provide "complete inventory of autonomous execution authority." The filtering creates a compliance gap, undermines the platform's evidence-grade positioning, and ignores the capability-based threat model that enterprise buyers require.
Bottom line: Ingest everything. Filter nothing. Let the UI and API handle relevance tiers. The 77 entities should live in the platform's database with their security_relevance: internal_inventory classification intact, queryable by auditors, and visible via a toggle. The current pre-ingest filtering approach transforms a presentation-layer decision into a data-loss decision.
1. The Dormant Automation Threat Model
1.1 Why 0 Executions Does Not Equal 0 Risk
The current filtering logic treats execution_count_30d: 0 as a primary signal for exclusion. This conflates two fundamentally different states:
| State | Meaning | Risk |
|---|---|---|
| Confirmed dormant | We have execution monitoring in place, and it shows zero activity | Low (but not zero) |
| Unobserved | We cannot confirm whether the automation ran because our monitoring does not cover its trigger type | Unknown (potentially high) |
The distinction matters. The platform's own documentation acknowledges that Business Rules and Script Includes have "no deterministic SN-side execution log" (transformer.py, lines 1060-1064). The execution_count_30d: 0 value for these types means "we have no data," not "confirmed zero runs." For the 22 flows with execution_mode: unknown, we cannot even classify HOW they would run, let alone confirm they have not.
When an auditor asks "can you confirm these 77 automations have not executed in the past 30 days?", the honest answer is "no -- we can confirm zero executions for flows with sys_flow_context records, but we lack execution telemetry for several automation types." This is a material qualifier that must accompany any filtering decision.
1.2 Scenario: The Dormant Weaponization Attack
Consider the following attack chain:
- Attacker gains write access to a ServiceNow instance (via compromised admin credentials, supply chain, or insider threat)
- Attacker identifies "Knowledge - Approval Publish" -- a dormant flow that references the
sys_usertable (identity data domain) and has 0 executions - Attacker modifies the flow to exfiltrate user data on each trigger, adding an HTTP action to an external endpoint
- The flow activates when a knowledge article enters the approval process -- a legitimate business event
- Because SecurityV0 filtered this flow pre-ingest, there is no baseline for the flow's configuration. No "was vs. is" delta is possible. The modification is invisible.
The attack succeeds precisely BECAUSE the flow was dormant. An actively executing flow has a baseline behavior pattern that anomaly detection can reference. A dormant flow has no such baseline -- modifying it creates no detectable deviation because there was nothing to deviate from.
This is the core of the dormant automation threat model: dormant automations are attack surface, not noise. They are the digital equivalent of an unlocked door that nobody walks through -- until an attacker does.
1.3 Scenario: The Latent Trigger Activation
45 of the filtered flows have execution_mode: autonomous -- they are configured to execute automatically on events like record creation, updates, or schedule triggers. They have zero executions only because the specific trigger condition has not occurred recently. This is NOT the same as being unable to execute.
Consider a flow triggered by record_create on a table that receives new records quarterly (e.g., sn_compliance_audit or contract_renewal). The flow has zero executions in the 30-day window because the trigger condition occurs outside that window. The flow IS autonomous. It IS active. It WILL execute when the next record arrives. Filtering it as "noise" creates a gap in the automation inventory that will only become apparent when the flow activates -- potentially with stale or inappropriate configuration.
1.4 The "User Who Initiates the Session" Privilege Model
Multiple filtered flows use "User who initiates the session" as their run_as identity. This run-as model means the flow executes with the permissions of WHOEVER triggers it. This is a privilege amplification vector:
- If a privileged admin triggers the flow, it executes with admin-level authority
- If the flow is modified to perform unauthorized actions, the actions inherit the triggering user's privilege level
- The flow itself has no fixed permission scope -- its blast radius is the UNION of all possible triggering users' permissions
This is not a theoretical concern. It is a known ServiceNow security pattern that has been exploited in the wild. Filtering these flows from the inventory means we cannot perform blast-radius analysis on them, even though their blast radius is potentially the largest of any automation type (because it inherits the highest-privileged user who could trigger it).
2. The Pre-Ingest Filtering Problem
2.1 Architecture: Where Filtering Happens Matters
The current implementation filters entities at the connector layer, before they reach the platform database:
Connector discovers 92 identity entities
|
v
transformer.py: filter_internal_inventory=True
|
v (77 entities removed)
|
NormalizedGraph with 15 entities
|
v
Platform ingestion API
|
v
MongoDB: 15 entities stored
This is architecturally wrong. The connector's job is to DISCOVER and NORMALIZE. The platform's job is to STORE, EVALUATE, and PRESENT. Filtering at the connector layer means:
- The platform has no knowledge that 77 entities exist. It cannot report on them, query them, or include them in compliance attestations.
- The filtering logic is embedded in Python connector code, not in the platform's configurable rules engine. Changing the filtering criteria requires a connector code change and redeployment, not a UI toggle.
- The decision is irreversible per sync cycle. If the criteria change (e.g., a flow gains external egress between syncs), the platform cannot retroactively include it because the previous sync's data was never stored.
- Audit trail is broken. There is no record in the platform that 77 entities were discovered and filtered. The platform's sync metrics will show 15 entities discovered, which is factually incorrect.
The platform's own documentation recommends Option B (platform-side filtering) or Option C (connector tags + platform filters) over Option A (connector-side filtering). The 2026-02-12-automation-filtering-graph-strategy.md document explicitly states: "Don't do this. Discovery should be broad." Yet the implementation uses the approach the documentation warns against.
2.2 The Attestation Gap
When an auditor reviews SecurityV0's output, they will see:
- "92 total identity entities discovered" (if they can access connector logs)
- "15 identity entities in platform" (what the API reports)
- "77 entities not accounted for"
The auditor will ask: "Where are the other 77 entities?" The answer -- "we filtered them at the connector because they had zero executions and no external egress" -- raises immediate follow-up questions:
- Who authorized the filtering criteria?
- Were the criteria reviewed by security?
- Can you prove the filtered entities pose no risk?
- Can you produce the full inventory on demand?
- How do you ensure the filtering criteria remain appropriate as threat landscapes change?
These are not hypothetical questions. They are standard SOC2 Type II auditor inquiries for any system that claims to provide identity inventory.
2.3 The Recommended Architecture
Connector discovers 92 identity entities
|
v
transformer.py: compute security_relevance for ALL entities
| (no filtering)
v
NormalizedGraph with 92 entities + security_relevance tags
|
v
Platform ingestion API
|
v
MongoDB: 92 entities stored (all with security_relevance property)
|
v
API default: return entities WHERE security_relevance != 'internal_inventory'
|
UI default: show entities WHERE security_relevance != 'internal_inventory'
|
v
Auditor mode: show ALL entities (no filter)
This preserves:
- Complete inventory for compliance attestation
- Presentation-layer filtering for usability (the 77 flows do not clutter the default view)
- Reversibility -- changing filtering criteria does not require re-ingestion
- Audit trail -- the platform knows about all 92 entities and can report on the full inventory
- Temporal tracking -- if a dormant flow becomes active, the platform already has its baseline
3. Zero Executions Does Not Equal Zero Risk: The Case for Capability-Based Assessment
3.1 Activity-Based vs. Capability-Based Risk Models
The current filtering uses an activity-based model: "has this automation done anything recently?" This is the wrong primary question for an inventory system. The right question is: "what COULD this automation do if it executed?"
| Model | Question | Strength | Weakness |
|---|---|---|---|
| Activity-based | Has it run? | Identifies actively executing threats | Misses dormant threats; blind to capability without evidence |
| Capability-based | What could it do? | Identifies latent risk regardless of activity | May overcount; requires permission scope data |
| Combined | What could it do, and is it doing it? | Complete picture | Requires both capability and activity data |
SecurityV0 should use the COMBINED model. Activity-based assessment (execution evidence) answers "what IS happening." Capability-based assessment (permission scope, trigger configuration, data domain access) answers "what COULD happen." Both are needed.
3.2 Capability Assessment for the 77 Filtered Flows
Even without execution evidence, we can assess the capability of each filtered flow:
| Capability Signal | Available? | What It Tells Us |
|---|---|---|
| Trigger type (record, schedule, event) | Yes -- triggerTypes property | Whether the flow can execute autonomously |
| Trigger table | Yes -- trigger_tables property | What data domain activates the flow |
| Run-as identity | Yes -- run_as property | What permissions the flow inherits |
| Flow actions | Partial -- HTTP actions detected | Whether the flow can reach external systems |
| Status (active/disabled) | Yes -- status property | Whether the flow could execute if triggered |
| Creator account status | Yes -- sys_created_by + user lookup | Whether ownership has decayed |
For the 54 active, autonomous flows with zero executions:
- They CAN execute at any time (status: active)
- They WILL execute automatically when triggered (execution_mode: autonomous)
- They MIGHT access identity data (some reference sys_user tables)
- They have NO execution baseline (which means any future execution is uncharacterized)
A capability-based assessment would classify these as LOW risk (no external egress, no identity binding) but NOT zero risk (active, autonomous, potentially sensitive data domain access).
3.3 The "Knowledge - Approval Publish" Case Study
This specific flow illustrates the limitation of activity-only assessment:
| Property | Value | Implication |
|---|---|---|
| Status | active | Could execute |
| execution_mode | autonomous | Will execute on trigger |
| execution_count_30d | 0 | Has not executed recently |
| Trigger | Record-based on knowledge articles | Activates on content publishing |
| Data domain | References sys_user (identity data) | Touches identity information |
| Egress | None observed | No current external reach |
| security_relevance | internal_inventory | FILTERED from platform |
Activity-based verdict: No risk. Zero executions, no egress.
Capability-based verdict: Low risk with latent escalation potential. Active autonomous flow that references identity data. If modified to add an HTTP action (trivial in Flow Designer -- it is a drag-and-drop operation), it becomes a data exfiltration channel for user identity information with no baseline to detect the change.
The capability-based assessment is the correct one for an inventory system. The activity-based assessment is appropriate for a threat detection system. SecurityV0 claims to be both.
4. The "Unknown" Execution Mode Problem
4.1 Scale of the Problem
22 of 77 filtered flows (29%) have execution_mode: unknown. This means the connector could not classify their trigger type from the available ServiceNow metadata.
This is an audit finding in itself, independent of any other issue. It means:
- The taxonomy is incomplete. 29% classification failure rate indicates the trigger type mapping does not cover all ServiceNow trigger types.
- Risk assessment is unreliable. If we cannot determine whether a flow is autonomous or human-triggered, we cannot reliably assess its risk profile.
- The filtering decision is based on incomplete data. We are filtering entities we do not fully understand, which violates the precautionary principle.
4.2 What "Unknown" Could Mean
Each "unknown" flow could be:
- Autonomous -- triggered by a record change or schedule we do not recognize. In this case, filtering it is a false negative.
- Human-triggered -- requires a UI action or manual step. In this case, filtering it is probably correct.
- Operator-assisted -- triggered by a service catalog request or email. In this case, it MIGHT be security-relevant if it has external egress.
Without classification, we cannot distinguish these cases. The conservative position is to treat "unknown" as "potentially autonomous until proven otherwise" -- which is what the glossary definition says: "Treated as in scope until proven otherwise."
Yet the current implementation filters ALL "unknown" flows as internal_inventory because they lack external egress and identity binding. This contradicts the stated policy.
4.3 Remediation
- Investigate the 22 unknown flows to determine their actual trigger types. This may require querying
sys_hub_trigger_instancewith additional field coverage. - Expand the trigger type mapping in
transformer.pyto cover the unrecognized trigger types. - Until classification is complete, treat unknown flows as
dormant_authority, notinternal_inventory. They should be ingested into the platform. - Track classification coverage as a connector health metric: "% of flows with known execution_mode."
5. Compliance Requirements Matrix
5.1 SOC2 Trust Service Criteria
| Control | Requirement | Current State | Gap |
|---|---|---|---|
| CC6.1 (Logical Access) | Maintain inventory of all automated processes that can access or modify data | 15 of 92 entities inventoried | 77 entities excluded -- incomplete inventory |
| CC6.2 (Access Reviews) | Evidence of periodic access reviews covering all non-human identities | Reviews can only cover inventoried entities | 84% of automation inventory not reviewable |
| CC6.3 (Access Revocation) | Demonstrate timely revocation when access is no longer needed | Cannot revoke what is not inventoried | Dormant automations with decayed ownership not tracked |
| CC7.1 (Monitoring) | Monitor system components for anomalies | No baseline for filtered entities | Cannot detect anomalous behavior in non-inventoried automations |
| CC7.2 (Incident Detection) | Detect incidents including unauthorized changes | Modifications to filtered automations are invisible | Configuration changes to dormant flows are undetectable |
5.2 ISO 27001:2022 Controls
| Control | Requirement | Current State | Gap |
|---|---|---|---|
| A.5.15 (Access Control) | Provision and manage access rights including for automated processes | Incomplete automation inventory | 77 automations not subject to access governance |
| A.5.18 (Access Rights) | Review access rights at regular intervals | Review scope excludes filtered entities | Access reviews cover 16% of automation population |
| A.8.2 (Privileged Access) | Restrict and manage privileged access for automated tools | Cannot assess privilege of filtered entities | "User who initiates the session" run-as model not analyzed |
| A.8.15 (Logging) | Produce, store, protect, and analyze logs of activities | No execution telemetry for filtered entities | Audit log completeness cannot be attested |
| A.8.16 (Monitoring) | Monitor networks, systems, and applications for anomalous behavior | No baseline for filtered entities | Zero-day anomaly detection impossible |
5.3 SOX IT General Controls (ITGC)
| Control Area | Requirement | Current State | Gap |
|---|---|---|---|
| Change Management | All changes to automated processes documented and approved | Filtered automations not tracked for changes | Modifications to 77 flows are not change-managed |
| Access Management | Complete inventory of automated access to financial data | Flows touching financial data domains may be filtered | Cannot confirm no filtered flow accesses financial data |
| Operations | Monitoring of automated job execution | Filtered jobs have no execution monitoring | Cannot prove operational completeness |
5.4 What an Auditor Needs to See
For a SOC2 Type II examination, the auditor requires:
- Complete inventory of all automated processes that can access or modify data in scope systems. "We filtered 84% of them" is not acceptable.
- Classification rationale for any prioritization or tiering of the inventory. This must be documented, reviewed, and approved by a responsible party.
- Evidence of review for the complete inventory, even if reviews are tiered (monthly for Tier 1, quarterly for Tier 2, annually for Tier 3).
- Change detection for all inventoried automations, with alerts for modifications to dormant or low-priority items.
- Attestation of completeness -- a signed statement that the inventory represents ALL automated processes, not a filtered subset.
The current architecture cannot produce items 1, 3, 4, or 5 for the 77 filtered entities.
6. Debate with Product Owner: Should Dormant Automations Be in Phase 1?
6.1 The Product Owner's Position (Anticipated)
"Phase 1 is MVP. Customers want to see ACTIVE risks first. They do not want to scroll through 77 dormant flows to find the 6 that matter. Filtering is a UX decision -- we are showing customers what they care about. We can always add dormant automations later."
6.2 The CISO's Counter
The Product Owner's position conflates two distinct decisions:
- What do we SHOW the customer by default? (Presentation -- a UX decision)
- What do we STORE in the platform? (Data completeness -- a compliance decision)
I fully agree with decision #1: the default view should show only security-relevant entities. Nobody benefits from scrolling through 77 dormant flows. The tiered approach (active_external, dormant_authority, internal_inventory) with UI-level filtering is exactly right for UX.
But decision #2 is where I draw the line. Filtering pre-ingest turns a reversible UX decision into an irreversible data-loss decision. Once the connector drops those 77 entities, the platform has no record they exist. We cannot:
- Show them when the customer clicks "Show all"
- Include them in compliance exports
- Track changes to them over time
- Detect when a dormant flow becomes active
- Produce a complete inventory for auditors
6.3 The Compliance Liability
Consider this scenario: A customer deploys SecurityV0 and passes their SOC2 audit using our platform as evidence of NHI inventory coverage. Six months later, a breach occurs through a dormant ServiceNow flow that SecurityV0 filtered. The auditor's investigation reveals:
- SecurityV0 discovered the flow during its scan
- SecurityV0's connector intentionally excluded it from the platform
- The customer relied on SecurityV0's output as their NHI inventory
- The inventory was incomplete, and the gap was exploited
This is a product liability scenario. The customer will argue that SecurityV0 represented its output as a "complete inventory" when it was, by design, filtering 84% of discovered entities. The fact that the filtered entities were "low risk" is irrelevant -- the inventory was incomplete, and the gap was material.
6.4 The Middle Ground
Ingest all 92 entities. Store them with their security_relevance classification. Default the UI and API to filtering internal_inventory. Provide a "Show all" toggle and a "Compliance mode" that returns the full inventory.
This gives the Product Owner exactly the UX they want (clean, focused, security-relevant default view) while giving the CISO exactly the data completeness they need (full inventory, auditable, attestable).
The engineering cost of this approach is LOWER than the current approach. Instead of writing filtering logic in the connector that removes nodes and cascades edge removals (the _filter_internal_inventory method in transformer.py is 56 lines of non-trivial graph cleanup code), we write a one-line API filter: WHERE security_relevance != 'internal_inventory'. The connector code becomes simpler, the platform data becomes richer, and compliance is preserved.
6.5 For the Pilot Gate
Even for the Phase 1 pilot, the "ingest all, filter in UI" approach is superior:
| Criteria | Pre-ingest filter | UI-level filter |
|---|---|---|
| Customer sees clean dashboard | Yes | Yes |
| Customer can drill into full inventory | No | Yes |
| Auditor can attest completeness | No | Yes |
| Engineering complexity | Higher (graph cleanup logic) | Lower (API query filter) |
| Reversibility | Requires re-scan to include | Toggle in UI |
| Risk of false negative | Yes (criteria may miss edge cases) | No (all data available) |
There is no scenario where pre-ingest filtering is the better choice.
7. Challenge Questions for Other Roles
7.1 For the Product Owner
Q: How do you explain to a SOC2 auditor that 77 automations are "noise"?
The auditor's standard is "complete inventory of automated processes." The word "complete" does not have a qualifier for "security-relevant." If the customer's Statement of Applicability (SoA) includes ServiceNow automations in scope, all of them must be inventoried. The auditor will not accept "we filtered them because they had zero executions" as a completeness attestation.
Q: What happens when a customer asks "how many automations do I have?" and the answer is 15, but they can see 92 in ServiceNow?
This creates a credibility gap. The customer will question what else SecurityV0 is not showing them. Trust in the platform's completeness is foundational -- if the inventory is incomplete, every finding the platform produces is suspect.
Q: Sergey's feedback emphasizes "sensitivity of data" and "was vs. is" delta. How do we compute sensitivity delta for entities we do not track?
If a dormant flow is modified to access sensitive data, we cannot detect the change because we have no baseline. The "was vs. is" risk velocity metric requires BOTH states to exist in the platform. Pre-ingest filtering eliminates the "was" state.
7.2 For the Architect
Q: Is the capability-based risk model technically feasible with current data?
Partially. The connector already extracts trigger types, trigger tables, run-as identity, and flow actions. These provide the inputs for a capability assessment:
- Trigger type determines if the flow can execute autonomously
- Trigger table indicates the data domain the flow touches
- Run-as identity determines the permission scope
- Flow actions reveal external reach (HTTP actions, REST calls)
What is missing: the actual PERMISSION SCOPE of "User who initiates the session" run-as flows. This requires enumerating all users who could trigger the flow and computing the union of their permissions -- which is a complex graph traversal but technically feasible.
Q: Can the platform handle 92 identity entities without performance issues?
This is a non-question. The platform is designed for 1,000+ identities per tenant with materialized execution paths. 92 entities is approximately 9% of the design capacity. There is no performance justification for pre-ingest filtering at this scale.
7.3 For the Integrator (Connector Team)
Q: Can we get the actual permission scope of these flows from ServiceNow?
For flows with explicit run_as user binding: yes. Query sys_user_has_role for the run-as user to enumerate their roles, then traverse Role -> Permission -> Resource to compute the flow's effective permission scope.
For flows with "User who initiates the session": this is harder. We would need to:
- Identify the trigger table and trigger condition
- Determine which users/groups have access to create/modify records on that table
- For each such user, enumerate their roles and permissions
- The flow's effective blast radius is the UNION of all these users' permission scopes
This is computationally expensive but deterministic. It could be implemented as a post-ingest enrichment in the platform evaluator rather than in the connector.
Q: Can we get execution evidence for the automation types that currently show execution_count_30d: 0 due to missing telemetry?
For Flow Designer flows: sys_flow_context provides execution records. This is already implemented.
For Business Rules: No direct execution log exists in ServiceNow. Indirect evidence can come from syslog_transaction (if the BR triggers an outbound REST call) or sys_audit (if the BR modifies records). This is a known gap.
For Scheduled Jobs: sys_trigger contains execution history. This is already partially implemented.
7.4 For the Developer
Q: What would a compliance-mode API flag look like?
// API endpoint: GET /api/v1/entities
// Query parameters:
// compliance_mode=true -> returns ALL entities regardless of security_relevance
// compliance_mode=false -> returns entities WHERE security_relevance != 'internal_inventory'
// Default: compliance_mode=false (focused view)
// Auditor usage: compliance_mode=true (complete inventory)
// Implementation: single query filter toggle
const filter = req.query.compliance_mode === 'true'
? { tenant_id: tenantId, entity_type: 'identity' }
: { tenant_id: tenantId, entity_type: 'identity',
'properties.security_relevance': { $ne: 'internal_inventory' } };
This is approximately 5 lines of code. Compare to the 56-line _filter_internal_inventory method in the connector that performs graph cleanup with cascading edge removal and orphaned node detection. The compliance-mode approach is simpler, more correct, and more maintainable.
Q: What about the graph visualization problem?
The 2026-02-12-automation-filtering-graph-strategy.md document already solves this: use security_relevance as a default filter in the graph view. The graph renders 15-25 entities by default (perfectly readable with Dagre). Users click "Show all" to see the full 92-entity graph. This is a solved problem -- the graph does not need to show everything by default, but the DATABASE must contain everything.
8. Top 5 Security Recommendations (Prioritized)
Recommendation 1: Eliminate Pre-Ingest Filtering (P0 -- Immediate)
Action: Set filter_internal_inventory=False (the default) in all connector invocations. Ingest all 92 entities into the platform with their security_relevance property intact.
Rationale: Pre-ingest filtering creates an irreversible data gap that undermines compliance attestation, temporal tracking, and the platform's evidence-grade positioning. The security_relevance property already exists on all nodes -- use it for UI/API filtering instead of data deletion.
Effort: Zero engineering effort. The default is already False. Remove the filter_internal_inventory=True flag from the CLI/pipeline invocation.
Risk of NOT doing this: Compliance audit failure on inventory completeness (SOC2 CC6.1, ISO 27001 A.5.15). Product liability if a filtered entity is involved in a security incident.
Recommendation 2: Implement Compliance-Mode API (P0 -- This Sprint)
Action: Add a compliance_mode query parameter to the entities API that returns the full inventory regardless of security_relevance filtering. Ensure all export endpoints (SCIM, OAA) default to compliance mode.
Rationale: Auditors and GRC tools need the complete inventory. The default view can remain filtered for usability, but a compliance export must include everything.
Effort: 2-4 hours (query parameter + filter toggle).
Risk of NOT doing this: Auditor cannot produce complete NHI inventory from the platform. Customer must manually supplement SecurityV0 output with ServiceNow reports, undermining the value proposition.
Recommendation 3: Resolve the "Unknown" Execution Mode Gap (P1 -- Next Sprint)
Action: Investigate the 22 flows with execution_mode: unknown to determine their actual trigger types. Expand the trigger type mapping in transformer.py. Track classification coverage as a connector health metric.
Rationale: 29% classification failure rate is an audit finding. It undermines the reliability of the entire execution_mode / security_relevance taxonomy. Until resolved, unknown flows should be treated as dormant_authority, not internal_inventory.
Effort: 4-8 hours (ServiceNow API investigation + mapping updates).
Risk of NOT doing this: False negative rate of 29% for automation classification. Possible misclassification of autonomous flows as noise.
Recommendation 4: Add Capability-Based Risk Properties (P1 -- Next Sprint)
Action: Enrich all automation nodes with capability signals independent of execution evidence:
can_execute_autonomously: boolean (derived from trigger type)data_domain_access: string[] (derived from trigger tables and run-as scope)potential_blast_radius: enum (derived from run-as identity's permission count)status_active: boolean (could be activated if currently disabled)
Rationale: Activity-based assessment (execution_count) tells us what IS happening. Capability-based assessment tells us what COULD happen. Both are needed for a complete risk picture. Particularly important for dormant automations where execution evidence is absent by definition.
Effort: 8-12 hours (property computation + API exposure).
Risk of NOT doing this: Risk model only covers active threats. Dormant threats (which are the majority of the automation population) have no risk assessment.
Recommendation 5: Establish Automation Access Review Process (P2 -- Pre-Production)
Action: Document and implement a tiered access review process for the automation inventory:
- Tier 1 (active_external): Monthly review -- verify ownership, permission scope, execution patterns
- Tier 2 (dormant_authority): Quarterly review -- verify continued business need, ownership status
- Tier 3 (internal_inventory): Annual review -- verify classification accuracy, check for dormant-to-active transitions
Rationale: SOC2 CC6.2 and ISO 27001 A.5.18 require periodic access reviews covering all non-human identities. The tiered approach makes reviews proportional to risk while maintaining compliance coverage.
Effort: 16-24 hours (process design + workflow implementation + documentation).
Risk of NOT doing this: Access review gap for 84% of automation population. SOC2 audit finding on CC6.2.
9. Summary Position
The SecurityV0 platform positions itself as providing "complete inventory of autonomous execution authority" with "evidence-grade, deterministic, verifiable outputs." Filtering 84% of discovered automations before they reach the platform database is fundamentally incompatible with these claims.
The filtering was implemented as an engineering optimization to solve a legitimate UX problem (graph readability at 126 nodes). The UX problem is real and the solution (tiered relevance classification) is correct. But the implementation (pre-ingest data deletion) is wrong. The correct implementation is: ingest everything, tag everything, filter at the presentation layer.
The 77 dormant automations are not "noise" from a security perspective. They are:
- 45 autonomous processes that could execute at any time
- 54 active configurations that are one trigger away from execution
- 22 unclassified entities whose behavior we cannot characterize
- 77 attack surface elements with no baseline, no monitoring, and no access governance
From a CISO's perspective, the most dangerous entity in an automation inventory is not the one that executes every 15 minutes -- that one has a known behavior pattern, established baselines, and active monitoring. The most dangerous entity is the one that has never executed, because when it does, there is nothing to compare it against.
Ingest everything. Filter nothing. Present intelligently. This is the only approach that satisfies compliance requirements, supports the platform's evidence-grade positioning, and provides the complete automation inventory that enterprise security teams require.
This analysis was prepared from the CISO Advisor perspective for the SecurityV0 automation-analysis team. It represents the most conservative position on the team and is intended to challenge assumptions, not to veto product decisions. The recommendations are prioritized by compliance impact and should be weighed against engineering capacity and pilot timeline constraints.