@raishin/vanguard-frontier-agentic 2.10.0 → 2.11.0

package/skills/microsoft/m365-identity-zero-trust/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: m365-identity-zero-trust
+description: Review Microsoft Entra identity posture, Conditional Access policy design, MFA coverage, Privileged Identity Management (PIM) configuration, access reviews, and least-privilege role assignments against the Zero Trust identity pillar. Static review and advisory only; designing or reviewing Conditional Access baselines, PIM eligible/active role assignments, and access review cadences. Refuse to weaken MFA or Conditional Access for convenience. Escalate live-tenant configuration changes to live-guard gate.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-16"
+  category: security
+---
+
+# Microsoft 365 Identity Zero Trust
+
+## Purpose
+
+Act as the Microsoft Entra identity reviewer who treats every missing MFA policy, standing admin assignment, stale guest account, and unconstrained Conditional Access exclusion as a future breach until proven otherwise.
+
+## When to use
+
+Use this skill for:
+
+- Conditional Access policy design and review — baseline policies, named locations, sign-in and user risk conditions, session controls, authentication strengths
+- MFA coverage assessment — phishing-resistant MFA for admins, MFA for all users, legacy authentication blocking, security defaults vs. Conditional Access
+- Privileged Identity Management (PIM) — eligible vs. active role assignments, JIT activation, approval workflows, MFA-on-activation, access reviews for privileged roles
+- Least-privilege role assignment review — Global Administrator blast-radius reduction, role delegation by task, administrative units
+- Microsoft Entra ID Governance — access reviews, entitlement management, access packages, lifecycle workflows
+- Stale guest and external identity review — B2B collaboration, guest access reviews, external user lifecycle
+- Risky sign-in and Identity Protection signal review — risk-based Conditional Access, self-service password reset, password protection
+- Identity blast-radius analysis for overprivileged or standing admin accounts
+
+## Lean operating rules
+
+- Prefer current Microsoft Learn documentation for service behavior. Use facts in `references/official-sources.md` as starting anchors; when the user has configured read-only Microsoft Entra MCP access, use exposed read-only tools for current-state evidence instead of guessing.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Refuse to recommend weakening MFA or Conditional Access policies for convenience, exemption scope creep, or to unblock delivery. State this refusal plainly.
+- Challenge standing privileged roles, broad Conditional Access exclusions, missing break-glass account controls, and guest access without review cadence.
+- 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 identity posture review, CA baseline gap assessment, or formatting the final review.
+- [Safety checklist](references/safety-checklist.md) — use before any recommendation that changes Conditional Access policies, MFA requirements, PIM configuration, or role assignments.
+- [Official sources](references/official-sources.md) — use when grounding Microsoft Entra, Conditional Access, or PIM service behavior, or checking the detailed source list.
+- [Identity Zero Trust Domain Guide](references/identity-zero-trust-domain.md) — use for Zero Trust identity pillar failure modes, safe workflow, verification targets, and pushback criteria.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the Zero Trust identity pillar control(s) implicated and the main risks or gaps,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/microsoft/m365-identity-zero-trust/metadata.json

@@ -0,0 +1,30 @@
+{
+  "id": "m365-identity-zero-trust",
+  "name": "Microsoft 365 Identity Zero Trust",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Microsoft Entra identity posture, Conditional Access policy design, MFA coverage, Privileged Identity Management (PIM) configuration, access reviews, and least-privilege role assignments against the Zero Trust identity pillar. Static review and advisory only — designing or reviewing Conditional Access baselines and PIM — never making live tenant changes. Refuses to weaken MFA or Conditional Access for convenience.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/security/zero-trust/deploy/identity",
+    "https://learn.microsoft.com/entra/identity/conditional-access/plan-conditional-access",
+    "https://learn.microsoft.com/entra/identity/conditional-access/overview",
+    "https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-configure",
+    "https://learn.microsoft.com/entra/fundamentals/zero-trust-protect-identities"
+  ],
+  "security_notes": "Never recommend weakening MFA or Conditional Access policies for convenience, exemption scope creep, or delivery pressure. Live-tenant configuration changes — Conditional Access policy creation or modification, PIM role assignments, MFA policy changes — are live-guard gated and require explicit human confirmation, blast-radius assessment, and rollback path. Do not ask for secrets, tenant IDs, admin credentials, client secrets, certificates, or customer data. Label all evidence as sampled evidence, repo evidence, user-provided sanitized evidence, documentation-based, or inference.",
+  "last_verified": "2026-06-16",
+  "path": "skills/microsoft/m365-identity-zero-trust",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "security",
+  "companion_agents": ["m365-identity-zero-trust-agent"]
+}

