Skip to content

Promote policy advisor to blocking deployment gate #22

@arnaudlh

Description

@arnaudlh

Description

The policy advisor skill and agent are already comprehensive — they query live subscription state, classify findings by 4-tier severity, generate remediation code (ARM JSON + CLI), and produce split reports (dev template fixes + platform subscription actions). The only structural gap is the absence of a blocking gate that prevents deployment when policy violations are found. This mirrors the existing security gate (Stage 2.5) pattern.

What already exists (no changes needed)

  • ARM template policy analysis across 7 resource categories
  • Live subscription policy queries (az policy assignment list, management groups)
  • Microsoft Learn runtime lookup for current built-in policies
  • 4-tier severity classification (Critical/High/Medium/Low) with Audit/Deny effects
  • Split report: Part 1 (template fixes) + Part 2 (subscription actions)
  • Auto-remediation suggestions with exact ARM JSON snippets
  • Policy-as-code generation (Microsoft.Authorization/policyAssignments)
  • Enforcement mode preference in copilot-instructions.md (Audit default, Deny for production)
  • Pipeline integration at Stage 2.85

Scope (what's needed)

  1. Stage 2.55 Policy Gate — Add a blocking gate step after the policy advisor runs, mirroring the Stage 2.5 security gate pattern:
    • 🟢 POLICY GATE: PASSED — No Critical or High policy violations. Deployment may proceed.
    • 🔴 POLICY GATE: BLOCKED — Critical or High violations found. Deployment blocked until resolved.
    • Override mechanism: user types "I accept the policy risk" (logged as OVERRIDDEN).
  2. Config toggle — Formalize the existing audit/deny preference in copilot-instructions.md or .azure/git-ape.yml as a gate mode:
    • audit (default) — Policy report is generated and shown but does not block deployment.
    • deny — Policy findings at Critical/High severity block deployment (gate enforced).
  3. Workflow integration — Add policy analysis summary to git-ape-plan.yml PR comment alongside security and cost sections.

Acceptance Criteria

  • Policy gate step added at Stage 2.55 with PASSED/BLOCKED status.
  • Gate mode configurable: audit (non-blocking) or deny (blocking).
  • Deny mode blocks deployment on Critical/High policy findings.
  • Override mechanism with logged justification.
  • Plan workflow PR comment includes policy compliance section.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions