Skip to main content

AWS Integration Strategy for SecurityV0

Executive Summary​

The right AWS move for SecurityV0 is not "cover AWS broadly." It is:

  1. Treat AWS as a workload-identity and access-path platform from day one.
  2. Assume multi-account is the default customer shape, not an advanced case.
  3. Lead with serverless + Bedrock + cross-account trust, because that is where modern autonomous authority is easiest to prove and most relevant to buyers.
  4. Use AWS CDK for demo infrastructure generation, with StackSets only for shared multi-account baseline.

The most effective sequential wedge for now is:

  • Phase 0 foundation: account-aware tenant model, org/account/OU inventory, org-trail-compatible evidence ingestion, demo org bootstrap.
  • Phase 1 wedge: IAM roles + AssumeRole trust + Lambda + Step Functions + EventBridge + Secrets Manager + S3/DynamoDB + Bedrock Agents/Knowledge Bases/Flows.
  • Phase 2 expansion: ECS/ECR/EKS Pod Identity + GitHub OIDC + supply-chain-to-runtime authority paths.
  • Phase 3 hardening: deeper SCP/KMS/resource-policy evaluation, IAM Identity Center correlation, richer ServiceNow and external-system pathing.

This keeps the product aligned with SecurityV0's core promise: deterministic, evidence-backed visibility into what autonomous systems did access, under what identity, across which boundaries, and who owns it.

1. Product Frame: What AWS Should Mean for SecurityV0​

AWS should not turn SecurityV0 into a generic CSPM or "everything in the AWS console" scanner.

The AWS expansion should stay centered on five SecurityV0 principles:

PrincipleAWS implication
Observed authority firstPrefer CloudTrail / invocation / execution evidence over static inventory whenever possible
Workload identity, not just IAM hygieneCenter the model on roles assumed by Lambda, ECS, EKS, Step Functions, Bedrock, and automation services
Cross-system execution pathsPrioritize paths that cross accounts, clouds, CI/CD systems, ITSM, or AI systems
Ownership and accountabilityShow which team or individual owns the workload and which account/OU it sits in
Deterministic proof over probabilistic scoringSurface structural caveats clearly when conditions, SCPs, or KMS layers are not fully evaluated

In Scope for the first serious AWS push​

  • Autonomous workloads and their runtime identities
  • Cross-account trust chains
  • Sensitive-data reach from workloads
  • Agentic / Bedrock surfaces
  • Cross-system orchestration involving ServiceNow, GitHub, IdPs, and external APIs
  • Demoable, real infrastructure with repeatable seeded data

Explicitly not the first goal​

  • Exhaustive coverage of every AWS service
  • Full human IAM posture management
  • Generic EC2 inventory and every legacy IAM user pattern
  • Perfect effective-permission simulation across all IAM conditions on day one

2. The Realistic AWS Customer Shape​

SecurityV0 should design for the customer shape AWS itself recommends: multiple accounts organized into OUs, with tightly controlled access to the management account and workloads running mostly in member accounts.

AWS documentation is clear on the fundamentals:

  • AWS Organizations is the central control plane for multi-account governance.
  • The management account should be tightly restricted and should not contain business workloads.
  • Organization trails can log activity across all member accounts automatically.
  • IAM Identity Center is organization-scoped and maps permission sets to roles in accounts.

Product implication​

Multi-account cannot be an "enterprise add-on." It must be part of the first-class model:

tenant
  -> aws_organization
    -> organizational_unit
      -> aws_account
        -> region
          -> workload / identity / resource / evidence
ModeWhen to useProduct stance
Organization modeReal customer, serious pilot, best demoPreferred path
Selected accounts modeCustomer has fragmented ownership or limited sponsor accessMust be supported in v1
Single-account modeSmall teams, evaluations, dev sandboxesSupported, but treated as starter mode

Non-negotiable fields in the AWS data model​

  • organization_id
  • ou_id
  • ou_path
  • account_id
  • account_name
  • account_purpose (security, shared_services, prod, sandbox, data, etc.)
  • region
  • is_management_account
  • is_delegated_admin

Even if deeper SCP evaluation is phased later, account and OU context must exist from day one or the first enterprise onboarding will paint us into a corner.

3. The Most Valuable AWS Use-Case Families​

The strongest initial value is where four things overlap:

  1. real workload identity,
  2. autonomous execution,
  3. sensitive data or privileged operations,
  4. easy buyer narrative.