package/skills/microsoft/m365-identity-zero-trust/references/identity-zero-trust-domain.md

@@ -0,0 +1,67 @@
+# Identity Zero Trust Domain Guide
+
+Use this reference for Microsoft Entra identity posture, Conditional Access design failure modes, PIM configuration, access review cadence, safe workflow, verification targets, and pushback criteria.
+
+## What people get wrong
+
+The lazy story is:
+
+> We have MFA turned on, so our identity is Zero Trust.
+
+Wrong. Zero Trust identity is about verifying every access request with all available signals, enforcing least privilege via JIT/JEA, and assuming breach by minimizing admin blast radius. MFA is necessary but insufficient — it can be bypassed by token theft, adversary-in-the-middle phishing, MFA fatigue, or legacy authentication protocols that skip MFA entirely.
+
+Common bad assumptions:
+
+- Security defaults provide equivalent protection to Conditional Access.
+- Per-user MFA enforcement is as effective as Conditional Access-enforced MFA.
+- Making admins eligible in PIM is enough without access reviews or activation requirements.
+- Excluding a few VIPs or service accounts from Conditional Access policies is acceptable with no compensating controls.
+- Blocking legacy authentication will break everything and can be deferred indefinitely.
+- A single Global Administrator account is acceptable if it has a strong password and MFA.
+- Guest access reviews are optional if external users are "trusted partners."
+
+## Identity Zero Trust failure modes
+
+- **Persistent admin assignments**: Standing Global Administrator or other privileged roles outside PIM create a permanent high-value target. A single compromised admin credential grants full tenant control.
+- **Legacy authentication not blocked**: SMTP, POP3, IMAP, Basic Auth, and older Office clients bypass Conditional Access and MFA. Credential stuffing and password spray attacks exploit these.
+- **Broad CA exclusions**: Excluding break-glass accounts, service accounts, or VIP users without monitoring and compensating controls creates undetected bypass paths.
+- **MFA fatigue**: Push-notification MFA without number matching or additional context is vulnerable to fatigue attacks. Phishing-resistant MFA (FIDO2, certificate-based auth) is required for privileged accounts.
+- **No risk-based CA**: Without Microsoft Entra ID Protection risk-based policies, compromised credentials may authenticate successfully across sessions before detection.
+- **Stale guest access**: B2B guest accounts that never went through an access review accumulate over time. Compromised guest accounts can pivot to internal resources.
+- **No break-glass monitoring**: Emergency access accounts excluded from CA policies are invisible to normal sign-in monitoring. Unauthorized use goes undetected without specific alerts.
+- **PIM without access reviews**: Converting roles to eligible status without periodic access reviews means stale eligibility accumulates — a privileged role the employee no longer needs is still one activation away.
+
+## Minimum safe workflow
+
+1. Identify all Global Administrators and privileged role holders; use PIM Discovery and Insights to find permanent assignments outside PIM.
+2. Review Conditional Access policy inventory — baseline coverage, exclusions, report-only vs. enforced, legacy authentication block status.
+3. Classify MFA gaps: which user populations, apps, or authentication flows are not covered by CA-enforced MFA.
+4. Classify PIM gaps: which privileged roles have standing active assignments instead of eligible; which eligible roles lack activation requirements (MFA, approval, time limit).
+5. Review guest and external identity lifecycle — last sign-in dates, access review schedule, cross-tenant access policies.
+6. Verify break-glass account hygiene — excluded from CA, password-based, monitored via alerts, reviewed by separate identity team.
+7. Recommend smallest safe change: enable Conditional Access in report-only mode first, pilot PIM eligible conversion before full rollout, stage legacy authentication block by protocol.
+8. Require approval and rollback plan before any Conditional Access policy moves from report-only to enforced mode.
+
+## Verification targets
+
+- PIM Discovery and Insights report — permanent active privileged role assignments to convert
+- Conditional Access policy list — enforcement mode, assignment scope, exclusions, conditions, session controls
+- Sign-in logs — legacy authentication protocol usage (filter by client app = Other clients, Exchange ActiveSync)
+- Microsoft Entra access review results — privileged roles, guest users, group memberships, application assignments
+- Authentication Methods policy — FIDO2, Microsoft Authenticator, certificate-based auth registration coverage
+- Break-glass account inventory — excluded from CA, FIDO2 or certificate-based auth, alerts configured, last review date
+- Microsoft Entra ID Protection risk detections — risky users, risky sign-ins, risk policy configuration
+- Role assignment audit log — unexpected permanent assignments or PIM activations
+
+## When to push back
+
+Push back if the user asks to:
+
+- Disable or weaken MFA for any user population to reduce friction
+- Add broad Conditional Access exclusions without time-bounded exceptions and monitoring
+- Keep standing Global Administrator assignments outside PIM because "PIM is too complex"
+- Defer blocking legacy authentication because of old client concerns without a migration plan
+- Approve Conditional Access policy changes directly in enforced mode without report-only validation
+- Remove access reviews from PIM configuration to reduce administrative overhead
+- Trust guest partner accounts without periodic access review or expiration
+- Exclude all service accounts from CA without documenting workload identity alternatives

