12 — Agentic Authority Impact Assessment

How SecurityV0 answers the question: "What changes in my security posture when I deploy this new MCP server or AI agent?"

---

Naming — What This Feature Actually Is

This capability has three distinct modes. Each has a different name because each makes a different promise:

Mode	Name	What It Does	Requires
Post-deployment detection	Authority Impact Assessment	SV0 scans, detects new agents, shows what authority they gained	Read-only API permissions (no client action)
Pre-deployment preview	Pre-Deployment Authority Preview	Client submits config/manifest before deploying; SV0 projects authority graph	Client submits config file (not code)
Deployment gate	Deployment Approval Gate	SV0 blocks or approves deployment via CI/CD integration	CI/CD webhook + enforcement integration

We do not call post-deployment detection "approval." Approval implies enforcement that does not exist yet. Security buyers will notice the difference.

---

Design Constraint: No Code Access

SecurityV0 discovers authority through cloud management plane APIs only. We never require access to client source code, repositories, or deployment pipelines.

• Clients will not give a security vendor access to their codebase
• Code access requires VPN, repository permissions, internal deployment access — each a separate sales blocker
• Management plane APIs are the source of truth for permissions. Code is the source of intent. SV0 cares about truth.
• Writing new connectors for new platforms is horizontal scaling — the more connectors, the better. But each connector uses only standard read-only cloud APIs.

---

How API-Only Discovery Works

The Core Loop

Closing the Scan Gap

Post-deployment detection has a timing gap: the agent exists before we scan it. Three mechanisms to minimize this:

Mechanism	How It Works	Latency
Event-driven scan trigger	EventBridge rule on bedrock:CreateAgent; ARM activity log on Foundry agent creation → triggers immediate SV0 scan	Minutes
Client webhook	After deployment, client CI/CD calls POST /api/v1/syncs/trigger → immediate scan	Seconds after deploy
Scheduled scan	Regular connector scan cycle	Hours (depends on schedule)

Event-driven triggers are the recommended path for clients who want near-real-time detection.

---

What Each Platform Exposes Through APIs

Azure AI Foundry — Production Today

Our existing azure-foundry connector discovers the full authority chain. Permissions are tiered:

Tier 1 — Minimal (agents + infrastructure):

Permission	Type	What SV0 Discovers
Reader	Azure RBAC (subscription)	Foundry projects, managed identities, ARM role assignments
Azure AI User	Azure RBAC (AIServices)	AI agents, connections (endpoints + auth types), execution activity

Tier 2 — Standard (adds identity resolution):

Permission	Type	What SV0 Adds
Application.Read.All	Graph API	Service principal details for each agent identity
Directory.Read.All	Graph API	Service principal owners — who is accountable
User.Read.All	Graph API	Owner account status — detect orphaned agents

Graceful degradation: Without Tier 2, the connector still discovers agents and infrastructure but cannot resolve identity ownership. This is documented in our pilot scope doc and works today.

What the connector actually sees (verified against foundry_client.py):

• list_agents() → agent name, model, tools, created_at
• list_connections() → connection type (AzureOpenAI, AzureBlob, CognitiveSearch, MCP, Custom), endpoint, auth type
• list_role_assignments() → ARM RBAC on managed identities
• count_threads() → execution evidence proxy (thread creation timestamps)

Honest limitation — MCP connections are a black box: When a Foundry connection has connection_type: "MCP", we see the endpoint URL and auth type. We do NOT see what tools the MCP server exposes, what data domains those tools access, or what downstream systems the MCP server connects to. The MCP server is opaque from the Foundry API.

Honest limitation — agent publish identity change: When a Foundry agent transitions from unpublished (shared project identity) to published (distinct Entra Agent ID), the identity changes. Our connector detects this as an entity update, but we need to verify we correctly surface this as a governance signal (new identity = new authority surface).

AWS Bedrock — Planned, Tiered Permissions

Tier 1 — Minimal (agent inventory):

