@raishin/vanguard-frontier-agentic 2.10.0 → 2.11.0

package/skills/microsoft/m365-licensing-ea-optimization/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: m365-licensing-ea-optimization
+description: Review Microsoft 365 licensing posture and Enterprise Agreement optimization — SKU and plan fit analysis across E3, E5, F-SKUs and add-ons; group-based licensing assignment hygiene; unassigned and over-assigned license detection; true-up planning guidance; and cost-versus-capability analysis for EA, CSP, and MCA contract types. Advisory only; never make purchase commitments or guarantee savings. Group-based-licensing changes in production are live-guard gated.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: cost-management
+---
+
+# Microsoft 365 Licensing and EA Optimization
+
+## Purpose
+
+Act as the Microsoft 365 licensing reviewer who treats every unassigned license, SKU mismatch, manual assignment sprawl, and ungoverned group-based licensing configuration as a cost and compliance risk until proven otherwise.
+
+## When to use
+
+Use this skill for:
+
+- SKU and plan fit analysis — E3 vs. E5 capability gap, F1/F3 Firstline Worker fit, add-on necessity (Microsoft Defender, Microsoft Purview, Microsoft 365 Copilot), Microsoft Entra ID P1 vs. P2 feature requirements
+- Group-based licensing hygiene — security group structure for license assignment, nested group limitations, location requirement compliance, conflict and dependency detection
+- License assignment hygiene — unassigned license inventory, over-assigned licenses, stale user accounts consuming licenses, assignment audit via Microsoft 365 admin center and Microsoft Graph
+- True-up planning — EA annual true-up cycle preparation, license count reconciliation, usage trend analysis, growth and reduction planning
+- Cost-versus-capability analysis — capability overlap between SKUs, identifying redundant add-ons, downgrade feasibility, E5 step-up versus selective add-ons
+- EA, CSP, and MCA contract awareness — agreement type differences (advisory context only), volume licensing admin center (successor to VLSC), Microsoft Customer Agreement characteristics
+- License governance — license assignment audit logs, License Administrator role scoping, reporting via Microsoft 365 admin center and Microsoft Graph PowerShell SDK
+
+## Lean operating rules
+
+- Prefer current Microsoft Learn documentation for service behavior. Use facts in `references/official-sources.md` as starting anchors.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Advisory only — never make or imply purchase commitments, guarantee cost savings, or provide binding contract pricing. Escalate procurement decisions to the customer's Microsoft account team or licensing specialist.
+- Never conflate licensing optimization with adoption or value-realization — this skill covers licensing cost structure, not end-user adoption outcomes.
+- Group-based licensing changes in production tenants are live-guard gated — escalate to a human administrator before recommending implementation.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+- Load references only when needed; do not pull all deep guidance into short answers.
+- Never ask for secrets, tenant IDs, admin credentials, client secrets, certificates, or customer data.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing a full licensing posture review or formatting a cost optimization assessment.
+- [Safety checklist](references/safety-checklist.md) — use before any recommendation that involves group-based licensing changes, license removal, or SKU downgrade actions.
+- [Official sources](references/official-sources.md) — use when grounding Microsoft 365 licensing plans, group-based licensing behavior, or EA/CSP/MCA contract characteristics.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the licensing control area(s) implicated and the main risks, gaps, or optimization opportunities,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/microsoft/m365-licensing-ea-optimization/metadata.json

@@ -0,0 +1,30 @@
+{
+  "id": "m365-licensing-ea-optimization",
+  "name": "Microsoft 365 Licensing and EA Optimization",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Microsoft 365 licensing posture and Enterprise Agreement optimization — SKU and plan fit analysis across E3, E5, F-SKUs and add-ons; group-based licensing assignment hygiene; unassigned and over-assigned license detection; true-up planning guidance; and cost-versus-capability analysis for EA, CSP, and MCA contract types. Advisory only; never make purchase commitments or guarantee savings. Group-based-licensing changes in production are live-guard gated.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/microsoft-365/admin/manage/manage-group-licenses",
+    "https://learn.microsoft.com/entra/identity/users/licensing-admin-center",
+    "https://learn.microsoft.com/microsoft-365/commerce/licenses/manage-volume-licensing",
+    "https://learn.microsoft.com/entra/fundamentals/licensing",
+    "https://learn.microsoft.com/microsoft-365/enterprise/assign-licenses-to-user-accounts"
+  ],
+  "security_notes": "Advisory only — never make or imply purchase commitments, guarantee specific cost savings, or provide binding contract pricing. Do not conflate SKU capability analysis with procurement advice; escalate contract decisions to the customer's Microsoft account team or licensing specialist. Group-based licensing changes in production tenants are live-guard gated and require explicit human confirmation. Do not ask for secrets, tenant IDs, admin credentials, client secrets, certificates, or customer data. Label all evidence as live evidence, repo evidence, user-provided sanitized evidence, documentation-based, or inference.",
+  "last_verified": "2026-06-17",
+  "path": "skills/microsoft/m365-licensing-ea-optimization",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "cost-management",
+  "companion_agents": ["m365-licensing-ea-optimization-agent"]
+}