3.1 Serverless production automation​

Why it matters: This is the cleanest AWS NHI surface. Lambda, Step Functions, EventBridge, and Secrets Manager are widely used, high-value, and deterministic.

SecurityV0 story:
workload -> runtime role -> secret/data store -> observed execution

Priority entities

  • Lambda execution role
  • Step Functions execution role
  • EventBridge rules and API destinations
  • Secrets Manager secrets
  • SSM SecureString parameters
  • S3 buckets
  • DynamoDB tables
  • RDS / Aurora metadata

High-signal findings

  • orphaned runtime role with recent execution
  • dormant role with standing access to secrets
  • cross-account AssumeRole into restricted data
  • external API egress from EventBridge or Step Functions
  • scope drift on runtime role compared with observed usage

3.2 Bedrock and agentic workloads​

Why it matters: This is the CEO's wedge and a strong category story. Bedrock is now a real workload plane, not a novelty surface.

SecurityV0 story:
agent or flow -> service role -> knowledge base / action group / model invocation logs -> destination data

Priority entities

  • Bedrock agents
  • Bedrock agent aliases
  • action groups
  • knowledge bases
  • flows
  • guardrails
  • model invocation logging configuration
  • supporting Lambda functions

3.3 Cross-account platform operations​

Why it matters: The highest-severity AWS incidents often involve lower-trust accounts reaching higher-trust accounts through role trust or artifact pipelines.

SecurityV0 story:
workload in account A -> AssumeRole -> role in account B -> sensitive data or prod mutation

Priority entities

  • cross-account role trust
  • org trail / org evidence
  • selected SCP context
  • shared services account
  • security account
  • prod workload accounts

3.4 Container workload identities and supply chain​

Why it matters: ECS, EKS, ECR, and GitHub OIDC are how many modern teams actually deploy.

SecurityV0 story:
GitHub Actions or CI -> OIDC / AssumeRole -> ECR -> ECS or EKS runtime role -> data

This is highly valuable, but more complex than serverless and Bedrock. It should be the next expansion, not the first blocker.

3.5 ITSM and operations orchestration​

Why it matters: Buyers understand ServiceNow. It turns AWS authority into an operational governance story, not only a cloud-security story.

SecurityV0 story:
ServiceNow flow or ticket action -> AWS automation or API -> AWS workload / resource

or

AWS finding / event / incident -> ServiceNow incident / change / CMDB

4. Cross-System Patterns We Should Design For​

These are the most realistic cross-system patterns to treat as first-class narratives.

4.1 ServiceNow -> AWS operations​

AWS's own Service Management Connector and Systems Manager docs show that ServiceNow commonly drives:

  • Systems Manager Automation runbooks
  • OpsCenter items
  • Incident Manager workflows
  • pre-approved AWS change requests

This matters because the control point is often outside AWS, while the authority executes inside AWS.

Path pattern

ServiceNow workflow
  -> credential / integration
  -> AWS API or Systems Manager automation
  -> AWS role / runbook / workload
  -> target resource

4.2 AWS -> ServiceNow incidents and changes​

AWS also supports bi-directional patterns where AWS events or findings create or update ServiceNow records.

High-value examples:

  • Security Hub findings -> ServiceNow incidents
  • OpsItems -> ServiceNow tickets
  • EventBridge / Step Functions HTTP tasks -> ServiceNow APIs

Path pattern

AWS event source
  -> EventBridge / Step Functions / Lambda
  -> connection secret / auth method
  -> ServiceNow endpoint
  -> incident / change / CMDB update

4.3 GitHub -> AWS runtime​

AWS IAM explicitly supports OIDC federation for external systems such as GitHub Actions.

Path pattern

GitHub workflow
  -> OIDC federation
  -> IAM role
  -> ECR / Lambda / ECS / CloudFormation / CDK deployment
  -> runtime workload role
  -> data access

This is one of the strongest "modern company" stories because it shows how CI/CD authority becomes runtime authority.

4.4 Entra / Okta -> IAM Identity Center -> AWS accounts​

IAM Identity Center is the clean human-to-account control plane. Even though SecurityV0 is NHI-first, this matters for:

  • proving who can assign or change access to workloads,
  • correlating owner/team context,
  • showing where workforce and workload authority interact.

Path pattern

