@raishin/vanguard-frontier-agentic 2.8.0 → 2.9.0

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

@@ -0,0 +1,68 @@
+# Azure Key Vault Rotation and Purge 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
+
+- Treating rotation as safe because Key Vault creates a new version.
+- Purging soft-deleted material before proving no dependent service needs recovery.
+- Granting purge rights to the same operators who rotate keys or secrets.
+- Enabling purge protection without warning that it cannot be disabled.
+- Disabling old key versions before re-encryption or dependent services are migrated.
+
+## Officially grounded service shape
+
+Microsoft Learn evidence says soft delete retains deleted vaults and objects for a configurable period, cannot be disabled once enabled, and purge protection prevents permanent deletion until retention elapses. Purge protection cannot be disabled or overridden after enablement. Key rotation should use versioning and rotation policy with dependent-service planning; purge operations require elevated permissions and can be irreversible.
+
+- Soft delete and purge protection are recovery controls with retention windows.
+- Purge protection depends on soft delete and prevents purge until retention passes.
+- Key rotation creates new versions; consumers must either follow latest version safely or be updated deliberately.
+- Secret rotation requires dependent application validation and rollback.
+- Azure Policy can audit or deny missing soft delete and purge protection.
+
+## Non-negotiable design rules
+
+- Never request or print key material, secret values, connection strings, or private keys.
+- Separate rotation authority from purge authority.
+- List dependencies before rotate, disable, delete, recover, or purge.
+- Warn explicitly when an operation is irreversible or not fully rollbackable.
+- Prefer recovery and quarantine over purge unless destruction is approved and evidenced.
+
+## Minimal safe implementation flow
+
+- Scope vault, object type, object name, environment, owner, and dependent services.
+- Collect read-only evidence for soft delete, purge protection, retention, RBAC, object versions, rotation policy, and deleted-object state.
+- Classify requested action as rotation, policy update, enable protection, recover, delete, disable, or purge.
+- Gate mutation on dependency impact, backup/recovery posture, and explicit approval.
+- Verify new version, consumer health, recovery posture, audit events, and remaining risk.
+
+## High-risk assumptions to kill
+
+- Rotation does not prove consumers follow the latest version; pinned key, secret, or certificate versions can break silently after disable/delete.
+- Soft delete is not backup. Recovering a vault does not restore all integrated services such as RBAC role assignments or Event Grid subscriptions.
+- Purge protection cannot be disabled after enablement and purge can be immediate and irrecoverable when protection does not block it.
+- Purge permission should not live with routine rotation automation; separation of duties is the safety control.
+- Secret, key, certificate, connection-string, or private-key material must never be pasted into the workflow as evidence.
+
+## Safe command/code verification targets
+
+- Verify vault soft-delete state, purge-protection state, retention period, RBAC/access model, deleted-object state, and object versions.
+- Check rotation policy and consumer version-pinning before rotate, disable, delete, recover, or purge.
+- Confirm purge authority is narrow, approved, and not reused for normal rotation paths.
+- Validate dependent service health against the new version before disabling old versions.
+- Label purge and protection changes as irreversible or time-bound where Microsoft Learn documents those constraints.
+
+## Safe verification targets
+
+- Soft delete and purge protection state are known and documented.
+- Purge role assignments are narrow, JIT where possible, and not routine automation.
+- Rotation policy aligns with compliance and consumer behavior.
+- Dependent services are tested against new key/secret versions.
+- Recovery or purge decision has owner approval and retention/irreversibility caveat.
+
+## When to push back
+
+- The user asks to purge without dependency and approval evidence.
+- The user asks to paste or export secret/key material.
+- Rotation would break pinned-version consumers with no migration plan.
+- Purge protection or retention implications are not understood by the approver.

package/skills/azure/azure-live-keyvault-rotation-purge-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-keyvault-rotation-purge-guard/references/official-sources.md

@@ -1,13 +1,35 @@
-# Official Sources: Azure Live Key Vault Rotation Purge Guard
+# Official Sources
 
