@raishin/vanguard-frontier-agentic 2.8.0 → 2.10.0

package/skills/azure/azure-entra-id-specialist/references/entra-id-identity-operations.md

@@ -0,0 +1,62 @@
+# Microsoft Entra identity operations
+
+## What people get wrong
+
+- They disable security defaults before replacement Conditional Access coverage exists.
+- They make broad Conditional Access exclusions for executives, service accounts, or break-glass without monitoring and compensating controls.
+- They grant permanent privileged roles instead of using PIM and just-in-time activation.
+- They ignore workload identities, app registrations, credentials, and delegated permissions while focusing only on human users.
+- They treat report-only Conditional Access results as proof enforcement is safe for every token path.
+
+## Officially grounded service shape
+
+Microsoft Learn describes security defaults as a basic baseline requiring MFA registration, administrator MFA, protection for privileged Azure Resource Manager access, and blocking of legacy authentication and device code flow. For complex tenants, Conditional Access provides customizable policies. Microsoft guidance also emphasizes PIM for just-in-time privileged roles, MFA for administrators, emergency access accounts, least privilege, backup/recovery, and monitoring of identity governance changes.
+
+## Non-negotiable design rules
+
+1. Keep either security defaults or equivalent Conditional Access coverage active.
+2. Require emergency access accounts and monitoring before risky policy changes.
+3. Prefer PIM eligible assignments over permanent privileged roles.
+4. Minimize exclusions and document owner, reason, expiration, and compensating controls.
+5. Block or phase out legacy authentication and risky flows unless a documented exception exists.
+6. Govern workload identities with owners, least privilege, credential lifecycle, and reviews.
+7. Treat identity configuration changes as high blast-radius mutations.
+
+## Minimal safe implementation flow
+
+1. Identify licensing and whether security defaults or Conditional Access is the active baseline.
+2. Inventory MFA, legacy auth, device code flow, admin access, and emergency access posture.
+3. Review Conditional Access assignments, targets, conditions, grants, sessions, exclusions, and report-only data.
+4. Review privileged roles, PIM settings, activation requirements, alerts, and access reviews.
+5. Review app registrations and workload identities for owners, credentials, grants, and lifecycle.
+6. Stage changes with pilot scope, report-only, break-glass verification, and rollback.
+7. Enforce only after monitoring and support readiness are proven.
+
+## High-risk assumptions to kill
+
+- Disabling security defaults is unsafe unless equivalent Conditional Access coverage, emergency access, monitoring, and support readiness already exist.
+- Report-only Conditional Access is impact evidence, not enforcement proof; token paths, exclusions, app dependencies, and break-glass flows still need testing.
+- Broad block policies can lock out admins, especially when combined with all-resources scope and weak exclusion planning.
+- Workload identities are not covered by user-scoped Conditional Access; service principals, managed identities, and federated credentials need separate review.
+- A control may require specific Entra licensing or service entitlement; do not imply availability from documentation alone.
+
+## Safe command/code verification targets
+
+- Inspect policy-as-code or exported Conditional Access JSON for users/workload identities, target resources, conditions, grants, session controls, state, exclusions, and report-only posture.
+- Review role assignments and PIM configuration for permanent privileged roles, activation duration, MFA, approval, notifications, and access reviews.
+- Check app registrations and service principals for owners, credential type, credential age, federated credentials, API permissions, consent grants, and sign-in/risk logs.
+- Verify emergency access accounts are excluded appropriately, monitored, tested, and not used for routine administration.
+- Confirm final evidence distinguishes documented Microsoft Learn behavior from sampled tenant evidence and unverified licensing assumptions.
+
+## Safe verification targets
+
+- Security defaults state or equivalent Conditional Access baseline.
+- MFA registration and enforcement for users and privileged roles.
+- Legacy authentication and device code flow handling.
+- Emergency access account count, configuration, and alerting.
+- PIM role eligibility, activation duration, approval, MFA, and notifications.
+- Workload identity owners, credentials, permissions, and risk signals.
+
+## When to push back
+
+Push back on disabling defaults, enforcing broad Conditional Access without emergency access, permanent Global Administrator assignments, unowned app registrations, blanket exclusions, or identity recommendations based only on screenshots or assumptions.

package/skills/azure/azure-entra-id-specialist/references/licensing-and-service-entitlements.md

@@ -121,3 +121,7 @@ Use this when the user is designing AI agents and assumes ordinary Entra pattern
 - “Documentation says this feature requires Entra ID P1, but I do not know whether your tenant has that license.”
 - “Business Premium includes Conditional Access, but risk-based Conditional Access depends on P2-backed ID Protection.”
 - “Fabric uses the same Entra tenant, but user rights and capacity rights are separate from Entra feature entitlements.”
+
+## Evidence refresh - 2026-06-04
+
+- Microsoft Learn documents separate prerequisites for agent security features: Conditional Access for agents requires Entra ID P1, ID Protection for agents requires Entra ID P2, ID Governance for agents requires Entra ID P1, and network controls for agents require Global Secure Access licensing. Treat these as documented prerequisites, not proof of tenant entitlement.

package/skills/azure/azure-entra-id-specialist/references/mcp-and-evidence.md

@@ -1,33 +1,27 @@
-# MCP and evidence path
+# MCP and evidence path for Microsoft Entra identity operations
 
-Use this reference only when you need to decide how to gather Entra evidence.
+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.
 
-## Live-first evidence rule
+## Evidence ladder
 
-1. Prefer live Azure MCP capability evidence when the active client exposes Azure tools.
-2. Treat the runtime-exposed tool inventory as truth.
-3. If Entra-specific tooling is not exposed live, say so and switch to documentation-based guidance instead of pretending the namespace exists.
+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.
 
-## Azure MCP grounding
+## Rules
 
-Based on Microsoft documentation:
+- 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.
 
-- Microsoft recommends **consolidated mode** for AI agents because it reduces tool count and improves usability.
-- Namespace filtering means a client may expose only a subset of Azure tools.
-- Do not assume that the active client exposes Entra-specific operations just because Microsoft documents broader Azure MCP capabilities.
+## Final-answer evidence language
 
-## Evidence hierarchy
+Use phrases like:
 
-Use this order:
-
-1. **live evidence** — Azure MCP output, sanitized screenshots, sanitized policy exports, sanitized logs, or user-provided config excerpts
-2. **user-provided sanitized evidence** — redacted CA policy summaries, app-registration details, audit logs, sign-in logs, risk events, or screenshots
-3. **documentation-based** — Microsoft Learn and official Azure MCP documentation
-4. **inference** — conclusions derived from patterns but not directly proven by evidence
-
-## Entra caution points
-
-- Do not bless Conditional Access exclusions without explicit break-glass and recovery logic.
-- Do not assume MFA means safe posture if registration, authentication methods, or legacy paths are weak.
-- Do not confuse identity governance controls with full Entra ID security posture.
-- Do not assume workload identities, service principals, or app registrations are low-risk just because they are nonhuman.
+- "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-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.