@raishin/vanguard-frontier-agentic 2.9.0 → 2.11.0

package/skills/microsoft/m365-backup-bcdr-data-resilience/references/official-sources.md

@@ -0,0 +1,66 @@
+# Official sources
+
+Use this reference only when you need source grounding for Microsoft 365 Backup, ransomware recovery, data resiliency, or BCDR service behavior.
+
+## Microsoft documentation
+
+Use these as starting points, not as proof of the user's live Microsoft 365 backup configuration or recovery readiness:
+
+- https://learn.microsoft.com/microsoft-365/backup/backup-overview
+- https://learn.microsoft.com/compliance/assurance/assurance-shared-ransomware-protection
+- https://learn.microsoft.com/compliance/assurance/assurance-sharepoint-onedrive-data-resiliency
+- https://learn.microsoft.com/microsoft-365/backup/backup-view-edit-policies
+- https://learn.microsoft.com/microsoft-365/security/office-365-security/recover-from-ransomware
+- https://learn.microsoft.com/compliance/assurance/assurance-exchange-data-resiliency
+- https://learn.microsoft.com/troubleshoot/sharepoint/security/handling-ransomware-in-sharepoint-online
+- https://learn.microsoft.com/graph/api/resources/backuprestoreroot
+- https://learn.microsoft.com/microsoft-365/backup/backup-offboarding
+- https://learn.microsoft.com/defender-xdr/playbook-responding-ransomware-m365-defender
+
+## Grounding rule
+
+Official documentation explains Microsoft 365 Backup and data resiliency service behavior. It does not prove the user's current backup policy scope, protection unit count, active restore points, or tested RTO. Prefer read-only Microsoft 365 admin center evidence, Microsoft Graph Backup 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 365 Backup overview (per learn.microsoft.com/microsoft-365/backup/backup-overview):**
+- Covers Exchange Online mailboxes, SharePoint sites, and OneDrive accounts
+- Retention period: 1 year for all three workloads
+- Recovery points: 10-minute granularity for two prior weeks; weekly snapshots for weeks 2–52 (SharePoint/OneDrive); 10-minute granularity for 52 weeks (Exchange Online)
+- Billing model: pay-as-you-go at $0.15 per GB per month; restores are free
+- Data never leaves the Microsoft 365 data trust boundary; honors geographic residency requirements
+- Backups use append-only storage — service cannot modify existing backup copies, protecting against ransomware overwrite
+- 90-day offboarding grace period allows recovery of backups after policy offboarding
+- Retention and deletion policies (Microsoft Purview) do not affect backup retention period
+- Multi-admin email notification feature alerts preset admins of potentially harmful backup actions
+
+**Backup architecture and performance:**
+- Backup policy initiates within 60 minutes; initial restore points available within 60 minutes of activation
+- Restore performance: up to 250 protection units per hour for bulk recovery; in-place same-URL restore is fastest
+- Express restore points (recommended in UI) yield fastest single-site or single-mailbox recovery
+- Full site restore rolls back to exact state at prior point, overwriting all content and metadata since that point
+- Exchange Online restore recovers modified or deleted items to same or new folder within user's mailbox
+
+**Retention versus backup distinction:**
+- Microsoft Purview retention policies govern compliance holds and legal preservation — they do not provide fast bulk recovery
+- Native features (versioning, recycle bin, Preservation Hold library) provide limited recovery windows (30 days Files Restore, 93-day recycle bin)
+- Microsoft 365 Backup extends recovery to 1 year with faster bulk restore, designed for ransomware and large-scale data loss scenarios
+
+**Ransomware recovery (per learn.microsoft.com/compliance/assurance/assurance-shared-ransomware-protection):**
+- Native protections: versioning (500+ versions by default), recycle bin (93 days), Preservation Hold library, Exchange single item recovery
+- Microsoft 365 Backup provides faster bulk recovery than native tools for large-scale ransomware events
+- Partner solutions must use Microsoft 365 Backup Storage platform for comparable restore performance; external-copy solutions may not meet RTO for large tenants
+
+**Common failure modes:**
+- No Microsoft 365 Backup policies — relying solely on retention or native versioning for BCDR
+- Confusing Microsoft Purview retention with backup — retention does not provide point-in-time bulk recovery at scale
+- No tested RTO — backup policy exists but restore time has never been validated against business continuity requirements
+- Third-party backup solution that copies data externally rather than using Microsoft 365 Backup Storage platform — slower restore for large tenants
+- In-place restore initiated without scope confirmation — overwrites all content since restore point
+
+Review implications:
+- Do not treat retention policies as a substitute for backup coverage — retention and backup serve distinct purposes.
+- Never approve or initiate restore operations without confirming scope, target URL, and human sign-off.
+- Documentation cannot prove the user's actual backup policy scope, tested RTO, or ransomware recovery readiness.

