@raishin/vanguard-frontier-agentic 2.8.0 → 2.10.0

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.

package/skills/azure/azure-key-vault-secret-lifecycle-auditor/references/workflow-and-output.md

@@ -1,101 +1,30 @@
 # Workflow and Output Contract
 
-## Safe Workflow
+## Execution flow
 
-1. **Scope the vault estate**
-   - Which vaults matter?
-   - Which workloads or teams depend on them?
-   - Which assets are secrets, keys, or certificates?
-2. **Check the protection floor**
-   - Is soft delete enabled?
-   - Is purge protection enabled?
-   - What is the retention period?
-   - Are policy controls enforcing the floor?
-3. **Check the permission model**
-   - Azure RBAC or legacy access policies?
-   - Who can read, write, delete, recover, or purge?
-   - Are roles assigned at the right scope?
-   - Is purge authority too broad?
-4. **Check secret lifecycle hygiene**
-   - Expiration set or missing?
-   - Owner and rotation metadata present?
-   - Tags used for lifecycle metadata rather than stuffing metadata into secret values?
-   - General configuration data incorrectly stored as secrets?
-5. **Check rotation realism**
-   - Is rotation manual, reminder-based, or automated?
-   - Is dual-credential or zero-downtime rotation needed?
-   - Are dependent services updated correctly?
-   - Are failed rotations visible?
-6. **Check monitoring and events**
-   - Near-expiry notifications configured?
-   - Event Grid or other alerting present?
-   - Are alert owners named?
-7. **Check recovery posture**
-   - Can deleted secrets be recovered?
-   - Does the team understand purge consequences?
-   - Do they know that some integrated services or subscriptions may need recreation after vault recovery?
-8. **Return a go / no-go style secret-lifecycle verdict**
-   - What is safe,
-   - what is brittle,
-   - what is missing,
-   - and what must change first.
+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
 
-- Reject “it’s in Key Vault, so it’s secure.” Storage location is not lifecycle discipline.
-- Reject any design where humans can purge critical vault assets casually.
-- Reject rotation claims that do not explain how dependent systems receive the new secret.
-- Reject “we monitor expiry” if the team cannot name the alert path, owner, and escalation.
-- Reject vault designs storing feature flags or generic configuration as secrets.
-- Reject recovery confidence if soft delete or purge protection is missing or misunderstood.
-- Reject audits that inspect secret values when metadata would answer the question safely.
-- Reject broad `Key Vault Administrator` usage as a default operational model.
+- `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 Key Vault Secret Lifecycle Audit: <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 risk:
-- Evidence level: live evidence / documentation-based / sanitized evidence / inference
+## Response discipline
 
-## Scope
-- Vault(s):
-- Environment:
-- Dependent workloads:
-- Permission model:
-
-## Findings
-| Area | Finding | Severity | Evidence | Recommendation | Owner |
-|---|---|---|---|---|---|
-
-## Lifecycle control review
-| Control area | Expected state | Observed state | Gap | Blocking |
-|---|---|---|---|---|
-| Soft delete |  |  |  |  |
-| Purge protection |  |  |  |  |
-| RBAC / purge authority |  |  |  |  |
-| Expiration metadata |  |  |  |  |
-| Rotation process |  |  |  |  |
-| Eventing / alerts |  |  |  |  |
-| Recovery readiness |  |  |  |  |
-
-## Safe next actions
-1.
-2.
-3.
-
-## Open questions
--
-```
-
-## Red Flags
-
-- The team wants an audit but refuses to separate secrets, keys, and certificates.
-- Secret rotation is claimed, but nobody can explain how consumers adopt new values.
-- Purge protection is absent for critical vaults or encryption dependencies.
-- Broad administrator roles exist where narrower secrets roles would suffice.
-- The audit relies on secret contents instead of safer metadata.
-- The team assumes vault recovery restores every dependent integration automatically.
+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-keyvault-certificate-issuer-review/SKILL.md

@@ -4,8 +4,8 @@ description: Use this skill when reviewing Azure Key Vault certificate issuer co
 allowed-tools: Read Grep Glob
 metadata:
   author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-05"
+  version: 0.1.4
+  updated: "2026-06-05"
   category: security
 ---
 
@@ -23,13 +23,17 @@ Review Azure Key Vault configurations used as certificate issuers for cert-manag
 - Check Key Vault network access configuration: if `publicNetworkAccess: Disabled`, verify the AKS cluster has private endpoint access to the Key Vault and DNS resolution via private DNS zone. Flag missing private endpoint as MEDIUM.
 - For integrated CAs (DigiCert, GlobalSign): verify the Key Vault has the CA integration configured and the credential secret is scoped to a minimum (single certificate profile, not account-wide).
 - Review cert-manager `renewBefore` against the Key Vault certificate's auto-rotation policy to detect overlapping rotation windows. Flag simultaneous rotation triggers as MEDIUM.