-## Key Vault key management
+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.
 
-- 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
+## Primary Microsoft Learn sources
 
-## Source-grounding rule
+- 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
+
+## Grounding notes
+
+- Documentation-based claim: Microsoft Learn evidence says soft delete retains deleted vaults and objects for a configurable period, cannot be disabled once enabled, and purge protection prevents permanent deletion until retention elapses. Purge protection cannot be disabled or overridden after enablement. Key rotation should use versioning and rotation policy with dependent-service planning; purge operations require elevated permissions and can be irreversible.
+- 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
+
+- Soft delete is enabled by default for new vaults and cannot be disabled after enablement.
+- Purge protection is not enabled by default, but once enabled it cannot be disabled or bypassed during the retention period.
+- Key rotation creates a new key version; it does not re-encrypt dependent data by itself, so old and new versions may both be needed during rewrap/migration.
+- Recovering a soft-deleted vault does not automatically restore every integrated artifact such as role assignments or event subscriptions.
 
-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

@@ -1,5 +1,9 @@
 # Permission Model: Azure Live Key Vault Rotation Purge 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.
+
 ## Rotation operator role — no delete, no purge
 
 ```json
@@ -34,7 +38,7 @@
     "Microsoft.KeyVault/vaults/certificates/purge/action"
   ],
   "AssignableScopes": [
-    "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<TARGET_RG>/providers/Microsoft.KeyVault/vaults/<VAULT_NAME>"
+    "$APPROVED_KEY_VAULT_SCOPE"
   ]
 }
 ```
@@ -62,3 +66,5 @@ until the retention period (7–90 days) expires. This is a one-way door.
 - `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)
+
+Use exact resource scopes from approved change records; do not paste raw subscription identifiers into chat.

package/skills/azure/azure-live-keyvault-rotation-purge-guard/references/preflight-commands.md

@@ -1,32 +1,38 @@
 # Preflight Commands: Azure Live Key Vault Rotation Purge Guard
 
+Use shell variables for examples instead of raw identifiers. Populate them from an approved change record or already configured shell context; never paste tenant, subscription, resource, or secret values into chat.
+
+## Evidence-variable convention
+
+Variables such as $AZURE_RESOURCE_GROUP_NAME, $APP_SERVICE_APP_NAME, or $KEY_VAULT_NAME are local operator placeholders. Do not commit real values, and redact them from shared evidence unless the change record explicitly allows disclosure.
+
 Run these before any Key Vault rotation or purge operation.
 
 ## 1. Confirm identity and vault target
 
 ```bash
 az account show --query "{subscription:id, name:name, user:user.name}"
-az keyvault show -n <VAULT_NAME> -g <RESOURCE_GROUP> \
+az keyvault show -n $KEY_VAULT_NAME -g $AZURE_RESOURCE_GROUP_NAME \
   --query "{name:name, enableSoftDelete:properties.enableSoftDelete, enablePurgeProtection:properties.enablePurgeProtection, softDeleteRetentionInDays:properties.softDeleteRetentionInDays}"
 ```
 
 ## 2. List key versions and identify current/active
 
 ```bash
-az keyvault key list-versions --vault-name <VAULT_NAME> -n <KEY_NAME> \
+az keyvault key list-versions --vault-name $KEY_VAULT_NAME -n $KEY_VAULT_KEY_NAME \
   --query "[].{kid:kid, enabled:attributes.enabled, created:attributes.created, expires:attributes.expires}"
 ```
 
 ## 3. Check rotation policy
 
 ```bash
-az keyvault key rotation-policy show --vault-name <VAULT_NAME> -n <KEY_NAME>
+az keyvault key rotation-policy show --vault-name $KEY_VAULT_NAME -n $KEY_VAULT_KEY_NAME
 ```
 
 ## 4. List soft-deleted keys (purge risk check)
 
 ```bash
