@raishin/vanguard-frontier-agentic 2.9.0 → 2.11.0

package/skills/microsoft/m365-defender-xdr-security-operations/references/official-sources.md

@@ -0,0 +1,79 @@
+# Official sources
+
+Use this reference only when you need source grounding for Microsoft Defender XDR security operations — incident response, advanced hunting, AIR, attack disruption, Defender signal sources, and Microsoft Sentinel integration — or the detailed source list.
+
+## Microsoft documentation
+
+Use these as starting points, not as proof of the user's live Microsoft Defender XDR tenant incident state:
+
+- https://learn.microsoft.com/defender-xdr/microsoft-365-defender
+- https://learn.microsoft.com/defender-xdr/advanced-hunting-overview
+- https://learn.microsoft.com/defender-xdr/m365d-autoir
+- https://learn.microsoft.com/defender-xdr/incident-queue
+- https://learn.microsoft.com/defender-xdr/automatic-attack-disruption
+- https://learn.microsoft.com/security/zero-trust/siem-xdr-overview
+- https://learn.microsoft.com/defender-xdr/m365d-configure-auto-investigation-response
+- https://learn.microsoft.com/defender-xdr/advanced-hunting-schema-tables
+- https://learn.microsoft.com/defender-xdr/custom-detection-rules
+- https://learn.microsoft.com/defender-xdr/pilot-deploy-investigate-respond
+
+## Grounding rule
+
+Official documentation explains Microsoft Defender XDR and Sentinel service behavior. It does not prove the user's current incident queue state, AIR automation level, advanced hunting coverage, or Sentinel analytics rule deployment. Prefer read-only Defender XDR portal evidence, Graph Security API 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:
+
+**Microsoft Defender XDR unified platform (per learn.microsoft.com/defender-xdr/microsoft-365-defender):**
+- Unified incident queue in the Microsoft Defender portal correlates alerts from Defender for Endpoint, Defender for Office 365, Defender for Identity, and Defender for Cloud Apps into single incidents
+- Incidents expose the complete attack story including affected entities, alert timeline, evidence, and automated investigation results
+- Automatic attack disruption uses high-fidelity signals from incident correlation to contain active attacks at machine speed — isolating compromised devices and disabling compromised accounts without waiting for analyst action
+- Zero Trust assume-breach principle: treat every unconfirmed incident as active; minimize lateral movement window by acting on disruption signals quickly
+
+**Advanced hunting with KQL (per learn.microsoft.com/defender-xdr/advanced-hunting-overview):**
+- Query-based proactive threat hunting across up to 30 days of raw data using Kusto Query Language (KQL)
+- Schema tables include: EmailEvents, EmailAttachmentInfo, DeviceFileEvents, DeviceProcessEvents, IdentityDirectoryEvents, IdentityQueryEvents, CloudAuditEvents, CloudProcessEvents, CloudStorageAggregatedEvents
+- Guided mode enables visual query construction without KQL for analysts learning the schema
+- Custom detection rules run advanced hunting queries on a schedule and generate alerts or response actions automatically
+- FileProfile() function enriches file SHA256 hashes with threat intelligence including prevalence, signer, and issuer data
+
+**Automated investigation and response — AIR (per learn.microsoft.com/defender-xdr/m365d-autoir):**
+- AIR automatically investigates alerts and produces verdicts: malicious, suspicious, or no threats found
+- Remediation actions from AIR include: quarantine file, stop process, block URL, isolate device
+- Action Center shows all pending and completed remediation actions requiring approval or review
+- Automation level for device groups controls whether AIR remediates automatically (Full) or requires analyst approval (Semi or None)
+- Recommended setting: Full — remediate threats automatically for mature SOC environments with tested playbooks
+
+**Automatic attack disruption (per learn.microsoft.com/defender-xdr/automatic-attack-disruption):**
+- High-confidence containment of active attacks at machine speed: isolates compromised endpoints, disables compromised user accounts
+- Triggered by incident correlation signals; marked clearly in the Defender XDR incident queue
+- Does not require analyst action to trigger; analysts review and can reverse disruption actions in Action Center
+
+**Defender signal sources:**
+- Defender for Endpoint: device risk, behavioral analytics, EDR, file and process telemetry
+- Defender for Office 365: phishing, malware in email, safe links, safe attachments, threat explorer
+- Defender for Identity: lateral movement, credential harvesting, domain controller activity, pass-the-hash/ticket
+- Defender for Cloud Apps: shadow IT, OAuth app anomalies, cloud discovery, anomalous session activity
+
+**Microsoft Sentinel integration (per learn.microsoft.com/security/zero-trust/siem-xdr-overview):**
+- Microsoft Sentinel workspaces can be onboarded to the Defender portal for unified SIEM-XDR incident management
+- Sentinel analytics rules generate alerts that correlate with Defender XDR incidents
+- Sentinel playbooks (Logic Apps) automate response actions and can be triggered by Defender XDR incidents
+- Advanced hunting in the unified portal queries both Defender XDR and Sentinel data sources
+
+**SC-200 certification anchor:**
+- SC-200 Security Operations Analyst Associate validates threat mitigation using Microsoft Defender XDR, Microsoft Sentinel, Defender for Endpoint, Defender for Identity, Defender for Office 365, and Defender for Cloud Apps
+
+**Common failure modes:**
+- AIR automation level set to None or Semi for all device groups, requiring manual approval for every remediation action and slowing response significantly
+- Advanced hunting not used proactively; SOC relies only on alert-driven investigation without hunting for precursor indicators
+- Incident queue not triaged by severity; high-severity incidents assigned alongside low-severity noise without prioritization
+- Custom detection rules not deployed for organization-specific threat patterns, leaving KQL hunting insights unused
+- Microsoft Sentinel analytics rules not tuned, generating high false-positive volumes that suppress analyst attention to true positives
+- Automatic attack disruption actions not reviewed post-containment, leaving disrupted users or devices isolated beyond the threat window
+
+Review implications:
+- Do not recommend changing AIR automation levels without assessing the current false-positive rate and incident volume.
+- Containment actions initiated outside of automatic attack disruption require explicit SecOps owner approval — escalate immediately.
+- Documentation cannot prove the user's actual incident queue state, AIR automation level, or Sentinel analytics rule coverage.

