@raishin/vanguard-frontier-agentic 2.8.0 → 2.10.0

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.

package/skills/azure/azure-identity-governance-review/references/mcp-and-evidence.md

@@ -1,49 +1,26 @@
-# MCP and Evidence Path
+# Documentation and Evidence Path
 
-## Official Azure / Entra Linkage
+## Preferred evidence order
 
-Ground this skill in official Microsoft Learn content only.
+1. Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior.
+2. Sampled read-only Azure or Kubernetes evidence, when safely available, for current configured-environment observations.
+3. Sanitized user-provided evidence.
+4. Clearly labeled inference.
 
-Preferred linkage:
-- Use the Cloud Adoption Framework identity-access design area to frame identity-plane responsibilities, separation of duties, and privileged-access expectations.
-- Use Microsoft Entra ID Governance documentation for PIM, access reviews, and entitlement management behavior.
-- Use Azure RBAC or role-assignment evidence only when correlating governance findings to actual Azure scopes or role sprawl.
+## What each evidence type can prove
 
-If live Azure tooling is available in the client, use Azure role-related evidence carefully for:
-- which principals hold privileged Azure resource roles,
-- whether assignment scope is broader than claimed,
-- whether standing assignments remain where eligibility should exist.
+- Microsoft Learn documentation can prove documented service behavior, supported concepts, and recommended patterns.
+- Sampled read-only evidence can prove the sampled configured state at the time observed.
+- Sanitized user evidence can prove only what the snippet shows.
+- None of these alone prove broad regional availability, future success, full account posture, or production readiness.
 
-Do not claim that Azure MCP exposes full Entra governance state unless the active client actually does. If governance evidence is missing, say so.
+## Safe usage pattern
 
-## Platform-Agnostic Execution
+- State whether each claim is documentation-based, sampled-current-state, user-provided, or inference.
+- Use read-only queries before recommending changes.
+- Do not include sensitive internal identifiers, tenant identifiers, subscription identifiers, or secrets in committed docs or final findings.
+- If no sampled evidence is available, say the review is documentation-based and list the exact evidence still needed.
 
-This skill must work in MCP-only, browser-only, and documentation-only environments. Prefer neutral evidence language:
-- `<tenant>`
-- `<management-group | subscription | resource-group | resource>`
-- `<principal>`
-- `<privileged role>`
-- `<access package>`
+## Asset guidance
 
-If commands or portal paths are useful, keep them platform-neutral and adapt only after the user’s actual environment is known.
-
-## Documentation Fallback When Live Data Is Unavailable
-
-Live tenant evidence beats documentation. If live evidence is unavailable, denied, incomplete, or unsafe to collect:
-
-- switch to documentation-grounded review mode,
-- ask for sanitized exports or screenshots of assignments, PIM settings, review schedules, access packages, or ownership mappings,
-- label each conclusion as `live evidence`, `documentation-based`, `sanitized evidence`, or `inference`,
-- refuse to present documentation as proof of current tenant posture.
-
-Documentation fallback is acceptable for:
-- control-pattern recommendations,
-- review-cadence design,
-- eligibility-versus-standing critiques,
-- entitlement-management workflow design.
-
-It is not enough for:
-- proving PIM is enabled,
-- proving reviews actually run,
-- proving expired access is removed,
-- proving ownership is assigned and operational.
+Use Microsoft Learn documentation through the user's configured documentation MCP for documented Entra behavior. Use sampled read-only Azure evidence only for current tenant observations and label it as sampled evidence.

package/skills/azure/azure-identity-governance-review/references/official-sources.md

@@ -1,28 +1,28 @@
 # Official Sources
 
-## References
+Use these sources to ground the skill. Microsoft Learn documentation proves documented Azure behavior; it does not prove the user's tenant, RBAC, quotas, deployed resources, or production readiness.
 
-Load only what is needed:
+## Primary Microsoft Learn sources
 
-- Azure identity and access management design area
-  https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/identity-access
-- Landing zone identity and access management
-  https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/identity-access-landing-zones
-- Microsoft Entra roles best practices
-  https://learn.microsoft.com/en-us/azure/active-directory/roles/best-practices
-- Privileged Identity Management documentation
-  https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/
-- Assign Azure resource roles in Privileged Identity Management
-  https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-resource-roles-assign-roles
-- Access reviews overview
-  https://learn.microsoft.com/en-us/entra/id-governance/access-reviews-overview
-- Manage access with access reviews
-  https://learn.microsoft.com/en-us/entra/id-governance/manage-access-review
-- Perform access reviews for Azure resource and Microsoft Entra roles in PIM
-  https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-perform-roles-and-resource-roles-review
-- Entitlement management overview
-  https://learn.microsoft.com/en-us/entra/id-governance/entitlement-management-overview
-- Create an access review of an access package in entitlement management
-  https://learn.microsoft.com/en-us/entra/id-governance/entitlement-management-access-reviews-create
-- Azure MCP tool inventory
-  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
+
+## Grounding notes
+
+- Documentation-based claim: 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.
+- Current-state claim: requires sampled read-only Azure evidence or sanitized user-provided evidence.
+- Inference: allowed only when labeled and tied to observed fields or documented behavior.
+- Do not include sensitive internal identifiers or secret material in findings.
+
+## Source use rules
+
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP for current Azure service behavior.
+- Use sampled read-only Azure evidence only to validate current configured-environment observations.
+- If documentation and sampled evidence appear to conflict, report both and stop short of a production-ready verdict.
+- Re-check official sources before changing high-risk guidance, because cloud behavior and feature availability can change.

