@raishin/vanguard-frontier-agentic 2.10.0 → 2.11.0

package/skills/microsoft/power-automate-automation-risk-review/references/workflow-and-output.md

@@ -0,0 +1,66 @@
+# Workflow and output contract
+
+Use this reference only when performing the full Power Automate automation risk review or formatting the final answer.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Ownership and continuity: single-owner risk on business-critical flows, multiple owners, succession
+- Sharing: run-only vs co-owner, flows shared outside the environment, external co-owners, run-only-user connection context
+- Connector and DLP: business vs non-business classification, blocked combinations, HTTP/custom connector exposure
+- Security segmentation: Environment Maker vs run-only users, environment security groups, least privilege
+- Resilience: error handling (run-after, Terminate), retry policy with exponential backoff, idempotency
+- Monitoring: failure notifications, Application Insights, CoE Starter Kit auditing and alerting
+- Connection lifecycle: credential rotation, expired OAuth tokens (90+ day unused), service-account connections
+- Criticality: which flows are business-critical and what fails if they stop
+
+## Safe workflow
+
+1. **Frame scope**
+   - Flow(s) or environment in scope and business criticality:
+   - Required outcome (continuity / sharing hardening / connector-DLP review / resilience / monitoring):
+   - Available evidence (admin center export, CoE dashboards, flow run history):
+   - Explicit non-goals:
+
+2. **Collect evidence**
+   - Prefer Power Platform admin center exports, CoE Starter Kit dashboards, and flow run histories.
+   - 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 risk**
+   - Which business-critical flows have a single owner (bus-factor risk)?
+   - Where is co-ownership broader than necessary, or shared outside the environment?
+   - Which connectors are unscoped by DLP, or use HTTP/custom connectors that could exfiltrate data?
+   - Which flows lack error handling, retry, or failure notifications?
+   - Which connections risk expiry or use unrotated service-account credentials?
+
+4. **Recommend the smallest safe action**
+   - Prefer run-only sharing over co-ownership; add a second owner for continuity; scope connectors with DLP.
+   - Production DLP, ownership, and connector changes require live-guard escalation with a rollback plan.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# Power Automate Automation Risk Review: <scope>
+## Executive verdict
+- Status: LOW RISK / MODERATE RISK / HIGH 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/power-platform-alm-pipelines/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: power-platform-alm-pipelines
+description: Review Power Platform application lifecycle management health across managed and unmanaged solutions, Power Platform Pipelines, environment strategy (dev/test/prod), solution layering, connection references, environment variables, source control via Git integration, and deployment gates. Use to detect unhealthy ALM patterns, missing rollback paths, and ungoverned production deployments. Static review only; production pipeline and deployment-configuration changes are escalated.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-16"
+  category: delivery
+---
+
+# Power Platform ALM & Pipelines Health Review
+
+## Purpose
+
+Act as the Power Platform ALM governance reviewer who treats every unmanaged solution in production, missing deployment gate, ungoverned pipeline, and absent rollback path as a release-integrity risk until proven otherwise. Cover the full ALM lifecycle from solution design through environment promotion, pipeline execution, and post-deployment validation.
+
+## When to use
+
+Use this skill for:
+
+- Solution hygiene: managed vs. unmanaged solution posture, publisher and prefix standards, solution layering, and avoiding customizations in the default solution
+- Environment strategy: dev/test/prod topology, Managed Environments licensing, environment type configuration (sandbox vs. production), and environment security group assignment
+- Power Platform Pipelines: pipeline host setup, stage configuration, deployment gate checks, pre-flight validation, connection references, and environment variable injection
+- Source control: Git integration for Dataverse solutions, branch strategy, commit discipline, and solution export/import lifecycle
+- Connection references and environment variables: ensuring environment-specific configuration is injected at pipeline time rather than hardcoded
+- Solution Checker and quality gates: running solution analysis before promotion, interpreting critical and high-severity findings
+- CI/CD integration: Azure DevOps Power Platform Build Tools, GitHub Actions for Power Platform, and pac CLI pipeline commands
+- ALM anti-pattern detection: unmanaged solutions in target environments, missing diff FormXml, bypassed stages, manual exports without version tracking
+
+Do not use this skill for:
+
+- Copilot Studio agent governance (use copilot-studio-agent-governance-alm)
+- Dynamics 365 Field Service operations (use d365-field-service-to-cash)
+- D365 implementation phase-gate governance (use d365-success-by-design-governance)
+
+## Lean operating rules
+
+- Prefer current Microsoft Learn documentation for Power Platform ALM, Pipelines, and solution concepts. Never rely on memory for licensing requirements or feature availability.
+- Separate confirmed facts from inference. If pipeline configuration or environment topology was not provided, say so.
+- Challenge unmanaged solutions in production, missing connection references, hardcoded environment-specific values, and deployments that bypass QA stages.
+- Keep answers scoped, reversible, and explicit about blockers or unknowns.
+- Load references only when needed.
+- Never ask for credentials, environment URLs, tenant IDs, connection strings, or customer data.
+- Never bless unmanaged solutions in production environments — this is a hard refusal regardless of urgency.
+- Never approve a deployment recommendation without confirming a documented rollback path exists.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full ALM health review or formatting the final answer.
+- [Safety checklist](references/safety-checklist.md) — use before any recommendation involving production pipeline configuration, deployment stage changes, or solution promotion.
+- [Official sources](references/official-sources.md) — use when grounding Power Platform ALM, Pipelines, or solution behavior.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main solution hygiene, environment strategy, pipeline configuration, or deployment gate gaps,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/microsoft/power-platform-alm-pipelines/metadata.json