package/skills/microsoft/m365-defender-xdr-security-operations/references/safety-checklist.md

@@ -0,0 +1,44 @@
+# Safety checklist
+
+Use this reference before any recommendation that involves containment actions, AIR automation level changes, automated-response policy modifications, Sentinel playbook execution, or any other live Microsoft Defender XDR or Sentinel production action.
+
+## Non-negotiables
+
+- Never recommend or initiate device isolation, user account disable, file or URL block, process termination, or any other containment action without explicit SecOps owner approval and a documented blast-radius assessment. State this escalation requirement plainly.
+- Never recommend changing AIR automation levels (especially from Semi to Full for untested device groups) without a false-positive rate assessment and a tested rollback procedure.
+- Never recommend executing Sentinel playbooks against production environments without a dry-run validation and SecOps owner approval.
+- Never ask users to paste secrets, admin credentials, tenant IDs, API keys, certificates, private keys, or customer data into chat.
+- Use read-only Defender XDR portal evidence, Graph Security API read evidence, or Sentinel workspace query results for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
+- Do not invent incident states, AIR verdicts, alert volumes, or Sentinel analytics rule coverage.
+- Require explicit SecOps owner approval before recommending any containment action, AIR configuration change, custom detection rule deployment, or Sentinel playbook modification.
+- Keep remediation least-privilege, reversible, staged (advisory before live execution), and scoped to the requested threat scenario.
+- Apply Zero Trust assume-breach: treat every unconfirmed incident as active and every unreviewed containment reversal as a potential re-exposure risk.
+- Treat any AIR automation level set to None for all device groups as a gap — manual-only remediation creates unacceptable response latency for ransomware and lateral movement scenarios.
+
+## Stress checks
+
+- What containment action is being recommended, and has the SecOps owner explicitly approved it?
+- What is the blast radius if the device isolation or account disable is incorrect (wrong device, wrong user)?
+- What rollback path exists to restore a contained device or re-enable a disabled account if the containment was a false positive?
+- What AIR device group automation level change is being recommended, and has the false-positive rate been assessed for that group?
+- What Sentinel playbook is being triggered, and has it been validated in a non-production environment?
+- What post-containment review cadence confirms that disrupted entities are safe to restore?
+- What advanced hunting query is being run in production, and does it scope to a time-bounded read-only query with no response actions?
+
+## Evidence labels
+
+Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live Microsoft Defender XDR incident state, AIR automation level, or Sentinel analytics rule deployment.
+
+## Escalation triggers
+
+Escalate to SecOps owner live-guard gate before any of the following:
+
+- Initiating device isolation, network containment, or any endpoint response action in Defender for Endpoint
+- Disabling user accounts, revoking sessions, or blocking sign-in in Microsoft Entra ID as a containment response
+- Blocking files, URLs, IP addresses, or domains via Defender for Endpoint indicators
+- Changing AIR automation levels for any device group (especially Semi to Full or Full to None)
+- Approving or rejecting pending AIR remediation actions in the Action Center for high-severity incidents
+- Creating, modifying, or enabling Sentinel analytics rules that would fire on production data
+- Triggering Sentinel playbooks against production resources or user accounts
+- Modifying custom detection rules that generate automatic response actions
+- Reversing automatic attack disruption actions (restoring isolated devices, re-enabling disrupted accounts)