-az keyvault key list-deleted --vault-name <VAULT_NAME> \
+az keyvault key list-deleted --vault-name $KEY_VAULT_NAME \
   --query "[].{name:name, deletedDate:attributes.deletedDate, scheduledPurgeDate:attributes.scheduledPurgeDate}"
 ```
 
@@ -35,14 +41,19 @@ az keyvault key list-deleted --vault-name <VAULT_NAME> \
 ```bash
 # Check disk encryption sets using this vault
 az disk-encryption-set list --query \
-  "[?activeKey.sourceVault.id contains '<VAULT_NAME>'].{name:name, id:id}"
+  "[?activeKey.sourceVault.id contains '$KEY_VAULT_NAME'].{name:name, id:id}"
 # Check Storage accounts with CMK
 az storage account list --query \
-  "[?encryption.keyVaultProperties.keyVaultUri contains '<VAULT_NAME>'].{name:name}"
+  "[?encryption.keyVaultProperties.keyVaultUri contains '$KEY_VAULT_NAME'].{name:name}"
 ```
 
 ## 6. Confirm backup exists before any key version operation
 
 ```bash
-az keyvault key backup --vault-name <VAULT_NAME> -n <KEY_NAME> -f <KEY_NAME>-backup.json
+az keyvault key backup --vault-name $KEY_VAULT_NAME -n $KEY_VAULT_KEY_NAME -f $KEY_VAULT_KEY_NAME-backup.json
 ```
+
+
+## Read-only configured evidence labels
+
+Treat key, secret, certificate, and Managed HSM metadata reads as sampled read-only Azure evidence. Do not print secret values. A successful metadata read proves only the sampled vault/object state, not tenant-wide Key Vault posture.

package/skills/azure/azure-live-keyvault-rotation-purge-guard/references/rollback-playbook.md

@@ -1,10 +1,14 @@
 # Rollback Playbook: Azure Live Key Vault Rotation Purge Guard
 
+## 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.
+
 ## Restore a key from backup
 
 ```bash
 # Restore the key backup created during preflight
-az keyvault key restore --vault-name <VAULT_NAME> -f <KEY_NAME>-backup.json
+az keyvault key restore --vault-name $KEY_VAULT_NAME -f $KEY_VAULT_KEY_NAME-backup.json
 ```
 
 Note: key backup/restore only works within the same geography and subscription security boundary.
@@ -12,7 +16,7 @@ Note: key backup/restore only works within the same geography and subscription s
 ## Re-enable a disabled key version
 
 ```bash
-az keyvault key set-attributes --vault-name <VAULT_NAME> -n <KEY_NAME> \
+az keyvault key set-attributes --vault-name $KEY_VAULT_NAME -n $KEY_VAULT_KEY_NAME \
   --version <VERSION_ID> --enabled true
 ```
 
@@ -20,10 +24,10 @@ az keyvault key set-attributes --vault-name <VAULT_NAME> -n <KEY_NAME> \
 
 ```bash
 # List soft-deleted keys
-az keyvault key list-deleted --vault-name <VAULT_NAME>
+az keyvault key list-deleted --vault-name $KEY_VAULT_NAME
 
 # Recover
-az keyvault key recover --vault-name <VAULT_NAME> -n <KEY_NAME>
+az keyvault key recover --vault-name $KEY_VAULT_NAME -n $KEY_VAULT_KEY_NAME
 ```
 
 ## Revert rotation policy to previous settings
@@ -31,8 +35,8 @@ az keyvault key recover --vault-name <VAULT_NAME> -n <KEY_NAME>
 ```bash
 # Update rotation policy with restored values
 az keyvault key rotation-policy update \
