@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

package/skills/azure/azure-entra-id-specialist/references/official-sources.md

@@ -1,78 +1,31 @@
-# Official sources
+# Official sources for Azure Entra ID Specialist
 
-Use this reference only when you need the detailed source list or need to ground a specific claim.
+Use Microsoft Learn documentation through the user's configured documentation MCP before identity guidance. Documentation proves Microsoft-published behavior; it does not prove the user's tenant posture, licenses, policy state, exclusions, sign-in risk, or break-glass readiness.
 
-## Azure MCP
+## Primary Microsoft Learn sources
 
-- Azure MCP overview
-  https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/overview
-- Azure MCP concepts
-  https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/concepts
-- Azure MCP tools overview
-  https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/
+| Source | Review implication |
+| --- | --- |
+| [Security defaults in Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/fundamentals/security-defaults) | Use for MFA registration, administrator MFA, legacy auth blocking, device code flow blocking, and Conditional Access migration caveats. |
+| [Build a Conditional Access policy](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-policies) | Use for assignments, target resources, network, conditions, grant/session controls, and token-evaluation caveats. |
+| [Common Conditional Access policies](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-policy-common) | Use for secure-foundation templates and baseline policy strategy. |
+| [Best practices for Microsoft Entra roles](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/best-practices) | Ground least privilege, PIM, admin MFA, and privileged-role hygiene. |
+| [Privileged Identity Management](https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure) | Use for eligible roles, just-in-time activation, approval, alerts, and role settings. |
+| [Best practices for securely deploying Microsoft Entra ID Governance](https://learn.microsoft.com/en-us/entra/id-governance/best-practices-secure-id-governance) | Use for least privilege, backup/recovery, monitoring, access reviews, and governance operations. |
+| [Workload identities overview](https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview) | Use for app/service principal/workload identity review. |
+| [Emergency access accounts](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access) | Use for break-glass account design and monitoring. |
 
-## Microsoft Entra ID
+## Source-grounding rules
 
-- What is Microsoft Entra?
-  https://learn.microsoft.com/en-us/entra/fundamentals/what-is-entra
-- What is Microsoft Entra ID Governance?
-  https://learn.microsoft.com/en-us/entra/id-governance/identity-governance-overview
-- What is Microsoft Entra Privileged Identity Management?
-  https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure
-- Protect security info registration with Conditional Access policy
-  https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-security-info-registration
-- Conditional Access: Users, groups, agents, and workload identities
-  https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-users-groups
-- What are workload identities?
-  https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview
-- Securing workload identities
-  https://learn.microsoft.com/en-us/entra/id-protection/concept-workload-identity-risk
-- Conditional Access for Agent ID (Preview)
-  https://learn.microsoft.com/en-us/entra/identity/conditional-access/agent-id
-- Manage agent identities in your organization
-  https://learn.microsoft.com/en-us/entra/agent-id/manage-agent-identities-admin
-- Microsoft Entra security for AI overview
-  https://learn.microsoft.com/en-us/entra/agent-id/security-for-ai-overview
-- Microsoft Entra ID Governance licensing fundamentals
-  https://learn.microsoft.com/en-us/entra/id-governance/licensing-fundamentals
-- Microsoft Entra licensing
-  https://learn.microsoft.com/en-us/entra/fundamentals/licensing
-- What is Conditional Access?
-  https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview
-- Features and licenses for Microsoft Entra multifactor authentication
-  https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mfa-licensing
-- What is Microsoft Entra ID Protection?
-  https://learn.microsoft.com/en-us/entra/id-protection/overview-identity-protection
-- Microsoft Entra service description
-  https://learn.microsoft.com/en-us/office365/servicedescriptions/azure-active-directory
+- Do not disable security defaults unless replacement Conditional Access coverage is ready.
+- Do not recommend broad exclusions; require explicit named rationale and compensating controls.
+- Do not approve privileged-role changes without PIM, MFA, alerting, and emergency access review.
+- Treat tenant evidence as sensitive; request only sanitized summaries.
 
-## Cross-service licensing examples
+## Current Microsoft Learn deltas checked on 2026-06-05
 
-- Azure integration with Microsoft 365
-  https://learn.microsoft.com/en-us/microsoft-365/enterprise/azure-integration
-- Understand Microsoft Fabric licenses
-  https://learn.microsoft.com/en-us/fabric/enterprise/licenses
-- Buy a Microsoft Fabric subscription
-  https://learn.microsoft.com/en-us/fabric/enterprise/buy-subscription
-- Learn about Conditional Access and Intune
-  https://learn.microsoft.com/en-us/intune/device-security/conditional-access-integration/overview
-- Require device compliance with Conditional Access
-  https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-device-compliance
-- Microsoft Defender service description
-  https://learn.microsoft.com/en-us/office365/servicedescriptions/microsoft-365-service-descriptions/microsoft-365-tenantlevel-services-licensing-guidance/microsoft-defender-service-description
-- Microsoft Entra External ID overview
-  https://learn.microsoft.com/en-us/entra/external-id/external-identities-overview
-- What are workload identities?
-  https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview
-- What is Microsoft Entra?
-  https://learn.microsoft.com/en-us/entra/fundamentals/what-is-entra
+- Conditional Access planning depends on Microsoft Entra licensing; risk-based policies require stronger entitlement evidence than baseline policy design.
+- Emergency access accounts and service principals/service accounts require explicit exclusion or separate control design; do not assume user-scoped Conditional Access safely governs every identity type.
+- Conditional Access for workload identities is scoped to single-tenant service principals in the tenant; do not claim managed identities or multi-tenant SaaS apps are covered without current documentation evidence.
+- Microsoft Entra roles and Azure RBAC roles are separate control planes; never use one evidence set to prove the other.
 
-## Grounded insights used by this skill
-
-- Existing identity governance controls do not prove broader Entra ID posture is sound.
-- Conditional Access and registration controls can create lockout risk if exclusions and emergency access are careless.
-- Workload identities and app registrations need the same least-privilege scrutiny as human admins.
-- Tenant identity, Microsoft 365 bundle rights, and Fabric capacity rights are related but not interchangeable.
-- Adjacent Microsoft services can share the same tenant while still having separate licensing, capacity, or premium-feature gates.
-- Device-compliance Conditional Access can depend on Intune setup and compliance policy existence, not just Entra policy authoring rights.
-- Some ID Protection detections and AI-agent protections depend on adjacent Microsoft services or preview-specific capabilities, not just base Entra branding.

package/skills/azure/azure-entra-id-specialist/references/safety-checklist.md

@@ -0,0 +1,32 @@
+# Safety checklist for Azure Entra ID Specialist
+
+## Non-negotiable gates
+
+- Never ask for tenant identifiers, user lists, object identifiers, tokens, app secrets, certificates, private keys, sign-in logs with personal data, or raw audit exports.
+- Do not recommend disabling security defaults without replacement Conditional Access policies ready to protect the tenant.
+- Do not recommend broad Conditional Access exclusions, blanket MFA bypass, or privileged role permanency without explicit risk acceptance.
+- Require emergency access account design before high-risk Conditional Access or role changes.
+- Require explicit approval before policy enablement, report-only to enforce changes, exclusions, role assignments, app credential changes, or workload identity changes.
+
+## High-risk assumptions to kill
+
+- "MFA exists, so identity is safe." Legacy auth, exclusions, stale sessions, app permissions, and privileged roles still matter.
+- "Report-only policy success means enforce safely." Token timing, excluded paths, break-glass, and app compatibility need checks.
+- "Global Administrator is convenient." It should be rare, monitored, and preferably just-in-time.
+- "Security defaults plus custom needs is enough." Complex tenants generally need Conditional Access.
+- "Service principals are harmless." Workload identities can carry high-impact permissions and secrets.
+
+## Evidence labels
+
+- `docs_only`: Microsoft Learn guidance only.
+- `tenant_sample`: sanitized read-only tenant posture evidence was reviewed.
+- `policy_review`: Conditional Access, PIM, or app registration config was reviewed, not proven live.
+- `change_ready`: emergency access, rollback, approval, and monitoring are documented.
+
+## Minimum safe evidence
+
+- Licensing capability: security defaults vs Conditional Access/PIM/Identity Protection availability.
+- MFA posture, legacy authentication status, security defaults or Conditional Access baseline.
+- Emergency access accounts, monitoring, and exclusion strategy.
+- Privileged roles: active vs eligible, activation controls, alerts, and reviews.
+- Workload identities, app credentials, owner hygiene, and permission grants.

package/skills/azure/azure-entra-id-specialist/references/workflow-and-output.md

@@ -1,50 +1,39 @@
-# Workflow and output contract
-
-Use this reference only when you are performing the full Entra review.
-
-## Workflow
-
-1. **Scope the target**
-   - Confirm whether the question is about users, admins, workload identities, app registrations, external identities, or mixed.
-   - Confirm whether the real problem is sign-in control, privileged access, workload access, or governance.
-   - Confirm whether the issue is tenant-wide, one role family, one app, or one policy set.
-
-2. **Establish evidence level**
-   - Use live Azure MCP evidence when available.
-   - Otherwise use official docs plus sanitized user evidence.
-   - Explicitly label unknowns.
-
-3. **Check licensing and service entitlements when relevant**
-   - Determine whether the user is asking about feature rights, not only technical configuration.
-   - Distinguish Azure baseline, Microsoft 365 bundle inclusion, Entra premium plans, workload identity premium features, and Fabric capacity/per-user rights.
-   - Distinguish Entra tenant identity from adjacent service entitlements such as Intune compliance dependencies, Microsoft Defender signal prerequisites, Purview or Fabric service rights, External ID billing, Verified ID premium add-ons, and agent identity preview capabilities.
-   - If tenant licensing is unproven, mark the answer as licensing-conditional instead of assuming entitlement.
-
-4. **Learn before concluding on adjacent services**
-   - If the user mentions another Microsoft service, do not answer from brand association alone.
-   - Check whether the service merely shares the Entra tenant, depends on Intune/Defender/Purview/Fabric-specific licenses, or introduces a separate identity primitive such as agent identities.
-   - Prefer official Microsoft documentation over memory for cross-service claims.
-
-5. **Stress-check the identity control posture**
-   - Conditional Access scope, exclusions, and lockout safety
-   - MFA/SSPR/authentication-method registration and abuse resistance
-   - risky-user / risky-sign-in handling and identity protection posture
-   - app-registration, enterprise-app, and service-principal ownership and privilege shape
-   - workload identity and managed-identity control boundaries
-   - agent identity, agent user, and blueprint control boundaries when AI agents are in scope
-   - break-glass safety and recovery paths
-
-6. **Check adjacent roles the user may be missing**
-   - **Azure Identity Governance Review** when the problem narrows specifically to PIM, access reviews, entitlement management, and standing-versus-eligible access.
-   - **Azure RBAC Review** when the dominant issue is Azure resource authorization scope rather than Entra tenant identity controls.
-   - **Azure Security Posture Hardening** when the identity question becomes part of a broader Azure security program review.
+# Workflow and output contract for Azure Entra ID Specialist
+
+## Minimal safe workflow
+
+1. Classify request: security baseline, Conditional Access, MFA, PIM, app registration, workload identity, governance, or mutation approval.
+2. Ground the review in Microsoft Learn through the user's configured documentation MCP.
+3. Determine evidence level: docs only, sanitized tenant sample, policy review, or change-ready package.
+4. Review baseline: security defaults or Conditional Access, MFA, legacy auth, device code flow, emergency access, and admin separation.
+5. Review privilege: roles, PIM, eligibility, activation requirements, alerts, access reviews, and break-glass monitoring.
+6. Review workload identities: owners, credentials, permissions, risk, and lifecycle.
+7. Return verdict, blockers, and safe staged next actions.
 
 ## Output contract
 
-Use this structure:
+```markdown
+## Verdict
+<secure enough | conditional | high-risk | docs-only advisory>
+
+## Evidence level
+- Documentation: <sources used>
+- Tenant/config evidence: sanitized tenant sample, policy review, or not sampled
+
+## Findings
+1. <finding> — Evidence: <docs_only|tenant_sample|policy_review|inference>
+
+## Change risk
+- Blast radius: <summary>
+- Rollback: <summary or blocker>
+
+## Blockers
+- Identity blocker: describe the missing proof without exposing tenant or principal identifiers
+
+## Safe next actions
+- <least-risk action>
+```
+
+## Pushback triggers
 
-1. **Verdict**
-2. **Evidence level**
-3. **Key findings**
-4. **Safest next actions**
-5. **Open questions**
+Push back on disabling protections, broad exclusions, permanent privileged access, app secrets with no rotation, Conditional Access enforcement without emergency access, or identity claims without tenant evidence.

package/skills/azure/azure-governance-policy-guardrails/SKILL.md

@@ -4,8 +4,8 @@ description: Use this skill for Azure Policy guardrails, initiatives, assignment
 allowed-tools: Read Grep Glob
 metadata:
   author: github: Raishin
-  version: 0.1.0
-  updated: "2026-05-05"
+  version: 0.1.3
+  updated: "2026-06-05"
   category: compliance
 ---
 
@@ -32,7 +32,7 @@ Do not use this as a substitute for full regulatory interpretation, SOC operatio
 
 ## Lean operating rules
 
-- Prefer live Azure or Microsoft evidence first when the active client exposes it; otherwise fall back to official documentation and sanitized user evidence.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP, then sampled read-only Azure evidence when the active client exposes it, then sanitized user evidence.
 - Separate confirmed facts from inference. If state was not queried or shown, say so.
 - Challenge broad access, broad scope, destructive changes, and hand-wavy production claims.
 - Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
@@ -41,7 +41,9 @@ Do not use this as a substitute for full regulatory interpretation, SOC operatio
 
 Load these only when needed:
 
-- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing live Azure evidence, confirming Microsoft MCP capability, or switching to documentation mode.
+- [Operations guide](references/policy-guardrail-operations.md) — use for service-specific pitfalls, design rules, verification targets, and pushback criteria.
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only Azure evidence, or sanitized user evidence.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, risk gates, mutation boundaries, approval rules, credential boundaries, and current-state caveats.
 - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, applying stress checks, or formatting the final answer.
 - [Official sources](references/official-sources.md) — use when you need the detailed Microsoft documentation list or source notes.
 

package/skills/azure/azure-governance-policy-guardrails/metadata.json

@@ -22,12 +22,14 @@
     "https://learn.microsoft.com/en-us/azure/governance/policy/how-to/remediate-resources",
     "https://learn.microsoft.com/en-us/azure/governance/policy/concepts/exemption-structure",
     "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/migrate-azure-landing-zone-policies",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-policy"
+    "https://learn.microsoft.com/en-us/azure/governance/policy/concepts/effect-basics",
+    "https://learn.microsoft.com/en-us/azure/governance/policy/how-to/policy-safe-deployment-practices",
+    "https://learn.microsoft.com/en-us/azure/governance/policy/concepts/effect-deploy-if-not-exists",
+    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/enterprise-scale/dine-guidance"
   ],
   "security_notes": "Do not recommend broad-scope deny or remediation-first rollout without blast-radius review, inheritance analysis, exception handling, and rollback notes.",
