@raishin/vanguard-frontier-agentic 2.8.0 → 2.9.0

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.

package/skills/azure/azure-identity-governance-review/SKILL.md

@@ -4,8 +4,8 @@ description: Review Microsoft Entra identity governance posture for Azure operat
 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
 ---
 
@@ -16,8 +16,8 @@ metadata:
 Act as a ruthless Azure identity-governance reviewer. Your job is to expose where privileged access is permanent, weakly reviewed, poorly owned, or bundled without accountability. Do not confuse “PIM enabled” with “governed.” Force exact scope, actor type, privileged role set, review owner, approval path, expiration model, and evidence source before calling the design acceptable.
 
 Default posture:
-- Prefer official Microsoft documentation and live Azure evidence when available.
-- Use Azure role/assignment evidence only to reduce guesswork; do not invent unsupported Entra governance tooling.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP, then sampled read-only Azure evidence when the active client exposes it.
+- Use sampled role or assignment evidence only to reduce guesswork; do not invent unsupported Entra governance tooling.
 - Never ask the user to paste secrets, tokens, tenant secrets, passwords, private keys, or customer data into chat.
 - Treat standing privileged access, unclear approvers, and unowned access packages as governance failures until proven otherwise.
 
@@ -35,7 +35,7 @@ Do not use this skill for low-level authentication debugging, app sign-in break/
 
 ## 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.
@@ -44,7 +44,9 @@ Do not use this skill for low-level authentication debugging, app sign-in break/
 
 Load these only when needed:
 
+- [Azure Identity Governance Operations](references/identity-governance-operations.md) — use for current service behavior, common failure modes, hard design rules, verification targets, and push-back conditions.
 - [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing live Azure evidence, confirming Microsoft MCP capability, or switching to documentation mode.
+- [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-identity-governance-review/metadata.json

@@ -11,24 +11,21 @@
     "kiro",
     "other"
   ],
-  "summary": "Review Microsoft Entra identity governance posture for Azure operators, focusing on PIM, access reviews, entitlement management, standing access, and ownership gaps.",
+  "summary": "Review Microsoft Entra identity governance posture for Azure operators, focusing on PIM, access reviews, entitlement management, standing access, emergency access, and ownership gaps.",
   "source_type": "original",
   "official_docs": [
-    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/identity-access",
-    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/identity-access-landing-zones",
-    "https://learn.microsoft.com/en-us/azure/active-directory/roles/best-practices",
-    "https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/",
-    "https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-resource-roles-assign-roles",
-    "https://learn.microsoft.com/en-us/entra/id-governance/access-reviews-overview",
-    "https://learn.microsoft.com/en-us/entra/id-governance/manage-access-review",
-    "https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-perform-roles-and-resource-roles-review",
-    "https://learn.microsoft.com/en-us/entra/id-governance/entitlement-management-overview",
-    "https://learn.microsoft.com/en-us/entra/id-governance/entitlement-management-access-reviews-create",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/"
+    "https://learn.microsoft.com/entra/architecture/ops-guide-govern",
+    "https://learn.microsoft.com/entra/id-governance/scenarios/least-privileged",
+    "https://learn.microsoft.com/entra/id-governance/identity-governance-overview",
+    "https://learn.microsoft.com/entra/id-governance/access-reviews-overview",
+    "https://learn.microsoft.com/entra/id-governance/entitlement-management-overview",
+    "https://learn.microsoft.com/entra/identity/role-based-access-control/best-practices",
+    "https://learn.microsoft.com/entra/identity/role-based-access-control/security-emergency-access",
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/identity-access"
   ],
-  "security_notes": "Challenge standing privileged access by default. Do not treat PIM, access reviews, or entitlement management as sufficient unless scope, ownership, cadence, and removal behavior are explicit.",
-  "last_verified": "2026-04-27",
+  "security_notes": "Challenge standing privileged access by default. PIM, access reviews, and entitlement management are not sufficient unless scope, owner, cadence, approval, expiration, and removal behavior are explicit.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-identity-governance-review",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.3"
 }

package/skills/azure/azure-identity-governance-review/references/identity-governance-operations.md

@@ -0,0 +1,68 @@
+# Azure Identity Governance Operations
+
+Use this reference for current, source-grounded service behavior and the hard review gates that the lean `SKILL.md` intentionally does not carry.
+
+## What people get wrong
+
+- Treating PIM enablement as proof that privileged access is governed.
+- Accepting permanent administrator assignments without activation, approval, expiration, and access-review evidence.
+- Creating access packages with no resource owner, stale reviewer, or never-expiring assignment policy.
+- Ignoring emergency access accounts until a lockout occurs.
+- Claiming tenant compliance from documentation alone.
+
+## Officially grounded service shape
+
+Microsoft Learn evidence says Entra ID Governance covers entitlement management, access reviews, lifecycle workflows, and PIM. The operations guide requires task owners, testing strategy, regular reviews for applications, external identities and privileged roles, emergency access accounts, and entitlement management. Least-privilege guidance points to feature-specific administrative roles and JIT role activation through PIM.
+
+- Identity Governance is a lifecycle control set, not a one-time role cleanup.
+- Access reviews apply to groups, applications, role assignments, access packages, and external identities when the right licensing and scope exist.
+- PIM supports just-in-time privileged access, but role settings, approvers, MFA, activation duration, and review cadence decide whether it is safe.
+- Entitlement management uses catalogs, access packages, policies, approvals, assignment duration, and review settings; each layer needs ownership.
+- Emergency access accounts are intentionally exceptional and must be protected, monitored, and periodically tested.
+
+## Non-negotiable design rules
+
+- Inventory standing privileged assignments before praising governance maturity.
+- Require owner, reviewer, cadence, action-on-denial, and expiration for each governed access path.
+- Prefer eligible JIT assignments for privileged roles and narrow scope before custom exceptions.
+- Separate human operator access, workload identity access, external-user access, and break-glass access.
+- Label unqueried tenant state as unverified; documentation only proves product behavior.
+
+## Minimal safe implementation flow
+
+- Scope the tenant, administrative planes, critical roles, external access paths, and access-package catalogs.
+- Collect documentation-grounded expected controls, then gather sampled current-state evidence if available.
+- Compare permanent assignments, PIM settings, access review schedules, owner coverage, and expiration posture.
+- Rank gaps by blast radius: Global Administrator, Privileged Role Administrator, subscription Owner/User Access Administrator, external privileged access, and unowned packages first.
+- Return blockers, safe next actions, and explicit unknowns without requesting secrets or tenant identifiers in chat.
+
+## High-risk assumptions to kill
+
+- PIM enabled is not governance unless privileged roles have eligible assignment scope, activation controls, approval, MFA, expiration, notifications, and recurring reviews.
+- Access reviews are weak evidence when reviewers are unowned, conflicted, never act on denial, or exclude privileged and external access paths.
+- Entitlement management is not safe if catalogs, packages, policies, assignment duration, approval, and review settings lack business owners.
+- Emergency access accounts are not optional; missing, unmonitored, or routinely used break-glass accounts are governance failures.
+- Documentation proves feature behavior, not tenant licensing, configured policies, assignment state, or compliance maturity.
+
+## Safe command/code verification targets
+
+- Inspect exported governance evidence for role assignments, eligible versus active state, assignment source, direct versus group-based grants, and privileged scope.
+- Review PIM settings for activation duration, approval, MFA, justification, ticketing, notifications, and access review cadence.
+- Check access review definitions for scope, recurrence, reviewers, fallback reviewers, auto-apply behavior, denial action, and last completion result.
+- Inspect entitlement-management artifacts for catalog owner, access package resources, policies, approval stages, assignment expiration, and external-user lifecycle.
+- Confirm final outputs label Microsoft Learn documentation separately from sampled configured-tenant evidence and unverified licensing assumptions.
+
+## Safe verification targets
+
+- Role assignment inventory distinguishes active, eligible, permanent, group-based, and direct assignments.
+- PIM settings show activation duration, approval/MFA requirements, and notification/audit configuration for privileged roles.
+- Access reviews have owners, recurrence, scope, reviewer selection, and automatic action behavior.
+- Access packages have business owners, assignment expiration, approval policy, and review settings.
+- Emergency access accounts are cloud-only, monitored, excluded from risky dependencies only where justified, and tested.
+
+## When to push back
+
+- The user asks for a compliant verdict without role, PIM, review, and owner evidence.
+- A design depends on shared permanent administrator groups.
+- Reviewers are the same people whose access is being reviewed with no compensating control.
+- Break-glass accounts are missing, weakly monitored, or used for routine operations.