Entra or Okta user/group
  -> IAM Identity Center
  -> permission set
  -> account-scoped role
  -> ability to alter workload identities or Bedrock resources

4.5 Bedrock -> external systems​

Bedrock action groups, flows, and supporting Lambda functions can reach external systems through HTTPS APIs or downstream systems like ServiceNow, Slack, CRMs, and internal APIs.

Path pattern

Bedrock agent or flow
  -> service role
  -> action group Lambda / Step Functions / HTTP task
  -> external API or SaaS
  -> business data movement

This is where SecurityV0 can make "agentic access path" concrete instead of hand-wavy.

5. Bedrock and Agentic Scope: What We Need to Understand Early​

Bedrock is not one thing. It is several identity and data surfaces layered together.

5.1 The core Bedrock workload surfaces​

SurfaceIdentity surfaceData surfaceWhy it matters
AgentAgent service rolemodel calls, KB queries, action executionprimary autonomous workload
Knowledge BaseKB service roleS3 / OpenSearch / Aurora / external vector store authdurable data access plane
FlowFlow service rolenodes may touch prompts, agents, KBs, Lambda, S3, guardrailsorchestration layer
Action groupLambda resource policy + Lambda execution roleany system reachable by Lambdatransitive authority hop
GuardrailBedrock and KMS permissionspolicy/control metadatacontrol artifact, not just model setting
Invocation loggingaccount-level configrequest, response, metadata in CloudWatch/S3evidence surface

5.2 Bedrock-specific product implications​

Agents have real execution identities​

Bedrock Agents use service roles with permissions to call models, query attached knowledge bases, invoke collaborators, apply guardrails, and interact with action-group Lambdas. That is a classic SecurityV0 identity surface.

Knowledge bases are separate authority surfaces​

A knowledge base has its own service role and its own data-source permissions. That means:

  • the agent may be narrow,
  • but the knowledge base role may be broad,
  • and the supporting vector store or S3 bucket may be even broader.

SecurityV0 should model this explicitly rather than flattening it into "agent can read KB."

Flows are orchestrators​

Bedrock Flows can invoke prompts, knowledge bases, agents, Lambda, S3, guardrails, and more. That makes flows equivalent to Step Functions for AI orchestration and a first-class workload type, not just metadata attached to an agent.

Invocation logging is critical evidence​

Amazon Bedrock model invocation logging is disabled by default and can log request/response data and metadata to CloudWatch Logs and S3. For SecurityV0, this is a high-value proof surface for observed authority and for demo realism.

Multi-agent collaboration creates data propagation paths​

Bedrock multi-agent collaboration adds another layer: the supervisor can coordinate or route work to collaborator agents, and can relay conversation history to collaborators. That creates a concrete intra-agent data propagation surface.

5.3 Bedrock-first findings worth planning now​

  • Orphaned agent with live action-group execution
  • Agent knowledge base role reaches restricted data domain
  • Supervisor agent can invoke collaborators with broader data reach than intended
  • Model invocation logging disabled on sensitive AI workflows
  • Action group Lambda has broader access than the agent's declared business purpose
  • Flow includes external egress node or Lambda path with weak ownership

5.4 Visual example: AWS agent creates a GitHub pull request​

This is a concrete pattern SecurityV0 should be able to represent, because it is both realistic and high-value:

The key is to avoid boiling the ocean while still building the right platform shape.

Phase 0: Foundation we should not skip​

This is the work that makes enterprise AWS possible.

Product / architecture​

  • Treat AWS accounts and OUs as first-class objects in the tenant model
  • Support selected-account and org-scoped onboarding
  • Add account/OU metadata to entities, findings, and access paths
  • Decide how account context appears in the UI and evidence pack

