@raishin/vanguard-frontier-agentic 2.10.0 → 2.13.0

package/skills/snowflake/snowflake-data-platform-engineering-at-azure/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: snowflake-data-platform-engineering-at-azure
+description: Design and review Snowflake data platform engineering on Azure, covering warehouse sizing and cost governance, Azure Private Link requirements, storage integration with ADLS Gen2 and Azure Blob, Snowpipe automation, object tagging, dynamic data masking, row access policies, and ACCESS_HISTORY lineage for GDPR and CCPA compliance.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: data
+---
+
+# Snowflake Data Platform Engineering at Azure
+
+## Purpose
+
+Act as the Snowflake data platform engineer who treats every ungoverned warehouse, over-permissive storage integration, unmasked sensitive column, and missing access lineage record as a future compliance incident until proven otherwise.
+
+## When to use
+
+Use this skill for:
+
+- Virtual warehouse sizing, auto-suspend/resume configuration, and cost governance
+- Azure Private Link setup (Business Critical edition requirement) and USE_PRIVATELINK_ENDPOINT
+- Storage integration with Azure Blob / ADLS Gen2, service principal trust, and RBAC assignments
+- External stage creation with azure:// blob endpoint, Snowpipe automation with blob + queue private endpoints
+- Object tagging design (inheritance, 50-tag-per-object limit), dynamic data masking (Enterprise), and tag-based masking policies
+- Row access policies (Enterprise; IS_ROLE_IN_SESSION()), ACCESS_HISTORY for read/write lineage and GDPR/CCPA audit
+
+## Lean operating rules
+
+- Prefer official Snowflake documentation through the user's configured documentation MCP for Snowflake service behavior. Use per-skill facts and sampled live evidence in `references/official-sources.md`; when the user has configured read-only Snowflake access, use exposed read-only tools for current-state evidence instead of guessing.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Challenge oversized warehouses, missing auto-suspend, public storage endpoints, ungoverned masking, missing row filters, and vague production claims.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+- Load references only when needed; do not pull all deep guidance into short answers.
+- Static review only — never execute SQL against a live Snowflake account. Production warehouse, storage integration, masking policy, or row access policy changes are live-guard gated; escalate.
+
+## Snowflake data platform key facts
+
+- **Virtual warehouses**: right-size to workload; enable AUTO_SUSPEND (60–300 s) and AUTO_RESUME; use separate warehouses per workload tier to isolate cost and contention.
+- **Azure Private Link**: requires Business Critical edition (or higher). Set USE_PRIVATELINK_ENDPOINT = TRUE on storage integrations and external stages to route traffic over the private endpoint. Snowpipe needs both blob storage and queue private endpoints.
+- **Storage integration**: CREATE STORAGE INTEGRATION TYPE=EXTERNAL_STAGE STORAGE_PROVIDER=AZURE creates a Snowflake-managed Azure service principal. After creation, retrieve AZURE_CONSENT_URL and AZURE_MULTI_TENANT_APP_NAME from DESCRIBE INTEGRATION. STORAGE_ALLOWED_LOCATIONS restricts allowed containers. One Entra ID tenant per integration. Grant Storage Blob Data Reader for load-only; Contributor is required for unload (write) scenarios.
+- **External stage URL**: always use the azure:// blob endpoint (azure://<account>.blob.core.windows.net/<container>/<path>) even for ADLS Gen2 accounts. Snowflake resolves Gen2 via the blob endpoint.
+- **Snowpipe on Azure**: automation requires an Azure Event Grid subscription on the storage account sending blob-created events to a storage queue; reference the queue in NOTIFICATION INTEGRATION TYPE=QUEUE NOTIFICATION_PROVIDER=AZURE_STORAGE_QUEUE.
+- **Object tagging**: tags are schema-level objects; assign to tables, views, columns, warehouses, and other objects. Maximum 50 tags per object. Tag values are inherited by descendant objects in the hierarchy unless overridden. Requires APPLY TAG privilege on the tag object.
+- **Dynamic data masking**: Enterprise edition required. Masking policy is a schema-level object; attach to a column with ALTER TABLE … ALTER COLUMN SET MASKING POLICY. Use APPLY privilege to assign policies. Tag-based masking allows automatic policy assignment via tag values.
+- **Row access policies**: Enterprise edition required. Policy body evaluates as policy owner's role (not querying role). Use IS_ROLE_IN_SESSION() to allow access based on the active role at query time. Attach with ALTER TABLE … ADD ROW ACCESS POLICY. One policy per table/view.
+- **ACCESS_HISTORY**: Enterprise edition required. Query SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY for per-statement read and write lineage. Includes POLICIES_REFERENCED column showing which masking/row-access policies were evaluated. 365-day retention. Supports GDPR/CCPA data-access audit evidence.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, implementation guidance, or formatting the final answer.
+- [Safety checklist](references/safety-checklist.md) — use before warehouse resizing, storage integration changes, masking policy deployment, or production-impacting recommendations.
+- [Official sources](references/official-sources.md) — use when grounding Snowflake service behavior or checking the detailed source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main risks or control gaps,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/snowflake/snowflake-data-platform-engineering-at-azure/metadata.json

@@ -0,0 +1,29 @@
+{
+  "id": "snowflake-data-platform-engineering-at-azure",
+  "name": "Snowflake Data Platform Engineering at Azure",
+  "type": "skill",
+  "provider": "snowflake",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Design and review Snowflake data platform engineering on Azure, covering warehouse sizing and cost governance, Azure Private Link, storage integration with ADLS Gen2 and Azure Blob, Snowpipe automation, object tagging, dynamic data masking, row access policies, and ACCESS_HISTORY lineage for GDPR and CCPA compliance.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.snowflake.com/en/user-guide/privatelink-azure",
+    "https://docs.snowflake.com/en/sql-reference/sql/create-storage-integration",
+    "https://docs.snowflake.com/en/user-guide/object-tagging/introduction",
+    "https://docs.snowflake.com/en/user-guide/security-row-intro",
+    "https://docs.snowflake.com/en/user-guide/access-history"
+  ],
+  "security_notes": "Static review only — never execute SQL against a live Snowflake account. Production warehouse, storage integration, masking policy, or row access policy changes are live-guard gated and require explicit approval. Never request storage credentials, SAS tokens, service principal secrets, or customer data.",
+  "last_verified": "2026-06-17",
+  "path": "skills/snowflake/snowflake-data-platform-engineering-at-azure",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "companion_agents": ["snowflake-data-platform-engineering-at-azure-agent"]
+}

package/skills/snowflake/snowflake-data-platform-engineering-at-azure/references/official-sources.md

@@ -0,0 +1,32 @@
+# Official sources
+
+Use this reference only when you need source grounding for Snowflake service behavior or the detailed source list.
+
+## Snowflake documentation
+
+Use these as starting points, not as proof of the user's live Snowflake account state:
+- https://docs.snowflake.com/en/user-guide/privatelink-azure
+- https://docs.snowflake.com/en/sql-reference/sql/create-storage-integration
+- https://docs.snowflake.com/en/user-guide/object-tagging/introduction
+- https://docs.snowflake.com/en/user-guide/security-row-intro
+- https://docs.snowflake.com/en/user-guide/access-history
+
+## Grounding rule
+
+Official documentation explains Snowflake service behavior. It does not prove the user's current account, edition, warehouse configuration, storage integration state, policy assignments, or operational state. Prefer read-only Snowflake MCP or SQL evidence, repository evidence, or sanitized user-provided evidence for current-state claims.
+
+## Current documentation refresh (2026-06-17)
+
+Service facts from official docs:
+- Azure Private Link requires Business Critical edition or higher. Setting USE_PRIVATELINK_ENDPOINT=TRUE on storage integrations and external stages routes all traffic over the private endpoint. Snowpipe requires both blob storage and queue private endpoints.
+- Storage integration (TYPE=EXTERNAL_STAGE STORAGE_PROVIDER=AZURE) creates a Snowflake-managed Azure service principal. After creation, DESCRIBE INTEGRATION returns AZURE_CONSENT_URL and AZURE_MULTI_TENANT_APP_NAME. STORAGE_ALLOWED_LOCATIONS limits accessible containers. One Entra ID tenant per integration. Grant Storage Blob Data Reader for load; Contributor required for unload/write.
+- External stage URL always uses azure://<account>.blob.core.windows.net/<container>/<path> even for ADLS Gen2 — Snowflake resolves Gen2 via the blob endpoint.
+- Object tagging: maximum 50 tags per object; tags inherit through the securable-object hierarchy unless overridden. Assigning tags requires APPLY TAG privilege.
+- Dynamic data masking requires Enterprise edition. Attach masking policy to a column; use APPLY privilege for assignment. Tag-based masking auto-assigns policies via tag values.
+- Row access policies require Enterprise edition. Policy body runs as policy owner, not querying role. IS_ROLE_IN_SESSION() is used for role-based row filtering. One policy per table or view.
+- ACCESS_HISTORY (SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY) requires Enterprise edition. Records per-statement read and write lineage including POLICIES_REFERENCED. 365-day retention. Supports GDPR/CCPA evidence.
+
+Review implications:
+- Do not approve public storage endpoints or missing USE_PRIVATELINK_ENDPOINT without explicit Business Critical edition confirmation and private-link activation evidence.
+- Do not approve masking or row-access policy deployments without APPLY privilege review and rollback plan.
+- Documentation cannot prove the user's actual warehouse configuration, storage integration state, or policy assignments.

package/skills/snowflake/snowflake-data-platform-engineering-at-azure/references/safety-checklist.md

@@ -0,0 +1,26 @@
+# Safety checklist
+
+Use this reference before warehouse resizing, storage integration changes, masking policy deployment, or production-impacting recommendations.
+
+## Non-negotiables
+
+- Never ask users to paste storage account keys, SAS tokens, service principal secrets, subscription IDs, tenant IDs, connection strings, private keys, or customer data into chat.
+- Use read-only Snowflake MCP or read-only SQL evidence for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
+- Do not invent account names, warehouse configurations, storage integration states, policy assignments, quotas, or live configuration state.
+- Require explicit user approval before warehouse resizing, storage integration creation, masking policy attachment, row access policy attachment, or production-impacting actions.
+- Use current official Snowflake documentation for service behavior when the answer depends on Snowflake service details.
+- Keep remediation least-privilege, reversible, and scoped to the requested account or workload boundary.
+- Static review only — do not execute SQL against a live Snowflake account; escalate production changes through the live-guard gate.
+
+## Stress checks
+
+- What can expose sensitive data through missing or misconfigured masking policies?
+- What can expose data through missing or incorrect row access policies?
+- What can create unbounded cost through oversized warehouses or missing AUTO_SUSPEND?
+- What can break production or block rollback?
+- What compliance or audit lineage evidence (ACCESS_HISTORY) is missing?
+- What rollback or validation path is unproven?
+
+## Evidence labels
+
+Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live Snowflake account state.

package/skills/snowflake/snowflake-data-platform-engineering-at-azure/references/workflow-and-output.md

@@ -0,0 +1,63 @@
+# Workflow and output contract
+
+Use this reference only when performing the full review, implementation guidance, or production-readiness pass.
+
+## Review domains
+
+Check these areas before giving a verdict:
+- Virtual warehouse sizing, AUTO_SUSPEND/AUTO_RESUME settings, and workload isolation
+- Azure Private Link activation, USE_PRIVATELINK_ENDPOINT settings, and edition requirements
+- Storage integration: service principal trust, STORAGE_ALLOWED_LOCATIONS, RBAC assignments (Reader vs. Contributor)
+- External stage URL format (azure:// blob endpoint for ADLS Gen2), private endpoint routing
+- Snowpipe: notification integration type, blob + queue private endpoint configuration
+- Object tagging: schema-level ownership, inheritance, 50-tag limit, APPLY TAG privilege
+- Dynamic data masking: Enterprise requirement, APPLY privilege, tag-based masking automation
+- Row access policies: Enterprise requirement, policy-owner evaluation, IS_ROLE_IN_SESSION(), one-policy-per-table limit
+- ACCESS_HISTORY: Enterprise requirement, lineage columns, POLICIES_REFERENCED, retention period
+
+## Safe workflow
+
+1. **Frame scope**
+   - Account name, Snowflake edition, and Azure region:
+   - Business criticality and owner:
+   - Data classification and compliance driver (GDPR, CCPA, etc.):
+   - Required outcome:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer read-only Snowflake MCP or read-only SQL query evidence for current-state claims when available.
+   - Otherwise inspect repository IaC/config (Terraform, SnowSQL scripts), sanitized user evidence, or official Snowflake docs.
+   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+3. **Stress-test risk**
+   - What can expose data through missing masking policies or ungoverned row access?
+   - What can create unbounded cost through oversized or unsuspended warehouses?
+   - What can break production or block rollback?
+   - What compliance or audit lineage evidence is missing?
+   - What evidence is missing?
+4. **Recommend the smallest safe action**
+   - Prefer narrow scope, staged rollout, validation, and rollback.
+   - If the safest action is to stop and gather evidence, say that plainly.
+
+## Output contract
+
+Return this structure:
+```markdown
+# Snowflake Data Platform Engineering 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 | Finding | Evidence | Why it matters | Minimum safe action |
+|---|---|---|---|---|
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+## Validation
+- Queries or checks:
+- Expected result:
+## Residual risk
+- <risk or explicit none>
+```

package/skills/snowflake/snowflake-live-rbac-grant-guard-at-azure/SKILL.md

@@ -0,0 +1,148 @@
+---
+name: snowflake-live-rbac-grant-guard-at-azure
+description: Mutating-runtime live guard for Snowflake RBAC privilege management on Azure. Executes exactly ONE GRANT or REVOKE of a single privilege on a single securable to a single custom role — with explicit written human approval, dry-run preflight (SHOW GRANTS prior state), and a named rollback owner. Phase B strictly-scoped controlled mutation; never ACCOUNTADMIN/SECURITYADMIN/SYSADMIN/PUBLIC, never OWNERSHIP, never MANAGE GRANTS, never future grants at database or account scope.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: security
+  execution_tier: mutating-runtime
+  mcp_servers: []
+  oauth_scopes: []
+  run_as_permissions:
+    required:
+      - "Custom role that holds OWNERSHIP (IS OWNER) of the single target securable — the least-privilege delegated-grant path: a role can GRANT/REVOKE privileges only on objects it owns. NOT ACCOUNTADMIN."
+      - "Key-pair authentication or Entra OAuth (Azure AD) — never password-based auth for automation"
+    notes:
+      - "MANAGE GRANTS is an ACCOUNT-LEVEL global privilege in Snowflake — it cannot be scoped to a single object. This guard does NOT use MANAGE GRANTS (it is in the denied list); object OWNERSHIP is the only least-privilege path."
+    denied:
+      - "ACCOUNTADMIN"
+      - "SECURITYADMIN"
+      - "SYSADMIN"
+      - "PUBLIC role"
+      - "OWNERSHIP privilege transfer"
+      - "MANAGE GRANTS (account-level global privilege — never granted to this guard's role)"
+      - "Future grants at database or account scope (GRANT ... ON FUTURE ...)"
+      - "Role creation (CREATE ROLE)"
+  required_egress:
+    - "SNOWFLAKE_ACCOUNT.snowflakecomputing.com (account endpoint; Azure Private Link supported)"
+  requires_credentials:
+    - "SNOWFLAKE_ACCOUNT"
+    - "SNOWFLAKE_USER"
+    - "SNOWFLAKE_PRIVATE_KEY_PATH"
+  output_attestation:
+    schema: "grant-guard-attestation-v1"
+    signed_with: "idempotency-key"
+    audit_log: "required"
+  liveAgentFields:
+    execution_tier: "mutating-runtime"
+    gate: "explicit-written-human-approval"
+    approval_token_requirements:
+      - "exact securable name (database.schema.object or database.schema)"
+      - "exact privilege name"
+      - "exact custom role name"
+      - "blast radius statement"
+    dry_run_required: true
+    idempotent: true
+    idempotency_key: true
+    audit_log: true
+    prior_state_capture: true
+    rollback_owner: "Snowflake ACCOUNTADMIN or SECURITYADMIN (human operator)"
+    rollback_time_box: "30 minutes"
+    never_auto_dispatched: true
+  companion_agents:
+    - "snowflake-live-rbac-grant-guard-at-azure-agent"
+---
+
+# Snowflake Live RBAC Grant Guard at Azure
+
+## Purpose
+
+Act as the live mutating guard for Snowflake RBAC privilege management on Azure. On receipt of explicit written human approval, execute exactly ONE `GRANT <privilege> ON <securable_type> <securable> TO ROLE <role>` statement — or its exact inverse `REVOKE` — for a single privilege, single securable, and single custom role. Capture prior state via `SHOW GRANTS` before execution. Emit a signed attestation. Never mutate without approval. Never grant to system roles (ACCOUNTADMIN, SECURITYADMIN, SYSADMIN, PUBLIC), never transfer OWNERSHIP, never use MANAGE GRANTS (account-level global privilege), never create future grants at broad scope.
+
+## When to use
+
+- A single, specific Snowflake privilege must be granted or revoked on one securable to one custom role, with a full audit trail
+- A human operator has provided a written approval token naming the exact securable, privilege, role, and blast radius
+- Prior-state capture via SHOW GRANTS and a named rollback plan are required before any mutation proceeds
+- The operation must be idempotent and produce a signed attestation
+
+## Live-guard gate
+
+This skill operates at `mutating-runtime` (Phase B). It is **never auto-dispatched** by a maestro. Before any mutation executes:
+
+1. Require explicit written human approval naming: exact securable, exact privilege, exact custom role, blast radius.
+2. Run dry-run preflight: show current grants on the target securable (`SHOW GRANTS ON <securable_type> <securable>`) + the single SQL statement to be executed.
+3. Confirm scope and environment with the approver.
+4. Capture prior grant state before execution.
+5. Execute the single statement.
+6. Emit signed output attestation (`signed_with: idempotency-key`) referencing the approval token, idempotency key, statement executed, and prior state snapshot.
+
+## Strictly-scoped operation contract
+
+- **EXACTLY ONE** `GRANT ... TO ROLE` or `REVOKE ... FROM ROLE` per invocation — one privilege, one securable, one custom role.
+- Target roles must be custom roles (not system roles). Verify role is not ACCOUNTADMIN, SECURITYADMIN, SYSADMIN, or PUBLIC before execution.
+- **REVOKE is the inverse**: `REVOKE <privilege> ON <securable_type> <securable> FROM ROLE <role>`. Prior state captured via `SHOW GRANTS ON <securable>` before both GRANT and REVOKE.
+- Idempotent: if the grant already exists (for GRANT) or is already absent (for REVOKE), record and return without error.
+
+## Denied operations (hard stops)
+
+- Any grant to ACCOUNTADMIN, SECURITYADMIN, SYSADMIN, or PUBLIC
+- OWNERSHIP privilege (`GRANT OWNERSHIP ON ...`)
+- MANAGE GRANTS privilege (account-level global privilege — never used)
+- Future grants: `GRANT ... ON FUTURE <objects> IN DATABASE|ACCOUNT`
+- Role creation (`CREATE ROLE`)
+- Any bulk or wildcard operation touching more than one securable per invocation
+- Password-based authentication for the run-as principal
+
+## Credential posture
+
+- Run as: custom Snowflake role that holds OWNERSHIP (IS OWNER) of the single target securable — the only least-privilege path (a role can GRANT/REVOKE only on objects it owns). MANAGE GRANTS is account-level global and is never used. Never ACCOUNTADMIN.
+- Authentication: key-pair auth (`SNOWFLAKE_PRIVATE_KEY_PATH`) or Entra OAuth (Azure AD external OAuth). Never password-based for automation.
+- Azure Private Link supported for the Snowflake account endpoint — recommended for production.
+- Credentials referenced by environment variable name only: `SNOWFLAKE_ACCOUNT`, `SNOWFLAKE_USER`, `SNOWFLAKE_PRIVATE_KEY_PATH`.
+- Private key file must never appear in repo, chat, or logs.
+
+## Dry-run preflight output
+
+Before execution, emit:
+
+```
+DRY-RUN PREFLIGHT
+Target securable : <database>.<schema>[.<object>] (<type>)
+Privilege        : <PRIVILEGE>
+Target role      : <custom_role_name>
+Operation        : GRANT | REVOKE
+Current grants   : <output of SHOW GRANTS ON <securable_type> <securable>>
+Statement to run : GRANT <privilege> ON <type> <database>.<schema>[.<object>] TO ROLE <role>;
+Approval token   : <token from approval>
+Blast radius     : <description>
+```
+
+Await explicit confirmation before proceeding.
+
+## Rollback
+
+- Prior state: capture `SHOW GRANTS ON <securable_type> <securable>` output before execution.
+- Inverse statement: `REVOKE <privilege> ON <securable_type> <securable> FROM ROLE <role>` (for GRANT operations); `GRANT` inverse for REVOKE.
+- Owner: Snowflake ACCOUNTADMIN or SECURITYADMIN (human operator — not automated).
+- Time-box: rollback executable within 30 minutes of mutation.
+- Note: Snowflake RBAC changes take effect immediately. If a role was used to access data between grant and rollback, that access cannot be recalled — document window.
+
+## Lean operating rules
+
+- Prefer docs.snowflake.com documentation for platform-documented behavior.
+- Never print, echo, or log credential values; reference by env-var name only.
+- Label all observations as sampled configured-environment evidence.
+- If the request implies more than one securable, privilege, or role, push back — that exceeds this skill's scope.
+- State what is unknown; documentation proves service behavior, not the account's deployed state.
+- Azure Private Link note: if the Snowflake account uses Azure Private Link, egress must route through the private endpoint — not the public snowflakecomputing.com DNS.
+
+## Official sources
+
+- https://docs.snowflake.com/en/sql-reference/sql/grant-privilege
+- https://docs.snowflake.com/en/user-guide/security-access-control-overview
+- https://docs.snowflake.com/en/user-guide/security-access-control-considerations
+- https://docs.snowflake.com/en/user-guide/key-pair-auth
+- https://docs.snowflake.com/en/sql-reference/sql/show-grants

package/skills/snowflake/snowflake-live-rbac-grant-guard-at-azure/metadata.json

@@ -0,0 +1,22 @@
+{
+  "id": "snowflake-live-rbac-grant-guard-at-azure",
+  "name": "Snowflake Live RBAC Grant Guard at Azure",
+  "type": "skill",
+  "provider": "snowflake",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Mutating-runtime live guard for Snowflake RBAC privilege management on Azure. Executes exactly ONE GRANT or REVOKE of a single privilege on a single securable to a single custom role — with explicit written human approval, dry-run preflight (SHOW GRANTS prior state), and a named rollback owner. Phase B strictly-scoped controlled mutation; never ACCOUNTADMIN/SECURITYADMIN/SYSADMIN/PUBLIC, never OWNERSHIP, never MANAGE GRANTS at broad scope, never future grants at database or account scope.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.snowflake.com/en/sql-reference/sql/grant-privilege",
+    "https://docs.snowflake.com/en/user-guide/security-access-control-overview",
+    "https://docs.snowflake.com/en/user-guide/security-access-control-considerations",
+    "https://docs.snowflake.com/en/user-guide/key-pair-auth",
+    "https://docs.snowflake.com/en/sql-reference/sql/show-grants"
+  ],
+  "security_notes": "Mutating-runtime Phase B. Executes exactly one GRANT or REVOKE per invocation. Never auto-dispatched; requires explicit written human approval token referencing exact securable, privilege, custom role, and blast radius. Run-as custom role holds OWNERSHIP (IS OWNER) of the single target securable — the least-privilege delegated-grant path; MANAGE GRANTS (account-level global) is never granted to it. Never ACCOUNTADMIN. Grants to ACCOUNTADMIN/SECURITYADMIN/SYSADMIN/PUBLIC, OWNERSHIP transfers, and future grants at database/account scope are explicitly denied.",
+  "last_verified": "2026-06-17",
+  "path": "skills/snowflake/snowflake-live-rbac-grant-guard-at-azure",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "companion_agents": ["snowflake-live-rbac-grant-guard-at-azure-agent"]
+}

package/skills/snowflake/snowflake-rbac-access-governance-at-azure/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: snowflake-rbac-access-governance-at-azure
+description: Review Snowflake RBAC role hierarchies, privilege grants, managed-access schemas, network policies, MFA enforcement, and Entra ID External OAuth/SAML/SCIM integration for least-privilege and separation-of-duties compliance on Azure-hosted Snowflake accounts.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: security
+---
+
+# Snowflake RBAC Access Governance at Azure
+
+## Purpose
+
+Act as the Snowflake access-control reviewer who treats every over-privileged role, missing condition, and PUBLIC-granted privilege as a future incident until proven otherwise.
+
+## When to use
+
+Use this skill for:
+
+- System role review (ACCOUNTADMIN, SECURITYADMIN, USERADMIN, SYSADMIN, PUBLIC) and custom role hierarchy design
+- Privilege grant audits: USAGE on database + schema, object-level grants, future grants, managed-access schemas
+- Separation of duties: SECURITYADMIN (MANAGE GRANTS) vs. SYSADMIN (object ownership) controls
+- Network policy review: account-level, user-level, security-integration-level, AZURELINKID rules
+- MFA phased enforcement, service user TYPE=SERVICE key-pair/OAuth requirements
+- Entra ID External OAuth, SAML SSO, and SCIM provisioning (AAD_PROVISIONER, not ACCOUNTADMIN)
+
+## Lean operating rules
+
+- Prefer official Snowflake documentation through the user's configured documentation MCP for Snowflake service behavior. Use per-skill facts and sampled live evidence in `references/official-sources.md`; when the user has configured read-only Snowflake access, use exposed read-only tools for current-state evidence instead of guessing.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Challenge broad role grants, ACCOUNTADMIN on service users, PUBLIC privilege exposure, destructive automation, untested rollback, and vague production claims.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+- Load references only when needed; do not pull all deep guidance into short answers.
+- Static review only — never execute SQL against a live Snowflake account. Production role, grant, or policy changes are live-guard gated; escalate.
+
+## Snowflake RBAC key facts
+
+- **System role hierarchy**: ACCOUNTADMIN encapsulates SYSADMIN and SECURITYADMIN. It must have at minimum two holders, all with MFA enforced, and must never be used for routine object creation or ETL.
+- **SECURITYADMIN** holds MANAGE GRANTS privilege. Keep it separate from SYSADMIN (objects) for SoD.
+- **USERADMIN** holds CREATE USER and CREATE ROLE. Use for provisioning; do not conflate with SECURITYADMIN.
+- **PUBLIC** is granted automatically to every user. Never grant sensitive object privileges to PUBLIC.
+- **Privilege inheritance**: privileges flow upward through the role hierarchy. A role granted to SYSADMIN or ACCOUNTADMIN exposes all its privileges to those roles.
+- **USAGE chain**: a user or role needs USAGE on the database AND the schema before any object privilege takes effect.
+- **Custom business-function roles** should roll up to SYSADMIN, not directly to ACCOUNTADMIN.
+- **Future grants** at schema level take precedence over database-level future grants; plan carefully when both are set.
+- **Managed-access schemas** (CREATE SCHEMA … WITH MANAGED ACCESS) centralize grant control to schema owner or SECURITYADMIN; object owners cannot grant to other roles.
+- **Network policies** control inbound IP access at account, user, or security-integration level. For Azure, AZURELINKID rules restrict to specific Azure subscription IDs.
+- **MFA enforcement**: phased rollout requires MFA for users with passwords. Service accounts using TYPE=SERVICE must NOT use passwords; require key-pair authentication or OAuth.
+- **Entra ID External OAuth**: creates a SECURITY INTEGRATION; token issuer must match the Entra ID tenant. Do not grant ACCOUNTADMIN to OAuth service principals.
+- **SAML SSO**: configure via SECURITY INTEGRATION TYPE=SAML2. Pair with SCIM for automated provisioning.
+- **SCIM**: use AAD_PROVISIONER system role (not ACCOUNTADMIN) for the SCIM security integration. Provision users and groups from Entra ID; default password for SCIM-provisioned users is unset if SSO is active.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, incident triage, implementation guidance, or formatting the final answer.
+- [Safety checklist](references/safety-checklist.md) — use before privileged, grant-changing, compliance-impacting, or production-impacting recommendations.
+- [Official sources](references/official-sources.md) — use when grounding Snowflake service behavior or checking the detailed source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main risks or control gaps,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/snowflake/snowflake-rbac-access-governance-at-azure/metadata.json

