@raishin/vanguard-frontier-agentic 2.8.0 → 2.9.0

package/skills/azure/azure-live-cost-budget-action-guard/references/rollback-playbook.md

@@ -1,21 +1,23 @@
 # Rollback Playbook: Azure Live Cost Budget Action Guard
 
-## Revert a budget modification
+## Evidence-variable convention
+
+Shell variables in examples are local operator placeholders from an approved change record or already configured shell context. Do not commit real values, and redact them from shared evidence unless disclosure is explicitly approved.
+
+## Budget update rollback
 
 ```bash
 # Inspect current state before revert
 az consumption budget show -n <BUDGET_NAME>
 
-# Delete and recreate with original values
-az consumption budget delete -n <BUDGET_NAME>
-
+# Re-apply the original budget values without deleting the budget when possible
 az consumption budget create \
   -n <BUDGET_NAME> \
   --amount <ORIGINAL_AMOUNT> \
   --time-grain <Monthly|Quarterly|Annually> \
   --start-date <YYYY-MM-01> \
   --end-date <YYYY-MM-01> \
-  --notification <KEY=VALUE pairs from original>
+  --notification $ORIGINAL_NOTIFICATION_FIELDS_JSON
 ```
 
 ## Remove a runaway action group from a budget
@@ -38,3 +40,8 @@ az consumption budget create -n <BUDGET_NAME> \
 - Spend that already occurred before the budget alert triggered cannot be reversed.
 - Deleting a budget does NOT stop any VMs or resources — it only removes the alerting rule.
 - Quota increases, once approved by Microsoft, cannot be reduced below the original limit.
+
+
+## Cost-data latency caveat
+
+Microsoft Learn documents that cost and usage data is typically available within 8-24 hours and budget evaluation runs every 24 hours. A rollback or threshold reduction does not undo spend that already occurred and might not immediately reflect current consumption.

package/skills/azure/azure-live-cost-budget-action-guard/references/safety-checklist.md

@@ -0,0 +1,29 @@
+# Safety Checklist
+
+## Evidence labels
+
+- `documentation-based`: grounded in Microsoft Learn or listed official documentation.
+- `sampled-current-state`: grounded in read-only Azure or Kubernetes observations from the user's configured tools.
+- `user-provided`: grounded in sanitized snippets supplied by the user.
+- `inference`: reasoned from evidence but not directly proven.
+
+## Mutation boundary
+
+- Default to read-only review.
+- Do not perform create, update, delete, rotate, purge, recover, apply, swap, reset, complete, deploy, assign, revoke, deallocate, quota, budget, or policy changes unless the user explicitly asks and approval is clear.
+- Prefer preview, what-if, dry-run, status, describe, list, show, diff, activity-log, and policy evaluation evidence before any mutation.
+
+## Credential and data boundary
+
+- Never ask users to paste credentials, tokens, tenant IDs, subscription IDs, customer data, private keys, kubeconfig contents, CA requester credentials, secret values, connection strings, or raw environment dumps.
+- Summarize sensitive evidence by field presence, control state, and risk; do not reproduce secret material.
+
+## Risk gates
+
+- Stop on ambiguous target, ambiguous principal, missing approval, missing rollback, missing financial owner, or missing asset owner for high-impact assets.
+- Treat broad permissions, permanent privileged access, public exposure, purge authority, destructive deployment behavior, quota increases, budget automation, and production slot swaps as high-risk.
+- Separate documented product behavior from sampled configured-environment evidence.
+
+## Asset-specific hard line
+
+Never approve quota increases, budget threshold raises, automated cost actions, or high-cost SKU provisioning without explicit financial owner approval, cost data latency caveat, rollback or stop action, and scope confirmation.

package/skills/azure/azure-live-cost-budget-action-guard/references/workflow-and-output.md