-  --vault-name <VAULT_NAME> \
-  -n <KEY_NAME> \
+  --vault-name $KEY_VAULT_NAME \
+  -n $KEY_VAULT_KEY_NAME \
   --value @previous-rotation-policy.json
 ```
 

package/skills/azure/azure-live-keyvault-rotation-purge-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
+
+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.

package/skills/azure/azure-live-keyvault-rotation-purge-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-pim-jit-activation-guard/SKILL.md

@@ -4,8 +4,8 @@ description: Gate Entra ID PIM eligible role activations with justification, MFA
 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, then 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,6 +36,8 @@ Use this skill when:
 
 Load these only when needed:
 
+- [Azure PIM JIT Activation Operations](references/pim-jit-activation-operations.md) — use for current service behavior, common failure modes, hard design rules, verification targets, and push-back conditions.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, risk gates, mutation boundaries, approval rules, credential boundaries, and current-state caveats.
 - [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.

package/skills/azure/azure-live-pim-jit-activation-guard/metadata.json

@@ -11,17 +11,19 @@
     "kiro",
     "other"
   ],
-  "summary": "Gate Entra ID PIM eligible role activations with justification, MFA, ticket binding, time-bound scope, and approval workflow gates before any privileged Azure role becomes active.",
+  "summary": "Gate Microsoft Entra PIM eligible role activations with justification, MFA, reduced scope, ticket binding, time-bound duration, approval workflow checks, and cache/propagation caveats.",
   "source_type": "original",
   "official_docs": [
-    "https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-deployment-plan",
-    "https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-resource-roles-configure-role-settings",
-    "https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-how-to-activate-role",
-    "https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure-azure-ad-roles"
+    "https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-configure",
+    "https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-resource-roles-activate-your-roles",
+    "https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-resource-roles-configure-role-settings",
+    "https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-resource-roles-approval-workflow",
+    "https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-deployment-plan",
+    "https://learn.microsoft.com/entra/identity/role-based-access-control/best-practices"
   ],
-  "security_notes": "Never activate a PIM role without justification, ticket reference, and MFA confirmation. An agent cannot activate another user's PIM role on their behalf \u2014 only the eligible principal may submit. Requires Entra ID P2 or equivalent license.",
-  "last_verified": "2026-04-30",
+  "security_notes": "Never activate or approve PIM privileged access without confirming eligible principal, scope, role, activation duration, MFA/Conditional Access requirement, justification or ticket, approval status, and deactivation/expiry behavior.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-live-pim-jit-activation-guard",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.6"
 }

package/skills/azure/azure-live-pim-jit-activation-guard/references/mcp-and-evidence.md

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

package/skills/azure/azure-live-pim-jit-activation-guard/references/official-sources.md

@@ -1,13 +1,26 @@
-# Official Sources: Azure Live PIM JIT Activation Guard
+# Official Sources
 
-## Privileged Identity Management
+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, migration project, network, telemetry, deployed resources, or production readiness.
 
-- https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-how-to-activate-role
-- https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure
-- https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-resource-roles-overview
-- https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-apis
+## Primary Microsoft Learn sources
 
-## Source-grounding rule
+- https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-configure
+- https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-resource-roles-activate-your-roles
+- https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-resource-roles-configure-role-settings
+- https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-resource-roles-approval-workflow
+- https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-deployment-plan
+- https://learn.microsoft.com/entra/identity/role-based-access-control/best-practices
 
-Use official Microsoft Learn documentation as the source of truth for PIM behavior.
-PIM API versions change — verify the API version parameter in all Graph API calls against current docs.
+## Grounding notes
+
+- Documentation-based claim: Microsoft Learn evidence says PIM provides just-in-time, time-bound, approval-based privileged access for Microsoft Entra and Azure resources. Azure resource role activation can require MFA, reduced scope, start time, duration, and reason; approval can leave a request pending. PIM temporarily adds active assignment and later removes it, but applications can cache role state so access changes may not appear immediately.
+- Current-state claim: requires sampled read-only Azure evidence or sanitized user-provided evidence.
+- 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.

package/skills/azure/azure-live-pim-jit-activation-guard/references/permission-model.md

@@ -27,7 +27,7 @@ Preferred model:
   ],
   "NotActions": [],
   "AssignableScopes": [
-    "/subscriptions/<SUBSCRIPTION_ID>"
+    "$APPROVED_AZURE_SCOPE"
   ]
 }
 ```