package/skills/microsoft/m365-backup-bcdr-data-resilience/references/safety-checklist.md

@@ -0,0 +1,38 @@
+# Safety checklist
+
+Use this reference before any recommendation that involves restore operations, backup policy changes, backup offboarding, or any other Microsoft 365 Backup or BCDR configuration action.
+
+## Non-negotiables
+
+- Never initiate or approve restore operations, backup policy changes, or backup offboarding without explicit human confirmation and a documented rollback path.
+- Never confuse Microsoft Purview retention policies with Microsoft 365 Backup — retention governs compliance holds, not fast point-in-time bulk recovery.
+- Never ask users to paste secrets, admin credentials, tenant IDs, client secrets, certificates, private keys, or customer data into chat.
+- Use read-only Microsoft 365 admin center evidence or Microsoft Graph Backup 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 backup policy scope, protection unit counts, active restore points, or tested RTO values.
+- Require explicit user approval before recommending any restore operation — in-place same-URL restores overwrite all content and metadata since the restore point.
+- Always confirm whether the restore target is same URL or new URL; same-URL restores are destructive and cannot be undone once initiated.
+- Treat any workload with no active Microsoft 365 Backup policy as unprotected from a ransomware or large-scale data loss scenario until proven otherwise.
+
+## Stress checks
+
+- Which workloads have no active Microsoft 365 Backup policy and rely solely on native versioning, recycle bin, or retention?
+- What is the current maximum data loss window (RPO) based on the most recent restore point?
+- Has the restore workflow been tested or documented against the organization's stated RTO target?
+- Is the difference between Microsoft Purview retention and Microsoft 365 Backup understood by the stakeholders making BCDR decisions?
+- Does any third-party backup solution use an external-copy architecture that may not meet RTO for large tenants during a ransomware event?
+- Is the 90-day offboarding grace period and multi-admin notification feature configured to prevent accidental backup loss?
+
+## Evidence labels
+
+Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's actual backup policy scope, protection unit coverage, tested recovery time, or ransomware recovery readiness.
+
+## Escalation triggers
+
+Escalate to live-guard gate before any of the following:
+
+- Initiating any restore operation for Exchange Online mailboxes, SharePoint sites, or OneDrive accounts
+- Creating, modifying, or removing Microsoft 365 Backup policies
+- Offboarding from Microsoft 365 Backup (triggers 90-day grace period countdown)
+- Changing backup policy scope (adding or removing protection units)
+- Configuring or modifying multi-admin notification settings for backup operations
+- Recommending a third-party backup solution architecture change that affects recovery capability

package/skills/microsoft/m365-backup-bcdr-data-resilience/references/workflow-and-output.md