@@ -0,0 +1,33 @@
+# Workflow and Output Contract
+
+## Execution flow
+
+1. Scope the exact target, environment boundary, owner, requested operation, approval state, and rollback owner.
+2. Load `official-sources.md`, then the component operations guide for service behavior and risk gates.
+3. Gather sampled read-only evidence only when available and safe.
+4. Compare observed posture against documented behavior, least-privilege expectations, and live-operation safety rules.
+5. Refuse or defer mutation if target, approval, rollback, or evidence is incomplete.
+6. Return a verdict with evidence level, blockers, safe next actions, and open questions.
+
+## Required output
+
+- `verdict`: pass, warn, fail, or blocked.
+- `evidence_level`: documentation-based, sampled-current-state, user-provided, inference, or mixed.
+- `scope`: what was reviewed and what was not reviewed.
+- `approval_status`: explicit approval, missing approval, or not applicable for read-only review.
+- `blockers`: issues that prevent a safe or production-ready conclusion.
+- `findings`: severity-labeled risks with source labels.
+- `rollback_posture`: exact rollback path or explicit non-reversibility caveat.
+- `safe_next_actions`: reversible actions first; mutation only with explicit approval.
+- `open_questions`: missing facts that would change the verdict.
+
+## Stress checks
+
+- What assumption would make this recommendation unsafe?
+- Which role, policy, budget, quota, deployment, swap, or purge action has the largest blast radius?
+- What evidence would disprove the claimed readiness?
+- Is the answer accidentally treating documentation as environment-specific proof?
+
+## Response discipline
+
+Use Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior. Use sampled read-only Azure evidence only for current configured-environment observations and label it as sampled evidence.

package/skills/azure/azure-live-entra-role-assignment-guard/SKILL.md

@@ -4,8 +4,8 @@ description: Guard live permanent Microsoft Entra ID and Azure RBAC role assignm
 allowed-tools: Read Grep Glob WebFetch
 metadata:
   author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-05"
+  version: 0.1.7
+  updated: "2026-06-05"
   category: security
 ---
 
@@ -25,7 +25,7 @@ Use this skill when:
 
 ## Lean operating rules
 
-- Prefer Azure CLI (`az`) and Microsoft Learn docs when available; fall back to sanitized user evidence.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP; use sampled read-only Azure evidence when available, then sanitized user evidence.
 - Do not create or delete any role assignment until subscription or tenant, active principal, target scope, role, and assignee identity are all explicit.
 - Prefer read-only inspection (`az role assignment list`, `az ad user show`) before any write.
 - Flag the following as high-severity and require explicit justification with business case before proceeding:
@@ -41,10 +41,14 @@ Use this skill when:
 
 Load these only when needed:
 
-- [Preflight commands](references/preflight-commands.md) — Azure CLI commands to inspect current assignments, identity, and scope before any write.
-- [Rollback playbook](references/rollback-playbook.md) — how to remove an assignment and verify access is revoked.
-- [Permission model](references/permission-model.md) — least-privilege role alternatives, dangerous role IDs, and PIM vs permanent guidance.
-- [Official sources](references/official-sources.md) — authoritative Microsoft documentation links.
+- [Azure Entra and RBAC Role Assignment Operations](references/role-assignment-operations.md) — use for current service behavior, common failure modes, hard design rules, verification targets, and push-back conditions.
+- [Preflight commands](references/preflight-commands.md) — CLI commands to run before any mutation.
+- [Rollback playbook](references/rollback-playbook.md) — concrete rollback steps for this service.
+- [Permission model](references/permission-model.md) — RBAC role definitions and PIM guidance.
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only evidence, or sanitized user evidence.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, permanent assignment blast radius, PIM eligibility, guest/service-principal risk, propagation delay, and rollback limits.
+- [Workflow and output contract](references/workflow-and-output.md) — execution flow and final response contract.
+- [Official sources](references/official-sources.md) — authoritative Azure documentation links.
 
 ## Response minimum
 

package/skills/azure/azure-live-entra-role-assignment-guard/metadata.json

@@ -11,18 +11,19 @@
     "kiro",
     "other"
   ],
-  "summary": "Guard live permanent Microsoft Entra ID and Azure RBAC role assignments with scope audit, principal-type risk classification, dangerous-role detection, and explicit approval gates before write.",
+  "summary": "Guard live permanent Microsoft Entra ID and Azure RBAC role assignments with scope audit, principal-type risk classification, dangerous-role detection, PIM preference, propagation caveats, and explicit approval gates before write.",
   "source_type": "original",
   "official_docs": [
-    "https://learn.microsoft.com/en-us/azure/role-based-access-control/overview",
-    "https://learn.microsoft.com/en-us/azure/role-based-access-control/best-practices",
-    "https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles",
-    "https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-alert",
-    "https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure"
+    "https://learn.microsoft.com/azure/role-based-access-control/overview",
+    "https://learn.microsoft.com/azure/role-based-access-control/best-practices",
+    "https://learn.microsoft.com/azure/role-based-access-control/role-assignments-steps",
+    "https://learn.microsoft.com/azure/role-based-access-control/role-assignments-alert",
+    "https://learn.microsoft.com/azure/role-based-access-control/troubleshooting#azure-role-assignments",
+    "https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-deployment-plan"
   ],