package/skills/azure/azure-identity-governance-review/references/safety-checklist.md

@@ -0,0 +1,29 @@
+# Safety Checklist
+
+## Evidence labels
+
+- `documentation-based`: grounded in Microsoft Learn or official Kubernetes documentation where listed.
+- `sampled-current-state`: grounded in read-only Azure or Kubernetes observations from the user's configured tools.
+- `user-provided`: grounded in sanitized snippets supplied by the user.
+- `inference`: reasoned from evidence but not directly proven.
+
+## Mutation boundary
+
+- Default to read-only review.
+- Do not perform create, update, delete, rotate, purge, recover, apply, restart, drain, cordon, scale, rollout, role-assignment, policy-assignment, or network changes unless the user explicitly asks and approval is clear.
+- Prefer preview, dry-run, status, describe, what-if, list, show, and policy evaluation evidence before any mutation.
+
+## Credential and data boundary
+
+- Never ask users to paste credentials, tokens, tenant IDs, subscription IDs, customer data, private keys, kubeconfig contents, CA requester credentials, secret values, or connection strings.
+- Summarize sensitive evidence by field presence, control state, and risk; do not reproduce secret material.
+
+## Risk gates
+
+- Stop on ambiguous target, ambiguous principal, missing approval, missing rollback, or missing owner for high-impact assets.
+- Treat broad permissions, permanent privileged access, public exposure, purge authority, destructive operations, and live rollout changes as high-risk.
+- Separate documented product behavior from sampled configured-environment evidence.
+
+## Asset-specific hard line
+
+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.

package/skills/azure/azure-identity-governance-review/references/workflow-and-output.md

@@ -1,76 +1,30 @@
 # Workflow and Output Contract
 
-## Safe Workflow
+## Execution flow
 
-1. **Identify privileged population**: Azure resource roles, Microsoft Entra roles, privileged groups, app-access groups, external users, and service principals/workload identities when relevant.
-2. **Separate assignment design from governance process**: who has access, whether it is active or eligible, how it is activated, who approves it, how long it lasts, and who reviews it.
-3. **Challenge standing privilege first**: any always-active privileged role needs explicit justification, bounded scope, and an owner.
-4. **Review PIM posture**: activation requirements, approval path, time limits, notifications, and whether eligibility is actually used for human admin access.
-5. **Review access-review posture**: target resources, reviewer accountability, cadence, completion/application of results, and stale-access handling.
-6. **Review entitlement-management use**: whether access packages are used where recurring project/team access exists, whether package owners exist, and whether assignments expire and get reviewed.
-7. **Map ownership/accountability gaps**: role owner, group owner, package owner, approver, review owner, and exception approver.
-8. **Return a go/no-go governance verdict** with explicit evidence labels, least-privilege recommendations, and missing facts.
+1. Scope the exact asset, environment boundary, owner, and requested decision.
+2. Load `official-sources.md`, then the component operations guide for service behavior and risk gates.
+3. Gather sampled read-only evidence only when available and safe.
+4. Compare observed posture against documented behavior, least-privilege expectations, and operational safety rules.
+5. Return a verdict with evidence level, blockers, safe next actions, and open questions.
 
-## Role-Specific Stress Checks
+## Required output
 
-- PIM does not fix bad scope design. Eligible `Owner` at subscription scope can still be reckless.
-- Access reviews that never apply removals are theater, not governance.
-- Entitlement management without package owners, approval rules, expiration, and reviews is packaging, not control.
-- Standing access for human administrators is a red flag unless there is a documented break-glass or operational justification.
-- Privileged groups can hide excessive access just as easily as direct role assignments; do not stop at direct assignments.
-- “We review quarterly” means nothing unless the review target, reviewer, completion path, and removal action are defined.
-- Service principals and workload identities need governance too, but do not force human PIM patterns onto unsupported cases.
+- `verdict`: pass, warn, fail, or blocked.
+- `evidence_level`: documentation-based, sampled-current-state, user-provided, inference, or mixed.
+- `scope`: what was reviewed and what was not reviewed.
+- `blockers`: issues that prevent a safe or production-ready conclusion.
+- `findings`: severity-labeled risks with source labels.
+- `safe_next_actions`: reversible actions first; mutation only with explicit approval.
+- `open_questions`: missing facts that would change the verdict.
 
-## Output Template
+## Stress checks
 