package/skills/microsoft/m365-identity-zero-trust/references/official-sources.md

@@ -0,0 +1,64 @@
+# Official sources
+
+Use this reference only when you need source grounding for Microsoft Entra identity, Conditional Access, PIM, and Zero Trust identity pillar service behavior or the detailed source list.
+
+## Microsoft documentation
+
+Use these as starting points, not as proof of the user's live Microsoft Entra tenant state:
+
+- https://learn.microsoft.com/security/zero-trust/deploy/identity
+- https://learn.microsoft.com/entra/identity/conditional-access/plan-conditional-access
+- https://learn.microsoft.com/entra/identity/conditional-access/overview
+- https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-configure
+- https://learn.microsoft.com/entra/fundamentals/zero-trust-protect-identities
+- https://learn.microsoft.com/entra/id-governance/access-reviews-overview
+- https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-create-roles-and-resource-roles-review
+- https://learn.microsoft.com/security/zero-trust/zero-trust-identity-device-access-policies-overview
+- https://learn.microsoft.com/entra/identity/conditional-access/concept-conditional-access-policy-common
+- https://learn.microsoft.com/entra/identity/role-based-access-control/best-practices
+
+## Grounding rule
+
+Official documentation explains Microsoft Entra and Conditional Access service behavior. It does not prove the user's current tenant Conditional Access policy set, PIM configuration, role assignments, MFA enforcement state, or guest access review cadence. Prefer read-only Microsoft Entra admin evidence, Graph API read output, repository evidence, or sanitized user-provided evidence for current-state claims.
+
+## Current documentation refresh (2026-06-16)
+
+Key service facts from official Microsoft Learn documentation:
+
+**Zero Trust identity principles (per learn.microsoft.com/security/zero-trust/deploy/identity):**
+- Verify explicitly: evaluate every access request with all available signals — user, device, location, risk, app
+- Least privilege: JIT/JEA via PIM, risk-based Conditional Access, role delegation by task
+- Assume breach: minimize admin blast radius, segment privileged access, audit privileged role activations
+
+**Conditional Access (per learn.microsoft.com/entra/identity/conditional-access):**
+- Real-time Zero Trust policy engine in Microsoft Entra ID
+- Signals: user/group, location (named location/country), device state, app, sign-in risk, user risk, authentication strength
+- Common baseline policies (Microsoft Entra ID P1): require MFA for admins, require MFA for all users, block legacy authentication
+- Risk-based policies (Microsoft Entra ID P2 / Identity Protection): require MFA on medium/high sign-in risk, require password change on high user risk
+- Require phishing-resistant MFA (FIDO2/certificate-based) for privileged administrators
+
+**Privileged Identity Management (per learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-configure):**
+- Converts standing ("active") privileged role assignments to time-bound JIT ("eligible") assignments
+- Requires MFA, approval, justification, and time limit for role activation
+- Sends notifications on role activation
+- Access reviews for privileged roles — periodic re-attestation by approvers
+- PIM Discovery and Insights — identify all permanent admin assignments for conversion
+- Supports Microsoft Entra roles and resource roles (subscriptions, resource groups)
+
+**Microsoft Entra ID Governance (access reviews, entitlement management):**
+- Access reviews for groups, applications, privileged roles, and guest users
+- Entitlement management — time-bound access packages with automatic expiration
+- Lifecycle workflows — automate identity lifecycle (joiner/mover/leaver)
+
+**Common failure modes:**
+- Standing Global Administrator assignments outside PIM (permanent active admin)
+- Broad Conditional Access exclusions for VIPs, service accounts, or legacy applications without compensating controls
+- MFA gaps for guest and external users
+- Stale guest accounts without access review cadence
+- Break-glass accounts without monitoring and review procedures
+- Legacy authentication not blocked, enabling password spray / credential stuffing
+
+Review implications:
+- Do not approve CA policy designs that weaken MFA or add broad exclusions without time-bounded exceptions and compensating controls.
+- PIM eligibility alone does not prove least privilege — verify role scope, activation requirements, and review cadence.
+- Documentation cannot prove the user's actual Conditional Access policy state, PIM configuration, or role assignment coverage.

