# MCP and evidence path

Use this reference to choose the right evidence path without leaking environment details.

## 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 posture matters.
3. Sanitized user-provided evidence when read-only evidence is unavailable.
4. Explicit inference only when evidence is incomplete.

## What each evidence type proves

- Microsoft Learn proves documented Azure service behavior, Well-Architected guidance, and Microsoft security recommendations.
- Sampled read-only Azure evidence can prove observed configuration or API results in the configured environment at the time sampled.
- User-provided evidence proves only what the user provided, and only if identifiers and secrets are sanitized.
- Inference is not proof; label it and keep recommendations conditional.

## What evidence does not prove

- Documentation does not prove the user's tenant, subscriptions, RBAC, quotas, deployed resources, billing state, security posture, or production readiness.
- Sampled read-only evidence does not prove broad regional availability, all accounts, all subscriptions, all resources, or future posture.
- Secure score, compliance state, and recommendation counts do not prove risk acceptance, owner readiness, or incident-response capability.

## Safe phrasing

- “Microsoft Learn documentation through the user's configured documentation MCP says...”
- “Sampled current-state evidence shows...”
- “The current state was not queried, so this remains an assumption.”
- “This recommendation is documentation-based and needs environment validation before production change.”

# Official sources

Use this reference when grounding current Azure behavior for `azure-waf-security-review`.

## Microsoft Learn sources

- https://learn.microsoft.com/azure/well-architected/security/principles
- https://learn.microsoft.com/azure/well-architected/security/checklist
- https://learn.microsoft.com/azure/well-architected/security/establish-baseline
- https://learn.microsoft.com/azure/well-architected/security/secure-development-lifecycle
- https://learn.microsoft.com/azure/well-architected/security/threat-model
- https://learn.microsoft.com/azure/well-architected/security/data-classification
- https://learn.microsoft.com/azure/well-architected/security/segmentation
- https://learn.microsoft.com/azure/well-architected/security/identity-access
- https://learn.microsoft.com/azure/well-architected/security/networking
- https://learn.microsoft.com/azure/well-architected/security/encryption
- https://learn.microsoft.com/azure/well-architected/security/harden-resources
- https://learn.microsoft.com/azure/well-architected/security/application-secrets
- https://learn.microsoft.com/azure/well-architected/security/monitor-threats
- https://learn.microsoft.com/azure/well-architected/security/test
- https://learn.microsoft.com/azure/well-architected/security/incident-response
- https://learn.microsoft.com/security/benchmark/azure/introduction
- https://learn.microsoft.com/azure/defender-for-cloud/concept-regulatory-compliance
- https://learn.microsoft.com/azure/defender-for-cloud/secure-score-security-controls
- 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.
- Secure score, regulatory compliance, and MCSB mappings help prioritize controls, but they do not replace workload-specific threat modeling, ownership, testing, and incident response evidence.

## 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 Azure workload security reviews, hardening recommendations, policy/Defender changes, identity changes, network exposure decisions, incident-response claims, or production-readiness statements.

## Non-negotiables

- Do not ask for or print credentials, tokens, secrets, tenant IDs, subscription IDs, resource IDs, customer data, private keys, or raw incident payloads.
- Keep the default mode read-only and advisory.
- Require explicit approval before changing Entra ID, Conditional Access, RBAC, PIM, Azure Policy, Defender plans, Sentinel connectors, network controls, Key Vault settings, or production diagnostics.
- Prefer managed identities and least privilege over stored secrets and broad standing privilege.
- Separate Microsoft Learn documentation evidence from sampled read-only Azure evidence and sanitized user evidence.
- Do not call a workload secure unless evidence covers identity, segmentation, data, secrets, logging, threat detection, vulnerability management, and incident response.
- Treat paid-plan, preview, manual, and shared-responsibility controls as caveated evidence.

## Component risks

- **Identity and access:** broad Owner/Contributor grants, weak Conditional Access, standing privilege, unmanaged workload identities, stale service principals.
- **Segmentation and networking:** public ingress, uncontrolled egress, flat networks, missing Private Link DNS review, NSG/firewall rules without owners.
- **Data protection:** unclassified data, unmanaged keys, missing audit trails, untested backup/recovery security, exfiltration paths.
- **Secrets:** secret values in code, app settings, pipelines, logs, tickets, or chat; missing rotation and emergency rotation.
- **Policy and compliance:** broad deny effects without safe deployment, stale exemptions, compliance dashboards used as proof without control review.
- **Threat monitoring:** unowned alerts, missing diagnostic settings, weak log retention, disconnected SecOps process.
- **DevSecOps:** no threat model, no SAST/dependency/IaC/image scanning, findings without SLA or release gate.
- **Incident response:** paper runbooks, unclear owner, no tabletop, no recovery security validation.

## Evidence labels

Use `documentation-based`, `sampled current-state evidence`, `repo evidence`, `user-provided evidence`, or `inference`. Documentation alone never proves the user's live Azure posture.

# Azure WAF Security Operations

> Version note: Azure service behavior and tooling change over time. Verify exact command syntax, permissions, feature availability, and recommendation semantics 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

- Treating a generic security checklist as proof of workload security.
- Calling secure score, Defender coverage, or policy compliance production readiness without owner-reviewed evidence.
- Equating encryption-at-rest defaults with complete data protection.
- Assuming private endpoints or firewalls fix weak identity, secret handling, or egress paths.
- Skipping threat modeling, secure-development controls, incident-response testing, and recovery security.

## Officially grounded service shape