Connector architecture​

  • Two-tier data collection model:
    • Tier 1 — Central account (no spoke roles needed): Config Aggregator for resource inventory across all accounts/regions (IAM users, roles, policies, Lambda, S3, etc.), Security Hub for aggregated Access Analyzer/GuardDuty findings, CloudTrail Org Trail for execution evidence, Organizations API for account/OU discovery and SCPs
    • Tier 2 — Spoke roles (for deep IAM analysis): GetAccountAuthorizationDetails (full IAM dump), GenerateCredentialReport (key ages, MFA), GenerateServiceLastAccessedDetails (actual usage vs allowed), resource-based policies (s3:GetBucketPolicy, kms:GetKeyPolicy, lambda:GetPolicy)
  • Delegated admin, NOT management account: SecurityV0's connector should target a customer-designated Security Tooling account registered as delegated admin for Config, Security Hub, and Access Analyzer. The management account should never run business workloads (AWS best practice) and cannot be restricted by SCPs.
  • GetAccountAuthorizationDetails as the primary per-account API — returns all roles, users, policies, and trust policies in one paginated call per account
  • Trust policy parsing as a core differentiator — the AssumeRolePolicyDocument on every IAM role encodes the entire federation model (which services, accounts, OIDC/SAML providers can assume each role)
  • Phased scanning for time-to-value: P0 fast scan (roles + Lambda + Access Analyzer, 5-15 min/account) → P1 permissions → P2 evidence → P3 org context
  • CloudFormation StackSet for customer onboarding (deploys SecurityV0-ReadOnly role to all accounts)
  • Minimal-privilege connector IAM policy with explicit deny on all writes and secret value retrieval (see AWS Integration Competitive Analysis for concrete policy JSON)
  • STS operational limits to design for:
    • ~100 TPS rate limit on sts:AssumeRole per account — require exponential backoff and concurrency cap for multi-account scanning
    • Chained role sessions (Role A → Role B) always capped at 1 hour regardless of MaxSessionDuration — assume directly from hub to spoke, never chain
    • Cache assumed-role credentials and reuse until near expiry — do not call AssumeRole per API request
    • Use regional STS endpoints for lower latency; must be explicitly activated
    • Cannot AssumeRole across AWS partitions (aws → aws-cn / aws-us-gov) — separate connector instances per partition

Evidence​

  • Plan for organization trail ingestion
  • Define which observed-evidence fields are mandatory vs optional
  • Make all AWS paths carry explicit caveats when only structural authority is proven
  • Evidence completeness reporting per source: available, unavailable_not_enabled, partial (maps to existing evidenceCompleteness field in connector interface)
  • Flag Bedrock model invocation logging as a finding when disabled (disabled by default)
  • Flag CloudTrail data events (Lambda invocations, S3 access) status — only available if explicitly enabled in trail configuration

Demo lab​

  • Stand up one demo organization with a realistic OU structure
  • Decide the scenario definition format before writing IaC

Phase 1: Serverless + Bedrock core​

This is the best first delivery.

Must cover​

  • IAM roles and trust relationships (trust policy parsing as primary discovery mechanism)
  • cross-account AssumeRole
  • Lambda
  • Step Functions
  • EventBridge rules and connections
  • Secrets Manager
  • S3
  • DynamoDB
  • Bedrock agents
  • Bedrock knowledge bases
  • Bedrock flows
  • Bedrock invocation logging
  • CloudTrail org trail / per-account trail ingestion
  • IAM Access Analyzer findings (both external access and unused access — pre-computed signals for scope_drift, dormant_authority, and privilege_justification_gap findings)

Why this is the right wedge​

  • strongest buyer relevance
  • high density of NHI / workload identity
  • good observed evidence
  • modern architecture without needing total AWS breadth
  • directly supports Bedrock and non-AI automation stories

Phase 2: Runtime and supply chain expansion​

  • ECS task role vs execution role
  • ECR repository access
  • EKS Pod Identity and IRSA
  • GitHub OIDC to AWS
  • Lambda-to-Lambda and workflow-to-workload chaining

This phase unlocks the "pipeline to production runtime" story.

Phase 3: Control-plane and constraint depth​

  • IAM Identity Center permission sets and assignments
  • deeper SCP evaluation
  • KMS key policy-aware path filtering
  • richer resource-policy evaluation
  • broader ServiceNow / ITSM operational pathing

This phase improves precision and governance depth, but does not need to block the first meaningful launch.

7. Multi-Account Success Path Recommendation​

The onboarding and demo success path should mirror how mature customers actually run AWS.

7.1 Preferred topology​

Management account
Security account
Shared services account
Workload account(s)
Data account(s)
Sandbox account(s)

