SecurityV0 Demo Lab — Enhancement Plan
The Problem
Today, SecurityV0 demos run against synthetic metadata seeded directly into the platform database (demo-w1 tenant, seed-demo-w1.ts). This approach was essential for early development — it let us build and validate the UI, findings engine, and evidence packs without external dependencies.
But synthetic data has a ceiling:
- Prospects can tell. Seeded data lacks the depth, inconsistency, and messiness of real environments. A CISO who has lived inside ServiceNow or Entra ID will notice the difference.
- Connector coverage is invisible. We can't show what SecurityV0 actually reads from source systems because there's no source system to read from.
- Edge cases stay theoretical. Real connector behavior — API pagination, rate limits, partial data, temporal gaps — only surfaces against live APIs.
- The "so what" gap. Partners sell the report, not the tool. A report built from synthetic metadata doesn't carry the weight of one built from a real environment that a prospect could verify.
The Approach: SecurityV0 Demo Lab
Proposed name: Demo Lab (internal), SecurityV0 Experience Environment (client-facing)
Alternative names considered:
| Name | Pros | Cons |
|---|---|---|
| Demo Lab | Short, internal-friendly, clear | Too informal for client-facing |
| Experience Environment | Professional, implies hands-on | Longer |
| Live Sandbox | Emphasizes real data | "Sandbox" can imply toy/test |
| Field Demo Tenants | Ties to tenant model | Too technical |
Two-Tier Architecture
Each scenario operates at two complementary tiers, not as an either/or choice:
Tier 1: Enhanced Seed Data
Upgraded seed scripts that populate SecurityV0's database with business-contextualized data — not generic "Contoso" entities but data modeled after what a real connector would return from a specific industry environment. Each seed dataset includes documentation mapping every seeded object to the real business object it represents and why it matters.
What Tier 1 adds over current demo-w1:
- Industry-specific naming (real-sounding service accounts, departments, vendors for each vertical)
- Documented business context — every entity has a "this represents..." annotation explaining what the real-world equivalent looks like in the source system
- Multiple temporal snapshots baked in — showing how permissions drifted, when owners left, when automations went dormant
- Compliance domain tags tied to real frameworks (SOX, HIPAA, PCI-DSS, CMMC)
- Seed scripts per scenario, composable — run one or several
When to use: Development, CI testing, quick internal demos, first-call prospect overviews, situations where standing up live infrastructure isn't practical.
Tier 2: Live Dev Instances
Real source system instances (ServiceNow developer instances, Entra ID test tenants, AWS sandbox accounts) populated with the same business data that Tier 1 seeds describe. SecurityV0 connectors run the full pipeline — connect, read, normalize, ingest, evaluate, generate evidence packs.
What Tier 2 adds over Tier 1:
- Real connector execution — prospects see the actual ingestion flow, not pre-populated results
- Source system artifacts visible — "here's the ServiceNow flow, here's the Entra service principal, here's what SecurityV0 reads from it"
- API behavior is real — pagination, rate limits, partial data, temporal gaps
- Temporal history from actual repeated scans, not synthesized snapshots
- Report credibility — the evidence pack references objects that verifiably exist in a live system
When to use: Sales demos for serious prospects, partner training, pilot onboarding, scenarios where "show me the source" matters.
How the tiers relate
The seed data (Tier 1) and the live instance data (Tier 2) are derived from the same scenario definition. For each scenario, a single source-of-truth document defines the business narrative, the entities, the risk patterns, and the expected findings. From that definition:
- Tier 1 seed scripts generate the MongoDB documents directly
- Tier 2 IaC templates create the corresponding objects in real source systems
This means a Tier 1 demo and a Tier 2 demo for the same scenario produce equivalent findings and evidence packs — the difference is where the data lives, not what SecurityV0 shows.
Important caveat: Temporal findings (
scope_drift,ownership_drift) requireentity_versionshistory in the database. Tier 1 seed scripts must explicitly seed version history documents — not just current-state entities — or these findings will not fire. This is additional seed script complexity compared to the current demo-w1 approach, which does not seed version history. Tier 2 gets version history naturally from repeated connector scans.
What stays the same across both tiers
- SecurityV0 platform code is identical — no demo-specific logic
- Read-only connector model — we never write back to source systems
- Deterministic evaluation — same rules, same findings
- Evidence packs generated with full integrity hashes
Scenarios
Each scenario represents a realistic business situation where SecurityV0 delivers clear, demonstrable value. Every scenario is designed to be self-contained: a prospect watching a demo should recognize the situation from their own organization.
Scenario 1: Financial Services — Privileged Automation Sprawl
Industry: Banking / Financial Services
Narrative: A mid-size bank ("Meridian National Bank") runs ServiceNow for IT operations and uses Entra ID for identity governance. Over two years, their finance team deployed several automated workflows — invoice processing, payment reconciliation, regulatory reporting. Each started with minimal permissions but accumulated additional roles through change requests that were approved individually without reviewing cumulative scope.
What SecurityV0 reveals:
- 4 service principals with scope drift — permissions grew from 2-3 roles to 8-12 each
- 2 automations accessing PCI-scoped data (cardholder records) that weren't in the original design
- 1 orphaned automation still running under a departed contractor's identity
- Compliance mapping shows 3 automations touching SOX-relevant financial data without documented controls
Why this sells: Every bank has this problem. Auditors ask about it. Nobody has visibility into it today.
Tier 1 seed data — business mapping:
| Seeded Entity | Represents in Real Bank Environment |
|---|---|
svc-meridian-invoice-proc (SP, scope drift) | ServiceNow scripted REST integration that pulls invoice data from the core banking ERP. Started with read-only, accumulated AP Write + Ledger Admin via 3 separate change requests |
svc-meridian-payment-recon (SP, scope drift + PCI) | Nightly reconciliation job matching card payment records against settlement files. The PCI-scoped access (cardholder table) was added in a "quick fix" CR |
svc-meridian-reg-reporting (SP, scope drift) | Quarterly regulatory data export to Federal Reserve reporting system. Accumulated 4 extra roles across HR and Compliance data domains |
contractor-davis-k (orphaned identity) | Contractor account for Kevin Davis, engagement ended 2025-11. ServiceNow flows still execute under this identity |
Compliance tags: SOX-ITGC, PCI-DSS | Maps to SOX ITGC AC-2 (Account Management), ITGC AC-6 (Least Privilege), PCI-DSS Req 7.1 (Restrict access by business need-to-know) |
Systems needed (Tier 2): ServiceNow (dev instance), Entra ID (test tenant)
Scenario 2: Healthcare — Unmonitored PHI Data Flows
Industry: Healthcare / Hospital Systems
Narrative: A regional hospital system ("Lakeview Health Network") integrated ServiceNow ITSM with their clinical systems for automated patient record synchronization and care coordination workflows. Several automations were built during COVID-era rapid digitization with minimal governance. The security team was never consulted.
What SecurityV0 reveals:
- 3 automations accessing patient health information (PHI) with no individual accountability — group-owned only
- 1 automation syncing records to an external telehealth vendor with credentials that haven't been rotated in 14 months
- 2 dormant workflows that still hold active credentials to clinical data stores
- No individual owner on PHI-touching automations — governance gap visible in evidence pack (group ownership only, no accountability chain)
Why this sells: HIPAA enforcement is increasing. Healthcare CISOs need to demonstrate they know where PHI flows, especially through automated processes. Manual audits miss automations entirely.
Tier 1 seed data — business mapping:
| Seeded Entity | Represents in Real Hospital Environment |
|---|---|
svc-lakeview-patient-sync (group-owned, PHI) | ServiceNow scheduled job syncing patient demographic data from Epic/Cerner integration table to care coordination dashboard. Owned by "Clinical IT Team" group — no named individual |
svc-lakeview-telehealth-export (external egress, stale creds) | Nightly export of appointment and visit summary records to external telehealth vendor (MedConnect). Connection credentials last rotated 14 months ago |
svc-lakeview-lab-results (group-owned, PHI) | Flow Designer automation routing lab result notifications. Accesses lab orders table containing PHI. Owned by "Lab Systems" group |
svc-lakeview-referral-router (dormant, PHI) | Patient referral automation — last executed 5 months ago but retains active credentials to referral records containing diagnosis codes |
Compliance tags: HIPAA, PHI | Maps to HIPAA Security Rule controls for access management and audit logging |
Systems needed (Tier 2): ServiceNow (dev instance), Entra ID (test tenant)
Scenario 3: Enterprise SaaS — Auto-route identity tickets
Industry: Technology / SaaS
Narrative: A growing SaaS company ("Nimbus Cloud Inc.") uses ServiceNow to auto-route identity tickets. The workflow runs as sn-ticket-router, pulls requester and group context from Microsoft Graph, sends selected routing context to Microsoft Foundry for classification, and writes the route and priority back into ServiceNow. The workflow is real, still active, and now materially different from what was originally approved.
What SecurityV0 reveals:
- one live access chain from ServiceNow through
sn-ticket-routerinto Microsoft Graph and Microsoft Foundry - Graph scope drift on the live path: the router now carries broader read reach than the routing use case requires
- ownership loss: the workflow no longer resolves to a valid accountable owner
- Microsoft Foundry added after baseline and is now part of the production execution path
Why this sells: Every enterprise understands ticket routing. Very few can prove the exact production path, the delegated authority behind it, and the structural drift on that same path across ServiceNow, Entra, and Microsoft Foundry.
Tier 1 seed data — business mapping:
| Seeded Entity | Represents in Real SaaS Environment |
|---|---|
Auto-route identity tickets | ServiceNow workflow that triggers on a new identity ticket and orchestrates the routing sequence |
incident | The ticket record that triggers the workflow and receives the write-back route and priority |
Graph - sn-ticket-router | ServiceNow connection object used for the Graph context fetch |
Azure Graph OAuth Client | OAuth client credential object backing the Graph branch |
sn-ticket-router | The Entra non-human identity under which the live routing path runs |
Microsoft Graph: User.Read.All + Group.Read.All + Directory.Read.All | The current Graph reach on the live path; Directory.Read.All is the drift signal |
Current owner invalid | Represents the stale or disabled owner state on the workflow/router branch |
Microsoft Foundry classification | The post-baseline model step now inserted into the live path before ServiceNow write-back |
Systems needed (Tier 2): ServiceNow (dev instance), Entra ID (test tenant), Microsoft Foundry
Scenario 4: Insurance — Compliance Reporting Drift
Industry: Insurance / Regulated Financial Services
Narrative: An insurance carrier ("Granite Mutual Insurance") relies on automated compliance reporting workflows to satisfy state regulator requirements. These automations export policy data, claims records, and actuarial calculations to regulatory filing systems. Over time, the automations were patched and extended by different teams without updating compliance documentation.
What SecurityV0 reveals:
- 2 compliance export automations whose actual roles (7 each) far exceed their documented scope (3 roles) — added permissions include policyholder PII, agent commissions, and actuarial tables that were never in the original design
- 1 regulatory filing automation running under an orphaned service account — original owner transferred divisions 8 months ago
- Temporal analysis shows permission scope increased in 3 discrete jumps over 6 months, each correlated with a change request but never reviewed holistically
- Evidence pack maps each automation's actual access against its compliance control documentation
Why this sells: Insurance regulators are tightening automation oversight. A compliance officer who can show proactive discovery and remediation avoids enforcement actions.
Tier 1 seed data — business mapping:
| Seeded Entity | Represents in Real Insurance Environment |
|---|---|
svc-granite-naic-filing (scope drift, orphaned) | ServiceNow scheduled job exporting policy and claims data to NAIC (National Association of Insurance Commissioners) filing system. Original owner (VP Compliance) transferred to Life division 8 months ago. Scope crept from policy summaries to full claims detail + actuarial tables |
svc-granite-state-report (scope drift) | State regulatory reporting automation. Documented scope: "policy count and premium volume by state." Actual scope: includes individual policyholder records, agent commission data, and loss ratio calculations |
svc-granite-audit-trail (dormant) | Internal audit log exporter — stopped executing 4 months ago, retains write access to compliance archive |
| 3 temporal snapshots per entity | Shows permission scope expanding in discrete jumps: Jan (2 roles), Mar (4 roles), Jun (7 roles) — each tied to a change request number |
Compliance tags: NAIC, State Filing, SOX-ITGC | Maps to real regulatory filing controls: SOX ITGC AC-1 (Access Control Policy), SOX ITGC AC-2 (Account Management), NAIC Model Audit Rule §7 |
Systems needed (Tier 2): ServiceNow (dev instance), Entra ID (test tenant)
Scenario 5: Retail / E-Commerce — Cross-Cloud Identity Sprawl
Industry: Retail
Narrative: A retail chain ("Harbor Retail Group") runs ServiceNow for IT operations, Entra ID for corporate identity, and AWS for their e-commerce platform. Service accounts span all three environments. After a recent organizational restructure, several team-owned accounts lost their accountable owners, and cross-cloud service principals were never consolidated.
What SecurityV0 reveals:
- 6 service principals spanning Entra ID and AWS, 2 with no identifiable owner
- 1 AWS IAM role assumed by a ServiceNow automation — cross-cloud trust chain with no governance
- 3 automations accessing customer PII (order history, payment metadata) across cloud boundaries
- Evidence pack shows the full access path: ServiceNow → Entra SP → AWS IAM Role → S3 bucket with customer data
Why this sells: Multi-cloud is the norm. Cross-cloud automation sprawl is invisible to single-cloud tools. SecurityV0 shows the full path.
Tier 1 seed data — business mapping:
| Seeded Entity | Represents in Real Retail Environment |
|---|---|
svc-harbor-order-sync (cross-cloud, PII) | ServiceNow integration syncing e-commerce orders from AWS DynamoDB to IT ticketing for fulfillment issues. Access path: ServiceNow → Entra SP → AWS IAM Role → DynamoDB (orders table with customer PII) |
svc-harbor-inventory-bridge (cross-cloud, orphaned) | Inventory reconciliation between AWS warehouse system and ServiceNow CMDB. Owned by "Supply Chain IT" team — team was dissolved in reorg, no new owner assigned |
svc-harbor-loyalty-export (external egress, PII) | Customer loyalty data export to external marketing analytics vendor. Crosses from Entra identity into AWS S3 bucket with customer purchase history |
svc-harbor-returns-proc (scope drift) | Returns processing automation. Started in ServiceNow, expanded to read payment metadata from AWS payment gateway |
| AWS IAM cross-account trust | IAM role with trust policy allowing assume-role from the Entra SP — the bridge that makes cross-cloud access invisible to single-cloud tools |
Compliance tags: PCI-DSS, GDPR, CCPA | Maps to customer data protection requirements across jurisdictions |
Systems needed (Tier 2): ServiceNow (dev instance), Entra ID (test tenant), AWS (sandbox account)
Connector dependency: Tier 2 for this scenario requires the AWS connector, which has not shipped yet. Until the AWS connector is available, this scenario is Tier 1 (seed data) only. The seed scripts can model the cross-cloud access paths, but live ingestion from AWS is blocked. Plan accordingly when scheduling Phase 3.
Scenario 6: Government Contractor — Controlled Unclassified Information (CUI) Access Control
Industry: Defense / Government Contracting
Narrative: A defense contractor ("Apex Defense Solutions") maintains strict access control boundaries between CUI (Controlled Unclassified Information) and standard corporate environments. IT automation was introduced to streamline helpdesk operations and asset management across both environments. Over time, some service accounts gained access to CUI-scoped data stores without proper review.
What SecurityV0 reveals:
- 2 ServiceNow automations with access paths that cross environment boundaries (standard corporate → CUI-scoped data stores)
- 1 service principal with accumulated roles across 3 Entra tenants — exceeding its original single-tenant scope
- 4 automations with no individual owner — all team-owned, violating the contractor's access accountability policy
- Temporal snapshot shows the boundary violation emerged 4 months ago and was never detected
Why this sells: CMMC compliance requires demonstrable access control. Automated process access is a blind spot that auditors are starting to ask about.
Tier 1 seed data — business mapping:
| Seeded Entity | Represents in Real Gov Contractor Environment |
|---|---|
svc-apex-helpdesk-bridge (boundary crossing) | ServiceNow automation routing IT tickets across the standard/CUI boundary. Originally scoped to standard corporate environment only — gained read access to CUI asset inventory via a misconfigured role grant |
svc-apex-asset-sync (boundary crossing, group-owned) | Asset management sync between two Entra tenants (standard corporate and CUI-scoped). Owned by "IT Infrastructure" group, no individual accountability |
svc-apex-patch-compliance (multi-tenant drift) | Patch compliance reporting spanning 3 Entra tenants. Started in one tenant, accumulated roles across all three via separate access requests |
svc-apex-onboarding-flow (group-owned) | Employee onboarding automation. Team-owned, violates the contractor's individual accountability policy for CUI-adjacent processes |
| Temporal snapshots showing boundary breach | Shows the CUI access appearing exactly 4 months ago in a single role change — no review, no detection since |
Compliance tags: CMMC Level 2, NIST 800-171, CUI | Maps to specific CMMC access control practices (AC.L2-3.1.1, AC.L2-3.1.2) |
Systems needed (Tier 2): ServiceNow (dev instance), Entra ID (2 test tenants)
Scenario 7: Manufacturing — IT/OT Bridge Automation Risk
Industry: Manufacturing
Narrative: A manufacturing company ("Ironworks Industrial") connected their operational technology monitoring (plant floor systems, SCADA alerts) to their IT service management via ServiceNow. Automated workflows bridge sensor data, maintenance tickets, and production alerts between OT and IT environments. These integrations were built by operations engineers, not the security team.
What SecurityV0 reveals:
- 3 ServiceNow automations bridging OT monitoring data to IT systems — none governed by the security team
- 1 automation exporting production data to an external vendor analytics platform — dormant for 3 months but credentials still active
- 2 service accounts with admin-level access to both OT alerting and IT ticketing — scope far exceeds operational need
- No individual owner on any OT-bridge automation — all owned by the "Plant Operations" group
Why this sells: IT/OT convergence is a growing attack surface. SecurityV0 shows the automated bridges between these worlds that traditional tools can't see.
Tier 1 seed data — business mapping:
| Seeded Entity | Represents in Real Manufacturing Environment |
|---|---|
svc-ironworks-scada-bridge (OT/IT bridge, group-owned) | ServiceNow integration pulling SCADA alerts from OT monitoring system into IT incident management. Owned by "Plant Operations" group — operations engineers built it, security team has no visibility |
svc-ironworks-maintenance-auto (OT/IT bridge, over-privileged) | Automated maintenance ticket creation from equipment sensor data. Has admin-level access to both OT alert tables and IT CMDB — far exceeds what's needed for ticket creation |
svc-ironworks-vendor-analytics (dormant, external egress) | Production metrics export to external vendor analytics platform (PredictiveMaint Inc.). Dormant 3 months, active credentials to production data and external endpoint |
svc-ironworks-shift-report (OT/IT bridge, over-privileged) | Automated shift report generation pulling from OT production counters and IT asset records. Admin access to both domains |
Compliance tags: IEC 62443, NIST CSF | Maps to IEC 62443 zone/conduit model and NIST Cybersecurity Framework requirements for OT environments |
Systems needed (Tier 2): ServiceNow (dev instance), Entra ID (test tenant)
Scenario Variant: Post-M&A Identity Orphanage (applies to any scenario)
Not a standalone scenario — this is a variant that can overlay any of the above scenarios with minimal extra work (zero additional connector requirements).
Narrative: After an acquisition, the acquired company's service accounts were migrated into the parent company's Entra tenant. The migration preserved access but lost ownership context — the original owners are no longer in the directory, team names changed, and nobody in the parent company knows what these automations do or who is responsible.
What SecurityV0 reveals:
- N orphaned service principals whose original owners exist only in the acquired company's (now-decommissioned) directory
- Automations still running with the acquired company's naming conventions, accessing data domains in the parent company
- No accountability chain — ownership points to groups or individuals that don't exist in the current org
Why this variant matters: Post-M&A identity cleanup is one of the most common and immediately recognizable problems in enterprise security. Adding 2-3 "acquired company" service principals to any scenario creates instant recognition for prospects who have been through an acquisition.
Tier 1 implementation: Add 2-3 entities with acquired-company naming (e.g., acq-legacy-invoice-sync) and orphaned ownership to any existing scenario seed script. Minimal effort.
AWS Agentic Demo Lab — Bedrock, MCP, and Cross-System Paths
Added 2026-04-08, revised 2026-04-09. This section reprioritizes the demo lab program to lead with AWS agentic scenarios (Bedrock + MCP + cross-system authority paths) and consolidates the program into exactly two labs (Nimbus Cloud + Nimbus Enterprise) instead of one lab per connector feature. Aligns with the Agentic Authority Impact Assessment architecture and the AWS Integration Strategy.
Why Agentic First
The original phasing (Phase 1: ServiceNow + Entra scenarios) was designed before the AWS connector and deployment approval architecture existed. The market has shifted:
- Clients are asking: "How can I approve deploying something new with MCP? How can I see what changes in the identity graph?"
- Bedrock agents, MCP servers, and multi-agent orchestration are the hottest buyer topic in 2026
- SecurityV0's differentiator — cross-system authority paths — is most compelling when it traces an AI agent across AWS, MCP, Entra, and ServiceNow in a single graph
The ServiceNow + Entra scenarios (#1–#4) already work with synthetic seed data (Tier 1). AWS agentic scenarios require real infrastructure to be credible — this is where Tier 2 investment should go first.
AWS Organization Structure
The demo lab runs in a dedicated AWS Organization under SecurityV0's management account. Credits: $5,000 via Mercury AWS Activate (Portfolio tier).
Root
├── securityv0-mgmt (365066817305) — management account, billing only
├── SecurityV0 Platform (OU — empty, future connector Lambda/EventBridge)
└── SV0 Demo Labs (OU)
├── Nimbus Cloud (Lab 1 — single-account AI startup, shipped)
│ └── sv0-demo-lab-1 (087380083467, us-east-2)
└── Nimbus Enterprise (Lab 2 — multi-account, cross-system, future)
├── nimbus-security — org trail, Config Aggregator, Access Analyzer, SV0 connector reads here
├── nimbus-workloads — Bedrock agents, Lambda action groups, MCP servers, Step Functions
└── nimbus-data — S3 (KB sources, PII), DynamoDB, Secrets Manager
Each demo lab is an OU named after a fictional company. We treat Nimbus Cloud (Lab 1) and MediaPro (Lab 2) as the same fictional customer at two life stages — a single-account AI startup (Lab 1) and the same company post-Series-C, now multi-account, with identity governance and ITSM (Lab 2). This gives the sales team a story arc that bridges both demos instead of two unrelated brands.
Lab 2 brand update (2026-04-22): the placeholder "Nimbus Enterprise" name has been retired in favor of MediaPro — a real upcoming pilot, multi-AWS, post-Series-C streaming-media SaaS. MediaPro is the canonical Lab 2 customer going forward. See MediaPro Lab 2 demo plan for the current architectural plan and the end-to-end implementation umbrella for the full work-stream sequencing. The Lab 2 section below documents the original architectural intent; the MediaPro plan supersedes it on naming, scenario coverage, and IaC layout.
Two-Lab Principle
There are two demo labs, total. New connector features grow Lab 1 in place; new integration strategies graduate to Lab 2.
This is a deliberate constraint. Earlier drafts of the Phase 2 plan paired every connector feature with its own demo-lab issue, which would have spawned 4–5 small labs. We are not doing that. Instead:
- Lab 1 — Nimbus Cloud is the home for everything the AWS connector can show against a single account. ECS/ECR, CloudTrail seed data, IAM Access Analyzer, additional Bedrock workloads — these all land in Lab 1 by extending its terraform, not by spinning up a new lab.
- Lab 2 — Nimbus Enterprise is built once when the cross-system narrative is genuinely ready end-to-end: AWS multi-account org + Entra IdP federation + ServiceNow + cross-connector graph stitching (platform issue #300). Until those pieces are all in place, building Lab 2 produces a half-stitched demo that undersells the product.
- No third lab exists. If a future feature needs to be demoed and doesn't fit either lab's narrative, the right answer is almost always "extend Lab 1 or Lab 2," not "create Lab 3." A new lab only earns its existence by showing a structurally different integration strategy, not a new feature.
This rule supersedes any per-feature demo-lab issues already filed in sv0-demo-labs. Issues tied to ECS/ECR, CloudTrail, multi-account, and Entra federation should be reframed as Lab 1 expansions or as components of the single Lab 2 build, not as standalone labs.
Lab 1 — Nimbus Cloud (Single Account, AI Startup) — Shipped
Status: Shipped. The terraform lives at sv0-demo-labs/labs/sv0-demo-lab-1/. The lab runs in account 087380083467 (us-east-2) under the Nimbus Cloud OU. AWS connector Phase 1 has been validated end-to-end against this lab.
Goal: A concise, single-account narrative — what does an AI-native startup's blast radius actually look like — that proves the AWS connector pipeline and tells a complete story without depending on any other system.
Deployed inventory:
- IAM: roles, policies, trust relationships (the connector parses both inline and managed policy attachments)
- Compute: Lambda functions with execution roles
- Bedrock: agents, knowledge bases, action groups, flows
- Data: S3 buckets, DynamoDB tables, Secrets Manager secrets, SSM parameters
- Eventing: SNS topics, EventBridge rules, Step Functions state machines
- CloudTrail: account-level trail (the management trail is on; per-path execution evidence still requires connector #31 + seed data)
- IAM Access Analyzer: account-level
Current connector baseline (after Phase 1):
| Metric | Value |
|---|---|
| Nodes | 88 |
| Edges | 86 |
| Authority paths | 13 |
| Findings | 51 (5 critical / 20 high / 26 medium) |
What Lab 1 validates:
- AWS connector discovers Bedrock agents + KBs + action groups + flows
- IAM trust policy parsing works (service roles, execution roles, OIDC federation)
- Authority paths materialize from Bedrock → service role → Lambda → execution role → Secrets / DynamoDB / S3
- Tag-based ownership inference and orphan detection
- Tiered permission model (Tier 1/2/3 connector IAM)
- Evidence completeness reporting per source system
Lab 1 expansion path (no new lab — these all extend the same terraform):
| Increment | Status | Pairs with |
|---|---|---|
| ECS/ECR (Fargate data pipeline with overprivileged task role) | Connector wired in PR #37; lab terraform pending in sv0-demo-labs#2 (to be reframed as a Lab 1 expansion) | sv0-connectors#30 |
| CloudTrail seed data for proven_execution evidence | Pending | sv0-connectors#31 + platform #302 |
| IAM Access Analyzer integration | Pending | sv0-connectors#33 |
| Pagination retry correctness fix | Pending | sv0-connectors#36 |
These increments do not create new labs. They grow the Nimbus Cloud terraform and re-validate against the existing baseline.
This covers Scenario B1 from the deployment approval architecture.
No cross-account, no cross-system. That is by design. Lab 1 is the concise demo — anything cross-system belongs in Lab 2.
Lab 2 — MediaPro (Multi-Account + Cross-System) — The Killer Demo
Authoritative plan:
2026-04-22-mediapro-lab2-demo-plan.md. The dependency-sequencing for the architectural prerequisites lives in2026-04-22-multi-account-e2e-implementation-plan.md. The section below remains as the original architectural intent (preserved for traceability) — refer to the MediaPro plan for the current account names (mp-security/mp-workloads/mp-data), validation matrix, and Terraform layout.
Status: Not yet built. Built once, when all of: AWS connector multi-account scanning (sv0-connectors#32), Entra connector ready for the federation story, ServiceNow connector ready, and platform-level cross-connector graph stitching (sv0-platform#300) are in place. Building it earlier produces a half-stitched demo that undersells the product.
Goal: Demonstrate SecurityV0's unique value — tracing an AI agent's authority across AWS accounts, through MCP, into Entra and ServiceNow — in a single graph that no single-cloud tool can produce.
Narrative: Nimbus Cloud (Lab 1's AI startup) has just closed its Series C, hired a CISO, and adopted Entra ID for SSO and ServiceNow for ITSM. The same automations from Lab 1 now span three AWS accounts and reach into the new identity and ticketing stack. The CISO needs to know what the AI agents can actually touch.
AWS structure:
SV0 Demo Labs (OU)
└── Nimbus Enterprise (OU)
├── nimbus-security — org trail, Config Aggregator, Access Analyzer, SV0 connector reads here
├── nimbus-workloads — Bedrock agents, Lambda action groups, MCP servers, Step Functions
└── nimbus-data — S3 (KB sources, PII), DynamoDB, Secrets Manager
What to deploy:
In nimbus-workloads:
- Bedrock Supervisor Agent (
ops-coordinator) — routes to collaborator agents - Collaborator Agent 1 (
log-analyzer) — queries CloudWatch Logs - Collaborator Agent 2 (
remediation-executor) — Lambda withec2:RebootInstances,ssm:SendCommand - Bedrock Agent (
customer-support-bot) — KB + action group Lambda - Action Group Lambda — calls MCP server and ServiceNow via Secrets Manager credentials
- Cross-account role — assumes role in
nimbus-datato read S3 PII
In nimbus-data:
- S3 bucket — customer PII (records), KB source documents
- DynamoDB — support ticket log, customer records
- Secrets Manager — ServiceNow credentials, API keys
- Cross-account role — trust policy allowing assume from
nimbus-workloads
In nimbus-security:
- Organization CloudTrail — logs all activity across all accounts
- Config Aggregator — resource inventory across accounts
- IAM Access Analyzer — org-level, detects external and unused access
- Security Hub — aggregated findings
- This is where the SV0 AWS connector connects — single ingest point
Cross-system wiring (requires Entra + ServiceNow connectors):
Bedrock Agent (nimbus-workloads)
→ Action Group Lambda
→ Secrets Manager (nimbus-data) — ServiceNow credentials
→ ServiceNow REST API — creates incidents, updates CMDB, queries HR PII
→ MCP Server (Azure Function with managed identity)
→ Entra Service Principal (sp-nimbus-ops)
→ ServiceNow OAuth App (same client_id — CORRELATED edge)
→ HR employee table (PII: name, SSN, salary)
What SecurityV0 shows in the stitched graph:
- AWS connector discovers: Bedrock agents, Lambda roles, cross-account trust, S3/DynamoDB data reach, CloudTrail evidence
- Entra connector discovers: Service principal ownership, disabled accounts, group memberships
- ServiceNow connector discovers: OAuth app, REST messages, HR table access, PII fields
- Stitched path: Bedrock Agent → Lambda → MCP → Entra SP → ServiceNow → HR PII
- The CISO story: "Your AI ops-coordinator agent can indirectly reboot EC2 instances AND read employee SSNs through a cross-account, cross-system path that touches 4 different platforms. Nobody approved this full path."
Demo scenarios covered (from 12-deployment-approval):
| Scenario | What It Proves |
|---|---|
| B1: Customer Support Agent | Tiered permission model, overprivileged Lambda |
| B2: Multi-Agent Supervisor | Transitive authority through collaborator agents |
| B3: Cross-Account Access | Authority path crosses account boundary to reach PII |
| M2: MCP as Bedrock Action Group | Lambda proxies to MCP server — IAM visible, MCP tools opaque |
| X3: Bedrock → Lambda → ServiceNow | Cross-system path from AWS into ServiceNow |
Critical dependency: Cross-connector entity correlation (Phases C/E from correlation research) must be built for the stitched graph. Without it, each connector produces a separate graph. The CORRELATED edge via client_id exists within entra-servicenow, but platform-level graph stitching across connector boundaries is not yet built.
Lab 2 — Phase B: Add Azure Foundry (Full Cross-Platform)
This is not a third lab. It is a follow-on phase that grows Lab 2 once the base Nimbus Enterprise environment is stable.
Goal: The flagship demo that no competitor can replicate — a single graph showing AI agent authority spanning Azure Foundry, AWS Bedrock, MCP, Entra, and ServiceNow.
This is Scenario X4 from the deployment approval architecture: a Foundry agent in Azure connects to an MCP server, which authenticates via Entra to ServiceNow. Meanwhile, a Bedrock agent in AWS accesses the same ServiceNow instance through different credentials. SecurityV0 traces both paths and shows the combined blast radius.
Phase B adds Azure Foundry resources to the existing Nimbus Enterprise environment and exercises the full cross-connector correlation engine. It is the validation gate for the Agentic Authority Impact Assessment feature.
Phase B is deferred until: Lab 2 base is built and stable + Azure Foundry connector is production-ready + cross-connector correlation has been validated against the AWS↔Entra↔ServiceNow stitched graph from Phase A.
Scenario Priority and Phasing (Updated 2026-04-09)
| Priority | Scenario | Lab | Systems | Rationale |
|---|---|---|---|---|
| Shipped | AWS connector Phase 1 baseline | Lab 1 — Nimbus Cloud | AWS (single account) | Connector validated end-to-end. 88 nodes / 86 edges / 13 paths / 51 findings. |
| Phase 1 | #3 Shadow AI / LLM (Tier 1 seed) | (no lab — seed only) | ServiceNow, Entra, Azure OpenAI | 2026 door-opener. Works today with synthetic seed data. |
| Phase 1 | Lab 1 expansion: ECS/ECR + CloudTrail seed + Access Analyzer | Lab 1 — Nimbus Cloud | AWS (single account) | Grow the existing lab in place. No new lab. Pairs with sv0-connectors #30/#31/#33 + platform #302. |
| Phase 2 | #1 Financial Services (Tier 1 seed + Tier 2 live) | (no lab — Tier 2 uses external SN/Entra dev instances) | ServiceNow, Entra | Broadest appeal. Tier 1 works now; Tier 2 adds ServiceNow live instance. |
| Phase 2 | Lab 2 — Phase A: Nimbus Enterprise (multi-account + cross-system) | Lab 2 — Nimbus Enterprise | AWS (3 accounts), ServiceNow, Entra | The killer demo. Built once when AWS multi-account scanning, Entra federation, and platform graph stitching are all ready. |
| Phase 3 | Lab 2 — Phase B: add Azure Foundry | Lab 2 — Nimbus Enterprise | Azure, AWS, ServiceNow, Entra | Grows Lab 2 with Foundry. Full cross-platform reality. |
| Phase 3 | #4 Insurance, #2 Healthcare | (no lab — seed only) | ServiceNow, Entra | Vertical-specific seed scenarios for pipeline. |
| Phase 3 | #5 Retail / Cross-Cloud | (no lab — seed only) | ServiceNow, Entra, AWS | Reuses Lab 1 narrative for the AWS side. |
| Phase 3 | #6 Gov Contractor | (no lab — seed only) | ServiceNow, Entra (2 tenants) | Niche, high-value. |
| Backlog | #7 Manufacturing / IT-OT | — | ServiceNow, Entra | OT side invisible to SV0 connectors. Defer. |
Forward Path
Step 1: Lab 1 — Nimbus Cloud baseline (Done)
- ✅ AWS Organization created;
sv0-demo-lab-1account087380083467underNimbus CloudOU - ✅ Mercury AWS Activate credits ($5K, Portfolio tier) applied
- ✅ IAM Identity Center configured (
sv0-demo-labs-1-IF-AdministratorAccessprofile) - ✅ Terraform under
sv0-demo-labs/labs/sv0-demo-lab-1/deploys Lambda, Bedrock, S3, DynamoDB, SNS, Step Functions, EventBridge, Secrets, IAM, CloudTrail, Access Analyzer
Step 2: AWS connector Phase 1 validation against Lab 1 (Done)
- ✅ AWS connector built and merged in
sv0-connectors - ✅ Validated against Lab 1: 88 nodes / 86 edges / 13 authority paths / 51 findings (5 critical / 20 high / 26 medium)
- ✅ Authority paths materialize; trust policy parsing works; tiered permission model verified
Step 2b: Lab 1 expansion increments (In progress — no new lab)
These extend the existing Lab 1 terraform and connector. Each is a discrete PR pair, not a new demo environment.
- ECS/ECR Fargate data pipeline — connector wiring shipped in
sv0-connectors#37. Lab terraform expansion pending insv0-demo-labs#2(to be reframed as a Nimbus Cloud expansion, not a new lab). - CloudTrail seed + per-path execution evidence — connector
sv0-connectors#31+ platformsv0-platform#302. Lab terraform pending insv0-demo-labs#4(reframed as Nimbus Cloud expansion). - Pagination retry correctness — connector
sv0-connectors#36. No lab change required. - IAM Access Analyzer — connector
sv0-connectors#33. Lab terraform may need a tightening pass.
Step 3: Tier 1 Seed Scripts (ServiceNow + Entra Scenarios)
Build per-scenario seed scripts for the existing scenarios (#1–#4) in parallel with AWS work:
- One seed script per scenario (e.g.,
seed-finserv.ts,seed-shadow-ai.ts), composable so multiple can run in parallel as separate tenants - Seed
entity_versionshistory — critical for temporal findings (scope_drift,ownership_drift) - Compliance domain tags tied to real framework control IDs
- Documentation alongside each seed script explaining the business mapping
Step 4: Lab 2 — Nimbus Enterprise build (gated)
This is the single Lab 2 build. It is gated on the prerequisites listed above (sv0-connectors#32 multi-account, Entra federation readiness, ServiceNow connector, and sv0-platform#300 cross-connector graph stitching). Until those land, do not start this work — the resulting demo would be a half-stitched graph.
When the gate opens:
- Create
Nimbus EnterpriseOU with 3 accounts (nimbus-security,nimbus-workloads,nimbus-data) - Deploy the full Bedrock + MCP + cross-account terraform stack
- Wire ServiceNow and Entra connectors to the same demo tenant
- Validate cross-system authority paths render as a single stitched graph in SecurityV0
Step 5: Tier 2 — ServiceNow + Entra Live Instances
Establish live infrastructure for ServiceNow + Entra scenarios:
- ServiceNow developer instance(s) — free tier available for development
- Entra ID test tenant(s) — Azure AD Free or P1 trial
- Infrastructure-as-code templates to provision and reset environments
ServiceNow PDI hibernation risk: Free PDIs hibernate after 10 days of inactivity. Mitigation: GitHub Actions keep-alive (already implemented in sv0-connectors). Pre-demo checklist as backup.
Step 6: Demo Playbook
Package each scenario into a repeatable demo flow:
- Scenario brief (1-page context for the sales team)
- Guided walkthrough (what SecurityV0 surfaces, in what order)
- Tier selection guide — when to use seed data vs. live environment
- Reset procedure for both tiers (re-run seed script /
cdk deploy/ re-provision IaC)
Step 7: Continuous Evolution
- Add new scenarios as connectors expand (e.g., Okta, GCP, Vertex AI)
- Update existing scenarios when new capabilities ship
- Use prospect feedback to refine narratives
Relationship to Existing Demo Data
The Demo Lab evolves the current approach rather than replacing it:
| demo-w1 (current) | Demo Lab Tier 1 (enhanced seed) | Demo Lab Tier 2 (live) | |
|---|---|---|---|
| Use case | Development, CI testing | Quick demos, first calls, internal reviews | Sales demos, prospect pilots, partner training |
| Setup time | Seconds | Seconds | Minutes |
| Connector required | No | No | Yes |
| Business context | Generic (Contoso) | Industry-specific with documented mappings | Industry-specific in real systems |
| Temporal history | Static | Synthesized multi-snapshot | Real scan history |
| Realism | Sufficient for dev | Convincing for initial conversations | Production-grade |
| Maintenance | Low | Low-Medium | Medium |
demo-w1 continues to serve as the development and CI baseline. Demo Lab Tier 1 scenarios are the next step up for any customer-facing conversation. Tier 2 is reserved for high-value opportunities where "show me the source system" matters.
Open Questions
-
Shared vs. per-scenario ServiceNow instances? A single dev instance with multiple scenarios is cheaper but risks data bleed between scenarios. Separate instances are cleaner but cost more to maintain.
-
Temporal history depth. How many scan cycles should we pre-populate to show meaningful temporal trends (scope drift over time, dormancy detection)?
-
Prospect self-service. Should we build toward letting prospects connect their own test environments, or keep Demo Lab as a controlled, sales-led experience?
-
Data refresh cadence. Should Demo Lab environments be static (reset before each demo) or evolving (data changes over time to simulate real environment drift)?
-
Partner access. Do channel partners get their own Demo Lab instances, or do they use ours during joint demos?