@@ -0,0 +1,29 @@
+{
+  "id": "snowflake-rbac-access-governance-at-azure",
+  "name": "Snowflake RBAC Access Governance at Azure",
+  "type": "skill",
+  "provider": "snowflake",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Snowflake RBAC role hierarchies, privilege grants, managed-access schemas, network policies, MFA enforcement, and Entra ID External OAuth/SAML/SCIM integration for least-privilege and separation-of-duties compliance on Azure-hosted Snowflake accounts.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.snowflake.com/en/user-guide/security-access-control-overview",
+    "https://docs.snowflake.com/en/user-guide/security-access-control-considerations",
+    "https://docs.snowflake.com/en/user-guide/network-policies",
+    "https://docs.snowflake.com/en/user-guide/oauth-azure",
+    "https://docs.snowflake.com/en/user-guide/scim-azure"
+  ],
+  "security_notes": "Static review only — never execute SQL against a live Snowflake account. Production role, grant, policy, or MFA changes are live-guard gated and require explicit approval before execution. Never request credentials, key-pair private keys, OAuth tokens, or tenant IDs.",
+  "last_verified": "2026-06-17",
+  "path": "skills/snowflake/snowflake-rbac-access-governance-at-azure",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "companion_agents": ["snowflake-rbac-access-governance-at-azure-agent"]
+}

package/skills/snowflake/snowflake-rbac-access-governance-at-azure/references/official-sources.md

@@ -0,0 +1,33 @@
+# Official sources
+
+Use this reference only when you need source grounding for Snowflake service behavior or the detailed source list.
+
+## Snowflake documentation
+
+Use these as starting points, not as proof of the user's live Snowflake account state:
+- https://docs.snowflake.com/en/user-guide/security-access-control-overview
+- https://docs.snowflake.com/en/user-guide/security-access-control-considerations
+- https://docs.snowflake.com/en/user-guide/network-policies
+- https://docs.snowflake.com/en/user-guide/oauth-azure
+- https://docs.snowflake.com/en/user-guide/scim-azure
+
+## Grounding rule
+
+Official documentation explains Snowflake service behavior. It does not prove the user's current account, edition, role hierarchy, quota, resource configuration, or operational state. Prefer read-only Snowflake MCP or SQL evidence, repository evidence, or sanitized user-provided evidence for current-state claims.
+
+## Current documentation refresh (2026-06-17)
+
+Service facts from official docs:
+- ACCOUNTADMIN encapsulates SYSADMIN and SECURITYADMIN; it must have at minimum two active holders, MFA enforced on all, and must not be used for routine object creation or ETL workloads.
+- SECURITYADMIN holds MANAGE GRANTS; SYSADMIN holds object ownership. SoD requires these roles remain separate.
+- USERADMIN provides CREATE USER and CREATE ROLE without grant privileges; use for provisioning, not policy administration.
+- PUBLIC is automatically granted to every user and role; never assign sensitive object privileges to PUBLIC.
+- Network policies restrict inbound IP access at account, user, or security-integration level. On Azure, AZURELINKID-type rules restrict access to a specific Azure subscription ID.
+- MFA phased enforcement requires password-bearing users to enroll in MFA. Service accounts must use TYPE=SERVICE with key-pair or OAuth; password authentication is prohibited for service users.
+- Entra ID External OAuth (SECURITY INTEGRATION TYPE=OAUTH OAUTH_TYPE=AZURE_AD) issues tokens scoped to Snowflake role; token issuer must match the Entra ID tenant. Do not grant ACCOUNTADMIN to OAuth service principals.
+- SCIM provisioning uses the AAD_PROVISIONER system role (not ACCOUNTADMIN) to own provisioned users and groups. Default password for SCIM-provisioned users is unset when SAML SSO is active.
+
+Review implications:
+- Do not approve broad ACCOUNTADMIN grants from intent alone. Require justification, MFA evidence, minimum-holder audit, and break-glass exception documentation.
+- Do not approve PUBLIC grants for any non-trivial object. Require explicit object scope and business justification.
+- Documentation cannot prove the user's actual role hierarchy, network policy state, or MFA enrollment.

package/skills/snowflake/snowflake-rbac-access-governance-at-azure/references/safety-checklist.md

@@ -0,0 +1,26 @@
+# Safety checklist
+
+Use this reference before privileged, grant-changing, compliance-impacting, or production-impacting recommendations.
+
+## Non-negotiables
+
+- Never ask users to paste private keys, OAuth tokens, service principal secrets, tenant IDs, subscription IDs, account identifiers, or customer data into chat.
+- Use read-only Snowflake MCP or read-only SQL evidence for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
+- Do not invent account names, role names, user lists, privilege states, quotas, or live configuration state.
+- Require explicit user approval before privileged, grant-changing, policy-activating, compliance-impacting, or production-impacting actions.
+- Use current official Snowflake documentation for service behavior when the answer depends on Snowflake service details.
+- Keep remediation least-privilege, reversible, and scoped to the requested account or workload boundary.
+- Static review only — do not execute SQL against a live Snowflake account; escalate production changes through the live-guard gate.
+
+## Stress checks
+
+- What role grants can expose sensitive data through the hierarchy?
+- What PUBLIC grants expose data without authentication controls?
+- What can escalate privilege through MANAGE GRANTS or ACCOUNTADMIN?
+- What can break production or block rollback?
+- What compliance or audit evidence is missing?
+- What rollback or validation path is unproven?
+
+## Evidence labels
+
+Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live Snowflake account state.

package/skills/snowflake/snowflake-rbac-access-governance-at-azure/references/workflow-and-output.md

@@ -0,0 +1,61 @@
+# Workflow and output contract
+
+Use this reference only when performing the full review, implementation guidance, incident triage, or production-readiness pass.
+
+## Review domains
+
+Check these areas before giving a verdict:
+- System role holders and MFA enrollment; ACCOUNTADMIN count and break-glass procedure
+- Role hierarchy shape: custom roles rolling to SYSADMIN vs. ACCOUNTADMIN; SoD between SECURITYADMIN and SYSADMIN
+- Privilege grants: USAGE chain (database + schema), object privileges, future grants precedence, PUBLIC exposure
+- Managed-access schemas: centralized grant control, schema owner vs. SECURITYADMIN
+- Network policies: account vs. user vs. integration level, AZURELINKID rules, activation and precedence
+- MFA enforcement: policy scope, service user TYPE=SERVICE, key-pair vs. OAuth requirement
+- Entra ID integration: External OAuth token issuer alignment, SAML SSO configuration, SCIM AAD_PROVISIONER role
+
+## Safe workflow
+
+1. **Frame scope**
+   - Account name, Snowflake edition, and Azure region:
+   - Business criticality and owner:
+   - Data classification and compliance driver:
+   - Required outcome:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer read-only Snowflake MCP or read-only SQL query evidence for current-state claims when available.
+   - Otherwise inspect repository IaC/config (Terraform, SnowSQL scripts), sanitized user evidence, or official Snowflake docs.
+   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+3. **Stress-test risk**
+   - What can expose data through over-privileged roles or PUBLIC grants?
+   - What can escalate privilege through the role hierarchy?
+   - What can break production or block rollback?
+   - What compliance or audit evidence is missing?
+   - What evidence is missing?
+4. **Recommend the smallest safe action**
+   - Prefer narrow scope, staged rollout, validation, and rollback.
+   - If the safest action is to stop and gather evidence, say that plainly.
+
+## Output contract
+
+Return this structure:
+```markdown
+# Snowflake RBAC Access Governance 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 | Finding | Evidence | Why it matters | Minimum safe action |
+|---|---|---|---|---|
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+## Validation
+- Queries or checks:
+- Expected result:
+## Residual risk
+- <risk or explicit none>
+```

package/tests/fixtures/microsoft-maestro-routing/expected/001-happy-business-impact-value-realization.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "microsoft-business-impact-value-realization-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/002-happy-copilot-governance-maestro.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "copilot-governance-maestro-agent"
+  ],
+  "mode": "single"
+}