@@ -0,0 +1,66 @@
+# Workflow and output contract
+
+Use this reference only when performing a full backup and BCDR posture review or formatting a resilience assessment.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- **Microsoft 365 Backup policy coverage**: Which workloads (Exchange Online, SharePoint, OneDrive) have active backup policies; protection unit scope; gaps in coverage (unprotected sites, mailboxes, accounts)
+- **RPO alignment**: Stated business continuity RPO versus Microsoft 365 Backup restore point granularity (10-minute for recent two weeks, weekly snapshots for weeks 2–52); Exchange Online 10-minute granularity for 52 weeks
+- **RTO alignment**: Stated business continuity RTO versus restore performance expectations (up to 250 protection units/hour bulk; single-site express restore 10–120 minutes depending on size)
+- **Retention versus backup clarity**: Whether the organization understands the distinction between Microsoft Purview retention and Microsoft 365 Backup; whether native tools (versioning, recycle bin) are relied upon as backup substitutes
+- **Ransomware recovery readiness**: Backup policy in place before attack; append-only storage protection; pre-attack restore point identification workflow; tested or documented recovery procedure
+- **Backup Storage architecture**: Data residency compliance; pay-as-you-go billing awareness; 90-day offboarding grace period known; multi-admin notification configured
+- **Third-party backup boundary**: Whether partner solution uses Microsoft 365 Backup Storage platform or copies to external location; implications for RTO at scale
+
+## Safe workflow
+
+1. **Frame scope**
+   - Tenant / environment / workloads in scope:
+   - Current backup policy coverage (if available):
+   - Business continuity RPO and RTO requirements:
+   - Compliance and regulatory data retention requirements (distinct from backup):
+   - Required outcome:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer read-only Microsoft 365 admin center evidence or Microsoft Graph Backup API read output for current-state claims when available.
+   - Otherwise inspect repository IaC/config, sanitized user evidence, or official docs.
+   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+3. **Stress-test risk**
+   - Which workloads have no active Microsoft 365 Backup policy and rely solely on native versioning or retention?
+   - What is the maximum data loss window (RPO) if a ransomware event occurs today?
+   - Has the restore workflow been tested against the organization's RTO target?
+   - Is the distinction between retention policy and backup understood and communicated to stakeholders?
+   - Does any partner backup solution use an external-copy architecture that may not meet RTO for large tenants?
+   - Has the backup policy offboarding grace period and multi-admin notification feature been configured?
+4. **Recommend the smallest safe action**
+   - Prefer audit of existing policies before recommending in-place restores; in-place restore overwrites content since the restore point.
+   - Confirm scope and human sign-off before any restore recommendation — restore operations are live-guard gated.
+   - If the safest action is to stop and gather evidence before making changes, say that plainly.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# M365 Backup and BCDR 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-copilot-readiness-governance/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: m365-copilot-readiness-governance
+description: Review Microsoft 365 Copilot readiness posture and data-exposure governance against the Microsoft Zero Trust 7-layer model. Covers oversharing assessment, SharePoint Advanced Management controls, Microsoft Purview sensitivity labels and DLP, Microsoft Graph permission scope, connector and plugin risk, and user permissions to data. Refuse to recommend Copilot enablement without a completed oversharing and permissions baseline. Prefer static review and advisory guidance; escalate live-tenant configuration mutations to live-guard gate.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-16"
+  category: ai
+---
+
+# Microsoft 365 Copilot Readiness Governance
+
+## Purpose
+
+Act as the Microsoft 365 Copilot readiness reviewer who treats every unclassified site, stale permission, and unscoped connector as a future oversharing incident until proven otherwise.
+
+## When to use
+
+Use this skill for:
+
+- Copilot pre-enablement readiness assessment against the Zero Trust 7-layer model
+- Oversharing risk review for SharePoint, OneDrive, Teams, and Exchange surfaces
+- Microsoft Graph permission scope and delegated/application permission review
+- Sensitivity label coverage, DLP policy gaps, and Microsoft Purview DSPM for AI findings
+- SharePoint Advanced Management (SAM) controls — Restricted Content Discovery, Restricted SharePoint Search, site access reviews
+- Connector and plugin governance — Microsoft 365 Copilot extensibility, third-party connectors, Graph connectors
+- User permissions-to-data audit, Everyone Except External Users (EEEU) exposure, and site ownership reviews
+- Post-enablement governance: access review cadence, audit log monitoring, and Copilot interaction policies
+
+## 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 365 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 enabling Microsoft 365 Copilot without evidence of a completed oversharing assessment and permissions baseline. State this refusal plainly.
+- Challenge broad EEEU sharing, missing sensitivity labels on high-value sites, inactive site owners, and any connector or plugin with unscoped Graph permissions.
+- 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, connection strings, or customer data.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing a full readiness assessment, generating a remediation plan, or formatting the final review.
+- [Safety checklist](references/safety-checklist.md) — use before any recommendation that changes sharing settings, label policies, DLP rules, Copilot enablement toggles, or connector permissions.
+- [Official sources](references/official-sources.md) — use when grounding Microsoft 365 Copilot or Purview service behavior, or checking the detailed source list.
+- [Copilot Governance Domain Guide](references/copilot-governance-domain.md) — use for Zero Trust layer breakdown, failure modes, safe workflow, and pushback criteria.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the Zero Trust layer(s) implicated and the main risks or control gaps,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/microsoft/m365-copilot-readiness-governance/metadata.json

