# MCP and evidence path

Use this reference when deciding how to ground `azure-security-posture-hardening` guidance.

## Evidence order

1. Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior.
2. Sampled read-only Azure evidence when the user has configured it and current-state confirmation is necessary.
3. Sanitized user-provided evidence when no read-only evidence path is available.
4. Clearly labeled inference when evidence is incomplete.

## Boundaries

- Documentation evidence does not prove the user's tenant, subscription, RBAC, quotas, deployed resources, billing state, security posture, reliability state, or production readiness.
- Sampled read-only evidence proves only the sampled configured environment and time window.
- User-provided evidence can be incomplete or stale; preserve uncertainty.
- Never ask for credentials, tokens, secrets, tenant IDs, subscription IDs, resource IDs, customer data, private keys, or raw incident payloads.

## Required phrasing

Use generic phrasing such as "Microsoft Learn documentation through the user's configured documentation MCP". Do not expose internal tool names, profile names, environment names, or local identifiers in committed docs.

# Official sources

Use this reference when grounding current Azure behavior for `azure-security-posture-hardening`.

## Microsoft Learn sources

- https://learn.microsoft.com/azure/key-vault/general/secure-key-vault
- https://learn.microsoft.com/security/benchmark/azure/baselines/key-vault-security-baseline
- https://learn.microsoft.com/security/benchmark/azure/baselines/microsoft-defender-for-cloud-security-baseline
- https://learn.microsoft.com/azure/defender-for-cloud/recommendations-reference-identity-access
- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/security
- https://learn.microsoft.com/azure/governance/policy/overview
- https://learn.microsoft.com/azure/role-based-access-control/best-practices
- https://learn.microsoft.com/azure/defender-for-cloud/secure-score-security-controls
- https://learn.microsoft.com/azure/defender-for-cloud/concept-cloud-security-posture-management
- https://learn.microsoft.com/azure/defender-for-cloud/review-security-recommendations

## Current documentation refresh (2026-06-05)

- Microsoft Learn documentation through the user's configured documentation MCP is the primary source for documented Azure behavior.
- Documentation evidence is not live customer-state evidence. It does not prove the user's tenant, subscription, RBAC, quotas, deployed resources, billing state, security posture, or production readiness.
- Use sampled read-only Azure evidence only when the user has configured it and the task requires current-state confirmation. Label it as sampled evidence, not broad proof.

## Grounding rule

Docs explain service behavior. Current-state claims require sampled read-only evidence or sanitized user-provided evidence. If current state was not queried or shown, say so.

# Safety checklist

Use before recommending production Azure changes, access grants, security remediation, hierarchy moves, cost actions, reliability changes, or readiness conclusions for `azure-security-posture-hardening`.

## Non-negotiables

- Do not ask for or print credentials, client secrets, certificates, private keys, access tokens, tenant IDs, subscription IDs, resource IDs, customer data, raw incident payloads, or environment-specific identifiers.
- Prefer Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior.
- Use sampled read-only Azure evidence only for current-state claims and label it as sampled evidence.
- Require explicit approval before recommending live mutation, broad access, destructive remediation, billing changes, commitment purchases, hierarchy moves, failover, failback, or alert suppression.
- Keep recommendations least-privilege, reversible where possible, and scoped to the named resource or workload.
- Separate documentation-based claims, sampled evidence, user-provided evidence, and inference.

## Component risks

- **Identity and roles:** broad privileged roles, direct user grants, wildcard custom roles, missing PIM/time-bound controls, inherited scope surprises.
- **Security posture:** stored secrets, public exposure, missing managed identities, weak Key Vault boundaries, no diagnostic coverage, untracked policy exemptions.
- **Resource organization:** flat hierarchy drift, fake isolation via resource groups, subscription sprawl, weak ownership, policy inheritance surprises.
- **Cost:** optimizing recommendations without workload context, deleting resources without owner confirmation, buying commitments before rightsizing, ignoring licensing and reliability cost tradeoffs.
- **Reliability:** vague SLOs, untested recovery, overengineered topology, missing health model, no dependency mapping, unvalidated chaos or failover assumptions.

## Evidence labels

Use `documentation-based`, `sampled read-only evidence`, `repo evidence`, `user-provided evidence`, or `inference`. Documentation alone never proves the user's live Azure environment.

# Azure Security Posture Hardening Operations

> Version note: Azure service behavior and tooling change over time. Verify exact command syntax, permissions, and feature availability against Microsoft Learn documentation through the user's configured documentation MCP before production use. Do not paste secrets or sensitive identifiers into commands, files, or chat.

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

- Calling a workload hardened because it has a Key Vault.
- Using stored service-principal secrets when managed identities are supported.
- Keeping Key Vault public access or legacy access policies without justification.
- Treating Defender recommendations as optional noise instead of risk signals to triage.
- Skipping diagnostics and audit logs until after an incident.

## Officially grounded service shape

