Enterprise AI Governance at Snowflake: Balancing Innovation and Risk

Enterprise AI Governance at Snowflake: Balancing Innovation and Risk

Speaker: Ragini Ramalingam, Director, Enterprise Security, Snowflake

Conference: [un]prompted 2026 — The AI Security Practitioner Conference

Date: March 3–4, 2026, San Francisco

Watch on YouTube: https://www.youtube.com/watch?v=RF4gR5uviv0

Reading time: ~10 minutes

TL;DR

Snowflake's enterprise security director Ragini Ramalingam detailed how the AI data cloud governs AI adoption internally — at a company where "engineering at speed" is in the DNA. Her framework centers on four principles: cross-functional governance structures that enable fast decisions, four-pathway visibility into AI usage, enterprise guardrails that constrain execution authority rather than block adoption, and continuous vendor engagement to close control gaps before they become incidents.

Introduction

Governing AI at a company like Snowflake presents a particular challenge: the company is itself the AI data cloud, and rapid engineering iteration is a core cultural value. As Snowflake CISO Brad Jones put it, governing AI there is "like laying tracks in front of a running train." Ragini Ramalingam's job was to lay those tracks without slowing the train.

The traditional enterprise security model assumed deterministic execution. Identities authenticate. Systems run predefined logic. Automation exists, but humans define it in advance. AI has shattered that model. Agents make runtime decisions, invoke actions across endpoints, cloud, and SaaS, read and write files, make system calls, and trigger outbound network egress — all from a single prompt. The control plane that used to exist cleanly at the endpoint, or at the network boundary, or in the cloud layer, no longer maps cleanly to anything. One prompt can span all of them.

"The traditional governance models don't work anymore," Ramalingam stated at [un]prompted 2026. "Governance has to become dynamic and evolve."

▶ Watch: Opening — deterministic to non-deterministic execution (00:00)

Why AI Governance Is Fundamentally Different

Ramalingam identified three structural reasons why AI governance cannot be handled with existing enterprise security frameworks:

1. AI tool adoption doesn't wait for review cycles. Engineers experiment. Product teams integrate. Solution engineers demo. Business teams increase productivity. All of this happens at a pace that outstrips any traditional approval process. Governance structures have to operate at the same velocity.

2. Feature velocity outpaces security maturity. AI vendors release features weekly, sometimes multiple times a week. Enterprise-grade security controls in those tools do not evolve at the same pace. New features often arrive without the control plane capabilities needed to restrict or audit them.

3. AI blurs the control plane boundary. A single prompt can trigger a system call at the endpoint, read or write files locally, make outbound network egress, and invoke external APIs. The clean separation between endpoint security, network security, cloud security, and SaaS security no longer holds. Any governance model that assumes those boundaries are intact will have blind spots.

The implication: "In order to govern AI, we need to evolve our governance model at the same velocity at which the technology is evolving."

▶ Watch: Why AI governance is fundamentally different (02:00)

The Governance Structure: Enterprise Steering Committee

Snowflake's response was to build a governance structure capable of making fast, risk-informed decisions rather than one optimized for thoroughness at the expense of speed.

They formed an enterprise AI steering committee with members drawn from security, IT, legal, privacy, AI/ML, data engineering, and procurement. The committee's mandate was cross-functional visibility into AI adoption and usage patterns across the enterprise, combined with the authority to identify risks, agree on mitigations (technical controls, process controls, or contractual protections), and escalate decisions to executive leadership when needed.

The critical design principle: enabling or disabling AI was explicitly framed as a business decision, not a security decision. "It's not a security trade-off, it's a business trade-off," Ramalingam said. By bringing executive leadership into the risk-informed decision-making process, Snowflake was able to get alignment on both the risk appetite and the cultural change required to govern a rapidly evolving technology. This shift — from reactive approvals to proactive risk ownership — is what allowed the governance model to keep pace.

▶ Watch: Governance structure — enterprise steering committee (04:01)

Four Pathways to Visibility

"You cannot govern what you cannot see." Ramalingam's second principle was that governance depends on visibility, and visibility requires deliberate investment across multiple channels.

Snowflake built visibility through four pathways:

1. Procurement process integration. Snowflake already had a mature procurement process. They built AI oversight into it — not just security risk reviews, but rationalization of overlapping tool capabilities. If two tools being considered serve the same function, eliminating the redundant one reduces both operational overhead and attack surface.

2. AI features in existing tools. AI doesn't only arrive as new products. Existing tools turn on AI features, and those features change the risk profile of already-approved tools. Snowflake required security reviews for enabling AI features in existing platforms — a gate that many organizations overlook because the tool itself is already approved.

3. Active discovery of AI artifacts. Snowflake's security data lake runs on their own platform. Using AI-powered analytics on endpoint telemetry, network data, cloud logs, and SaaS signals, their security team actively scans for AI artifacts: MCP components, models, agents, and their interaction patterns. This proactive discovery gave them visibility into AI usage that wouldn't have surfaced through procurement or policy channels alone.

4. Business unit security partners. Snowflake maintains security embedded in business units — partners who provide early signals on AI adoption before it becomes a formal request. This intelligence-gathering function was described as "critical" for getting ahead of adoption rather than reacting to it.

▶ Watch: Four pathways to AI visibility (06:01)

Enterprise Guardrails: Constrain Execution, Don't Block Adoption

With the governance structure and visibility in place, Snowflake moved to a framework of enterprise guardrails — controls designed to constrain what AI can do, rather than whether AI can be used.

