@raishin/vanguard-frontier-agentic 1.1.0 → 1.3.0

package/skills/azure/azure-live-cost-budget-action-guard/references/permission-model.md

@@ -0,0 +1,66 @@
+# Permission Model: Azure Live Cost Budget Action Guard
+
+## Custom role — budget read/write, quota read, no VM creation
+
+```json
+{
+  "Name": "Cost Budget Action Guard",
+  "IsCustom": true,
+  "Description": "Read and modify subscription budgets and read compute quotas. Cannot create VMs. Cannot delete budgets.",
+  "Actions": [
+    "Microsoft.Consumption/budgets/read",
+    "Microsoft.Consumption/budgets/write",
+    "Microsoft.CostManagement/budgets/read",
+    "Microsoft.CostManagement/budgets/write",
+    "Microsoft.CostManagement/query/action",
+    "Microsoft.Compute/locations/usages/read",
+    "Microsoft.Compute/locations/vmSizes/read",
+    "Microsoft.Quota/quotas/read",
+    "Microsoft.Quota/usages/read"
+  ],
+  "NotActions": [
+    "Microsoft.Compute/virtualMachines/write",
+    "Microsoft.Compute/virtualMachineScaleSets/write",
+    "Microsoft.Quota/quotas/write",
+    "Microsoft.Consumption/budgets/delete",
+    "Microsoft.CostManagement/budgets/delete"
+  ],
+  "AssignableScopes": [
+    "/subscriptions/<SUBSCRIPTION_ID>"
+  ]
+}
+```
+
+`Microsoft.Quota/quotas/write` is excluded: quota increase requests carry spending risk
+and must go through a separate approval workflow, not this role. VM creation is
+explicitly excluded to prevent the cost guard from becoming a provisioning path.
+
+`Microsoft.Consumption/budgets/delete` and `Microsoft.CostManagement/budgets/delete`
+are excluded: deleting a budget silently removes the only cross-region financial
+guardrail and disables every threshold alert on the subscription. Cleanup of stale or
+test budgets must go through a separate PIM-eligible role with MFA + justification gates.
+
+## Azure Policy guardrail (deploy alongside the role)
+
+Deny GPU VM SKU provisioning without an approved budget tag:
+
+```json
+{
+  "if": {
+    "allOf": [
+      {"field": "type", "equals": "Microsoft.Compute/virtualMachines"},
+      {"field": "Microsoft.Compute/virtualMachines/sku.name", "in": [
+        "Standard_ND96asr_v4", "Standard_NC24rs_v3", "Standard_ND40rs_v2"
+      ]},
+      {"field": "tags.BudgetApproval", "exists": "false"}
+    ]
+  },
+  "then": {"effect": "Deny"}
+}
+```
+
+## Do not assign
+
+- `Cost Management Contributor` at management-group scope
+- `Billing Account Contributor`
+- `Microsoft.Compute/virtualMachines/write` to this role

package/skills/azure/azure-live-cost-budget-action-guard/references/preflight-commands.md

@@ -0,0 +1,48 @@
+# Preflight Commands: Azure Live Cost Budget Action Guard
+
+Run these before any budget modification. Paste sanitized output as evidence.
+
+## 1. Confirm identity and subscription
+
+```bash
+az account show --query "{subscription:id, name:name, user:user.name}"
+```
+
+## 2. List current budgets
+
+```bash
+az consumption budget list --query \
+  "[].{name:name, amount:properties.amount, timeGrain:properties.timeGrain, currentSpend:properties.currentSpend.amount}"
+```
+
+## 3. Inspect a specific budget detail
+
+```bash
+az consumption budget show -n <BUDGET_NAME> \
+  --query "{amount:properties.amount, filter:properties.filter, notifications:properties.notifications}"
+```
+
+## 4. Check current spend vs. budget
+
+```bash
+az costmanagement query \
+  --type ActualCost \
+  --dataset-aggregation '{"totalCost":{"name":"PreTaxCost","function":"Sum"}}' \
+  --timeframe MonthToDate \
+  --scope "/subscriptions/<SUBSCRIPTION_ID>"
+```
+
+## 5. Check compute quota usage before action
+
+```bash
+az vm list-usage -l <LOCATION> \
+  --query "[?contains(name.value,'cores') || contains(name.value,'GPU')].{name:name.localizedValue, current:currentValue, limit:limit}"
+```
+
+## 6. Verify budget action groups are configured
+
+```bash
+az consumption budget show -n <BUDGET_NAME> \
+  --query "properties.notifications"
+# All notification.actionGroups should point to valid Action Group resource IDs
+```

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