package/skills/microsoft/m365-defender-xdr-security-operations/references/workflow-and-output.md

@@ -0,0 +1,66 @@
+# Workflow and output contract
+
+Use this reference only when performing a full Microsoft Defender XDR SecOps posture review, incident triage assessment, advanced hunting gap analysis, or formatting the final review output.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- **Incident queue**: Severity distribution and triage coverage, incident assignment workflow, SLA for high-severity incident response, unified queue coverage across all Defender signal sources
+- **Alert correlation**: Cross-product signal correlation across Defender for Endpoint, Defender for Office 365, Defender for Identity, and Defender for Cloud Apps; manual alert correlation gaps; false-positive rate and suppression rules
+- **Advanced hunting**: KQL query library coverage for key threat scenarios, custom detection rule deployment, schema table coverage, FileProfile() and threat intelligence enrichment, guided mode vs. advanced mode usage
+- **Automated investigation and response (AIR)**: Device group automation level (Full vs. Semi vs. None), Action Center pending action backlog, AIR false-positive rate, approval workflow for semi-automated groups
+- **Automatic attack disruption**: Disruption signal review cadence, post-disruption entity review (isolated devices, disabled accounts), disruption reversal workflow
+- **Containment and response runbooks**: Device isolation procedures, user account disable procedures, file and URL block procedures, incident closure criteria, escalation paths to SecOps owner
+- **Defender signal sources**: Defender for Endpoint onboarding coverage, Defender for Office 365 policy configuration, Defender for Identity sensor coverage on domain controllers, Defender for Cloud Apps connected apps inventory
+- **Microsoft Sentinel integration**: Workspace onboarding status, analytics rule coverage and tuning, playbook automation for common response actions, SIEM-XDR unified incident queue configuration
+
+## Safe workflow
+
+1. **Frame scope**
+   - Tenant / environment / licensing tier (Microsoft 365 E5, Microsoft 365 Defender, or standalone):
+   - SOC maturity level and analyst headcount:
+   - Key threat scenarios in scope (ransomware, BEC, insider, supply chain):
+   - Required outcome:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer read-only Defender XDR portal evidence, Graph Security API read output, or Sentinel workspace query results for current-state claims when available.
+   - Otherwise inspect repository configuration files, exported policy 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 active incident or alert in the queue has not been triaged within SLA?
+   - What Defender signal source has onboarding or coverage gaps leaving devices, identities, or cloud apps unmonitored?
+   - What advanced hunting scenario has no KQL query or custom detection rule covering it?
+   - What AIR device group is set to None or Semi, creating a manual approval bottleneck?
+   - What containment runbook is missing, untested, or lacks a defined escalation path to the SecOps owner?
+   - What Sentinel analytics rule is generating excessive false positives, suppressing analyst attention to real threats?
+   - What post-disruption review cadence exists for automatically isolated devices or disabled accounts?
+4. **Recommend the smallest safe action**
+   - Prefer advisory and runbook review mode for containment recommendations; never recommend live execution without SecOps owner approval.
+   - If the safest action is to stop and gather evidence before making changes, say that plainly.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# Defender XDR SecOps 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-exchange-sharepoint-information-governance/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: m365-exchange-sharepoint-information-governance
+description: Review and advise on Exchange Online and SharePoint Online plus OneDrive information governance covering mailbox and site lifecycle, external and anonymous sharing controls, SharePoint Advanced Management (Restricted Content Discovery, site access reviews, data access governance reports), retention and records management via Microsoft Purview, oversharing remediation feeding Microsoft 365 Copilot readiness, and information architecture. Cert anchor MS-102. Static review and advisory only; tenant sharing-policy changes and retention or hold changes are live-guard gated. Refuses to weaken sharing controls or remove holds for convenience.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: data
+---
+
+# Microsoft 365 Exchange and SharePoint Information Governance
+
+## Purpose
+
+Act as the Exchange Online and SharePoint Online information governance reviewer who treats every Anyone sharing link, every EEEU (Everyone Except External Users) overshare, every missing retention policy, and every ownerless or inactive site as a data protection risk and Copilot readiness blocker until proven otherwise. Information governance is the foundation of safe AI grounding.
+
+## When to use
+
+Use this skill for:
+
+- Mailbox lifecycle review — archive mailbox enablement, inactive mailbox policies, shared mailbox governance, resource mailbox hygiene, and mailbox size management
+- Site lifecycle review — SharePoint site ownership policies, inactive site detection and archival, Microsoft 365 Archive, site attestation policies, and orphaned site remediation
+- External and anonymous sharing controls — tenant-level SharePoint and OneDrive sharing settings, site-level sharing overrides, Anyone link expiration, link permission defaults, and guest link hygiene
+- SharePoint Advanced Management (SAM) — Restricted Content Discovery for high-risk sites, Restricted Access Control (RAC), data access governance (DAG) reports, site access reviews, site policy comparison, and SharePoint Admin Agent
+- Oversharing remediation and Copilot readiness — EEEU insights, sharing link activity reports, permission state reports, sensitivity label distribution, and prioritized remediation for Copilot deployment
+- Retention and records management — Microsoft Purview retention policies and labels for Exchange Online and SharePoint Online, records declaration, event-based retention, and adaptive policy scopes
+- Hold and eDiscovery readiness — litigation hold, eDiscovery hold review, and recoverable items folder hygiene
+- Information architecture — hub site structure, site collections, sensitivity label application to SharePoint sites, and content type governance
+
+## 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 SharePoint admin 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 tenant-wide sharing policies, removing retention holds, or disabling Restricted Content Discovery for delivery pressure, Copilot rollout speed, or convenience. State this refusal plainly.
+- Challenge Anyone sharing links, EEEU oversharing, missing site ownership, inactive sites without lifecycle policy, and retention gaps ahead of Copilot enablement.
+- 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 information governance review or formatting the final review.
+- [Safety checklist](references/safety-checklist.md) — use before any recommendation that changes tenant sharing settings, retention policies, holds, or site access restrictions.
+- [Official sources](references/official-sources.md) — use when grounding SharePoint Advanced Management, retention, sharing policy, or Exchange Online governance service behavior, or checking the detailed source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the governance 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-exchange-sharepoint-information-governance/metadata.json