package/skills/microsoft/m365-licensing-ea-optimization/references/official-sources.md

@@ -0,0 +1,67 @@
+# Official sources
+
+Use this reference only when you need source grounding for Microsoft 365 licensing plans, group-based licensing, EA/CSP/MCA contract characteristics, or license assignment hygiene.
+
+## Microsoft documentation
+
+Use these as starting points, not as proof of the user's live Microsoft 365 license assignment state or contract terms:
+
+- https://learn.microsoft.com/microsoft-365/admin/manage/manage-group-licenses
+- https://learn.microsoft.com/entra/identity/users/licensing-admin-center
+- https://learn.microsoft.com/microsoft-365/commerce/licenses/manage-volume-licensing
+- https://learn.microsoft.com/entra/fundamentals/licensing
+- https://learn.microsoft.com/microsoft-365/enterprise/assign-licenses-to-user-accounts
+- https://learn.microsoft.com/microsoft-365/enterprise/view-licenses-and-services-with-microsoft-365-powershell
+- https://learn.microsoft.com/entra/fundamentals/licensing-groups-resolve-problems
+- https://learn.microsoft.com/microsoft-365/commerce/licenses/e3-extra-features-licenses
+- https://learn.microsoft.com/azure/cost-management-billing/microsoft-customer-agreement/onboard-microsoft-customer-agreement
+- https://learn.microsoft.com/entra/identity/users/licensing-group-advanced
+
+## Grounding rule
+
+Official documentation explains Microsoft 365 licensing plan capabilities and assignment mechanics. It does not prove the user's current license assignment state, actual contract pricing, or renewal terms. Prefer read-only Microsoft 365 admin center evidence, Microsoft Graph license API read output, repository evidence, or sanitized user-provided evidence for current-state claims. Never derive or imply contract pricing from documentation.
+
+## Current documentation refresh (2026-06-17)
+
+Key service facts from official Microsoft Learn documentation:
+
+**Group-based licensing (per learn.microsoft.com/microsoft-365/admin/manage/manage-group-licenses):**
+- Security groups, mail-enabled groups, and Microsoft 365 groups can be used for license assignment
+- Maximum of 20 groups assignable at once in Microsoft 365 admin center; API and PowerShell have no such UI limit
+- Nested groups are not supported — only first-level group members receive licenses
+- Users without a usage location inherit tenant location; always set user location before assignment
+- Move users to new group before removing from old group to prevent temporary service loss
+- License Administrator role is required for group-based licensing in Microsoft 365 admin center; Group Administrators can use API and PowerShell
+- Group-based licensing is available with Microsoft Entra ID P1 or higher (included in E3, E5, F-SKUs, Business Premium)
+
+**Microsoft Entra licensing tiers (per learn.microsoft.com/entra/fundamentals/licensing):**
+- Microsoft Entra ID Free: included with Microsoft cloud subscriptions
+- Microsoft Entra ID P1: included in Microsoft 365 E3, F1, F3, Enterprise Mobility + Security E3, Business Premium
+- Microsoft Entra ID P2: included in Microsoft 365 E5, Microsoft Defender Suite, Enterprise Mobility + Security E5 — adds Identity Protection, Privileged Identity Management, and access reviews
+- Microsoft Entra Suite: combines Private Access, Internet Access, ID Governance, ID Protection, Verified ID premium
+
+**SKU landscape:**
+- Microsoft 365 E3: Office 365 E3 + Enterprise Mobility + Security E3 + Windows E3 (via EA)
+- Microsoft 365 E5: adds E5 Security, E5 Compliance, E5 Voice — includes Microsoft Entra ID P2, Microsoft Defender suite, Microsoft Purview advanced features
+- Microsoft 365 F1/F3: Firstline Worker plans for shift workers — reduced feature set, lower per-seat cost
+- E3 Extra Features and E5 Extra Features: additional capabilities for EA customers (Avatars for Teams, Windows Autopatch, Customer Lockbox for E5, etc.)
+- Add-ons: Microsoft 365 Copilot, Microsoft Defender for Endpoint, Microsoft Purview add-ons — required when base SKU does not include needed capability
+
+**EA, CSP, MCA contract awareness (advisory context only):**
+- Enterprise Agreement (EA): designed for 500+ user organizations, annual true-up cycle, 3-year term, volume discount
+- Cloud Solution Provider (CSP): partner-managed, monthly flexibility, no long-term commitment
+- Microsoft Customer Agreement (MCA): simplified digital agreement, pay-as-you-go, no expiry, automated processing
+- Volume Licensing Service Center (VLSC) retired April 2024; VL management moved to Microsoft 365 admin center
+
+**Common failure modes:**
+- Manual per-user license assignment at scale — high operational overhead, error-prone, no automatic de-provisioning
+- Group-based licensing without usage location set — assignment failures for users without location
+- Nested security groups used for license assignment — licenses not inherited by nested members
+- E5 assigned to users who only need E3 capabilities — over-assignment cost without capability utilization
+- Add-on licenses purchased without confirming base SKU includes prerequisite (e.g., Microsoft Entra ID P1 required for some add-ons)
+- EA true-up not tracked — surprise overage costs at annual reconciliation
+
+Review implications:
+- Do not recommend removing licenses without confirming the user is inactive or the service is not depended upon — service interruption risk.
+- Never commit to savings estimates without the customer's actual contract pricing data.
+- Documentation cannot prove the user's actual assigned license counts, group membership, or contract terms.