API Call	What SV0 Discovers
bedrock:ListAgents, bedrock:GetAgent	Agent names, service role ARNs, model access, guardrail config
bedrock:ListAgentActionGroups	Action group → Lambda function ARNs
bedrock:ListKnowledgeBases, bedrock:GetKnowledgeBase	KB → data source type and ARNs
bedrock:ListFlows, bedrock:GetFlow	Flow definitions → node types
lambda:ListFunctions, lambda:GetFunction	Lambda configs → execution role ARNs

Tier 2 — Standard (adds managed policy names):

API Call	What SV0 Adds
iam:GetRole	Role trust policies (who can assume)
iam:ListAttachedRolePolicies	AWS managed policy names attached to roles

Tier 3 — Full (complete authority chain):

API Call	What SV0 Adds
iam:GetRolePolicy, iam:ListRolePolicies	Inline policy documents (full permission details)
s3:GetBucketPolicy, kms:GetKeyPolicy	Resource-based policies (cross-account access)
lambda:GetPolicy	Lambda resource policies

Graceful degradation:

• Tier 1 alone: "You have 5 Bedrock agents. We can see they exist and what Lambdas/KBs they use." No authority chain detail.
• Tier 1+2: "Agent X uses role Y with managed policies: AmazonS3ReadOnlyAccess, AmazonDynamoDBReadOnlyAccess." Authority chain by policy name, not specific resources.
• Tier 1+2+3: Full authority chain with specific resource ARNs and actions.

Honest limitation — IAM policy access is a hard sell. iam:GetRolePolicy exposes full policy documents including internal resource names and cross-account trust relationships. Many enterprises restrict this to internal security teams. The tiered model lets us deliver value without Tier 3, but the full authority story requires it.

Honest limitation — AgentCore Token Vault is partially opaque. We can see that Token Vault bindings exist and the credential provider type (Google, Slack, Salesforce). We cannot see specific OAuth scopes or downstream resource identifiers through read APIs.

Google Vertex AI — Planned

API Call	What SV0 Discovers
Agent Builder APIs	Agent definitions, tool configs, data store references
iam.googleapis.com	Service account IAM bindings per agent
cloudresourcemanager.googleapis.com	Project-level IAM policies

Similar tiered model. Needs detailed API audit before committing to specific permission requirements.

MCP — The Honest Gap

MCP servers are not cloud resources. There is no management plane API to discover them.

What We CAN See (no code access)	What We CANNOT See
If the MCP server runs under a known cloud identity → we see that identity's permissions	That it IS an MCP server specifically
Foundry connections of type "MCP" → endpoint + auth type	What tools the MCP server exposes
If the client uses an MCP gateway → gateway registry	Tool-to-data-domain mapping
	Downstream systems the MCP server connects to

For MCP, the honest answer is: "Submit the config file (mcp.json). It's not code — it's a 10-line JSON file declaring server name, tools, and identity bindings. We project the authority graph from that."

This is the one platform where we need client input. For Bedrock, Foundry, and Vertex AI, we discover everything through APIs.

Multi-Agent Systems — Visibility Limits

Pattern	What We See	Gap
Bedrock supervisor → collaborator	Supervisor's bedrock:InvokeAgent permission reveals collaborator ARN; both agents scanned independently	Need to stitch graphs to show full chain
Foundry A2A	Connection type AgenticIdentity reveals A2A endpoint	Cannot trace full authority chain through second agent from Foundry API alone
LangGraph/CrewAI multi-agent	Invisible — agent-to-agent delegation is a code construct	Only see runtime identity permissions, not inter-agent relationships

---

Client Journey

Stage 1 — Deploy

The dev team deploys the agent. No SV0 interaction needed — or optionally, client submits MCP config for pre-deploy preview.

Stage 2 — Discover

SV0 scan (scheduled or event-triggered) detects the new agent. All new authority paths are Grade C (structural).

Stage 3 — Review

Analyst reviews authority delta: new paths, sensitive data reachability, egress classification, ownership state, findings.

Stage 4 — Assess

Analyst records assessment: acknowledge baseline, flag findings, assign remediation. This is an assessment record, not an enforcement gate.

Stage 5 — Continuous Verify

Every subsequent scan compares against the assessed baseline. Authority drift is surfaced automatically. Evidence grades upgrade over time (C → B → A).

---

Architecture

What We Need to Build (W2) — Honest Complexity Assessment

