Automation Analysis — Team Synthesis Report
Date: 2026-02-12 Team: automation-analysis (5 agents) Core Question: What should count as an autonomous execution (automation) vs. a static configuration artifact in our ServiceNow automation inventory?
Team Participants
| Role | Model | Lines | Key Contribution |
|---|---|---|---|
| Product Owner | opus | 409 | 4-tier taxonomy, MVP gate criteria, Sergey feedback integration |
| Architect | opus | 603 | Decision tree, trigger classification fix, RUNS_AS semantics deep-dive |
| CISO | opus | 506 | Compliance matrix (SOC2/ISO/SOX), "ingest all, filter in UI" mandate |
| Integrator | sonnet | 556 | ServiceNow ground-truth, trigger type validation, execution count verification |
| Developer | sonnet | 1538 | API data quality audit, TypeScript types, endpoint specs, implementation checklist |
1. Agreed Taxonomy (Team Consensus)
All 5 teammates converged on a tiered classification with the following agreed structure:
Tier 1: Active Threat Surface (default view)
- Has external egress (LLM/cloud/external) AND execution evidence
- Current count: 1 entity (AI Triage via Azure OpenAI)
- Display: Always visible, top of dashboard
Tier 2: Dormant Authority (default view)
- Has egress capability OR identity binding, but 0 recent executions
- OR touches sensitive data domains (sys_user, HR, customer, financial) — new criterion from CISO+PO
- Current count: 9-17 entities (9 current + 5-8 promoted from Tier 3)
- Display: Always visible, sorted after Tier 1
Tier 3: Internal Inventory (hidden by default, toggle to show)
- No egress, no binding, no execution, no sensitive data access
- Standard ITSM workflows (Change, Incident, Request management)
- Current count: ~62-65 entities
- Display: Behind "Show all automations" filter
Tier 4: Templates / Disabled (informational only)
status: disabledor template flows- Current count: 23 disabled entities
- Display: Within Tier 3, with "Disabled" badge
2. Key Agreements (All 5 Roles Aligned)
A. The 22 "Unknown" Execution Modes Are a Bug, Not a Feature
Unanimous agreement: Trigger types created, updated, created or updated, knowledge management, and sla task are ALL autonomous event-driven triggers. They must be added to _AUTONOMOUS_TRIGGERS in transformer.py.
| Role | Position |
|---|---|
| Product Owner | "22 unknowns undermine the deterministic promise" |
| Architect | "10-line code change, 5 new test cases — ship before next release" |
| CISO | "29% classification failure rate is itself an audit finding" |
| Integrator | "These are display-value labels from label_cache parsing — same mechanism as record_create" |
| Developer | "Platform should also have fallback classification for known subtypes" |
Action: Add 5 trigger strings to _AUTONOMOUS_TRIGGERS. Estimated effort: 2 hours.
B. "Ingest All, Filter in UI" — Not Pre-Ingest Deletion
Unanimous agreement: The 77 internal_inventory entities should be INGESTED into the platform (not filtered pre-ingest) and HIDDEN via UI/API default filters.
| Role | Position |
|---|---|
| Product Owner | "Compliance teams need 'show all' toggle for inventory completeness (PRD §1)" |
| Architect | "Discovery should be broad, analysis should be narrow" |
| CISO | "Pre-ingest filtering creates irreversible data loss — compliance liability" |
| Integrator | "Filtering was a UX optimization, not a data decision" |
| Developer | "API filter is 5 lines; connector filter is 56 lines of graph cleanup" |
Action: Keep filter_internal_inventory=False (already the default). Add security_relevance!=internal_inventory as default API/UI filter. Estimated effort: 2-3 hours.
C. execution_count_30d: 0 Is Real (Not a Data Gap)
Integrator + Developer agreement: The connector correctly queries sys_flow_context using X-Total-Count headers. The zero counts reflect genuine inactivity — these flows are configured but dormant.
Caveat: Add execution_data_availability field to distinguish "confirmed zero" from "data unavailable" for future robustness.
D. "RUNS AS: User Who Initiates" Is NOT Human-Only
Architect + Integrator agreement: This is a delegation policy, not a human-only restriction. If an autonomous flow triggers a "user who initiates" flow, it runs with the triggering flow's context (potentially admin).
Action: Classify execution_mode based on TRIGGER TYPE only, not run-as mode. Add execution_context property (system/user_session/inherited).
3. Key Disagreements (Resolved with Compromise)
Dormant Automations in Phase 1
CISO Position: ALL dormant automations must be visible — filtering is a compliance liability.
Product Owner Position: Phase 1 MVP should show active risks first. 77 dormant flows overwhelm the UI.
Resolution: Both are right for different concerns. Ingest all, show Tier 1+2 by default, "Show all" toggle for compliance. The CISO gets full inventory in the database; the PO gets a clean default view. 5-8 sensitive-data flows are PROMOTED from Tier 3 to Tier 2.
Script Includes — In Scope or Out?
Integrator: Exclude — they are libraries, not autonomous executors.
CISO: Include — capability inventory matters even if they don't execute independently.
Resolution: Model as entity type with is_executor: false property. Visible in full inventory but not in automation dashboard. Defer to Phase 2.
4. Top 5 Action Items (Prioritized, Team-Agreed)
| # | Action | Owner | Effort | Priority | Clears |
|---|---|---|---|---|---|
| 1 | Add created, updated, knowledge management, sla task, created or updated to _AUTONOMOUS_TRIGGERS | Integrator | 2h | P0 | Eliminates 22/22 unknowns |
| 2 | Promote flows touching sensitive data domains (sys_user, HR, customer) from internal_inventory to dormant_authority | Integrator | 2h | P0 | Surfaces 5-8 hidden identity-data flows |
| 3 | Add compliance_mode API parameter + default security_relevance filter | Developer | 3h | P0 | Compliance-mode export + clean default UX |
| 4 | Add execution_data_availability and execution_mode_confidence properties | Developer + Integrator | 8h | P1 | Data quality transparency |
| 5 | Add execution_context property (system/user_session/inherited) to normalize RUNS_AS | Architect + Integrator | 4h | P1 | Fixes RUNS_AS semantics |
Total P0 effort: ~7 hours. Total P0+P1: ~19 hours.
5. Answer to the Core Question
"What should count as an autonomous execution (automation) vs. a static configuration artifact?"
Team Answer:
An automation in SecurityV0 is any configured artifact that:
- CAN execute without a human clicking a button (autonomous or operator-assisted execution_mode)
- Has standing authority (trigger configuration, run-as identity, or permissions that persist independently)
The classification is NOT binary. It's a spectrum measured on three orthogonal axes:
| Axis | Property | Purpose |
|---|---|---|
| CAN it execute autonomously? | execution_mode | Determines if human intervention is required |
| HAS it executed? | execution_count_30d | Determines if risk is theoretical or realized |
| WHAT can it do? | security_relevance + risk_group | Determines blast radius and priority |
The "Knowledge - Approval Publish" Verdict
What This Automation Does (Plain English)
Knowledge - Approval Publish is a ServiceNow Flow Designer flow that handles the publishing of knowledge base articles through an approval workflow.
How it works in real life:
- A support engineer writes a knowledge base article (e.g., "How to Reset Your VPN Token")
- The article is submitted for review via the Knowledge Management application
- When a knowledge manager approves the article, ServiceNow's Knowledge Management engine fires a
knowledge managementevent - This event triggers the "Knowledge - Approval Publish" flow automatically — no human clicks a button to run the flow
- The flow reads from the
sys_usertable to resolve article authors, reviewers, and notification recipients - The flow transitions the article state from "Draft" → "Published" and notifies the author
Why it matters for security:
- It runs autonomously on every knowledge article approval (event-driven, not manual)
- It reads from
sys_user— the identity table containing employee names, emails, roles, and org structure - It runs as "User who initiates the session" — meaning if another automation triggers an approval, this flow inherits that automation's identity context (potentially admin-level)
- Even though it has 0 executions in the last 30 days, the standing configuration means it WILL execute the next time anyone approves a KB article
Real-world risk scenario: An attacker who compromises a knowledge base workflow could inject a subflow that exfiltrates sys_user data through the approval publish chain. The flow's access to identity data makes it a stepping stone for privilege enumeration even though it has no external egress on its own.
Classification
| Property | Value | Classification |
|---|---|---|
| execution_mode | autonomous (knowledge management = event trigger) — currently misclassified as "unknown" | |
| execution_count_30d | 0 — real zero, confirmed by sys_flow_context query | |
| data_domains | ["identity"] — touches sys_user (sensitive) | |
| egress_category | none — no external reach | |
| RUNS_AS | "User who initiates" — dynamic identity, NOT human-only | |
| Verdict | Dormant authority — should be promoted from internal_inventory because it touches identity data |
This flow IS an automation (autonomous trigger, standing configuration, identity data access). It is NOT an active threat (no execution, no egress). It SHOULD be visible in the default view because it touches sensitive data.
6. Phase 1 Gate Status
| Gate | Criterion | Status | Fix |
|---|---|---|---|
| G1 | Tier 1+2 visible by default | PARTIAL | Add blast-radius sort to homepage |
| G2 | Evidence chain walkable per automation | MET | — |
| G3 | Ownership status visible | MET | — |
| G4 | execution_mode classified >90% | NOT MET (76%) | Add 5 trigger strings |
| G5 | No sensitive-data flows hidden | NOT MET | Promote sensitive-data flows |
| G6 | "Show all" toggle works | MET | — |
| G7 | Evidence completeness declared | MET | — |
8-10 hours of engineering to clear all P0 gates.
7. Files Produced
| File | Role | Content |
|---|---|---|
| product-owner.md | Product Owner | Taxonomy, MVP definition, Sergey integration, Phase 1 gates |
| architect.md | Architect | Decision tree, trigger fix, RUNS_AS deep-dive, schema changes |
| ciso.md | CISO | Compliance matrix, dormant threat model, ingest-all mandate |
| integrator.md | Integrator | ServiceNow ground-truth, trigger validation, data quality |
| developer.md | Developer | API audit, TypeScript types, endpoint specs, implementation checklist |
| 00-synthesis.md | Lead | This document — team consensus and action items |
Analysis complete. 3,612 lines of research across 5 perspectives, synthesized into 5 agreed actions totaling 7 hours P0 / 19 hours P0+P1.