@@ -0,0 +1,40 @@
+# Rollback Playbook: Azure Live Cost Budget Action Guard
+
+## Revert a budget modification
+
+```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>
+
+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>
+```
+
+## Remove a runaway action group from a budget
+
+```bash
+# Show notification rules
+az consumption budget show -n <BUDGET_NAME> --query "properties.notifications"
+
+# Update budget to clear action groups on a specific notification key
+az consumption budget create -n <BUDGET_NAME> \
+  --amount <AMOUNT> \
+  --time-grain Monthly \
+  --start-date <DATE> \
+  --end-date <DATE>
+# Re-specify only the notification rules you want to keep
+```
+
+## Rollback limitations
+
+- 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.

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

@@ -0,0 +1,56 @@
+---
+name: azure-live-entra-role-assignment-guard
+description: 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. Use only when a direct (non-PIM) role assignment is intentionally requested against a confirmed target.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# Azure Live Entra Role Assignment Guard
+
+## Purpose
+
+Act as the guarded live Azure operator for azure-live-entra-role-assignment-guard work. Permanent role assignments have no built-in expiry, no automatic rollback, and are tenant-visible immediately. Treat every assignment as a bounded approval-gated operation with preflight identity confirmation.
+
+## When to use
+
+Use this skill when:
+
+- a direct (non-PIM) Entra ID or Azure RBAC role assignment must be created against a confirmed principal and scope
+- an existing assignment must be removed and the downstream access impact must be assessed before deletion
+- a role assignment audit finds over-broad, stale, or guest assignments that must be remediated with least-privilege alternatives
+
+## Lean operating rules
+
+- Prefer Azure CLI (`az`) and Microsoft Learn docs when available; fall back to 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:
+  - Owner, Contributor, or User Access Administrator at subscription or management-group scope
+  - Any role assignment to a Guest principal (external account, highest breach risk)
+  - Any Entra ID directory role (Global Administrator, Privileged Role Administrator, Application Administrator)
+  - Permanent assignments where PIM eligible assignment would satisfy the requirement
+- If the request skips scope confirmation, assignee type verification, or rollback awareness, push back.
+- Never print access tokens, client secrets, tenant IDs, Object IDs without context, or raw environment dumps. Summarize sanitized evidence only.
+- Load references only when needed.
+
+## References
+
+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.
+
+## Response minimum
+
+Return, at minimum:
+
+- confirmed tenant, subscription (if applicable), target scope, and active caller identity
+- preflight evidence: existing assignments on the target scope and current assignee roles
+- principal-type risk classification (member user / guest / service principal / managed identity / group)
+- role risk classification (Owner / Contributor / UAA / custom / narrow built-in)
+- approval status and explicit justification for the assignment
+- rollback posture: the exact `az role assignment delete` command to undo
+- post-assignment verification steps or refusal reason

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

@@ -0,0 +1,28 @@
+{
+  "id": "azure-live-entra-role-assignment-guard",
+  "name": "Azure Live Entra Role Assignment Guard",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "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.",
+  "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"
+  ],
+  "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",
+  "path": "skills/azure/azure-live-entra-role-assignment-guard",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

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

@@ -0,0 +1,21 @@
+# 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.

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

