@raishin/vanguard-frontier-agentic 2.8.0 → 2.9.0

package/skills/azure/azure-cost-optimization-governor/references/mcp-and-evidence.md

@@ -1,30 +1,27 @@
-# MCP and Evidence Path
+# MCP and evidence path for Azure cost optimization governance
 
-## Official Azure MCP Linkage
+Use Microsoft Learn documentation through the user's configured documentation MCP as the first grounding path for Azure service behavior. This file defines evidence boundaries; it must not imply that documentation proves the user's tenant, subscriptions, RBAC, quotas, billing agreement, deployed resources, or production readiness.
 
-Use official Azure MCP servers as configured in the active runtime. Do not hard-code the server name; users may register the official Azure MCP server under any label. Detect by exposed tool capability and package identity hints, not by fixed server naming.
+## Evidence ladder
 
-Preferred official Azure MCP capability for this role:
+1. `docs_only`: Microsoft Learn documentation and official architecture guidance. Use for documented behavior, caveats, and safe review criteria.
+2. `sampled_read_only`: configured-environment evidence from read-only tools, if available and explicitly scoped. Use only for the sampled resource/time window.
+3. `user_supplied`: sanitized outputs, IaC, diagrams, billing summaries, or metrics provided by the user. Treat as unverified unless independently checked.
+4. `mutation_ready`: documentation plus current-state evidence plus explicit approval, blast-radius statement, and rollback path.
 
-- `pricing` for retail pricing, deployment-cost estimation, and pricing comparisons.
-- `advisor` for live cost recommendation posture and optimization candidates.
-- `quota` only when quota posture materially affects reservation, sizing, or cost-governance decisions.
+## Rules
 
-If the expected Azure MCP tools are missing or ambiguous, ask only which configured MCP server exposes the official Azure tools. Do not ask for secrets, raw billing exports, subscription dumps, credentials, or tokens.
+- Do not expose environment-specific implementation details in committed docs or user-facing guidance.
+- Do not ask for credentials, tokens, tenant identifiers, subscription identifiers, billing account identifiers, connection strings, private keys, customer data, or raw secrets.
+- If current-state evidence was not sampled, say `not sampled`; do not imply it.
+- If evidence is representative or partial, say so. A sample does not prove broad regional availability, billing accuracy, policy compliance, or production readiness.
+- Prefer read-only evidence before mutation planning. Stop for approval before write operations.
 
-Do not invent unsupported MCP tools. If a live need exceeds confirmed Azure MCP capability, switch to documentation mode and say so.
+## Final-answer evidence language
 
-## Platform-Agnostic Execution
+Use phrases like:
 
-This skill must work on macOS, Windows, Linux, browser-first clients, and MCP-only clients. Prefer Azure MCP evidence. When portal checks, CLI, PowerShell, Bicep, or automation examples are useful, show neutral command or workflow shape with `<placeholders>` and adapt only after the user's active platform is known.
-
-## Documentation Fallback When Live Data Is Unavailable
-
-Live Azure MCP data beats documentation. If live data is unavailable, incomplete, denied, or unsafe to query, switch to documentation/reference mode:
-
-- Use Microsoft Learn Cost Management and Billing documentation for cost-governance behavior, budget mechanics, cost-analysis visibility, exports, and optimization framing.
-- Use Microsoft Learn Azure Advisor guidance for recommendation categories and cost-saving posture.
-- Use Microsoft Learn Azure MCP documentation only to describe confirmed official MCP capabilities, not to invent runtime access or tenant state.
-- Ask for sanitized screenshots, cost-analysis views, redacted export samples, tag dictionaries, ownership matrices, or redacted budget definitions when current-state evidence is required.
-- Label every conclusion as `live evidence`, `documentation-based`, `user-provided sanitized evidence`, or `inference`.
-- Do not pretend documentation proves current spend, current savings opportunity, or current reservation coverage.
+- "Based on Microsoft Learn documentation..."
+- "Configured-environment evidence was not sampled in this review."
+- "The following is an inference from the provided configuration, not proven live state."
+- "This recommendation is mutation-ready only after explicit approval and rollback review."

package/skills/azure/azure-cost-optimization-governor/references/official-sources.md

@@ -1,14 +1,23 @@
-# Official Sources
+# Official sources for Azure Cost Optimization Governor
 
-## References
+Use Microsoft Learn documentation through the user's configured documentation MCP before recommending Azure cost optimizations. Documentation proves tool behavior and best practices; it does not prove the user's utilization, commitment coverage, budget ownership, or actual savings.
 
-Load these only when needed, following progressive disclosure:
+## Primary Microsoft Learn sources
 
