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
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions