How do I install the Security Governance skill?

Run npx skillmds add majiayu000/security-governance in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Security Governance safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: reads secrets. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Security Governance?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Security Governance free to use?

Yes. Installing skills from SkillMD is free. This skill is licensed under MIT.

Who published Security Governance?

majiayu000 (@majiayu000) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Security Governance by majiayu000 — Agent Skill

Name: Security Governance
Rating: 4.2 (5 reviews)
Author: majiayu000

Security Governance

Explain MotherDuck security, governance, and access-control patterns. Use when a security_compliance_owner, technical_owner, or application_builder is asking about residency, access boundaries, service accounts, isolation, sharing, or governance posture.

majiayu000 c18854b 2 files · 3.0 KB Updated Sep 9, 2026 567 repo stars

File contents

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.
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.

Workflow

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

Open Next

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

Related Skills

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

---name: security-governancedescription: Explain MotherDuck security, governance, and access-control patterns. Use when a security_compliance_owner, technical_owner, or application_builder is asking about residency, access boundaries, service accounts, isolation, sharing, or governance posture.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. - 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. ## 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 - `references/SECURITY_GOVERNANCE_PLAYBOOK.md` for public security anchors, service-account posture, residency framing, sharing boundaries, and what not to overstate ## Related Skills - `connect` for secure token handling and endpoint selection - `explore` when governance depends on what data is actually present and how it is partitioned - `share-data` when the design includes governed data distribution

Frequently asked questions