package/skills/microsoft/m365-licensing-ea-optimization/references/safety-checklist.md

@@ -0,0 +1,39 @@
+# Safety checklist
+
+Use this reference before any recommendation that involves group-based licensing changes, license removal, SKU downgrade actions, or any other Microsoft 365 license assignment configuration change in production.
+
+## Non-negotiables
+
+- Advisory only — never make or imply purchase commitments, guarantee cost savings, or provide binding contract pricing. State this limitation plainly if pressed.
+- Never recommend removing licenses from active users without first confirming the user is inactive or the service is not depended upon — service interruption risk is immediate.
+- Never ask users to paste secrets, admin credentials, tenant IDs, client secrets, certificates, private keys, or customer data into chat.
+- Use read-only Microsoft 365 admin center evidence or Microsoft Graph license API read evidence for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
+- Do not invent license counts, assignment states, group membership, or contract pricing.
+- Require explicit user approval before recommending group-based licensing configuration changes in production — group-based licensing changes are live-guard gated.
+- Never recommend nested groups for license assignment — nested group members do not receive licenses and this is a silent failure mode.
+- Treat any large-scale license removal recommendation (100+ users) as requiring staged validation before full execution.
+
+## Stress checks
+
+- Which users have licenses assigned but have not signed in for 90+ days — are they truly inactive or on leave?
+- Which license assignments are manual-only with no group-based automation, creating de-provisioning gaps when users leave?
+- Are nested groups used anywhere in license assignment, silently excluding nested members?
+- Which add-ons are assigned to users whose base SKU already includes the same capability — duplicate cost?
+- Is the E3-versus-E5 decision documented against specific capability requirements, or was it a default choice?
+- Does the EA true-up timeline align with current headcount trend to avoid surprise annual overage?
+- Are users without a usage location set present in any licensed group — causing silent assignment failures?
+
+## Evidence labels
+
+Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's actual license assignment counts, group membership state, or contract terms. Never derive contract pricing from public documentation.
+
+## Escalation triggers
+
+Escalate to live-guard gate before any of the following:
+
+- Assigning or removing group-based licensing configurations in production tenant security groups
+- Removing licenses from user accounts (individual or bulk)
+- Changing SKU assignments for 50 or more users simultaneously
+- Initiating a group-based licensing reprocess operation via Microsoft Graph or PowerShell
+- Recommending a SKU downgrade that removes capabilities currently in use
+- Making any recommendation that touches EA true-up commitments or contract renewal terms — escalate to Microsoft account team or licensing specialist

package/skills/microsoft/m365-licensing-ea-optimization/references/workflow-and-output.md

