Snowflake's Security Evolution: From Shared Responsibility to Shared Destiny and the AI Frontier

Being the Chief Information Security Officer (CISO) at a major cloud data platform like Snowflake is inherently complex, a role demanding constant vigilance and strategic foresight. However, the spring of 2024 presented a particularly acute challenge for Snowflake and its CISO, Brad Jones. A series of high-profile data breaches impacting major customers, including Ticketmaster and Santander, brought the critical issue of cloud security, and specifically customer security practices, into sharp focus.

These incidents, while not stemming from a compromise of Snowflake's core infrastructure, highlighted vulnerabilities residing squarely on the customer side. Attackers successfully accessed over 160 customer accounts by leveraging previously exposed credentials, often harvested by infostealer malware from compromised customer systems. A critical failure across these affected accounts was the absence of multi-factor authentication (MFA), a fundamental security control that could have largely mitigated the impact of the stolen credentials.

While investigations by leading incident response firms like Mandiant and CrowdStrike ultimately confirmed that Snowflake's own enterprise environment and employee credentials were not the source of the breaches, the events served as a stark reminder of the interconnectedness of security in the cloud ecosystem. The fallout, though technically attributed to customer security gaps, inevitably cast a shadow over Snowflake, demonstrating that in the eyes of the public and the market, the security of data hosted on a platform is a shared concern, regardless of where the technical responsibility lies in a traditional model.

This experience prompted a significant introspection and strategic pivot within Snowflake's security leadership. According to Brad Jones, the incidents catalyzed a fundamental rethinking of the relationship between cloud provider and customer security. The traditional 'shared responsibility model,' while technically accurate in defining boundaries, proved insufficient in preventing reputational damage and ensuring robust customer security outcomes.

"It was an unfortunate situation that our customers went through, and we've really pivoted from a shared-security model to more of a shared-destiny model with our customers," Jones explained in an interview. This shift acknowledges a crucial reality: the security fate of the cloud provider and its customers are inextricably linked. When a customer experiences a breach involving data stored on the platform, it negatively impacts both parties. "If something's in the news on Snowflake, or a customer that happens to involve Snowflake, it's negative for both," Jones emphasized.

The 'shared destiny' model represents a commitment by Snowflake to move beyond merely providing security controls and documentation. It signifies a proactive engagement with customers to help them achieve and maintain a strong security posture on the platform. This is not about taking over customer responsibility, but about becoming a more active partner in their security journey, providing tools, visibility, and even intervention when necessary.

From Shared Responsibility to Shared Destiny: A Paradigm Shift

To fully appreciate the significance of Snowflake's pivot, it's helpful to understand the traditional cloud 'shared responsibility model.' This model, widely adopted across the cloud industry, delineates specific security duties between the cloud provider and the customer. The exact division varies depending on the service model (IaaS, PaaS, SaaS), but generally:

• Cloud Provider Responsibility: Security of the cloud. This includes the physical infrastructure (data centers, hardware), network infrastructure, and the underlying virtualization or containerization layers. For a PaaS like Snowflake, this also extends to the platform software itself.

• Customer Responsibility: Security in the cloud. This encompasses everything the customer runs or puts into the cloud environment. For Snowflake users, this primarily involves:

  • Data security and classification.
  • Identity and access management (user accounts, permissions, authentication).
  • Configuration of security controls provided by the platform.
  • Operating system, application, and network controls within their deployed instances (less relevant for a pure data platform like Snowflake, but applies to connecting systems).
  • Client-side security (protecting credentials on user devices).

In theory, this model provides clarity. The provider secures the foundation, and the customer secures what they build and store on that foundation. However, in practice, this model often breaks down due to several factors:

• Complexity: Cloud platforms are vast and complex. Understanding and correctly configuring all available security controls can be challenging for customers, especially those with limited cloud security expertise.
• Misconfiguration: Human error in configuration is a leading cause of cloud breaches. Default settings might not be secure enough, or users might inadvertently expose data or weaken authentication.
• Credential Management: Customers are responsible for managing user credentials and implementing strong authentication mechanisms like MFA. Failures here, often due to poor password hygiene or lack of MFA adoption, are frequently exploited.
• Lack of Visibility: Customers may lack adequate visibility into their security posture within the cloud environment, making it difficult to identify and remediate risks proactively.
• Evolving Threats: Attackers constantly develop new techniques, such as sophisticated phishing campaigns and infostealer malware, specifically targeting user credentials that grant access to cloud resources.

The 2024 Snowflake-related breaches were a textbook example of the shared responsibility model's limitations in the face of real-world threats. While Snowflake secured its platform, customer-side failures in credential management and MFA adoption led to significant data exfiltration. The 'shared destiny' model is Snowflake's response to this reality, acknowledging that technical responsibility is only one part of the equation; mutual success in security requires a more collaborative and proactive approach.

Concrete Actions in the Shared Destiny Model

The shift to a shared destiny model is not just a philosophical change; it's backed by concrete actions and feature implementations aimed at making customers more secure, even against their own potential missteps or external credential compromises. Brad Jones detailed several key initiatives:

Strengthening Authentication Defaults and Requirements

Recognizing that compromised credentials were the primary vector in the 2024 incidents, Snowflake took decisive action to bolster authentication:

• Mandatory MFA for New Accounts: Starting in October 2024, multi-factor authentication became mandatory by default for all newly created Snowflake accounts. This is a critical step, as it significantly reduces the risk of unauthorized access even if a password is stolen.
• Phased Deprecation of Single-Factor Logins: Snowflake initiated a phased plan to deprecate and eventually block single-factor password-only logins entirely. The target for a full block is November 2025. This aggressive timeline forces existing customers to adopt stronger authentication methods, moving away from inherently weaker single-factor reliance.

These measures directly address the root cause of the 2024 breaches and represent a significant intervention into the customer's traditional domain of identity and access management configuration. By making strong authentication the default and eventually the only option, Snowflake is actively shaping customer security behavior for the better.

Enhancing Platform-Level Security Controls and Visibility

Beyond authentication, the shared destiny model involves providing customers with better tools and insights into their security posture:

• Uniform Security Controls: Ensuring consistent and robust security controls are available and easily configurable across the different cloud service providers where Snowflake operates (AWS, Azure, GCP).
• Private Networking Connectivity: Offering options for customers to connect to Snowflake services via private networks, ensuring sensitive data traffic does not traverse the public internet, reducing exposure to eavesdropping or man-in-the-middle attacks.
• Default Encryption: All data stored internally within Snowflake is encrypted by default. While encryption is a standard practice, emphasizing it as a default setting reinforces the baseline level of data protection provided by the platform.
• Benchmarking Against CIS Controls: Snowflake actively promotes and facilitates customers benchmarking their security configurations against the Center for Internet Security (CIS) Benchmark for Snowflake. This benchmark provides a set of 31 recommended best practices for securing the platform. By encouraging and providing visibility into adherence to these controls, Snowflake helps customers identify and close security gaps.
• Account Team Visibility: Empowering Snowflake's account teams with visibility into the security posture of their customers. This allows account managers and security specialists to proactively engage with customers who may have weak configurations or low adoption of critical security features like MFA, offering guidance and support before an incident occurs.

Proactive Threat Detection and Response

A key element of shared destiny is Snowflake taking a more active role in detecting potential threats targeting customer accounts:

• Leaked Password Protection Service: Snowflake launched a service that actively scours the dark web and other sources for leaked Snowflake account credentials. If potentially compromised credentials are found, Snowflake proactively validates their activity. If they are still active, the company takes immediate action, locking the account and initiating communication with the customer. This moves beyond simply notifying customers after a potential compromise is detected through login attempts; it's an effort to get ahead of attackers using stolen credentials harvested elsewhere.

This proactive monitoring and intervention capability is a significant departure from a strict shared responsibility model, where detecting and responding to the use of stolen credentials would typically fall solely on the customer's security operations team.

These initiatives collectively demonstrate Snowflake's commitment to a shared destiny. They represent a strategic investment in customer security, recognizing that the platform's reputation and success are intrinsically tied to the security outcomes of its users. It's a model where the provider doesn't just offer tools but actively participates in ensuring those tools are used effectively to build a resilient security posture.

The Evolving Threat Landscape: Beyond Credentials

While addressing the lessons learned from past incidents is crucial, the security landscape is constantly evolving. Brad Jones highlighted that one of the biggest challenges for CISOs is anticipating and preparing for the 'unknowns' – the emerging threats that haven't yet materialized into widespread attacks. At the forefront of these unknowns is the rapid advancement of Artificial Intelligence (AI).

AI presents a dual challenge for security professionals. Firstly, it introduces new vulnerabilities and attack vectors targeting AI systems themselves. Secondly, and perhaps more significantly, it empowers attackers with new tools and capabilities, accelerating the pace and sophistication of attacks.

AI Security Challenge 1: Data Protection and Exposure

As organizations increasingly integrate AI into their workflows and applications, the handling of data becomes paramount. AI models require vast amounts of data for training and operation, and this data can be highly sensitive. The primary concern, according to Jones, revolves around ensuring that data used with or processed by AI remains secure and is not exposed in unintended ways.

This concern is amplified when using third-party AI services or models. Organizations need to be acutely aware of how these services handle the data they process. Are prompts logged? Is uploaded data retained? Is the data used for further training of the third-party model, potentially exposing proprietary or sensitive information? The DeepSeek example cited by Jones, where a service reportedly captured and accidentally exposed user data, serves as a cautionary tale about the risks associated with external AI dependencies and inadequate due diligence.

Beyond third-party risks, internal AI deployments also pose data security challenges. Ensuring proper access controls, data masking, and anonymization techniques are applied to training data is critical. Preventing data poisoning, where malicious data is introduced into the training set to manipulate model behavior or compromise data integrity, is another growing concern.

AI Security Challenge 2: The Pace of Evolution and Agentic AI