-- Label all findings as live evidence, documentation-based, or inference.
+- Label all findings as sampled configured-environment evidence, documentation-based, or inference.
 
 ## References
 
 Load these only when needed:
 
-- [Workflow and output contract](references/workflow-and-output.md)
+- [Azure Key Vault Certificate Issuer Operations](references/keyvault-certificate-issuer-operations.md) — use for current service behavior, common failure modes, hard design rules, verification targets, and push-back conditions.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, risk gates, mutation boundaries, approval rules, credential boundaries, and current-state caveats.
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only evidence, or sanitized user evidence.
+- [Official sources](references/official-sources.md) — use when you need the detailed Microsoft documentation list or source notes.
+- [Workflow and output contract](references/workflow-and-output.md) — execution flow and final response contract.
 
 ## Response minimum
 

package/skills/azure/azure-keyvault-certificate-issuer-review/metadata.json

@@ -3,18 +3,25 @@
   "name": "Azure Key Vault Certificate Issuer Review",
   "type": "skill",
   "provider": "azure",
-  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
-  "summary": "Review Azure Key Vault certificate issuer configurations for cert-manager, covering certificate policy alignment, Managed Identity authorization scope, exportability posture, private endpoint connectivity, integrated CA credential scoping, and cert-manager vs Key Vault auto-rotation race conditions.",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Azure Key Vault certificate issuer configurations for cert-manager and AKS, covering certificate policy alignment, managed identity authorization scope, exportability posture, private endpoint connectivity, issuer credential scoping, and renewal timing.",
   "source_type": "original",
   "official_docs": [
-    "https://learn.microsoft.com/en-us/azure/key-vault/certificates/about-certificates",
-    "https://learn.microsoft.com/en-us/azure/key-vault/certificates/certificate-scenarios",
-    "https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles/security",
-    "https://learn.microsoft.com/en-us/azure/key-vault/general/network-security"
+    "https://learn.microsoft.com/azure/key-vault/certificates/about-certificates",
+    "https://learn.microsoft.com/azure/key-vault/certificates/how-to-integrate-certificate-authority",
+    "https://learn.microsoft.com/azure/key-vault/certificates/create-certificate",
+    "https://learn.microsoft.com/azure/key-vault/certificates/secure-certificates"
   ],
-  "security_notes": "Key Vault Contributor role assigned to cert-manager allows deletion of the Key Vault, management policy changes, and purge of soft-deleted certs — a full management plane compromise. Use Key Vault Certificate Officer (data plane RBAC) instead. Exportable certificates allow private key extraction from Key Vault; use non-exportable certs for cluster-internal mTLS.",
-  "last_verified": "2026-05-02",
+  "security_notes": "Use Key Vault certificate data-plane roles for certificate lifecycle tasks and avoid broad management-plane roles. Treat exportable private keys, unscoped CA requester credentials, missing renewal contacts, and untested renewal handoff as high-risk.",
+  "last_verified": "2026-06-06",
   "path": "skills/azure/azure-keyvault-certificate-issuer-review",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.4"
 }

package/skills/azure/azure-keyvault-certificate-issuer-review/references/keyvault-certificate-issuer-operations.md