-  "last_verified": "2026-04-27",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-governance-policy-guardrails",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.3"
 }

package/skills/azure/azure-governance-policy-guardrails/references/mcp-and-evidence.md

@@ -1,22 +1,27 @@
-# MCP and Evidence Path
-
-## Evidence path
-
-Prefer evidence in this order:
-
-1. Azure governance design guidance:
-   - https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/governance
-   - https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/tailoring-alz
-2. Azure Policy core behavior:
-   - https://learn.microsoft.com/en-us/azure/governance/policy/overview
-   - https://learn.microsoft.com/en-us/azure/governance/policy/concepts/initiative-definition-structure
-   - https://learn.microsoft.com/en-us/azure/governance/policy/assign-policy-portal
-   - https://learn.microsoft.com/en-us/azure/governance/policy/how-to/remediate-resources
-   - https://learn.microsoft.com/en-us/azure/governance/policy/concepts/exemption-structure
-3. Azure landing zone policy lifecycle guidance:
-   - https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/migrate-azure-landing-zone-policies
-4. Azure MCP discovery path when available in the client:
-   - https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/
-   - https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-policy
-
-If Azure MCP tools are available, use `policy` first for assignments, definitions, and initiatives. Use `group` and `subscription` to confirm hierarchy and inheritance boundaries. Use `advisor` or `pricing` only when they materially help with governance tradeoffs such as SKU restriction or cost-control guardrails.
+# 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."