@@ -54,3 +54,5 @@ Use Conditional Access + time-bounded Entra ID Group membership via Access Packa
 - Standing `Owner` at subscription scope
 - Standing `User Access Administrator` (allows arbitrary role assignments)
 - `Microsoft.Authorization/roleAssignments/write` to non-PIM principals
+
+Use exact resource scopes from approved change records; do not paste raw subscription identifiers into chat.

package/skills/azure/azure-live-pim-jit-activation-guard/references/pim-jit-activation-operations.md

@@ -0,0 +1,68 @@
+# Azure PIM JIT Activation Operations
+
+Use this reference for current, source-grounded service behavior and the hard review gates that the lean `SKILL.md` intentionally does not carry.
+
+## What people get wrong
+
+- Treating eligible assignment as active access.
+- Activating the broadest eligible scope instead of reducing scope to the actual resource needed.
+- Skipping justification, ticket, MFA, or approval because the task is urgent.
+- Assuming deactivation instantly removes access from every downstream application cache.
+- Trying to activate another user’s eligible role from an agent context.
+
+## Officially grounded service shape
+
+Microsoft Learn evidence says PIM provides just-in-time, time-bound, approval-based privileged access for Microsoft Entra and Azure resources. Azure resource role activation can require MFA, reduced scope, start time, duration, and reason; approval can leave a request pending. PIM temporarily adds active assignment and later removes it, but applications can cache role state so access changes may not appear immediately.
+
+- PIM role settings are configured per role and per resource.
+- Eligible members activate roles only when needed and within configured maximum duration.
+- Activation can require MFA, justification, ticket information, Conditional Access, and approval.
+- Users can view pending requests, cancel pending requests, and deactivate active assignments subject to timing rules.
+- PIM audit and notification signals are part of the control, not optional decoration.
+
+## Non-negotiable design rules
+
+- Confirm the eligible principal is the requester or authorized approver; do not impersonate activation.
+- Require the narrowest scope, shortest duration, and explicit business reason.
+- Require approval state before treating access as usable.
+- Document cache and sign-out/sign-in caveats for access add/remove.
+- Refuse activation when target scope, role, principal, approval, or rollback/deactivation path is ambiguous.
+
+## Minimal safe implementation flow
+
+- Scope principal, role, resource scope, duration, approval workflow, and task ticket.
+- Collect read-only evidence of eligibility, current active assignments, PIM role settings, and request status.
+- Check MFA, Conditional Access, approval, justification, and reduced-scope requirements.
+- If mutation is requested, require explicit user approval before activation, approval, cancellation, or deactivation.
+- Verify request status, active assignment, expiry time, audit evidence, and deactivation plan.
+
+## High-risk assumptions to kill
+
+- Eligible does not mean active. Do not treat an eligible assignment as usable access until request status proves activation or approval state.
+- PIM activation is not a way for an agent to impersonate another human; the eligible principal or authorized approver boundary must remain explicit.
+- Broad management-group or subscription activation is not justified when a narrower resource scope satisfies the task.
+- Deactivation is not an instant proof of downstream access removal because applications can cache role state.
+- Approval, MFA, justification, ticket, and duration controls are not paperwork; they are the evidence that privileged access was bounded.
+
+## Safe command/code verification targets
+
+- Verify eligible assignment, active assignment, request status, role settings, approval requirement, MFA requirement, and maximum duration before any activation path.
+- Check reduced scope and shortest viable duration before submitting or approving an activation.
+- Capture request state as pending, approved, active, denied, canceled, expired, or deactivated; do not infer it from intent.
+- Verify audit evidence and expiry/deactivation plan after activation.
+- State access-cache and sign-out/sign-in caveats whenever access add/remove is part of the verdict.
+
+## Safe verification targets
+
+- Eligible assignment exists for the requested principal and scope.
+- Activation duration is within policy and no broader than operational need.
+- MFA/approval/justification/ticket controls are satisfied where required.
+- Audit or request status proves pending, active, denied, canceled, expired, or deactivated state.
+- Access-cache caveat and sign-out/sign-in mitigation are stated.
+
+## When to push back
+
+- The user asks the agent to activate someone else’s role.
+- Scope or role is broader than the task requires.
+- Approval workflow is bypassed or approval owner is unclear.
+- The user needs permanent access but calls it JIT.

