@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

package/skills/azure/azure-cost-optimization-governor/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: azure-cost-optimization-governor
-description: Review Azure spend governance, budgets, alerts, cost analysis visibility, reservation and savings-plan awareness, tagging for cost allocation, exports, and FinOps ownership with official Microsoft documentation and Azure MCP evidence where available.
+description: Review Azure spend governance, budgets, alerts, cost analysis visibility, reservation and savings-plan awareness, tagging for cost allocation, exports, and FinOps ownership with official Microsoft documentation and sampled read-only Azure evidence where available.
 allowed-tools: Read Grep Glob
 metadata:
   author: github: Raishin
-  version: 0.1.0
-  updated: "2026-05-05"
+  version: 0.1.3
+  updated: "2026-06-05"
   category: finops
 ---
 
@@ -16,10 +16,10 @@ metadata:
 Act as a ruthless Azure cost optimization governor. Your job is to stop vague FinOps theater, missing ownership, and fake savings claims before they become budget drift. Force exact scope, billing boundary, owner, timeframe, tagging posture, visibility gaps, and control maturity before recommending changes.
 
 Default access posture:
-- Prefer detected official Azure MCP tools when available.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP; use sampled cost or recommendation evidence only when the active client exposes a relevant read-only path.
 - Otherwise work from official Microsoft documentation and user-provided sanitized evidence.
 - Never ask the user to paste secrets, billing exports with customer data, credentials, tokens, tenant secrets, or account identifiers into chat.
-- Do not hard-code MCP server names, subscriptions, management groups, billing accounts, resource groups, storage accounts, or automation identities.
+- Do not hard-code environment-specific identifiers, billing scopes, resource groups, storage accounts, or automation identities.
 
 ## Trigger Situations
 
@@ -34,7 +34,7 @@ Use this skill when the user asks to:
 
 ## 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.
 - Challenge broad access, broad scope, destructive changes, and hand-wavy production claims.
 - Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
@@ -43,7 +43,9 @@ Use this skill when the user asks to:
 
 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/cost-optimization-governance.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.
 - [Official sources](references/official-sources.md) — use when you need the detailed Microsoft documentation list or source notes.
 

package/skills/azure/azure-cost-optimization-governor/metadata.json

@@ -20,13 +20,16 @@
     "https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/reporting-get-started",
     "https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/tutorial-improved-exports",
     "https://learn.microsoft.com/en-us/azure/advisor/advisor-reference-cost-recommendations",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-pricing",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-advisor"
+    "https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/overview-cost-management",
+    "https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/cost-mgt-best-practices",
+    "https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/tutorial-acm-opt-recommendations",
+    "https://learn.microsoft.com/en-us/azure/advisor/advisor-workbook-cost-optimization",
+    "https://learn.microsoft.com/en-us/azure/cost-management-billing/savings-plan/decide-between-savings-plan-reservation",
+    "https://learn.microsoft.com/en-us/azure/cost-management-billing/savings-plan/purchase-recommendations"
   ],
   "security_notes": "Do not promise savings without utilization evidence, treat budgets as alerts rather than enforcement, keep billing and export data sanitized, and require named ownership for alerts, tags, exports, and optimization follow-up before calling the FinOps posture credible.",
-  "last_verified": "2026-04-27",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-cost-optimization-governor",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.3"
 }

package/skills/azure/azure-cost-optimization-governor/references/cost-optimization-governance.md

@@ -0,0 +1,62 @@
+# Azure cost optimization governance
+
+## What people get wrong
+
+- They chase potential savings before establishing cost visibility, ownership, and clean allocation.
+- They buy reservations or savings plans before right-sizing and removing idle resources.
+- They treat budgets as hard controls when they are primarily alerts and automation triggers.
+- They add Advisor recommendation totals together even though recommendation datasets can overlap.
+- They optimize one subscription while shared services, logs, networking, and commitments sit elsewhere.
+
+## Officially grounded service shape
+
+Microsoft Learn frames Cost Management as an ongoing organizational practice with planning, visibility, accountability, optimization, and iteration. Cost data can be analyzed through Cost Analysis, exports, APIs, budgets, tags, management groups, and dimensions. Advisor and Cost Optimization workbooks expose recommendations, while reservations and savings plans are rate-optimization tools that require stable usage and careful sequencing.
+
+## Non-negotiable design rules
+
+1. Establish cost scope, billing model, owners, and reporting dimensions before optimization.
+2. Enforce allocation tags and reporting conventions where they drive accountability.
+3. Use budgets and alerts with named response owners.
+4. Remove waste and right-size before purchasing commitments.
+5. Treat Advisor and workbook recommendations as leads, not orders.
+6. Validate actual savings after implementation.
+7. Require approval and rollback for any action that changes runtime state or financial commitment.
+
+## Minimal safe implementation flow
+
+1. Map billing/resource hierarchy and cost ownership.
+2. Validate Cost Analysis views, exports, budgets, tags, dimensions, and alert recipients.
+3. Build a sanitized top-cost and trend view by service, owner, environment, and region.
+4. Review idle, oversized, scheduling, retention, and architecture opportunities.
+5. Review rate optimization only after baseline usage is clean.
+6. Turn recommendations into owner-approved work items with impact, rollback, and measurement.
+7. Reconcile realized savings against actual cost data after the billing cycle.
+
+## High-risk assumptions to kill
+
+- Budgets alert; they do not inherently stop spend unless connected automation and ownership exist.
+- Advisor recommendations are leads, not guaranteed savings, and recommendation totals can overlap or be operationally unsafe.
+- Commitment purchases are dangerous before idle waste, rightsizing, and usage stability are proven.
+- Tag coverage is not allocation quality if owners, environments, applications, or inherited tags are inconsistent.
+- Cost exports and billing data can contain sensitive business context; do not request raw dumps in chat.
+
+## Safe command/code verification targets
+
+- Inspect budget definitions for scope, thresholds, forecast/actual triggers, recipients, action groups, and named response owner.
+- Review export definitions and report pipelines for dataset type, destination, schedule, retention, sanitization, and downstream access controls.
+- Check dashboards or queries for top services, owner/environment dimensions, amortized versus actual views, commitment utilization, and anomaly trends.
+- Verify optimization tickets include expected impact, operational risk, approval, rollback, and post-billing-cycle measurement.
+- Confirm reservation or savings-plan recommendations are backed by stable utilization windows and do not double-count rightsizing or deletion savings.
+
+## Safe verification targets
+
+- Budget thresholds, recipients, action groups, and runbook response.
+- Cost exports: actual, amortized, FOCUS, price sheet, reservation, and recommendation datasets where appropriate.
+- Top services, anomalous growth, idle resources, underutilized commitments, and log/storage retention.
+- Tag coverage and allocation quality by owner/environment/application.
+- Advisor recommendations with overlap and feasibility review.
+- Before/after actuals for implemented optimizations.
+
+## When to push back
+
+Push back on savings guarantees, blind resource deletion, unowned recommendations, raw billing data requests, immediate commitment purchases, or optimization plans without measurement and rollback.

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