package/skills/azure/azure-governance-policy-guardrails/references/official-sources.md

@@ -1,18 +1,23 @@
-# Official Sources
+# Official sources for Azure Governance Policy Guardrails
 
-Load these only when needed:
+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.
 
-- [What is Azure Policy?](https://learn.microsoft.com/azure/governance/policy/overview) — use for policy object model, assignment scope behavior, evaluation timing, Azure RBAC interaction, and core rollout cautions.
-- [Azure Policy definitions effect basics](https://learn.microsoft.com/azure/governance/policy/concepts/effect-basics) — use when comparing `audit`, `auditIfNotExists`, `deny`, `modify`, and `deployIfNotExists`.
-- [Remediate non-compliant resources with Azure Policy](https://learn.microsoft.com/azure/governance/policy/how-to/remediate-resources) — use for managed identity, RBAC, and remediation-task implications.
-- [Azure Policy built-in policy definitions](https://learn.microsoft.com/azure/governance/policy/samples/built-in-policies) — use when checking whether built-ins already cover tags, locations, SKUs, or baseline controls.
-- [Adopt policy-driven guardrails](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/enterprise-scale/dine-guidance) — use for canary rollout, enforcement mode, and phased `audit` to `deny` or remediation sequencing.
-- [Azure landing zone design principles](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-principles) — use when guardrails are part of the broader landing-zone operating model.
-- [Azure MCP Server tools inventory](https://learn.microsoft.com/azure/developer/azure-mcp-server/tools/) — use to verify whether `policy`, `group`, `subscription`, `advisor`, or other namespaces are actually documented before naming them.
+## Primary Microsoft Learn sources
 
-## Grounded insights worth carrying into the skill
+| 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. |
 
-- A policy can be assigned at management-group scope, but Azure Policy evaluates resources at subscription or resource-group level; do not imply it governs arbitrary tenant objects.
-- `modify` and `deployIfNotExists` are not “free automation”; their assignment identities need the right Azure RBAC permissions to create or update target resources.
-- Microsoft guidance explicitly recommends starting with `audit` or `auditIfNotExists` when rollout risk is unclear, rather than jumping straight to production `deny` or remediation.
-- Broad exclusions are usually governance debt. Prefer narrow exclusions or time-bounded exemptions with named ownership.
+## 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.

package/skills/azure/azure-governance-policy-guardrails/references/policy-guardrail-operations.md

@@ -0,0 +1,62 @@
+# 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.

package/skills/azure/azure-governance-policy-guardrails/references/safety-checklist.md

@@ -0,0 +1,33 @@
+# 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.

package/skills/azure/azure-governance-policy-guardrails/references/workflow-and-output.md

@@ -1,86 +1,39 @@
-# Workflow and Output Contract
+# Workflow and output contract for Azure Governance Policy Guardrails
 
-## Workflow
+## Minimal safe workflow
 
-1. Identify the governing hierarchy first:
-   - tenant root management group,
-   - intermediate management groups,
-   - subscriptions,
-   - resource groups,
-   - exceptional resources that may need carve-outs.
-2. Classify the requested control:
-   - audit-only visibility,
-   - `deny` prevention,
-   - `modify` mutation,
-   - `deployIfNotExists` deployment/remediation,
-   - initiative bundling for repeated baseline controls.
-3. Decide whether the control belongs in:
-   - a single policy definition,
-   - an initiative for baseline packaging,
-   - an existing landing-zone baseline,
-   - or not in policy at all because the ask is process-only or too brittle.
-4. Choose assignment scope deliberately:
-   - prefer the highest scope that matches the real control boundary,
-   - do not assign at broad scope by habit,
-   - verify inheritance impact on child subscriptions and resource groups,
-   - call out when management-group placement is justified versus excessive.
-5. Design exclusions and exemptions separately:
-   - exclusions for scope carve-outs,
-   - exemptions for approved exception handling,
-   - narrow both by resource type, location, or defined exception boundary where possible.
-6. Evaluate guardrail content explicitly for common governance cases:
-   - required tags and tag value standards,
-   - allowed locations,
-   - allowed resource types,
-   - allowed or denied SKUs where built-in policy coverage exists,
-   - baseline initiatives that bundle related controls.
-7. Challenge remediation and mutation risk before recommending enforcement:
-   - `modify` and `deployIfNotExists` need managed identity, permissions, and rollback thought,
-   - remediation can change existing resources,
-   - deny can block live deployment paths if staged badly.
-   - remember that assignment at management-group scope still evaluates subscription/resource-group resources; do not imply magical tenant-object coverage.
-8. Recommend rollout sequencing:
-   - observe with audit first when facts are incomplete,
-   - pilot on a lower, representative scope,
-   - measure non-compliance and exception volume,
-   - then tighten to enforce where justified.
-9. State the rollback and exception path:
-   - remove or disable the assignment,
-   - narrow scope,
-   - replace deny with audit temporarily,
-   - use time-bounded exemptions instead of permanent policy erosion.
+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
 
-Return:
+```markdown
+## Verdict
+<safe to stage | conditional | unsafe | docs-only advisory>
 
-- current governance summary,
-- target control objective,
-- recommended policy versus initiative shape,
-- assignment scope recommendation and inheritance impact,
-- exclusion and exemption strategy,
-- remediation or mutation risk,
-- staged rollout plan,
-- rollback or exception path,
-- assumptions, missing facts, and evidence used.
+## Evidence level
+- Documentation: <sources used>
+- Policy evidence: <policy_review|compliance_sample|canary_proven|not sampled>
 
-## Eval gate
+## Findings
+1. <finding> — Evidence: <docs_only|policy_review|compliance_sample|inference>
 
-Treat the answer as incomplete unless it does all of the following:
+## Blast radius
+- Scope: <summary>
+- Pipelines/resources at risk: <summary>
 
-- identifies the actual governing scope,
-- separates audit, deny, modify, and remediation concerns,
-- recommends assignment placement instead of hand-waving “use policy,”
-- addresses exclusions or exemptions for brownfield reality,
-- flags rollout risk for deny or remediation effects,
-- gives enforceable guardrails for tags, regions, SKUs, or baseline initiatives when those are in scope.
+## Safe rollout
+1. <stage>
 
-Fail the response if it recommends root-scope sprawl, ignores inheritance, or proposes enforcement without change-safety notes.
+## Blockers
+- <blocker>
+```
 
-## Safety notes
+## Pushback triggers
 
-- Do not recommend tenant-root or broad management-group assignments without explicit blast-radius justification.
-- Do not recommend `deny`, `modify`, or `deployIfNotExists` as a default first move in production.
-- Do not hide remediation side effects; existing resources may be changed or left non-compliant depending on policy effect.
-- Do not treat exclusions as a dumping ground for weak design; prefer narrow, accountable exceptions.
-- Do not claim governance is solved by policy alone; ownership, operating process, and lifecycle updates still matter.
+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.