MCP & Agentic Deployment Approval: Graph Impact Preview

Date: 2026-04-07 Type: Strategic research — client-driven Trigger: Potential clients asking: "How can I approve the deployment of something new with MCP? How can I see what would change in the identity graph and access path graph?" Scope: Technical analysis of how SecurityV0 answers "what will change" before an agentic tool goes live

Executive Summary

Clients deploying agentic tools (MCP servers, Bedrock agents, Foundry agents, LangGraph chains) need to answer one question before approval: "What authority does this grant, and what changes in my security graph?"

Today, SecurityV0 can show the current authority graph and detect drift after deployment (W1). The gap is showing the predicted impact before deployment (W2). This research analyzes five technical approaches — from lightweight (scan-then-diff) to ambitious (what-if simulation) — and maps them against every major agentic platform.

Key finding: The most practical approach combines multi-environment scanning (scan a staging/preview environment, diff against production baseline) with connector-level manifest parsing (read MCP server configs, Bedrock agent definitions, Foundry connection specs before deployment). Full "what-if" graph simulation is technically possible but premature — the scan-and-diff approach delivers 80% of the value with 20% of the complexity.

1. The Client Question, Precisely Stated

When a client says "how can I approve something new with MCP," they are asking three sub-questions:

Sub-question	What they need to see	SV0 capability today
What authority does this new tool/agent grant?	Full authority chain: Agent → Identity → Destination → Data Domain	Exists for deployed workloads (W1). Does not exist for proposed workloads.
How does this change my current security posture?	Delta: new paths, expanded permissions, new egress, new sensitive-data reachability	Entity-level diff exists. Path-level diff does not. Global graph diff does not.
Is this safe to approve?	Evidence-graded authority posture with ownership state and governance conditions	W1 produces this for current state. W2 approval workflow is designed but not built.

The gap is not "can SV0 assess authority?" — it can. The gap is "can SV0 assess authority before the thing is deployed?"

2. The Agentic Deployment Landscape

Clients don't use one platform. They use many, often simultaneously. Each has a different deployment model, identity model, and tool/permission surface. SecurityV0 must handle them all.

2.1 Platforms and Their Identity Models

All three hyperscalers now have agent-specific identity types (as of early 2026). This is a new graph surface that existing CIEM tools do not yet model.

Platform	Deployment Unit	Identity Model	Tool/Permission Surface	How to Discover Pre-Deployment
MCP (Model Context Protocol)	MCP server (process or container)	Inherits host process identity (no native IAM); OAuth 2.1 for client→server auth	Tools declared in server manifest (`tools/list`); `.well-known/mcp-server` discovery (2026 roadmap)	Parse `mcp.json` / server config before deployment
AWS Bedrock Agents	Agent + Action Groups + Knowledge Bases	IAM service role per agent; Lambda execution roles for action groups	Action groups (Lambda), KB data sources (S3/OpenSearch), model access	Read agent definition + IAM policy from CloudFormation/CDK/Terraform before apply
AWS Bedrock AgentCore	Runtime + Workload Identity	Workload Identity (auto-provisioned per runtime) + Token Vault for downstream credentials	OAuth 2.0 client credentials + authorization code grants; VPC + PrivateLink isolation	Read AgentCore config + Token Vault bindings from CloudFormation
Azure AI Foundry	Project + Agents + Connections	Entra Agent ID (new identity type, purpose-built for AI agents); shared project identity for unpublished, distinct identity for published agents	Connections (OpenAI, Storage, MCP servers, A2A); 4-stage OAuth token exchange	Read project definition + connection configs from ARM/Bicep templates
Google Vertex AI Agent Builder	Agent + Tools + Data Stores	Service account per agent; Cloud API Registry for tool governance (Preview)	Tools (OpenAPI, data stores, MCP servers via registry); VPC Service Controls	Read agent config + IAM bindings from Terraform/gcloud
LangChain / LangGraph	Application code + tool definitions	Application-level (inherits deployment identity); no built-in governance	Tools are Python/TS functions with arbitrary access	Parse tool manifests or OpenAPI specs; inspect deployment IAM
CrewAI / AutoGen / DSPy	Agent definitions in code	Application-level; CrewAI integrates with NVIDIA NemoClaw for infrastructure-level policy	Tools defined in code with arbitrary access	Static analysis of tool definitions; inspect deployment IAM
OpenAI Assistants / GPTs	Assistant + Actions	API key or OAuth per action; `x-openai-isConsequential` forces user confirmation	Actions defined via OpenAPI schemas	Parse OpenAPI action schemas + credential configs

2.2 What "Deploying Something New" Actually Means

The client question maps to concrete deployment actions:

Action	What Changes in the Authority Graph	Severity
Add new MCP server	New workload node, new tool edges, new data-domain reachability via tools	High — new blast radius
Add tool to existing MCP server	New edges from existing workload to new resources/data domains	Medium — expanded blast radius
Deploy new Bedrock agent	New agent node + service role + action group Lambdas + KB data sources	High — full new authority chain
Add action group to Bedrock agent	New Lambda with own execution role, potentially new cross-account access	High — transitive authority hop
Add connection in Foundry project	New edge from project identity to external resource	Medium — depends on connection target
Update agent permissions/roles	Changed edges in authority graph, potentially new sensitive-data reachability	Medium to High
Remove tool/connection	Removed edges — reduced blast radius	Low (positive change)

3. Five Technical Approaches

3.1 Approach A: Scan-Then-Diff (Recommended First Step)

Concept: Deploy the change to a pre-production environment. SV0 scans that environment. Diff the resulting graph against the production baseline.

How it works:

What SV0 needs to build:

Component	Current State	Gap
Multi-environment tenant model	Single tenant per deployment	Need: environment-scoped tenants (prod, staging, preview) within one SV0 instance
Graph-level diff engine	Entity-level diff exists; path-level does not	Need: full graph diff — new/removed nodes, new/removed edges, new/removed authority paths
Baseline snapshots	Posture snapshots exist (metrics only)	Need: full graph snapshots as diff baseline
Scan trigger API	Designed, not implemented	Need: `POST /api/v1/syncs` with environment context
Cross-environment correlation	Not designed	Need: correlate staging entities to production entities (same logical workload, different IDs)

Strengths:

Uses real infrastructure — no speculation
Reuses existing scan pipeline
Graph diff is deterministic (no prediction)
Works for ANY platform (MCP, Bedrock, Foundry, custom)

Weaknesses:

Requires a staging environment (not all clients have one)
Cross-system staging is noisy (different object IDs — see Section 2.2 of pre-deployment assurance research)
Staging may not faithfully represent production (different IAM policies, different network rules)
Adds latency to deployment workflow (scan takes minutes)

When to use: Clients with mature staging environments; single-platform deployments (e.g., only Foundry, or only Bedrock) where staging/prod correlation is simpler.

3.2 Approach B: Manifest Parsing (Recommended — Build Alongside A)

Concept: Read the definition of the new agent/tool/MCP server before deployment. Construct a projected authority graph by combining the manifest with the current production graph.

How it works:

Platform-specific manifest sources:

Platform	Manifest Source	What SV0 Parses
MCP	`mcp.json`, server config, `tools/list` response	Server identity, declared tools, tool input schemas, resource URIs
Bedrock	CloudFormation template, CDK construct, Terraform `aws_bedrockagent_agent`	Agent role ARN, action group Lambda ARNs, KB data source ARNs, model access
Foundry	ARM template, Bicep, Terraform `azurerm_ai_foundry_project`	Project managed identity, connections (type, endpoint, auth), agent definitions
Vertex AI	Terraform `google_dialogflow_cx_agent`, gcloud config	Service account, tools (OpenAPI specs), data store references
LangChain/LangGraph	Tool definitions in code, `langgraph.json`	Tool function signatures, API endpoints called, credentials referenced
Kubernetes + MCP	Helm chart, K8s manifests	Service account, mounted secrets, network policies, MCP server sidecar configs

What SV0 needs to build:

Component	Current State	Gap
Manifest parsers per platform	Not designed	Need: parsers for MCP config, CloudFormation, ARM templates, Terraform
Projected graph construction	Not designed	Need: take manifest → produce NormalizedGraph nodes/edges → overlay on existing graph
Authority path projection	Materializer works on ingested data	Need: run materializer on projected graph to show predicted authority paths
Evaluator on projected state	Evaluator works on current state	Need: run evaluator against projected graph to surface predicted findings

Strengths:

No staging environment required — works from config files
Fast — no scan latency, just file parsing
Can integrate into CI/CD (parse IaC in PR review)
Shows intent, not just infrastructure state

Weaknesses:

Manifests may not capture all transitive authority (a Lambda's IAM role is separate from the Bedrock agent definition)
Different IaC formats per platform — large parser surface
Does not capture runtime behavior — only configured authority
Grade C evidence only (standing authority, no execution proof)

When to use: Pre-deployment review in CI/CD pipelines; clients who want fast feedback on proposed changes; complement to Approach A.

3.3 Approach C: What-If Graph Simulation

Concept: Allow users to describe hypothetical changes ("add an MCP server with these tools and this identity") and show the projected impact on the authority graph without any deployment.

How it works:

User: "What if I add an MCP server connected to the hr-bot service principal
       with tools: search_employees, update_records, export_to_csv?"

SV0: "Projected impact:
      • 1 new workload node (MCP server)
      • 3 new authority paths via hr-bot identity
      • Path to HR domain: search_employees → HR Database (Grade C)
      • Path to HR domain: update_records → HR Database (Grade C, WRITE)
      • Path to external egress: export_to_csv → External CSV endpoint (Grade C)
      • New findings:
        - WRITE access to sensitive domain via new MCP tool
        - External egress from sensitive-domain workload
      • Ownership: inherits hr-bot owner (valid) or needs new owner assignment"

What SV0 needs to build:

Component	Complexity	Description
Hypothetical node/edge injection	Medium	API to add temporary nodes/edges to graph without persisting
Graph snapshot fork	High	Copy current graph state, apply hypothetical changes, run analysis
Authority path re-materialization	High	Re-run materializer on modified graph
Evaluator on hypothetical state	Medium	Run evaluator rules against modified graph
UI for "what-if" queries	High	Form or natural language interface for describing hypothetical changes

Strengths:

Most powerful user experience — "what would happen if..."
No staging environment needed
No deployment needed
Instant feedback

Weaknesses:

Highest implementation complexity
Hypothetical graphs may not match reality (missing transitive permissions, network constraints)
Risk of false confidence — "SV0 said it was safe" based on incomplete simulation
Graph fork + re-materialization is computationally expensive

When to use: Future capability (W3+). Most valuable after the graph model is mature and clients trust the current-state analysis.

3.4 Approach D: Multi-Environment Comparison Dashboard

Concept: SV0 scans multiple environments (dev, staging, production) continuously. Provide a dashboard showing graph differences between environments.

How it works:

What SV0 needs to build:

Component	Current State	Gap
Multi-environment tenant model	Single tenant	Need: environment-as-first-class-concept within a tenant
Cross-environment entity correlation	Not designed	Need: match logical entities across environments (e.g., same agent, different object IDs)
Environment comparison API	Entity diff exists	Need: graph-level diff across environments
Environment comparison UI	Not designed	Need: side-by-side or overlay view

Strengths:

Continuous visibility — not just at deployment time
Shows drift between environments
Natural upgrade path from single-environment scanning

Weaknesses:

Requires client to have multiple environments with SV0 connectors
Cross-environment correlation is hard (different IDs, different configs)
Expensive — doubles or triples scan volume
Environment differences may be noisy (dev experiments, test data)

When to use: Clients with mature multi-environment setups; enterprise customers with formal promotion pipelines.

3.5 Approach E: MCP-Native Governance Layer

Concept: Build an MCP-aware governance layer that intercepts MCP server registration and tool discovery, analyzing the security implications before the server becomes available to agents.

How it works:

What this requires:

Component	Description
MCP proxy / gateway	Sits between agent hosts and MCP servers; intercepts `tools/list`
Tool-to-authority mapper	Maps MCP tool definitions to authority graph concepts (data domains, egress)
Real-time evaluation	Run evaluator on tool definitions as they're discovered
Policy enforcement point	Allow/block/warn based on evaluation results

Strengths:

Native to MCP — understands the protocol
Real-time — catches issues at connection time, not scan time
Could become the "MCP firewall" — unique market position

Weaknesses:

MCP-specific — doesn't cover Bedrock, Foundry, etc.
Requires deployment in the agent's network path
MCP spec is evolving rapidly — maintenance burden
Enforcement is hard to get right (false positives block legitimate tools)

When to use: Future differentiation play. Build only after core scan-and-diff is proven.

4. What We Already Have (Capability Inventory)

4.1 Platform Capabilities Relevant to Deployment Approval

Capability	Status	How It Helps
NormalizedGraph ingestion	Production	Any connector can submit nodes + edges; projected graphs could use same format
Authority path materialization	Production	Workload → Identity → Destination → Domain chains computed automatically
Entity-level diff (`GET /entities/:id/diff`)	Production	Compare entity versions between timestamps
Entity versioning (EntityVersionDoc)	Production	Point-in-time entity state with `valid_at` / `expired_at`
Posture snapshots (PostureSnapshotDoc)	Production	Captures path counts, execution metrics, ownership state per sync
Posture delta	Production	Computes new/removed paths, ownership changes between snapshots
Evaluator (15 rules)	Production	Entity + path-level finding generation — deterministic, evidence-graded
Evidence packs (SHA256 integrity)	Production	Tamper-detecting evidence bundles
Baseline management (BaselineMetadataDoc)	Production	Stores baseline entity state for deletion detection
Graph traversal API (`GET /graph/subgraph`)	Production	Neighborhood and execution-flow traversal with depth control
Batch entity fetch	Production	Fetch up to 100 entities at once
Risk clustering	Production	8 compound risk conditions combining multiple finding types

4.2 Connector Capabilities Relevant to Deployment Approval

Connector	What It Discovers	Relevance to Pre-Deployment
azure-foundry	Foundry projects, agents, connections, managed identities, ARM RBAC, execution evidence	Already models Foundry agent authority chains. Could parse ARM templates for projected state.
entra-servicenow	Service principals, OAuth apps, automations, execution chains	Models SaaS automation authority. Could parse ServiceNow update sets for projected changes.
AWS connector (planned)	Bedrock agents, Lambda, Step Functions, IAM roles, cross-account trust	Will model AWS agentic authority. Could parse CloudFormation/CDK for projected state.

4.3 What's Missing

Gap	Priority	Complexity	Which Approach
Path-level diff engine	P0	Medium	All approaches need this
Full graph snapshot (not just posture metrics)	P0	Medium	A, C, D
Multi-environment tenant model	P1	High	A, D
Manifest parsers (MCP config, CloudFormation, ARM, Terraform)	P1	Medium per parser	B
Projected graph construction	P1	Medium	B, C
Cross-environment entity correlation	P2	High	A, D
Hypothetical graph injection API	P2	High	C
Graph fork + re-materialization	P3	Very High	C
MCP protocol proxy	P3	High	E

5. MCP-Specific Deep Dive

MCP deserves special attention because it's the protocol clients are specifically asking about and it's the emerging standard for AI tool connectivity.

5.1 MCP Security Model Today

MCP (Model Context Protocol) as of 2026 has grown from ~100K downloads (Nov 2024) to 8M+ (April 2025), with backing from Anthropic, OpenAI, Google, Microsoft, and AWS. It moved to Linux Foundation governance with formal Working Groups.

No native identity model. An MCP server runs as a process and inherits the identity of its host (the service account, IAM role, or user credential running the process). There is no "MCP identity" — the identity is whatever the deployment platform provides.
OAuth 2.1 authorization (spec addition, 2025-2026). MCP servers can require OAuth 2.1 tokens from clients (RFC 9728 Protected Resource Metadata). This means the client (AI agent) authenticates to the server (tool provider), but it doesn't govern what the server can do downstream.
Tool declarations (tools/list). Every MCP server declares its tools with names, descriptions, and input schemas. This is the manifest SV0 can parse. The declarations don't include authority metadata (what data domains the tool accesses, what systems it calls).
No tool-level permissions. MCP has no native concept of "this tool can access Finance data" or "this tool has external egress." The protocol declares capabilities but not authority scope.
2026 roadmap: Stateless server scaling (current stateful sessions fight load balancers), .well-known/mcp-server discovery endpoints for registry/crawler discovery, an IETF draft (draft-serra-mcp-discovery-uri) proposing mcp:// URI scheme.
Critical vulnerabilities — quantified risk:
- Tool poisoning: Malicious instructions embedded in tool descriptions, invisible to users but visible to AI models. 7.2% of 1,899 open-source MCP servers contain general vulnerabilities; 5.5% have MCP-specific tool poisoning.
- Rug-pull attacks: Tool descriptions/behavior silently altered after user approval, turning benign tools malicious.
- CVE-2025-6514 (mcp-remote, CVSS 9.6): Command injection via untrusted MCP servers. 500K+ downloads affected.
- Aggregate risk: Deploying 10 MCP plugins creates a 92% probability of exploitation. Even a single plugin has a 9% exploit probability.
- 43% of tested MCP implementations contain command injection flaws; 30% permit unrestricted URL fetching.
MCP Gateways (emerging enterprise answer): Intermediary proxies between agents and MCP servers providing centralized auth, audit trails, RBAC, and rate limiting. Key players: MintMCP Gateway, Lunar.dev MCPX, Lasso MCP Gateway, and the open-source agentic-community/mcp-gateway-registry with Keycloak/Entra integration.

5.2 What SecurityV0 Can Add for MCP

SV0 can fill MCP's governance gap by providing the authority-level analysis that MCP doesn't have natively:

MCP Gap	What SV0 Provides
No identity model	Map MCP server → deployment identity → IAM roles → data access
No authority scope on tools	Classify tools by data domain reachability and egress type via connector analysis
No pre-deployment review	Parse MCP config → project authority graph → evaluate before deploy
No post-deployment verification	Continuous scanning detects if MCP server authority drifts from approved baseline
No ownership governance	Track who owns each MCP server workload; surface orphaned or unowned servers

5.3 MCP Config as Connector Input

MCP servers are typically configured via a JSON file (mcp.json, claude_desktop_config.json, or platform-specific config). A new connector type could parse these configs:

{
  "mcpServers": {
    "hr-document-search": {
      "command": "node",
      "args": ["./servers/hr-search/index.js"],
      "env": {
        "DATABASE_URL": "postgres://hr-readonly@db.internal:5432/hr",
        "AZURE_CLIENT_ID": "sp-hr-bot-prod"
      }
    },
    "finance-reports": {
      "url": "https://mcp.internal.company.com/finance",
      "headers": {
        "Authorization": "Bearer ${FINANCE_API_TOKEN}"
      }
    }
  }
}

What SV0 extracts:

Config Element	SV0 Graph Node/Edge
Server name	Workload node (`hr-document-search`)
`env.AZURE_CLIENT_ID`	Edge: workload AUTHENTICATES_AS → service principal
`env.DATABASE_URL`	Edge: workload CALLS → resource (HR database); data domain: HR
`url` (remote server)	Edge: workload CALLS → external endpoint; egress classification
`headers.Authorization`	Credential node; edge: workload USES → credential

Combined with the tools/list response (or static tool definitions in the codebase), SV0 can construct the full authority chain before the server is deployed.

6. Platform-Specific Approaches

6.1 AWS Bedrock

Current state: AWS connector (planned, Phase 1 per AWS strategy) will discover Bedrock agents, KBs, flows, action groups.

Pre-deployment approach:

CloudFormation/CDK parsing: Read AWS::Bedrock::Agent, AWS::Bedrock::KnowledgeBase, AWS::Lambda::Function resources from templates. Extract IAM role ARNs, action group definitions, KB data source configs.
Terraform parsing: Read aws_bedrockagent_agent, aws_bedrockagent_knowledge_base, aws_lambda_function resources. Extract the same authority metadata.
CloudFormation changeset API: AWS provides CreateChangeSet which shows exactly what would change without deploying. SV0 could call this API and parse the projected changes.

Authority chain for a Bedrock agent:

Bedrock Agent (workload)
  → Agent Service Role (identity)
    → InvokeModel on foundation model (permission)
    → InvokeAgent on collaborator agents (permission)
    → Action Group Lambda (workload)
      → Lambda Execution Role (identity)
        → S3 / DynamoDB / Secrets Manager / External API (resources)
    → Knowledge Base (workload)
      → KB Service Role (identity)
        → S3 / OpenSearch / Aurora (data sources)

Bedrock AgentCore (GA Oct 2025): Introduces Workload Identities — auto-provisioned per runtime, representing the agent's digital identity within AWS. Features a Token Vault storing OAuth 2.0 tokens bound to (workload identity + user ID) pairs, with built-in credential providers for Google, GitHub, Slack, Salesforce, Atlassian. Supports dual authentication (inbound JWT/SigV4, outbound via Token Vault). This is a new identity surface SV0 should model.

Key finding: Bedrock's multi-layer identity model (agent role + Lambda role + KB role + AgentCore Workload Identity + Token Vault credentials) creates transitive authority chains that are invisible without graph analysis. This is exactly SV0's strength.

6.2 Azure AI Foundry

Current state: azure-foundry connector already discovers projects, agents, connections, managed identities, ARM RBAC.

Critical new finding — Entra Agent ID: Azure has introduced a purpose-built identity type for AI agents (distinct from user/managed identity/workload identity). Unpublished agents share a project identity; published agents get a distinct Entra Agent ID with separate RBAC. This means the blast radius changes silently at publish time — a governance gap SV0 can surface.

4-stage OAuth token exchange: Blueprint auth → agent identity token → scoped downstream token → authenticated tool call. MCP servers use auth type AgenticIdentityToken; A2A endpoints use AgenticIdentity.

Pre-deployment approach:

ARM template parsing: Read Microsoft.MachineLearningServices/workspaces and connection resources from Bicep/ARM templates.
Foundry agent definition parsing: Read agent configs (model, tools, instructions) from deployment manifests.
Connection manifest: Foundry connections define endpoint + auth type. Parse these to project authority edges before deployment.
Publish-time delta detection: Flag when an agent transitions from shared project identity to distinct Entra Agent ID — this changes the authority graph and needs explicit review.

Key finding: SV0 already models Foundry authority chains in production. The gap is reading the proposed configuration (ARM template, Bicep, agent definition file) rather than the deployed configuration (ARM API, Foundry API). The Entra Agent ID surface is new and not yet covered by any CIEM tool.

6.3 Google Vertex AI Agent Builder

Pre-deployment approach:

Terraform parsing: Read google_dialogflow_cx_agent, google_vertex_ai_agent resources.
Service account analysis: Map agent → service account → IAM bindings → accessible resources.
Tool definition parsing: OpenAPI specs for tools define which external APIs the agent can call.

Authority chain:

Vertex AI Agent (workload)
  → Service Account (identity)
    → IAM Bindings (permissions)
      → BigQuery / Cloud Storage / Cloud SQL (resources)
    → Tools (capabilities)
      → OpenAPI endpoints (external resources)
    → Data Stores (data sources)
      → Cloud Storage / BigQuery (backing data)

6.4 LangChain / LangGraph / CrewAI

Pre-deployment approach:

These frameworks don't have a centralized management plane. The authority comes from:

Deployment identity: The IAM role / service account / credential the application runs under. SV0 discovers this through the platform connector (AWS, Azure, GCP).
Tool definitions in code: Static analysis of tool function signatures, API calls, credential references. This is harder — requires code analysis, not just config parsing.
LangGraph deployment manifest: langgraph.json declares entry points and dependencies. Some authority metadata can be extracted.

Key finding: Framework-based agents are harder to analyze pre-deployment because authority is defined in application code, not in platform configuration. SV0's primary approach here is Approach A (scan staging after deployment) rather than Approach B (manifest parsing).

7. Recommended Strategy

Phase 1: Foundation (Prerequisite for All Approaches)

Build these regardless of which approach is prioritized:

Path-level diff engine — Extend the existing entity diff to compare authority paths between two states (timestamps, environments, or real vs. projected).
Full graph snapshot — Extend BaselineMetadataDoc to capture the complete authority graph (all nodes, edges, and materialized paths) at a point in time, not just posture metrics.
Approval workflow records — Store approval decisions with the authority posture snapshot, approver identity, scoped workloads, and acknowledged findings. (This is the W2 2a/2b build from the pre-deployment assurance research.)

Phase 2: Scan-Then-Diff (Approach A) + Manifest Parsing (Approach B)

Build in parallel — they complement each other:

Approach A (scan-then-diff):

Add environment-scoped tenants (prod, staging, preview) within a single SV0 instance
Implement POST /api/v1/syncs scan trigger with environment context
Build graph-level diff between environments
Start with single-platform environments (e.g., diff Foundry staging vs Foundry prod) where cross-environment correlation is straightforward

Approach B (manifest parsing):

Build MCP config parser (highest client demand)
Build CloudFormation/Terraform parser for Bedrock (aligns with AWS connector Phase 1)
Build ARM/Bicep parser for Foundry (extends existing azure-foundry connector)
Each parser outputs NormalizedGraph format → feeds directly into existing ingestion pipeline
Run evaluator on projected graph → surface predicted findings

Phase 3: Multi-Environment Dashboard (Approach D)

Continuous multi-environment scanning
Cross-environment entity correlation (match logical entities across environments)
Side-by-side graph comparison UI
Drift detection between environments (staging is ahead of prod, dev has unapproved changes)

Phase 4: What-If Simulation (Approach C) + MCP Governance (Approach E)

Hypothetical graph injection API
Graph fork + re-materialization
MCP protocol proxy / gateway
Natural language "what-if" queries

8. Competitive Positioning

8.1 No One Else Does This

As of April 2026, the market is converging on runtime enforcement (intercept and block at execution time) and post-deployment monitoring. No vendor provides pre-deployment authority graph impact analysis:

Vendor	What They Offer	What They Don't
Microsoft Agent Governance Toolkit (OSS, Apr 2026)	Runtime policy engine (AgentOS), DID-based identity (AgentMesh), compliance mapping (EU AI Act, HIPAA, SOC2), Ed25519 plugin signing. Integrates with LangChain, CrewAI, Google ADK.	Runtime enforcement only — no pre-deployment graph impact analysis; no authority path visualization
Cisco Zero Trust for Agents (RSA 2026)	Agent discovery in Identity Intelligence, agent IAM in Duo, MCP gateway in Secure Access SSE, DefenseClaw framework, AI Defense Explorer for pre-deployment red teaming	Red teaming ≠ authority graph analysis; no cross-system authority path mapping; no evidence grading
Wiz AI-SPM	AI workload discovery, AI-BOM, attack path analysis, blast radius	No deployment-triggered impact preview; no authority path diff; no MCP awareness; no cross-SaaS chains
Permiso	Identity graph (human + NHI + AI), behavioral analytics	Detection/response focus; no pre-deployment analysis; no evidence grading
Google Cloud API Registry	Administrator-curated tool approval for Vertex AI agents (Preview)	Google-only; no cross-system authority analysis; no graph diffing
Oasis Security	NHI lifecycle, dependency mapping, "Agentic Access Management"	Posture management, not deployment-triggered; no evidence packs
Lasso Security	AI governance platform, MCP gateway with audit logging	Policy enforcement focus; no deterministic authority graph; no cross-system paths
OPA / Conftest	Policy-as-code evaluation	No identity graph; needs a data source (SV0 could feed it)

8.2 The Governance Gap — Quantified

CSA Research Note (April 2026) documents the gap SV0 can fill:

92% of large-enterprise security leaders lack visibility into AI agent identities
95% doubt their ability to detect or contain compromised agents
Only 38% monitor AI traffic end-to-end; only 17% track agent-to-agent interactions
Only 16% effectively govern AI access to core business systems
No enforceable agent-specific security controls exist today; first substantive NIST deliverables not expected before late 2026

Regulatory tailwind: EU AI Act high-risk obligations take effect August 2026. Colorado AI Act enforceable June 2026. Both create demand for pre-deployment evidence of authority posture — exactly what SV0 produces.

8.3 SecurityV0's Unique Position

SV0 is the only platform that can say:

"Before you deploy this MCP server / Bedrock agent / Foundry agent, here is exactly what authority it would gain, which sensitive data domains it could reach, what egress boundaries it would cross, and how this compares to your currently approved posture — with evidence grades on every claim."

This is the W2 thesis realized for the agentic deployment use case.

9. Client Conversation Framework

When a client asks "How can I approve deploying something new with MCP?", the answer should be framed progressively:

Today (W1)

"SecurityV0 shows you the full authority graph for your deployed agentic tools — every identity, every data domain they can reach, every egress boundary, with evidence grades (confirmed execution, inferred, or standing authority). After you deploy, we detect any authority drift from your baseline. You see exactly what changed."

Near-Term (W2 Phase 1-2)

"Before you deploy, give us the MCP server config (or Bedrock agent definition, or Foundry project template). We'll project the authority graph — showing what new paths would be created, what sensitive domains the new tool would reach, and what findings would be generated. You approve with full visibility. After deployment, we verify reality matches what was projected."

Future (W2 Phase 3-4)

"We scan your staging and production environments continuously. Before promotion, you see a live graph diff — exactly what would change in production. You can also ask 'what-if' questions: 'What if I give this agent access to the finance database?' and see the projected impact instantly."

Next Action

Status: research-complete Decision needed from: CTO / CEO Options:

Adopt Phase 1 — Build path-level diff + full graph snapshots + approval workflow. This unlocks post-deployment verification (the W2 2a-2c build). GitHub Issue: create in sv0-platform.
Adopt Phase 1 + Phase 2 (MCP manifest parser) — In parallel with Phase 1, build MCP config parser as the first manifest-based connector. This gives the fastest answer to the specific client question about MCP. GitHub Issue: create in sv0-connectors.
Adopt Phase 1 + Phase 2 (scan-then-diff) — In parallel with Phase 1, build multi-environment tenant model. Requires more platform work but handles all platforms, not just MCP. GitHub Issue: create in sv0-platform.
Defer — Focus on W1 maturity (AWS connector, more evaluator rules, UX) before tackling pre-deployment. Revisit after Inetum onboarding.

Recommended: Option 2 — Phase 1 + MCP manifest parser. It directly answers the client question, builds on existing architecture, and creates a unique competitive differentiator. The MCP manifest parser is the smallest new-build that delivers the most client-visible value.

GitHub Issues: Not yet created — pending decision.

Appendix A: MCP Tool Authority Classification

When parsing MCP tool definitions, SV0 needs to classify each tool's authority implications. Proposed classification:

Tool Property	Authority Signal	Example
Tool name/description mentions "read", "search", "get"	Read-only access to data domain	`search_employees` → HR domain, read
Tool name/description mentions "write", "update", "create", "delete"	Write access to data domain	`update_records` → HR domain, write
Tool name/description mentions "send", "post", "email", "notify"	External egress	`send_notification` → external, write
Tool input schema references URLs or endpoints	Configurable egress target	`{ endpoint: string }` → dynamic egress
Tool input schema references file paths	File system access	`{ path: string }` → local data access
Tool input schema references credentials or tokens	Credential propagation	`{ api_key: string }` → credential exposure

This classification is structural (Grade C) — it infers authority from tool definitions, not observed execution. After deployment, execution evidence upgrades classifications to Grade B or A.

Appendix B: Projected NormalizedGraph Example

When SV0 parses an MCP server config and produces a projected NormalizedGraph:

{
  "syncId": "projected-abc123",
  "connectorId": "mcp_manifest",
  "tenantId": "customer-tenant",
  "transformedAt": "2026-04-07T10:00:00Z",
  "projectionSource": "manifest",
  "projectionContext": {
    "sourceFile": "mcp.json",
    "targetEnvironment": "production",
    "baselineSnapshotId": "snapshot-xyz789"
  },
  "nodes": [
    {
      "nodeId": "mcp:hr-document-search",
      "nodeType": "automation",
      "sourceSystem": "mcp_manifest",
      "sourceId": "hr-document-search",
      "status": "projected",
      "properties": {
        "mcp_server_name": "hr-document-search",
        "transport": "stdio",
        "tool_count": 3,
        "data_domains": ["hr"],
        "egress_categories": ["internal", "llm"],
        "projection_confidence": "structural"
      }
    },
    {
      "nodeId": "mcp:hr-document-search:tool:search_employees",
      "nodeType": "permission",
      "sourceSystem": "mcp_manifest",
      "sourceId": "search_employees",
      "status": "projected",
      "properties": {
        "tool_name": "search_employees",
        "access_type": "read",
        "data_domain": "hr",
        "description": "Search employee directory by name or department"
      }
    }
  ],
  "edges": [
    {
      "edgeType": "GRANTS",
      "sourceNodeId": "mcp:hr-document-search",
      "targetNodeId": "mcp:hr-document-search:tool:search_employees"
    },
    {
      "edgeType": "AUTHENTICATES_VIA",
      "sourceNodeId": "mcp:hr-document-search",
      "targetNodeId": "entra:sp-hr-bot-prod",
      "properties": {
        "correlation_method": "env_variable_match",
        "env_key": "AZURE_CLIENT_ID"
      }
    }
  ],
  "evidenceCompleteness": {
    "sources": {
      "execution_evidence": "unavailable_not_deployed",
      "sign_in_logs": "unavailable_not_deployed"
    }
  }
}

This projected graph feeds into the same ingestion pipeline as live connector output. The status: "projected" and projectionSource: "manifest" fields distinguish it from observed state. The evaluator runs the same rules but all findings are Grade C (structural, no execution evidence).

1. The Client Question, Precisely Stated​

2. The Agentic Deployment Landscape​

2.1 Platforms and Their Identity Models​

2.2 What "Deploying Something New" Actually Means​

3. Five Technical Approaches​

3.1 Approach A: Scan-Then-Diff (Recommended First Step)​

3.2 Approach B: Manifest Parsing (Recommended — Build Alongside A)​

3.3 Approach C: What-If Graph Simulation​

3.4 Approach D: Multi-Environment Comparison Dashboard​

3.5 Approach E: MCP-Native Governance Layer​

4. What We Already Have (Capability Inventory)​

4.1 Platform Capabilities Relevant to Deployment Approval​

4.2 Connector Capabilities Relevant to Deployment Approval​

4.3 What's Missing​

5. MCP-Specific Deep Dive​

5.1 MCP Security Model Today​

5.2 What SecurityV0 Can Add for MCP​

5.3 MCP Config as Connector Input​

6. Platform-Specific Approaches​

6.1 AWS Bedrock​

6.2 Azure AI Foundry​

6.3 Google Vertex AI Agent Builder​

6.4 LangChain / LangGraph / CrewAI​

7. Recommended Strategy​

Phase 1: Foundation (Prerequisite for All Approaches)​

Phase 2: Scan-Then-Diff (Approach A) + Manifest Parsing (Approach B)​

Phase 3: Multi-Environment Dashboard (Approach D)​

Phase 4: What-If Simulation (Approach C) + MCP Governance (Approach E)​

8. Competitive Positioning​

8.1 No One Else Does This​

8.2 The Governance Gap — Quantified​

8.3 SecurityV0's Unique Position​

9. Client Conversation Framework​

Today (W1)​

Near-Term (W2 Phase 1-2)​

Future (W2 Phase 3-4)​

Next Action​

Appendix A: MCP Tool Authority Classification​

Appendix B: Projected NormalizedGraph Example​

1. The Client Question, Precisely Stated

2. The Agentic Deployment Landscape

2.1 Platforms and Their Identity Models

2.2 What "Deploying Something New" Actually Means

3. Five Technical Approaches

3.1 Approach A: Scan-Then-Diff (Recommended First Step)

3.2 Approach B: Manifest Parsing (Recommended — Build Alongside A)

3.3 Approach C: What-If Graph Simulation

3.4 Approach D: Multi-Environment Comparison Dashboard

3.5 Approach E: MCP-Native Governance Layer

4. What We Already Have (Capability Inventory)

4.1 Platform Capabilities Relevant to Deployment Approval

4.2 Connector Capabilities Relevant to Deployment Approval

4.3 What's Missing

5. MCP-Specific Deep Dive

5.1 MCP Security Model Today

5.2 What SecurityV0 Can Add for MCP

5.3 MCP Config as Connector Input

6. Platform-Specific Approaches

6.1 AWS Bedrock

6.2 Azure AI Foundry

6.3 Google Vertex AI Agent Builder

6.4 LangChain / LangGraph / CrewAI

7. Recommended Strategy

Phase 1: Foundation (Prerequisite for All Approaches)

Phase 2: Scan-Then-Diff (Approach A) + Manifest Parsing (Approach B)

Phase 3: Multi-Environment Dashboard (Approach D)

Phase 4: What-If Simulation (Approach C) + MCP Governance (Approach E)

8. Competitive Positioning

8.1 No One Else Does This

8.2 The Governance Gap — Quantified

8.3 SecurityV0's Unique Position

9. Client Conversation Framework

Today (W1)

Near-Term (W2 Phase 1-2)

Future (W2 Phase 3-4)

Next Action

Appendix A: MCP Tool Authority Classification

Appendix B: Projected NormalizedGraph Example