@raishin/vanguard-frontier-agentic 2.8.0 → 2.9.0

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"
 }

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

@@ -0,0 +1,68 @@
+# Azure Key Vault Secret Lifecycle 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
+
+- Auditing by reading secret values instead of metadata, ownership, and lifecycle policy.
+- Treating soft delete alone as enough for production recovery.
+- Leaving purge authority with broad operators or automation identities.
+- Using one vault as a shared dumping ground across apps, environments, or tenants.
+- Equating an expiration date with a tested rotation path.
+
+## Officially grounded service shape
+
+Microsoft Learn evidence says Key Vault should be secured with vault segmentation, network restrictions, managed identities, Azure RBAC for critical workloads, soft delete, purge protection, rotation, logging, Event Grid monitoring, Azure Policy, and tested backup or recovery. Soft delete preserves deleted vaults and objects for a retention period, while purge protection blocks permanent deletion until the retention period elapses.
+
+- Key Vault is a security boundary for keys, secrets, and certificates, not a general configuration database.
+- Critical workloads should prefer Azure RBAC and managed identities; legacy access policies are harder to govern safely.
+- Soft delete enables recovery; purge protection prevents premature permanent deletion during retention.
+- Secret rotation commonly depends on owner, dependency mapping, eventing or alerting, automation, and rollback.
+- Event Grid and logs can support lifecycle visibility, but alerts must map to owners and tested runbooks.
+
+## Non-negotiable design rules
+
+- Never ask for or print secret values, connection strings, tokens, or private keys.
+- Audit secret names, versions, enabled state, expiration, tags, content type, owners, RBAC, and deleted-object posture instead.
+- Require purge permission to be narrowly scoped, JIT where possible, and separate from routine secret writers.
+- Treat missing recovery test evidence as a blocker for production-safe claims.
+- Require app dependency impact analysis before disabling, deleting, purging, or rotating secrets.
+
+## Minimal safe implementation flow
+
+- Scope vaults by application, environment, region, and tenant boundary.
+- Confirm RBAC/access model, network exposure, soft delete, purge protection, logging, and policy coverage.
+- Review secret inventory metadata for missing owner, missing expiration, stale versions, ambiguous naming, and unmanaged dependencies.
+- Review rotation and recovery runbooks against actual downstream consumers and alert routes.
+- Return findings without exposing secret material.
+
+## High-risk assumptions to kill
+
+- Soft delete alone is not enough for production; purge protection, recovery ownership, and dependency restore testing still matter.
+- A secret with an expiration date is not rotated unless automation, owner response, downstream validation, and rollback are proven.
+- Broad purge, delete, recover, or secret officer permissions can turn routine administration into irreversible outage or breach risk.
+- A shared vault across applications, environments, regions, or tenants expands blast radius unless there is a documented exception.
+- Event Grid or logging configuration is not operational readiness unless alerts reach accountable responders with tested runbooks.
+
+## Safe command/code verification targets
+
+- Inspect vault IaC for RBAC mode, soft delete, purge protection, retention days, public network access, private endpoints, diagnostic settings, and Event Grid subscriptions.
+- Review role assignments for secret read/write/delete/recover/purge permissions, assignment scope, permanence, and JIT or approval controls.
+- Check secret metadata inventory for owner tags, purpose, enabled state, expiration, content type, stale versions, and dependency mapping without retrieving values.
+- Verify rotation automation references managed identity or equivalent secretless auth, emits status, and has rollback for failed downstream credential update.
+- Confirm backup/recovery runbooks cover the secret object and the dependent application behavior after recovery, not just vault restore commands.
+
+## Safe verification targets
+
+- Vault uses an access model appropriate for critical workloads and has no broad persistent secret or purge roles.
+- Soft delete and purge protection are enabled with retention expectations documented.
+- Secrets have owner, purpose, expiration or justified exception, and rotation mechanism or compensating control.
+- Near-expiry, deletion, and failed-rotation events route to accountable responders.
+- Recovery has been tested for both secret object and dependent application behavior.
+
+## When to push back
+
+- The user wants secret contents pasted into chat.
+- Purge, delete, recover, or rotation changes are requested without approval and rollback evidence.
+- A single vault spans unrelated apps, environments, or tenants without a documented exception.
+- No one can name the owner or dependent services for a production secret.