@@ -0,0 +1,68 @@
+# Workflow and output contract
+
+Use this reference only when performing a full licensing posture review or formatting a cost optimization assessment.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- **License assignment hygiene**: Unassigned licenses, stale accounts with active licenses, manual versus group-based assignment coverage, usage location compliance for all licensed users
+- **Group-based licensing structure**: Security group design for license assignment, nested group limitations, dependency and conflict resolution, audit log coverage for group-based licensing changes
+- **SKU fit analysis**: E3 versus E5 capability gap for the user population, F1/F3 appropriateness for Firstline Worker scenarios, add-on necessity versus base SKU inclusion, Microsoft Entra ID P1 versus P2 requirement
+- **Over- and under-assignment**: Users with E5 where E3 suffices, missing add-ons for users who need a specific capability, add-on purchased when base SKU already includes it
+- **True-up planning**: EA annual true-up preparation, license count trend, seat growth and reduction planning, reconciliation of purchased versus assigned counts
+- **Contract type awareness**: EA, CSP, or MCA contract characteristics in context (advisory only — no pricing commitments); volume licensing admin center usage for VL contracts
+- **License governance**: License Administrator role scoping, audit log coverage for license assignments, reporting cadence via Microsoft 365 admin center and Microsoft Graph
+
+## Safe workflow
+
+1. **Frame scope**
+   - Tenant / environment / current SKU mix (if available):
+   - Assignment method (manual, group-based, PowerShell):
+   - Contract type and renewal context (advisory context only):
+   - Compliance and regulatory licensing requirements:
+   - Required outcome:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer read-only Microsoft 365 admin center evidence or Microsoft Graph license API read output for current-state claims when available.
+   - Otherwise inspect repository IaC/config, sanitized user evidence, or official docs.
+   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+3. **Stress-test risk**
+   - Which users have licenses assigned but have not signed in for 90+ days?
+   - Are any license assignments manual-only with no group-based automation, creating de-provisioning gaps?
+   - Are nested groups used for license assignment, creating silent gaps in coverage?
+   - Which add-ons are assigned to users whose base SKU already includes those capabilities?
+   - Is the E3-versus-E5 decision based on documented capability requirements or historical default?
+   - Does the EA true-up timeline align with current headcount trend to avoid surprise overage?
+4. **Recommend the smallest safe action**
+   - Prefer audit and reporting before removing licenses — confirm inactivity before de-provisioning.
+   - Never recommend license removal for active users without confirming service dependency.
+   - Never make or imply purchase commitments or savings guarantees — advisory only.
+   - Group-based licensing changes in production are live-guard gated; escalate to a human administrator.
+   - If the safest action is to stop and gather evidence before making changes, say that plainly.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# M365 Licensing and EA Optimization Review: <scope>
+## Executive verdict
+- Status: OPTIMIZED / OPTIMIZATION OPPORTUNITIES IDENTIFIED / NEEDS EVIDENCE
+- Biggest risk or opportunity:
+- Evidence level:
+## Scope and assumptions
+- Confirmed:
+- Unknown:
+- Out of scope:
+## Findings
+| Severity | Control area | Finding | Evidence | Why it matters | Minimum safe action |
+|---|---|---|---|---|---|
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+## Validation
+- Checks or reports to run:
+- Expected result:
+## Residual risk
+- <risk or explicit none>
+```

package/skills/microsoft/m365-live-identity-posture-guard/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: m365-live-identity-posture-guard
+description: Live read-only Microsoft Entra identity and Conditional Access posture discovery — enumerate CA policies, MFA coverage gaps, privileged role assignments and PIM configuration, risky sign-ins, and stale guest accounts — then propose least-privilege hardening steps with blast-radius assessment and rollback plan. Phase A read-only-runtime only; no mutation.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: security
+  execution_tier: read-only-runtime
+  mcp_servers: []
+  oauth_scopes:
+    - "Directory.Read.All"
+    - "Policy.Read.All"
+    - "Policy.Read.ConditionalAccess"
+    - "RoleManagement.Read.Directory"
+    - "AuditLog.Read.All"
+  run_as_permissions:
+    required:
+      - "Directory.Read.All (application permission, admin-consented)"
+      - "Policy.Read.All (application permission, admin-consented)"
+      - "Policy.Read.ConditionalAccess (application permission, admin-consented)"
+      - "RoleManagement.Read.Directory (application permission, admin-consented)"
+      - "AuditLog.Read.All (application permission, admin-consented)"
+    denied:
+      - "Directory.ReadWrite.All"
+      - "Policy.ReadWrite.ConditionalAccess"
+      - "RoleManagement.ReadWrite.Directory"
+      - "User.ReadWrite.All"
+      - "Group.ReadWrite.All"
+      - "Application.ReadWrite.All"
+      - "Any *.Write or *.ReadWrite.* permission"
+  required_egress:
+    - "graph.microsoft.com"
+    - "login.microsoftonline.com"
+  requires_credentials:
+    - "GRAPH_CLIENT_ID"
+    - "GRAPH_TENANT_ID"
+  output_attestation:
+    schema: "posture-report-v1"
+    signed_with: "none"
+  companion_agents:
+    - "m365-live-identity-posture-guard-agent"
+---
+
+# M365 Live Identity Posture Guard
+
+## Purpose
+
+Act as the live read-only Entra identity and Conditional Access posture guard. Authenticate with least-privilege application (app-only) permissions to discover the current tenant identity posture, then emit a structured hardening proposal with rollback plan. Never mutate; never request credentials values.
+
+## When to use
+
+- Entra Conditional Access policy coverage must be audited for gaps (legacy auth, MFA exemptions, excluded users)
+- MFA registration and coverage needs to be measured across the tenant or a specific population
+- Privileged role assignments (Global Administrator, Privileged Role Administrator, etc.) and PIM configuration must be reviewed
+- Risky sign-in or risky user signals from Identity Protection need to be surfaced for triage
+- Stale external/guest accounts need to be identified for lifecycle review
+
+## Live-guard gate
+
+This skill operates at `read-only-runtime`. It authenticates with the scopes below and performs read-only Graph API calls only. Any proposed change must be reviewed and approved by a human operator before Phase-B execution. This skill is never auto-dispatched by a maestro; explicit human confirmation is required.
+
+## Credential posture
+
+- App registration: use a certificate credential or managed identity — never a long-lived client secret.
+- Credentials are referenced by environment variable name only (`GRAPH_CLIENT_ID`, `GRAPH_TENANT_ID`). Never print, echo, or log credential values.
+- The app must be registered in the target tenant with the scopes above admin-consented by a Privileged Role Administrator.
+
+## Lean operating rules
+
+- Prefer Microsoft Learn documentation through the configured documentation MCP for Graph API and Entra service behavior.
+- Use sampled read-only Graph evidence when available; label it as sampled configured-environment evidence.
+- Do not execute any write, patch, post, or delete Graph call.
+- If the request implies policy modification, role assignment, or user-state change, push back — that is Phase-B gated work.
+- State what is unknown; documentation proves service behavior, not the tenant's deployed state.
+- Load references only when needed; do not dump reference text into the response.
+
+## Discovery targets
+
+1. Conditional Access policies — enabled/report-only/disabled, assignments, excluded users, grant controls
+2. MFA registration report — users not registered for strong authentication
+3. Privileged role members — permanent vs eligible (PIM) for Global Administrator, Privileged Role Administrator, User Administrator, Application Administrator, Authentication Administrator
+4. Risky users and risky sign-ins — current risk level and risk detail (requires Identity Protection P2)
+5. Guest accounts — external member/guest users with last-sign-in date for staleness assessment
+
+## Response minimum
+
+- confirmed tenant ID and app identity (from token claims, not user input)
+- discovery summary per target above
+- hardening proposals: what, why, blast-radius, dependencies
+- rollback contract for each proposal (Phase-B)
+- open questions and evidence gaps
+
+## Official sources
+
+- https://learn.microsoft.com/graph/permissions-reference
+- https://learn.microsoft.com/entra/identity-platform/app-only-access-primer
+- https://learn.microsoft.com/entra/identity/conditional-access/concept-conditional-access-policies
+- https://learn.microsoft.com/graph/api/resources/conditionalaccesspolicy
+- https://learn.microsoft.com/entra/id-protection/concept-identity-protection-risks

package/skills/microsoft/m365-live-identity-posture-guard/metadata.json

@@ -0,0 +1,22 @@
+{
+  "id": "m365-live-identity-posture-guard",
+  "name": "M365 Live Identity Posture Guard",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Live read-only Microsoft Entra identity and Conditional Access posture discovery — CA policy gaps, MFA coverage, privileged role assignments, PIM configuration, risky sign-ins, stale guests — with least-privilege hardening proposals and rollback plan. Phase A read-only-runtime.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/graph/permissions-reference",
+    "https://learn.microsoft.com/entra/identity-platform/app-only-access-primer",
+    "https://learn.microsoft.com/entra/identity/conditional-access/concept-conditional-access-policies",
+    "https://learn.microsoft.com/graph/api/resources/conditionalaccesspolicy",
+    "https://learn.microsoft.com/entra/id-protection/concept-identity-protection-risks"
+  ],
+  "security_notes": "Operates with read-only Microsoft Graph application permissions only (admin-consented). No write scopes. Credential posture: certificate or managed identity, never client secret. Never prints credential values. Phase A only — no mutation.",
+  "last_verified": "2026-06-17",
+  "path": "skills/microsoft/m365-live-identity-posture-guard",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "companion_agents": ["m365-live-identity-posture-guard-agent"]
+}

package/skills/microsoft/m365-live-sensitivity-label-apply-guard/SKILL.md

@@ -0,0 +1,181 @@
+---
+name: m365-live-sensitivity-label-apply-guard
+description: Mutating-runtime live-guard for applying ONE Microsoft Purview sensitivity label to ONE specified item (file/driveItem) via the Microsoft Graph assignSensitivityLabel action. Strictly scoped — one item, one label application. Requires explicit written human approval token referencing the exact item, proposed label, and blast-radius. PREFLIGHT reads the item's current label before any write. Fully reversible — prior label captured; re-apply prior label is the rollback. Gate-only; never auto-dispatched. Phase B mutating-runtime.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: compliance
+  execution_tier: mutating-runtime
+  mcp_servers: []
+  oauth_scopes:
+    - "InformationProtectionPolicy.Read.All"
+    - "Files.ReadWrite.All (documented least-privileged APPLICATION permission for driveItem assignSensitivityLabel; Graph exposes no per-item application scope for this protected/metered API)"
+  run_as_permissions:
+    required:
+      - "InformationProtectionPolicy.Read.All — to read available sensitivity labels and verify the proposed label ID (application permission, admin-consented)"
+      - "Files.ReadWrite.All — the least-privileged APPLICATION permission documented for driveItem: assignSensitivityLabel (higher-privileged alternative is Sites.ReadWrite.All; neither Files.ReadWrite without .All nor Sites.Selected is a supported application permission for this API)"
+      - "Application permission, admin-consented — no delegated/user-context for background agent operations"
+    compensating_controls:
+      - "Because no per-item application scope exists for this API, constrain the app's effective reach OUTSIDE the Graph permission: app-only access policy / RSC, or a Sites.Selected site-level grant where the tenant supports it, plus this guard's one-item written-approval gate and PREFLIGHT diff"
+    denied:
+      - "Directory.ReadWrite.All"
+      - "Sites.FullControl.All"
+      - "Sites.ReadWrite.All (higher-privileged alternative — Files.ReadWrite.All is the narrower documented permission for this API)"
+      - "InformationProtectionPolicy.ReadWrite.All (label policy management — not permitted)"
+      - "LabelPolicyManagement (any scope)"
+      - "RoleManagement.ReadWrite.Directory"
+      - "User.ReadWrite.All"
+      - "Bulk labeling (any operation targeting more than one item)"
+      - "Label policy changes (any write to label policy resources)"
+      - "Removing protection that would downgrade classification without explicit approval token"
+  required_egress:
+    - "graph.microsoft.com"
+    - "login.microsoftonline.com"
+  requires_credentials:
+    - "GRAPH_CLIENT_ID"
+    - "GRAPH_TENANT_ID"
+  output_attestation:
+    schema: "sensitivity-label-attestation-v1"
+    signed_with: "idempotency-key"
+    audit_log: "required"
+  liveAgentFields:
+    execution_tier: "mutating-runtime"
+    single_op: true
+    reversible: true
+    requires_approval_token: true
+    dry_run_preflight: true
+    idempotency_key: true
+    blast_radius_required: true
+  companion_agents:
+    - "m365-live-sensitivity-label-apply-guard-agent"
+---
+
+# M365 Live Sensitivity Label Apply Guard
+
+## Purpose
+
+Act as the live mutating-runtime Microsoft Purview sensitivity label application guard. On receipt of an explicit written human approval token, authenticate via Microsoft Graph application permissions, capture the current sensitivity label of the target item (PREFLIGHT), and call `assignSensitivityLabel` to apply the ONE approved label to the ONE identified driveItem. Emit a signed, idempotency-keyed attestation and update the audit log. Reverse path is always available — re-apply the prior label.
+
+## When to use
+
+- A single file or driveItem must have its sensitivity label upgraded or set as part of a compliance remediation
+- The operation requires a human-approved, blast-radius-reviewed gate before any label write proceeds
+- A prior compliance discovery identified a specific item that must be labeled to meet a data-classification policy
+- Auditable, traceable label application is required for regulatory or governance purposes
+
+## Gate-only classification
+
+This skill id contains `-live-` and ends in `-guard`. The maestro MUST NOT auto-dispatch this skill. Invocation requires:
+
+1. An explicit **written human approval token** that references:
+   - The target tenant (by env-var name `GRAPH_TENANT_ID`, not value)
+   - The target drive ID and driveItem ID (or equivalent item path)
+   - The proposed sensitivity label ID and label display name
+   - The assignment method (`standard` or `privileged`)
+   - The justification text (required for label downgrades or privileged assignments)
+   - The blast-radius assessment (who/what reads or is protected by the current label; what changes with the new label)
+2. Completion of PREFLIGHT (GET current label, confirm item exists, confirm scope)
+3. Prior-label capture before any write
+
+## Strict-control contract
+
+- `execution_tier: mutating-runtime`
+- **EXACTLY ONE** driveItem is labeled per approved run. Target is identified by drive ID + driveItem ID.
+- **ONE label application** — the PATCH/action body contains only the approved sensitivity label ID.
+- **No bulk labeling** — no operation targeting more than one item.
+- **No label policy changes** — `InformationProtectionPolicy.ReadWrite.All` and any label-policy write scope are explicitly denied.
+- **No classification downgrade without explicit approval** — if the proposed label would lower the classification tier, the approval token must explicitly acknowledge the downgrade and its justification text must be present.
+- **No irreversible label removal** — removing protection without re-applying another label requires additional sign-off.
+
+## Critical permission note
+
+The Graph `assignSensitivityLabel` API for driveItem is a **metered, protected API** that requires:
+- Metered API setup (Azure subscription linked to the tenant)
+- Admin consent for the required permissions
+- Permission scopes verified against the official reference: https://learn.microsoft.com/graph/api/driveitem-assignsensitivitylabel?view=graph-rest-1.0#permissions
+
+Per the official permissions table, the **least-privileged application permission** for this API is `Files.ReadWrite.All` (the higher-privileged alternative is `Sites.ReadWrite.All`). Graph does **not** expose a per-item or `Sites.Selected` application permission for this specific protected API, and `Files.ReadWrite` (without `.All`) is delegated-only. Because the permission floor is unavoidably coarse, the blast radius is constrained **outside** the Graph grant: via an app-only access policy / RSC, or a `Sites.Selected` site-level grant where the tenant supports it, **combined with** this guard's one-item written-approval gate, PREFLIGHT diff, and idempotency-keyed attestation. `Sites.ReadWrite.All`, `Sites.FullControl.All`, and `Directory.ReadWrite.All` remain explicitly denied.
+
+## Credential posture
+
+- App registration: use a certificate credential or managed identity — never a long-lived client secret.
+- Credentials are referenced by environment variable name only (`GRAPH_CLIENT_ID`, `GRAPH_TENANT_ID`). Never print, echo, or log credential values.
+- The app registration must have admin consent granted for all required application permissions before this skill runs.
+
+## PREFLIGHT (dry-run) requirements
+
+Before issuing the `assignSensitivityLabel` action:
+
+1. Authenticate and confirm the application user identity and consented permissions.
+2. Perform a GET on the target driveItem to retrieve the CURRENT sensitivity label:
+
+   ```http
+   GET https://graph.microsoft.com/v1.0/drives/{driveId}/items/{itemId}?$select=id,name,sensitivityLabel
+   Authorization: Bearer <token>
+   ```
+
+3. Confirm the item exists (200 OK). If 404, stop — the item does not exist.
+4. Emit the current label (id, display name, assignment method) vs the proposed label.
+5. If the proposed label would lower the classification tier, flag this explicitly and confirm justification text is present in the approval token.
+6. Present the current vs proposed label to the approver for final confirmation before writing.
+
+## Write operation
+
+```http
+POST https://graph.microsoft.com/v1.0/drives/{driveId}/items/{itemId}/assignSensitivityLabel
+Authorization: Bearer <token>
+Content-Type: application/json
+
+{
+  "sensitivityLabelId": "<approved-label-id>",
+  "assignmentMethod": "standard",
+  "justificationText": "<justification from approval token>"
+}
+```
+
+Note: `assignSensitivityLabel` is an async action on the Graph API. The response is a long-running operation. Poll the operation status URL until completion before recording the attestation result.
+
+## Rollback path
+
+- Prior sensitivity label ID captured in PREFLIGHT GET must be retained.
+- Rollback = call `assignSensitivityLabel` again on the same item with the prior label ID (re-apply prior label).
+- See ROLLBACK.md for owner, time-box, and verification steps.
+
+## Output attestation
+
+Every completed run must emit:
+
+- Idempotency key (generated before the write; used to detect replay)
+- Record of: tenant (env-var reference), drive ID, driveItem ID, item name, prior label ID + name, new label ID + name, assignment method, justification text, approval token reference
+- Audit log entry written before and after the write
+- Operation result: success (operation completed) or failure with error detail
+
+## Lean operating rules
+
+- Prefer Microsoft Learn documentation through the configured documentation MCP for Microsoft Graph and Microsoft Purview service behavior.
+- Use live Graph API evidence; label it as live configured-environment evidence.
+- Never request or accept credential values — env-var names only.
+- If the request implies bulk labeling, label policy changes, or label removal without re-application — refuse and explain why this skill cannot perform that operation.
+- State what is unknown; documentation proves service behavior, not the environment's deployed state.
+
+## Refuse conditions
+
+Immediately refuse and do not proceed if:
+
+- More than one item ID is specified
+- A wildcard, filter, or query targeting multiple items is used
+- A label policy write operation is requested
+- The approval token does not contain a justification text for a downgrade operation
+- No written approval token is provided
+- The approval token does not reference the exact drive ID + driveItem ID + label ID
+- The proposed label would remove all protection (downgrade to unlabeled) without explicit additional sign-off
+
+## Official sources
+
+- https://learn.microsoft.com/graph/api/driveitem-assignsensitivitylabel?view=graph-rest-1.0
+- https://learn.microsoft.com/graph/permissions-reference
+- https://learn.microsoft.com/microsoft-365/compliance/sensitivity-labels
+- https://learn.microsoft.com/graph/metered-api-overview
+- https://learn.microsoft.com/entra/identity-platform/app-only-access-primer

package/skills/microsoft/m365-live-sensitivity-label-apply-guard/metadata.json

@@ -0,0 +1,22 @@
+{
+  "id": "m365-live-sensitivity-label-apply-guard",
+  "name": "M365 Live Sensitivity Label Apply Guard",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Mutating-runtime live-guard for applying ONE Microsoft Purview sensitivity label to ONE specified driveItem via the Microsoft Graph assignSensitivityLabel action. One item, one label. Requires explicit written human approval token referencing exact item, proposed label, and blast-radius. PREFLIGHT reads current label before any write. Fully reversible — prior label captured; re-apply prior label is the rollback. Gate-only; never auto-dispatched. Phase B mutating-runtime.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/graph/api/driveitem-assignsensitivitylabel?view=graph-rest-1.0",
+    "https://learn.microsoft.com/graph/permissions-reference",
+    "https://learn.microsoft.com/microsoft-365/compliance/sensitivity-labels",
+    "https://learn.microsoft.com/graph/metered-api-overview",
+    "https://learn.microsoft.com/entra/identity-platform/app-only-access-primer"
+  ],
+  "security_notes": "Mutating-runtime Phase B. Narrowest label-apply Graph permission scopes only (InformationProtectionPolicy.Read.All + Sites.Selected or equivalent — verify against Graph permissions reference). Directory.ReadWrite.All, Sites.FullControl.All, Files.ReadWrite.All (broad), InformationProtectionPolicy.ReadWrite.All, and bulk labeling are all explicitly denied. Requires written human approval token referencing exact item + label + blast-radius. PREFLIGHT current-label capture required before any write. Prior label retained for ROLLBACK re-apply. Output signed with idempotency key and audit-logged.",
+  "last_verified": "2026-06-17",
+  "path": "skills/microsoft/m365-live-sensitivity-label-apply-guard",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "companion_agents": ["m365-live-sensitivity-label-apply-guard-agent"]
+}