package/skills/microsoft/m365-identity-zero-trust/references/safety-checklist.md

@@ -0,0 +1,38 @@
+# Safety checklist
+
+Use this reference before any recommendation that changes Conditional Access policies, MFA requirements, PIM configuration, role assignments, guest access policies, or any other Microsoft Entra tenant configuration.
+
+## Non-negotiables
+
+- Never recommend weakening MFA coverage, adding broad Conditional Access exclusions, or disabling risk-based policies for convenience, deadline pressure, or VIP exceptions. State this refusal plainly.
+- Never ask users to paste secrets, admin credentials, tenant IDs, client secrets, certificates, private keys, or customer data into chat.
+- Use read-only Microsoft Entra admin evidence or Graph 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 Conditional Access policy states, PIM configuration, role assignment counts, or MFA enforcement coverage.
+- Require explicit user approval before recommending creation or modification of Conditional Access policies, PIM role assignments, access review configuration, or break-glass account changes.
+- Keep remediation least-privilege, reversible, staged (report mode before enforcement), and scoped to the requested role or policy boundary.
+- Treat any standing Global Administrator assignment outside PIM as critical until converted to eligible.
+- Treat any Conditional Access policy with broad exclusions (all admins excluded, no MFA for legacy apps) as high risk until compensating controls are documented.
+
+## Stress checks
+
+- What identity path can an attacker follow from initial compromise to Global Administrator?
+- What MFA or Conditional Access gap allows password spray, phishing, or credential stuffing to succeed?
+- What standing privileged role assignment widens blast radius if compromised?
+- What guest or external account has stale, unreviewed access?
+- What break-glass account monitoring gap would hide unauthorized emergency access use?
+- What rollback path exists if a new Conditional Access policy locks out users or breaks service accounts?
+
+## Evidence labels
+
+Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live Microsoft Entra tenant Conditional Access policy state, PIM configuration, or role assignment coverage.
+
+## Escalation triggers
+
+Escalate to live-guard gate before any of the following:
+
+- Creating or modifying Conditional Access policies (especially disabling, adding exclusions, or changing enforcement mode from report-only to enabled)
+- Changing PIM eligible or active role assignments for privileged roles
+- Modifying MFA registration policies or authentication methods
+- Changing external collaboration or B2B cross-tenant access policies
+- Modifying break-glass or emergency access account configurations
+- Enabling, disabling, or modifying Microsoft Entra ID Protection risk policies

package/skills/microsoft/m365-identity-zero-trust/references/workflow-and-output.md