- Microsoft Learn evidence says Well-Architected security starts from Zero Trust, the CIA triad, and recurring security improvement rather than one-time hardening.
- The Security checklist covers baseline/compliance, secure development lifecycle and threat modeling, data classification, segmentation, strict IAM, network isolation, encryption, resource hardening, application secrets, threat monitoring, security testing, and incident response.
- Microsoft security guidance says to verify explicitly, use least privilege for the right duration and assets, and assume breach with compensating controls that limit blast radius.
- Defender for Cloud can assess resources against security standards such as Microsoft Cloud Security Benchmark, but documentation-based recommendations do not prove the user's configured posture.
- MCSB and Defender compliance evidence can support prioritization, but preview controls, manual/shared responsibilities, exemptions, and paid-plan requirements must be labeled clearly.

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

- Define the workload boundary, data classification, critical flows, compliance drivers, owners, and production impact before judging security.
- Require identity-first access, least privilege, time-bound privileged access, and workload identities before approving sensitive operations.
- Require intentional segmentation across identity, network, resource organization, and data paths; do not treat a single perimeter as sufficient.
- Require evidence for data protection, secret lifecycle, logging, threat monitoring, vulnerability management, and incident response.
- Treat security recommendations as staged risk reduction, not as permission to mutate policies, networking, Defender plans, or identity controls without approval.

## Minimal safe implementation flow

- Scope workload, environments, data sensitivity, critical flows, compliance obligations, owners, and current evidence sources.
- Collect Microsoft Learn documentation requirements and sampled read-only evidence when available for identity, network, data, policy, Defender, logging, secrets, and DevSecOps controls.
- Classify gaps against Security checklist areas: baseline, SDL/threat model, classification, segmentation, IAM, networking, encryption, hardening, secrets, monitoring, testing, and incident response.
- Prioritize fixes by exploitability, business impact, blast radius, reversibility, and owner readiness.
- Return verdict, evidence level, blockers, staged remediation, validation checks, and residual risk.

## High-risk assumptions to kill

- “We use Azure, so default platform security is enough.”
- “Secure score is high, so the workload is secure.”
- “Private networking means attackers cannot reach the workload.”
- “Encryption is enabled, so data protection is complete.”
- “PIM exists, so privileged access is solved.”
- “Defender/Sentinel is connected, so detection and response are ready.”
- “No incidents means no security gaps.”

Those are lazy assumptions.

## Safe command/code verification targets

- Inventory role assignments, privileged access paths, workload identities, Conditional Access dependencies, and secret usage with read-only queries.
- Inspect segmentation evidence across resource organization, network boundaries, ingress, egress, private access, and data flows.
- Review data classification, encryption configuration, key ownership, Key Vault posture, secret rotation, and audit logs without exposing secret values.
- Query Defender recommendations, secure score controls, policy compliance, exemptions, diagnostic settings, alert rules, and log destinations as sampled current-state evidence.
- Check secure-development controls such as threat models, dependency scanning, IaC scanning, image scanning, release gates, and vulnerability triage evidence.
- Verify incident-response runbooks, alert ownership, escalation paths, tabletop/test evidence, and post-incident feedback loops before claiming readiness.

## Safe verification targets

- Security baseline maps to compliance requirements, platform recommendations, and workload-specific threats.
- IAM is strict, conditional, auditable, least-privilege, and time-bound for privileged operations.
- Data is classified and protected with encryption, key ownership, access controls, and audit trails matching sensitivity.
- Network segmentation controls north-south and east-west traffic and has explicit egress handling.
- Threat monitoring, alert routing, vulnerability management, testing, and incident response are owned and exercised.

## When to push back

- The user wants production-ready approval without workload boundary, data classification, or critical-flow context.
- Broad roles, public exposure, static secrets, or unowned alerts are normalized as temporary shortcuts.
- Defender, Sentinel, or policy is cited without current-state evidence and owner follow-up.
- The recommendation would change identity, network, policy, or Defender settings without explicit approval, blast-radius review, and rollback plan.

# Workflow and output contract

Use this reference for full Azure Well-Architected Security reviews.

## Workflow

1. **Classify scope**
   - Workload, environment, data sensitivity, critical flows, compliance obligations, owners, and production impact.
   - Identity, network, data, secrets, monitoring, policy, DevSecOps, and incident-response surfaces in scope.

2. **Ground in Microsoft Learn**
   - Use Microsoft Learn documentation through the user's configured documentation MCP for current Well-Architected Security, MCSB, Defender, Policy, Key Vault, Entra, and Azure Monitor guidance.
   - Treat commands and exact feature availability as version-sensitive until verified.

3. **Collect current-state evidence when available**
   - Read-only role assignments, identities, network exposure, Defender recommendations, secure score controls, policy compliance, exemptions, diagnostics, alerting, logs, secrets posture, and vulnerability controls.
   - Do not retrieve secret values or raw customer payloads.

4. **Stress test the posture**
   - Ask what attacker path remains if identity is compromised.
   - Ask what data can be exfiltrated if an app component is compromised.
   - Ask which alerts fire, who owns them, and what runbook executes.
   - Ask what breaks if a deny policy or private endpoint is rolled out too broadly.

5. **Prioritize remediation**
   - Fix broad access, public exposure, secret leakage, missing logs, and unowned alerts before nice-to-have maturity work.
   - Stage disruptive changes and require rollback or safe-deployment plans.

## Output contract

Return:

1. Scoped workload and evidence level
2. Verdict: pass, conditional, or blocked
3. Top security blockers
4. Findings by Security checklist area
5. Safe next actions in priority order
6. Required approvals for any mutation
7. Open questions and assumptions
8. Evidence labels and source notes