The second major challenge is the sheer speed at which AI capabilities are advancing, particularly with the emergence of 'agentic AI.' Agentic AI refers to systems designed to operate autonomously, making decisions and taking actions to achieve a goal without requiring step-by-step human instruction.

Jones referenced Microsoft's roadmap outlining the stages of agentic AI development:

1. Chatbot Phase: AI assists humans by fetching information, answering questions, summarizing documents, and analyzing data. Human remains firmly in control, initiating queries and interpreting results.
2. Action-Taking Phase: AI can automate workflows and perform repetitive tasks, but only when explicitly triggered and directed by a human user. The AI acts as a powerful tool under human supervision.
3. Independent Operation Phase: AI agents operate autonomously, orchestrating other AI tools, accessing systems, and making decisions to achieve higher-level objectives without constant human prompting. Humans transition to managing teams of agents rather than directly instructing them.

It is this third phase – where AI agents act independently – that introduces significant security and governance complexities. While immensely powerful for automation and efficiency, autonomous agents raise questions about accountability, control, and unintended consequences. What happens if an agent encounters an unexpected situation? How do you ensure it adheres to security policies when operating without direct human oversight? How do you audit its actions? The potential for autonomous agents to inadvertently or maliciously access sensitive systems, propagate errors, or be exploited by attackers is a significant concern.

Managing teams of agents requires a robust governance framework. This includes defining clear boundaries for agent actions, implementing strong access controls for the systems they interact with, establishing monitoring and alerting mechanisms for unusual behavior, and having mechanisms to pause or terminate agent operations if necessary. The more complex and interconnected the environment, the more challenging this governance becomes.

The 'Yes, And' Philosophy for Security Leaders

Given the rapid pace of technological change, particularly with AI, security teams can sometimes be perceived as blockers – the team that always says "no" to new initiatives due to perceived risks. Brad Jones argued strongly against this approach, advocating instead for a philosophy borrowed from improvisational theater: the "yes, and" rule.

"Security [can't] say whether it's a good or bad idea. Security has to adapt. Security Teams can never be the team of no," Jones stated. Instead of rejecting new technologies like AI outright, security leaders must embrace them with a proactive mindset. The response should be, "Yes, we can explore and implement this technology, AND here are the necessary controls, safeguards, and best practices to do so securely."

This approach positions security as an enabler rather than an impediment. It involves working collaboratively with business units, understanding their goals and the potential benefits of new technologies, and then finding secure ways to achieve those goals. For AI, this means:

• Understanding the Technology: Security professionals must educate themselves on how AI works, its capabilities, and its inherent risks.
• Integrating Security Early: Security considerations must be built into the design and implementation phases of AI projects, not bolted on afterward. This aligns with DevSecOps principles.
• Developing AI-Specific Controls: Traditional security controls may not be sufficient for AI. New methods for validating AI outputs, monitoring agent behavior, and securing training data are needed.
• Establishing Governance Frameworks: Clear policies and procedures are required for the responsible and secure use of AI, especially autonomous agents.
• Promoting Security Awareness: Educating users and developers about the risks associated with AI and how to use it securely is crucial.

Jones's perspective underscores a fundamental truth for modern security leaders: technology adoption is driven by business needs. AI will become increasingly integrated into operations, and security teams must adapt to secure its use rather than attempting to prevent it. By adopting a "yes, and" mindset, security can become a strategic partner, helping the organization leverage powerful new tools like AI while managing the associated risks effectively.

Conclusion: Navigating the Future of Cloud and AI Security

The experiences of 2024 served as a catalyst for Snowflake, prompting a significant evolution in its approach to customer security. The shift from a shared responsibility model, which proved insufficient in the face of widespread customer-side vulnerabilities, to a proactive 'shared destiny' model reflects a deeper understanding of the interconnected nature of security in the cloud ecosystem. By implementing mandatory MFA, deprecating weak authentication, enhancing platform controls, and launching proactive threat detection services, Snowflake is taking tangible steps to improve the collective security posture of its platform and its customers.

Looking ahead, the security challenges continue to mount, with the rapid rise of AI, particularly agentic AI, presenting complex new 'unknowns.' Securing data used by AI and governing the actions of autonomous agents will require innovative approaches and a willingness from security teams to adapt and evolve.

Brad Jones's insights highlight the critical role of the modern CISO: not just as a defender against known threats, but as a strategic leader who can navigate uncertainty, collaborate with the business, and enable the secure adoption of transformative technologies. The 'shared destiny' model at Snowflake and the embrace of a 'yes, and' philosophy for AI security are indicative of the proactive and adaptive strategies required to secure the future of cloud computing and artificial intelligence.

The lessons from the 2024 breaches resonate far beyond Snowflake, serving as a reminder to all cloud users and providers about the persistent threat of compromised credentials and the vital importance of fundamental security hygiene like MFA. As AI agents become more prevalent, the need for robust governance and a collaborative security approach will only intensify, demanding that organizations and their technology partners work together more closely than ever to build a truly shared secure destiny.