-  "security_notes": "Never create Owner, Contributor, or User Access Administrator assignments at subscription or management-group scope without explicit CISO-level justification. Always prefer PIM eligible assignment over permanent. Block any assignment to Guest principals without Director-level sign-off. Token caching means deletion may take up to 5 minutes to propagate.",
-  "last_verified": "2026-05-01",
+  "security_notes": "Never create or delete privileged role assignments without confirmed tenant/scope, assignee identity, principal type, role definition, existing assignment evidence, PIM alternative review, explicit approval, propagation caveat, and rollback command.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-live-entra-role-assignment-guard",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.7"
 }

package/skills/azure/azure-live-entra-role-assignment-guard/references/mcp-and-evidence.md

@@ -0,0 +1,26 @@
+# Documentation and Evidence Path
+
+## Preferred evidence order
+
+1. Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior.
+2. Sampled read-only Azure evidence, when safely available, for current configured-environment observations.
+3. Sanitized user-provided evidence.
+4. Clearly labeled inference.
+
+## What each evidence type can prove
+
+- Microsoft Learn documentation can prove documented service behavior, supported concepts, limitations, and recommended patterns.
+- Sampled read-only evidence can prove the sampled configured state at the time observed.
+- Sanitized user evidence can prove only what the snippet shows.
+- None of these alone prove broad regional availability, future success, full account posture, or production readiness.
+
+## Safe usage pattern
+
+- State whether each claim is documentation-based, sampled-current-state, user-provided, or inference.
+- Use read-only queries before recommending changes.
+- Do not include sensitive internal identifiers, tenant identifiers, subscription identifiers, or secrets in committed docs or final findings.
+- If no sampled evidence is available, say the review is documentation-based and list the exact evidence still needed.
+
+## Live-operation rule
+
+For live operations, documentation is never enough. Require target confirmation, current-state evidence, explicit approval, rollback constraints, and post-action verification.

package/skills/azure/azure-live-entra-role-assignment-guard/references/official-sources.md

@@ -1,21 +1,35 @@
 # Official Sources
 