- Microsoft Learn Key Vault guidance implements Zero Trust principles: verify explicitly, use least privilege, and assume breach.
- Key Vault hardening includes one vault per application/region/environment where appropriate, private access or firewall controls, Azure RBAC over legacy access policies for critical workloads, PIM for privileged operations, soft delete, purge protection, rotation, logging, Defender, policy enforcement, and backup/recovery testing.
- Security baselines call out managed identities, Azure Policy audit/deny/deploy-if-not-exists effects, Defender for Cloud monitoring, conditional access where supported, and secure storage of credentials in Key Vault.
- Documentation-based security recommendations do not prove the user has enabled these controls. Current-state posture needs sampled read-only evidence.

Documentation evidence proves documented Azure service behavior. It does not prove the user's tenant, subscription, RBAC, quotas, deployed resources, billing state, security posture, or production readiness.

## Non-negotiable design rules

- Prefer managed identities over stored secrets where the service supports them.
- Use Azure RBAC, least privilege, and PIM/time-bound elevation for privileged operations.
- Disable public exposure or restrict network access where workload requirements allow it.
- Require diagnostic logs, alerts, and policy compliance evidence before calling posture audit-ready.
- Stage remediation and avoid broad production changes without rollback and owner approval.

## Minimal safe implementation flow

- Scope workload, data sensitivity, identities, secrets, public exposure, policies, logging, and production impact.
- Collect documentation requirements and sampled posture evidence when available.
- Classify gaps by identity, network, secret lifecycle, policy, monitoring, and backup/recovery risk.
- Prioritize reversible least-privilege remediations before disruptive controls.
- Return hardened target state, blockers, safe rollout sequence, verification checks, and residual risk.

## High-risk assumptions to kill

- Secure score equals production readiness; it is an input, not a substitute for owner-reviewed risk acceptance.
- A Defender recommendation is false positive noise until triaged; unreviewed recommendations are unbounded risk debt.
- Enabling a paid plan, policy, or deny effect is automatically safe; it can affect cost, deployment paths, and operations.
- A Key Vault exists, therefore secrets are safe; network access, RBAC model, purge protection, diagnostics, and rotation still matter.
- Documentation guidance proves current posture; it only proves documented service behavior unless sampled evidence confirms the environment.

## Safe command/code verification targets

- Query Defender secure score controls and recommendations read-only, then label results as sampled current-state evidence.
- Review policy assignments, exemptions, and compliance states before recommending deny or deploy-if-not-exists effects.
- Inspect identity usage, Key Vault access model, network settings, soft delete, purge protection, rotation, and diagnostic settings without exposing secrets.
- Verify log destinations and alert ownership; an enabled diagnostic setting with no owner is not audit readiness.
- Separate documentation evidence, sampled read-only evidence, and sanitized user evidence in the final verdict.

## Safe verification targets

- Managed identities or approved credential model are used for service access.
- Key Vault RBAC, network controls, soft delete, purge protection, rotation, and diagnostics match sensitivity.
- Policy assignments or Defender recommendations cover required controls and exemptions are justified.
- Audit logs and alerts reach an owned destination.
- Remediation has rollback or staged deployment plan.

## When to push back

- The user wants public access because private networking is inconvenient.
- The plan stores credentials in repo, pipeline files, or app settings without a secure reference.
- The request skips logging or Defender/Policy evidence.
- The remediation would break production without staged validation.

# Workflow and output contract

Use this reference for full execution of `azure-security-posture-hardening`.

## Workflow

1. **Classify the request**
   - Identify service/domain, resource scope, environment, production impact, and whether mutation or billing impact is requested.
   - Identify whether the task needs documentation-only guidance, sampled read-only current-state evidence, or sanitized user evidence.

2. **Ground in current sources**
   - Prefer Microsoft Learn documentation through the user's configured documentation MCP.
   - Read the component operations guide before issuing design, safety, or readiness conclusions.
   - Treat current-state claims as unproven unless supported by sampled read-only evidence or sanitized user-provided evidence.

3. **Stress-test the plan**
   - Kill broad permissions, vague ownership, missing rollback, missing validation, and unsupported production-readiness claims.
   - Separate facts from inference.
   - State blockers before recommendations.

4. **Recommend minimal safe action**
   - Prefer read-only inspection, preview, what-if, diagnostic query, cost forecast, or staged rollout before mutation.
   - Require explicit approval for live, destructive, access, reliability, hierarchy, or billing-impacting actions.
   - Keep the recommendation scoped and reversible where possible.

5. **Validate and hand off**
   - Name verification targets and evidence gaps.
   - Provide safe next actions and escalation criteria.
   - Do not claim tenant, subscription, resource, billing, quota, or posture state that was not observed.

## Output contract

Return:

1. Scope and target
2. Evidence level: documentation-based, sampled read-only evidence, user-provided evidence, repo evidence, or inference
3. Key findings and risks
4. Blockers or missing evidence
5. Minimal safe next actions
6. Verification targets
7. Rollback, cleanup, expiry, or reversal path where applicable