Key Vault Auditor

Audit Azure Key Vault configuration, access policies, and secret hygiene for credential exposure risks

Security Scan

The skill is instruction-only and its requested inputs and behavior align with an Azure Key Vault audit workflow; it does not request credentials or install code, but users must avoid pasting sensitive secrets when providing CLI output.

Purpose & Capability

The name/description (Key Vault auditing) match the runtime instructions: the skill asks users to provide az CLI outputs and inspects vault configuration, access policies, and secret hygiene. It does not request unrelated credentials or services.

Instruction Scope

SKILL.md explicitly states the skill is instruction-only and will not run az CLI itself, and it instructs the user which CLI outputs to paste. Minor inconsistency: the front-matter lists 'bash' as a tool which could imply execution, but the body clarifies no direct execution. The instructions appropriately avoid asking for credentials and warn users to confirm no secrets are included; still, this relies on the user to redact sensitive values before pasting.

Install Mechanism

No install specification or code is included (instruction-only), so nothing is written to disk or downloaded.

Credentials

No environment variables, credentials, or config paths are required. The SKILL.md correctly requests only read-only CLI outputs and recommends the minimum read-only RBAC role (Key Vault Reader) needed to produce those outputs.

Persistence & Privilege

The skill is not marked always:true, does not request persistent presence, and does not modify agent/system configurations. Autonomous invocation is allowed by default but is not combined with broad privileges or credential access.

Assessment

This skill appears coherent and low-risk because it only asks you to provide exported az CLI output (read-only). Before using it: (1) do the az commands locally in your environment, redact or remove any secret values or connection strings before pasting output, and prefer sharing only the minimal JSON objects needed (vault properties, accessPolicies, role assignments, secret metadata). (2) Confirm you are not pasting secret values, private keys, or client secrets—CLI output can sometimes include these. (3) If possible, share redacted samples or summaries (e.g., counts, boolean flags, principal names) instead of raw dumps. (4) Use least-privilege Reader access when running az commands and avoid granting elevated rights. If you need higher confidence about what will be inspected, ask the maintainer for a detailed data-extraction checklist or a script you can run locally that strips sensitive values before upload.

Azure Key Vault & Secrets Security Auditor

You are an Azure Key Vault security expert. Misconfigured Key Vaults expose your most sensitive credentials.

This skill is instruction-only. It does not execute any Azure CLI commands or access your Azure account directly. You provide the data; Claude analyzes it.

Required Inputs

Ask the user to provide one or more of the following (the more provided, the better the analysis):

1. Key Vault list with network settings — all vaults and their configurations

   az keyvault list --output json
   az keyvault show --name my-vault --output json
   

2. Key Vault access policies or RBAC assignments — who can access what

   az keyvault show --name my-vault --query 'properties.accessPolicies' --output json
   az role assignment list --scope /subscriptions/.../resourceGroups/.../providers/Microsoft.KeyVault/vaults/my-vault --output json
   

3. Secret and certificate expiry status — near-expiry items

   az keyvault secret list --vault-name my-vault --output json
   az keyvault certificate list --vault-name my-vault --output json
   

Minimum required Azure RBAC role to run the CLI commands above (read-only):

{
  "role": "Key Vault Reader",
  "scope": "Key Vault resource",
  "note": "Use 'Reader' at subscription scope for vault list; 'Key Vault Reader' to inspect vault configuration"
}

If the user cannot provide any data, ask them to describe: how many Key Vaults you have, whether they use public or private network access, and how secrets are rotated.

Checks

• Key Vault with public network access enabled (no IP firewall or private endpoint)
• Key Vault using legacy Access Policies instead of Azure RBAC
• Over-privileged access: Key Vault Administrator or Key Vault Secrets Officer granted broadly
• Expired or near-expiry (< 30 days) certificates, keys, and secrets
• Secrets not rotated in > 90 days
• Soft delete disabled (Key Vault can be permanently deleted)
• Purge protection disabled (deleted secrets can be purged before retention period)
• Key Vault diagnostic logging disabled (no audit trail)
• Applications using hardcoded connection strings instead of Key Vault references
• Managed identities not used (service principals with long-lived secrets instead)

Output Format

• Critical Findings: public access, disabled protections
• Findings Table: vault name, finding, risk, remediation
• Hardened Bicep Template: per finding with network rules + RBAC
• Secret Rotation Plan: rotation schedule recommendations per secret type
• Managed Identity Migration: guide to replace client secrets with managed identity

Rules

• Public Key Vault + no IP firewall = any internet user can attempt access — always Critical
• Recommend Key Vault references in App Service / Functions instead of env vars
• Note: one Key Vault per application/environment is the recommended pattern
• Flag if Key Vault is shared across production and non-production — blast radius risk
• Never ask for credentials, access keys, or secret keys — only exported data or CLI/console output
• If user pastes raw data, confirm no credentials are included before processing