@@ -0,0 +1,65 @@
+# Workflow and output contract
+
+Use this reference only when performing the full identity posture review, Conditional Access baseline gap assessment, or formatting the final review.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- **MFA coverage**: Admin MFA (phishing-resistant), all-user MFA, legacy authentication block, security defaults vs. Conditional Access tradeoffs
+- **Conditional Access baseline**: Common policies (admin MFA, all-user MFA, legacy block, device compliance, app protection), named location inventory, session controls, authentication strengths
+- **Risk-based policies**: Sign-in risk and user risk policies (requires Identity Protection / Entra ID P2), self-remediation flows
+- **Privileged Identity Management**: Standing vs. eligible role assignments, activation requirements (MFA, approval, justification, time limit), PIM Discovery and Insights, access review cadence for privileged roles
+- **Least-privilege role assignments**: Global Administrator count and alternatives, role delegation by task, administrative units, custom roles
+- **Microsoft Entra ID Governance**: Access reviews for groups, apps, privileged roles, and guest users; entitlement management expiration; lifecycle workflows
+- **Guest and external identity**: B2B collaboration settings, guest access reviews, cross-tenant access policies, external user lifecycle
+- **Break-glass accounts**: Emergency access accounts, excluded from CA policies, monitored via alerts, reviewed regularly
+
+## Safe workflow
+
+1. **Frame scope**
+   - Tenant / environment / licensing tier (Entra ID P1 or P2):
+   - Administrator count and role inventory:
+   - Data classification and compliance driver:
+   - Required outcome:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer read-only Microsoft Entra admin evidence or Graph API read output for current-state claims when available.
+   - Otherwise inspect repository IaC/config (Bicep, Terraform, JSON), 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**
+   - What identity path can an attacker use to escalate to Global Administrator?
+   - What MFA or Conditional Access gap allows password spray or phishing to succeed?
+   - What standing privileged assignment widens blast radius?
+   - What guest or external identity has stale access?
+   - What compliance or audit evidence is missing?
+   - What rollback or validation path is unproven for CA changes?
+4. **Recommend the smallest safe action**
+   - Prefer report mode for new CA policies, staged rollout (pilot group), PIM eligible before active, and access reviews before removal.
+   - If the safest action is to stop and gather evidence before making changes, say that plainly.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# M365 Identity Zero Trust Review: <scope>
+## Executive verdict
+- Status: READY / READY WITH RISKS / NOT READY / NEEDS EVIDENCE
+- Biggest risk:
+- 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-intune-endpoint-management/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: m365-intune-endpoint-management
+description: Review and advise on Microsoft Intune endpoint management posture covering device enrollment, compliance policies, configuration profiles, app protection (MAM) policies, Conditional Access device-compliance signal, Windows Autopilot, update rings, and endpoint security baselines. Applies Zero Trust device-health-as-signal principles. Static review and advisory only; production compliance-policy or Conditional Access-impacting changes and device wipe or retire actions are live-guard gated. Refuses to weaken device compliance or Conditional Access requirements for convenience.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: platform
+---
+
+# Microsoft 365 Intune Endpoint Management
+
+## Purpose
+
+Act as the Microsoft Intune endpoint management reviewer who treats every unmanaged device, every unenforced compliance policy, and every missing app protection policy as a potential breach vector until proven otherwise. Device health is a Zero Trust signal — devices that cannot prove compliance must not access corporate resources.
+
+## When to use
+
+Use this skill for:
+
+- Device enrollment review — Microsoft Entra join, Hybrid join, Windows Autopilot, Apple Automated Device Enrollment (ADE), Android Enterprise enrollment, and personally owned device (BYOD) approaches
+- Compliance policy design and gap assessment — minimum OS version, BitLocker encryption, Secure Boot, Defender health, jailbreak/root detection, and noncompliance actions
+- Configuration profile review — device restrictions, endpoint protection, Wi-Fi, VPN, certificates, and Settings Catalog profiles
+- App protection (MAM) policy review — data transfer restrictions, PIN requirements, managed browser controls, and level 2 enterprise enhanced data protection for unmanaged and managed devices
+- Conditional Access device-compliance signal review — require compliant device or Microsoft Entra hybrid join policies, app protection policy enforcement
+- Windows Autopilot review — Autopilot deployment profile, enrollment status page (ESP), hybrid join configuration, and device group tag strategy
+- Update rings and feature update policy review — deferral periods, deadlines, active hours, pilot vs. broad rings, Windows Autopatch
+- Endpoint security baseline review — Windows security baseline, Microsoft Defender for Endpoint baseline, Microsoft Edge baseline, compliance with industry frameworks
+- Endpoint Privilege Management (EPM) — standard user elevation, least-privilege endpoint access
+- Defender for Endpoint integration — device risk signal feeding Conditional Access, vulnerability remediation workflow
+
+## Lean operating rules
+
+- Prefer current Microsoft Learn documentation for service behavior. Use facts in `references/official-sources.md` as starting anchors; when the user has configured read-only Intune or Microsoft Graph MCP access, use exposed read-only tools for current-state evidence instead of guessing.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Refuse to recommend weakening device compliance policies, removing Conditional Access device-compliance requirements, or creating broad noncompliance exceptions for delivery pressure or VIP exemptions. State this refusal plainly.
+- Challenge unmanaged device access to corporate resources, missing app protection policies for BYOD scenarios, unenforced update rings, and missing Defender for Endpoint integration.
+- 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 endpoint management posture review or formatting the final review.
+- [Safety checklist](references/safety-checklist.md) — use before any recommendation that changes compliance policies, Conditional Access, update rings, or triggers device actions.
+- [Official sources](references/official-sources.md) — use when grounding Intune, Autopilot, endpoint security baseline, or update ring service behavior, or checking the detailed source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the Zero Trust device-health control(s) implicated and the main risks or gaps,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/microsoft/m365-intune-endpoint-management/metadata.json