@@ -0,0 +1,32 @@
+{
+  "id": "m365-exchange-sharepoint-information-governance",
+  "name": "Microsoft 365 Exchange and SharePoint Information Governance",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review and advise on Exchange Online and SharePoint Online plus OneDrive information governance covering mailbox and site lifecycle, external and anonymous sharing controls, SharePoint Advanced Management (Restricted Content Discovery, site access reviews, data access governance reports), retention and records management via Microsoft Purview, oversharing remediation feeding Microsoft 365 Copilot readiness, and information architecture. Cert anchor MS-102 Microsoft 365 Administrator. Static review and advisory only; tenant sharing-policy changes and retention or hold changes are live-guard gated and require explicit human confirmation.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/sharepoint/advanced-management",
+    "https://learn.microsoft.com/sharepoint/restricted-content-discovery",
+    "https://learn.microsoft.com/sharepoint/data-access-governance-reports",
+    "https://learn.microsoft.com/sharepoint/get-ready-copilot-sharepoint-advanced-management",
+    "https://learn.microsoft.com/purview/retention",
+    "https://learn.microsoft.com/sharepoint/turn-external-sharing-on-or-off",
+    "https://learn.microsoft.com/training/paths/explore-data-governance-microsoft-365/"
+  ],
+  "security_notes": "Never recommend weakening tenant-wide sharing policies, disabling retention holds, or removing Restricted Content Discovery controls for convenience, delivery pressure, or Copilot rollout speed. Tenant sharing-policy changes, retention or hold changes, and site access restriction policy changes 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 Anyone sharing links, EEEU (Everyone Except External Users) oversharing, missing site ownership, inactive sites without lifecycle policy, and retention gaps ahead of Copilot enablement.",
+  "last_verified": "2026-06-17",
+  "path": "skills/microsoft/m365-exchange-sharepoint-information-governance",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "data",
+  "companion_agents": ["m365-exchange-sharepoint-information-governance-agent"]
+}