@@ -0,0 +1,31 @@
+{
+  "id": "power-platform-alm-pipelines",
+  "name": "Power Platform ALM & Pipelines Health Review",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Power Platform application lifecycle management health including managed versus unmanaged solutions, Power Platform Pipelines configuration, environment strategy across dev/test/prod, solution layering, connection references, environment variables, Git source control integration, deployment gates, and rollback readiness to reduce release-integrity risk.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/power-platform/alm/implement-healthy-alm",
+    "https://learn.microsoft.com/power-platform/alm/pipelines",
+    "https://learn.microsoft.com/power-platform/alm/set-up-pipelines",
+    "https://learn.microsoft.com/power-platform/alm/run-pipeline",
+    "https://learn.microsoft.com/power-platform/alm/move-from-unmanaged-managed-alm",
+    "https://learn.microsoft.com/power-platform/alm/devops-build-tools"
+  ],
+  "security_notes": "Static review only. Never approve unmanaged solutions in production environments or recommend deployment stage bypass regardless of urgency. Do not recommend production pipeline configuration changes, deployment stage removals, or Managed Environment policy changes without documented owner sign-off, blast-radius assessment, and a tested rollback path. Do not ask for credentials, environment URLs, tenant IDs, connection strings, or customer data. Treat missing connection references, hardcoded environment-specific values, and ungoverned pipeline stages as deployment integrity risks until reviewed.",
+  "last_verified": "2026-06-16",
+  "path": "skills/microsoft/power-platform-alm-pipelines",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "delivery",
+  "companion_agents": ["power-platform-alm-pipelines-agent"]
+}

package/skills/microsoft/power-platform-alm-pipelines/references/official-sources.md