-Load these only when needed:
-
-- [Azure RBAC overview](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) — use for role assignment model, scope hierarchy (management group → subscription → resource group → resource), and security principal types.
-- [Best practices for Azure RBAC](https://learn.microsoft.com/en-us/azure/role-based-access-control/best-practices) — use for least privilege, group-based assignment, PIM preference, limiting Owner and UAA, and stable role ID usage.
-- [Azure built-in roles](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles) — use when checking whether a narrow built-in role satisfies the requirement before recommending Contributor or Owner.
-- [Alert on privileged role assignments](https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-alert) — use for the Kusto query pattern to detect Owner / Contributor / UAA assignment events in Activity Log.
-- [Entra ID PIM overview](https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure) — use when the permanent assignment request should instead use PIM eligible assignment with JIT activation.
-- [az role assignment CLI reference](https://learn.microsoft.com/en-us/cli/azure/role/assignment) — use for exact `az role assignment create`, `list`, `delete` syntax and parameter options.
-- [Understand role assignments](https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments) — use for role assignment object structure (name, roleDefinitionId, principalId, principalType, scope, condition).
-
-## Grounded insights worth carrying into the skill
-
-- The Azure RBAC API version for role assignments is `2022-04-01` (`Microsoft.Authorization/roleAssignments`).
-- Dangerous role definition IDs (stable — never rename): Owner `8e3af657-a8ff-443c-a75c-2fe8c4bcb635`, Contributor `b24988ac-6180-42a0-ab88-20f7382dd24c`, User Access Administrator `18d7d88d-d35e-4fb5-a5c3-7773c20a72d9`.
-- A permanent role assignment at subscription scope granted to a Guest user is one of the most common post-breach persistence techniques in Azure tenants — always block without explicit CISO-level sign-off.
-- Azure AD token caching means a deleted assignment may still be honored for up to 5 minutes after deletion; do not declare rollback complete immediately.
-- `Microsoft.Authorization/roleAssignments/write` at subscription scope is the permission that enables all downstream privilege escalation — any principal with it can assign themselves Owner.
-- Prefer `az role assignment list --include-inherited` to find assignments at parent scopes that affect the target resource.
-- Microsoft recommends group-based role assignment over direct user assignment to simplify access reviews and offboarding.
+Use these sources to ground the skill. Microsoft Learn documentation proves documented Azure behavior; it does not prove the user's tenant, subscription, RBAC, quota, deployed resources, current cost, vault state, app health, or production readiness.
+
+## Primary Microsoft Learn sources
+
+- https://learn.microsoft.com/azure/role-based-access-control/overview
+- https://learn.microsoft.com/azure/role-based-access-control/best-practices
+- https://learn.microsoft.com/azure/role-based-access-control/role-assignments-steps
+- https://learn.microsoft.com/azure/role-based-access-control/role-assignments-alert
+- https://learn.microsoft.com/azure/role-based-access-control/troubleshooting#azure-role-assignments
+- https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-deployment-plan
+
+## Grounding notes
+
+- Documentation-based claim: Microsoft Learn evidence says Azure RBAC grants who can access Azure resources, what they can do, and where. Best practices require least privilege, narrow scope, limiting privileged administrator roles, assigning to groups where manageable, and using PIM for just-in-time access. Privileged role assignments such as Owner, Contributor, and User Access Administrator are powerful and can be monitored with alerts; role assignment changes can take time to propagate.
+- Current-state claim: requires sampled read-only Azure evidence or sanitized user-provided evidence.
+- Live-operation claim: requires target, principal, approval, preflight evidence, rollback constraints, and post-action verification.
+- Inference: allowed only when labeled and tied to observed fields or documented behavior.
+- Do not include sensitive internal identifiers or secret material in findings.
+
+## Source use rules
+
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP for current Azure service behavior.
+- Use sampled read-only Azure evidence only to validate current configured-environment observations.
+- If documentation and sampled evidence appear to conflict, report both and stop short of a production-ready verdict.
+- Re-check official sources before changing high-risk guidance, because cloud behavior and feature availability can change.
+
+## Current Microsoft Learn deltas checked on 2026-06-05
+
+- Azure RBAC and Microsoft Entra directory roles are different assignment systems with different scopes and tooling.
+- Eligible, time-bound PIM assignment for Azure RBAC is not equivalent for users, service principals, applications, and managed identities; verify supported principal type before recommending PIM as the answer.
+- Built-in Microsoft Entra roles assigned to guests can grant the same role permissions as member users; do not downplay guest-admin blast radius.
+- Administrative-unit-scoped assignments can still need tenant-scope read permissions for some principal types to function.
+

package/skills/azure/azure-live-entra-role-assignment-guard/references/permission-model.md

@@ -1,5 +1,9 @@
 # Permission Model: Azure Live Entra Role Assignment Guard
 
+## Evidence-variable convention
+
+Shell variables in examples are local operator placeholders from an approved change record or already configured shell context. Do not commit real values, and redact them from shared evidence unless disclosure is explicitly approved.
+
 ## Risk classification by role
 
 | Role | Risk | Reason |
@@ -55,7 +59,7 @@
     "Microsoft.Authorization/roleDefinitions/read"
   ],
   "AssignableScopes": [
-    "/subscriptions/<SUBSCRIPTION_ID>"
+    "$APPROVED_AZURE_SCOPE"
   ]
 }
 ```
@@ -68,3 +72,5 @@ Restrict `AssignableScopes` to resource-group scope for operators who should not
 - User Access Administrator at subscription scope (allows re-elevating to Owner)
 - Any Entra directory role (Global Admin, Privileged Role Admin) assigned outside of PIM
 - Service principal with Owner and no owner/contact defined in application registration
+
+Use exact resource scopes from approved change records; do not paste raw subscription identifiers into chat.

package/skills/azure/azure-live-entra-role-assignment-guard/references/preflight-commands.md

@@ -14,19 +14,19 @@ az ad signed-in-user show --query "{displayName:displayName, id:id, userPrincipa
 ```bash
 # Subscription scope
 az role assignment list \
-  --scope "/subscriptions/<SUBSCRIPTION_ID>" \
+  --scope "$APPROVED_AZURE_SCOPE" \
   --include-inherited \
   --query "[].{role:roleDefinitionName, principal:principalName, principalType:principalType, scope:scope}"
 
 # Management group scope
 az role assignment list \
