Motherduck Security Governance

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.

Workflow

1. Identify where credentials live and who administers them. 2. Define the actual isolation boundary: account, database, schema, or query filter. 3. Determine who can read, write, share, or administer the data. 4. Check whether residency, compliance, or contractual guarantees are part of the requirement. 5. Use only publicly documented security anchors unless the user has current commercial documentation in hand.

Open Next

• Read references/SECURITY_GOVERNANCE_PLAYBOOK.md for public security anchors, service-account posture, residency framing, sharing boundaries, and what not to overstate

Related Skills

• motherduck-connect for secure token handling and endpoint selection
• motherduck-explore when governance depends on what data is actually present and how it is partitioned
• motherduck-share-data when the design includes governed data distribution

Security and Governance Playbook

Reference for discussing MotherDuck security posture, access-control boundaries, residency framing, and governance-safe architecture defaults.

Contents

When To Use

• The user asks about residency, isolation, access control, auditing, sharing, or governance.
• The user is reviewing a proposed architecture for tenant isolation or token handling.
• The user needs a secure default pattern for an app, pipeline, or analytics rollout.

SQL Review Checks

Use SQL to validate the governance boundary that the architecture claims to have.

Check what databases and aliases are actually in scope:

SELECT alias AS database_name, type
FROM MD_ALL_DATABASES();

Check what shares are owned:

FROM MD_INFORMATION_SCHEMA.OWNED_SHARES;

Check what shares are attached from others:

FROM MD_INFORMATION_SCHEMA.SHARED_WITH_ME;

Check whether a proposed consumer path is reading from a curated shared database instead of a raw internal database:

SELECT *
FROM "shared_partner_data"."main"."approved_metrics"
LIMIT 10;

Secure Defaults

• Prefer service accounts for production systems, not personal tokens.
• Prefer backend-held credentials over browser-exposed credentials.
• Prefer structural isolation over query-time tenant filtering for serious B2B or CFA workloads.
• Prefer region-specific guidance when residency matters.
• Use shares as database-level read-only publication boundaries, not as row-level security.

Publicly Documented Security Anchors

These are safe public anchors to use:

• MotherDuck publicly states that it undergoes independent third-party audits and has a SOC 2 Type II attestation.
• MotherDuck publicly states that it is GDPR verified and that signed DPAs can be requested via security@motherduck.com.
• Public pricing and trust pages state that compliance reports are available through the commercial process, and that some commercial or security features vary by plan.
• MotherDuck publicly documents service accounts as organization-owned non-human identities for applications and automation.
• MotherDuck publicly documents shares as read-only, zero-copy, database-level distribution rather than row-level or table-level entitlement enforcement.
• MotherDuck publicly documents SSO support with identity providers such as Okta, Microsoft Entra ID, and SAML/OIDC options. Verify current plan requirements and limitations before promising a rollout path.
• MotherDuck publicly documents data recovery through automatic snapshots, named snapshots, point-in-time restore, and UNDROP DATABASE, with retention and availability varying by plan.

Do not overstate beyond those anchors. If the user needs a compliance report, a signed DPA, a HIPAA BAA, or plan-specific contractual commitments, say that these require confirmation through current Trust/Security or commercial channels.

Governance Checklist

Answer these questions:

1. Where do credentials live? 2. What is the isolation boundary: account, database, schema, or query filter? 3. Who can read, write, share, or administer data? 4. Does the design require region or residency constraints? 5. What proof or documentation still needs to come from current public trust or compliance material?

If the design claims governed distribution, also ask:

6. Which database is actually being shared? 7. Is the shared database curated or just a raw internal workspace? 8. Does the plan rely on query-time tenant filtering where a stronger database or service-account boundary is warranted?

Region and Residency Guidance

• Treat region and residency as first-class architectural constraints.
• Verify current public region availability before answering. MotherDuck's public pricing page currently lists AWS us-east-1 and AWS eu-central-1.
• Distinguish clearly between:
• region availability
• data residency expectations
• network connectivity requirements
• contractual or compliance requirements

If the user is really asking for a residency guarantee or legal assurance, direct them to current Trust & Security materials and the account/security channel rather than improvising.

Product-Specific Patterns To Prefer

• Hypertenancy for strong per-customer or per-user compute isolation
• one service account per customer or workload boundary when the blast radius matters
• read-only tokens or read-scaling tokens for high-concurrency read paths
• backend-only token handling for applications
• careful sharing boundaries when using shares or Dives

Dives and Sharing Guidance

• Dives are shareable live visualizations that persist in the MotherDuck workspace.
• Shares are zero-copy, database-level, and read-only. Use them for governed distribution, not as a substitute for row-level entitlement logic.
• Do not assume Dives replace all BI tooling; MotherDuck positions them for the long tail of questions that do not justify a full dashboard.
• For broad external or client-facing access, be explicit about whether the right pattern is a share, a Dive, or a full customer-facing application.

SSO Guidance

• Treat SSO as an organization-level authentication control, not a data-access boundary.
• Current public docs place SSO on Business and Enterprise plans; verify the organization plan before proposing implementation work.
• Confirm verified domains, IdP ownership, and domain conflicts before activation.
• Once SSO is active for matching domains, users should expect to authenticate through the identity provider rather than unmanaged login paths.
• If the user needs multi-org SSO behavior, verify current docs before committing; do not infer it from ordinary SAML or OIDC support.

Recovery and Retention Guidance

• Treat recovery posture as a governance requirement when the user asks about rollback, deletion recovery, audit readiness, or operational resilience.
• Verify the plan-specific retention window before promising a recovery target; current docs give Business configurable retention up to 90 days, with narrower defaults on lower tiers.
• Use named snapshots for explicit restore points that should survive automatic snapshot garbage collection.
• UNDROP DATABASE can recover dropped databases only within the documented recovery window.

What Not To Overstate

• Do not imply certifications, contractual terms, or legal guarantees that are not explicitly documented in current MotherDuck materials.