@@ -0,0 +1,68 @@
+# Azure Key Vault Certificate Issuer 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
+
+- Assigning management-plane contributor access when only certificate data-plane lifecycle operations are needed.
+- Ignoring that a certificate also creates backing key and secret objects.
+- Allowing exportable private keys for cluster-internal mTLS without a specific need.
+- Letting cert-manager and Key Vault renewal policies race without a clear owner of renewal timing.
+- Treating integrated CA setup as safe without checking requester credential scope and contacts.
+
+## Officially grounded service shape
+
+Microsoft Learn evidence says a Key Vault certificate creates addressable key and secret objects, has a policy that controls issuer, key properties, exportability, lifetime actions, and renewal behavior, and can use integrated issuers such as DigiCert and GlobalSign. Exportability controls whether private key material can be retrieved from the backing secret. Certificate contacts and Event Grid support lifecycle notification, and RBAC should separate certificate lifecycle permissions from broader vault administration.
+
+- A Key Vault certificate policy defines subject/SANs, key properties, exportability, secret content type, lifetime actions, issuer, and validation type.
+- Integrated issuers can automate renewal for supported CAs; nonintegrated CAs require different renewal automation or manual process.
+- Certificate lifecycle events need contacts or event routing to accountable responders.
+- Private endpoint and DNS posture determine whether AKS workloads can reach a locked-down vault.
+- RBAC decisions must distinguish control plane, data plane, certificate, secret, and purge/recover operations.
+
+## Non-negotiable design rules
+
+- Prefer the least data-plane certificate role required; do not grant broad vault administration to cert-manager by default.
+- Flag exportable certificates when private key extraction is unnecessary for the workload.
+- Validate issuer object, certificate policy, lifetime action, contacts, and CA credential scope together.
+- Check AKS network path and private DNS before declaring a private vault usable.
+- Never request private keys, PFX content, CA passwords, or requester credentials in chat.
+
+## Minimal safe implementation flow
+
+- Scope the certificate issuer, Key Vault, AKS cluster, managed identity, namespaces, and certificate consumers.
+- Review policy fields: issuer, key type/size, exportable, reuse key on renewal, SANs, lifetime action, enabled state, and tags.
+- Review RBAC and network evidence without exposing credentials or private key material.
+- Compare cert-manager renewBefore behavior against Key Vault lifetime action and owner expectations.
+- Return severity-labeled findings with source labels and safe remediation path.
+
+## High-risk assumptions to kill
+
+- Certificate data-plane work does not require broad Key Vault or resource-group management-plane access by default.
+- A Key Vault certificate is also backed by key and secret objects; certificate review must include private-key retrieval and backing-secret implications.
+- `exportable` certificates are dangerous for mTLS and internal trust unless private-key extraction is explicitly required and audited.
+- Integrated CA renewal does not remove the need for contacts, lifecycle events, owner response, and failed-renewal handling.
+- Private endpoint enabled on the vault is insufficient unless AKS DNS, firewall, and egress paths are proven for the issuer workflow.
+
+## Safe command/code verification targets
+
+- Inspect certificate policy JSON or IaC for issuer, subject/SANs, key type/size, exportable, reuse-key-on-renewal, lifetime actions, secret content type, and enabled state.
+- Review role assignments for certificate lifecycle permissions separately from secret, key, purge, and management-plane permissions.
+- Check cert-manager issuer manifests or automation for managed identity binding, namespace scope, renewal timing, and absence of embedded CA credentials.
+- Verify Key Vault network definitions include private endpoint, private DNS zone links, firewall posture, and AKS egress compatibility.
+- Confirm monitoring covers certificate near-expiry, expiry, renewal success/failure, export operations, delete/recover/purge events, and accountable responders.
+
+## Safe verification targets
+
+- Managed identity has only required certificate operations, not broad vault delete or purge authority.
+- Certificate policies align with organizational issuer, key, exportability, and validity standards.
+- Renewal contacts/events exist and route to an accountable owner.
+- Private endpoint, firewall, and DNS path match the AKS connectivity model.
+- Rollback plan exists for failed renewal, wrong issuer, or bad private DNS change.
+
+## When to push back
+
+- The request asks to export private keys without a documented break-glass need.
+- The identity has broad Contributor or Administrator posture and the user wants to accept it as fine.
+- Issuer credentials are account-wide or unmanaged.
+- No owner can explain whether Key Vault or cert-manager owns the next renewal event.

package/skills/azure/azure-keyvault-certificate-issuer-review/references/mcp-and-evidence.md

@@ -0,0 +1,26 @@
+# Documentation and Evidence Path
+
+## Preferred evidence order
+
+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.
+
+## What each evidence type can prove
+
+- 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.
+
+## Safe usage pattern
+
+- 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.
+
+## Asset guidance
+
+Use Microsoft Learn documentation through the user's configured documentation MCP for documented Key Vault certificate behavior. Use sampled read-only Azure evidence only for certificate policy, issuer, RBAC, network, and renewal observations; never request private keys or CA account secrets.

package/skills/azure/azure-keyvault-certificate-issuer-review/references/official-sources.md

@@ -0,0 +1,28 @@
+# Official Sources
+
+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/certificates/about-certificates
+- https://learn.microsoft.com/azure/key-vault/certificates/secure-certificates
+- https://learn.microsoft.com/azure/key-vault/certificates/overview-renew-certificate
+- https://learn.microsoft.com/azure/key-vault/certificates/tutorial-rotate-certificates
+- https://learn.microsoft.com/azure/key-vault/certificates/how-to-integrate-certificate-authority
+- https://learn.microsoft.com/azure/key-vault/certificates/how-to-export-certificate
+- https://learn.microsoft.com/azure/key-vault/general/rbac-guide
+- https://learn.microsoft.com/azure/key-vault/general/network-security
+
+## Grounding notes
+
+- Documentation-based claim: Microsoft Learn evidence says a Key Vault certificate creates addressable key and secret objects, has a policy that controls issuer, key properties, exportability, lifetime actions, and renewal behavior, and can use integrated issuers such as DigiCert and GlobalSign. Exportability controls whether private key material can be retrieved from the backing secret. Certificate contacts and Event Grid support lifecycle notification, and RBAC should separate certificate lifecycle permissions from broader vault administration.
+- 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-keyvault-certificate-issuer-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
+
+Use Key Vault certificate data-plane roles for certificate lifecycle tasks and avoid broad management-plane roles. Treat exportable private keys, unscoped CA requester credentials, missing renewal contacts, and untested renewal handoff as high-risk.