agentsclimarketplace

Motherduck security governance

Skill motherduckdb/agent-skills/plugins/motherduck-skills-claude/skills/motherduck-security-governance

Opinionated AI agent skills for building applications with MotherDuck

Install
npx -y skills add motherduckdb/agent-skills --skill motherduck-security-governance

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.

What its author says it does

Copied from the file, not written here

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.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

2.6 KB, 412 tokens by cl100k_base, as published. Nobody here has run it

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

Gives 0 of the 12 instructions most audit compliance skills give in 412 tokens

Counted across 936 of the 1,487 authors here whose files we hold, read 2026-08-06

  • group findings by severityin 44 of 936
  • Fetch latest guidelines before each reviewin 43 of 936, across 3 files
  • Check files against all fetched rulesin 42 of 936, across 2 files
  • Output findings in terse file:line formatin 41 of 936, across 3 files
  • Ask user which files to review if none specifiedin 41 of 936, across 3 files
  • Read specified files or prompt user for filesin 39 of 936, across 1 file
  • generate the audit reportin 39 of 936, across 36 files
  • assign a severity to every findingin 25 of 936
  • run automated accessibility scansin 23 of 936, across 13 files
  • map findings to WCAG criteriain 20 of 936, across 10 files
  • confirm audit scopein 19 of 936, across 9 files
  • check title tags and meta descriptions for uniquenessin 19 of 936, across 5 files

Said here and by no other author read

  • Prefer MotherDuck public documentation as source of truth
  • Query MCP feature first if available
  • Verify claims against live public materials
  • Prefer service accounts over personal tokens in production
  • Keep credentials in backend-controlled secrets
  • Prefer structural isolation over query-time filtering

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.