Endpoint, network, and DLP controls aligned to AI usage patterns. The goal was to allow approved use cases and approved tools while maintaining an acceptable risk posture. When Snowflake identified unsanctioned AI tools already in use across the enterprise, they made a conscious decision: rather than blocking them outright, they evaluated whether to procure and manage them officially, or whether the risk profile required steering users toward approved alternatives.

Isolated experimentation environments. AI experimentation is part of Snowflake's engineering culture. The security team's operating principle for experimentation: provide isolated environments with test tenants and synthetic data. Where production-adjacent environments were unavoidable for a valid use case, they implemented what Ramalingam called a responsible AI experimentation framework — setting clear accountability for experimentation teams, adding additional review processes, and layering preventive and detective controls.

Feature-based risk assessment for gen AI tools. Snowflake recognized that enabling a gen AI tool doesn't mean enabling all its features. They evaluated each feature set against available enterprise control plane capabilities: Could they manage allow/deny lists for MCP servers? Could they restrict web search to specific domains? Could they control which integrations were permitted? Features with adequate controls were enabled. Features without sufficient controls were gated pending vendor enhancements. This approach triggered active conversations with vendors about feature requests, and Ramalingam noted that they have seen significant vendor responsiveness to those requests in recent months.

▶ Watch: Enterprise guardrails and responsible experimentation (08:01)

The Coding Agent Problem

Coding agents represent a specific escalation in the enterprise risk model. Ramalingam dedicated significant attention to them because they epitomize the shift from predefined to real-time execution.

These tools don't just write code. They execute system-level calls, make file system reads and writes, integrate with external APIs, and — critically — often include embedded browser components that can bypass standard enterprise controls. The threat model shifts substantially: prompt injection can deliver malicious instructions through source code or repository content; autonomous code execution can propagate through the development environment; and the browser pathways create data exfiltration vectors that don't pass through normal network inspection.

The assessment methodology Snowflake developed for coding agents mirrors what they did for gen AI tools, but with additional attention to execution surfaces (command line vs. desktop), autonomous vs. manual operation modes, and the specific capabilities of each agent's enterprise control plane. Snowflake found that most coding agent control planes do not yet offer schema-based feature enablement — the ability to selectively deploy specific capabilities to specific user groups. That gap means many controls have to be implemented using existing EDR and IT tooling rather than the agent's native settings.

For automated browser pathways, Snowflake restricted them to internal domains only. For manual browser pathways, they applied the same EDR constraints as the rest of the enterprise environment.

▶ Watch: Coding agents — threat model and control approach (12:01)

Lessons Learned: What Enables AI to Scale Responsibly

Ramalingam closed with four principles derived from Snowflake's experience:

1. Cross-functional alignment is not optional. Security cannot govern AI alone. The steering committee model, which brings security, legal, privacy, engineering, and procurement into a shared decision-making structure, enables faster decisions and broader risk ownership.

1. Executive sponsorship with data. Governance decisions need to be backed by visibility data — usage patterns, adoption trends, risk signals. Leadership needs to see the data, not just receive recommendations.

1. Shared ownership scales better than central control. A governance model that requires security to approve every AI decision doesn't scale at Snowflake's pace. Distributing risk ownership to teams, with security setting the guardrails, is what makes the model sustainable.

1. Constrain execution authority, not AI itself. "You cannot stop innovation. You cannot stop AI adoption in the enterprise, because if you did, it'll go around you." The security team's job is to constrain what AI can do — not to decide whether AI happens.

▶ Watch: Lessons learned and scaling AI responsibly (18:02)

Notable Quotes

"Governing AI at a company like Snowflake — we are the AI data cloud — is like laying tracks in front of a running train."

— Brad Jones, Snowflake CISO (quoted by Ragini Ramalingam), 00:00

"Enabling or disabling AI was not a security decision. It is actually a business decision."

— Ragini Ramalingam, 06:01

"You cannot govern what you cannot see."

— Ragini Ramalingam, 06:01

"You cannot stop AI adoption in the enterprise, because if you did, it'll go around you. Focus on constraining the execution authority of the AI, not restraining AI completely."

— Ragini Ramalingam, 20:02

Key Takeaways

• Governance structures must enable fast decisions. A steering committee with cross-functional membership and executive sponsorship can make risk-informed calls at the pace AI adoption requires; a traditional security review process cannot.
• Build four-way visibility. Procurement reviews, AI feature reviews in existing tools, active discovery via telemetry, and business unit security partners together surface AI adoption that no single channel would catch alone.
• Evaluate gen AI tools at the feature level, not just the product level. Enabling a tool doesn't mean enabling all its features. Gate high-risk features until adequate controls are available; use that gap as leverage to push vendors for enhancements.
• Coding agents require a distinct threat model. Embedded browsers, autonomous code execution, and file system access make coding agents categorically different from conversational AI tools. Assess execution surfaces specifically and constrain browser pathways explicitly.
• Shared ownership scales; central control doesn't. Distribute risk ownership to teams with clear accountability, set enterprise guardrails, and reserve central governance for high-stakes decisions.

Slides Reference

Slides are available from the conference: 2026-04-04-D1-S2-10-05-Enterprise-AI-Governance-at-Snowflake-.pdf. A transcript PDF is also available: 2026-04-04-Day1-Stage2-EnterpriseAIGovernanceAtSnowflake-Rama.pdf. The slides cover the enterprise steering committee structure, the four visibility pathways, the feature-based risk assessment framework for gen AI tools, the coding agent threat model, and the responsible AI experimentation framework.