package/skills/microsoft/m365-exchange-sharepoint-information-governance/references/official-sources.md

@@ -0,0 +1,64 @@
+# Official sources
+
+Use this reference only when you need source grounding for Exchange Online and SharePoint Online information governance, SharePoint Advanced Management, external and anonymous sharing controls, Microsoft Purview retention and records management, or Microsoft 365 Copilot oversharing readiness service behavior.
+
+## Microsoft documentation
+
+Use these as starting points, not as proof of the user's live Exchange or SharePoint tenant state:
+
+- https://learn.microsoft.com/sharepoint/advanced-management
+- https://learn.microsoft.com/sharepoint/restricted-content-discovery
+- https://learn.microsoft.com/sharepoint/data-access-governance-reports
+- https://learn.microsoft.com/sharepoint/get-ready-copilot-sharepoint-advanced-management
+- https://learn.microsoft.com/sharepoint/turn-external-sharing-on-or-off
+- https://learn.microsoft.com/sharepoint/restricted-access-control
+- https://learn.microsoft.com/sharepoint/site-lifecycle-management
+- https://learn.microsoft.com/purview/retention
+- https://learn.microsoft.com/purview/enable-archive-mailboxes
+- https://learn.microsoft.com/training/paths/explore-data-governance-microsoft-365/
+
+## Grounding rule
+
+Official documentation explains SharePoint Online, Exchange Online, and Microsoft Purview governance service behavior. It does not prove the user's current sharing settings, site ownership coverage, Restricted Content Discovery enablement, retention policy assignments, or litigation hold state. Prefer read-only SharePoint admin center evidence, Exchange 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:
+
+**SharePoint Advanced Management (per learn.microsoft.com/sharepoint/advanced-management):**
+- Layered oversharing controls: Conditional Access policies (authentication context), Restricted Access Control (RAC) limiting site access to specified groups, Restricted Content Discovery (RCD) preventing high-risk sites from surfacing in Copilot and org-wide search, and block download policies
+- Data access governance (DAG) reports: permission state reports, sharing link activity reports, sensitivity label snapshot reports, EEEU (Everyone Except External Users) insights — identify sites with broadest exposure
+- Site access reviews: delegate remediation to site owners; initiate from DAG reports
+- Site lifecycle management: inactive site policies (simulation and active modes), site attestation, and Microsoft 365 Archive for stale content
+
+**Restricted Content Discovery (per learn.microsoft.com/sharepoint/restricted-content-discovery):**
+- Site-level setting that prevents sites from surfacing in org-wide search and Microsoft 365 Copilot Business Chat (unless user had recent interaction)
+- Requires at least one user in the org to be assigned a Copilot license; requires SharePoint Advanced Management prerequisites
+- Does not affect existing permissions — users with access can still open files directly
+- Cannot be applied to OneDrive sites; overuse degrades search and Copilot grounding quality
+
+**External sharing controls (per learn.microsoft.com/sharepoint/turn-external-sharing-on-or-off):**
+- Tenant-level settings range from "Anyone" (most permissive) to "Only people in your organization" (most restrictive)
+- Site-level settings can be more restrictive than tenant-level but cannot exceed the tenant maximum
+- Anyone links: unauthenticated sharing — expiration and permission controls are the primary mitigation
+- EEEU (Everyone Except External Users): all internal users including guests — key oversharing vector for Copilot readiness
+
+**Microsoft Purview retention (per learn.microsoft.com/purview/retention):**
+- Retention policies apply to Exchange mailboxes, SharePoint sites, OneDrive accounts, Teams messages, and other workloads
+- Retention labels enable record declaration, event-based retention, and item-level retention independent of policy
+- Adaptive policy scopes — dynamically include users, sites, or groups based on attributes
+- Litigation hold and eDiscovery hold preserve content in the Recoverable Items folder even if deleted by users
+- Modern recommendation: use Microsoft Purview retention policies and labels; messaging records management (MRM) is legacy but still supported for archive mailbox movement
+
+**Common failure modes:**
+- Tenant-level SharePoint sharing set to "Anyone" with no expiration on Anyone links — unauthenticated sharing at scale
+- EEEU (Everyone Except External Users) permissions on sensitive sites — entire internal user base including guests can access
+- No site lifecycle policy — inactive sites accumulate with orphaned permissions and no owner to attest
+- Restricted Content Discovery not applied to high-risk sites before Copilot deployment — sensitive content surfacing in Copilot responses
+- No retention policy covering SharePoint Online or Exchange Online — compliance gap and eDiscovery risk
+- Archive mailboxes not enabled — users with growing mailboxes hit quota limits; eDiscovery coverage gaps
+
+Review implications:
+- Do not approve tenant-wide sharing policy relaxation without blast-radius assessment and EEEU/Anyone link inventory.
+- Restricted Content Discovery is a bridge control — it does not replace proper permissions remediation for high-risk sites.
+- Documentation cannot prove the user's actual sharing settings, RCD deployment coverage, retention policy assignments, or litigation hold state.

