Skip to main content

Pre-Deployment Assurance: "Is It Safe to Deploy This?"

Date: 2026-02-27 Type: Strategic research Review rounds: Initial research → Codex cross-review → Pessimist/Optimist dual review Scope: How SecurityV0 delivers authority impact analysis at deployment time

CEO Executive Summary

The problem: CISOs feel pressure to say yes to AI. They don't want to be the headline. They lack visibility into what agents are doing. If SecurityV0 disappeared tomorrow, they would lose the only canonical map of execution authority for AI systems.

The thesis: SecurityV0 becomes the system of record that CISOs use to approve or challenge AI deployments — providing the deterministic authority graph, execution lineage, and audit evidence that no other tool produces.

We double down on:

  • Deterministic authority graph — Workload → Identity → Destination → Domain, evidence-graded (A/B/C)
  • Execution lineage — prove what was exercised, not just what's configured
  • Ownership decay — surface who is accountable (or isn't) for every autonomous path
  • Approval workflows — evidence-backed approval records with authority posture snapshots
  • Evidence for audit — SHA256 integrity-checked, chained, walkable evidence packs

We do NOT drift into: risk scoring gimmicks, behavior detection arms races, or alerting-first positioning.

The trajectory: W1 builds the canonical authority map. W2 adds approval workflows and post-deployment verification. W3 runs it continuously. Each wedge strengthens the system of record.

1. The Core Question​

A CISO, CTO, or analyst needs to answer one question before every AI agent deployment:

"Is it safe to put this into production?"

Today, this question has no good answer. CISOs feel pressure to say yes — the business pushes AI into production fast, and nobody wants to be the team that blocked innovation. But they also don't want to be the headline when an uncontrolled agent reaches sensitive data. They lack visibility. They lack evidence. They approve blind.

SV0 can answer this question by answering three sub-questions:

  1. What authority does this deployment grant? — Map the full authority chain: Workload → Identity → Destination → Data Domain. Show every sensitive domain the agent can reach and every egress boundary it can cross.

  2. How does this compare to what was previously approved? — Compute the authority delta: new paths created, permissions expanded, new egress destinations. Deterministic diff, not a score.

  3. What is the evidence quality? — Grade every authority path: Grade A (confirmed execution from prior runs), Grade B (inferred activity), Grade C (standing authority, no execution proof). CISOs know exactly what they can prove and where evidence blind spots exist.

Important framing: W2 answers a different question than W1.

  • W1 asks (backward-looking): "What autonomous authority exists and what was exercised?" — execution-determined.
  • W2 asks (forward-looking): "What authority posture does this deployment create?" — authority-determined by design.

At deployment time for new workloads, there is no execution history. All paths are Grade C. This is honest and expected — the deployment hasn't run yet. SV0 surfaces the authority posture so the CISO can approve with full visibility. After deployment, as execution evidence accumulates (via W1/W3 continuous scanning), paths upgrade C → B → A.

2. Four Ideas Evaluated​

2.1 Evidence-Backed Approval Workflow + Post-Deployment Verification — Recommended​

Concept: Before deploying, the security team reviews SV0's current authority posture for the relevant workloads. SV0 provides the canonical authority graph, evidence grades, and ownership state. The human approves with full visibility. The approval is recorded with the current authority snapshot as baseline. After deployment, SV0's next scan detects authority changes and surfaces the delta.

Why this is the strongest approach:

  • Production-only scanning — SV0 scans the actual production environment. No cross-system staging correlation needed. Same object IDs, same SPs, same authority graph.
  • Approval workflow, not CI/CD gate — The CISO or analyst reviews evidence and approves in SV0. The approval record includes the authority snapshot, the approver, and the timestamp. This is audit evidence, not pipeline automation.
  • Post-deployment verification — After deployment, SV0's next scan detects what changed. New authority paths, expanded permissions, new egress — all surfaced as a delta from the approved baseline. If unexpected changes appear, SV0 generates findings.
  • Aligns with core product — This doubles down on what SV0 already does: deterministic authority graph, execution lineage, ownership decay, evidence for audit. It adds an approval layer and a baseline comparison — not a fundamentally new product.

The progressive model:

  1. Before deployment: CISO reviews current authority posture in SV0. Evidence grades show Grade A (confirmed), B (inferred), C (standing). Approves with baseline snapshot.
  2. After deployment: SV0 scans production. Detects authority delta. Surfaces new Grade C paths. "3 new paths reaching Finance-scoped data appeared since approval."
  3. Over time: Execution evidence accumulates. Paths upgrade C → B → A. The gap between approved authority and exercised authority is itself a governance signal.

2.2 Two-Phase Deployment Gate (Deploy → Scan → Promote) — Technically Viable, Practically Unlikely​

Concept: Deploy to staging, SV0 scans staging, approves/rejects before production promotion.

Architectural fit: GitHub Deployment Protection Rules fire before the deployment job runs, which means a two-phase staging→production promotion workflow is needed. The mechanism is well-documented (30-day timeout, async, Markdown reports).

The cross-system reality problem: SV0 scans across multiple systems (ServiceNow, Entra, Foundry). A staging ServiceNow instance connects to different Entra service principals than production. Object IDs are different. Role assignments are different. The authority graph in staging is fundamentally different from production — it is not a faithful preview of what production will look like after deployment.

This means:

  • Integration complexity doubles or triples (correlate staging IDs to production IDs across all systems)
  • The authority delta between staging and production baseline would be noisy with environment-specific differences, not deployment-specific changes
  • False positives from environment mismatch would undermine CISO trust

Verdict: Keep as a future option for single-system deployments (e.g., customer only deploys Foundry agents, no cross-system correlation needed). Not the primary approach. CI/CD integration details preserved in Appendix A for when the use case materializes.

2.3 AI Chat for Describing Future Changes — Defer​

Assessment: Does not align with SV0's design principles. Requires speculative reasoning (violates deterministic constraint). Overlaps with IaC scanning tools where SV0 has no differentiation.

Kernel of value: "What-if" delta queries against the authority graph have merit for W3. Defer, don't kill.

2.4 Staging vs Production Comparison — Not a Feature​

Assessment: Staging environments are not representative in cross-system integrations — different SPs, different object IDs, different role bindings. The comparison would be dominated by environment noise, not deployment signal. Multi-environment scanning may emerge as a byproduct of the scan-trigger API, but it should not be positioned as a feature.

3. Recommended Approach: Approval Workflow + Post-Deployment Verification​

3.1 How It Works​

3.2 What the Analyst Reviews Before Approval​

The approval is not a sign-off on the entire organization's authority graph. It is scoped to the workloads affected by the deployment.

Scope selection: The analyst selects the workloads relevant to the deployment — for example, "all Foundry agents in the HR-Automation project" or "the ServiceNow integration account svc-ticketing-prod." SV0 filters the authority graph to show only the paths originating from those workloads.

The review — what the analyst sees:

Review ItemWhat It ShowsWhy It Matters
Authority pathsEvery path from selected workloads: Workload → Identity → Destination → DomainThe blast radius — what sensitive domains can these workloads reach?
Evidence gradesGrade A (confirmed execution), B (inferred), C (standing/unconfirmed)How much is proven vs. how much is assumption? For new deployments, everything is Grade C — that's expected and honest.
Egress classificationLLM API, Cloud Storage, External HTTP, InternalWhere data can leave the organizational boundary
Ownership stateOwner assigned or orphanedCan someone be held accountable if this path is exercised?
Active findingsExisting security findings for these workloadsAre there known issues the analyst should acknowledge before approving?
Governance conditionsOrphaned credentials, long-lived tokensHygiene signals that affect the risk of the deployment

What "approve" means:

The analyst is recording: "I have reviewed the authority posture for these workloads as of this timestamp. I understand the evidence grades, the egress boundaries, and the active findings. I accept this posture as the approved baseline."

This is not a rubber stamp. The approval record captures:

  • Who approved — user identity (audit trail)
  • When — timestamp
  • What was in scope — the set of workloads reviewed
  • The authority posture at that moment — snapshot of all paths, evidence grades, findings, ownership state
  • Acknowledged findings — any existing findings the analyst accepted (e.g., "I see the 3 orphaned paths — accepted pending ownership assignment by March 15")

After approval, the baseline is locked. Every subsequent scan compares against this approved snapshot. The analyst doesn't need to re-review the entire organization — only the delta from the approved baseline surfaces for attention.

What the analyst does NOT need to do:

  • Review every entity in the tenant — only the scoped workloads
  • Understand the raw data model — SV0 presents authority paths in the Clarity UX (Overview → Exposure Brief → Path Detail)
  • Make a binary pass/fail decision — the analyst approves with notes, acknowledges findings, and sets the baseline. SV0 handles the ongoing comparison.

3.3 The Assurance Output​

SV0's deployment assurance output is not a pass/fail flag. It is evidence for the approval decision:

ComponentDescriptionCurrent State
Authority Posture SnapshotFull authority graph at approval time: all paths, evidence grades, ownership state, egress classification, active findingsNew component — snapshot + versioning
Approval RecordWho approved, when, what authority posture was in effect, what findings were acknowledgedNew component
Post-Deployment DeltaAuthority changes detected after deployment: new paths, expanded permissions, new egress, changed evidence gradesNew component — requires path-level delta
Evidence PackSHA256 integrity hash, immutable content, chained via previous_pack_id. Detects accidental tampering.Production — tamper detection, not non-repudiation (see Section 7)

3.4 What Makes This Different​

Most security tools produce alerts or pass/fail scores. SV0 produces evidence for a human decision:

  • The CISO sees the full authority graph before approving — every path, every evidence grade, every ownership gap
  • The approval is recorded with the authority snapshot — audit trail of what was known at decision time
  • After deployment, the delta tells the CISO if what actually happened matches what was approved
  • Evidence gaps are surfaced as findings — "47 paths have no execution evidence. These are your blind spots."

SV0 is not a policy enforcement engine. It is the canonical map of execution authority that CISOs use to make informed decisions and prove they did their due diligence.

3.5 Remediation: Returning to Secure Posture​

When post-deployment verification detects unexpected authority changes, the response is rarely "redeploy everything." SV0's authority delta provides targeted remediation guidance because each finding maps to a specific, identifiable authority path.

The delta tells you exactly what changed.

Each post-deployment finding includes the specific authority path that appeared or expanded. Remediation is surgical, not wholesale:

Delta TypeWhat ChangedTypical Remediation
New path to sensitive domainWorkload gained access to Finance data via a new role assignmentRevoke the specific role assignment (e.g., remove Data Reader from svc-agent-prod on the Finance storage account)
New egress boundaryAgent can now reach external HTTP endpoints it couldn't beforeRemove the specific outbound connection or API credential
Expanded permissionsExisting identity gained additional roles beyond what was approvedRemove the newly added role(s) — the identity and workload stay, only the excess authority is revoked
New identity createdDeployment provisioned an unexpected service principalDisable or delete the specific service principal
Credential exposureLong-lived credential appeared for a workloadRotate the specific credential; configure short-lived token issuance instead
Ownership gapNew workload has no assigned ownerAssign an owner before the workload proceeds — don't revoke, just govern

Why full rollback is usually wrong:

A deployment typically introduces both intended changes (the new feature) and unintended authority expansion (the security concern). Full rollback removes the feature along with the problem. SV0's path-level delta lets the team:

  1. Keep the deployment — the feature works as designed
  2. Revoke the excess authority — remove only the unintended paths
  3. Re-scan to verify — confirm the authority posture now matches the approved baseline

Example: A Foundry agent deployment creates 5 new authority paths. 3 are expected (the agent needs Graph API read access for user profiles). 2 are unexpected (the deployment also granted Blob Storage write access to a Finance container via a role the deployment script included by default). The remediation: remove the 2 Blob Storage role assignments, keep the agent running. Re-scan. Authority posture now matches what was approved.

When full rollback IS appropriate:

  • The deployment created authority paths that cannot be individually revoked (e.g., a wildcard role at the subscription level that cascades to all resources)
  • The identity created by the deployment has already been exercised on unexpected paths — Grade A evidence of unauthorized execution exists
  • The number of unexpected paths is so large relative to expected paths that surgical remediation is impractical

SV0's role in remediation:

SV0 does not perform remediation — it is read-only. It provides:

  • The specific paths to address — actionable ("revoke role X from identity Y on resource Z"), not vague ("review your permissions")
  • The evidence grade for each path — was it exercised (Grade A — urgent) or just configured (Grade C — important but not yet exploited)?
  • Re-scan capability — after the team performs remediation in the source systems (Azure Portal, ServiceNow admin, Foundry settings), SV0 re-scans and verifies the authority posture now matches the approved baseline
  • Updated evidence pack — the post-remediation state is captured in a new evidence pack, providing a complete audit trail: approved baseline → unexpected delta → remediation → verified return to posture

The remediation actions themselves happen in the source systems or through the customer's IaC/automation tooling. SV0 closes the loop by confirming the fix worked.

3.6 CI/CD Integration (Future — See Appendix A)​

The approval workflow described above is the primary approach. CI/CD pipeline integration (GitHub Deployment Protection Rules, Azure DevOps Checks) is a future delivery vehicle that automates the trigger. The platform-specific details, constraints, and architectural considerations are documented in Appendix A for when this use case materializes. Key constraints discovered during research:

  • GitHub DPR fires before deployment — requires staging-to-production promotion pattern
  • Cross-system staging environments have different object IDs (see Section 2.2) — limits staging-scan viability
  • GitLab has 2-minute timeout — incompatible with SV0's scan latency
  • All platforms allow admin bypass — SV0's value is evidence and auditability, not enforcement

4. Architecture Readiness​

W1 infrastructure provides a foundation. W2 requires significant new components — this is a meaningful new build, not a repackaging of W1.

CapabilityCurrent StateGap
Scan pipeline (ingest → diff → materialize → evaluate → evidence)ProductionNone
Authority path materializationProduction, 4-node chainNone
Evidence packs (SHA256 integrity hash, chained)ProductionTamper detection only — signing deferred (see Section 7)
Circuit breaker safetyProduction (entity + path deletion breakers)None
Entity-level diff engineProductionNone
Scan trigger API (POST /syncs)Designed, not implementedNew endpoint — prerequisite for all gate integrations
Targeted scan modeScanScope.targeted in type systemNeed connector support
Authority path delta (path-level diff)Does not existNew capability — entity diff exists, path diff does not
Deployment webhook handlerNot designedNew component — receive webhook, trigger scan, callback
Baseline management (approved state tracking)Not designedNew component — store/version approved postures
Policy engine (pass/fail rules)Not designedNew component or delegate to OPA/Conftest
Cross-connector reconciliationDesigned, not implementedNeeded for full cross-platform authority coverage

Summary: 5 production-ready components (foundation). 2 designed but not implemented. 5 not yet designed (core W2 functionality). The webhook handler, path-level delta, and baseline management are the three critical new builds.

5. Competitive Landscape​

5.1 Honest Competitive Positioning​

Several vendors operate in adjacent territory. The differentiation is real but must be stated precisely.

VendorWhat They DoWhat SV0 Does Differently
Wiz (AI-SPM)Cloud security posture + IaC scanning + attack path analysis (including AI workloads). Agentless AI service discovery, AI-BOM. Correlates identities with vulnerabilities and data risks.Wiz maps infrastructure-level blast radius (VM → network → storage). SV0 maps authority-level blast radius (Workload → Identity → Destination → Domain). Wiz does not produce evidence-graded authority paths, temporal drift analysis, or deployment-specific delta reports.
PermisoUniversal Identity Graph covering human, NHI, and AI identities. Proactive posture (Discover + Protect) and reactive threat detection (Defend). Behavioral analytics.Permiso focuses on detection and response (anomalous behavior, misuse). SV0 focuses on governance assessment (what authority exists, what was exercised, what changed). Permiso does not produce deployment-specific authority impact reports or grade evidence quality.
Astrix SecurityNHI discovery + AI agent security. Anomaly detection on API traffic.Anomaly detection is heuristic. SV0 is deterministic. No deployment gate integration. No evidence grading.
Oasis SecurityNHI lifecycle management + dependency mapping. New "Agentic Access Management" capability.Focus on posture management, not deployment-triggered analysis. No sealed evidence packs. No temporal drift.
Token SecurityHybrid cloud NHI inventory. Zero-trust NHI security.AI-powered = probabilistic. No deployment integration. No evidence grading.
Checkov / TrivyStatic IaC policy checks (Terraform, CloudFormation, K8s). Graph-based config analysis.Config-level only. No runtime identity model. No execution path chains. No evidence packs.
OPA / ConftestPolicy-as-code evaluation engine.No identity graph, no evidence packs. Needs a data source — SV0 could feed OPA.

5.2 What's Actually Differentiated​

Three capabilities that survive honest competitive analysis:

  1. Evidence-graded authority paths. No competitor grades paths by evidence quality (Grade A/B/C). Wiz shows attack paths flat. Permiso shows identity relationships flat. SV0 shows: "14 confirmed, 38 inferred, 90 unconfirmed."

  2. Evidence gaps as governance findings. SV0 surfaces where evidence is missing and what the customer needs to enable. "You have 90 paths where you cannot confirm or deny execution. Here is exactly what to enable to close the gap." No competitor frames evidence absence as a finding.

  3. Deterministic, no-ML, walkable findings. In a market of probabilistic risk scoring, SV0's deterministic model is counter-intuitive and powerful for regulated customers. Every finding is walkable end-to-end. Every evidence pack is auditable.

What is NOT yet differentiated (requires W2 build): Deployment-triggered authority delta reports. This is the W2 deliverable — it does not exist today.

5.3 Market Context​

  • NHI access management market: $11.3B (2025) → $38.8B (2036) — source: GlobeNewsWire market report, directional
  • According to Gravitee (vendor-sponsored survey, 2026): 81% of teams past planning phase for agentic AI, only 14.4% have full security approval
  • AI agent governance has no established market leader
  • The market is moving fast — Wiz, Permiso, Oasis, and Astrix are all adding AI-specific capabilities

SV0's window is open but not indefinite. The evidence grading framework and deterministic model provide a defensible moat if shipped before competitors converge.

6. Regulatory and Standards Alignment​

FrameworkStatusSV0 Alignment
OWASP Top 10 Agentic (2026)Published, community-drivenASI03 (Identity & Privilege Abuse) maps directly to authority path analysis. ASI10 (Rogue Agents) maps to drift detection. Strongest regulatory alignment.
EU AI ActLaw, high-risk rules effective Aug 2026Pre-deployment risk assessment requirement for high-risk AI systems. Fines up to 7% of turnover. Applicability is phased and not all AI systems are high-risk.
NIST SP 800-37/137 (cATO)Published framework with concrete criteriaW2 (point-in-time assessment) + W3 (continuous monitoring), when both built, would map to cATO lifecycle. Neither is production today.
NIST AI Agent Standards InitiativeLaunched Feb 2026, no concrete requirements yetSV0's deterministic model is designed to align with likely outcomes. Future-guidance-oriented.
SLSAPublished frameworkEvidence packs contain the right data. Formatting as SLSA attestations requires cryptographic signing (not yet implemented — see Section 7).
SOC 2OngoingAutomated evidence collection per deployment would support SOC 2 continuous compliance. Requires W2 build.

Lead with OWASP and EU AI Act — these are published, concrete, and survive scrutiny. Use NIST AI Agent Standards and cATO as future alignment signals.

7. Honest Assessment: Evidence Integrity Model​

The research must be transparent about the gap between aspiration and current implementation.

Current state (production):

Evidence packs use SHA-256 content hashing (integrity.ts). The hash is computed from a canonical JSON serialization of the pack content (including tenant_id, finding_id, schema_version). This provides tamper detection — any accidental corruption is detectable by recomputing the hash.

Known limitation (documented in 03-database.md):

The hash is stored alongside the content in the same mutable MongoDB collection. An actor with database write access could rewrite both content and hash. This provides tamper detection, not non-repudiation. The architecture doc explicitly defers KMS/HSM-backed signing and WORM storage until customer compliance requirements drive it.

What this means for W2:

ClaimAccurate?
"SV0 produces audit-supporting evidence"Yes — deterministic, walkable, SHA256 integrity checked
"Evidence detects accidental tampering"Yes — hash recomputation catches corruption
"Evidence is tamper-proof / non-repudiable"No — requires signing + immutable storage (not implemented)
"Evidence is SLSA-compatible"Not yet — requires cryptographic signing (in-toto format ready for adoption)
"Evidence is a signed attestation"No — SHA-256 hash only, no cryptographic signature

Upgrade path (layered):

  1. Layer 1 (today): SHA-256 content integrity — tamper detection
  2. Layer 2 (W2): Platform-level signing — SV0 signs attestations with its own key. Provides non-repudiation of "SV0 produced this assessment"
  3. Layer 3 (W2-W3): RFC 3161 timestamping — independent proof that assessment existed at time T
  4. Layer 4 (compliance-driven): WORM storage + KMS/HSM — full NIST 800-53 AU-10/SI-7 compliance

Layer 1 is sufficient for design partner pilots. Layer 2 is recommended before enterprise sales. Layer 3-4 are compliance-driven features.

8. What "Assurance" Means​

In SV0 terms, assurance is precisely defined:

Assurance IS:

  • Deterministic — based on authority configuration and (where available) execution evidence, not probabilistic scoring
  • Evidence-graded — every authority path labeled with evidence quality (Grade A/B/C)
  • Comparative — always relative to an approved baseline (authority delta)
  • Temporal — point-in-time snapshot that forms part of a historical record
  • Auditable — walkable, SHA256 integrity-checked, chained via previous_pack_id

Assurance is NOT:

  • A score — no "risk score 7.3"
  • A prediction — SV0 does not model hypothetical future states
  • A policy decision — SV0 provides evidence; the human or policy engine decides
  • A guarantee — SV0 shows authority posture; it cannot prove absence of risk
  • An enforcement action — SV0 is read-only; all CI/CD platforms allow admin bypass
  • A signed attestation (today) — SHA256 integrity hash, not cryptographic signature

9. Phased Approach: W1 → W2 → W3​

Pre-deployment assurance is not a pivot. It is a natural extension of the existing model.

W1 — Post-Deployment Discovery (current, production)​

Question: "What autonomous authority exists and what was exercised?"

Key capabilities W2 inherits: Authority path materialization, evidence packs (SHA256), scan pipeline with circuit breakers, finding evaluation rules (12 entity + 10 path), entity-level diff engine.

W2 — Approval Workflow + Post-Deployment Verification (next)​

Question: "What authority does this deployment grant, and how does it compare to the approved baseline?"

Honest framing: For new deployments, all new authority paths are Grade C (standing authority). This is by design — the deployment hasn't run yet. For redeployments of existing workloads, Grade A/B evidence from prior runs carries forward. The gap between approved standing authority (Grade C) and exercised authority (Grade A) is itself a governance signal that compounds over time.

New capabilities to build:

PhaseCapabilityDescription
2aApproval workflowCISO reviews authority posture in SV0, records approval with baseline snapshot
2bBaseline managementStore approved authority posture snapshots. Version with approver + timestamp.
2cAuthority path deltaPath-level diff: new paths, removed paths, changed evidence grades vs baseline
2dOn-demand scan triggerPOST /api/v1/syncs — trigger scan with metadata (deployment context)
2ePost-deployment verification finding"Authority posture changed since approval: N new paths, M expanded permissions"
2fPlatform signingCryptographic signing of assessment output (Layer 2 integrity)

W3 — Continuous Assurance (future)​

Question: "Has authority drifted since the last approval?"

New capabilities: continuous drift detection, cross-plane authority correlation, risk trends, baseline lifecycle (approved → drifted → re-assessed), SOC-ready signal export.

W3 feeds back into W2: Drift exceeding threshold triggers re-assessment → re-gate.

10. Open Questions​

  1. Authority path delta design — Entity-level diffing exists. Path-level diffing (new paths, removed paths, evidence grade changes) is a new capability requiring design.

  2. Cross-connector reconciliation — A deployment may touch multiple systems. Full assessment requires entity correlation across connectors. Research exists but implementation is not started.

  3. Policy engine scope — SV0 provides evidence. Who evaluates pass/fail? Options: (a) built-in deterministic rules, (b) delegate to OPA/Conftest, (c) leave to customer's pipeline. Some built-in rules are likely needed for the webhook callback to return a meaningful disposition.

  4. Baseline management — What constitutes an "approved baseline"? Authority posture at a specific sync? Manually curated paths? How is it versioned?

  5. First integration target — GitHub Deployment Protection Rules (recommended). Requires GitHub App registration and a two-phase staging→production workflow pattern.

  6. Scan latency — P95 target ≤15 minutes is fine for GitHub (30-day timeout) and Azure DevOps (configurable). GitLab (2-minute timeout) requires pipeline job polling instead of External Status Checks.

Appendix A: Platform Integration Details​

GitHub Deployment Protection Rules​

  1. Register a GitHub App with deployment_protection_rules event subscription
  2. Configure the app as a required reviewer on a protected environment (e.g., production)
  3. Critical timing: The webhook fires before the deployment job runs. The job is held until the external check approves. Environment secrets are not accessible until approval.
  4. For SV0: The customer deploys to staging first (no gate), then the promotion workflow references the production environment (gated). SV0 scans the live staging environment.
  5. Callback: POST /repos/{owner}/{repo}/actions/runs/{run_id}/deployment_protection_rule with state: "approved" | "rejected" and Markdown comment (up to 1024 chars, up to 10 reports)
  6. Timeout: 30 days

Existing partners: Datadog, Honeycomb, New Relic, ServiceNow DevOps.

Azure DevOps Approvals and Checks​

  1. Configure a Check on a protected resource (environment, service connection, etc.)
  2. "Invoke REST API" check type: polls SV0's status endpoint at configurable interval
  3. SV0 returns pending → running → approved/rejected
  4. Admin bypass exists: Administrators can override any check. Bypasses are logged. SV0 should detect bypass events as governance findings.
  5. Static checks (branch control, required template) execute before dynamic checks

GitLab (Pipeline Job Pattern)​

GitLab External Status Checks have a ~2-minute pending timeout and require Ultimate tier, making them incompatible with SV0's ≤15-minute scan.

Alternative: Integrate as a CI pipeline job:

  1. Pipeline job calls POST /api/v1/syncs to trigger a scan
  2. Job polls GET /api/v1/syncs/{id} until completion
  3. Job evaluates result and exits 0 (pass) or 1 (fail)
  4. Pipeline job timeout is configurable (default: 1 hour)

SLSA Attestation Format (Future — Requires Signing)​

The in-toto attestation format is the target for W2 Phase 2f. Evidence packs contain the right data. What's needed: cryptographic signing (KMS-backed key) to produce verifiable attestations.

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [{"name": "deployment-xyz", "digest": {"sha256": "..."}}],
  "predicateType": "https://securityv0.com/attestation/authority-assessment/v1",
  "predicate": {
    "tenant_id": "...",
    "deployment_id": "...",
    "assessment_time": "2026-02-27T14:30:00Z",
    "authority_paths_total": 142,
    "grade_a_paths": 14,
    "grade_b_paths": 38,
    "grade_c_paths": 90,
    "new_paths_since_baseline": 3,
    "disposition": "requires_review",
    "evidence_pack_sha256": "abc123..."
  }
}