package/skills/azure/azure-key-vault-secret-lifecycle-auditor/references/mcp-and-evidence.md

@@ -1,40 +1,26 @@
-# MCP and Evidence Path
+# Documentation and Evidence Path
 
-## Official Azure MCP Linkage
+## Preferred evidence order
 
-Use only official Azure MCP capabilities actually exposed in the active runtime.
+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.
 
-Relevant namespaces may include:
+## What each evidence type can prove
 
-- `keyvault` for vault, key, secret, certificate, and Managed HSM evidence,
-- `role` when RBAC assignment correlation is required,
-- `monitor` if alerting or event visibility is part of the audit,
-- `policy` when policy-enforced protections matter.
+- 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 confuse tool availability with audit sufficiency:
+## Safe usage pattern
 
-- Azure MCP can help inspect assets and settings.
-- It does not automatically prove rotation logic, downstream dependency handling, or restore readiness.
-- Secret-reading tools may require user confirmation because they can expose sensitive data. Avoid them unless absolutely necessary.
+- 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.
 
-## Platform-Agnostic Execution
+## Asset guidance
 
-This skill must work in MCP-only, macOS, Linux, and Windows clients.
-
-Prefer:
-
-1. Azure MCP metadata and configuration evidence,
-2. official Microsoft Learn and policy references,
-3. sanitized inventories, screenshots, or exports from the user,
-4. neutral placeholder commands only when needed.
-
-Do not assume the user operates through Azure CLI, PowerShell, Terraform, Bicep, or portal-only workflows unless they say so.
-
-## Documentation Fallback When Live Data Is Unavailable
-
-Live vault posture beats theory. If live access is unavailable, incomplete, denied, or unsafe:
-
-- fall back to official Microsoft documentation,
-- ask for sanitized inventories such as vault settings, secret lists without values, expiration metadata, role assignments, and alert definitions,
-- label each conclusion as `live evidence`, `documentation-based`, `user-provided sanitized evidence`, or `inference`,
-- do not claim a vault is safe merely because the platform supports the right features.
+Use Microsoft Learn documentation through the user's configured documentation MCP for documented Key Vault behavior. Use sampled read-only Azure evidence only for metadata, policy, RBAC, eventing, and recovery posture; never request or expose secret values.

package/skills/azure/azure-key-vault-secret-lifecycle-auditor/references/official-sources.md

@@ -1,15 +1,28 @@
 # Official Sources
 
-## References
-
-Load these only when needed:
-
-- [Azure MCP Server tools inventory](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/)
-- [Azure Key Vault tools for Azure MCP Server](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-key-vault)
-- [Manage Azure Key Vault with Azure MCP Server](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/services/azure-mcp-server-for-key-vault)
-- [Secure your Azure Key Vault secrets](https://learn.microsoft.com/en-us/azure/key-vault/secrets/secure-secrets)
-- [Understanding autorotation in Azure Key Vault](https://learn.microsoft.com/en-us/azure/key-vault/general/autorotation)
-- [Grant permission to applications to access an Azure key vault using Azure RBAC](https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-guide)
-- [Azure Key Vault soft-delete overview](https://learn.microsoft.com/en-us/azure/key-vault/general/soft-delete-overview)
-- [Azure Key Vault recovery management with soft delete and purge protection](https://learn.microsoft.com/en-us/azure/key-vault/general/key-vault-recovery)
-- [Built-in policy definitions for Key Vault](https://learn.microsoft.com/en-us/azure/key-vault/policy-reference)
+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.
+
+## Primary Microsoft Learn sources
+
+- 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
+
+## Grounding notes
+
+- Documentation-based claim: Microsoft Learn evidence says Key Vault should be secured with vault segmentation, network restrictions, managed identities, Azure RBAC for critical workloads, soft delete, purge protection, rotation, logging, Event Grid monitoring, Azure Policy, and tested backup or recovery. Soft delete preserves deleted vaults and objects for a retention period, while purge protection blocks permanent deletion until the retention period elapses.
+- 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-key-vault-secret-lifecycle-auditor/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
+
+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.