@@ -0,0 +1,32 @@
+{
+  "id": "m365-intune-endpoint-management",
+  "name": "Microsoft 365 Intune Endpoint Management",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review and advise on Microsoft Intune endpoint management posture covering device enrollment, compliance policies, configuration profiles, app protection (MAM) policies, Conditional Access device-compliance signal, Windows Autopilot, update rings, and endpoint security baselines. Applies Zero Trust device-health-as-signal principles — treating every unmanaged or noncompliant device as untrusted until proven otherwise. Static review and advisory only; production compliance-policy or Conditional Access changes, and device wipe or retire actions, are live-guard gated and require explicit human confirmation.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/intune/fundamentals/zero-trust",
+    "https://learn.microsoft.com/security/zero-trust/manage-devices-with-intune-overview",
+    "https://learn.microsoft.com/security/zero-trust/manage-devices-with-intune-compliance-policies",
+    "https://learn.microsoft.com/intune/device-security/security-baselines/overview",
+    "https://learn.microsoft.com/intune/device-updates/windows/manage-update-rings",
+    "https://learn.microsoft.com/autopilot/windows-autopilot-overview",
+    "https://learn.microsoft.com/intune/device-security/endpoint-security-policies"
+  ],
+  "security_notes": "Never recommend weakening device compliance policies or Conditional Access device-compliance requirements for convenience, delivery pressure, or broad exclusions. Production compliance-policy changes, Conditional Access policy creation or modification that affects device compliance signal, and device wipe or retire actions are live-guard gated and require explicit human confirmation, blast-radius assessment, and rollback path. Do not request secrets, tenant IDs, admin credentials, client secrets, certificates, or customer data. Label all findings as live evidence, repo evidence, user-provided sanitized evidence, documentation-based, or inference. Challenge standing noncompliance exceptions, unmanaged device access, missing app protection policies for unmanaged devices, and unenforced update rings.",
+  "last_verified": "2026-06-17",
+  "path": "skills/microsoft/m365-intune-endpoint-management",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "platform",
+  "companion_agents": ["m365-intune-endpoint-management-agent"]
+}

package/skills/microsoft/m365-intune-endpoint-management/references/official-sources.md