package/skills/azure/azure-live-pim-jit-activation-guard/references/preflight-commands.md

@@ -2,6 +2,10 @@
 
 Run these before initiating or approving a PIM activation.
 
+## 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.
+
 ## 1. Confirm current principal identity
 
 ```bash
@@ -14,16 +18,16 @@ az ad signed-in-user show --query "{displayName:displayName, id:id, userPrincipa
 ```bash
 # Using Azure CLI
 az role eligibility-schedule list \
-  --scope "/subscriptions/<SUBSCRIPTION_ID>" \
-  --query "[?principalId=='<PRINCIPAL_ID>'].{roleName:roleDefinitionDisplayName, scope:scope, endDateTime:endDateTime}"
+  --scope "$APPROVED_AZURE_SCOPE" \
+  --query "[?principalId=='$PRINCIPAL_OBJECT_ID'].{roleName:roleDefinitionDisplayName, scope:scope, endDateTime:endDateTime}"
 ```
 
 ## 3. List active role assignments (not eligible — currently active)
 
 ```bash
 az role assignment list \
-  --assignee <PRINCIPAL_ID_OR_UPN> \
-  --scope "/subscriptions/<SUBSCRIPTION_ID>" \
+  --assignee $PRINCIPAL_LOOKUP_VALUE \
+  --scope "$APPROVED_AZURE_SCOPE" \
   --query "[].{role:roleDefinitionName, scope:scope, principalType:principalType}"
 ```
 
@@ -31,7 +35,7 @@ az role assignment list \
 
 ```bash
 az role assignment schedule request list \
-  --scope "/subscriptions/<SUBSCRIPTION_ID>" \
+  --scope "$APPROVED_AZURE_SCOPE" \
   --query "[?status=='PendingApproval' || status=='PendingAdminDecision'].{requestId:name, role:roleDefinitionDisplayName, requestor:requestorId, justification:justification}"
 ```
 

package/skills/azure/azure-live-pim-jit-activation-guard/references/rollback-playbook.md

@@ -1,18 +1,22 @@
 # Rollback Playbook: Azure Live PIM JIT Activation 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.
+
 ## Deactivate an active PIM role assignment immediately
 
 ```bash
 # Find the active role assignment schedule instance to cancel
 az role assignment schedule list \
-  --scope "/subscriptions/<SUBSCRIPTION_ID>" \
-  --query "[?assignedTo=='<PRINCIPAL_ID>'].{id:name, role:roleDefinitionDisplayName, endDateTime:endDateTime}"
+  --scope "$APPROVED_AZURE_SCOPE" \
+  --query "[?assignedTo=='$PRINCIPAL_OBJECT_ID'].{id:name, role:roleDefinitionDisplayName, endDateTime:endDateTime}"
 
 # Submit a deactivation request
 az role assignment schedule request create \
-  --scope "/subscriptions/<SUBSCRIPTION_ID>" \
-  --role-definition-id <ROLE_DEF_ID> \
-  --principal-id <PRINCIPAL_ID> \
+  --scope "$APPROVED_AZURE_SCOPE" \
+  --role-definition-id $ROLE_DEFINITION_ID \
+  --principal-id $PRINCIPAL_OBJECT_ID \
   --request-type SelfDeactivate
 ```
 
@@ -30,9 +34,9 @@ Body: { "properties": { "status": "Denied", "justification": "<reason>" } }
 ```bash
 # Remove the active role assignment
 az role assignment delete \
-  --assignee <PRINCIPAL_ID> \
-  --role <ROLE_NAME> \
-  --scope "/subscriptions/<SUBSCRIPTION_ID>"
+  --assignee $PRINCIPAL_OBJECT_ID \
+  --role $ROLE_DEFINITION_NAME \
+  --scope "$APPROVED_AZURE_SCOPE"
 ```
 
 After revoking, immediately review Azure Monitor activity log for actions taken