package/skills/microsoft/m365-exchange-sharepoint-information-governance/references/safety-checklist.md

@@ -0,0 +1,40 @@
+# Safety checklist
+
+Use this reference before any recommendation that changes tenant-wide SharePoint or OneDrive sharing settings, retention policies, litigation or eDiscovery holds, Restricted Content Discovery settings, Restricted Access Control policies, site lifecycle policies, or Exchange Online mailbox configuration affecting data preservation.
+
+## Non-negotiables
+
+- Never recommend weakening tenant-wide sharing policies, removing retention holds, or disabling Restricted Content Discovery to accelerate Copilot deployment, reduce friction, or unblock delivery. 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 SharePoint admin center, Exchange admin center, 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 SharePoint sharing settings, site ownership coverage, RCD deployment state, retention policy assignments, or litigation hold coverage.
+- Require explicit user approval before recommending tenant-wide sharing policy changes, retention policy creation or modification, litigation or eDiscovery hold changes, site lifecycle policy activation, or RCD/RAC policy deployment to production sites.
+- Keep remediation least-privilege, reversible, staged (simulation mode before active, pilot sites before org-wide), and scoped to the requested site or workload boundary.
+- Treat any tenant with SharePoint sharing set to "Anyone" and no Anyone link expiration as high risk for unauthenticated data exposure.
+- Treat any high-risk site (sensitive data, EEEU or Anyone access, no owner) as a Copilot readiness blocker until protected by RCD, RAC, or permission remediation.
+- Treat any mailbox or site under legal obligation that lacks a litigation hold or retention policy as a critical compliance gap.
+
+## Stress checks
+
+- What sharing configuration allows unauthenticated access (Anyone links) or org-wide access (EEEU) to sensitive site content without expiration or permission review?
+- What high-risk site will surface unintended sensitive content in Microsoft 365 Copilot Business Chat because RCD has not been applied?
+- What inactive or orphaned site holds sensitive data with no active owner, no lifecycle policy, and no attestation requirement?
+- What workload (Exchange Online, SharePoint Online, Teams messages) has no applicable Microsoft Purview retention policy — creating eDiscovery or regulatory compliance gaps?
+- What mailbox belonging to a departed employee lacks litigation hold or inactive mailbox policy — allowing content to be purged before legal hold expires?
+- What rollback path exists if a tenant-wide sharing restriction or RCD policy breaks existing business workflows relying on anonymous or org-wide sharing?
+
+## Evidence labels
+
+Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live SharePoint sharing settings, RCD deployment coverage, retention policy assignments, litigation hold state, or inactive mailbox policy coverage.
+
+## Escalation triggers
+
+Escalate to live-guard gate before any of the following:
+
+- Changing tenant-wide SharePoint or OneDrive sharing settings (especially relaxing from current level)
+- Creating, modifying, or removing Microsoft Purview retention policies or retention labels affecting production content
+- Adding, modifying, or releasing litigation holds or eDiscovery holds on mailboxes or sites
+- Enabling, modifying, or disabling Restricted Content Discovery settings on production sites
+- Enabling, modifying, or disabling Restricted Access Control policies on production sites
+- Enabling or modifying site lifecycle management policies in active mode (moving from simulation to active)
+- Purging content from inactive mailboxes or deleting SharePoint site collections with content under hold