7.2 SecurityV0 product posture​

  • Preferred ingest point: delegated admin account (Security Tooling account) with Config Aggregator, Security Hub, and Access Analyzer. Not the management account — the management account is exempt from SCPs, making it the highest blast-radius target. SecurityV0 should never require running in the management account.
  • Preferred evidence source: organization trail to central S3 bucket in the log archive account
  • Preferred access pattern: read-only cross-account role with ExternalId + aws:PrincipalOrgID condition
  • Preferred scope controls: OU-based inclusion, account-level exclusions, region filters
  • Preferred deployment: CloudFormation StackSets (SERVICE_MANAGED permissions via delegated admin) to deploy SecurityV0-ReadOnly spoke roles. Enable drift detection to alert on spoke role tampering or deletion.
  • Fallback modes: If delegated admin slots are unavailable (customer already using them for Wiz/CrowdStrike), fall back to management account role with read-only Organizations API access + per-account spoke roles only.

7.2A Visual form: how an AWS access path should look in SecurityV0​

7.3 What "good enough" looks like in v1​

SecurityV0 does not need full effective-permission simulation on day one. It does need:

  • awareness of which account a workload belongs to
  • awareness of when authority crosses account boundaries
  • awareness of which OU/account contains sensitive targets
  • explicit labeling when SCP/KMS/conditions are not fully evaluated

That is enough to make the story real and evidence-backed without overclaiming.

7.4 Specific product decisions to make early​

  1. Will an AWS org map to one SecurityV0 source or many?
    Recommendation: one logical AWS source with per-account partitions, not one connector per account in the UI.

  2. Can customers onboard selected OUs only?
    Recommendation: yes, from the beginning.

  3. How will cross-account hops be shown in access paths?
    Recommendation: explicit account chips at every hop; do not hide account boundaries in the path UI.

  4. How will management-account sensitivity be treated?
    Recommendation: show any workload in the management account as a special governance smell, regardless of finding severity.

8. Demo Lab Strategy for AWS​

The user request is exactly right: we should create real AWS environments and data, not only synthetic platform rows.

8.1 Tooling recommendation​

Use AWS CDK v2 as the primary authoring layer.

Why CDK over raw CloudFormation​

  • faster to evolve scenarios in code
  • easier to model multiple accounts, environments, and repeated scenario variants
  • supports reusable constructs for "agent + kb + lambda + secret + bucket" patterns
  • synthesizes to CloudFormation, so we still stay in native AWS IaC

Why not make Terraform the default here​

  • the goal is fast iteration on AWS-native demos, not multi-cloud infra parity
  • the biggest complexity is scenario composition, not provider abstraction
  • CDK is better suited to encode realistic, programmable demo topologies quickly

Where StackSets fit​

Use CloudFormation StackSets with service-managed permissions only for org-wide baseline:

  • read-only SecurityV0 role deployment
  • shared logging bucket policies
  • CloudTrail / Config / Access Analyzer bootstrap
  • per-account baseline tags and outputs

Where Control Tower fits​

Control Tower is valuable for a more permanent demo org or partner lab because it gives:

  • landing zone structure
  • Account Factory
  • audit/logging baseline
  • recommended Security / Infrastructure / Sandbox / Workloads OU shape

But it should be treated as demo-platform bootstrap, not as the day-to-day scenario authoring tool.

AWS CDK app
  -> org baseline package
  -> scenario packages
  -> data seeding package
  -> post-deploy workload activity generators

Org baseline package​

  • optional Control Tower-aware bootstrap
  • baseline accounts / OUs
  • org trail
  • central logging bucket
  • read-only SecurityV0 role

Scenario packages​

  • serverless operations scenario
  • Bedrock support agent scenario
  • CI/CD to runtime scenario
  • ServiceNow to AWS operations scenario

Data seeding package​

  • S3 documents
  • DynamoDB sample records
  • Secrets Manager metadata
  • Aurora sample schema where needed

Activity generators​

  • Lambda invocations
  • Step Functions executions
  • EventBridge events
  • Bedrock agent invocations
  • cross-account AssumeRole activity

This is how we get real infrastructure plus realistic execution evidence.

8.3 Scenario-definition model​

Use a single scenario spec that can drive:

  1. AWS CDK infrastructure,
  2. post-deploy data seeding,
  3. expected SecurityV0 findings,
  4. demo documentation.

Suggested fields:

company_name:
industry:
accounts:
ous:
teams:
workloads:
identities:
data_stores:
cross_account_trusts:
external_systems:
bedrock_surfaces:
expected_paths:
expected_findings:

This mirrors the existing two-tier demo strategy, but with AWS as a first-class live source.

These are the first three AWS scenarios worth building.

Scenario A: Regulated multi-account serverless operations​

