From Optimization to Protection: Adding a Security and Governance Agent to Your Snowflake Multi-Agent Team (Part 3)

A developer built a Security and Governance Agent as the third specialist in a multi-agent team for Snowflake administration, adding the ability to answer security-related questions. The agent uses specialized views over Snowflake's account usage data and Cortex Analyst tools to detect login anomalies, excessive privileges, unauthorized access attempts, and user-role audits. The orchestrator routes security questions to this agent, enabling a unified response for operations, cost optimization, and security governance.

In Part 1 https://dev.to/swaroop krishna e2f4b83b2/ask-your-snowflake-account-anything-build-an-ai-admin-agent-with-cortex-github-copilot-1mk6 , we built an Admin Agent for usage and cost visibility. In Part 2 https://dev.to/swaroop krishna e2f4b83b2/from-one-agent-to-many-building-a-multi-agent-team-for-snowflake-administration-part-2-379d , we added a Cost Optimizer Agent and an Orchestrator that routes questions to specialists. Now we close the loop with the third specialist: a Security and Governance Agent . This turns your assistant from "what happened" and "what to optimize" into a full team that also answers "what is risky right now". By the end of this post, you will have: The first two agents are strong for operations and spend, but security requires a different lens: Could one large agent do everything? Sometimes. But specialized agents are easier to maintain, safer to evolve, and easier to test. User Question natural language | Orchestrator Agent / | \ Admin Cost Security Agent Optimizer Governance Agent \ | / Unified Response Create security-focused views over SNOWFLAKE.ACCOUNT USAGE , including: Implementation file: sql/08 create security governance views.sql Map these views into natural language dimensions, facts, and metrics so Cortex Analyst can reason over them. Examples: SV LOGIN ANOMALIES SV EXCESSIVE PRIVILEGES SV UNAUTHORIZED ACCESS ATTEMPTS SV USER ROLE AUDIT Implementation file: sql/09 create security governance semantic views.sql Define a dedicated agent with explicit analyst tools for each security domain: CREATE OR REPLACE AGENT <APP DB .<APP SCHEMA .<SECURITY AGENT NAME COMMENT = 'Security and Governance agent for access control and compliance' FROM SPECIFICATION $$ instructions: response: "You are a Security and Governance assistant..." orchestration: "Route role hierarchy questions to RoleHierarchyAnalyst; \ privilege grants to PrivilegeGrantAnalyst; \ failed logins to FailedLoginAnalyst; \ login anomalies to LoginAnomalyDetector..." tools: - tool spec: { type: "cortex analyst text to sql", name: "RoleHierarchyAnalyst" } - tool spec: { type: "cortex analyst text to sql", name: "PrivilegeGrantAnalyst" } - tool spec: { type: "cortex analyst text to sql", name: "FailedLoginAnalyst" } - tool spec: { type: "cortex analyst text to sql", name: "LoginAnomalyDetector" } - tool spec: { type: "cortex analyst text to sql", name: "ExcessivePrivilegeAnalyst" } - tool spec: { type: "cortex analyst text to sql", name: "UnauthorizedAccessAnalyst" } - tool spec: { type: "cortex analyst text to sql", name: "UserAuditAnalyst" } $$; Implementation file: sql/11 create security governance agent.sql Your orchestrator now includes SecurityAgent as a first-class route target. -- in sql/12 create orchestrator agent.sql -- Questions about security, roles, privileges, failed logins, unauthorized access - SecurityAgent It can also fan out to multiple agents for blended questions. Question: "Are there suspicious login failures in the last 7 days?" What happens: SV LOGIN ANOMALIES Example response: Login Anomaly Summary Last 7 Days Critical: 2 users with = 10 failed attempts/hour High: 5 users with 5-9 failed attempts/hour Pattern: Multiple failed attempts from distinct IPs for USER X Recommendation: - Lock and verify impacted accounts - Enforce MFA re-registration for affected users - Review network policy and source IP ranges Question: "Which users have ACCOUNTADMIN or SECURITYADMIN but low recent usage?" What happens: SV EXCESSIVE PRIVILEGES Example response: Excessive Privilege Findings Users flagged: 4 Critical: 2 users with no privileged role usage in 60+ days High: 2 users with < 5 privileged queries in 90 days Recommendation: - Revoke unused privileged grants - Replace standing privilege with just-in-time elevation - Document business justification for remaining elevated users Question: "Why are costs up and is there any security risk around this?" What happens: Example response: Integrated Account Assessment Operations Admin Agent - Compute credits up 18% month-over-month - Growth concentrated in two ETL warehouses Optimization Cost Optimizer Agent - Idle percentage 60% on one ETL warehouse - Suggested AUTO SUSPEND change could reduce waste materially Security Security Agent - One privileged user inactive but still assigned elevated role - Increased failed login attempts from multiple IPs for two accounts Priority Actions 1 Apply warehouse auto-suspend tuning 2 Review elevated role assignments and revoke unused grants 3 Investigate failed-login anomalies and tighten network controls If you already deployed Parts 1 and 2: 1 Security views sql/08 create security governance views.sql 2 Security semantic layer sql/09 create security governance semantic views.sql 3 Security agent sql/11 create security governance agent.sql 4 Orchestrator includes SecurityAgent routing sql/12 create orchestrator agent.sql Direct test: SELECT SNOWFLAKE.CORTEX.DATA AGENT RUN '<APP DB .<APP SCHEMA .<SECURITY AGENT NAME ', '{"messages": {"role":"user","content": {"type":"text","text":"Show failed login anomalies by severity"} } }' ; Orchestrated test: SELECT SNOWFLAKE.CORTEX.DATA AGENT RUN '<APP DB .<APP SCHEMA .<ORCHESTRATOR AGENT NAME ', '{"messages": {"role":"user","content": {"type":"text","text":"Analyze account risk: costs, idle warehouses, and failed logins"} } }' ; SNOWFLAKE.ACCOUNT USAGE views have latency. For near-real-time incident response, combine this with event-driven telemetry. <APP DB .<APP SCHEMA <EXEC WAREHOUSE <ADMIN ROLE , <DEVELOPER ROLE After Part 3, you have a complete multi-agent Snowflake administration team: This is where multi-agent design pays off: each specialist stays focused, and users still ask one simple question. sql/08 create security governance views.sql sql/09 create security governance semantic views.sql sql/11 create security governance agent.sql sql/12 create orchestrator agent.sql skills/security-governance/SKILL.md Complete implementation: Part 1 gave us visibility. Part 2 gave us optimization. Part 3 gives us governance and risk control. Same architecture pattern, broader coverage: Views - Semantic Views - Specialist Agent - Orchestrator Next directions: Questions or feedback? Drop a comment below. Part 1: Ask Your Snowflake Account Anything - Build an AI Admin Agent https://dev.to/swaroop krishna e2f4b83b2/ask-your-snowflake-account-anything-build-an-ai-admin-agent-with-cortex-github-copilot-1mk6 Part 2: From One Agent to Many - Building a Multi-Agent Team https://dev.to/swaroop krishna e2f4b83b2/from-one-agent-to-many-building-a-multi-agent-team-for-snowflake-administration-part-2-379d Part 3: Security and Governance Agent this post