{"id":89,"date":"2026-05-05T20:14:49","date_gmt":"2026-05-05T20:14:49","guid":{"rendered":"https:\/\/www.dataradar.io\/blog\/?p=89"},"modified":"2026-05-06T22:30:46","modified_gmt":"2026-05-06T22:30:46","slug":"snowflake-native-app-or-saas-token","status":"publish","type":"post","link":"https:\/\/www.dataradar.io\/blog\/snowflake-native-app-or-saas-token\/","title":{"rendered":"Snowflake Native App or SaaS Token. The Anodot Breach Made the Choice Easy."},"content":{"rendered":"
\n

On Good Friday, April 4, 2026, deliberately timed to a bank holiday during the Easter\/Passover weekend to slow detection and response, more than a dozen companies had their data stolen. Snowflake did not fail them. Public reports indicate the intrusion path involved a third-party integration used by multiple customers. That is a data security story. It is also a data monitoring story. And for most enterprises running Snowflake today, it is a warning they cannot afford to ignore.<\/p>\n

What Actually Happened in the Anodot Breach?<\/h2>\n

Attackers stole access tokens from a third-party tool called Anodot. They used those tokens to reach the Snowflake accounts of more than a dozen companies. Snowflake itself was not hacked. The tool connected to it was.<\/p>\n

\n

The headlines on early Monday, April 6, 2026, called it a Snowflake breach. That label was wrong. \u00b9Here is what the facts show. Anodot is a third-party AI tool. It connects to Snowflake customer accounts to run data checks. Attackers broke into Anodot’s own systems. They stole the access tokens Anodot used to reach its customers’ Snowflake data. Then they used those tokens to move into more than a dozen enterprise Snowflake accounts. \u00b9<\/p>\n

Snowflake’s own systems were not touched. No flaw in Snowflake was used. The breach point was the link between Anodot and its customers. Not the platform itself. The link.The ShinyHunters group later claimed credit. They said they had stolen data from dozens of companies. They also said they had access to Anodot’s systems for some time before anyone noticed.\u00b9<\/p>\n

This is not the first time this group has run this play. In 2024, they ran a nearly identical attack. That campaign hit AT&T, Ticketmaster, Santander, and Neiman Marcus, among others. \u00b9<\/p>\n

The method was the same both times. Find a tool that connects to Snowflake. Break into that tool. Use its access to reach the data behind it.<\/p>\n

Key Insight:<\/h5>\n

Snowflake’s platform held both times. The breach point both times was the external tool sitting between the attacker and the data. This is a pattern. Not a one-time event.<\/p>\n

Is Your Data Monitor Tool a Security Risk?<\/h2>\n

Anodot was a data anomaly detection tool. Its job was to catch problems in data. It did not catch the problem in its own systems. That gap exists in most third-party data monitoring tools today.<\/p>\n

\n

The Anodot incident is worth a closer look, because the details matter. According to public reporting from BleepingComputer, TechCrunch, and TechRadar, Anodot is an AI-powered anomaly detection platform. Its job is to spot unusual patterns in data for its customers.<\/p>\n

Here is what the reporting tells us. Attackers stole authentication tokens from inside Anodot’s systems. The group known as ShinyHunters then used those tokens to reach Snowflake environments owned by Anodot’s customers. On April 9, 2026, Snowflake confirmed that Anodot was the third-party platform involved. A small number of Snowflake customer accounts were affected. Snowflake’s own systems were not compromised.\u00b9<\/p>\n

For enterprise buyers, the lesson is about architecture, not blame. Any tool that uses third-party tokens to reach your Snowflake data creates an outside dependency. If that outside system is breached, the tokens become the path in. A true Snowflake Native App takes that path away. The work stays inside your Snowflake environment, where it belongs.<\/p>\n

That is not a knock on Anodot as a product. It is an example of a core limit in how most external data tools work.
\nWhen a data tool lives outside Snowflake, it can only see what it is allowed to access via its API link. It cannot see what is happening to the link itself. It cannot see if that link is being used by someone who should not have it.<\/p>\n

The monitoring stops at the edge of the tool. But the risk does not.<\/p>\n

IBM’s 2025 Cost of a Data Breach Report found that third-party and supply chain breaches cost an average of $4.91 million per incident, making them the second most expensive breach vector in the study.2<\/sup><\/p>\n

Verizon’s 2025 Data Breach Investigations Report put the scale of the trend in plain terms. Third-party breaches now account for 30% of all breaches. That is double the rate from two years ago.3<\/sup><\/p>\n

In the United States, the average cost of a data breach hit a record $10.22 million in 2025. Supply chain breaches also take an average of 26 extra days to detect compared to other breach types. Every extra day is another day of open exposure.2<\/sup><\/p>\n

What Does Native App Really Mean<\/h2>\n

Not every tool that calls itself a Snowflake Native App works the same way. Some are true native apps that run inside your Snowflake account. Others are connector agents that link your Snowflake account to their external application and process the data outside of your environment. The difference matters a great deal for security.<\/p>\n

\n

If you are shopping for a data monitoring tool for Snowflake right now, you will hear the phrase ‘Snowflake Native App’ from more than one vendor. It is important to understand that this phrase does not mean the same thing from vendor to vendor.
\nSnowflake’s own Native App Framework has a clear definition.<\/p>\n

A true Snowflake Native App runs within the customer’s Snowflake account. The code runs on the customer’s own compute, with no external processing of your data, greatly reducing your risk.<\/p>\n

What Do the Well-Known Data Observability Platforms Actually Do?<\/h2>\n

Most of the established data observability and monitoring platforms on the market today follow a similar architectural pattern. They deploy an agent or connector that authenticates to the customer’s Snowflake account, then pulls metadata, query logs, and, in many cases, sample data out of Snowflake and sends it to the vendor’s own cloud environment, typically AWS, GCP, or Azure, where the analysis, machine learning, and alerting happens. The results are then surfaced back to the customer through the vendor’s web application.<\/p>\n

This pattern is common because it is easier for vendors to build and maintain. All customers share the same vendor-hosted analytics stack. But it creates a set of risks that customers often do not see until something goes wrong:<\/p>\n<\/div>\n\n