-  --scope "/providers/Microsoft.Management/managementGroups/<MG_ID>" \
+  --scope "$APPROVED_MANAGEMENT_GROUP_SCOPE" \
   --include-inherited \
   --query "[].{role:roleDefinitionName, principal:principalName, principalType:principalType, scope:scope}"
 
 # Resource group scope
 az role assignment list \
-  --resource-group <RESOURCE_GROUP> \
+  --resource-group $AZURE_RESOURCE_GROUP_NAME \
   --include-inherited \
   --query "[].{role:roleDefinitionName, principal:principalName, principalType:principalType, scope:scope}"
 ```
@@ -35,17 +35,17 @@ az role assignment list \
 
 ```bash
 # For a user
-az ad user show --id <UPN_OR_OBJECT_ID> \
+az ad user show --id $ASSIGNEE_LOOKUP_VALUE \
   --query "{displayName:displayName, userPrincipalName:userPrincipalName, userType:userType, accountEnabled:accountEnabled}"
 
 # userType: "Guest" = external account, elevated risk. Always flag.
 
 # For a service principal
-az ad sp show --id <APP_ID_OR_OBJECT_ID> \
+az ad sp show --id $SERVICE_PRINCIPAL_LOOKUP_VALUE \
   --query "{displayName:displayName, appId:appId, servicePrincipalType:servicePrincipalType}"
 
 # For a managed identity
-az identity show --name <IDENTITY_NAME> --resource-group <RG> \
+az identity show --name $MANAGED_IDENTITY_NAME --resource-group $AZURE_RESOURCE_GROUP_NAME \
   --query "{name:name, principalId:principalId, tenantId:tenantId}"
 ```
 
@@ -54,7 +54,7 @@ az identity show --name <IDENTITY_NAME> --resource-group <RG> \
 ```bash
 # Find Owner and UAA at subscription scope (Kusto alternative via activity log)
 az role assignment list \
-  --scope "/subscriptions/<SUBSCRIPTION_ID>" \
+  --scope "$APPROVED_AZURE_SCOPE" \
   --query "[?roleDefinitionName=='Owner' || roleDefinitionName=='User Access Administrator'].{role:roleDefinitionName, principal:principalName, principalType:principalType}"
 ```
 
@@ -62,8 +62,8 @@ az role assignment list \
 
 ```bash
 az role eligibility-schedule list \
