![Ragini Ramalingam presenting talk - Ragini Ramalingam - Enterprise AI Governance at Snowflake | [un]prompted 2026 at unprompted 2026](https://thecyberarchive.com/assets/teasers/enterprise-ai-governance-at-scale-snowflakes-model-ragini-ramalingam.webp)
Enterprise AI governance is broken by design — the moment your security team finishes reviewing a tool, the vendor has shipped three new features that bypass every control you just ratified. At Snowflake, where the AI data cloud is core to the business, this tension is existential: governing AI means laying tracks in front of a running train.
This post unpacks how Snowflake’s enterprise security team built a governance model that scales at the velocity of AI adoption — covering their cross-functional steering structure, four visibility pathways, feature-based risk assessment for GenAI tools, and hard-won controls for coding agents that autonomously execute system calls and browser actions across the enterprise.
Key Takeaways
- You'll learn how to build a dynamic, cross-functional AI governance model that enables innovation at speed without sacrificing security — using a steering committee structure that makes risk-informed decisions aligned with executive appetite.
- You'll be able to identify the four visibility pathways (procurement, feature gating, active discovery, and business unit partnerships) that give security teams the data they need to govern AI they cannot directly control.
- Apply a feature-based risk assessment approach to GenAI and coding agents to selectively enable low-risk capabilities while constraining high-autonomy modes — without blocking developer productivity.
Why Traditional Enterprise Governance Fails for AI
AI security exposes a fundamental mismatch: the security frameworks built over decades were designed for a world that no longer exists. Understanding why traditional governance breaks is the prerequisite for building something that actually works.
The Deterministic Assumption Is Dead
For decades, enterprise security operated on a single founding premise: execution is predefined. Identities authenticate against known systems. Workflows execute logic that humans wrote. Automation runs exactly what engineers specified — no more, no less. Control planes were cleanly partitioned: endpoint security owned the endpoint, network security owned the perimeter, cloud security owned cloud infrastructure, SaaS security owned SaaS platforms.
Generative AI invalidates every one of these assumptions.
Today’s AI systems make decisions at runtime. They invoke actions autonomously — from endpoint to cloud to SaaS — without a human specifying each step in advance. A single prompt can:
- Trigger system-level calls on an endpoint
- Read or write files on the local file system
- Make outbound network egress
- Invoke APIs reaching out to SaaS platforms
This is not an incremental change to the threat model. It is a structural shift from deterministic action to context-aware, real-time execution that operates outside direct human control. The execution boundary has expanded to span every domain simultaneously, and it does so dynamically based on inputs that security teams cannot fully predict in advance.
Feature Velocity Outpaces Every Review Cycle
Legacy governance assumed a manageable pace of change. Security teams reviewed tools before deployment, assessed risk on a quarterly or annual cadence, and updated policies when major changes arrived. That model depended on vendors shipping features slowly enough that reviews remained meaningful.
AI vendors now ship features weekly — sometimes multiple times per week.
This creates three compounding failures in traditional governance:
- Adoption doesn’t wait for review. Engineers experiment. Product teams integrate. Solution engineers demo. Business teams chase productivity gains. By the time a formal review cycle concludes, the tool is already in use across multiple teams.
- Approvals go stale immediately. A security review of a GenAI tool conducted in January may be rendered incomplete by February’s feature release, which adds a new integration surface or autonomous capability that wasn’t in scope.
- Static risk assessments don’t hold. When the execution model shifts from predetermined to non-deterministic, risk is no longer a fixed property of a tool — it changes with every new capability the vendor enables.
The result: governance teams are perpetually behind, approving yesterday’s version of a tool that has already evolved into something materially different.
The Control Plane Boundary Collapse
Traditional security architecture maintained separation between control planes. Endpoint controls governed what happened on devices. Network controls governed traffic. Cloud controls governed infrastructure. SaaS controls governed third-party application data. Each domain had its own team, tooling, and policy framework.
AI collapses these boundaries by design.
Coding agent security illustrates this most sharply. They don’t just generate code in an isolated sandbox — they execute system-level calls, perform file reads and writes, invoke external APIs, and operate embedded browser components that bypass standard network controls. A single coding agent session can touch the endpoint, traverse the network, interact with cloud services, and exfiltrate data through SaaS integrations — all within a single autonomous workflow.
No existing control plane, by itself, can govern this. The risk is no longer static and domain-specific; it is dynamic, cross-boundary, and changes based on runtime context.
Why Governance Must Become Dynamic
The conclusion is unavoidable: traditional governance models don’t work for AI, and the gap is structural, not operational. It cannot be fixed by adding more reviewers, running more frequent assessments, or tightening existing policies. The underlying architecture of legacy governance — periodic reviews, static risk classifications, domain-specific control planes — was built for a world of deterministic execution. AI operates in a fundamentally different world.
As Snowflake’s CISO Brad Jones framed the challenge: governing AI at a company like Snowflake is like “laying tracks in front of a running train.” The train does not stop while you build the infrastructure. Governance must evolve at the same velocity as the technology — or it becomes irrelevant.
This requires a new model: one built for continuous risk visibility, cross-boundary control, and decision-making that operates at the speed of AI adoption rather than the speed of traditional security processes.
Actionable Takeaways
- Audit your current governance review cadence against AI vendor release frequency. If your review cycles run quarterly or annually and your AI vendors ship features weekly, you have a structural gap — document it and use it to justify building dynamic, continuous review processes instead of periodic ones.
- Map every AI tool in use against your existing control plane architecture (endpoint, network, cloud, SaaS). Identify which tools cross domain boundaries during normal operation — these represent governance blind spots where no single existing control plane provides complete visibility or enforcement.
- Reframe AI governance as a business risk decision, not a security veto. When AI adoption is already happening at the team level, the question is not whether to allow it but how to constrain what it is permitted to execute. Build that framing into your executive communication before a governance failure forces the conversation.
Common Pitfalls
- Treating AI tool reviews as one-time approvals. A vendor passing a security review at time of procurement is not a durable security posture — new features shipped in subsequent weeks can introduce capabilities (autonomous code execution, new integration surfaces, embedded browser components) that were never in scope for the original review. Reviews must be feature-aware and continuous, not one-time gates.
- Attempting to govern AI by blocking adoption entirely. As Snowflake's experience demonstrates, AI adoption at the business unit level does not wait for security approval — it happens regardless. Governance programs that operate primarily by blocking tools create shadow adoption that is harder to detect and impossible to constrain. The viable path is enabling approved tools with guardrails, not attempting to stop adoption.
Building a Dynamic AI Governance Structure
The Structural Problem: Why Static Committees Don’t Work for AI Governance
Enterprise AI governance cannot rely on the same approval-chain models that worked for traditional software procurement. When AI tool adoption begins with engineers experimenting, product teams integrating, solution engineers showcasing, and business units chasing productivity gains — all simultaneously and without waiting for review cycles — a governance structure that moves at procurement speed is structurally obsolete before it’s ratified.
Snowflake’s answer was to rebuild governance around one central insight: the pace of AI risk decisions must match the pace of AI adoption itself. That required a new institutional structure, not just updated policies.
The Enterprise Steering Committee: Composition and Purpose
Snowflake formed a cross-functional enterprise AI steering committee with representation from:
- Security — to identify and model AI-specific risks
- IT — to manage infrastructure and tooling implications
- Legal — to assess liability, terms of service, and compliance exposure
- Privacy — to evaluate data handling and residency concerns
- AI/ML — to assess model behavior, capability boundaries, and technical risk
- Data Engineering — to understand data flow and pipeline exposure
- Procurement — to gate vendor relationships and contractual protections
This composition was deliberate. Each function brought a distinct lens on AI adoption patterns and usage across the enterprise. Together, they could see what no single team could: the full picture of how AI was spreading through the organization, where risks were materializing, and which controls were feasible.
The committee’s operating model was to surface risks from observed adoption patterns, identify mitigations — whether technical controls, process controls, or contractual protections — and escalate decisions to executive leadership in engineering, product management, sales, customer experience, and IT.
Proactive Risk Ownership Over Reactive Approvals
The critical shift this structure enabled was from reactive approvals to proactive risk ownership. In a reactive model, security teams respond after tools are already in use — they’re always behind. In the proactive model, the steering committee is continuously monitoring adoption signals and surfacing risk before it compounds.
This distinction matters operationally. When risks are identified early and framed with data, they can be escalated to executive leadership with enough context to make risk-informed decisions aligned with the organization’s risk appetite. At Snowflake, that appetite is heavily weighted toward engineering velocity — “engineering at speed is in our DNA.” That reality had to be built into the governance model, not treated as an obstacle to it.
Ramalingam made an important framing point that security engineers should internalize: enabling or disabling AI is not a security decision — it is a business decision. Security’s role is to surface the risk clearly and ensure leadership understands the trade-off. The decision itself belongs to the business.
Executive Alignment as a Governance Mechanism
The steering committee’s escalation path to executive leadership served two distinct functions. First, it ensured that risk trade-offs were made by people with the authority and context to make them — not delegated down to security teams who may block innovation without understanding the business cost, or to engineering teams who may accept risk without understanding the security implications.
Second, executive involvement created the cultural conditions for change. When leadership visibly owns AI risk decisions, it signals organization-wide that AI governance is a shared business responsibility — not a security tax. This top-down alignment is what enabled Snowflake to effect cultural change around responsible AI adoption, rather than fighting a constant rearguard action against shadow AI usage.
Ramalingam summarized this as: “shared ownership scales better than central control.” A security team trying to unilaterally approve or block AI tools will always be overwhelmed. A cross-functional committee with executive sponsorship and shared accountability can sustain governance at scale.
Dynamic Governance: Keeping Pace with Feature Velocity
One structural requirement Snowflake built into their model was operational cadence. AI risk is not static — it evolves as vendors ship features, as usage patterns shift, and as new tools emerge. Governance that runs on quarterly review cycles cannot keep up with vendors shipping multiple times per week.
The steering committee model enabled more frequent decision cycles — weekly or even daily alignment on newly observed risks, anomalies, or urgent threats. When something needs to be shut down, the cross-functional structure allows quick escalation and alignment without waiting for a formal approval chain to cycle.
This cadence is not optional. As Ramalingam noted in response to a question about autonomous execution risk: “You need to be having these conversations on a weekly or sometimes on a daily basis about what you see across the enterprise and make those decisions. If you need to shut something down, you need to be able to get quick alignment and shut it down.”
The structural lesson is that governance must be a continuous operational process, not a periodic compliance checkpoint.
Actionable Takeaways
- Constitute a cross-functional AI steering committee that includes security, legal, privacy, IT, AI/ML, data engineering, and procurement. Each function provides a distinct view of AI adoption risk that security alone cannot see — the committee's combined visibility is what makes fast, informed decisions possible.
- Reframe AI governance decisions as business decisions, not security decisions. Security's role is to surface risk with data and clarity; executive leadership should own the trade-off between risk and innovation velocity. This framing is what generates the executive sponsorship that makes governance sustainable and culturally effective.
- Shift governance cadence from quarterly reviews to weekly or daily operational conversations. AI risk is continuous and dynamic — build a committee structure that can escalate and resolve issues at the pace at which new tools, features, and usage patterns emerge.
Common Pitfalls
- Treating AI governance as a security-owned approval gate rather than a cross-functional business process. Security teams that try to centrally control AI adoption without executive sponsorship and shared ownership will be overwhelmed by the velocity of adoption and will either create a bottleneck that drives shadow AI usage or fail to enforce controls at all.
- Running governance on procurement-cycle timelines when AI vendors are shipping features weekly. A governance model that cannot respond faster than its review cadence will always be governing yesterday's risk landscape. Build in operational mechanisms for rapid escalation and decision-making, not just formal approval workflows.
Achieving Visibility Into Enterprise AI Usage
The guiding principle behind Snowflake’s enterprise AI governance model is as direct as it is foundational: you cannot govern what you cannot see. Before any technical control can be enforced, before any risk decision can be made, security teams must first achieve comprehensive visibility into how AI is actually being adopted and used across the organization. Snowflake identified four distinct pathways to build that visibility — each targeting a different channel through which AI enters the enterprise.
Pathway 1: Procurement Oversight
The first visibility channel is the procurement process. Snowflake already had a mature vendor review workflow, and the team built AI-specific oversight directly into it. Critically, this wasn’t just a standard security risk review — the team also evaluated whether proposed tools had redundant capabilities relative to tools already in the approved stack.
This rationalization step had compounding benefits. By eliminating tools with overlapping functionality, Snowflake reduced operational overhead and, more importantly, eliminated unnecessary attack surfaces. Every approved AI tool that provides unique value is a calculated risk. Every approved tool that duplicates capabilities is a risk that was never worth taking.
The procurement pathway answers the question: What new AI products are entering the enterprise?
Pathway 2: Gating AI Features in Existing Tools
The second visibility channel addresses a less obvious but equally significant source of AI exposure: AI features being activated within tools the enterprise already owns. AI doesn’t arrive only as a new product. It also arrives as a toggle inside a SaaS platform, a new model capability added to an existing subscription, or a beta feature enabled by default after a vendor update.
Snowflake addressed this by requiring teams to go through a security review before enabling AI features in existing tools and platforms. This gate ensures that the security team knows when the AI surface area of an already-approved tool is expanding — and can assess the new risk before it’s live in production.
This pathway answers the question: Where is AI activation happening inside our existing toolset?
Pathway 3: Active Discovery of AI Artifacts
The third pathway is the most technically intensive: active discovery of AI artifacts and interactions across the enterprise. Rather than waiting for teams to self-report AI usage, Snowflake proactively scanned for it.
Snowflake’s security lake runs on its own platform, and the team leveraged the platform’s native AI capabilities to derive insights from telemetry collected across four surfaces:
- Endpoint data — local AI tool installations, agent runtimes, model files
- Network telemetry — outbound connections to AI APIs, model hosting services, and third-party integrations
- Cloud environments — AI infrastructure provisioned in cloud accounts
- SaaS platforms — AI feature usage signals from connected SaaS applications
From this telemetry, the team was able to identify specific AI artifacts — including MCP (Model Context Protocol) server components, models, and autonomous agents — and map their interactions across the enterprise. This is precisely the kind of discovery that procurement-only approaches miss: shadow AI deployments, individually installed coding agents, developer experiments using personal API keys, and AI integrations built by product teams without formal review.
This pathway answers the question: What AI is actually running in our environment right now?
Active Discovery of AI Artifacts Using Snowflake’s Own Security Lake
Proof of Concept
-
Establish the Security Lake as the unified telemetry sink: Snowflake routes endpoint, network, cloud, and SaaS log telemetry into their own Snowflake-hosted Security Lake. Because the security data store runs on the same AI data cloud platform that underpins the business, the team can apply Snowflake’s native AI and analytics capabilities directly to the raw telemetry — no data movement or secondary SIEM required for this discovery workflow.
- Define the AI artifact inventory target: The team scoped discovery to four artifact classes that represent the AI attack surface in an enterprise environment:
- MCP (Model Context Protocol) components — server-side integration points that extend coding agent capabilities with external tool access
- AI models — local or API-connected models running on or invoked from enterprise endpoints
- Agents — autonomous execution processes (coding agents, browser agents) operating on enterprise systems
- Agent interactions — outbound API calls, file system reads/writes, and network egress events attributable to AI agent processes
-
Query endpoint telemetry for AI process signatures: Using the AI query capabilities on the Security Lake, the team interrogated endpoint telemetry for process execution events consistent with known coding agent binaries, MCP server processes, and embedded browser components (which ship as part of most coding agents and represent a high-risk execution surface for data exfiltration and prompt injection).
-
Correlate network telemetry for outbound AI traffic: Network egress data in the Security Lake was queried for connections to AI vendor API endpoints, model hosting infrastructure, and MCP server URLs. This cross-correlation between endpoint process events and outbound network calls allowed the team to confirm which AI tools were actively making API calls — not just installed — and to identify unapproved tools generating outbound traffic outside the approved tool list.
-
Extend discovery to cloud and SaaS layers: Cloud and SaaS telemetry (IAM events, API gateway logs, SaaS audit logs) was included in the query scope to catch AI feature activations in existing tools — for example, a team enabling an AI assistant feature inside an approved SaaS platform without going through the security review gate.
-
Surface findings to the steering committee: Discovery outputs — lists of observed AI artifacts, active agent processes, unapproved tools, and anomalous egress patterns — were fed into the cross-functional enterprise steering committee on a recurring basis (weekly or more frequently as warranted). This closed the loop between technical discovery and risk-informed governance decisions.
- Use discovery outputs to drive procurement and control actions: When unapproved tools were identified via active discovery, the team either steered users toward approved alternatives or made a conscious decision to procure and formally manage the tool — applying the full feature-based risk assessment before enterprise enablement. When MCP servers or high-autonomy agent modes were discovered running outside the approved configuration, the findings were used to initiate vendor feature requests for allow/deny list controls at the enterprise tenant level.
Pathway 4: Business Unit Partnerships
The fourth pathway is organizational, not technical: ongoing partnerships with security-aligned contacts embedded in business units. Snowflake maintained relationships with security partners across business units to surface early intelligence on AI adoption before it reached formal review cycles.
This matters because the fastest AI deployments don’t start in procurement — they start in Slack threads, hackathons, and engineering spike sprints. By the time a tool shows up in a vendor review queue, teams may have been using it for weeks. Embedded partnerships give security teams advance signal on what’s coming, enabling proactive risk assessment rather than reactive containment.
This pathway answers the question: What AI adoption is being planned or piloted that we haven’t seen yet?
From Visibility to Action
With these four pathways in place, Snowflake’s security team had the data they needed to act. The combination of procurement intelligence, feature-gate enforcement, active artifact discovery, and business unit partnerships gave them a continuously updated picture of AI usage across the enterprise — one that fed directly into the steering committee’s risk decisions.
The visibility infrastructure also enabled a shift from policy-based blocking to evidence-based governance: rather than banning categories of tools, the team could identify which specific tools were already broadly adopted, rationalize the approved stack around them, and guide users toward managed alternatives where risks were too high. That shift — from gatekeeping to evidence-informed enabling — is what made the governance model culturally sustainable at a company where engineering velocity is foundational to the business.
Actionable Takeaways
- Embed AI oversight into your existing procurement process and add a redundant-capability rationalization step — every tool that duplicates functionality already covered by an approved alternative is an unnecessary attack surface that can be eliminated without impacting business capability.
- Build active discovery into your security operations by leveraging endpoint, network, cloud, and SaaS telemetry to surface AI artifacts (models, agents, MCP components) that were never formally approved — shadow AI deployments will not self-report, and procurement gates alone will not catch them.
- Establish and maintain security liaison relationships within business units so that AI adoption plans surface before they reach formal review, enabling proactive risk assessment rather than reactive containment after the deployment is already live.
Common Pitfalls
- Relying solely on procurement as a visibility mechanism creates a significant blind spot: AI features activated within already-approved tools, developer-installed agents, and shadow deployments all bypass the procurement channel entirely. A procurement-only approach gives a false sense of comprehensive coverage.
- Treating AI visibility as a one-time audit rather than a continuous operational capability means the picture goes stale almost immediately — AI vendors ship features weekly, and the enterprise AI surface changes faster than any point-in-time assessment can track. Visibility must be dynamic and ongoing, not periodic.
Feature-Based Risk Assessment for GenAI Tools and Coding Agents
Why Feature-Level Granularity Is the Only Viable Approach
The core problem with GenAI tool enterprise controls is a structural mismatch: vendors ship features weekly, sometimes multiple times a week, but the enterprise-grade control planes in those same tools evolve far more slowly. Broad enablement or broad blocking of an entire tool is a false choice — it either exposes the enterprise to unacceptable risk or kills adoption. The only workable posture is feature-based risk assessment: evaluate each capability individually, enable what the existing control surface can govern, and gate what it cannot.
Snowflake’s security team applied this model consistently across both standalone GenAI platforms and the newer class of coding agents that represent a qualitatively different threat surface.
Applying Feature-Based Risk Assessment to GenAI Platforms
For each GenAI tool feature, the assessment centers on a single question: does the enterprise control plane provide sufficient mechanisms to limit the risk from that capability?
Key control surface questions include:
- Allow/deny list management: Can you restrict which MCP servers, external tools, or web fetch/search integrations the tool can access? Without this, a prompt can reach arbitrary external destinations.
- Data exfiltration controls: Does the platform expose controls that prevent sensitive data from leaving the enterprise boundary through integrations?
- Integration surface limits: Can you constrain which APIs and downstream systems the tool is permitted to invoke?
The output of this assessment is a tiered enablement decision:
- Enable now: Features where sufficient controls already exist in the enterprise control plane and the residual risk is acceptable.
- Gate pending controls: Features where the control surface is insufficient — these are not enabled until either the vendor ships the required controls or compensating controls are implemented at the network or endpoint layer.
This gating process directly initiated vendor engagement. Snowflake used the list of gated features as a structured set of feature requests to their AI tool vendors, pushing for the enterprise-grade controls needed to unlock those capabilities. This is the correct loop: assessment surfaces gaps, gaps become vendor roadmap input, vendor ships controls, feature gets unlocked.
Coding Agents: A Fundamentally Different Threat Model
Coding agent security risks represent a step-change in enterprise attack surface, not just an incremental extension of the GenAI tool problem. The distinction is execution scope:
- Traditional GenAI tools generate text output that a human then acts on.
- Coding agents execute autonomously — they make system-level calls, read and write files on the endpoint, invoke APIs, and operate embedded browser components, all without human confirmation at each step.
This shifts the threat model in several concrete ways:
- Autonomous code execution risk: The agent can run arbitrary system calls in the context of the developer’s session. This amplifies remote code execution risk — any prompt injection or malicious instruction that reaches the agent can result in direct system compromise.
- Embedded browser components: Most coding agents include browser automation that bypasses standard web proxy and DLP controls. These browser pathways create data exfiltration channels and prompt injection surfaces that existing enterprise controls were not designed to intercept.
- Expanded execution boundary: A single compromised prompt can touch the endpoint, the network layer, cloud APIs, and SaaS platforms simultaneously — the same boundary-blurring problem as GenAI tools, but now with direct execution authority.
Structured Assessment for Agentic Tools
Snowflake applied the same feature-based risk assessment methodology to agentic AI tools, with assessment coverage across all execution surfaces:
- Command-line execution surface: What system calls can the agent make? What is the scope of its file system access?
- Desktop execution surface: What local resources — credentials stores, config files, clipboard — can the agent interact with?
- Browser execution surface (automated): What domains can automated browser sessions reach? Can these be constrained to internal domains only?
- Browser execution surface (manual): Do manual browser pathways within the agent respect the same domain allow-lists enforced elsewhere in the enterprise?
- API and integration surface: Which external APIs can the agent invoke? Is there an allow-list mechanism, or is the scope unrestricted?
A critical constraint throughout this assessment: developer productivity cannot be the casualty. At an engineering-first company like Snowflake, any control that materially degrades the developer experience will be circumvented. Every mitigation had to be evaluated against the risk appetite set by executive leadership, with productivity impact as a first-class constraint — not an afterthought.
Hardening When Native Controls Are Insufficient
The enterprise control planes in most coding agents today do not provide the immutable, schema-based configuration management that security teams need. Snowflake’s response was to layer compensating controls from their existing IT and security toolset:
- Endpoint hardening for immutable configuration: EDR[1] and endpoint management tooling was used to enforce coding agent configuration at the OS level — preventing users from modifying security-relevant settings that the coding agent’s own control plane could not lock down.
- Automated browser pathway restriction: Automated browser sessions were restricted to internal domains only, enforced at the network layer rather than relying on the agent’s own controls.
- Manual browser pathway alignment: EDR tooling was used to ensure that manual browser execution within coding agents matched the domain restrictions already in place enterprise-wide.
- Selective feature enablement by user risk profile: Where high-autonomy modes (e.g., fully automated multi-step execution) could not be safely deployed broadly, Snowflake scoped enablement to specific user groups based on risk profile. This is a partial mitigation — the ideal is schema-based role controls in the vendor’s control plane, which Snowflake formally requested.
Coding Agent Browser Pathway Restriction: Constraining Automated and Manual Execution
Proof of Concept
-
Identify the dual browser pathway threat surface: Coding agents ship with embedded browser components capable of executing web requests autonomously (automated pathway) and exposing a browser interface to the developer (manual pathway). Both pathways can be exploited for data exfiltration or prompt injection, and neither is adequately controlled by the coding agent’s own enterprise control plane at this stage of product maturity.
-
Assess native enterprise control plane capabilities: Before deploying the coding agent, evaluate what controls the vendor’s enterprise control plane actually provides. In Snowflake’s case, the coding agent vendor did not offer robust mechanisms for enforcing immutable browser configuration at the endpoint — meaning the security team could not rely on in-product controls to enforce domain restrictions or session boundaries.
-
Constrain the automated browser pathway to internal domains: For the automated execution pathway (where the coding agent itself initiates browser actions), restrict outbound web access to internal domains only. This prevents the agent from autonomously reaching external services, public APIs, or attacker-controlled infrastructure during agentic task execution. This constraint is implemented using existing enterprise security and IT tooling rather than native coding agent settings.
-
Apply EDR tooling to constrain the manual browser pathway: For the manual browser pathway (where a developer interacts with the browser interface surfaced by the coding agent), use the organization’s existing EDR toolset to enforce domain restrictions. The goal is to match the browser policy already in place for the rest of the enterprise — so the developer’s session within the coding agent browser is subject to the same allow-list enforcement as any other browser on that endpoint.
-
Recognize the gap and engage the vendor: Because native enterprise controls in the coding agent were insufficient to enforce immutable configuration, the team made formal feature requests to the vendor. Requested capabilities included schema-based feature enablement by user group, allow/deny list controls for MCP tool integrations and web search domains, and the ability to selectively restrict high-autonomy modes to specific user populations before broader rollout.
-
Iterate as vendor controls mature: Snowflake noted that vendors have begun responding to these enterprise feature requests, with meaningful improvements delivered in the months following initial engagement. The control model is treated as dynamic — compensating controls via existing tooling bridge the gap until native enterprise controls reach parity.
Vendor Engagement as a Security Control
Both the GenAI tool and coding agent tracks converged on the same conclusion: vendor engagement is not optional, it is a security control. The specific feature requests Snowflake pushed to their coding agent vendors included:
- Schema-based or role-based feature enablement — the ability to turn on high-autonomy modes for specific user groups only
- Allow/deny list management for MCP servers[2] and tool integrations
- Web search restriction to approved domains
- Configuration immutability controls that prevent end-user override
The outcome: vendors responded, and Snowflake observed significant improvements in enterprise control capabilities over the following months. Structured vendor engagement with specific, operationalized feature requests accelerates the control surface maturation of the tools you are already committed to deploying.
Responsible AI Experimentation Framework for Production-Adjacent Use Cases
Proof of Concept
-
Default posture — isolated environments first: The core operating principle for all AI experimentation at Snowflake is to provide isolated environments backed by test tenants and synthetic data. This is the preferred baseline for any AI experiment, keeping production data and systems out of reach.
-
Identify production-adjacent necessity: When a specific AI use case genuinely cannot be validated with synthetic data — for example, a model or agent that requires live data characteristics, production API responses, or real customer-adjacent workflows — the team escalates beyond the default isolated environment posture.
-
Invoke the Responsible AI Experimentation Framework: For these production-adjacent cases, Snowflake applies a named governance construct — the Responsible AI Experimentation Framework — rather than treating the exception informally. This signals that production-adjacent AI work is a recognized, controlled category, not an ad-hoc bypass.
-
Establish clear accountability: The framework begins by assigning explicit accountability to the experimentation team. The team running the AI experiment owns the risk and is responsible for operating within defined boundaries. Security and IT are designated as active participants, not passive reviewers.
-
Engage security and IT as co-owners: Security and IT are brought in with defined roles — not just as approvers but as embedded stakeholders who understand the experiment’s scope, data access, and execution pathways. This shared ownership model mirrors the broader enterprise steering committee structure.
-
Apply additional review processes: Production-adjacent experiments trigger supplementary review steps beyond the standard AI tool approval process. These reviews focus on what data the AI can access, what actions it can autonomously execute, and what egress or integration surfaces are exposed during the experiment.
-
Deploy preventive and detective controls: The framework mandates both preventive controls (constraining what the AI can do — limiting data access scope, restricting outbound API calls, enforcing allow-lists) and detective controls (monitoring for anomalous behavior, unexpected data access, or execution outside defined boundaries during the experiment).
Actionable Takeaways
- Apply feature-based risk assessment to every GenAI tool and coding agent deployment: enumerate each capability individually, map it against your enterprise control plane (allow/deny lists, DLP, integration scope), and enable only the features where your existing controls are sufficient. Gate the rest — and convert the gated list into structured vendor feature requests.
- For coding agents specifically, treat the browser execution pathway as the highest-priority control surface. Restrict automated browser sessions to internal domains at the network layer (not relying on the agent's own controls), and use EDR tooling to enforce that manual browser pathways within the agent match your enterprise-wide domain policy.
- Where native coding agent control planes cannot enforce immutable configuration, layer compensating controls from your existing endpoint and IT security toolset. Document each gap as a formal vendor feature request — schema-based role controls, MCP server allow-lists, and configuration lockdown are the specific capabilities most likely to unlock safer deployment of high-autonomy modes.
Common Pitfalls
- Treating a GenAI tool or coding agent as a monolithic risk decision — either "approved" or "blocked" — rather than assessing each feature individually. This leads to either over-permissive deployments (full tool enablement with high-risk features active) or over-restrictive blocks that push usage underground and eliminate visibility entirely.
- Assuming the coding agent's own enterprise control plane provides sufficient enforcement for immutable configuration. Most coding agent control planes today cannot prevent end-users from modifying security-relevant settings. Without compensating endpoint controls, any hardened configuration can be trivially overridden by the developer, making the security posture purely advisory.
Lessons Learned: Scaling AI Governance Without Blocking Innovation
The Core Principle: Constrain Execution Authority, Not AI Itself
The most important lesson from Snowflake’s enterprise AI governance journey reframes the entire problem. AI adoption cannot be stopped — and attempting to do so is both futile and damaging to the business. If security teams try to block AI entirely, users route around controls, and the organization pays a competitive cost. The correct frame is not “can we allow this AI tool?” but “what is this AI tool allowed to execute?”
This distinction — between restricting adoption and constraining execution authority — is what makes governance sustainable at scale. Blocking a tool creates friction and resentment. Limiting what a tool can do (which domains it can reach, which file paths it can access, which API calls it can make) preserves productivity while reducing real attack surface.
Executive Sponsorship Drives Alignment
No governance model survives without top-down alignment. Snowflake’s experience was clear: security teams alone cannot make AI adoption decisions, and they should not try to. These are business decisions, not security trade-offs. Enabling or disabling an AI tool affects developer productivity, sales engineering capability, and competitive positioning — all of which require executive judgment about risk appetite.
The practical implication is that security teams must continuously surface risk data to leadership in a digestible, timely format. The visibility pathways described earlier — procurement reviews, feature gating, active discovery, and business unit partnerships — exist precisely to generate the data that makes these conversations possible. Without that data, leadership cannot make informed decisions. With it, alignment becomes achievable even at the pace AI demands.
Shared Ownership Scales Better Than Central Control
Attempting to centralize all AI governance decisions in the security team creates a bottleneck that breaks under the velocity of modern AI adoption. Snowflake’s enterprise steering committee model distributes ownership across security, IT, legal, privacy, AI/ML, data engineering, and procurement — and surfaces decisions to executive leadership in engineering, product, sales, and customer experience.
This cross-functional alignment is what allowed the governance model to remain dynamic. Each function brought different visibility into AI usage patterns. Together, they could identify risks, propose controls, and make decisions in days rather than weeks. The steering committee structure also created the cultural change required: when business units see their own leadership involved in AI risk decisions, adoption of governance processes improves.
Governance Must Evolve at the Velocity of AI
Traditional security review cycles operate on timescales measured in weeks or quarters. AI vendors ship features multiple times per week. The mismatch is structural, and the only solution is to make governance processes themselves dynamic.
For Snowflake, this meant several things in practice:
- Weekly or daily conversations with the cross-functional team about what new adoption patterns or anomalies were visible across the enterprise
- Feature-based assessment rather than tool-level approval — continuously re-evaluating specific capabilities as vendors release new functionality
- Active vendor engagement as a governance mechanism — making feature requests for missing enterprise controls rather than waiting for vendors to build them on their own timeline
- Rapid shutdown capability — the ability to get quick cross-functional alignment and disable a tool or feature when a risk exceeds tolerance
Visibility Remains the Non-Negotiable Prerequisite
Every lesson from this journey traces back to the same foundation: you cannot govern what you cannot see. Without visibility into which AI tools are deployed, which features are active, and how they are being used, no governance structure can function effectively.
Security teams should invest early and continuously in all four visibility pathways — procurement processes that surface AI tool requests before deployment, security review gates for enabling AI features in existing platforms, active discovery of AI artifacts (models, agents, MCP components) across endpoint and cloud telemetry, and embedded security partners in business units who surface adoption patterns before they become incidents.
AI Governance Is the Foundation for Responsible Innovation
The final reframe from Snowflake’s experience is perhaps the most important for security leaders making the case internally: AI governance is not a roadblock to innovation — it is the foundation that enables innovation to happen responsibly.
Organizations that lack a governance model do not avoid governance problems; they simply discover them later, under worse conditions, with less control. Organizations that build dynamic governance structures — with executive sponsorship, cross-functional ownership, continuous visibility, and a focus on execution authority rather than blanket restriction — are the ones that can say yes to AI adoption confidently and at speed.
Actionable Takeaways
- Reframe governance internally as constraining execution authority rather than restricting AI adoption — this framing gets leadership buy-in, reduces user friction, and targets the actual risk surface (what AI can do) rather than a futile attempt to stop adoption entirely.
- Build a cross-functional steering committee with representation from security, IT, legal, privacy, AI/ML, data engineering, and procurement, and establish a cadence of weekly risk conversations with this group so governance decisions can match the velocity of AI feature releases.
- Invest in all four visibility pathways (procurement oversight, feature gating, active discovery, and business unit partnerships) before attempting to enforce controls — without the data these pathways provide, governance decisions are made blind and alignment with executive leadership becomes impossible.
Common Pitfalls
- Treating AI governance as a security-only decision rather than a business decision — this creates misalignment with executive risk appetite, causes security teams to be perceived as blockers, and results in users routing around controls when adoption is refused rather than managed.
- Applying tool-level approval processes to AI platforms rather than feature-level assessment — this fails because vendors ship new high-risk capabilities continuously after a tool is approved, meaning a one-time review becomes stale almost immediately and leaves new attack surfaces ungoverned.
Conclusion
Ragini Ramalingam’s talk at [un]prompted 2026 delivers one of the most practical and structurally honest takes on enterprise AI governance available today. The core argument — that governance must constrain execution authority, not block adoption — is the insight that makes every other piece of the framework coherent. You cannot stop AI. You can define what it is permitted to execute, see who is using what, and build institutional structures fast enough to keep pace.
The four visibility pathways (procurement, feature gating, active artifact discovery, and business unit partnerships), the cross-functional steering committee model, and the feature-based risk assessment approach together form a complete operational framework — one that any security team can adapt regardless of whether they run on Snowflake’s infrastructure or not.
For security leaders building or rebuilding AI governance programs, the most actionable summary is this: visibility first, then structure, then controls. Without the data, every other piece collapses.
For related coverage on this site:
- Explore all AI/ML security talks and deep-dives
- Coding agent security: attacks, controls, and threat models
- Enterprise AI security: governance, guardrails, and deployment risk
References & Tools
- EDR (Endpoint Detection and Response) — Endpoint security tooling used to enforce immutable coding agent configuration at the OS level and constrain browser execution pathways to match enterprise-wide domain policies. ↩
- MCP (Model Context Protocol) — A protocol that extends coding agent capabilities with external tool access; MCP server components represent a key AI artifact class requiring discovery, governance, and allow/deny list controls in enterprise deployments. ↩
Questions from the audience
Related deep dives
Kinetic Risk: Securing and Governing Physical AI in the Wild | [un]prompted 2026
Securing Workspace GenAI at Google Speed | [un]prompted 2026
The AI Security Larsen Effect - How to Stop the Feedback Loop | [un]prompted 2026