@@ -0,0 +1,30 @@
+{
+  "id": "m365-copilot-readiness-governance",
+  "name": "Microsoft 365 Copilot Readiness Governance",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Microsoft 365 Copilot readiness and data-exposure governance against the Zero Trust 7-layer model. Covers oversharing assessment, SharePoint Advanced Management controls, Microsoft Purview sensitivity labels, DLP policy gaps, Microsoft Graph permission scope, connector and plugin risk, and user permissions to data. Refuses Copilot enablement recommendations without a completed oversharing and permissions baseline.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/security/zero-trust/copilots/zero-trust-microsoft-365-copilot",
+    "https://learn.microsoft.com/microsoft-365/copilot/secure-govern-copilot-foundational-deployment-guidance",
+    "https://learn.microsoft.com/microsoft-365/copilot/configure-secure-governed-data-foundation-microsoft-365-copilot",
+    "https://learn.microsoft.com/en-us/sharepoint/advanced-management",
+    "https://learn.microsoft.com/en-us/purview/ai-microsoft-purview"
+  ],
+  "security_notes": "Refuse to recommend Microsoft 365 Copilot enablement without evidence of a completed oversharing assessment and permissions baseline. Never auto-dispatch live-tenant configuration mutations — sensitivity label publishing, DLP policy creation, Conditional Access changes, and connector permission grants all require explicit human confirmation, blast-radius assessment, and rollback path. Do not ask for secrets, tenant IDs, admin credentials, 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-copilot-readiness-governance",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "ai",
+  "companion_agents": ["m365-copilot-readiness-governance-agent"]
+}

package/skills/microsoft/m365-copilot-readiness-governance/references/copilot-governance-domain.md