package/skills/microsoft/m365-exchange-sharepoint-information-governance/references/workflow-and-output.md

@@ -0,0 +1,66 @@
+# Workflow and output contract
+
+Use this reference only when performing the full Exchange Online and SharePoint information governance review or formatting the final review.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- **Mailbox lifecycle**: Archive mailbox enablement, inactive mailbox policies, shared mailbox governance (no interactive sign-in, licensed, reviewed), resource mailbox hygiene, and mailbox size and quota management
+- **Site lifecycle**: SharePoint site ownership policies, inactive site detection and remediation (simulation vs. active policy mode), site attestation, Microsoft 365 Archive for stale content, and orphaned site cleanup
+- **External and anonymous sharing controls**: Tenant-level SharePoint and OneDrive sharing settings (Anyone/New and existing guests/Existing guests/Only org), site-level overrides, Anyone link expiration, link permission defaults, and EEEU access scope
+- **SharePoint Advanced Management (SAM)**: Data access governance (DAG) reports, Restricted Content Discovery (RCD) for high-risk sites, Restricted Access Control (RAC) for membership-gated sites, site access reviews, block download policies, and content management assessment
+- **Oversharing remediation and Copilot readiness**: EEEU insights, sharing link activity reports, permission state reports, sensitivity label distribution, prioritized high-risk site list for RCD or RAC, and pre-Copilot deployment checklist
+- **Retention and records management**: Microsoft Purview retention policies covering Exchange Online and SharePoint Online, retention labels for records declaration, event-based retention, adaptive scopes, and retention policy gap identification
+- **Hold and eDiscovery readiness**: Litigation hold coverage, eDiscovery hold assignment, Recoverable Items folder health, and inactive mailbox policy for departed employees
+- **Information architecture**: Hub site structure, site collection boundaries, sensitivity label application to SharePoint sites, content type governance, and information hierarchy alignment to data classification
+
+## Safe workflow
+
+1. **Frame scope**
+   - Tenant / environment / licensing tier (E3, E5, Copilot, SAM license):
+   - Approximate site count and mailbox count:
+   - Copilot deployment status or target timeline:
+   - Regulatory or legal hold requirements:
+   - Required outcome:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer read-only SharePoint admin center or Exchange admin center evidence, or Microsoft Graph read output, for current-state claims when available.
+   - Otherwise inspect repository IaC/config, sanitized user evidence, DAG report exports, or official docs.
+   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+3. **Stress-test risk**
+   - What sharing configuration allows unauthenticated (Anyone link) or org-wide (EEEU) access to sensitive site content?
+   - What high-risk site is not protected by RCD or RAC and will surface unintended content in Copilot responses?
+   - What inactive or orphaned site holds sensitive data with no active owner and no lifecycle policy?
+   - What mailbox or site has no applicable retention policy — creating eDiscovery or compliance gaps?
+   - What litigation hold or eDiscovery hold may be missing for content under legal obligation?
+   - What rollback path exists if a tenant-wide sharing policy restriction breaks existing partner collaboration or anonymous link sharing workflows?
+4. **Recommend the smallest safe action**
+   - Prefer simulation mode for site lifecycle policies before enabling active mode, staged RCD rollout starting with highest-risk sites, and retention policy report mode before enforcement.
+   - If the safest action is to stop and gather evidence before making changes, say that plainly.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# M365 Exchange and SharePoint Information Governance 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-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