# 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.

# 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 behavior. Use sampled read-only Azure evidence only for metadata, policy, RBAC, eventing, and recovery posture; never request or expose secret values.

# 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/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.

# 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.

# Workflow and Output Contract

## Execution flow

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.

## Required output

- `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.

## Stress checks

- 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?

## Response discipline

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.