Component	Description	Complexity	Why
Authority path snapshot model	New AuthorityPathSnapshotDoc capturing all active paths (full chain detail, not just counts) at a point in time. Current PostureSnapshotDoc stores only active_paths: number.	High	New collection, new storage methods, snapshot-on-demand trigger
Path-level diff engine	New diffAuthorityPaths(snapshotA, snapshotB) producing new/removed/modified paths. Current diff-engine.ts operates on EntityDoc only — zero awareness of AuthorityPathDoc.	High	New algorithm, not an extension of entity diff. Must compare composition_hash, evidence grades, ownership state per path.
Assessment workflow records	Store assessment decisions: who assessed, when, what authority posture was in scope, what findings were acknowledged.	Medium	New collection, new API endpoints, straightforward CRUD
"New agent" detection	When diff detects a workload entity that didn't exist in previous scan → flag as newly deployed, generate authority impact summary.	Low	Thin layer on top of entity diff
Scan trigger API	POST /api/v1/syncs/trigger with optional event context (which connector, what changed).	Medium	Endpoint exists in type system (ScanScope.targeted), needs connector support

What We Already Have (W1)

Component	How It Supports This Feature
azure-foundry connector	Already discovers Foundry agents, identities, connections, RBAC, execution evidence
NormalizedGraph ingestion	Same pipeline for all connectors
Authority Path Materializer	Builds authority chains; returns pathsCreated/Updated/Removed counts per sync
Evaluator (15 rules)	Fires on new paths (orphaned ownership, scope drift, LLM egress, etc.)
Entity-level diff	Computes entity changes between scans
Posture delta	Tracks new/removed path counts, ownership changes per sync
Evidence packs	SHA256 integrity-checked finding bundles
Circuit breakers	evaluateDeletionBreaker() and AP_REMOVAL_THRESHOLD prevent data corruption

Enforcement Integration Roadmap

SV0 is read-only. Assessment records are evidence, not enforcement. To become a deployment gate:

Integration	How It Works	Priority
CI/CD webhook	SV0 returns pass/fail for deployment checks (GitHub Deployment Protection Rules, Azure DevOps Checks)	P2 — after core assessment works
OPA/Conftest	SV0 exports authority data; customer's OPA policy evaluates pass/fail	P2 — data export, not enforcement
MCP Gateway	SV0 provides authority classification that gateways use for allow/deny	P3 — gateways are immature
Microsoft Agent Governance Toolkit	SV0 feeds authority data to AgentOS for runtime policy enforcement	P3 — toolkit is new (April 2026)

---

Demo Lab Validation Plan

Purpose

Before selling this capability, we need to prove it works on realistic agentic deployments. The demo lab simulates how enterprises actually deploy AI agents in March–April 2026, then validates that SV0 discovers the full authority chain through API-only scanning.

What Enterprises Are Actually Deploying (March–April 2026)

Based on market research (CSA, Gartner, client conversations):

Pattern	Prevalence	Example
Foundry agents for internal operations	High — Azure-first enterprises	HR document search, IT ticket triage, compliance check agents connected to SharePoint, ServiceNow, internal APIs
Bedrock agents for customer-facing automation	High — AWS-first enterprises	Customer support agents with KB (S3 docs), action groups (Lambda → CRM, ticketing, payment APIs)
MCP servers inside cloud platforms	Growing — developer tooling	MCP servers as Foundry connections or as Bedrock action group backends, providing tool access to databases, internal APIs
Standalone MCP servers for dev productivity	Growing — but not security-reviewed	Claude Desktop / Cursor / VS Code with MCP servers accessing internal databases, wikis, code repos
Multi-agent orchestration	Early — innovation teams	Bedrock supervisor + collaborators; LangGraph chains; Foundry A2A
Agents with cross-system access	Common — the scary case	Agent in Foundry reaching Azure Storage + external SaaS + ServiceNow via different identity paths

Azure Foundry Demo Lab (Extends Existing Infra)

Our existing Terraform in sv0-connectors/infra/ creates Foundry projects with AIServices. We extend it with realistic agent scenarios:

Scenario F1: HR Document Agent (benign, well-governed)