-  --scope "/subscriptions/<SUBSCRIPTION_ID>" \
-  --query "[?principalId=='<PRINCIPAL_OBJECT_ID>'].{role:roleDefinitionDisplayName, endDateTime:endDateTime, status:status}"
+  --scope "$APPROVED_AZURE_SCOPE" \
+  --query "[?principalId=='$ASSIGNEE_OBJECT_ID'].{role:roleDefinitionDisplayName, endDateTime:endDateTime, status:status}"
 ```
 
 If an eligible assignment already exists, the correct action is PIM activation, not a new permanent assignment.

package/skills/azure/azure-live-entra-role-assignment-guard/references/role-assignment-operations.md

@@ -0,0 +1,68 @@
+# Azure Entra and RBAC Role Assignment Operations
+
+Use this reference for current, source-grounded service behavior and the hard live-operation gates that the lean `SKILL.md` intentionally does not carry.
+
+## What people get wrong
+
+- Assigning Owner because Contributor failed without diagnosing the missing permission.
+- Granting broad subscription or management-group scope when resource-group or resource scope is enough.
+- Creating permanent assignment when PIM eligible access satisfies the need.
+- Skipping principal-type checks for guests, service principals, and groups.
+- Assuming deletion instantly revokes every cached token.
+
+## Officially grounded service shape
+
+Microsoft Learn evidence says Azure RBAC grants who can access Azure resources, what they can do, and where. Best practices require least privilege, narrow scope, limiting privileged administrator roles, assigning to groups where manageable, and using PIM for just-in-time access. Privileged role assignments such as Owner, Contributor, and User Access Administrator are powerful and can be monitored with alerts; role assignment changes can take time to propagate.
+
+- Azure RBAC assignment combines principal, role definition, and scope.
+- Privileged administrator roles create broad blast radius and should be minimized.
+- PIM can provide time-bound access for Azure resource roles.
+- Alerts can detect privileged role assignment events at subscription scope.
+- Propagation and token caching mean assignment or deletion may not be immediately observed.
+
+## Non-negotiable design rules
+
+- Confirm tenant, subscription, management group/resource scope, principal, role, and active caller before write.
+- Prefer built-in job-function roles and narrow scopes before privileged administrator roles.
+- Require PIM alternative analysis for privileged or temporary need.
+- Classify principal type and external/guest risk before approval.
+- Provide rollback delete command but state propagation caveats.
+
+## Minimal safe implementation flow
+
+- Scope requested role assignment or deletion and business justification.
+- Collect read-only evidence: principal details, existing assignments, target scope, role definition, and PIM eligibility.
+- Classify risk by role power, scope breadth, principal type, duration, and blast radius.
+- Gate mutation on explicit approval and rollback plan.
+- Verify assignment or deletion, alerts/audit trail, and expected propagation window.
+
+## High-risk assumptions to kill
+
+- A role assignment request is not safe because the requester knows the principal name; principal type, ownership, guest status, and stale service-principal risk still matter.
+- Owner, Contributor, User Access Administrator, Privileged Role Administrator, and Global Administrator are not troubleshooting shortcuts.
+- Permanent access is not the default for temporary work; PIM eligibility and activation evidence must be considered first for privileged roles.
+- Removing a role assignment does not prove immediate revocation everywhere because token caching and propagation can delay observable effects.
+- Group-based assignments can hide blast radius unless membership, role-assignable status, and approval process are reviewed.
+
+## Safe command/code verification targets
+
+- Resolve principal, role definition, assignment scope, inherited assignments, and existing eligible/active PIM state before any write.
+- Compare requested role permissions with least-privilege built-in alternatives and narrower scopes.
+- Check whether the request creates standing privileged access, guest/external access, or broad group blast radius.
+- Verify audit log or assignment evidence after change, while labeling propagation and token-cache caveats.
+- Prepare a rollback deletion command and monitoring query before creating privileged access.
+
+## Safe verification targets
+
+- Role is the least privileged role that meets the task.
+- Scope is the narrowest practical scope.
+- Principal type and owner are known and not an unapproved guest or stale service principal.
+- PIM eligible assignment was considered for privileged or temporary access.
+- Privileged assignment monitoring or audit evidence exists.
+
+## When to push back
+
+- The assignee identity or scope is ambiguous.
+- The request wants permanent privileged access for convenience.
+- Guest or broad group assignment lacks documented exception.
+- The user demands immediate revocation proof despite propagation limitations.

package/skills/azure/azure-live-entra-role-assignment-guard/references/rollback-playbook.md

@@ -2,13 +2,17 @@
 
 Permanent role assignments do not expire automatically. Rollback means explicit deletion. Always capture the assignment details before write so deletion is unambiguous.
 
+## Evidence-variable convention
+
+Variables such as $APPROVED_AZURE_SCOPE, $ASSIGNEE_LOOKUP_VALUE, $ROLE_DEFINITION_NAME, $KEY_VAULT_NAME, and $KEY_VAULT_KEY_NAME are local operator placeholders. Do not commit real values, and redact them from shared evidence unless the change record explicitly allows disclosure.
+
 ## Before any assignment write — capture the full assignment for rollback
 
 ```bash
 # Save the exact object ID, role definition ID, and scope
 az role assignment list \
-  --assignee <PRINCIPAL_OBJECT_ID_OR_UPN> \
-  --scope <SCOPE> \
+  --assignee $ASSIGNEE_LOOKUP_VALUE \
+  --scope $APPROVED_AZURE_SCOPE \
   --query "[].{name:name, roleDefinitionId:roleDefinitionId, principalId:principalId, scope:scope}"
 ```
 
@@ -16,31 +20,31 @@ az role assignment list \
 
 ```bash
 az role assignment delete \
-  --ids /subscriptions/<SUBSCRIPTION_ID>/providers/Microsoft.Authorization/roleAssignments/<ASSIGNMENT_NAME>
+  --ids $ROLE_ASSIGNMENT_ID
 ```
 
 ## Remove by role + assignee + scope (if name not captured)
 
 ```bash
 az role assignment delete \
-  --assignee <PRINCIPAL_OBJECT_ID_OR_UPN> \
-  --role "<ROLE_NAME_OR_ID>" \
-  --scope <SCOPE>
+  --assignee $ASSIGNEE_LOOKUP_VALUE \
+  --role "$ROLE_DEFINITION_NAME" \
+  --scope $APPROVED_AZURE_SCOPE
 ```
 
 ## Verify deletion took effect
 
 ```bash
 az role assignment list \