Narrative:
A financial or healthcare company runs scheduled and event-driven AWS automations across shared-services and prod accounts. A few runtime roles quietly gained too much access over time.

Why it sells

  • extremely recognizable
  • clean Lambda / Step Functions / Secrets Manager story
  • easy to produce observed evidence

Core path

Step Functions in shared-services
  -> AssumeRole into prod-data account
  -> Lambda
  -> Secrets Manager
  -> DynamoDB / Aurora / S3

Scenario B: Bedrock support or operations agent​

Narrative:
A SaaS company uses Bedrock Agents and Flows to summarize incidents, search internal runbooks, and take actions through Lambda. The AI workload now touches both sensitive data and operational systems.

Why it sells

  • current buyer urgency
  • clearly differentiates SecurityV0 from generic IAM tools
  • demonstrates that agentic systems have real runtime identity and data reach

Core path

Bedrock supervisor agent
  -> collaborator agent
  -> knowledge base
  -> action-group Lambda
  -> ServiceNow or internal API

Scenario C: GitHub to runtime supply chain​

Narrative:
GitHub Actions uses OIDC to assume a deployment role, pushes an image to ECR, and that image runs in ECS or EKS with broader runtime access than intended.

Why it sells

  • modern engineering reality
  • strong "development action becomes production authority" narrative
  • strong path visualization value

Core path

GitHub workflow
  -> OIDC provider
  -> deployment role
  -> ECR
  -> ECS task or EKS workload
  -> runtime role
  -> production data

Optional Scenario D: ServiceNow to AWS operations​

This should follow quickly after the first three if ServiceNow remains a key go-to-market bridge.

Visualized violation patterns to anchor early findings design​

10. Competitive Positioning​

Why this is a differentiated market move​

DimensionSecurityV0 advantage
NHI graph depthOnly product tracing Bedrock Agent → Lambda → cross-account → external system chains
Cross-systemEntra + ServiceNow + AWS + GitHub in one graph — competitors cover 1-2 systems max
Agentic AIFirst to map AI agent identity chains with blast radius — no competitor does this
DeterministicNo ML scoring — every finding is walkable, explainable, evidence-backed
TemporalDrift detection: "This role gained AdministratorAccess 47 days ago"

Current competitive gaps we fill​

CompetitorWhat they doWhat they miss
Wiz / OrcaCloud inventory + CSPMNo NHI execution chains, no cross-system, no Bedrock agent tracing
Astrix / OasisNHI lifecycle (tokens, keys)No workload identity chains, no AI agent coverage, no cross-system paths
AWS Access AnalyzerExternal access + unused accessNo graph, no cross-account path assembly, no cross-system
ConductorOne / VezaAuthorization graphsFocused on human access, limited NHI depth, no execution evidence

The Bedrock agentic chain tracing is a first-mover opportunity — no competitor currently traces from Bedrock Agent through Lambda action groups to external systems with full blast radius analysis.

How competitors onboard AWS (validated patterns)​

All major competitors use the same fundamental building blocks. SecurityV0's onboarding should be at parity:

VendorOnboarding PatternKey Detail
WizStackSets to root OU, role trusts Wiz SaaS account, OU/account exclusion supportTerraform provider (wiz_connector_aws) for IaC-native onboarding
CrowdStrikeIntermediate role in CS account + StackSets. API-driven registration returns auto-generated role ARNsEventBridge StackSet for near-real-time CloudTrail-based IOA detection
Prisma CloudSERVICE_MANAGED StackSets (delegated admin). 5 functional IAM policies. Auto-deployment to new accountsAPI workflow: fetch features → presigned CFT URL → deploy → register
LaceworkCustomer-side scanner account with ECS. Snapshot roles via StackSets5 specialized IAM roles for separation of duties
SailPointVA-based AssumeRole fan-out. No StackSets. CIEM module scales to 9,000 accountsSeparate connectors for IAM Users vs Identity Center
VezaSaaS cross-account roles. 28+ AWS service integrations. OAA SDK for custom extensions"Explain Assumed Roles" traces trust chains but lacks observed execution evidence. Uses Neo4j graph DB + PostgreSQL + ClickHouse + Kafka multi-store architecture. Full-replacement ingestion model (no delta API).

See AWS Integration Competitive Analysis for full details including Veza's platform architecture, IAM policies, trust policy patterns, and architecture diagrams.