@@ -0,0 +1,22 @@
+# Official sources
+
+Use this reference only when you need source grounding for Power Platform ALM, Pipelines, or solution lifecycle behavior.
+
+## Microsoft Learn documentation
+
+Use these as starting points, not as proof of the user's actual pipeline configuration, environment topology, or deployment history:
+
+- https://learn.microsoft.com/power-platform/alm/implement-healthy-alm — Healthy ALM scenarios covering new projects, citizen development, moving from single environment, moving from unmanaged to managed solutions, DevOps automation, and team development. Supports ALM pattern assessment and anti-pattern detection steps.
+- https://learn.microsoft.com/power-platform/alm/pipelines — Overview of Power Platform Pipelines: maker-run preconfigured deployments, pre-flight validation, automatic solution backup, sequential stage enforcement, and licensing requirements for Managed Environments. Supports pipeline configuration review steps.
+- https://learn.microsoft.com/power-platform/alm/set-up-pipelines — Pipeline setup via platform host (maker-configured) and custom host (admin-governed). Supports environment topology and host configuration review.
+- https://learn.microsoft.com/power-platform/alm/run-pipeline — Step-by-step pipeline run: stage selection, pre-flight checks, connection reference and environment variable injection, deployment scheduling, and notes. Supports deployment gate review steps.
+- https://learn.microsoft.com/power-platform/alm/move-from-unmanaged-managed-alm — Scenario 3: migrating from unmanaged to managed solutions in production. Critical for assessing organizations that have not yet adopted managed solution posture.
+- https://learn.microsoft.com/power-platform/alm/devops-build-tools — Power Platform Build Tools for Azure DevOps: export, import, solution checker, and environment management tasks for CI/CD pipelines. Supports pro-dev ALM review.
+- https://learn.microsoft.com/power-platform/alm/devops-github-actions — GitHub Actions for Power Platform: ALM automation for developer and admin teams using GitHub platform.
+- https://learn.microsoft.com/power-platform/developer/cli/reference/pipeline — pac pipeline CLI commands: pac pipeline list and pac pipeline deploy. Supports developer-driven deployment review.
+- https://learn.microsoft.com/power-platform/alm/form-alm-recommendations — Recommendations for healthy model-driven app form ALM: full vs. differential FormXml, publisher ownership, and avoiding manual customizations.xml edits.
+- https://learn.microsoft.com/power-platform/alm/git-integration/overview — Native Git integration for Dataverse solutions: source control, branch strategy, and commit discipline.
+
+## Grounding rule
+
+Official documentation explains Power Platform ALM and pipeline behavior. It does not prove the user's actual environment topology, pipeline configuration, solution posture, or deployment history. Prefer exported solution analysis reports, pipeline run logs, or sanitized user-provided summaries for current-state claims. Label each finding as `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`.

package/skills/microsoft/power-platform-alm-pipelines/references/safety-checklist.md