-  --assignee <PRINCIPAL_OBJECT_ID_OR_UPN> \
-  --scope <SCOPE> \
+  --assignee $ASSIGNEE_LOOKUP_VALUE \
+  --scope $APPROVED_AZURE_SCOPE \
   --query "[].{role:roleDefinitionName, scope:scope}"
 # Should return empty or not include the deleted assignment
 ```
 
 ## Caveats
 
-- Token caching: deleted assignments may still appear valid for up to 5 minutes due to Azure AD token caching. Wait before declaring rollback complete.
+- Token caching: deleted assignments may still appear valid for up to 10 minutes due to Azure Resource Manager caching; managed identity group membership can have longer cache behavior. Wait before declaring rollback complete.
 - Inherited assignments: if the assignment was at a parent scope (subscription or management group), removing it at the child scope is not possible — you must delete from the parent scope where it was created.
 - Guest accounts: if the principal is a guest and the assignment was their only entitlement, removal may trigger MFA re-enrollment on next access. Communicate with the affected user.
 - Audit log: the deletion will appear in Azure Activity Log under `Microsoft.Authorization/roleAssignments/delete`. Retain the activity log entry as evidence.

package/skills/azure/azure-live-entra-role-assignment-guard/references/safety-checklist.md

@@ -0,0 +1,29 @@
+# Safety Checklist
+
+## Evidence labels
+
+- `documentation-based`: grounded in Microsoft Learn or listed official documentation.
+- `sampled-current-state`: grounded in read-only Azure or Kubernetes observations from the user's configured tools.
+- `user-provided`: grounded in sanitized snippets supplied by the user.
+- `inference`: reasoned from evidence but not directly proven.
+
+## Mutation boundary
+
+- Default to read-only review.
+- Do not perform create, update, delete, rotate, purge, recover, apply, swap, reset, complete, deploy, assign, revoke, deallocate, quota, budget, or policy changes unless the user explicitly asks and approval is clear.
+- Prefer preview, what-if, dry-run, status, describe, list, show, diff, activity-log, and policy evaluation evidence before any mutation.
+
+## Credential and data boundary
+
+- Never ask users to paste credentials, tokens, tenant IDs, subscription IDs, customer data, private keys, kubeconfig contents, CA requester credentials, secret values, connection strings, or raw environment dumps.
+- Summarize sensitive evidence by field presence, control state, and risk; do not reproduce secret material.
+
+## Risk gates
+
+- Stop on ambiguous target, ambiguous principal, missing approval, missing rollback, missing financial owner, or missing asset owner for high-impact assets.
+- Treat broad permissions, permanent privileged access, public exposure, purge authority, destructive deployment behavior, quota increases, budget automation, and production slot swaps as high-risk.
+- Separate documented product behavior from sampled configured-environment evidence.
+
+## Asset-specific hard line
+
+Never create or delete privileged role assignments without confirmed tenant/scope, assignee identity, principal type, role definition, existing assignment evidence, PIM alternative review, explicit approval, propagation caveat, and rollback command.

package/skills/azure/azure-live-entra-role-assignment-guard/references/workflow-and-output.md

@@ -0,0 +1,33 @@
+# Workflow and Output Contract
+
+## Execution flow
+
+1. Scope the exact target, environment boundary, owner, requested operation, approval state, and rollback owner.
+2. Load `official-sources.md`, then the component operations guide for service behavior and risk gates.
+3. Gather sampled read-only evidence only when available and safe.
+4. Compare observed posture against documented behavior, least-privilege expectations, and live-operation safety rules.
+5. Refuse or defer mutation if target, approval, rollback, or evidence is incomplete.
+6. Return a verdict with evidence level, blockers, safe next actions, and open questions.
+
+## Required output
+
+- `verdict`: pass, warn, fail, or blocked.
+- `evidence_level`: documentation-based, sampled-current-state, user-provided, inference, or mixed.
+- `scope`: what was reviewed and what was not reviewed.
+- `approval_status`: explicit approval, missing approval, or not applicable for read-only review.
+- `blockers`: issues that prevent a safe or production-ready conclusion.
+- `findings`: severity-labeled risks with source labels.
+- `rollback_posture`: exact rollback path or explicit non-reversibility caveat.
+- `safe_next_actions`: reversible actions first; mutation only with explicit approval.
+- `open_questions`: missing facts that would change the verdict.
+
+## Stress checks
+
+- What assumption would make this recommendation unsafe?
+- Which role, policy, budget, quota, deployment, swap, or purge action has the largest blast radius?
+- What evidence would disprove the claimed readiness?
+- Is the answer accidentally treating documentation as environment-specific proof?
+
+## Response discipline
+
+Use Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior. Use sampled read-only Azure evidence only for current configured-environment observations and label it as sampled evidence.

package/skills/azure/azure-live-keyvault-rotation-purge-guard/SKILL.md

@@ -4,8 +4,8 @@ description: Guard Key Vault key rotation, rotation policy changes, soft-delete
 allowed-tools: Read Grep Glob WebFetch
 metadata:
   author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-05"
+  version: 0.1.6
+  updated: "2026-06-05"
   category: security
 ---
 
@@ -25,7 +25,7 @@ Use this skill when:
 
 ## Lean operating rules
 
-- Prefer Azure CLI (`az`) official documentation when available; fall back to Microsoft Learn docs and sanitized user evidence.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP; use sampled read-only Azure evidence when available, then sanitized user evidence.
 - Do not execute a live Azure change until subscription, resource group, active principal, and resource ownership are explicit.
 - Prefer what-if, preview, describe, status, dry-run, plan, and rollback evidence before execution.
 - If the request skips preview or rollback design, push back.
@@ -36,9 +36,13 @@ Use this skill when:
 
 Load these only when needed:
 
+- [Azure Key Vault Rotation and Purge Operations](references/keyvault-rotation-purge-operations.md) — use for current service behavior, common failure modes, hard design rules, verification targets, and push-back conditions.
 - [Preflight commands](references/preflight-commands.md) — CLI commands to run before any mutation.
 - [Rollback playbook](references/rollback-playbook.md) — concrete rollback steps for this service.
 - [Permission model](references/permission-model.md) — RBAC role definitions and PIM guidance.
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only evidence, or sanitized user evidence.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, rotation policy safety, soft-delete state, purge-protection irreversibility, recoverability, backup boundaries, and purge-right separation.
+- [Workflow and output contract](references/workflow-and-output.md) — execution flow and final response contract.
 - [Official sources](references/official-sources.md) — authoritative Azure documentation links.
 
 ## Response minimum

package/skills/azure/azure-live-keyvault-rotation-purge-guard/metadata.json

@@ -11,17 +11,19 @@
     "kiro",
     "other"
   ],
-  "summary": "Guard Key Vault key rotation, rotation policy changes, soft-delete enforcement, and purge-protection enablement with irreversibility warnings and rollback evidence.",
+  "summary": "Guard Key Vault key and secret rotation, rotation policy changes, soft-delete checks, purge-protection enablement, recover decisions, and purge attempts with irreversibility warnings and rollback evidence.",
   "source_type": "original",
   "official_docs": [
-    "https://learn.microsoft.com/en-us/azure/key-vault/general/key-vault-recovery",
-    "https://learn.microsoft.com/en-us/azure/key-vault/keys/about-keys-details",
-    "https://learn.microsoft.com/en-us/azure/key-vault/keys/how-to-configure-key-rotation",
-    "https://learn.microsoft.com/en-us/azure/key-vault/general/best-practices"
+    "https://learn.microsoft.com/azure/key-vault/general/key-vault-recovery",
+    "https://learn.microsoft.com/azure/key-vault/general/soft-delete-overview",
+    "https://learn.microsoft.com/azure/key-vault/general/secure-key-vault",
+    "https://learn.microsoft.com/azure/key-vault/keys/how-to-configure-key-rotation",
+    "https://learn.microsoft.com/azure/key-vault/keys/secure-keys",
+    "https://learn.microsoft.com/azure/key-vault/policy-reference"
   ],
-  "security_notes": "Purge-protection enable is irreversible. Soft-deleted keys can be recovered within the retention window. HSM-backed hard-purged keys cannot be recovered. Never grant purge rights to routine rotation operators.",
-  "last_verified": "2026-04-30",
+  "security_notes": "Purge protection enablement is irreversible, purge is permanent when allowed, and key/secret rotation can break dependent workloads. Never grant purge rights to routine rotation operators or mutate production vault lifecycle controls without owner approval and dependency evidence.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-live-keyvault-rotation-purge-guard",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.6"
 }