@@ -0,0 +1,66 @@
+# Official sources
+
+Use this reference only when you need source grounding for Microsoft Intune endpoint management, device compliance, app protection, Windows Autopilot, update rings, endpoint security baselines, or Zero Trust device-health-as-signal service behavior.
+
+## Microsoft documentation
+
+Use these as starting points, not as proof of the user's live Intune tenant state:
+
+- https://learn.microsoft.com/intune/fundamentals/zero-trust
+- https://learn.microsoft.com/security/zero-trust/manage-devices-with-intune-overview
+- https://learn.microsoft.com/security/zero-trust/manage-devices-with-intune-compliance-policies
+- https://learn.microsoft.com/security/zero-trust/manage-devices-with-intune-app-protection
+- https://learn.microsoft.com/intune/device-security/security-baselines/overview
+- https://learn.microsoft.com/intune/device-updates/windows/manage-update-rings
+- https://learn.microsoft.com/autopilot/windows-autopilot-overview
+- https://learn.microsoft.com/intune/device-security/endpoint-security-policies
+- https://learn.microsoft.com/intune/device-security/compliance/overview
+- https://learn.microsoft.com/intune/apps/app-protection-policy
+
+## Grounding rule
+
+Official documentation explains Microsoft Intune and endpoint management service behavior. It does not prove the user's current Intune compliance policy assignments, enrollment state, app protection policy coverage, update ring enforcement, or Defender for Endpoint integration status. Prefer read-only Intune admin center evidence, Microsoft Graph read output, repository evidence, or sanitized user-provided evidence for current-state claims.
+
+## Current documentation refresh (2026-06-17)
+
+Key service facts from official Microsoft Learn documentation:
+
+**Zero Trust with Intune (per learn.microsoft.com/intune/fundamentals/zero-trust):**
+- Verify explicitly: Intune compliance policies validate device health (OS version, encryption, Defender status, PIN) as a Conditional Access signal
+- Least privilege: Endpoint Privilege Management (EPM) allows standard users to complete elevation tasks without standing local admin rights; LAPS manages local administrator credentials
+- Assume breach: Intune integrates with Microsoft Defender for Endpoint for mobile threat defense, device risk scoring, and vulnerability remediation workflows via Security Copilot
+
+**Compliance policies (per learn.microsoft.com/security/zero-trust/manage-devices-with-intune-compliance-policies):**
+- Define minimum device health requirements per platform (Windows, iOS/iPadOS, Android, macOS)
+- Noncompliant devices trigger configurable actions: mark noncompliant, notify user, block, retire
+- Compliance signals feed Conditional Access — "require compliant device" policy blocks noncompliant access
+- Devices must be enrolled in Intune before compliance policies apply
+
+**App protection (MAM) policies (per learn.microsoft.com/security/zero-trust/manage-devices-with-intune-app-protection):**
+- Level 2 enterprise enhanced data protection is the recommended starting level for devices accessing sensitive data
+- MAM policies protect corporate data in managed apps without requiring device enrollment
+- Key controls: restrict cut/copy/paste to managed apps, require PIN, block backup to personal storage, require managed browser, wipe corporate data on unenrollment
+- Coordinate MAM policies with Conditional Access "require approved app and app protection" policy
+
+**Security baselines (per learn.microsoft.com/intune/device-security/security-baselines/overview):**
+- Preconfigured groups of Windows settings recommended by Microsoft security teams
+- Available baselines: Windows MDM security baseline, Microsoft Defender for Endpoint baseline, Microsoft Edge baseline
+- Test in isolation before broad deployment — some settings may conflict with Windows Autopilot or application delivery
+
+**Update rings (per learn.microsoft.com/intune/device-updates/windows/manage-update-rings):**
+- Control Windows update deferral periods, deadlines, restart behavior, and active hours
+- Common ring structure: test (0-day deferral), pilot (7-day), broad (14-21 day)
+- Windows Autopatch manages ring cadence automatically for qualifying tenants
+
+**Common failure modes:**
+- No app protection policies for BYOD/unmanaged devices accessing corporate data
+- Compliance policies assigned but Conditional Access not enforcing "require compliant device"
+- Missing Defender for Endpoint integration — device risk not flowing to Conditional Access
+- Update rings defined but not assigned — endpoints receiving updates without deferral control
+- Security baselines not tested before broad deployment causing application compatibility issues
+- Autopilot profiles missing enrollment status page (ESP) — users reaching desktop before policy applies
+
+Review implications:
+- Do not approve Conditional Access designs that allow noncompliant devices as a broad exception without compensating controls.
+- Compliance policy assignment alone is insufficient — verify that Conditional Access is enforcing the compliance signal.
+- Documentation cannot prove the user's actual Intune enrollment coverage, compliance policy assignments, or Defender for Endpoint integration state.

package/skills/microsoft/m365-intune-endpoint-management/references/safety-checklist.md

@@ -0,0 +1,39 @@
+# Safety checklist
+
+Use this reference before any recommendation that changes Intune compliance policies, Conditional Access device-compliance requirements, app protection policies, update ring enforcement, security baselines, or triggers any device action (wipe, retire, sync, restart).
+
+## Non-negotiables
+
+- Never recommend weakening device compliance requirements, adding broad noncompliance exceptions, or disabling Conditional Access device-compliance enforcement for convenience, deadline pressure, or VIP exceptions. State this refusal plainly.
+- Never ask users to paste secrets, admin credentials, tenant IDs, client secrets, certificates, private keys, or customer data into chat.
+- Use read-only Intune admin center evidence or Microsoft Graph 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 Intune enrollment coverage, compliance policy assignments, app protection policy states, update ring assignments, or Defender for Endpoint integration status.
+- Require explicit user approval before recommending compliance policy creation or modification, Conditional Access changes that affect device-compliance enforcement, update ring enforcement changes, security baseline deployments, or any device action such as wipe or retire.
+- Keep remediation least-privilege, reversible, staged (audit or report mode before enforcement), and scoped to the requested device group or policy boundary.
+- Treat any corporate resource accessible from an unmanaged or unenrolled device without app protection policies as high risk until protected.
+- Treat any compliance policy assignment that is not enforced by Conditional Access as a gap — compliance without enforcement is advisory only.
+
+## Stress checks
+
+- What device path allows an attacker with stolen credentials to reach corporate resources from an unmanaged or noncompliant device?
+- What app protection gap allows corporate data to exit the managed app boundary to personal storage or unmanaged apps?
+- What update ring gap leaves endpoints exposed to known CVEs beyond the approved deferral window?
+- What compliance policy is defined and assigned but not enforced by Conditional Access?
+- What security baseline conflict or missing configuration profile leaves a known security setting unconfigured?
+- What rollback path exists if a compliance policy or Conditional Access change causes a broad device lockout or service account disruption?
+
+## Evidence labels
+
+Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live Intune enrollment state, compliance policy assignments, app protection policy coverage, or update ring enforcement.
+
+## Escalation triggers
+
+Escalate to live-guard gate before any of the following:
+
+- Creating or modifying Intune compliance policies affecting Conditional Access enforcement
+- Changing Conditional Access policies that reference device compliance or app protection requirements
+- Modifying or deploying endpoint security baselines to production device groups
+- Changing Windows update ring deferral periods or deadline enforcement on production ring assignments
+- Triggering device actions (wipe, retire, fresh start, remote lock) on production devices
+- Enabling or disabling Microsoft Defender for Endpoint integration with Intune
+- Changing Windows Autopilot deployment profiles or enrollment status page configuration for production device groups

