@raishin/vanguard-frontier-agentic 2.10.0 → 2.11.0

package/skills/microsoft/fabric-power-bi-business-insights-governance/references/safety-checklist.md

@@ -0,0 +1,35 @@
+# Safety checklist
+
+Use this reference before any recommendation involving production workspace roles, RLS/OLS, sensitivity labels, DLP, or Fabric capacity.
+
+## Non-negotiables
+
+- Never ask users to paste credentials, tenant IDs, workspace URLs, or customer data into chat.
+- Use admin portal exports, lineage view, or sanitized user-provided evidence for current-state claims; otherwise use documentation and label the evidence level.
+- Do not invent model inventories, endorsement status, RLS rules, or capacity metrics.
+- Require explicit human approval before recommending any production workspace-role, RLS/OLS, sensitivity-label, DLP, or capacity change.
+- Use current official Microsoft Learn documentation for Fabric/Power BI security and governance behavior.
+- Keep recommendations least-privilege and reversible.
+
+## Stress checks
+
+- Which metrics come from duplicated or uncertified models (mistrust)?
+- Which sensitive models lack RLS — or rely on RLS while exposing Admin/Member/Contributor roles (RLS only restricts Viewers)?
+- Which reports are built on personal models rather than an endorsed shared model?
+- Which workspace roles are broader than necessary?
+- Which models lack sensitivity labels or DLP coverage?
+- What rollback exists if an RLS or workspace-role change exposes or hides data incorrectly?
+
+## Evidence labels
+
+Use `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's actual model inventory, endorsement, RLS configuration, or workspace roles.
+
+## Live-guard gate
+
+The following actions require explicit human confirmation and are out of scope for automated execution:
+
+- Changing production workspace role assignments (Admin/Member/Contributor/Viewer)
+- Modifying production RLS/OLS roles or rules on shared semantic models
+- Changing sensitivity labels or Purview DLP policies for Power BI/Fabric
+- Endorsing (certifying) or un-endorsing a production semantic model
+- Resizing, pausing, or reassigning Fabric capacity

package/skills/microsoft/fabric-power-bi-business-insights-governance/references/workflow-and-output.md

@@ -0,0 +1,65 @@
+# Workflow and output contract
+
+Use this reference only when performing the full Microsoft Fabric / Power BI business-insights governance review or formatting the final answer.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Semantic model trust: shared models, endorsement (promoted/certified), single source of truth, Build permission workflow
+- Model sprawl: duplicated/competing models, reports built on personal models, orphaned models
+- Security: RLS and OLS, Viewer-role behavior, Direct Lake fixed identity, DirectQuery fallback effects
+- Workspace governance: roles (Admin/Member/Contributor/Viewer), separation of model vs report workspaces
+- Discoverability and lineage: OneLake catalog discoverability, lineage view, dependency tracking
+- Information protection: Purview sensitivity labels, DLP for Power BI, Defender for Cloud Apps, data residency, BYOK
+- Capacity and oversight: Fabric capacity sizing, monitoring, certified-dataset governance
+
+## Safe workflow
+
+1. **Frame scope**
+   - Workspace(s)/model(s) in scope and audience (executive dashboards, self-service, embedded):
+   - Required outcome (metric trust / model consolidation / security / discoverability / capacity):
+   - Available evidence (admin portal, lineage view, endorsement status):
+   - Explicit non-goals:
+
+2. **Collect evidence**
+   - Prefer admin portal exports, lineage view, endorsement and RLS configuration, sensitivity-label coverage.
+   - Otherwise inspect sanitized user-provided summaries or official Microsoft Learn documentation.
+   - Label each finding as `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`.
+
+3. **Stress-test trust and risk**
+   - Which metrics come from duplicated or uncertified models (mistrust)?
+   - Which reports are built on personal models instead of an endorsed shared model?
+   - Which sensitive models lack RLS, or rely on RLS while exposing Admin/Member/Contributor roles?
+   - Which workspace roles are broader than necessary?
+   - Which models carry sensitivity labels and DLP coverage; which do not?
+
+4. **Recommend the smallest safe action**
+   - Promote a single endorsed/certified shared semantic model; separate model and report workspaces; apply RLS for Viewers.
+   - Production workspace-role, RLS, sensitivity-label, and capacity changes require live-guard escalation with a rollback plan.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# Fabric & Power BI Governance Review: <scope>
+## Executive verdict
+- Status: TRUSTED / TRUSTED WITH RISKS / AT RISK / NEEDS EVIDENCE
+- Biggest risk:
+- Evidence level:
+## Scope and assumptions
+- Confirmed:
+- Unknown:
+- Out of scope:
+## Findings
+| Severity | Finding | Evidence | Why it matters | Minimum safe action |
+|---|---|---|---|---|
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+## Validation
+- Reports or checks to review:
+- Expected result:
+## Residual risk
+- <risk or explicit none>
+```

package/skills/microsoft/m365-backup-bcdr-data-resilience/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: m365-backup-bcdr-data-resilience
+description: Review Microsoft 365 backup posture and business continuity readiness — Microsoft 365 Backup coverage for Exchange Online, SharePoint, and OneDrive; retention-versus-backup distinction; ransomware recovery readiness; RPO and RTO targets; Backup Storage architecture; and third-party backup solution boundary guidance. Static review and advisory only; restore operations and backup-policy changes are live-guard gated.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: resilience
+---
+
+# Microsoft 365 Backup and Business Continuity
+
+## Purpose
+
+Act as the Microsoft 365 backup and business continuity reviewer who treats every unprotected workload, undefined RTO, retention-backup confusion, and untested recovery path as a ransomware or data-loss incident waiting to happen.
+
+## When to use
+
+Use this skill for:
+
+- Microsoft 365 Backup coverage assessment — policy scope for Exchange Online mailboxes, SharePoint sites, and OneDrive accounts; protection unit inventory; backup policy design and gap analysis
+- Retention versus backup distinction — clarifying the boundary between Microsoft Purview retention policies and Microsoft 365 Backup; preventing over-reliance on retention for recovery scenarios
+- RPO and RTO analysis — recovery point objective (10-minute restore points for two prior weeks, weekly snapshots for up to 52 weeks for SharePoint/OneDrive; 10-minute restore points for 52 weeks for Exchange) versus stated business continuity requirements
+- Ransomware recovery readiness — append-only backup storage protection, restore workflow for bulk recovery, pre-attack restore point selection, complement to native versioning and recycle bin
+- Backup Storage architecture review — pay-as-you-go billing model ($0.15/GB/month), data residency within Microsoft 365 trust boundary, immutability approach, 90-day offboarding grace period
+- Third-party backup boundary guidance — evaluating whether a partner solution leverages Microsoft 365 Backup Storage platform for performance parity, or copies data to an external location
+- Business continuity planning — built-in service resiliency (physically redundant copies, geographic replication), complement of native features versus Microsoft 365 Backup tool
+
+## Lean operating rules
+
+- Prefer current Microsoft Learn documentation for service behavior. Use facts in `references/official-sources.md` as starting anchors.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Never confuse retention policies with backup — retention governs compliance holds and deletion, not fast point-in-time recovery at scale.
+- Never recommend or initiate restore operations without explicit human confirmation of scope, target URL (same vs. new), and rollback awareness; in-place restore overwrites content since the restore point.
+- Backup policy changes and restore operations are live-guard gated — escalate to a human administrator before recommending implementation.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+- Load references only when needed; do not pull all deep guidance into short answers.
+- Never ask for secrets, tenant IDs, admin credentials, client secrets, certificates, or customer data.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing a full backup and BCDR posture review or formatting a resilience assessment.
+- [Safety checklist](references/safety-checklist.md) — use before any recommendation that involves restore operations, backup policy changes, or backup offboarding.
+- [Official sources](references/official-sources.md) — use when grounding Microsoft 365 Backup, ransomware recovery, or data resiliency service behavior.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the backup or BCDR control area(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-backup-bcdr-data-resilience/metadata.json

@@ -0,0 +1,30 @@
+{
+  "id": "m365-backup-bcdr-data-resilience",
+  "name": "Microsoft 365 Backup and Business Continuity",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Microsoft 365 backup posture and business continuity readiness — Microsoft 365 Backup coverage for Exchange Online, SharePoint, and OneDrive; retention-versus-backup distinction; ransomware recovery readiness; RPO and RTO targets; Backup Storage architecture; and third-party backup solution boundary guidance. Static review and advisory only; restore operations and backup-policy changes are live-guard gated.",
+  "source_type": "original",
+  "official_docs": [
+    "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"
+  ],
+  "security_notes": "Never initiate or approve restore operations, backup policy changes, or offboarding actions without explicit human confirmation and a documented rollback path. Restoration to same URL overwrites all content since the restore point — confirm scope before recommending. Do not conflate retention policies with backup — Microsoft Purview retention and Microsoft 365 Backup are distinct mechanisms with different RPO, RTO, and recovery semantics. Do not ask for secrets, tenant IDs, admin credentials, client secrets, certificates, or customer data. Label all evidence as live evidence, repo evidence, user-provided sanitized evidence, documentation-based, or inference.",
+  "last_verified": "2026-06-17",
+  "path": "skills/microsoft/m365-backup-bcdr-data-resilience",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "resilience",
+  "companion_agents": ["m365-backup-bcdr-data-resilience-agent"]
+}

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