# MCP and evidence path for Azure Policy guardrail operations

Use Microsoft Learn documentation through the user's configured documentation MCP as the first grounding path for Azure service behavior. This file defines evidence boundaries; it must not imply that documentation proves the user's tenant, subscriptions, RBAC, quotas, billing agreement, deployed resources, or production readiness.

## Evidence ladder

1. `docs_only`: Microsoft Learn documentation and official architecture guidance. Use for documented behavior, caveats, and safe review criteria.
2. `sampled_read_only`: configured-environment evidence from read-only tools, if available and explicitly scoped. Use only for the sampled resource/time window.
3. `user_supplied`: sanitized outputs, IaC, diagrams, billing summaries, or metrics provided by the user. Treat as unverified unless independently checked.
4. `mutation_ready`: documentation plus current-state evidence plus explicit approval, blast-radius statement, and rollback path.

## Rules

- Do not expose environment-specific implementation details in committed docs or user-facing guidance.
- Do not ask for credentials, tokens, tenant identifiers, subscription identifiers, billing account identifiers, connection strings, private keys, customer data, or raw secrets.
- If current-state evidence was not sampled, say `not sampled`; do not imply it.
- If evidence is representative or partial, say so. A sample does not prove broad regional availability, billing accuracy, policy compliance, or production readiness.
- Prefer read-only evidence before mutation planning. Stop for approval before write operations.

## Final-answer evidence language

Use phrases like:

- "Based on Microsoft Learn documentation..."
- "Configured-environment evidence was not sampled in this review."
- "The following is an inference from the provided configuration, not proven live state."
- "This recommendation is mutation-ready only after explicit approval and rollback review."

# Official sources for Azure Governance Policy Guardrails

Use Microsoft Learn documentation through the user's configured documentation MCP before designing Azure Policy guardrails. Documentation proves policy behavior; it does not prove the user's assignment scope, current compliance, remediation identity permissions, or workload impact.

## Primary Microsoft Learn sources

