@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

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.

package/skills/azure/azure-keyvault-certificate-issuer-review/references/workflow-and-output.md

@@ -1,190 +1,30 @@
 # Workflow and Output Contract
 
-## Review Workflow
+## Execution flow
 
-### Step 1 — Identify the cert-manager issuer configuration
+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.
 
-Locate the cert-manager issuer resource that references Azure Key Vault:
+## Required output
 
-```bash
-kubectl get issuer -A -o yaml | grep -A10 "azureKeyVault\|keyVault"
-kubectl get clusterissuer -o yaml | grep -A10 "azureKeyVault\|keyVault"
-```
+- `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.
 
-Extract the Key Vault name and vault URI from the issuer spec. The exact fields depend on the cert-manager Azure issuer plugin in use (e.g., `cert-manager-webhook-azure` or CAPZ-style issuers).
+## Stress checks
 
-### Step 2 — Check Managed Identity role assignment
+- 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?
 
-Identify the Managed Identity or Service Principal used by cert-manager on AKS:
+## Response discipline
 
-```bash
-# Get the cert-manager pod's managed identity annotation
-kubectl get pod -n cert-manager -l app=cert-manager -o jsonpath='{.items[0].metadata.annotations}'
-
-# Or check the ServiceAccount for workload identity annotation
-kubectl get serviceaccount cert-manager -n cert-manager -o jsonpath='{.metadata.annotations}'
-```
-
-Retrieve role assignments on the Key Vault:
-
-```bash
-KV_ID=$(az keyvault show --name <vault-name> --query id -o tsv)
-az role assignment list --scope "$KV_ID" --output table
-```
-
-**Correct role:** `Key Vault Certificate Officer` (data plane only)
-
-Role comparison:
-
-| Role | Plane | Grants | Risk |
-|------|-------|--------|------|
-| `Key Vault Certificate Officer` | Data | Create, update, import, delete certificates | Correct |
-| `Key Vault Certificates Officer` | Data | Same as above (alias) | Correct |
-| `Key Vault Contributor` | Management | Manage vault config, delete vault, change policies | HIGH — management plane access |
-| `Key Vault Administrator` | Data + Management | Full control including purge | HIGH |
-| `Owner` / `Contributor` at subscription | All | Everything | CRITICAL |
-
-### Step 3 — Check RBAC mode vs legacy access policies
-
-```bash
-az keyvault show --name <vault-name> --query properties.enableRbacAuthorization
-```
-
-- `true` — RBAC mode (preferred, auditable via Azure RBAC)
-- `false` or `null` — legacy access policies (harder to audit)
-
-If legacy access policies are in use, check the policy:
-
-```bash
-az keyvault show --name <vault-name> --query properties.accessPolicies
-```
-
-The cert-manager identity should only have `certificates: ["get", "create", "import", "update", "list"]` — not `all` and not management operations.
-
-### Step 4 — Review certificate policy and exportability
-
-```bash
-az keyvault certificate get-default-policy
-az keyvault certificate show --vault-name <vault-name> --name <cert-name>
-```
-
-Key fields in the certificate policy:
-
-```json
-{
-  "x509CertificateProperties": {
-    "subject": "CN=myapp.internal",
-    "validityInMonths": 3,
-    "keyUsage": ["digitalSignature", "keyEncipherment"]
-  },
-  "keyProperties": {
-    "exportable": false,
-    "keyType": "RSA",
-    "keySize": 2048,
-    "reuseKey": false
-  },
-  "issuerParameters": {
-    "name": "Self"
-  }
-}
-```
-
-**Flags:**
-- `exportable: true` on a cert used for cluster-internal mTLS — MEDIUM (private key extractable)
-- `keySize < 2048` for RSA or `keySize < 256` for EC — HIGH (weak key)
-- `validityInMonths > 12` for workload certs — MEDIUM (excessive validity)
-
-Note: Non-exportable certs require the application to use Key Vault SDK or CSI driver for key operations, not just cert retrieval. Confirm application capability before enforcing non-exportable.
-
-### Step 5 — Review Key Vault network access
-
-```bash
-az keyvault show --name <vault-name> --query properties.networkAcls
-az keyvault show --name <vault-name> --query properties.publicNetworkAccess
-```
-
-If `publicNetworkAccess: Disabled`:
-
-```bash
-# Check for private endpoint
-az network private-endpoint list \
-  --query "[?privateLinkServiceConnections[?groupIds[0]=='vault']].{name:name,subnet:subnet.id}" \
-  --output table
-
-# Check for private DNS zone
-az network private-dns zone list --query "[?contains(name,'vaultcore')]" --output table
-```
-
-For AKS access to Key Vault:
-- AKS cluster VNet must be peered with or the same as the VNet hosting the private endpoint
-- Private DNS zone `privatelink.vaultcore.azure.net` must be linked to the AKS cluster VNet
-- Outbound traffic from cert-manager pod must route through the private endpoint
-
-**Flags:**
-- Key Vault with public access from internet and no firewall restrictions — MEDIUM
-- Key Vault with `publicNetworkAccess: Disabled` but missing private endpoint — HIGH (cert issuance will fail)
-- No private DNS zone link to AKS VNet (DNS resolution fails for private endpoint) — HIGH
-
-### Step 6 — Review integrated CA configuration (if applicable)
-
-For DigiCert or GlobalSign integrated CAs:
-
-```bash
-az keyvault certificate issuer show --vault-name <vault-name> --issuer-name DigiCert
-```
-
-Check that the issuer credential secret is stored in Key Vault and scoped to a minimum profile:
-
-```bash
-az keyvault secret show --vault-name <vault-name> --name DigiCert-issuer-creds
-```
-
-**Flags:**
-- Integrated CA credentials that have account-wide issuance scope (not single profile) — MEDIUM
-- Integrated CA credentials stored outside Key Vault (e.g., in a Kubernetes Secret) — MEDIUM
-
-### Step 7 — Review rotation race condition
-
-cert-manager rotation schedule:
-```bash
-kubectl get certificate <name> -n <namespace> -o jsonpath='{.spec.duration} {.spec.renewBefore}'
-```
-
-Key Vault auto-rotation policy:
-```bash
-az keyvault certificate get-default-policy | jq '.lifetimeActions'
-```
-
-A `lifetimeAction` of type `AutoRenew` triggers Key Vault to request a new cert from the issuer. If cert-manager's `renewBefore` window overlaps with the Key Vault auto-renewal trigger (both fire within the same rotation window), both may attempt to renew simultaneously, causing a temporary version mismatch.
-
-**Mitigation:** Disable Key Vault auto-rotation for certs managed by cert-manager, or ensure the Key Vault auto-renewal threshold is set beyond the cert-manager `renewBefore` window.
-
----
-
-## Output Format
-
-### Finding: `<short title>`
-
-| Field | Value |
-|-------|-------|
-| Severity | CRITICAL / HIGH / MEDIUM / LOW |
-| Resource | Key Vault name, role assignment, cert name, or policy field |
-| Evidence | documentation-based / live evidence / inference |
-| Description | What is wrong and its impact |
-| Remediation | Azure CLI command, policy JSON, or configuration change |
-
----
-
-### Overall Posture
-
-| Category | Status |
-|----------|--------|
-| Managed Identity role (data plane only) | PASS / FAIL |
-| RBAC mode (not legacy policies) | PASS / FAIL |
-| Certificate exportability | PASS / FAIL |
-| Key Vault network access | PASS / FAIL |
-| Certificate validity periods | PASS / FAIL |
-| Integrated CA credential scope | PASS / N/A / FAIL |
-| Rotation policy alignment | PASS / FAIL |
-
-**Verdict:** TRUSTED / UNTRUSTED / CONDITIONAL (list conditions)
+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.