@@ -0,0 +1,70 @@
+# Permission Model: Azure Live Entra Role Assignment Guard
+
+## Risk classification by role
+
+| Role | Risk | Reason |
+|---|---|---|
+| Owner | Critical | Full resource control + can reassign access |
+| User Access Administrator | Critical | Can assign any role to any principal at scope |
+| Contributor | High | Full resource read/write, no access management |
+| Global Administrator | Critical | Tenant-wide Entra ID control, bypasses RBAC |
+| Privileged Role Administrator | Critical | Can assign Entra directory roles including Global Admin |
+| Application Administrator | High | Can create service principals and grant Graph API permissions |
+| Custom roles with `*/write` | High | Broad mutation rights — review assignable scopes |
+| Reader | Low | Read-only — acceptable for most principals |
+| Narrow built-in roles | Low | e.g. Storage Blob Data Reader, Key Vault Secrets User |
+
+## Risk classification by scope
+
+| Scope | Risk |
+|---|---|
+| Management group | Critical — affects all child subscriptions and resource groups |
+| Subscription | High — affects all resources in the subscription |
+| Resource group | Medium — contained to group members |
+| Individual resource | Low — minimal blast radius |
+
+## Risk classification by principal type
+
+| Principal type | Risk | Notes |
+|---|---|---|
+| Guest user (`userType: Guest`) | Critical | External identity, not governed by corporate IdP; highest breach risk |
+| Member user | Medium | Internal — verify employment status and team ownership |
+| Service principal (application) | High | Non-human identity; verify application ownership and client secret rotation policy |
+| Managed identity (system-assigned) | Low-Medium | Scoped to a resource lifecycle; verify the resource owner |
+| Managed identity (user-assigned) | Medium | Shared across resources; verify all attached resources |
+| Group | Medium | Verify group membership is actively governed; avoid open groups |
+
+## Least-privilege guidance
+
+1. **Prefer PIM eligible assignments over permanent.** If the role is needed periodically, PIM with time-bounded activation + MFA + justification is always the correct approach.
+2. **Prefer narrow built-in roles over Contributor/Owner.** Azure has 200+ built-in roles; check whether a service-specific role (e.g. `Monitoring Contributor`, `Key Vault Secrets Officer`) satisfies the requirement.
+3. **Prefer resource-group scope over subscription scope.** Subscription scope is justified only for infrastructure, platform, or governance roles.
+4. **Prefer group-based assignment over direct user assignment.** Groups enable consistent access reviews and offboarding.
+
+## Minimum caller permissions for role assignment operations
+
+```json
+{
+  "Name": "Role Assignment Operator (Guarded)",
+  "IsCustom": true,
+  "Description": "Read role assignments and create new ones at resource-group or lower scope only.",
+  "Actions": [
+    "Microsoft.Authorization/roleAssignments/read",
+    "Microsoft.Authorization/roleAssignments/write",
+    "Microsoft.Authorization/roleAssignments/delete",
+    "Microsoft.Authorization/roleDefinitions/read"
+  ],
+  "AssignableScopes": [
+    "/subscriptions/<SUBSCRIPTION_ID>"
+  ]
+}
+```
+
+Restrict `AssignableScopes` to resource-group scope for operators who should not assign at subscription level.
+
+## Dangerous combinations — always block
+
+- Owner at management-group scope assigned to a Guest principal
+- 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

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