| Source | Review implication |
| --- | --- |
| [What is Azure Policy?](https://learn.microsoft.com/en-us/azure/governance/policy/overview) | Ground policy definitions, initiatives, assignments, evaluation triggers, remediation, RBAC, and start-with-audit recommendations. |
| [Azure Policy effect basics](https://learn.microsoft.com/en-us/azure/governance/policy/concepts/effect-basics) | Use for effect behavior, evaluation order, and why effects are not interchangeable. |
| [DeployIfNotExists effect](https://learn.microsoft.com/en-us/azure/governance/policy/concepts/effect-deploy-if-not-exists) | Use for DINE timing, managed identity, and remediation caveats. |
| [Policy compliance states](https://learn.microsoft.com/en-us/azure/governance/policy/concepts/compliance-states) | Use for compliance interpretation and limitations. |
| [Policy initiative definition structure](https://learn.microsoft.com/en-us/azure/governance/policy/concepts/initiative-definition-structure) | Use for grouping definitions and initiative parameter strategy. |
| [Policy exemption structure](https://learn.microsoft.com/en-us/azure/governance/policy/concepts/exemption-structure) | Use for exception governance and expiry. |
| [Remediate non-compliant resources](https://learn.microsoft.com/en-us/azure/governance/policy/how-to/remediate-resources) | Use for remediation tasks and required managed identity permissions. |
| [Adopt policy-driven guardrails](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/enterprise-scale/dine-guidance) | Use for phased DINE/Modify rollout and DoNotEnforce/canary patterns. |

## Source-grounding rules

- Do not use Azure Policy as a workload deployment engine.
- Do not deploy broad deny/modify/remediation first; start with audit or staged scope unless risk justifies enforcement.
- Do not treat compliance percentage as safety proof; inspect applicability, exclusions, exemptions, and stale evaluations.
- Require identity permission review for DINE/Modify remediation.

# Azure Policy guardrail operations

## What people get wrong

- They use Azure Policy as a workload deployment mechanism instead of a governance and compliance mechanism.
- They roll out deny or modify at management-group scope before seeing audit impact.
- They forget that policy assignments inherit and that explicit deny requires changing or excluding the denying assignment.
- They run remediation without checking the managed identity permissions and affected resources.
- They treat exemptions as permanent fixes instead of governed exceptions.

## Officially grounded service shape

Microsoft Learn describes Azure Policy as a service for enforcing organizational standards and assessing compliance at scale. Definitions can be grouped into initiatives and assigned to management group, subscription, resource group, or resource scopes. Effects such as audit, deny, modify, and deployIfNotExists behave differently and evaluate at different times. DINE and Modify remediation require managed identities with enough permissions. Microsoft guidance recommends starting with audit/auditIfNotExists and using staged rollout patterns for DINE/Modify controls.

## Non-negotiable design rules

1. Define business objective, target resource types, and scope before choosing an effect.
2. Prefer audit or DoNotEnforce/canary rollout before deny, modify, or DINE at broad scope.
3. Review inheritance, exclusions, exemptions, and explicit-deny behavior.
4. Use initiatives for related controls and parameter consistency.
5. Grant remediation identities only the permissions required by the policy.
6. Give exemptions an owner, reason, category, expiration, and review process.
7. Manage policy definitions, initiatives, and assignments as code with review.

## Minimal safe implementation flow

1. Draft policy or initiative and map each effect to desired behavior.
2. Assign at narrow canary scope with audit or enforcement disabled when practical.
3. Review compliance state, noncompliance causes, false positives, and pipeline failures.
4. Validate managed identity permissions for DINE/Modify remediation.
5. Define exemptions and notScopes with expiry and ownership.
6. Move to enforcement in stages by scope, resource selector, or management group path.
7. Monitor compliance, remediation failures, and deployment impact after rollout.

## High-risk assumptions to kill

- Broad-scope deny is dangerous without audit impact, false-positive review, and a rollback path.
- `modify` and `deployIfNotExists` are mutation paths; remediation identity permissions and affected resources must be reviewed before rollout.
- Exemptions and `notScopes` can make compliance look better than reality if ownership, reason, category, and expiry are missing.
- Assignment inheritance means a resource can be blocked by a parent policy even when local scope looks clean.
- Azure Policy should not be used as a substitute for application deployment orchestration or configuration management.

## Safe command/code verification targets

- Inspect policy and initiative JSON for mode, aliases, parameters, effect, effect overrides, definition versions, and resource selectors.
- Review assignment files for scope, enforcement mode, non-compliance messages, `notScopes`, exemptions, and staged rollout tiers.
- Check remediation definitions for managed identity type, roleDefinitionIds, least-privilege role assignments, resource filters, count, parallelism, and failure threshold.
- Verify CI/CD gates collect compliance results and fail when noncompliance, false positives, or application health impact diverges from expectations.
- Confirm rollback can disable or narrow assignment, revert definition/initiative version, stop remediation, or remove high-risk effects.

## Safe verification targets

- Policy definition mode, effect, aliases, parameters, and resource provider applicability.
- Initiative composition and parameter wiring.
- Assignment scope, notScopes, exemptions, enforcement mode, and resource selectors.
- Compliance states and noncompliance reasons.
- Remediation task settings, identity permissions, resource count, failure threshold, and deployment summary.
- Rollback plan: disable assignment, revert definition, reduce scope, or remove remediation.

## When to push back

Push back on broad deny without audit data, DINE/Modify without identity review, permanent exemptions, policy-as-deployment misuse, or compliance claims that ignore excluded and exempt resources.

# Safety checklist for Azure Governance Policy Guardrails

## Non-negotiable gates

- Never ask for tenant identifiers, subscription identifiers, customer data, raw resource inventories, or policy exports containing sensitive names without sanitization.
- Do not recommend broad-scope deny, modify, deployIfNotExists, or remediation without canary scope, exemption plan, owner, and rollback.
- Do not assign remediation identities broad permissions without least-privilege review.
- Do not use Azure Policy to deploy full workloads; use it for governance and compliance controls.
- Require explicit approval before assignment, enforcement-mode change, remediation task, exemption change, initiative update, or deny effect rollout.

## High-risk assumptions to kill

- "Audit passed, so enforcement is safe." Enforcement can still break deployment pipelines.
- "Deny is cleaner than audit." Deny can block urgent fixes and existing automation.
- "Remediation is automatic for everything." Existing resources need tasks; identity permissions matter.
- "Exemptions are harmless." They need reason, expiration, owner, and review.
- "Management group scope is always best." Inherited deny can have wide blast radius and explicit-deny behavior.

## Evidence labels

- `docs_only`: Microsoft Learn guidance only.
- `policy_review`: definition, initiative, assignment, or exemption reviewed statically.
- `compliance_sample`: sanitized compliance state or policy insights were sampled.
- `canary_proven`: staged scope tested without unexpected impact.
- `mutation_ready`: approval, scope, rollback, and identity permissions are documented.

## Minimum safe evidence

- Target scope, inheritance path, notScopes, exemptions, and affected resource types.
- Policy effect, mode, parameters, initiative membership, and assignment enforcement mode.
- Compliance sample, noncompliance causes, and deployment pipeline impact review.
- Managed identity permissions for DINE/Modify and remediation task plan.
- Canary scope, rollback plan, exception process, and owner.

# Workflow and output contract for Azure Governance Policy Guardrails

## Minimal safe workflow

1. Classify request: new policy, initiative, assignment, exemption, remediation, enforcement rollout, or compliance review.
2. Ground behavior in Microsoft Learn through the user's configured documentation MCP.
3. Identify scope and inheritance: management group, subscription, resource group, excluded scopes, and exemptions.
4. Review effect and mode: audit, deny, modify, DINE, disabled, manual, and assignment enforcement mode.
5. Stress test blast radius: deployment pipelines, existing resources, remediation identity, exemptions, and rollback.
6. Stage through audit or DoNotEnforce/canary before broad enforcement unless risk demands immediate action.
7. Return verdict with blockers and safe rollout sequence.

## Output contract

```markdown
## Verdict
<safe to stage | conditional | unsafe | docs-only advisory>

## Evidence level
- Documentation: <sources used>
- Policy evidence: <policy_review|compliance_sample|canary_proven|not sampled>

## Findings
1. <finding> — Evidence: <docs_only|policy_review|compliance_sample|inference>

## Blast radius
- Scope: <summary>
- Pipelines/resources at risk: <summary>

## Safe rollout
1. <stage>

## Blockers
- <blocker>
```

## Pushback triggers

Push back on broad deny first, remediation identities with excessive rights, exemptions with no expiry, compliance percentages without applicability review, or assignment changes without rollback.