-```markdown
-# Azure Identity Governance Review: <scope>
+- What assumption would make this recommendation unsafe?
+- Which role, policy, network, lifecycle, or rollout action has the largest blast radius?
+- What evidence would disprove the claimed readiness?
+- Is the answer accidentally treating documentation as tenant-specific proof?
 
-## Verdict
-- Status: READY / READY WITH RISKS / NOT READY
-- Biggest governance gap:
-- Evidence level: live evidence / documentation-based / sanitized evidence / inference
+## Response discipline
 
-## Scope
-- Tenant or hierarchy boundary:
-- Privileged population reviewed:
-- Requested outcome:
-- Review owner:
-
-## Current privilege model
-| Area | Current state | Risk |
-|---|---|---|
-| Standing vs eligible access |  |  |
-| PIM posture |  |  |
-| Access reviews |  |  |
-| Entitlement management |  |  |
-| Ownership/accountability |  |  |
-
-## Findings
-| Finding | Severity | Evidence | Why it matters | Recommendation | Owner |
-|---|---|---|---|---|---|
-
-## Least-privilege governance pattern
-- Human privileged access:
-- Workload or service access:
-- Review cadence:
-- Approval model:
-- Expiration model:
-
-## Safe next actions
-1.
-2.
-3.
-
-## Open questions
--
-```
-
-## Red Flags
-
-- Permanent `Owner`, `Contributor`, `User Access Administrator`, or high-privilege Entra role assignments for normal operator work.
-- PIM enabled only for a subset of admins while broad standing access remains elsewhere.
-- Access reviews exist but have no clear reviewer, no recurrence, or no evidence that denied access is removed.
-- Entitlement management is absent where recurring team/project access could replace manual privileged group handling.
-- No named owner for privileged groups, access packages, or approval workflows.
-- Governance claims rely only on documentation or intent, not tenant evidence.
+Use Microsoft Learn documentation through the user's configured documentation MCP for documented Entra behavior. Use sampled read-only Azure evidence only for current tenant observations and label it as sampled evidence.

package/skills/azure/azure-key-vault-secret-lifecycle-auditor/SKILL.md

@@ -4,8 +4,8 @@ description: Audit Azure Key Vault secret lifecycle posture across RBAC, soft de
 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: security
 ---
 
@@ -29,7 +29,7 @@ Force clarity on:
 
 Default access posture:
 
-- Prefer Azure MCP read-oriented evidence when Key Vault tooling is available.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP; use sampled read-only Key Vault evidence when the active client exposes it.
 - Treat secret contents as sensitive and unnecessary for most audits.
 - Never ask the user to paste secret values, certificate private keys, tokens, connection strings, or customer data into chat.
 - Prefer metadata, policy, ownership, and rotation posture over retrieving secret values.
@@ -48,7 +48,7 @@ Use this skill when the user asks to:
 
 ## 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.
@@ -57,7 +57,9 @@ Use this skill when the user asks to:
 
 Load these only when needed:
 
+- [Azure Key Vault Secret Lifecycle Operations](references/key-vault-secret-lifecycle-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-key-vault-secret-lifecycle-auditor/metadata.json

@@ -14,19 +14,18 @@
   "summary": "Audit Azure Key Vault secret lifecycle posture across RBAC, soft delete, purge protection, expiration, rotation, metadata hygiene, eventing, and recovery readiness without exposing secret values.",
   "source_type": "original",
   "official_docs": [
-    "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-key-vault",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/services/azure-mcp-server-for-key-vault",
-    "https://learn.microsoft.com/en-us/azure/key-vault/secrets/secure-secrets",
-    "https://learn.microsoft.com/en-us/azure/key-vault/general/autorotation",
-    "https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-guide",
-    "https://learn.microsoft.com/en-us/azure/key-vault/general/soft-delete-overview",
-    "https://learn.microsoft.com/en-us/azure/key-vault/general/key-vault-recovery",
-    "https://learn.microsoft.com/en-us/azure/key-vault/policy-reference"
+    "https://learn.microsoft.com/azure/key-vault/secrets/secure-secrets",
+    "https://learn.microsoft.com/azure/key-vault/general/secure-key-vault",
+    "https://learn.microsoft.com/azure/key-vault/general/rbac-guide",
+    "https://learn.microsoft.com/azure/key-vault/general/soft-delete-overview",
+    "https://learn.microsoft.com/azure/key-vault/general/key-vault-recovery",
+    "https://learn.microsoft.com/azure/key-vault/secrets/tutorial-rotation",
+    "https://learn.microsoft.com/azure/key-vault/general/event-grid-overview",
+    "https://learn.microsoft.com/azure/key-vault/policy-reference"
   ],
-  "security_notes": "Avoid retrieving secret values unless absolutely necessary. Treat purge authority, missing soft delete, missing purge protection, and unproven rotation or recovery paths as high-risk. Prefer RBAC least privilege and metadata-based audits over content access.",
-  "last_verified": "2026-04-27",
+  "security_notes": "Avoid retrieving secret values. Treat purge authority, missing soft delete, missing purge protection, legacy access policies for critical workloads, and untested rotation or recovery paths as high-risk.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-key-vault-secret-lifecycle-auditor",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.3"
 }