@@ -0,0 +1,69 @@
+# Preflight Commands: Azure Live Entra Role Assignment Guard
+
+Run all of these before creating or deleting any role assignment.
+
+## 1. Confirm caller identity and active subscription
+
+```bash
+az account show --query "{subscription:id, name:name, tenantId:tenantId, caller:user.name}"
+az ad signed-in-user show --query "{displayName:displayName, id:id, userPrincipalName:userPrincipalName}"
+```
+
+## 2. Inspect existing role assignments on the target scope
+
+```bash
+# Subscription scope
+az role assignment list \
+  --scope "/subscriptions/<SUBSCRIPTION_ID>" \
+  --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>" \
+  --include-inherited \
+  --query "[].{role:roleDefinitionName, principal:principalName, principalType:principalType, scope:scope}"
+
+# Resource group scope
+az role assignment list \
+  --resource-group <RESOURCE_GROUP> \
+  --include-inherited \
+  --query "[].{role:roleDefinitionName, principal:principalName, principalType:principalType, scope:scope}"
+```
+
+## 3. Verify the assignee identity and principal type
+
+```bash
+# For a user
+az ad user show --id <UPN_OR_OBJECT_ID> \
+  --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> \
+  --query "{displayName:displayName, appId:appId, servicePrincipalType:servicePrincipalType}"
+
+# For a managed identity
+az identity show --name <IDENTITY_NAME> --resource-group <RG> \
+  --query "{name:name, principalId:principalId, tenantId:tenantId}"
+```
+
+## 4. Check for existing dangerous standing assignments (audit)
+
+```bash
+# Find Owner and UAA at subscription scope (Kusto alternative via activity log)
+az role assignment list \
+  --scope "/subscriptions/<SUBSCRIPTION_ID>" \
+  --query "[?roleDefinitionName=='Owner' || roleDefinitionName=='User Access Administrator'].{role:roleDefinitionName, principal:principalName, principalType:principalType}"
+```
+
+## 5. Check whether a PIM eligible assignment already exists (prefer PIM over permanent)
+
+```bash
+az role eligibility-schedule list \
+  --scope "/subscriptions/<SUBSCRIPTION_ID>" \
+  --query "[?principalId=='<PRINCIPAL_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/rollback-playbook.md

@@ -0,0 +1,51 @@
+# Rollback Playbook: Azure Live Entra Role Assignment Guard
+
+Permanent role assignments do not expire automatically. Rollback means explicit deletion. Always capture the assignment details before write so deletion is unambiguous.
+
+## 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> \
+  --query "[].{name:name, roleDefinitionId:roleDefinitionId, principalId:principalId, scope:scope}"
+```
+
+## Remove a role assignment by name (most precise)
+
+```bash
+az role assignment delete \
+  --ids /subscriptions/<SUBSCRIPTION_ID>/providers/Microsoft.Authorization/roleAssignments/<ASSIGNMENT_NAME>
+```
+
+## 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>
+```
+
+## Verify deletion took effect
+
+```bash
+az role assignment list \
+  --assignee <PRINCIPAL_OBJECT_ID_OR_UPN> \
+  --scope <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.
+- 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.
+
+## What cannot be rolled back automatically
+
+- Access exercised during the window the assignment was active (data accessed, operations performed) cannot be undone via role removal.
+- Any resources created or deleted by the principal during the assignment window must be remediated separately.

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