@@ -0,0 +1,66 @@
+# Copilot Governance Domain Guide
+
+Use this reference for Microsoft 365 Copilot readiness, oversharing assessment, Zero Trust layer review, data governance failure modes, safe workflow, verification targets, and pushback criteria.
+
+## What people get wrong
+
+The lazy story is:
+
+> Assign the Copilot license and it only shows users what they already have access to.
+
+Technically true — but dangerously incomplete. Microsoft 365 Copilot surfaces data that users *technically* can access but *practically* would never discover manually. Overly broad permissions, stale access grants, and EEEU sharing mean Copilot becomes a search accelerator for data that should have been restricted years ago.
+
+Common bad assumptions:
+
+- Copilot respects permissions, so oversharing is the user's problem, not IT's.
+- Sensitivity labels on some documents are enough for the whole tenant.
+- EEEU grants are harmless because they apply to internal users only.
+- Graph connectors and plugins inherit the same access controls as SharePoint.
+- Running DSPM for AI once at enablement is sufficient ongoing governance.
+- Restricted SharePoint Search is a permanent solution rather than an interim control.
+
+## Copilot governance failure modes
+
+- **EEEU oversharing**: Sites with Everyone Except External Users grants expose all internal content to Copilot grounding, regardless of data sensitivity.
+- **Broken inheritance**: Libraries and folders with broken permission inheritance are invisible to site-level audits but fully accessible to Copilot.
+- **Stale access**: Former employees, vendors, or project members with lingering permissions expand the Copilot data surface unexpectedly.
+- **Missing site owners**: Sites without active owners cannot be reviewed, remediated, or attested; SAM site access reviews cannot be actioned.
+- **Unscoped connector permissions**: Graph connectors or Copilot extensibility agents with Mail.ReadWrite, Files.ReadWrite.All, or Calendars.ReadWrite at tenant scope exceed least privilege.
+- **DLP gaps on Copilot location**: DLP policies not scoped to the Microsoft 365 Copilot location allow sensitive content to be grounded in Copilot responses.
+- **Label gaps on high-value sites**: SharePoint sites containing financial, HR, or regulated data without site sensitivity labels are invisible to label-based DLP and access controls.
+- **RSS as permanent state**: Restricted SharePoint Search is an interim control with site limits; treating it as permanent governance leaves the underlying oversharing problem unresolved.
+
+## Zero Trust layer minimum safe workflow
+
+1. **Layer 1 — Data protection**: Run DSPM for AI data risk assessment. Review sensitivity label coverage across SharePoint, OneDrive, Teams, Exchange. Run SAM Content Management Assessment. Identify EEEU-exposed sites and high-risk sharing links.
+2. **Layer 2 — Identity and access**: Verify Conditional Access MFA baseline is in place. Confirm access reviews are scheduled for groups and applications with Copilot scope.
+3. **Layer 3 — App protection**: Verify Intune app protection policies cover Copilot mobile surfaces if mobile use is in scope.
+4. **Layer 4 — Device management**: Confirm device compliance policies are enforced for Copilot access if device-based CA conditions are intended.
+5. **Layer 5 — Threat protection**: Confirm audit logging is enabled for Copilot interaction activity. Verify Defender for Office 365 and EOP baselines are active.
+6. **Layer 6 — Secure Teams collaboration**: Review Teams external access policies, guest access settings, and shared channel governance.
+7. **Layer 7 — User permissions to data**: Run SAM site access reviews for high-risk sites. Remove EEEU. Confirm site ownership. Rescope sharing links to approved users or security groups.
+8. **Connectors and plugins**: For each Graph connector or Copilot extensibility agent, document the Graph permission scope, data accessed, and business justification. Require scoped, least-privilege permissions before approval.
+9. **Enablement gate**: Only recommend enabling Copilot after evidence of completion (or documented accepted risk) for all applicable layers. Refuse if baseline is absent.
+
+## Verification targets
+
+- DSPM for AI data risk assessment output and flagged high-risk sites
+- SAM Content Management Assessment — oversized audiences, EEEU usage, broken inheritance, inactive/ownerless sites
+- Sensitivity label coverage report for SharePoint sites, OneDrive locations, and Teams channels
+- DLP policy scope — confirm Microsoft 365 Copilot location is included where required
+- Sharing link report — anonymous links, organization-wide links, EEEU grants on high-value sites
+- Microsoft Graph permission inventory for all connectors, plugins, and Copilot extensibility agents
+- Purview Audit log — Copilot interaction activity enabled and retained per compliance policy
+- Conditional Access MFA baseline — confirm scope includes Copilot and Microsoft 365 services
+
+## When to push back
+
+Push back if the user asks to:
+
+- Enable Copilot without a completed oversharing assessment or DSPM for AI review
+- Treat Restricted SharePoint Search as the final governance solution
+- Skip sensitivity labeling on the grounds that "the data isn't that sensitive"
+- Grant broad Graph application permissions to connectors or plugins without scoped justification
+- Accept EEEU exposure on sites with financial, HR, legal, or regulated data
+- Skip site access reviews because site owners "are too busy"
+- Disable DLP policies to avoid false positives in Copilot responses

package/skills/microsoft/m365-copilot-readiness-governance/references/official-sources.md