@@ -0,0 +1,40 @@
+# Safety checklist
+
+Use this reference before any recommendation involving production pipeline configuration changes, deployment stage modifications, Managed Environment policy changes, or solution promotion in Power Platform.
+
+## Non-negotiables
+
+- Never approve unmanaged solutions in production environments. This is a hard refusal regardless of urgency, timeline pressure, or business justification.
+- Never recommend bypassing a pipeline stage (e.g., skipping QA to deploy directly to production). Pipelines enforce sequential stage ordering; document any request to circumvent this and escalate.
+- Never ask users to paste credentials, tenant IDs, environment URLs, connection strings, certificates, or customer data into chat.
+- Use exported solution analysis, pipeline run logs, or sanitized user-provided summaries for current-state claims; otherwise use documentation and label the evidence level.
+- Do not invent environment counts, solution version numbers, pipeline stage names, or deployment success rates.
+- Require explicit human approval before recommending any production pipeline reconfiguration, Managed Environment policy change, or deployment stage removal.
+- Use current official Microsoft Learn documentation for ALM, Pipelines, and solution behavior.
+- Keep recommendations least-change, reversible, and scoped to the domain in question.
+
+## Stress checks
+
+- What solutions exist in an unmanaged state in test or production environments, and what is the migration path to managed?
+- What pipeline stages are present, and is sequential stage ordering enforced?
+- Are connection references and environment variables configured per environment, or are values hardcoded?
+- Is Solution Checker running and passing before each stage promotion?
+- Is a rollback procedure documented, tested, and accessible if a deployment breaks production?
+- Are Managed Environments licensed and configured for all pipeline target environments?
+- Is source control (Git integration or DevOps) tracking solution history, or are exports manual and untracked?
+- Is the pipeline host (platform host or custom host) appropriate for the organization's governance requirements?
+
+## Evidence labels
+
+Use `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's actual environment topology, pipeline configuration, solution posture, or deployment history.
+
+## Live-guard gate
+
+The following actions require explicit human confirmation and are out of scope for automated execution:
+
+- Changing production pipeline stage configuration or removing deployment gates
+- Modifying Managed Environment policies or environment type in production
+- Promoting an unmanaged solution to a target environment
+- Executing bulk solution imports or environment resets
+- Removing or overwriting active customizations in a production environment
+- Changing service principal credentials or pipeline host configuration in production

package/skills/microsoft/power-platform-alm-pipelines/references/workflow-and-output.md

@@ -0,0 +1,68 @@
+# Workflow and output contract
+
+Use this reference only when performing the full Power Platform ALM and Pipelines health review or formatting the final answer.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Solution posture: managed vs. unmanaged solutions in each environment, publisher and prefix discipline, default-solution avoidance, and solution layering conflicts
+- Environment strategy: dev/test/prod topology, Managed Environments licensing for target and host environments, environment types (sandbox vs. production), and security group assignment
+- Pipeline configuration: pipeline host type (platform host vs. custom host), stage ordering, pre-flight validation, automatic solution backup, and deployment approval gates
+- Connection references and environment variables: environment-specific configuration injected at pipeline time rather than hardcoded in components; connection reference mapping per environment
+- Source control: Git integration enabled, branch strategy defined, solution export/import lifecycle tracked, no manual customizations.xml edits
+- Quality gates: Solution Checker run before promotion, critical and high-severity findings resolved, no bypassed stages
+- CI/CD integration: Azure DevOps Build Tools or GitHub Actions configuration, pac CLI authentication, service principal usage
+- Rollback readiness: automatic pipeline solution backups accessible, rollback procedure documented and tested, version history tracked
+
+## Safe workflow
+
+1. **Frame scope**
+   - Environments in scope (dev/test/prod count and topology):
+   - Pipeline type (platform host vs. custom host):
+   - Solution count and approximate complexity:
+   - Required outcome (solution posture / pipeline review / CI/CD integration / rollback readiness):
+   - Explicit non-goals:
+
+2. **Collect evidence**
+   - Prefer exported artifacts: solution list with managed/unmanaged status per environment, pipeline run history, Solution Checker report, Git commit log.
+   - 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 risk**
+   - What solutions exist in an unmanaged state in target (test/prod) environments?
+   - What pipeline stages are missing or can be bypassed?
+   - What connection references or environment variables are hardcoded rather than injected?
+   - Is Solution Checker passing before each promotion?
+   - What rollback exists if a promoted solution breaks production?
+   - What evidence is missing that would change the verdict?
+
+4. **Recommend the smallest safe action**
+   - Prefer solution hygiene and configuration fixes over pipeline architecture changes.
+   - Production pipeline configuration, Managed Environment policy changes, and deployment stage removals require live-guard escalation with a documented rollback plan.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# Power Platform ALM & Pipelines Health Review: <scope>
+## Executive verdict
+- Status: HEALTHY / HEALTHY 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/power-platform-governance-dataverse-security/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: power-platform-governance-dataverse-security
+description: Review and advise on Power Platform environment strategy, Data Loss Prevention (DLP) policy design, Dataverse security model, business unit hierarchy, security roles and teams, table/row/column-level permissions, connector governance, and Center of Excellence (CoE) alignment. Flags environment sprawl, weak DLP, unmanaged connectors, over-privileged Dataverse roles, insecure ad-hoc sharing, and misaligned business unit design. Static review only — no live tenant mutations. Escalates production DLP changes through the live-guard gate.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-16"
+  category: security
+---
+
+# Power Platform Governance & Dataverse Security Review
+
+## Purpose
+
+Act as the Power Platform governance and Dataverse security reviewer who treats every unclassified connector, every environment without a DLP policy, and every overly broad security role as an active risk until documented evidence proves otherwise.
+
+## When to use
+
+Use this skill for:
+
+- Power Platform environment strategy design or audit (default environment hygiene, environment groups, ALM topology)
+- Data Loss Prevention (DLP) policy design, layering, connector classification, and exception governance
+- Dataverse security role review, least-privilege hardening, and table/column privilege audit
+- Business unit hierarchy design and access-level (User / Business Unit / Parent-Child / Organization) analysis
+- Dataverse team design: owner teams vs. access teams, Microsoft Entra group-backed teams
+- Field-level security (column security profiles) review
+- Row-level sharing audit — flagging excessive ad-hoc sharing patterns
+- Center of Excellence (CoE) Starter Kit alignment and maker governance posture
+- Connector classification disputes, custom connector governance, and HTTP connector risk
+
+## Lean operating rules
+
+- Prefer Microsoft Learn documentation (via the configured MCP) for Power Platform and Dataverse service behavior. Label all findings as `documentation-based`, `repo evidence`, `user-provided evidence`, or `inference`.
+- Never ask for tenant IDs, environment IDs, connection strings, service principal secrets, or customer data.
+- Separate confirmed facts from inference. If state was not shown or queried, say so.
+- Challenge broad connector access, unclassified custom connectors, Organization-scope privileges on sensitive tables, and requests to disable or bypass DLP for convenience.
+- Production DLP changes are live-guard gated — always require explicit human approval, a blast-radius assessment, and a rollback path before recommending production policy mutation.
+- Keep all advice scoped, reversible, and least-privilege. State blockers and unknowns explicitly.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full governance review or producing a structured findings report.
+- [Safety checklist](references/safety-checklist.md) — use before any recommendation that touches production DLP, environment deletion, or Dataverse role bulk-assignment.
+- [Official sources](references/official-sources.md) — use when grounding Power Platform or Dataverse service behavior.
+- [Dataverse Security and DLP Domain Guide](references/dataverse-dlp-domain-guide.md) — use for failure modes, Dataverse privilege model depth, DLP layering pitfalls, and pushback criteria.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main governance 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/power-platform-governance-dataverse-security/metadata.json

@@ -0,0 +1,31 @@
+{
+  "id": "power-platform-governance-dataverse-security",
+  "name": "Power Platform Governance & Dataverse Security Review",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Power Platform environment strategy, DLP policy design, Dataverse security roles, business unit hierarchy, table/row/column permissions, connector governance, and Center of Excellence alignment for least-privilege and sprawl risks. Static review only; production DLP changes are live-guard gated.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/power-platform/guidance/adoption/environment-strategy",
+    "https://learn.microsoft.com/power-platform/guidance/adoption/dlp-strategy",
+    "https://learn.microsoft.com/power-platform/admin/wp-security-cds",
+    "https://learn.microsoft.com/power-platform/admin/wp-data-loss-prevention",
+    "https://learn.microsoft.com/power-platform/admin/database-security",
+    "https://learn.microsoft.com/power-platform/guidance/coe/starter-kit"
+  ],
+  "security_notes": "Production DLP policy changes are live-guard gated and must never be auto-applied. Never request or accept tenant IDs, environment IDs, connection strings, service principal secrets, or customer data. Refuse requests to disable or broadly relax DLP for convenience. All privilege grants in Dataverse are additive and accumulative — over-permissioning cannot be hidden by app-level controls alone. Connector classification disputes must document business justification before any reclassification.",
+  "last_verified": "2026-06-16",
+  "path": "skills/microsoft/power-platform-governance-dataverse-security",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "security",
+  "companion_agents": ["power-platform-governance-dataverse-security-agent"]
+}

package/skills/microsoft/power-platform-governance-dataverse-security/references/dataverse-dlp-domain-guide.md

@@ -0,0 +1,73 @@
+# Dataverse Security and DLP Domain Guide
+
+Use this reference for Power Platform DLP policy failure modes, Dataverse privilege model depth, connector governance pitfalls, and pushback criteria.
+
+## What people get wrong
+
+The lazy story is:
+
+> Block all connectors in the default environment and the tenant is secure.
+
+Wrong. DLP covers connector data flows but does not control Dataverse record access, column exposure, or maker ability to create new environments (if unrestricted). Governance requires both DLP discipline and Dataverse security model discipline.
+
+Common bad assumptions:
+
+- The default environment is automatically secured by a tenant policy — it requires explicit DLP hardening and environment routing.
+- Organization-scope read on a Dataverse table is acceptable for all users because "they need access to the app."
+- Ad-hoc row sharing is a safe substitute for a proper security role design.
+- Multiple DLP policies on the same environment simplify management — they fragment the connector space and create hard-to-debug compliance violations.
+- Blocking a connector in DLP prevents makers from using HTTP or custom connectors to reach the same endpoint.
+- Column-level security (field-level security) compensates for a weak record-level security model — it does not; users must already have record access for column security to apply.
+- Removing a user from a team automatically removes their accumulated privileges if the team has security roles.
+
+## DLP failure modes
+
+- Default environment has no tenant-level DLP policy, allowing any connector combination to be used by all licensed users in the organization.
+- Custom connectors are unclassified (default non-business) and can be used with any other non-business connectors, including third-party data exfiltration endpoints.
+- HTTP connector is not blocked, providing a generic bypass path to arbitrary external endpoints regardless of connector classification.
+- Multiple environment-level policies stack on the tenant policy, fragmenting connector availability in ways that makers cannot observe or understand.
+- Exception process for DLP changes is informal — admins reclassify connectors on request without blast-radius assessment or documentation.
+- No tenant-level policy covers newly created environments, leaving all maker-provisioned environments open until manually assigned.
+
+## Dataverse privilege failure modes
+
+- System Administrator role assigned to too many users, bypassing all record-level and column-level security controls.
+- Security roles grant Organization-scope Create, Write, or Delete on sensitive tables (customer data, financial records, HR data) where User-scope would suffice.
+- Business unit hierarchy is flat (single root BU) making Parent-Child scope equivalent to Organization scope, defeating the hierarchy-based isolation intent.
+- Owner teams accumulate security roles over time without periodic review — effective user access grows silently as team membership changes.
+- Access teams are used where ownership and accountability for records are required — access teams cannot own records and should not substitute for owner teams with defined roles.
+- Ad-hoc sharing of individual rows proliferates to compensate for missing role design — sharing is non-auditable at scale and degrades query performance.
+- Column security profiles are assigned to broad groups or teams, making "restricted" columns accessible to most of the organization.
+- Microsoft Entra guest accounts are granted Dataverse security roles without confirming they are excluded from sensitive connector access.
+
+## Minimum safe workflow
+
+1. Inventory: enumerate environments, DLP policies in scope, Dataverse security roles, business unit hierarchy, and team structure.
+2. Map coverage gaps: which environments have no DLP policy? Which tables have Organization-scope privileges in roles assigned to broad populations?
+3. Classify risk: connector exfiltration paths, privilege escalation via System Administrator, cross-BU data leakage, and ad-hoc sharing debt.
+4. Recommend smallest safe action: DLP policy changes on test environment first; role cloning with reduced scope before removing existing roles; BU restructuring in a sandbox.
+5. Gate production changes: explicit approval, blast-radius assessment, and rollback plan for any production DLP or Dataverse role change.
+
+## Verification targets
+
+- Tenant-level and environment-level DLP policy coverage: connector classification lists, environments in scope, custom connector assignments
+- Dataverse security roles: table-level privileges and access levels (None/User/BU/Parent-Child/Organization) for sensitive tables
+- Business unit hierarchy depth and whether hierarchy or position hierarchy is used
+- Team types (owner vs. access) and security role assignments per team
+- System Administrator role membership — minimize to operational necessity
+- Column security profiles: which columns are protected, which profiles exist, and which users/teams hold each profile
+- Ad-hoc sharing volume: row-level sharing records in audit logs or CoE inventory
+- CoE Starter Kit deployment and maker governance signals: environment request coverage, DLP change request workflow active
+
+## When to push back
+
+Push back if the user asks to:
+
+- disable DLP or exempt an environment from all policies to unblock a delivery deadline
+- grant Organization-scope privileges on sensitive tables to all licensed users
+- classify a custom connector as Business Data without documenting the endpoint and data handled
+- leave the HTTP connector unclassified or in the Non-Business group
+- rely on app-level access control as the sole substitute for Dataverse security roles
+- bulk-share rows with a broad Microsoft Entra group instead of designing a proper security role
+- add users directly to the System Administrator role to simplify troubleshooting
+- apply production DLP or role changes without a blast-radius assessment and rollback plan

package/skills/microsoft/power-platform-governance-dataverse-security/references/official-sources.md

@@ -0,0 +1,31 @@
+# Official sources
+
+Use this reference only when grounding Power Platform or Dataverse service behavior. These are starting points, not proof of the user's live tenant state.
+
+## Microsoft Learn documentation
+
+- https://learn.microsoft.com/power-platform/guidance/adoption/environment-strategy — Tenant environment strategy, environment groups, ALM topology, default environment hygiene
+- https://learn.microsoft.com/power-platform/guidance/adoption/dlp-strategy — DLP policy strategy, tiered data policies (Productivity / Power User / Pro Dev), connector classification
+- https://learn.microsoft.com/power-platform/admin/wp-security-cds — Security concepts in Dataverse: role-based security, business units, sharing, record-level and column-level security
+- https://learn.microsoft.com/power-platform/admin/wp-data-loss-prevention — Data loss prevention policies: connector classification (Business / Non-Business / Blocked), tenant and environment scope
+- https://learn.microsoft.com/power-platform/admin/database-security — Configuring user security in a Power Platform environment: security roles, teams, business units, user assignment
+- https://learn.microsoft.com/power-platform/admin/security-roles-privileges — Security roles and privileges reference
+- https://learn.microsoft.com/power-platform/admin/manage-teams — Dataverse teams: owner teams, access teams, Microsoft Entra group teams
+- https://learn.microsoft.com/power-platform/admin/field-level-security — Column (field) level security profiles
+- https://learn.microsoft.com/power-platform/guidance/coe/starter-kit — Center of Excellence (CoE) Starter Kit overview and governance tooling
+- https://learn.microsoft.com/power-platform/guidance/adoption/secure-default-environment — Securing the default environment
+- https://learn.microsoft.com/power-platform/admin/governance-considerations — Power Platform admin governance considerations
+
+## Grounding rule
+
+Official documentation explains Power Platform and Dataverse service behavior. It does not prove the user's current tenant, environment, DLP policy, or Dataverse role configuration. Prefer read-only Power Platform admin center evidence, repository evidence (exported policies/roles), or sanitized user-provided evidence for current-state claims. Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+
+## Key service facts (grounded 2026-06-16)
+
+- DLP policies classify connectors into Business, Non-Business, and Blocked groups. Connectors across Business and Non-Business groups cannot be combined in the same app or flow — this is enforced at runtime.
+- Tenant-level DLP policies apply to all environments or all-except-selected; environment-level policies stack on top. Multiple policies on the same environment fragment the connector space and should be minimized.
+- The default environment cannot be deleted; securing it (blocking all blockable connectors, routing new makers via environment routing) is a Day 1 governance priority.
+- Dataverse security is accumulative: a user's effective access is the union of all their directly assigned security roles plus all roles inherited from teams they belong to. The most permissive access level prevails — you cannot restrict a record for a user who already has Organization-scope read via another role.
+- Column-level security (field-level security) applies only to users who already have record-level access. It adds overhead and should not be used excessively.
+- Ad-hoc row sharing is harder to audit than role-based access and should be an exception, not the default pattern.
+- Microsoft Entra group-backed owner teams are the recommended pattern for scalable, auditable security role assignment.

package/skills/microsoft/power-platform-governance-dataverse-security/references/safety-checklist.md

@@ -0,0 +1,36 @@
+# Safety checklist
+
+Use this reference before any recommendation that touches production DLP policy mutation, environment deletion, Dataverse role bulk-assignment, or connector reclassification affecting a production environment.
+
+## Non-negotiables
+
+- Never ask for or accept tenant IDs, environment IDs, connection strings, service principal secrets, user passwords, or customer PII.
+- Never recommend disabling or broadly relaxing DLP policy to unblock delivery without documented business justification, blast-radius assessment, and explicit written approval.
+- Production DLP changes are live-guard gated: always require explicit human confirmation, a blast-radius scope (which apps/flows would break), and a tested rollback path before applying any policy change.
+- Do not invent environment names, connector classifications, security role privileges, or live configuration state.
+- Require explicit user approval before recommending mutations that change connector availability, security role assignment, business unit membership, or environment permissions at production scope.
+- Use current official Microsoft Learn documentation for service behavior when the answer depends on Power Platform or Dataverse service details.
+- Keep all remediations least-privilege, reversible, and scoped to the requested environment or workload boundary.
+
+## Stress checks
+
+- What connectors, if reclassified, would allow data to flow to uncontrolled external endpoints?
+- What Dataverse privilege change could expose records across business unit boundaries unintentionally?
+- What environment or DLP change could break existing production apps or flows?
+- What compliance or audit evidence is missing to support the recommendation?
+- What rollback or validation path is unproven for the recommended change?
+- Is the request to relax a control actually a symptom of missing environment strategy or CoE process?
+
+## Evidence labels
+
+Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live tenant DLP state, environment inventory, or Dataverse role configuration.
+
+## Live-guard gate reminder
+
+DLP policy mutations on production environments must not be auto-applied. The required sequence is:
+1. Identify blast radius (which apps/flows in scope environment use affected connectors).
+2. Communicate change to affected makers.
+3. Obtain explicit written approval from the Power Platform admin or tenant admin.
+4. Apply change in a test or sandbox environment first.
+5. Validate no regressions before production application.
+6. Document rollback procedure (policy export before change, restore path if issues arise).

package/skills/microsoft/power-platform-governance-dataverse-security/references/workflow-and-output.md

@@ -0,0 +1,67 @@
+# Workflow and output contract
+
+Use this reference only when performing the full governance review, structured findings report, environment strategy assessment, or DLP/Dataverse security implementation guidance.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- **Environment strategy**: default environment hygiene, environment count and purpose, environment groups and rules, ALM topology (Dev/Test/Prod), maker provisioning process, and shared vs. isolated environment decisions
+- **DLP policy posture**: coverage gaps (environments not covered), connector classification correctness, custom connector governance, HTTP connector exposure, policy layering complexity, and exception/escalation process
+- **Dataverse security roles**: privilege scope (User / Business Unit / Parent-Child / Organization) per table, wildcard or overly broad role assignments, System Administrator minimization, and role-to-job-function alignment
+- **Business unit design**: hierarchy depth, cross-business-unit data access patterns, hierarchy vs. position hierarchy use, and misaligned BU structure vs. org structure
+- **Team design**: owner teams vs. access teams, Microsoft Entra group-backed teams vs. manual membership, and security role assignment via teams vs. direct assignment
+- **Sharing posture**: ad-hoc row sharing volume, access team template appropriateness, and sharing with broad groups
+- **Column security**: field-level security profile coverage on PII or sensitive columns, profile assignment scope, and overhead risk
+- **CoE alignment**: CoE Starter Kit deployment, environment request process, DLP change request workflow, and maker governance signals
+
+## Safe workflow
+
+1. **Frame scope**
+   - Tenant name (sanitized) / environment context:
+   - Business criticality and data classification:
+   - Compliance drivers (industry, regulation):
+   - Required outcome:
+   - Explicit non-goals:
+
+2. **Collect evidence**
+   - Prefer exported DLP policy JSON, security role definitions, environment inventory, or Power Platform admin center screenshots as repo/user evidence.
+   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+
+3. **Stress-test risk**
+   - What connectors can exfiltrate data to uncontrolled endpoints?
+   - What Dataverse privileges can expose data beyond intended scope?
+   - What environment gaps allow makers to bypass DLP?
+   - What sharing or column security gaps leave sensitive tables exposed?
+   - What evidence is missing that prevents a stronger conclusion?
+
+4. **Recommend the smallest safe action**
+   - Prefer targeted DLP policy edits, role cloning with reduced scope, and staged rollout over broad changes.
+   - Production DLP changes require live-guard approval, blast-radius assessment, and rollback plan.
+   - If the safest action is to gather evidence first, say that plainly.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# Power Platform Governance & Dataverse Security 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 | Area | Finding | Evidence | Why it matters | Minimum safe action |
+|---|---|---|---|---|---|
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+## Validation
+- Checks or admin center views:
+- Expected result:
+## Residual risk
+- <risk or explicit none>
+```