• Foundry project: hr-automation
• Agent: hr-doc-search — searches employee handbooks, answers HR policy questions
• Connections: Azure Blob Storage (HR docs, hr-data container), Azure OpenAI (gpt-4o-mini)
• Managed identity with Storage Blob Data Reader on HR container only
• Owner assigned: HR team lead
• What SV0 should discover: Clean authority chain, narrow permissions, valid owner, Grade C (no execution yet)
• Why this matters: Baseline for "what a well-governed agent looks like"

Scenario F2: IT Operations Agent (overprivileged, orphaned)

• Foundry project: it-ops
• Agent: incident-responder — triages incidents, queries ServiceNow, updates Azure resources
• Connections: ServiceNow REST API (external egress), Azure Blob Storage (logs, it-logs container), Azure OpenAI
• Managed identity with Contributor on entire resource group (overprivileged — should be scoped to specific resources)
• Owner: former employee (disabled Entra account)
• What SV0 should discover: Overprivileged path, external egress to ServiceNow, orphaned ownership, findings: orphaned_ownership, scope_drift
• Why this matters: The "before SecurityV0" horror story

Scenario F3: Agent with MCP Connection (black box)

• Foundry project: dev-tools
• Agent: code-reviewer — uses MCP server for code search and review
• Connections: MCP server at internal endpoint (https://mcp.internal.company.com/code-search), Azure OpenAI
• Managed identity with minimal RBAC
• What SV0 should discover: Agent exists, connection to MCP endpoint visible, MCP server is a black box (tools unknown). Finding: external egress to MCP endpoint, authority chain incomplete beyond MCP connection
• Why this matters: Demonstrates the honest MCP visibility gap and what we can/can't see

Scenario F4: Agent publish identity transition

• Foundry project: finance-reporting
• Agent: quarterly-report-gen — initially unpublished (shared project identity), then published (distinct Entra Agent ID)
• Connections: Azure SQL (financial data), Azure Blob Storage (report output)
• What SV0 should discover: Pre-publish scan shows shared identity. Post-publish scan shows new Entra Agent ID with separate RBAC. Authority delta: "Identity changed. New RBAC assignments. Verify: does the published identity have the same or broader permissions?"
• Why this matters: Validates the publish-time governance signal

AWS Bedrock Demo Lab (New, Aligns with AWS Strategy Phase 1)

Uses CDK v2 per the AWS Integration Strategy Section 8.

Scenario B1: Customer Support Agent (realistic Bedrock deployment)

• Bedrock Agent: customer-support-bot
• Service role with bedrock:InvokeModel (Claude 3.5 Sonnet)
• Knowledge Base: S3 bucket with product documentation, FAQs
• Action Group: Lambda function create-support-ticket → calls ServiceNow API
• Lambda execution role with secretsmanager:GetSecretValue (ServiceNow credentials) + dynamodb:PutItem (ticket log)
• What SV0 should discover (Tier 1): Agent exists, uses Lambda X and KB Y
• What SV0 should discover (Tier 2): Lambda role has AmazonDynamoDBFullAccess managed policy (overprivileged — should be scoped to specific table)
• What SV0 should discover (Tier 3): Full authority chain: Agent → Service Role → InvokeModel + Lambda → Lambda Role → Secrets Manager (ServiceNow creds) + DynamoDB (all tables!) + S3 (KB bucket). Finding: scope_drift on DynamoDB access.
• Why this matters: Validates tiered permission model. Shows what you lose at each tier.

Scenario B2: Multi-Agent with Supervisor/Collaborator

• Supervisor Agent: ops-coordinator — routes requests to specialized collaborators
• Collaborator Agent 1: log-analyzer — queries CloudWatch Logs
• Collaborator Agent 2: remediation-executor — invokes Lambda to restart services, update configs
• Supervisor role has bedrock:InvokeAgent on both collaborators
• Remediation executor's Lambda role has ec2:RebootInstances, ssm:SendCommand — significant blast radius
• What SV0 should discover: Supervisor → collaborator relationship (via bedrock:InvokeAgent permission). Each collaborator's independent authority chain. Stitched graph showing: ops-coordinator can indirectly trigger EC2 reboots and SSM commands through remediation-executor.
• Why this matters: Multi-agent graph stitching validation. Shows transitive authority that no competitor visualizes.

Scenario B3: Bedrock Agent with Cross-Account Access

• Agent in workload-account with KB in data-account
• Agent service role assumes cross-account role to read S3 in data account
• Data account contains PII (customer records)
• What SV0 should discover: Cross-account trust chain. Authority path crosses account boundary to reach PII data domain. Finding: reachable_sensitive_domain via cross-account trust.
• Why this matters: The highest-severity AWS pattern. Validates cross-account authority path materialization.

MCP Demo Scenarios (Within Cloud Platforms)

These demonstrate the MCP discovery surface that's visible through cloud APIs vs. what's opaque:

Scenario M1: MCP Server as Foundry Connection

• Foundry agent connects to an MCP server (our own test MCP server) via connection type MCP
• MCP server provides 3 tools: search_docs, update_record, export_csv
• SV0 sees through Foundry API: Connection to MCP endpoint, auth type
• SV0 does NOT see: Tool names, tool data domains, tool egress targets
• Gap demonstration: Compare what Foundry scanner discovers vs. what submitting the mcp.json reveals. Quantify the visibility delta.

Scenario M2: MCP Server as Bedrock Action Group Backend

• Bedrock action group Lambda proxies requests to an MCP server
• MCP server has tools that access a database and an external API
• SV0 sees through Bedrock/IAM APIs: Lambda exists, Lambda role permissions, network egress configuration
• SV0 does NOT see: That the Lambda talks to an MCP server, what MCP tools exist
• Gap demonstration: The Lambda's IAM permissions are the authority boundary. Even without MCP tool visibility, IAM-level discovery shows what the Lambda CAN access.

Cross-System Authority Path Scenarios (The Differentiator)

These are the most important demo scenarios. Cross-system authority paths are what no competitor can trace. Wiz sees within a cloud. Permiso sees identities. SV0 traces the full path across system boundaries.

Scenario X1: Foundry Agent → MCP Server → ServiceNow PII Access

This is the flagship scenario. It combines all three elements: a Foundry AI agent, an MCP server as the tool bridge, and ServiceNow as the PII data source. It requires the azure-foundry connector, the entra-servicenow connector, and exercises the MCP visibility surface.

The realistic enterprise pattern: A Foundry agent doesn't call ServiceNow directly. The development team builds an MCP server that wraps ServiceNow HR tools (search_employees, get_employee_details, update_employee_record). The Foundry agent connects to the MCP server. The MCP server authenticates to ServiceNow using an Entra service principal registered as an OAuth app.

Foundry Agent "hr-assistant" (azure-foundry connector discovers)
  → Connection: Azure OpenAI (model access)
  → Connection: MCP Server at https://hr-mcp.internal.company.com (type: MCP)
    
MCP Server (runs as Azure Function, has managed identity)
  → Managed Identity → Entra Service Principal (sp-hr-mcp, client_id: abc-123)
  → Tools: search_employees, get_employee_details, update_employee_record
  → Each tool calls ServiceNow REST API under the SP's OAuth credentials

Same Service Principal (entra-servicenow connector discovers)
  → ServiceNow OAuth App (client_id: abc-123 — CORRELATED edge)
    → ServiceNow REST Message → HR API endpoint
      → Business Rule on hr_employee table
        → GlideRecord queries: employee name, SSN, salary (PII)

Demo lab setup:

Component	What to Build	Technology
Foundry project	hr-automation with agent hr-assistant	Existing Terraform + setup_foundry_env.py
MCP server	Azure Function running an MCP server with 3 HR tools	Python, mcp SDK, Azure Functions
MCP server identity	Managed identity → SP sp-hr-mcp with client_id	Terraform (Entra app registration)
ServiceNow OAuth app	Register same SP client_id as OAuth provider	ServiceNow admin config
ServiceNow HR data	hr_employee table with test PII records (name, SSN, salary)	ServiceNow dev instance (existing)
ServiceNow automations	Business Rules + REST Messages that the OAuth app triggers	ServiceNow config
Foundry → MCP connection	Agent connection type MCP pointing to the Function endpoint	Foundry project config

What SV0 discovers from azure-foundry connector:

• Foundry agent hr-assistant exists in project hr-automation
• Connection to Azure OpenAI (model access — low risk)
• Connection to MCP endpoint https://hr-mcp.internal.company.com (type: MCP, auth: ManagedIdentity)
• The MCP server itself is an Azure Function with managed identity → SP sp-hr-mcp
• ARM RBAC: SP has roles on the Function App's resource group
• What the connector does NOT see: The MCP server's tools (search_employees, etc.) — the Foundry API exposes the connection but not the tool list

What SV0 discovers from entra-servicenow connector:

• SP sp-hr-mcp (same client_id: abc-123) → ServiceNow OAuth app
• OAuth app → REST Messages to HR API endpoint
• Execution chains: OAuth app → Business Rules → GlideRecord on hr_employee
• Data domains touched: hr (from table name hr_employee)
• PII fields accessed: employee.ssn, employee.salary, employee.home_address
• Execution evidence: sign-in logs for the SP, flow execution records in ServiceNow

What SV0 discovers when BOTH connectors contribute to the same graph:

• Cross-system authority path: Foundry Agent → MCP connection → SP sp-hr-mcp → ServiceNow OAuth → HR API → PII data
• The CORRELATED edge links the Azure SP to the ServiceNow OAuth app via matching client_id
• The full path spans: Azure AI Foundry → MCP Server → Entra ID → ServiceNow → HR PII
• The MCP server is in the path but partially transparent — we know its identity and what that identity can reach, even though we can't see its tool definitions through the Foundry API

Findings SV0 should surface:

• reachable_sensitive_domain: AI agent can reach HR PII data (SSN, salary) via cross-system path through MCP server
• external_egress: Foundry agent reaches ServiceNow (external to Azure) via MCP bridge
• scope_drift: SP permissions in ServiceNow may exceed what the MCP tools actually need (e.g., SP has write access to hr_employee but the agent supposedly only searches)
• Ownership: Is the SP owner still employed? (entra-servicenow connector checks disabled accounts)
• MCP visibility caveat: "Authority chain passes through MCP server. Tool-level authority inferred from identity permissions, not from tool definitions."

Why this is the demo:

1. Cross-system path — Azure → MCP → ServiceNow → PII. No single system shows this. Azure sees "agent connects to MCP endpoint." ServiceNow sees "OAuth app queries HR tables." Only SV0 traces the full chain.
2. MCP in the real world — This is how enterprises actually use MCP: as a tool bridge between an AI platform and backend systems. The MCP server wraps ServiceNow APIs into tools the agent can call.
3. Honest MCP visibility — We show what we CAN see (the identity chain through the MCP server) and what we CAN'T (the specific MCP tools). The identity chain is enough to surface the PII finding.
4. The CISO story — "Your HR assistant AI agent can read employee SSNs. The path goes through an MCP server that your dev team deployed, using a service principal that also has write access to ServiceNow HR records. Nobody approved this full path."

Scenario X2: Foundry Agent → Logic App → ServiceNow Change Management

Foundry Agent (dev-ops assistant)
  → Connection: Logic App HTTP trigger (SAS auth)
    → Logic App workflow
      → ServiceNow API: creates Change Requests
      → ServiceNow API: updates CMDB
      → ServiceNow API: closes Incidents

• Agent assists developers with incident response — can auto-create change requests
• Connection to Logic App uses SAS token (not managed identity RBAC)
• Logic App has ServiceNow API connector with service account credentials
• ServiceNow service account has permissions to create/modify Change Requests, Incidents, CMDB records

Cross-system path: Foundry Agent → Logic App (SAS) → ServiceNow (service account) → Change Management + CMDB (data mutation) Key finding: The AI agent can indirectly modify production change management records — a significant governance concern. The connection is credential-based (SAS), not role-based, so the RBAC chain has a gap.

This scenario exercises the cross-connector endpoint URI correlation from Phase B/E of the correlation research — the Logic App's callback URL must match across connectors.

Scenario X3: Bedrock Agent → Lambda → External SaaS (Salesforce/HubSpot) + ServiceNow

Bedrock Agent (customer-ops)
  → Action Group Lambda (process-customer-request)
    → Secrets Manager (Salesforce API key)
      → Salesforce REST API (customer records — PII)
    → Secrets Manager (ServiceNow credentials)
      → ServiceNow REST API (create incident)

• Agent handles customer operations — looks up customer data, creates support tickets
• Lambda function has execution role with secretsmanager:GetSecretValue for multiple secrets
• One secret is Salesforce API key (external SaaS with customer PII)
• Another secret is ServiceNow credentials (internal ITSM)

Cross-system path: Bedrock Agent → Lambda → Salesforce (customer PII, external egress) + ServiceNow (incident management) Key findings:

• external_egress: Lambda reaches Salesforce (external SaaS)
• reachable_sensitive_domain: customer PII accessible via Salesforce API
• credential_sprawl: Single Lambda has credentials for multiple external systems
• The blast radius of this one Lambda spans two external systems with PII access

Scenario X4: Multi-Platform Agent Ecosystem (The "Enterprise Reality" Demo)

The most complex scenario — represents what a mature enterprise looks like:

Azure Foundry Agent (IT-ops-coordinator)
  → Connection: Azure OpenAI (model access)
  → Connection: MCP server (internal tooling — black box)
  → Managed Identity → SP: sp-it-ops
    → ServiceNow OAuth (same SP, CORRELATED)
      → ServiceNow Flow Designer: auto-remediation workflow
        → REST Message → AWS API Gateway
          → Lambda → EC2 reboot, SSM command execution

Meanwhile on AWS:
Bedrock Agent (security-reviewer)
  → Knowledge Base: S3 (compliance docs)
  → Action Group Lambda
    → Same ServiceNow instance (different credentials)
      → Incident creation, CMDB updates

This scenario shows:

• Two AI agents on different cloud platforms
• Both reaching the same ServiceNow instance (different identity paths)
• One path continuing from ServiceNow into AWS (ServiceNow automation triggering AWS actions)
• An MCP server as a black box in the middle
• Cross-cloud authority: Azure → ServiceNow → AWS

Why this matters for the demo: It demonstrates that the problem is not "one agent is overprivileged" but "the combined authority surface of multiple agents, across multiple platforms, creates paths that no one person approved as a whole."

Cross-System Demo Lab Requirements

Requirement	Status	Notes
Both connectors scanning same tenant	Existing — both connectors submit to same platform	Graph stitching happens via shared identity (same client_id)
Entra-ServiceNow connector with HR data	Existing demo data	Business Rules on hr_employee table
Azure-Foundry connector with agent using same SP	Need to configure	Agent's managed identity must use SP already known to ServiceNow connector
Cross-connector entity correlation (Phase A–E)	Designed, partially implemented	CORRELATED edge via client_id matching exists in entra-servicenow connector; platform-level correlation (Phase C) not yet built
Logic App → ServiceNow endpoint URI matching	Designed (Phase B)	Requires endpoint URI normalization across connectors
Authority path spanning both connector graphs	Requires Phase E (materializer extension)	Materializer must follow CORRELATED and CONNECTS_TO edges across connector boundaries

Critical dependency: Cross-system scenarios X1–X4 depend on the cross-connector entity correlation work (Phases A–E from correlation research). Without Phase C (platform correlator) and Phase E (path bridging), the connectors produce separate graphs that don't link. The CORRELATED edge exists within the entra-servicenow connector, but the platform doesn't yet stitch it with the azure-foundry connector's graph.

This is the highest-priority platform work: it unlocks the differentiator.

Validation Criteria

For each scenario, we validate:

Criterion	How to Measure
Discovery completeness	Does the connector find all entities? Compare discovered graph vs. known infrastructure.
Authority chain accuracy	Does the materialized path match the actual permission chain? Manually verify IAM → resource access.
Finding correctness	Do evaluator rules fire correctly? Verify orphaned ownership, scope drift, egress classification.
Diff accuracy	Deploy a new agent. Does the next scan correctly show the delta?
Tiered degradation	Run scans at Tier 1, Tier 2, Tier 3 permissions. Document what's lost at each tier.
Scan latency	Measure time from agent deployment to SV0 detection (scheduled vs. event-triggered).
MCP visibility gap	For MCP scenarios, quantify: what % of the authority chain is visible through APIs vs. requires config submission?
Cross-system path completeness	For X1–X4: does the materialized authority path span both connectors? Is the CORRELATED edge correctly linking identities? Does the full chain show in the UI?
Cross-system finding accuracy	Does reachable_sensitive_domain fire when the sensitive data is in a different system than the agent?

---

Supported Platforms: Discovery Completeness (Honest)

Platform	Discovery Method	Code Access?	What We See	What We Don't See
Azure Foundry	Existing connector	No	Agents, connections, identities, RBAC, execution evidence, owners	MCP tool details behind connections; agent instructions
AWS Bedrock	Planned connector	No	Agents, action groups, KBs, flows, IAM roles + policies (tiered)	Lambda source code; Token Vault downstream details
Google Vertex AI	Planned connector	No	Agents, service accounts, IAM bindings, data store refs	Tool implementation details
MCP via cloud platforms	Via Foundry/Bedrock connectors	No	Endpoint + auth type of MCP connection	MCP server tools, data domains, downstream systems
MCP standalone	Config submission required	Config file (not code)	Full authority projection from config	Runtime behavior
LangChain/CrewAI	Via deployment platform IAM	No	Runtime identity permissions	Inter-agent relationships, tool definitions

---

Phased Delivery

Phase	Scope	Validates
Phase 1	Authority path snapshots + path-level diff engine + assessment records	"Show what changed" — core capability
Phase 2	AWS Bedrock connector + demo lab scenarios B1–B3	Bedrock discovery works at each permission tier
Phase 3	Event-driven scan triggers + MCP config submission API	Near-real-time detection + MCP pre-deploy preview
Phase 4	CI/CD webhook enforcement integration	Actual deployment gate (GitHub DPR, Azure DevOps)
Phase 5	GCP connector + MCP gateway connector	Platform breadth

Demo lab should run in parallel with Phase 1–2. The lab validates that our API-only discovery actually works before we make claims to clients.

---

Known Limitations (From Adversarial Review)

Documented for transparency. These are not blockers but must be acknowledged in client conversations.

1. Path-level diff is the hardest build. Current diff-engine.ts and PostureSnapshotDoc operate on entities and posture metrics only. Authority path snapshots and path-level diffing require new data models and algorithms. This is the foundation — everything else depends on it.

2. No enforcement mechanism today. Assessment records are evidence, not gates. SV0 does not block deployments. The enforcement integration roadmap addresses this but requires CI/CD or gateway partnerships.

3. AWS IAM permissions are a trust barrier. Full authority chain analysis requires iam:GetRolePolicy (exposes policy documents). Many enterprises restrict this. The tiered model mitigates but doesn't eliminate this concern.

4. Standalone MCP is a discovery gap. For MCP servers not running within a cloud platform, API-only discovery finds nothing useful. Config submission or gateway integration is required.

5. Multi-agent graph stitching is unsolved. Supervisor → collaborator chains require independently scanning both agents and connecting the authority graphs. The platform does not do this today.

6. Scan latency vs. deployment speed. Without event-driven triggers, there's a window between deployment and detection. This must be documented as an SLA, not hidden.

7. Cross-connector entity correlation is the critical dependency. The cross-system authority paths (Foundry → Entra → ServiceNow) that differentiate SV0 require Phases A–E of the cross-connector correlation research. The CORRELATED edge via client_id exists within the entra-servicenow connector, but platform-level graph stitching (Phase C) and authority path bridging across connector boundaries (Phase E) are not built. This is the highest-priority platform work — it unlocks the differentiator.

---

Related Documents

• MCP & Agentic Deployment Approval Research — full research with competitive analysis, platform landscape, five approach evaluations
• Pre-Deployment Assurance Research — W2 approval workflow design (deferred, foundational)
• AWS Integration Strategy — AWS connector scope, demo lab CDK strategy, Bedrock agent discovery APIs
• AWS NHI Workload Identity Surface — complete API catalog for AWS identity discovery
• Access Paths — authority chain model (Workload → Identity → Destination → Domain)
• Processing Pipeline — existing scan pipeline that this feature extends
• Connectors — NormalizedGraph interface that all connectors implement