Explain MotherDuck security, governance, and access-control patterns. Use for any question about SOC 2, GDPR, compliance, data residency, regions, SSO, service accounts, token handling, tenant isolation, sharing…
---
name: motherduck-security-governance
description: Explain MotherDuck security, governance, and access-control patterns. Use for any question about SOC 2, GDPR, compliance, data residency, regions, SSO, service accounts, token handling, tenant isolation, sharing boundaries, snapshots and recovery, or governance posture — including when a security_compliance_owner, technical_owner, or application_builder is evaluating MotherDuck.
license: MIT
---
# Security and Governance
Use this skill when the user is evaluating whether MotherDuck can meet their security, governance, and deployment requirements. This is a workflow skill focused on control boundaries and safe patterns.
## Source Of Truth
- Prefer current MotherDuck public trust, security, pricing, and product documentation.
- If the MotherDuck MCP `ask_docs_question` feature is available, use it first.
- Use current SSO and data-recovery docs when the requirement involves identity-provider login, restore windows, named snapshots, or `UNDROP DATABASE`.
- Verify claims against live public materials before making compliance or commercial assertions.
## Default Posture
- Prefer service accounts for production systems, not personal tokens.
- Keep credentials in backend-controlled secrets, not browsers or hardcoded notebooks.
- Prefer structural isolation over query-time tenant filtering for serious B2B or CFA workloads.
- Treat region and residency as first-class architectural constraints that require current public confirmation.
- Be explicit about whether the boundary is a share, a Dive, a database, or a full application.
- Separate documented product guarantees from architectural recommendations and assumptions in the final answer.