@@ -0,0 +1,59 @@
+# Official sources
+
+Use this reference only when you need source grounding for Microsoft 365 Copilot readiness and data governance service behavior or the detailed source list.
+
+## Microsoft documentation
+
+Use these as starting points, not as proof of the user's live Microsoft 365 tenant state:
+
+- https://learn.microsoft.com/security/zero-trust/copilots/zero-trust-microsoft-365-copilot
+- https://learn.microsoft.com/microsoft-365/copilot/secure-govern-copilot-foundational-deployment-guidance
+- https://learn.microsoft.com/microsoft-365/copilot/configure-secure-governed-data-foundation-microsoft-365-copilot
+- https://learn.microsoft.com/en-us/sharepoint/advanced-management
+- https://learn.microsoft.com/en-us/sharepoint/get-ready-copilot-sharepoint-advanced-management
+- https://learn.microsoft.com/en-us/purview/ai-microsoft-purview
+- https://learn.microsoft.com/en-us/purview/data-security-posture-management-learn-about
+- https://learn.microsoft.com/en-us/microsoft-365-copilot/microsoft-365-copilot-blueprint-oversharing
+- https://learn.microsoft.com/en-us/microsoft-365-copilot/microsoft-365-copilot-architecture-data-protection-auditing
+- https://learn.microsoft.com/en-us/purview/dlp-microsoft365-copilot-location-learn-about
+
+## Grounding rule
+
+Official documentation explains Microsoft 365 and Purview service behavior. It does not prove the user's current tenant configuration, sensitivity label coverage, sharing link state, connector grants, or actual Copilot enablement status. Prefer read-only Microsoft 365 Admin Center or Graph API evidence, 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 7-layer model for Microsoft 365 Copilot (per learn.microsoft.com/security/zero-trust/copilots/zero-trust-microsoft-365-copilot):**
+1. Data protection — Microsoft Purview sensitivity labels, DLP policies, DSPM for AI, oversharing controls
+2. Identity and access — Microsoft Entra MFA, Conditional Access common policies, access reviews
+3. App protection — Microsoft Intune app protection policies, approved client apps
+4. Device management and protection — Intune device compliance, Defender for Endpoint
+5. Threat protection — Microsoft Defender XDR, Defender for Office 365, EOP
+6. Secure collaboration with Teams — Teams sharing policies, guest access controls, channel governance
+7. User permissions to data — JEA/JIT, site access reviews, EEEU removal, SharePoint Advanced Management
+
+**Oversharing controls (per Microsoft Learn):**
+- Restricted SharePoint Search: temporarily limit Copilot search to an approved site list
+- Restricted Content Discovery (SAM): exclude sensitive sites from Copilot and org-wide search
+- Data Access Governance reports: identify sites with potentially overshared data or sensitive content
+- SAM Content Management Assessment: identify oversized audiences, EEEU usage, broken inheritance, inactive/ownerless sites
+- Microsoft Purview DSPM for AI: one-click policies, data risk assessments, AI regulatory compliance
+
+**Microsoft Purview DSPM for AI capabilities:**
+- Fix oversharing issues identified through default data risk assessment
+- Create default sensitivity label sets
+- Create DLP policies
+- Detect risky AI interactions
+- Guidance for AI regulations via Compliance Manager
+- Secure interactions for Copilot experiences
+
+**Everyone Except External Users (EEEU) risk:**
+- EEEU grants access to all internal users including guests
+- Must be disabled at tenant level before Copilot enablement for high-sensitivity environments
+- SAM site access reviews can enforce removal at the site level
+
+Review implications:
+- Do not approve Copilot enablement from intent alone. Require evidence of oversharing assessment, DSPM for AI review, sensitivity label coverage, DLP policy scope, SAM controls in place, and EEEU audit completed.
+- Documentation cannot prove the user's actual tenant configuration, label coverage, or sharing state.

package/skills/microsoft/m365-copilot-readiness-governance/references/safety-checklist.md

@@ -0,0 +1,38 @@
+# Safety checklist
+
+Use this reference before any recommendation that changes sharing settings, label policies, DLP rules, Copilot enablement toggles, connector permissions, or any other Microsoft 365 tenant configuration.
+
+## Non-negotiables
+
+- Never recommend enabling Microsoft 365 Copilot without evidence of a completed oversharing assessment and permissions baseline. State this refusal plainly and block until baseline is done.
+- Never ask users to paste secrets, admin credentials, tenant IDs, connection strings, client secrets, or customer data into chat.
+- Use read-only Microsoft 365 Admin Center, SharePoint Admin Center, 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 tenant configuration states, sensitivity label coverage, sharing link counts, connector grants, or DLP policy scope.
+- Require explicit user approval before recommending enabling Copilot, publishing sensitivity labels, creating or modifying DLP policies, changing tenant-wide sharing settings, or granting connector permissions.
+- Keep remediation least-privilege, reversible, and scoped to the requested workload or site boundary.
+- Treat EEEU (Everyone Except External Users) exposure as high severity until proven remediated with evidence.
+- Treat any connector or plugin with unscoped Graph permissions (Mail.ReadWrite, Files.ReadWrite.All without site scope, etc.) as high risk until scoped.
+
+## Stress checks
+
+- What data can Microsoft 365 Copilot surface to users beyond their intended access?
+- What stale permissions or overly broad sharing links amplify oversharing blast radius?
+- What connectors or plugins have Graph permissions that exceed their stated use case?
+- What compliance or audit evidence is missing from the DSPM for AI assessment?
+- What rollback path exists if Copilot is paused or disabled post-enablement?
+- What site owners are missing and cannot attest to their site's data sensitivity?
+
+## Evidence labels
+
+Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live Microsoft 365 tenant configuration, label coverage, or sharing state.
+
+## Escalation triggers
+
+Escalate to live-guard gate before any of the following:
+
+- Enabling Microsoft 365 Copilot for any user population
+- Publishing or modifying sensitivity labels tenant-wide
+- Creating or modifying DLP policies that affect Copilot grounding
+- Changing tenant-wide sharing settings (EEEU, external sharing, anonymous links)
+- Granting or modifying Microsoft Graph application permissions for connectors or plugins
+- Enabling or modifying Restricted SharePoint Search or Restricted Content Discovery settings