package/skills/microsoft/m365-intune-endpoint-management/references/workflow-and-output.md

@@ -0,0 +1,67 @@
+# Workflow and output contract
+
+Use this reference only when performing the full Intune endpoint management posture review or formatting the final review.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- **Device enrollment coverage**: Enrolled vs. unmanaged device ratio, enrollment methods per platform (Microsoft Entra join, Hybrid join, Windows Autopilot, Apple ADE, Android Enterprise), and BYOD enrollment policy
+- **Compliance policies**: Per-platform compliance requirements (OS version, encryption, Defender health, jailbreak/root detection), noncompliance actions, grace periods, and Conditional Access "require compliant device" enforcement
+- **Configuration profiles**: Device restriction profiles, endpoint protection profiles, Settings Catalog profiles, Wi-Fi and VPN certificate delivery, and profile conflict detection
+- **App protection (MAM) policies**: Data transfer restrictions, PIN requirements, managed browser enforcement, level 2 protection coverage, and unmanaged device coverage
+- **Conditional Access device-compliance signal**: Require compliant device or Microsoft Entra hybrid join enforcement, app protection policy requirement, named location and platform conditions
+- **Windows Autopilot**: Deployment profiles, enrollment status page (ESP) configuration, device group tag strategy, and hybrid join vs. cloud-native architecture
+- **Update rings and feature updates**: Ring structure (test/pilot/broad), deferral periods, deadline enforcement, Windows Autopatch adoption, and ring assignment coverage
+- **Endpoint security baselines**: Baseline selection, customization from defaults, conflict detection, and compliance monitoring
+- **Endpoint Privilege Management (EPM)**: Standard user elevation policies, elevation rules, and LAPS configuration
+- **Defender for Endpoint integration**: Intune connector status, device risk signal feeding Conditional Access, and vulnerability remediation task workflow
+
+## Safe workflow
+
+1. **Frame scope**
+   - Tenant / environment / licensing tier (Intune Plan 1 or Plan 2):
+   - Device platform mix and enrollment method:
+   - BYOD vs. corporate-owned split:
+   - Required outcome:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer read-only Intune admin center evidence or Microsoft Graph read output for current-state claims when available.
+   - Otherwise inspect repository IaC/config (Bicep, Terraform, JSON exports), 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**
+   - What device path allows an attacker with stolen credentials to access corporate resources from an unmanaged or noncompliant device?
+   - What app protection gap allows corporate data to leak from a managed app to personal storage or an unmanaged app?
+   - What update ring gap leaves endpoints exposed to known vulnerabilities beyond acceptable deferral windows?
+   - What compliance policy is assigned but not enforced by Conditional Access?
+   - What baseline conflict or missing profile leaves a security configuration gap?
+   - What rollback path exists if a compliance policy or security baseline change causes a broad lockout?
+4. **Recommend the smallest safe action**
+   - Prefer report mode for new compliance policies, staged rollout (pilot group), app protection policy in audit mode before enforcement, and update ring testing before broad assignment.
+   - If the safest action is to stop and gather evidence before making changes, say that plainly.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# M365 Intune Endpoint Management Review: <scope>
+## Executive verdict
+- Status: READY / READY WITH RISKS / NOT READY / NEEDS EVIDENCE
+- Biggest risk:
+- 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>
+```