-- [Plan to manage Azure costs](https://learn.microsoft.com/en-us/azure/cost-management-billing/understand/plan-manage-costs) — use for baseline cost-governance posture, budgets, alerts, pricing, and optimization framing.
-- [Tutorial: Create and manage budgets](https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/tutorial-acm-create-budgets) — use for budget scope, thresholds, forecast alerts, and evaluation behavior.
-- [Azure landing zone governance design area](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/governance) — use when cost controls must be anchored in broader Azure governance ownership, scope, and policy operating model.
-- [Get started with Cost Management reporting](https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/reporting-get-started) — use for cost analysis visibility, reporting limits, and scope-aware analysis workflow.
-- [Tutorial: Create and manage Cost Management exports](https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/tutorial-improved-exports) — use for export automation, datasets, storage delivery, and recurring reporting workflows.
-- [Cost recommendations - Azure Advisor](https://learn.microsoft.com/en-us/azure/advisor/advisor-reference-cost-recommendations) — use when challenging waste, idle capacity, or optimization recommendation quality.
-- [Azure pricing tools for the Azure MCP Server](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-pricing) — use when cost estimation, pricing lookup, or template-based pricing evidence is needed through official Azure MCP tooling.
-- [Azure Advisor tools for the Azure MCP Server overview](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-advisor) — use when live Advisor-backed cost recommendation evidence is available through Azure MCP.
+| Source | Review implication |
+| --- | --- |
+| [How to optimize your cloud investment with Cost Management](https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/cost-mgt-best-practices) | Use for planning, visibility, accountability, cost analysis, exports, budgets, APIs, savings plans, reservations, and iteration. |
+| [What is Microsoft Cost Management](https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/overview-cost-management) | Ground Cost Management capabilities and Advisor as first stop for optimization recommendations. |
+| [Create and manage budgets](https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/tutorial-acm-create-budgets) | Use for budget thresholds and alerting; budgets inform and automate actions, they are not hard spend caps. |
+| [Create and manage Cost Management exports](https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/tutorial-improved-exports) | Use for actual/amortized/FOCUS exports, price sheet, reservation, and recommendation datasets. |
+| [Azure Advisor cost recommendations](https://learn.microsoft.com/en-us/azure/advisor/advisor-reference-cost-recommendations) | Use for recommendation classes and savings opportunities, but verify overlap and current utilization. |
+| [Cost Optimization workbook](https://learn.microsoft.com/en-us/azure/advisor/advisor-workbook-cost-optimization) | Use for Advisor workbook-driven optimization across rate and usage recommendations. |
+| [Savings plan recommendations](https://learn.microsoft.com/en-us/azure/cost-management-billing/savings-plan/purchase-recommendations) | Use for lookback, simulations, stale-data safeguards, and overcommitment risks. |
+| [Decide between a savings plan and a reservation](https://learn.microsoft.com/en-us/azure/cost-management-billing/savings-plan/decide-between-savings-plan-reservation) | Use for right-size-first sequencing and commitment selection. |
+
+## Source-grounding rules
+
+- Do not promise savings; label them as potential until implemented and measured.
+- Do not recommend commitments before waste removal and utilization stability checks.
+- Do not treat budgets as enforcement unless action groups or automation are explicitly designed.
+- Cost exports and cost data can contain sensitive business information; request sanitized summaries only.

package/skills/azure/azure-cost-optimization-governor/references/safety-checklist.md

@@ -0,0 +1,33 @@
+# Safety checklist for Azure Cost Optimization Governor
+
+## Non-negotiable gates
+
+- Never ask for invoices, billing account identifiers, enrollment identifiers, tenant identifiers, subscription identifiers, customer names, or raw exported cost data containing sensitive business details.
+- Do not recommend deleting, resizing, stopping, or changing commitments without owner, impact, rollback, and utilization evidence.
+- Do not purchase or recommend purchase of reservations or savings plans until waste is removed and baseline usage is stable.
+- Treat budgets as alerts/automation triggers, not guaranteed hard stops.
+- Require explicit approval before budget automation, resource shutdown, rightsizing, commitment purchase, export creation, tag enforcement, or policy remediation.
+
+## High-risk assumptions to kill
+
+- "Advisor savings are additive." Recommendation datasets can overlap.
+- "Potential savings equal realized savings." Realized savings require implementation and measurement.
+- "Budgets prevent overruns." They notify and can trigger automation; spend can still accrue.
+- "Commitments fix waste." Discounts reduce rates, not unused resources.
+- "Tags are enough." Tags must be enforced, inherited where appropriate, and used by reporting owners.
+
+## Evidence labels
+
+- `docs_only`: Microsoft Learn guidance only.
+- `cost_sample`: sanitized Cost Management/Advisor/export evidence reviewed.
+- `owner_confirmed`: resource or cost center owner confirmed action scope.
+- `savings_validated`: before/after actuals prove realized savings.
+- `mutation_ready`: approval, impact, rollback, and monitoring are documented.
+
+## Minimum safe evidence
+
+- Scope, billing model, management group/subscription/resource-group boundaries, and reporting owners.
+- Budget thresholds, alert recipients, action groups, and response runbook.
+- Cost analysis views, exports, dimensions, tags, and chargeback model.
+- Advisor recommendations with overlap analysis and owner review.
+- Utilization history before rightsizing or commitment decisions.

package/skills/azure/azure-cost-optimization-governor/references/workflow-and-output.md

@@ -1,71 +1,39 @@
-# Workflow and Output Contract
+# Workflow and output contract for Azure Cost Optimization Governor
 
-## Safe Workflow
+## Minimal safe workflow
 
-1. **Fix the scope first**: management group, subscription, resource group, billing scope, or mixed; name the decision owner and reporting audience.
-2. **Check visibility before optimization**: confirm cost analysis usage, scope coverage, tag coverage, amortized-versus-actual view awareness, and whether exported data exists for durable reporting.
-3. **Inspect ownership and accountability**: who receives alerts, who approves spend exceptions, who owns tag quality, who acts on Advisor findings, and who reviews recurring exports.
-4. **Review spend controls**: budgets, threshold alerts, forecast alerts, cadence, and whether thresholds are aligned to actual governance response rather than vanity numbers.
-5. **Review optimization evidence**: Advisor cost recommendations, pricing posture, reservation awareness, savings-plan awareness, idle or oversized patterns, and known blind spots.
-6. **Review allocation and reporting quality**: tag strategy, missing owner/cost-center tags, export automation, dataset choice, and downstream reporting consumers.
-7. **Give a prioritized governance verdict**: visibility gaps first, ownership gaps second, control gaps third, optimization actions fourth. Do not reverse that order unless evidence is overwhelming.
+1. Classify the request: spend visibility, budget governance, tagging, exports, rightsizing, rate optimization, or optimization approval.
+2. Ground the review in Microsoft Learn through the user's configured documentation MCP.
+3. Establish scope and evidence: docs only, sanitized cost sample, Advisor recommendation, export schema, or owner-confirmed action.
+4. Separate visibility gaps from savings opportunities.
+5. Rank opportunities: waste removal, rightsizing, scheduling, storage/log retention, reservations, savings plans, and architecture changes.
+6. For each action, require owner, blast radius, rollback, and measurement method.
+7. Return potential savings carefully, never as guaranteed realized savings.
 
-## Role-Specific Stress Checks
-
-- Do not promise savings without utilization or recommendation evidence.
-- Do not confuse price estimation with governance. A pricing quote is not a cost-control operating model.
-- Do not call budgets “enforcement.” Budgets alert; they do not stop resource consumption.
-- Do not ignore actual-versus-amortized cost views when reservations or savings plans matter.
-- Do not accept “we have tags” as success unless tag coverage, consistency, and ownership are real.
-- Do not recommend exports without naming dataset consumers, refresh cadence, storage path ownership, and verification checks.
-- Do not treat Azure Advisor recommendations as self-justifying. Check ownership, feasibility, and risk before calling them savings.
-- Do not accept governance claims when no one owns alerts, no one reviews exports, and no one triages cost anomalies.
-
-## Output Template
+## Output contract
 
 ```markdown
-# Azure Cost Governance Review: <scope>
-
 ## Verdict
-- Status: READY / READY WITH RISKS / NOT READY
-- Biggest cost-governance gap:
-- Evidence level: live evidence / documentation-based / sanitized evidence / inference
+<credible governance | conditional | high-risk | docs-only advisory>
 
-## Scope
-- Billing or resource scope:
-- Owner:
-- Audience:
-- Requested action:
+## Evidence level
+- Documentation: <sources used>
+- Cost evidence: <cost_sample|owner_confirmed|not sampled>
 
-## Visibility and ownership
-| Area | Current state | Risk | Evidence | Recommendation | Owner |
-|---|---|---|---|---|---|
-| Cost analysis |  |  |  |  |  |
-| Budgets and alerts |  |  |  |  |  |
-| Tags for cost |  |  |  |  |  |
-| Exports and reporting |  |  |  |  |  |
-| Reservation and savings-plan awareness |  |  |  |  |  |
-| Advisor and optimization review |  |  |  |  |  |
+## Findings
+1. <finding> — Evidence: <docs_only|cost_sample|owner_confirmed|inference>
 
-## Prioritized controls
-1.
-2.
-3.
+## Optimization backlog
+| Priority | Action | Evidence needed | Risk | Owner |
+| --- | --- | --- | --- | --- |
 
-## Safe next actions
-1.
-2.
-3.
+## Guardrails
+- <budget/export/tag/policy control>
 
-## Open questions
--
+## Safe next actions
+- <least-risk next step>
 ```
 
-## Red Flags
+## Pushback triggers
 
-- The request asks for “cost optimization” but no scope owner, budget owner, or reporting audience exists.
-- The answer claims savings based only on pricing pages or intuition, without usage evidence, Advisor findings, or documented governance gaps.
-- The design depends on reservations or savings plans but ignores amortized reporting.
-- The team has budgets but no alert recipients with accountability.
-- The team exports data but cannot name who consumes it or how failed exports are detected.
-- The plan depends on tags for cost allocation but tag coverage or ownership is unknown.
+Push back on unowned recommendations, immediate deletion, blind commitment purchases, unsanitized billing data, savings guarantees, or optimization plans without before/after measurement.

package/skills/azure/azure-entra-id-specialist/SKILL.md

@@ -4,8 +4,8 @@ description: Use this skill for Microsoft Entra ID specialist work, especially C
 allowed-tools: Read Grep Glob
 metadata:
   author: github: Raishin
-  version: 0.1.0
-  updated: "2026-05-05"
+  version: 0.1.5
+  updated: "2026-06-05"
   category: security
 ---
 
@@ -51,7 +51,7 @@ If the problem narrows mainly to PIM, access reviews, entitlement management, or
 
 ## Lean operating rules
 
-- Prefer live Azure or Microsoft evidence first when the active client exposes it; otherwise fall back to official documentation and sanitized user evidence.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP, then sampled read-only Azure evidence when the active client exposes it, then sanitized user evidence.
 - Separate confirmed facts from inference. If state was not queried or shown, say so.
 - Treat Microsoft licensing and service entitlement as a first-class constraint; do not imply a control exists for the tenant if the required license or product entitlement is unproven.
 - If the user mentions an adjacent Microsoft service that is not explicitly covered in the current examples, consult official references before concluding feature rights, identity scope, or licensing behavior. The examples in this skill are anchors, not the limit of the role.
@@ -62,7 +62,9 @@ If the problem narrows mainly to PIM, access reviews, entitlement management, or
 
 Load these only when needed:
 
-- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing live Azure evidence, confirming Microsoft MCP capability, or switching to documentation mode.
+- [Operations guide](references/entra-id-identity-operations.md) — use for service-specific pitfalls, design rules, verification targets, and pushback criteria.
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only Azure evidence, or sanitized user evidence.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, risk gates, mutation boundaries, approval rules, credential boundaries, and current-state caveats.
 - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, applying stress checks, or formatting the final answer.
 - [Licensing and service entitlements](references/licensing-and-service-entitlements.md) — use when Conditional Access, PIM, ID Protection, Workload ID, Microsoft 365 bundles, Microsoft Fabric examples, or cross-service feature rights are in scope.
 - [Adjacent Microsoft service expansion](references/adjacent-service-expansion.md) — use when the user brings up another Microsoft service and you need to learn the identity, entitlement, or licensing relationship before answering.

package/skills/azure/azure-entra-id-specialist/metadata.json

@@ -1,7 +1,7 @@
 {
   "id": "azure-entra-id-specialist",
   "name": "Azure Entra ID Specialist",
-  "version": "0.1.0",
+  "version": "0.1.5",
   "type": "skill",
   "provider": "azure",
   "harnesses": [
@@ -15,19 +15,22 @@
   "summary": "Review and guide Microsoft Entra ID tenant posture across conditional access, authentication methods, MFA and SSPR registration, identity protection, workload identities, app registrations, external identities, governance boundaries, and least-privilege identity operations with explicit evidence-versus-inference handling.",
   "source_type": "original",
   "official_docs": [
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/overview",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/concepts",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/",
     "https://learn.microsoft.com/en-us/entra/fundamentals/what-is-entra",
     "https://learn.microsoft.com/en-us/entra/id-governance/identity-governance-overview",
     "https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure",
     "https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-security-info-registration",
     "https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-users-groups",
     "https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview",
-    "https://learn.microsoft.com/en-us/entra/id-protection/concept-workload-identity-risk"
+    "https://learn.microsoft.com/en-us/entra/id-protection/concept-workload-identity-risk",
+    "https://learn.microsoft.com/en-us/entra/agent-id/security-for-ai-overview",
+    "https://learn.microsoft.com/en-us/entra/agent-id/what-is-microsoft-entra-agent-id",
+    "https://learn.microsoft.com/en-us/entra/id-governance/agent-id-governance-overview",
+    "https://learn.microsoft.com/en-us/entra/fundamentals/security-defaults",
+    "https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/best-practices",
+    "https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access"
   ],
   "security_notes": "Do not recommend broad exclusions, unsafe break-glass patterns, blanket MFA bypasses, overprivileged app registrations, or risky Conditional Access changes without scoping blast radius, role ownership, and recovery paths.",
-  "last_verified": "2026-04-28",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-entra-id-specialist",
   "author": "github: Raishin"
 }

package/skills/azure/azure-entra-id-specialist/references/adjacent-service-expansion.md

@@ -111,3 +111,7 @@ Typical checks:
 - “This service uses the same Entra tenant, but that does not by itself prove the needed feature rights.”
 - “This looks like a cross-service licensing question, so I’m grounding it against the service’s official documentation before concluding.”
 - “I can confirm the documented prerequisite, but I cannot confirm your tenant owns that license from the evidence provided.”
+
+## Evidence refresh - 2026-06-04
+
+- Agent identity guidance is now a first-class adjacent-service example: distinguish agent identities, agent users, sponsors, blueprints, Conditional Access for agents, ID Protection for agents, and Microsoft Agent 365 licensing before reusing ordinary human or workload identity conclusions.

package/skills/azure/azure-entra-id-specialist/references/entra-id-identity-operations.md

@@ -0,0 +1,62 @@
+# Microsoft Entra identity operations
+
+## What people get wrong
+
+- They disable security defaults before replacement Conditional Access coverage exists.
+- They make broad Conditional Access exclusions for executives, service accounts, or break-glass without monitoring and compensating controls.
+- They grant permanent privileged roles instead of using PIM and just-in-time activation.
+- They ignore workload identities, app registrations, credentials, and delegated permissions while focusing only on human users.
+- They treat report-only Conditional Access results as proof enforcement is safe for every token path.
+
+## Officially grounded service shape
+
+Microsoft Learn describes security defaults as a basic baseline requiring MFA registration, administrator MFA, protection for privileged Azure Resource Manager access, and blocking of legacy authentication and device code flow. For complex tenants, Conditional Access provides customizable policies. Microsoft guidance also emphasizes PIM for just-in-time privileged roles, MFA for administrators, emergency access accounts, least privilege, backup/recovery, and monitoring of identity governance changes.
+
+## Non-negotiable design rules
+
+1. Keep either security defaults or equivalent Conditional Access coverage active.
+2. Require emergency access accounts and monitoring before risky policy changes.
+3. Prefer PIM eligible assignments over permanent privileged roles.
+4. Minimize exclusions and document owner, reason, expiration, and compensating controls.
+5. Block or phase out legacy authentication and risky flows unless a documented exception exists.
+6. Govern workload identities with owners, least privilege, credential lifecycle, and reviews.
+7. Treat identity configuration changes as high blast-radius mutations.
+
+## Minimal safe implementation flow
+
+1. Identify licensing and whether security defaults or Conditional Access is the active baseline.
+2. Inventory MFA, legacy auth, device code flow, admin access, and emergency access posture.
+3. Review Conditional Access assignments, targets, conditions, grants, sessions, exclusions, and report-only data.
+4. Review privileged roles, PIM settings, activation requirements, alerts, and access reviews.
+5. Review app registrations and workload identities for owners, credentials, grants, and lifecycle.
+6. Stage changes with pilot scope, report-only, break-glass verification, and rollback.
+7. Enforce only after monitoring and support readiness are proven.
+
+## High-risk assumptions to kill
+
+- Disabling security defaults is unsafe unless equivalent Conditional Access coverage, emergency access, monitoring, and support readiness already exist.
+- Report-only Conditional Access is impact evidence, not enforcement proof; token paths, exclusions, app dependencies, and break-glass flows still need testing.
+- Broad block policies can lock out admins, especially when combined with all-resources scope and weak exclusion planning.
+- Workload identities are not covered by user-scoped Conditional Access; service principals, managed identities, and federated credentials need separate review.
+- A control may require specific Entra licensing or service entitlement; do not imply availability from documentation alone.
+
+## Safe command/code verification targets
+
+- Inspect policy-as-code or exported Conditional Access JSON for users/workload identities, target resources, conditions, grants, session controls, state, exclusions, and report-only posture.
+- Review role assignments and PIM configuration for permanent privileged roles, activation duration, MFA, approval, notifications, and access reviews.
+- Check app registrations and service principals for owners, credential type, credential age, federated credentials, API permissions, consent grants, and sign-in/risk logs.
+- Verify emergency access accounts are excluded appropriately, monitored, tested, and not used for routine administration.
+- Confirm final evidence distinguishes documented Microsoft Learn behavior from sampled tenant evidence and unverified licensing assumptions.
+
+## Safe verification targets
+
+- Security defaults state or equivalent Conditional Access baseline.
+- MFA registration and enforcement for users and privileged roles.
+- Legacy authentication and device code flow handling.
+- Emergency access account count, configuration, and alerting.
+- PIM role eligibility, activation duration, approval, MFA, and notifications.
+- Workload identity owners, credentials, permissions, and risk signals.
+
+## When to push back
+
+Push back on disabling defaults, enforcing broad Conditional Access without emergency access, permanent Global Administrator assignments, unowned app registrations, blanket exclusions, or identity recommendations based only on screenshots or assumptions.

package/skills/azure/azure-entra-id-specialist/references/licensing-and-service-entitlements.md

@@ -121,3 +121,7 @@ Use this when the user is designing AI agents and assumes ordinary Entra pattern
 - “Documentation says this feature requires Entra ID P1, but I do not know whether your tenant has that license.”
 - “Business Premium includes Conditional Access, but risk-based Conditional Access depends on P2-backed ID Protection.”
 - “Fabric uses the same Entra tenant, but user rights and capacity rights are separate from Entra feature entitlements.”
+
+## Evidence refresh - 2026-06-04
+
+- Microsoft Learn documents separate prerequisites for agent security features: Conditional Access for agents requires Entra ID P1, ID Protection for agents requires Entra ID P2, ID Governance for agents requires Entra ID P1, and network controls for agents require Global Secure Access licensing. Treat these as documented prerequisites, not proof of tenant entitlement.

package/skills/azure/azure-entra-id-specialist/references/mcp-and-evidence.md

@@ -1,33 +1,27 @@
-# MCP and evidence path
+# MCP and evidence path for Microsoft Entra identity operations
 
-Use this reference only when you need to decide how to gather Entra evidence.
+Use Microsoft Learn documentation through the user's configured documentation MCP as the first grounding path for Azure service behavior. This file defines evidence boundaries; it must not imply that documentation proves the user's tenant, subscriptions, RBAC, quotas, billing agreement, deployed resources, or production readiness.
 
-## Live-first evidence rule
+## Evidence ladder
 
-1. Prefer live Azure MCP capability evidence when the active client exposes Azure tools.
-2. Treat the runtime-exposed tool inventory as truth.
-3. If Entra-specific tooling is not exposed live, say so and switch to documentation-based guidance instead of pretending the namespace exists.
+1. `docs_only`: Microsoft Learn documentation and official architecture guidance. Use for documented behavior, caveats, and safe review criteria.
+2. `sampled_read_only`: configured-environment evidence from read-only tools, if available and explicitly scoped. Use only for the sampled resource/time window.
+3. `user_supplied`: sanitized outputs, IaC, diagrams, billing summaries, or metrics provided by the user. Treat as unverified unless independently checked.
+4. `mutation_ready`: documentation plus current-state evidence plus explicit approval, blast-radius statement, and rollback path.
 
-## Azure MCP grounding
+## Rules
 
-Based on Microsoft documentation:
+- Do not expose environment-specific implementation details in committed docs or user-facing guidance.
+- Do not ask for credentials, tokens, tenant identifiers, subscription identifiers, billing account identifiers, connection strings, private keys, customer data, or raw secrets.
+- If current-state evidence was not sampled, say `not sampled`; do not imply it.
+- If evidence is representative or partial, say so. A sample does not prove broad regional availability, billing accuracy, policy compliance, or production readiness.
+- Prefer read-only evidence before mutation planning. Stop for approval before write operations.
 
-- Microsoft recommends **consolidated mode** for AI agents because it reduces tool count and improves usability.
-- Namespace filtering means a client may expose only a subset of Azure tools.
-- Do not assume that the active client exposes Entra-specific operations just because Microsoft documents broader Azure MCP capabilities.
+## Final-answer evidence language
 
-## Evidence hierarchy
+Use phrases like:
 
-Use this order:
-
-1. **live evidence** — Azure MCP output, sanitized screenshots, sanitized policy exports, sanitized logs, or user-provided config excerpts
-2. **user-provided sanitized evidence** — redacted CA policy summaries, app-registration details, audit logs, sign-in logs, risk events, or screenshots
-3. **documentation-based** — Microsoft Learn and official Azure MCP documentation
-4. **inference** — conclusions derived from patterns but not directly proven by evidence
-
-## Entra caution points
-
-- Do not bless Conditional Access exclusions without explicit break-glass and recovery logic.
-- Do not assume MFA means safe posture if registration, authentication methods, or legacy paths are weak.
-- Do not confuse identity governance controls with full Entra ID security posture.
-- Do not assume workload identities, service principals, or app registrations are low-risk just because they are nonhuman.
+- "Based on Microsoft Learn documentation..."
+- "Configured-environment evidence was not sampled in this review."
+- "The following is an inference from the provided configuration, not proven live state."
+- "This recommendation is mutation-ready only after explicit approval and rollback review."

package/skills/azure/azure-entra-id-specialist/references/official-sources.md

@@ -1,78 +1,31 @@
-# Official sources
+# Official sources for Azure Entra ID Specialist
 
-Use this reference only when you need the detailed source list or need to ground a specific claim.
+Use Microsoft Learn documentation through the user's configured documentation MCP before identity guidance. Documentation proves Microsoft-published behavior; it does not prove the user's tenant posture, licenses, policy state, exclusions, sign-in risk, or break-glass readiness.
 
-## Azure MCP
+## Primary Microsoft Learn sources
 
-- Azure MCP overview
-  https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/overview
-- Azure MCP concepts
-  https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/concepts
-- Azure MCP tools overview
-  https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/
+| Source | Review implication |
+| --- | --- |
+| [Security defaults in Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/fundamentals/security-defaults) | Use for MFA registration, administrator MFA, legacy auth blocking, device code flow blocking, and Conditional Access migration caveats. |
+| [Build a Conditional Access policy](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-policies) | Use for assignments, target resources, network, conditions, grant/session controls, and token-evaluation caveats. |
+| [Common Conditional Access policies](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-policy-common) | Use for secure-foundation templates and baseline policy strategy. |
+| [Best practices for Microsoft Entra roles](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/best-practices) | Ground least privilege, PIM, admin MFA, and privileged-role hygiene. |
+| [Privileged Identity Management](https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure) | Use for eligible roles, just-in-time activation, approval, alerts, and role settings. |
+| [Best practices for securely deploying Microsoft Entra ID Governance](https://learn.microsoft.com/en-us/entra/id-governance/best-practices-secure-id-governance) | Use for least privilege, backup/recovery, monitoring, access reviews, and governance operations. |
+| [Workload identities overview](https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview) | Use for app/service principal/workload identity review. |
+| [Emergency access accounts](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access) | Use for break-glass account design and monitoring. |
 
-## Microsoft Entra ID
+## Source-grounding rules
 
-- What is Microsoft Entra?
-  https://learn.microsoft.com/en-us/entra/fundamentals/what-is-entra
-- What is Microsoft Entra ID Governance?
-  https://learn.microsoft.com/en-us/entra/id-governance/identity-governance-overview
-- What is Microsoft Entra Privileged Identity Management?
-  https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure
-- Protect security info registration with Conditional Access policy
-  https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-security-info-registration
-- Conditional Access: Users, groups, agents, and workload identities
-  https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-users-groups
-- What are workload identities?
-  https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview
-- Securing workload identities
-  https://learn.microsoft.com/en-us/entra/id-protection/concept-workload-identity-risk
-- Conditional Access for Agent ID (Preview)
-  https://learn.microsoft.com/en-us/entra/identity/conditional-access/agent-id
-- Manage agent identities in your organization
-  https://learn.microsoft.com/en-us/entra/agent-id/manage-agent-identities-admin
-- Microsoft Entra security for AI overview
-  https://learn.microsoft.com/en-us/entra/agent-id/security-for-ai-overview
-- Microsoft Entra ID Governance licensing fundamentals
-  https://learn.microsoft.com/en-us/entra/id-governance/licensing-fundamentals
-- Microsoft Entra licensing
-  https://learn.microsoft.com/en-us/entra/fundamentals/licensing
-- What is Conditional Access?
-  https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview
-- Features and licenses for Microsoft Entra multifactor authentication
-  https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mfa-licensing
-- What is Microsoft Entra ID Protection?
-  https://learn.microsoft.com/en-us/entra/id-protection/overview-identity-protection
-- Microsoft Entra service description
-  https://learn.microsoft.com/en-us/office365/servicedescriptions/azure-active-directory
+- Do not disable security defaults unless replacement Conditional Access coverage is ready.
+- Do not recommend broad exclusions; require explicit named rationale and compensating controls.
+- Do not approve privileged-role changes without PIM, MFA, alerting, and emergency access review.
+- Treat tenant evidence as sensitive; request only sanitized summaries.
 
-## Cross-service licensing examples
+## Current Microsoft Learn deltas checked on 2026-06-05
 
-- Azure integration with Microsoft 365
-  https://learn.microsoft.com/en-us/microsoft-365/enterprise/azure-integration
-- Understand Microsoft Fabric licenses
-  https://learn.microsoft.com/en-us/fabric/enterprise/licenses
-- Buy a Microsoft Fabric subscription
-  https://learn.microsoft.com/en-us/fabric/enterprise/buy-subscription
-- Learn about Conditional Access and Intune
-  https://learn.microsoft.com/en-us/intune/device-security/conditional-access-integration/overview
-- Require device compliance with Conditional Access
-  https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-device-compliance
-- Microsoft Defender service description
-  https://learn.microsoft.com/en-us/office365/servicedescriptions/microsoft-365-service-descriptions/microsoft-365-tenantlevel-services-licensing-guidance/microsoft-defender-service-description
-- Microsoft Entra External ID overview
-  https://learn.microsoft.com/en-us/entra/external-id/external-identities-overview
-- What are workload identities?
-  https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview
-- What is Microsoft Entra?
-  https://learn.microsoft.com/en-us/entra/fundamentals/what-is-entra
+- Conditional Access planning depends on Microsoft Entra licensing; risk-based policies require stronger entitlement evidence than baseline policy design.
+- Emergency access accounts and service principals/service accounts require explicit exclusion or separate control design; do not assume user-scoped Conditional Access safely governs every identity type.
+- Conditional Access for workload identities is scoped to single-tenant service principals in the tenant; do not claim managed identities or multi-tenant SaaS apps are covered without current documentation evidence.
+- Microsoft Entra roles and Azure RBAC roles are separate control planes; never use one evidence set to prove the other.
 
-## Grounded insights used by this skill
-
-- Existing identity governance controls do not prove broader Entra ID posture is sound.
-- Conditional Access and registration controls can create lockout risk if exclusions and emergency access are careless.
-- Workload identities and app registrations need the same least-privilege scrutiny as human admins.
-- Tenant identity, Microsoft 365 bundle rights, and Fabric capacity rights are related but not interchangeable.
-- Adjacent Microsoft services can share the same tenant while still having separate licensing, capacity, or premium-feature gates.
-- Device-compliance Conditional Access can depend on Intune setup and compliance policy existence, not just Entra policy authoring rights.
-- Some ID Protection detections and AI-agent protections depend on adjacent Microsoft services or preview-specific capabilities, not just base Entra branding.

package/skills/azure/azure-entra-id-specialist/references/safety-checklist.md

@@ -0,0 +1,32 @@
+# Safety checklist for Azure Entra ID Specialist
+
+## Non-negotiable gates
+
+- Never ask for tenant identifiers, user lists, object identifiers, tokens, app secrets, certificates, private keys, sign-in logs with personal data, or raw audit exports.
+- Do not recommend disabling security defaults without replacement Conditional Access policies ready to protect the tenant.
+- Do not recommend broad Conditional Access exclusions, blanket MFA bypass, or privileged role permanency without explicit risk acceptance.
+- Require emergency access account design before high-risk Conditional Access or role changes.
+- Require explicit approval before policy enablement, report-only to enforce changes, exclusions, role assignments, app credential changes, or workload identity changes.
+
+## High-risk assumptions to kill
+
+- "MFA exists, so identity is safe." Legacy auth, exclusions, stale sessions, app permissions, and privileged roles still matter.
+- "Report-only policy success means enforce safely." Token timing, excluded paths, break-glass, and app compatibility need checks.
+- "Global Administrator is convenient." It should be rare, monitored, and preferably just-in-time.
+- "Security defaults plus custom needs is enough." Complex tenants generally need Conditional Access.
+- "Service principals are harmless." Workload identities can carry high-impact permissions and secrets.
+
+## Evidence labels
+
+- `docs_only`: Microsoft Learn guidance only.
+- `tenant_sample`: sanitized read-only tenant posture evidence was reviewed.
+- `policy_review`: Conditional Access, PIM, or app registration config was reviewed, not proven live.
+- `change_ready`: emergency access, rollback, approval, and monitoring are documented.
+
+## Minimum safe evidence
+
+- Licensing capability: security defaults vs Conditional Access/PIM/Identity Protection availability.
+- MFA posture, legacy authentication status, security defaults or Conditional Access baseline.
+- Emergency access accounts, monitoring, and exclusion strategy.
+- Privileged roles: active vs eligible, activation controls, alerts, and reviews.
+- Workload identities, app credentials, owner hygiene, and permission grants.