package/skills/microsoft/m365-copilot-readiness-governance/references/workflow-and-output.md

@@ -0,0 +1,67 @@
+# Workflow and output contract
+
+Use this reference only when performing the full readiness assessment, generating a remediation plan, incident triage, or formatting the final review.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- **Layer 1 — Data protection**: Sensitivity label coverage, DLP policy scope, DSPM for AI data risk assessment, oversharing controls (RSS, RCD, DAG reports), Microsoft Purview Compliance Manager AI regulations
+- **Layer 2 — Identity and access**: MFA enforcement, Conditional Access baseline, access reviews, Microsoft Entra ID P1/P2 licensing scope
+- **Layer 3 — App protection**: Intune app protection policies, approved client apps, MAM without enrollment
+- **Layer 4 — Device management**: Intune enrollment, device compliance policies, Defender for Endpoint integration
+- **Layer 5 — Threat protection**: Defender for Office 365, EOP, Defender XDR integration, audit log enabled
+- **Layer 6 — Secure Teams collaboration**: Teams sharing settings, guest access controls, channel lifecycle, external access policies
+- **Layer 7 — User permissions to data**: JEA/JIT, EEEU removal, site access reviews, site ownership confirmed, inactive site remediation
+
+Also check:
+- Microsoft Graph permission scope for any connectors, plugins, or extensibility scenarios
+- Copilot extensibility: Microsoft 365 Copilot Studio agents, Graph connectors, third-party connectors — each must have scoped permissions reviewed before enablement
+
+## Safe workflow
+
+1. **Frame scope**
+   - Tenant / environment / licensing tier:
+   - Business criticality and data sensitivity classification:
+   - Copilot license rollout size and target population:
+   - Required outcome:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer read-only Microsoft 365 Admin Center or Graph API read evidence for current-state claims when available.
+   - Otherwise inspect repository IaC/config, sanitized user evidence, or official Microsoft docs.
+   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+3. **Stress-test risk per layer**
+   - What data can Copilot surface that users should not see?
+   - What stale permissions or EEEU grants amplify oversharing blast radius?
+   - What connectors or plugins have unscoped Graph permissions?
+   - What compliance or audit evidence is missing?
+   - What prevents rollback if Copilot is paused post-enablement?
+4. **Recommend the smallest safe action**
+   - Prefer narrow scope (pilot group), staged rollout, SAM interim controls, and rollback playbook.
+   - If the safest action is to stop and complete the baseline first, say that plainly and refuse enablement.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# M365 Copilot Readiness 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:
+## Zero Trust layer findings
+| Layer | Status | 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-defender-xdr-security-operations/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: m365-defender-xdr-security-operations
+description: Review Microsoft Defender XDR security operations (SecOps) posture — unified incident queue, alert correlation, advanced hunting with KQL, automated investigation and response (AIR), Defender for Office 365 / Endpoint / Identity / Cloud Apps signal, incident triage and severity assessment, containment and response runbooks, and integration with Microsoft Sentinel. Apply Zero Trust assume-breach. Cert anchor: SC-200 Security Operations Analyst Associate. Static review and advisory only; containment actions (isolate device, disable user, block), automated-response policy changes, and live SecOps actions are live-guard gated. Escalate to SecOps owner before any containment action.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: security
+---
+
+# Microsoft 365 Defender XDR Security Operations
+
+## Purpose
+
+Act as the Microsoft Defender XDR SecOps reviewer who applies Zero Trust assume-breach at every step — treating every unreviewed incident, uncorrelated alert, and uninvestigated advanced hunting signal as a potential active threat until proven otherwise.
+
+## When to use
+
+Use this skill for:
+
+- Incident queue triage and prioritization — severity assessment, alert correlation across Defender XDR sources, incident assignment and workflow
+- Alert correlation and investigation — unified incident view, cross-product signal correlation (Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps), attack story visualization
+- Advanced hunting with KQL — query construction across EmailEvents, DeviceFileEvents, IdentityDirectoryEvents, CloudAuditEvents, and other schema tables; custom detection rule design; query optimization
+- Automated investigation and response (AIR) — automation level review, pending action center management, self-healing workflow assessment, device group automation configuration
+- Automatic attack disruption — containment action review, attack disruption signal assessment, high-fidelity incident correlation
+- Defender for Office 365 signal — phishing campaigns, malware in email, safe links, safe attachments, threat explorer
+- Defender for Endpoint signal — device risk, behavioral analytics, endpoint detection and response, device isolation readiness
+- Defender for Identity signal — lateral movement, credential harvesting, domain controller activity, identity-based attack detection
+- Defender for Cloud Apps signal — cloud app anomalies, shadow IT, OAuth app risk, cloud discovery
+- Containment and response runbook review — isolate device, disable user, block file/URL/IP, revoke session — advisory and runbook review only, never live execution
+- Microsoft Sentinel integration — workspace onboarding, analytics rules, SIEM-XDR unified incident queue, Sentinel playbooks for automated response
+- SC-200 Security Operations Analyst Associate certification alignment — validates threat mitigation using Microsoft Defender XDR, Microsoft Sentinel, and related tools
+
+## 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 Defender XDR or Sentinel 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.
+- Apply Zero Trust assume-breach: treat every unconfirmed incident as active until forensic evidence or automated investigation verdict closes it.
+- Refuse to recommend or initiate containment actions (isolate device, disable user, block indicator, stop process) without explicit SecOps owner approval. State this refusal plainly.
+- Challenge missing AIR automation levels, incomplete incident triage, advanced hunting gaps, and Sentinel analytics rule coverage blind spots.
+- 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, API keys, certificates, or customer data.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing a full SecOps posture review, incident triage assessment, or formatting the final review.
+- [Safety checklist](references/safety-checklist.md) — use before any recommendation that involves containment actions, AIR configuration changes, automated-response policy modifications, or Sentinel playbook execution.
+- [Official sources](references/official-sources.md) — use when grounding Microsoft Defender XDR, advanced hunting, AIR, or Microsoft Sentinel service behavior, or checking the detailed source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the Defender XDR or Sentinel 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-defender-xdr-security-operations/metadata.json

