@raishin/vanguard-frontier-agentic 2.9.0 → 2.11.0

package/skills/netsuite/netsuite-web-services-integration-skill/metadata.json

@@ -0,0 +1,38 @@
+{
+  "id": "netsuite-web-services-integration-skill",
+  "name": "NetSuite Web Services Integration Skill",
+  "type": "skill",
+  "provider": "netsuite",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Static-review flashlight for NetSuite SuiteTalk REST/SOAP API design, integration record configuration, and OAuth 2.0 authentication posture. Reviews REST record endpoints, RESTlet definitions, integration record settings, and authentication method selection against Oracle's documented posture. TRIG",
+  "source_type": "original",
+  "category": "platform",
+  "execution_tier": "static-review",
+  "oauth_scopes": [],
+  "mcp_servers": [],
+  "run_as_permissions": {},
+  "sandbox_only": false,
+  "production_allowed": true,
+  "official_docs": [
+    "https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/article_2104046421.html",
+    "https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_157780312610.html",
+    "https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_158263562006.html",
+    "https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/article_1011040638.html",
+    "https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_4381113277.html",
+    "https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/chapter_4247329078.html",
+    "https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_N3445710.html",
+    "https://www.netsuite.com/portal/services/training/suite-training/netsuite-certification.shtml"
+  ],
+  "security_notes": "Static review only — never calls NetSuite APIs, never requests or stores credentials, tokens, client secrets, or org IDs. Works exclusively from sanitized configuration excerpts. SOAP usage is flagged as a migration risk citing the confirmed sunset timeline. OAuth 2.0 is confirmed NOT supported for SOAP; only for REST, RESTlets, and SuiteAnalytics Connect. Never recommends the Administrator role. Custom reviewer role requires 2FA when permissions include Access Token Management or OAuth 2.0 Authorized Applications Management.",
+  "last_verified": "2026-06-09",
+  "path": "skills/netsuite/netsuite-web-services-integration-skill",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/netsuite/netsuite-web-services-integration-skill/references/auth-posture-matrix.md

@@ -0,0 +1,14 @@
+# Auth Posture Matrix
+
+Matrix of supported authentication methods by integration type: REST, RESTlet, SOAP, SuiteAnalytics Connect
+
+Scope: SuiteTalk REST/SOAP API design and integration record configuration review. Flags SOAP usage as migration risk, validates OAuth 2.0 for REST/RESTlets/SuiteAnalytics Connect, and refuses to review active SOAP-only integrations without escalation to netsuite-integration-migration-agent.
+
+- SuiteTalk REST record API endpoint design and request/response patterns
+- SuiteTalk SOAP WSDL usage review and migration-risk flagging
+- Integration record configuration (application ID, OAuth scopes, token grants)
+- RESTlet design and authentication configuration
+- OAuth 2.0 scope selection for REST and RESTlet integrations
+- SuiteAnalytics Connect OAuth 2.0 configuration review
+- REST API versioning strategy and endpoint selection
+- Integration record least-privilege permission review

package/skills/netsuite/netsuite-web-services-integration-skill/references/least-privilege.md

@@ -0,0 +1,61 @@
+# Least-privilege NetSuite posture for NetSuite Web Services Integration Agent
+
+## Execution tier
+
+**T0 — Static Review**
+
+Rationale: `execution_tier: "static-review"` declared in `metadata.json`. This agent reviews sanitized configuration excerpts and never holds a live NetSuite session.
+
+## Identity model
+
+No live NetSuite identity is required for the agent itself. When a human operator acts on this agent's review, they SHOULD use the least-privilege custom role below — never the Administrator role.
+
+## Recommended custom role
+
+- **Custom role name:** NetSuite Web Services Integration Reviewer (custom)
+- **Copy from standard role:** Integration Manager (or closest available standard role with web services access) (NetSuite guidance: start from a copy of a standard role, then remove unneeded permissions).
+- **Modules in scope:** REST Web Services, SOAP Web Services, OAuth 2.0, Token-Based Authentication
+- **Two-Factor Authentication required:** Yes
+
+### Minimal permissions
+
+- **REST Web Services** (View) — Required to review REST integration record configurations
+- **SOAP Web Services** (View) — Required to review SOAP configuration for migration-risk assessment
+- **Integration Record** (View) — Required to inspect integration record settings and OAuth grant configuration
+- **Log in using OAuth 2.0 Access Tokens** (View) — Required to review OAuth 2.0 token grant configuration
+- **Access Token Management** (View) — Required to review TBA token records — triggers mandatory 2FA per evidence-matrix row 5c
+
+## Forbidden
+
+- Administrator role
+- Full permission roles
+- Any role with Create/Edit/Full on Integration Record or Token Management
+
+## Blast-radius bound
+
+Even if fully compromised, this agent cannot mutate a NetSuite account: it has no live session, no API tokens, and no SDF deploy rights. It can only produce review text.
+
+## Refusal triggers
+
+- Request includes credentials, tokens, secrets, client secrets, or API keys — refuse and instruct user to redact
+- Request asks agent to use the Administrator role or roles with full permissions
+- Request asks agent to fire live API calls or mutate a NetSuite account
+- User claims Web Services Developer Professional is a confirmed available exam without citing the official exam page — mark status UNVERIFIED per evidence-matrix row 1f
+- Request requires evaluating SOAP integration as a long-term strategy without flagging migration risk
+
+## Escalation path
+
+Route all live-account changes to `netsuite-live-org-mutation-guard-agent` with a named human decision owner and a structured case capsule.
+
+## Role creation steps
+
+1. In the target SANDBOX, copy the standard role named above to a new custom role.
+2. Remove every permission not listed under Minimal permissions.
+3. Add only the listed permissions at the stated access level.
+4. Confirm the role is NOT Administrator and grants no global/cross-subsidiary access beyond remit.
+5. Enable 2FA enforcement if the role touches privileged permissions.
+6. Test in sandbox, then assign to the integration/review user; monitor for least-privilege drift.
+
+## Companion skill
+
+`netsuite-web-services-integration-skill` — NetSuite Web Services Integration Skill

package/skills/netsuite/netsuite-web-services-integration-skill/references/official-sources.md

@@ -0,0 +1,14 @@
+# Official Sources
+
+Confirmed Oracle/NetSuite official documentation URLs for REST, SOAP, OAuth 2.0, and TBA
+
+Verified 2026-06-09 against official Oracle/NetSuite documentation:
+
+- https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/article_2104046421.html
+- https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_157780312610.html
+- https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_158263562006.html
+- https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/article_1011040638.html
+- https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_4381113277.html
+- https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/chapter_4247329078.html
+- https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_N3445710.html
+- https://www.netsuite.com/portal/services/training/suite-training/netsuite-certification.shtml

package/skills/netsuite/netsuite-web-services-integration-skill/references/release-drift.md

@@ -0,0 +1,11 @@
+# Release Drift
+
+SOAP sunset timeline: 2026.1 REST+OAuth2 default, 2027.1 new SOAP blocked, 2028.2 all endpoints disabled
+
+NetSuite releases biannually. Content verified 2026-06-09.
+
+Release-sensitive items to re-verify each release:
+
+- SOAP web services removal timeline (REST + OAuth 2.0 recommended for new integrations from 2026.1; new SOAP integrations blocked at 2027.1).
+- Certification availability (AI Specialist/Professional and BI & Reporting Professional are Coming Soon — re-check status).
+- AI Connector / MCP permission names and role restrictions.

package/skills/netsuite/netsuite-web-services-integration-skill/references/safety-checklist.md

@@ -0,0 +1,17 @@
+# Safety Checklist
+
+Pre-review checklist: redaction verification, SOAP risk flags, auth posture checks
+
+- No credentials, tokens, or secrets present in inputs — refuse and instruct user to redact if found
+- SOAP usage flagged as migration risk with confirmed timeline cited (2026.1 / 2027.1 / 2028.2)
+- OAuth 2.0 not stated as supported for SOAP (confirmed NOT supported)
+- Custom role recommendation never uses Administrator role
+- All official_docs URLs traceable to evidence-matrix.md
+
+## Refusal triggers
+
+- Request includes credentials, tokens, secrets, client secrets, or API keys — refuse and instruct user to redact
+- Request asks agent to use the Administrator role or roles with full permissions
+- Request asks agent to fire live API calls or mutate a NetSuite account
+- User claims Web Services Developer Professional is a confirmed available exam without citing the official exam page — mark status UNVERIFIED per evidence-matrix row 1f
+- Request requires evaluating SOAP integration as a long-term strategy without flagging migration risk

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.