@@ -0,0 +1,49 @@
+---
+name: azure-live-keyvault-rotation-purge-guard
+description: Guard Key Vault key rotation, rotation policy changes, soft-delete enforcement, and purge-protection enablement with irreversibility warnings and rollback evidence.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# Azure Live Key Vault Rotation Purge Guard
+
+## Purpose
+
+Act as the guarded live Azure operator for azure-live-keyvault-rotation-purge-guard work. Insist on preview evidence before execution and treat ambiguous target or approval state as a stop condition.
+
+## When to use
+
+Use this skill when:
+
+- a Key Vault key or secret rotation must be triggered or scheduled against a live vault
+- soft-delete or purge-protection must be verified or enabled on a production vault
+- a key or secret has been soft-deleted and recovery or permanent purge must be decided
+
+## Lean operating rules
+
+- Prefer Azure CLI (`az`) official documentation when available; fall back to Microsoft Learn docs and 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.
+- Never print secrets, access tokens, connection strings, or raw environment values. Summarize sanitized evidence only.
+- Load references only when needed.
+
+## References
+
+Load these only when needed:
+
+- [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.
+- [Official sources](references/official-sources.md) — authoritative Azure documentation links.
+
+## Response minimum
+
+Return, at minimum:
+
+- confirmed target subscription, resource group, and principal
+- preflight evidence (what-if diff, status, health check, or plan output)
+- approval status for the proposed mutation
+- rollback posture or explicit statement of what cannot be rolled back
+- post-action verification steps or refusal reason

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

@@ -0,0 +1,27 @@
+{
+  "id": "azure-live-keyvault-rotation-purge-guard",
+  "name": "Azure Live Key Vault Rotation Purge Guard",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Guard Key Vault key rotation, rotation policy changes, soft-delete enforcement, and purge-protection enablement 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"
+  ],
+  "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",
+  "path": "skills/azure/azure-live-keyvault-rotation-purge-guard",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/azure/azure-live-keyvault-rotation-purge-guard/references/official-sources.md

@@ -0,0 +1,13 @@
+# Official Sources: Azure Live Key Vault Rotation Purge Guard
+
+## Key Vault key management
+
+- https://learn.microsoft.com/en-us/azure/key-vault/keys/about-keys
+- 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/soft-delete-overview
+- https://learn.microsoft.com/en-us/azure/key-vault/general/key-vault-recovery
+
+## Source-grounding rule
+
+Use official Microsoft Learn documentation as the source of truth for Key Vault behavior.
+Purge-protection and soft-delete mechanics change between API versions — verify against current docs.

package/skills/azure/azure-live-keyvault-rotation-purge-guard/references/permission-model.md

@@ -0,0 +1,64 @@
+# Permission Model: Azure Live Key Vault Rotation Purge Guard
+
+## Rotation operator role — no delete, no purge
+
+```json
+{
+  "Name": "Key Vault Rotation Guard",
+  "IsCustom": true,
+  "Description": "Rotate keys and update rotation policies. Cannot delete or purge keys/secrets/certificates. Cannot purge the vault itself. Cannot disable soft-delete.",
+  "Actions": [
+    "Microsoft.KeyVault/vaults/read",
+    "Microsoft.KeyVault/vaults/keys/read",
+    "Microsoft.KeyVault/vaults/secrets/read"
+  ],
+  "NotActions": [
+    "Microsoft.KeyVault/vaults/purge/action",
+    "Microsoft.KeyVault/vaults/delete",
+    "Microsoft.KeyVault/vaults/write",
+    "Microsoft.KeyVault/vaults/accessPolicies/write"
+  ],
+  "DataActions": [
+    "Microsoft.KeyVault/vaults/keys/read",
+    "Microsoft.KeyVault/vaults/keys/rotate/action",
+    "Microsoft.KeyVault/vaults/keys/rotationpolicy/read",
+    "Microsoft.KeyVault/vaults/keys/rotationpolicy/write",
+    "Microsoft.KeyVault/vaults/secrets/getSecret/action"
+  ],
+  "NotDataActions": [
+    "Microsoft.KeyVault/vaults/keys/delete",
+    "Microsoft.KeyVault/vaults/keys/purge/action",
+    "Microsoft.KeyVault/vaults/secrets/delete",
+    "Microsoft.KeyVault/vaults/secrets/purge/action",
+    "Microsoft.KeyVault/vaults/certificates/delete",
+    "Microsoft.KeyVault/vaults/certificates/purge/action"
+  ],
+  "AssignableScopes": [
+    "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<TARGET_RG>/providers/Microsoft.KeyVault/vaults/<VAULT_NAME>"
+  ]
+}
+```
+
+Nearest built-in roles: `Key Vault Crypto Officer` (keys), `Key Vault Secrets Officer` (secrets).
+Both include delete — prefer the custom role above for rotation-only scenarios.
+
+**Action vs DataAction distinction (security-critical)**:
+`Microsoft.KeyVault/vaults/purge/action` is a **control-plane Action** that purges the
+soft-deleted **vault** itself (irreversible). It is **not** a DataAction and is not blocked
+by `NotDataActions`. It must be in `NotActions`. Certificate operations exist on both planes;
+this role blocks both. Do not assume `NotDataActions` covers all destructive Key Vault paths.
+
+## Purge-protection enablement (separate, PIM-gated operation)
+
+Requires `Microsoft.KeyVault/vaults/write` on the vault resource.
+Assign via PIM with justification. Maximum 1-hour activation window.
+
+**IRREVERSIBILITY WARNING**: Once `enablePurgeProtection: true` is set on a vault,
+it cannot be unset. All soft-deleted objects are protected from permanent deletion
+until the retention period (7–90 days) expires. This is a one-way door.
+
+## Do not assign
+
+- `Key Vault Administrator` standing (includes purge rights)
+- `Microsoft.KeyVault/vaults/purge/action` to rotation operators
+- `Microsoft.KeyVault/vaults/accessPolicies/write` to non-admins (legacy access policy model)