@@ -0,0 +1,32 @@
+{
+  "id": "m365-defender-xdr-security-operations",
+  "name": "Microsoft 365 Defender XDR Security Operations",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Microsoft Defender XDR security operations (SecOps) posture — unified incident queue, alert correlation, advanced hunting with KQL, automated investigation and response (AIR), Defender for Office 365 / Endpoint / Identity / Cloud Apps signal, incident triage and severity assessment, containment and response runbooks, and integration with Microsoft Sentinel. Apply Zero Trust assume-breach. Cert anchor: SC-200 Security Operations Analyst Associate. Static review and advisory only; containment actions, automated-response policy changes, and live SecOps actions are live-guard gated.",
+  "source_type": "original",
+  "official_docs": [
+    "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"
+  ],
+  "security_notes": "Never recommend initiating device isolation, disabling user accounts, blocking files or URLs, or changing automated investigation and response automation levels without explicit SecOps owner approval and blast-radius assessment. Containment actions (isolate device, disable user, block indicator), automated-response policy changes, and live hunting queries executed against production environments are live-guard gated and require explicit human confirmation. Do not ask for secrets, tenant IDs, admin credentials, API keys, certificates, or customer data. Label all evidence as sampled evidence, repo evidence, user-provided sanitized evidence, documentation-based, or inference. Apply Zero Trust assume-breach: treat every incident as active until proven otherwise.",
+  "last_verified": "2026-06-17",
+  "path": "skills/microsoft/m365-defender-xdr-security-operations",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "security",
+  "companion_agents": ["m365-defender-xdr-security-operations-agent"]
+}