11. What We Should Deliberately Defer​

These are important, but should not block the first meaningful AWS release:

  • full SCP and permission-boundary evaluation
  • complete KMS-aware effective reachability
  • broad EC2 / instance-profile coverage
  • every resource-based policy variant in every AWS service
  • exhaustive AWS service inventory
  • full human IAM governance parity with workforce products

The right move is to surface these as caveated structural gaps, not to wait until they are perfect.

12. Decision​

Recommendation​

Adopt the following as the official AWS plan:

  1. Model AWS as multi-account from the start.
  2. Launch with serverless + Bedrock + cross-account trust as the first real wedge.
  3. Treat GitHub OIDC, ECS/EKS, and ECR as the next expansion, not phase-zero blockers.
  4. Use AWS CDK for scenario infrastructure and StackSets for multi-account baseline.
  5. Stand up a real demo organization before trying to finish broad AWS connector breadth.

Why this is the most effective move now​

  • It matches current AWS customer reality.
  • It aligns with the CEO's Bedrock and buyer-relevance thesis.
  • It stays true to SecurityV0's deterministic product identity.
  • It creates strong demo narratives fast.
  • It avoids turning the AWS effort into an endless cloud-inventory project.

13. Suggested Immediate Next Actions​

  1. Write a short ADR for AWS multi-account tenant modeling.
  2. Create a GitHub epic for Phase 0 + Phase 1 AWS scope.
  3. Create sv0-demo-lab/aws/ and scaffold a CDK app with:
    • org baseline
    • scenario definition format
    • first serverless scenario
  4. Decide whether the first live AWS demo is:
    • regulated serverless, or
    • Bedrock support agent
  5. Update the earlier AWS connector research doc with a pointer to this strategy note as the product-facing sequencing layer.

Sources​

Primary sources used for this strategy and the 2026-03-31 competitive research update:

Appendix A: Visual Comparison — Current vs. AWS Access Paths​

A.1 Current state: Entra ID + ServiceNow only​

SecurityV0 today discovers execution paths between Microsoft Entra ID and ServiceNow. The graph follows: Workload → Connection → Credential → Identity → Role → Permission → Resource, with cross-system links via AUTHENTICATES_TO.

Limitation: The blast radius stops at the boundary of these two systems. We cannot see what else the SP can reach beyond Entra and ServiceNow.

A.2 With AWS — single-account access path​

Adding AWS reveals a dramatically richer NHI surface. AWS workloads (Lambda, Step Functions, Bedrock Agents) have their own execution identities (IAM roles), and those roles can reach sensitive data stores.

A.3 With AWS — multi-account cross-account path​

Real enterprises use multiple AWS accounts. Cross-account role assumption creates trust chains that are invisible without graph-based analysis.

A.4 With AWS — Bedrock agentic access path​

A single Bedrock Agent creates 4+ NHIs. No competitor currently traces these chains end-to-end.

Appendix B: Cross-System Value Analysis​

B.1 Finding complexity scales with connected systems​

B.2 Three-system access path: the killer demo​

This is the most valuable access path SecurityV0 can surface — spanning ServiceNow, AWS, and Entra ID:

The CISO story: "A ServiceNow emergency patch workflow can wipe every managed device in your organization. The path crosses three systems: ServiceNow triggers an AWS Lambda, which uses Entra credentials from Secrets Manager to authenticate as a Service Principal with Device.ReadWrite.All. Nobody owns this path."

B.3 Connector multiplication effect​

ConnectorsSystemsCross-System PathsExample Findings
Entra only10Orphaned SP, stale credentials
Entra + ServiceNow21 bidirectionalSP authenticates as SN integration user with admin role
+ AWS36 pathsSN → AWS → data, AWS → Entra, GitHub → AWS → SN, Bedrock → Lambda → Entra → SN
+ GitHub412 pathsFull supply chain: GH → AWS → Entra → SN with blast radius across all

Adding AWS doesn't just add AWS findings — it reveals hidden paths between ALL existing connectors that transit through AWS.

B.4 Cross-system value matrix​

Next Action​

Status: research-complete

Decision needed from: CEO / PO

Recommended action: Adopt Phase 0 + Phase 1, and start the AWS demo-lab scaffold in parallel with the connector architecture work.

Supporting reference: AWS NHI Workload Identity Surface — detailed entity-by-entity mapping catalog for connector implementation.