Current status: This format is aspirational. Evidence packs today have SHA256 integrity hashing (tamper detection) but not cryptographic signing (non-repudiation). The 03-database.md architecture doc explicitly documents this gap and defers signing until compliance requirements drive it.

Appendix B: Review History​

Round 1: Initial Research (3 parallel agents)​

  • Product vision agent: Mapped W1→W2→W3 progression, identified W2 job areas
  • Architecture agent: Assessed scan pipeline readiness, identified API and delta query gaps
  • Industry agent: Researched deployment gate patterns, AI agent governance frameworks, competitive landscape

Round 2: Codex Cross-Review​

Key corrections incorporated:

  • GitHub DPR timing (fires before deployment, not after)
  • GitLab 2-minute timeout and Ultimate tier requirement
  • Azure DevOps admin bypass capability
  • Evidence pack integrity model distinction (tamper detection vs non-repudiation)
  • Wiz AI-SPM and Permiso competitive understatement
  • W2 execution-determined vs standing-authority tension

Round 3: Pessimist/Optimist Dual Review​

Pessimist findings: CEO summary overpromised on 4 dimensions simultaneously. "Architecture-ready" claim was misleading (33% ready, not 60%). "Nobody does this" framing was too absolute. cATO alignment was aspirational, not current.

Optimist solutions: Two-phase gate pattern resolves GitHub timing. Bypass detection turns Azure DevOps bypass into a governance finding. Layered integrity strategy provides upgrade path from tamper detection to signed attestation. Evidence gaps as findings turns SV0's limitation into the customer's problem. Grade C → A trajectory reframes standing authority as the honest starting point, not a weakness.

Sources​

Next Action​

Status: deferred — W2 capability Architecture designed but implementation deferred until post-Inetum onboarding. No GitHub issue created yet — revisit when W1 (current roadmap) is complete.