Varonis Blog

Varonis and Cohesity: Improving Cyber Resilience with Data Security

Dan Petrillo — Wed, 30 Sep 2026 15:04:57 GMT

Backup datasets often contain sensitive information — from PII to intellectual property — and a wide range of business-critical data. Without visibility into their backups, security teams are left with a blind spot that increases the blast radius and impedes cyber recovery.

Together, Varonis and Cohesity close that gap, pairing deep insight into backup data with stronger security and faster recovery.

Varonis integrates with Cohesity to combine proactive data security with cyber resilience, surfacing what’s inside backup data, automating remediation, detecting threats, and enabling secure recovery.

How Varonis and Cohesity reduce risk and strengthen resilience

Varonis and Cohesity address the gap between data security and cyber resilience, from discovery through recovery. Each layer builds on the last:

Discover and classify sensitive data

Varonis automatically discovers and classifies sensitive and regulated data across Cohesity Data Cloud, helping organizations identify risk, reduce data exposure, strengthen cyber resilience, and accelerate recovery efforts. Continuous visibility into sensitive data supports compliance, retention requirements, and AI readiness.

Lock down access and shrink the blast radius

Overexposed data is a breach waiting to happen. Varonis maps your entire permissions structure, providing visibility into where data resides, who has access to it, and who's using it. From there, you can enforce least privilege: managing access at a granular level and safely automating permission changes, while shrinking the blast radius with minimal effort.

Detect and stop threats in real time

Varonis builds baseline behavioral profiles for users and non-human identities, then continuously monitors for the activity that signals an attack, including suspicious data access, lateral movement, and privilege escalation. When something looks wrong, Varonis can alert your team and leverage automated responses to prevent data from being affected, like shutting down user sessions and changing passwords, with no wait for manual triage.

And for organizations that want 24x7 coverage, Varonis Managed Data Detection and Response (MDDR) provides expert-led monitoring, investigation, and response to help stop threats before they impact critical data.

Contain ransomware and recover fast

If ransomware reaches your data, the two platforms work together to contain and recover. Varonis flags the abnormal file activity that signals encryption and triggers an automated response to lock it down. Cohesity hardens the data itself with AES-256 encryption, multifactor authentication, DataLock for WORM and FIPS-compliant encryption.

And because Cohesity keeps unlimited, fully hydrated snapshots, you can mass-restore files, VMs and application objects almost instantly, cutting recovery time from days to minutes.

Optimize cost

Varonis Data Lifecyle Management continuously identifies redundant, obsolete, and trivial (ROT) data, helping organizations safely archive or dispose of data that no longer provides business value. By shrinking the amount of data stored and protected in Cohesity, customers can improve storage efficiency, reduce infrastructure costs, and maintain a cleaner, more manageable data estate while preserving compliance and security requirements.

Complete visibility, protection, and recovery

Security teams work faster when the picture is unified. By continuously identifying sensitive, stale, and overexposed data, Varonis helps organizations reduce cyber risk before an incident occurs and provides the context needed to prioritize recovery efforts when one does.

Cohesity gives you a single UI and enterprise search across silos, VMs, backups, data centers, remote sites, and multiple clouds. Varonis layers on the context that makes that data defensible: classification, automated remediation, threat detection, and ROT reduction.

Together, Varonis and Cohesity deliver a unified approach to data security and cyber resilience, helping organizations protect sensitive data throughout its lifecycle.

AI Security Fundamentals: The Real Industry Shift Taking Place

Jonathan Villa — Fri, 25 Sep 2026 18:27:54 GMT

Key takeaways

"Security for AI" isn't a distinct discipline. AI systems need the same governance, access controls, and monitoring as everything else in the stack.
Adopting AI often functions as an unplanned pen test, exposing pre-existing weaknesses like excessive permissions, weak identity controls, and poor data classification.
AI's real advantage for defenders isn't securing AI itself — it's using AI to finally process, prioritize, and act on security data at a scale humans never could.

AI adoption is forcing organizations to confront problems they've ignored for years, especially around data governance, identity management, and access controls. The real story isn't how to secure AI as its own category — it's how AI is exposing those long-standing gaps, and how it's finally giving defenders a way to keep up.

Varonis recently sat down with cybersecurity leaders Mike Privette, the mind behind Return on Security, and Matt Lock, former Field CTO at Varonis, to unpack how AI is reshaping both sides of that equation. Here are the key takeaways from their conversation.

Security for AI vs. AI for security

It boils down to this: Security for AI isn’t distinctive, it’s security. AI systems are simply another piece of an organization’s technology stack that require the same governance, access controls, monitoring, and protection as the rest.

When AI was first introduced, early security efforts took a narrow view: protecting chatbots and models, preventing leakage, securing system prompts. That didn't last. The industry quickly moved from protecting AI to using AI to supercharge cybersecurity.

It's the same trajectory cloud computing took. Companies once marketed themselves as cloud companies, but today, using the cloud is simply assumed. Matt expects AI to reach that same point, where the question isn't whether a product uses AI, but whether it delivers better security outcomes because of it.

Why AI exposes existing weaknesses

An organization adopting AI opens itself up to what Mike calls “unexpected pen tests," because they quickly face a reality check on the level of unintended access an agent could have. That's because deploying tools like Copilot or Claude reveal excessive permissions, weak identity controls, poor data classification, and other issues.

Agents accessing systems autonomously may also discover pathways security teams would not have otherwise anticipated. And for agents to do so in split seconds means that a sole bad actor with access to an organization’s unsecured AI can do serious damage in a short amount of time.

AI vs. AI: The new security arms race

Thanks to AI, attackers are seeing increases in both speed and scale. Matt points out that cybercriminals don’t care about compliance, governance, or guardrails. They’ll do whatever it takes to get what they’re after. In many cases, that’s data.

For decades, cybersecurity has largely been reactive. AI may offer the first technology that allows defenders to be proactive. With things like automated detection, 24/7 monitoring, preemptive phishing takedowns and automated investigations, the playing field has certainly leveled.

Matt and Mike also propose an interesting tactic: making attacks too expensive for attackers. Strategies like AI honeypots and AI labyrinths can waste attacker time, burn through an attacker’s tokens, and force attackers through useless paths.

Using AI to supercharge security

AI’s biggest impact is enabling defenders to operate at machine speed. Security teams generate enormous amounts of data but struggle to sort through it manually.

With AI, security teams can easily:

Investigate alerts

Correlate signals

Add context

Reduce false positives
Surface only meaningful threats

Rather than having SOC analysts review everything, AI can help ensure only prioritized incidents reach humans.

Vulnerability prioritization

Matt also argues that the hard part isn’t finding the vulnerabilities, it’s fixing and prioritizing them. Historically, cybersecurity has been constrained by human capacity. AI changes that by helping enterprise security teams process more data, analyze more signals, reduce response time, and scale expertise across the security team.

The future of cybersecurity, then, is about knowing which ones are important.

Security fundamentals still win

Despite the excitement around AI security, the conversation repeatedly comes back to the same thing: organizations need to focus on the fundamentals. Every AI initiative relies on accurate permissions, clean identity models, and data governance.

Data and identity remain the core problems behind cybersecurity. An organization without control over their data, identity, and access opens themselves to immense risk. Matt has preached this to other cybersecurity professionals for over a decade, but he's only now hearing others say the same thing back to him.

The real AI security shift

For all the discussion around agents, autonomous systems, vulnerability discovery, and AI-powered attacks, Matt and Mike repeatedly return to the same conclusion: AI is changing cybersecurity, but it's not changing what cybersecurity is trying to accomplish.

The industry’s first reaction to AI was to ask: How do we secure AI? The more important question turned out to be: How do we use AI to solve security problems we've struggled with for decades?

If their predictions hold true, the future of cybersecurity won't be defined by who adopts AI first. It'll be defined by who uses it to solve the problems that have been there all along.

Watch their full conversation:

Meet AvisLoader: A Windows Loader Built to Outlast a Takedown

Daniel Kelley — Wed, 23 Sep 2026 13:00:01 GMT

Varonis Threat Labs recently discovered AvisLoader, a new Windows loader named after the Latin word for bird. We found it on an exposed staging server alongside a ClickFix lure, supporting tools, and its Command Center.

The attack starts with a familiar ClickFix lure. A page posing as a document-signing request asks visitors to copy and run an attacker-supplied command on their machine.

The more interesting part is how AvisLoader stays connected. It communicates via Tox, an encrypted peer-to-peer (P2P) messaging network that carries commands and additional payloads from the operator.

That setup makes traditional domain-based takedowns harder. The command-and-control (C2) channel does not depend on a fixed domain or server address, and operators can keep the same identity when moving to another server.

The seller references this in a cybercrime forum listing, claiming the controller can be moved by copying its Tox save file, with clients following without the need for a domain.

In this post, we look at how AvisLoader works, the MITRE ATT&CK techniques it uses, and the indicators security teams can use to detect it.

Delivery through ClickFix and Cloudflare

The specific ClickFix lure we found alongside AvisLoader was hosted on Cloudflare Workers and made to look like a DocuSign signing request.

A fake “Manual verification” dialog claims “Verification is handled by Cloudflare” and asks visitors to paste a “verification code” into a terminal. It presents running the command as a step needed to access the document.

What lands on the clipboard is a command that retrieves and runs code from a Cloudflare Quick Tunnel address on trycloudflare.com. A download still takes place, but through the pasted command, outside the browser’s normal download flow.

Although the lure shows a macOS command, the exposed directory contained a Windows loader. We did not find a corresponding macOS payload among the recovered files.

Inside the loader

The Windows payload is a single 3.4 MB 64-bit executable. Its manifest specifies asInvoker, meaning it inherits the privileges of the process that launches it without requesting User Account Control (UAC) elevation at startup.

Its section table contains seventeen additional sections of identical size, with names associated with well-known packers, including Themida, VMProtect, Enigma, and UPX. None is marked executable. These names appear intended to confuse packer identification, although the names alone do not establish that any of those packers was used.

Underneath, it’s a Tox client. The executable statically links c-toxcore, the reference implementation of the Tox protocol, and retains the developer’s build path, C:\Users\dev\Desktop\c-toxcore.

Using Tox lets the loader communicate with its controller as another peer on the network. This removes reliance on a single centralized command-and-control address, but the network connections remain observable alongside the loader’s activity on the host.

Escalation, persistence, and stealth

AvisLoader’s persistence code targets shortcuts on the desktop and in the taskbar-pinned folder. The executable contains shortcut-backup strings and a VBScript launcher associated with the name VLCAssistant. These artifacts indicate a mechanism designed to launch the malware when a user opens a modified shortcut, then start the intended application so it appears to open normally.

The recovered files also include auto.exe, a small helper that references method 41 from UACME, a public User Account Control (UAC) bypass project. Its strings identify the ICMLuaUtil interface and the Component Object Model (COM) elevation mechanism associated with that technique. The helper also warns that updated Windows versions may mitigate the bypass, so its presence does not establish successful elevation.

A separate dynamic-link library (DLL), hmn_hook.dll, provides process-hiding functionality. It hooks NtQuerySystemInformation, a Windows function used to retrieve process information, and filters a specified process name from the results. This could hide that process from software using the hooked function, but the recovered files do not establish that the DLL was loaded into Task Manager or used to hide AvisLoader itself.

The AvisLoader command center

The recovered tools give us a view of AvisLoader’s endpoint capabilities. Its web panel, branded the AvisLoader Command Center, shows how operators are meant to manage clients, configure tasks, and distribute files. The dashboard includes counts of total, online, and offline clients, along with a world map.

A Clients table includes fields for hostname, country, central processing unit (CPU), graphics processing unit (GPU), antivirus, administrator status, and a public key. These fields bring host information into one view. The public-key field is consistent with Tox’s peer identity model.

The Tasks tab lets operators configure shell commands and select clients by hardware, location, and administrator status. Its controls indicate support for tasks that run when matching clients come online, allowing operators to prepare commands ahead of a client connecting.

The Files tab provides an interface for staging files and describes delivery “to clients over Tox.” This gives operators a way to prepare additional payloads for distribution.

Defenses and takeaways

AvisLoader gives security teams several opportunities for detection, from the initial ClickFix command to shortcut changes and unexpected Tox traffic. The delivery setup and recovered files point to four areas for monitoring:

Treat document-signing or verification pages that ask users to paste commands into a terminal or the Windows Run dialog as suspicious. Users should report these requests before running the command.
Investigate unfamiliar workers.dev and trycloudflare.com addresses when they appear in document-signing lures or commands that download and execute code. Both domains support legitimate services, so consider the page content and surrounding activity when assessing them.
Monitor command shells and script interpreters that retrieve and execute remote code, especially when the activity follows a visit to a suspicious page. Check for unexpected Tox or other peer-to-peer traffic on the same device. A command pasted by a user may run without the browser appearing as its parent process.
Hunt for modified desktop and taskbar shortcuts, associated .backup files, and references to VLCAssistant. Investigate matches for the recovered auto.exe and hmn_hook.dll samples, then examine the surrounding activity for elevation attempts or process-list hooks.

What we learned from AvisLoader

AvisLoader brings familiar malware techniques together around Tox. The recovered Windows sample includes shortcut-persistence artifacts, while its Command Center offers shell tasks and file delivery over an encrypted peer-to-peer connection.

For security teams, this means a legitimate messaging protocol can also carry operator commands and additional malware. Understanding that traffic means looking at the application behind it and what it does on the device, alongside the network connections it makes.

MITRE ATT&CK

Technique ID	Technique name	Supporting evidence
T1204.004	User Execution: Malicious Copy and Paste	The ClickFix lure instructs visitors to paste and run an attacker-supplied command.
T1547.009	Boot or Logon Autostart Execution: Shortcut Modification	Loader artifacts support the modification of desktop and taskbar shortcuts to launch malware when opened. Boot or logon execution was not established.
T1548.002	Abuse Elevation Control Mechanism: Bypass User Account Control	The bundled auto.exe helper implements the UACME method 41 bypass. Successful elevation was not confirmed.
T1014	Rootkit	The bundled hmn_hook.dll hooks NtQuerySystemInformation to filter a specified process name from returned results. Its deployment was not confirmed.
T1071	Application Layer Protocol	The loader incorporates c-toxcore for Tox-based command-and-control communications.
T1105	Ingress Tool Transfer	The Command Center offers file delivery to clients over Tox. Successful transfers were not confirmed.

Indicators of compromise

File indicators

Filename	SHA-256	Role
78324.exe	35dd164a7f5d8b42b9870c7009f7425b1c8cb771280c9e6c525e09f3dd13c2cc	AvisLoader Windows client
auto.exe	f0a6870cb774a55775eda15fd39e8a17eb3169d5b9365186dae8edff07ff3975	Bundled elevation-bypass helper
hmn_hook.dll	cd1e835f52e5f55279dcdf3857e11bc9298ea6caa88eb214ea2d40ff5d38b5f5	Bundled process-hiding library

Host and analysis artifacts

Attribute	Value
Persistence-related launcher name	VLCAssistant
Shortcut backup extension	.backup, relevant alongside modified desktop or taskbar shortcuts
Embedded developer build path	C:\Users\dev\Desktop\c-toxcore, present inside the loader
hmn_hook.dll exports	HMN_HideStart, HMN_HideStatus, HMN_HideStop
Function hooked by hmn_hook.dll	NtQuerySystemInformation, a legitimate Windows function
Component Object Model (COM) class identifier referenced by auto.exe	{3E5FC7F9-9A51-4367-9063-A120244FBEC7}, associated with the elevation-bypass technique

How Varonis can help

Varonis' Data Security Platform uses behavioral analytics to flag abnormal activity that matches these techniques, including unexpected process lineage from a browser or script interpreter, privilege escalation, and the data access that usually follows a loader.

Even when the command channel has no domain to block, Varonis catches what the intrusion does next. Varonis MDDR pairs that detection with an expert team that triages and contains incidents like this one.

Introducing Varonis Triage Agent: An Autonomous Incident Responder to Amplify MDDR Service

Nolan Necoechea — Tue, 22 Sep 2026 13:38:36 GMT

Key takeaways

The Varonis Triage Agent is an AI incident responder that investigates alerts like an analyst, gathering evidence and testing explanations.
With the Triage Agent, MDDR analysts respond to malicious activity more quickly.
The agent maintains a production recall rate above 96%, reliably surfacing real threats without burying them in false-positive noise.

The average security analyst has minutes to figure out whether a login attempt is a valid employee attempting to gain access or an attacker already inside the network. Every second spent gathering context — checking identity history, cross-referencing data access, ruling out false positives — is a second an attacker can use to move laterally and widen the blast radius of their reach.

Varonis Managed Data Detection and Response (MDDR) service is built to close that gap with a team of dedicated security experts who monitor customer environments around the clock, investigate alerts, and respond to real threats before they escalate.

To stay ahead of threats, including attackers armed with AI, the MDDR team continues to innovate with AI, most recently with the Varonis Triage Agent.

What is the Varonis Triage Agent?

The Varonis Triage Agent is an automated AI agent trained to operate as an incident responder and amplify MDDR’s ability to respond to threats decisively. Developed by security researchers and data scientists at Varonis, the agent weighs numerous signals, including identity behavior, data sensitivity, and login patterns, against the context of Varonis’ extensive repository of security incidents. The result enables the MDDR team to act even more quickly.

Varonis MDDR analysts have used agentic AI since early 2025 to help prioritize alerts to match the speed and scale of automated attacks. Just like an incident responder, the Triage Agent gathers evidence, considers alternative explanations, and analyzes signals for patterns against more than 300 threat scenarios.

It's just one of the innovations that makes Varonis MDDR one of the most effective ways to keep your data continuously protected.

How much faster does the Triage Agent make detection and response?

The Triage Agent works alongside MDDR analysts, beginning the investigation earlier, connecting evidence across the environment, and giving analysts a well-constructed starting point rather than a blank page. That means analysts spend less time gathering evidence and connecting dots and more time acting on it.

With the Triage Agent, MDDR analysts can respond to malicious activity twice as fast.

In production, Varonis has measured:

Up to 100% improvement in analyst efficiency.

A production recall rate above 96%, meaning the agent reliably surfaces real threats rather than burying them in noise.

For customers, the practical effect is a faster path from signal to resolution.

How the Triage Agent investigates an alert

Rather than scoring an alert in isolation, the Triage Agent investigates the way an experienced analyst would: forming a hypothesis, gathering evidence, testing benign explanations, and changing direction when the facts don't fit.

In one recent case, that approach let the agent connect a moderate, easy-to-overlook alert to two related alerts from the same day — reconstructing what looked like three isolated spikes into a single, escalating exfiltration attempt spanning over 17,000 file downloads. Learn more about how the agent reached that conclusion in our technical deep dive.

Why the Triage Agent can be trusted in production

This was never simply a prompting project. The orchestration, tools, and data foundation all mattered, but the system only became useful once those pieces were grounded in the investigative methods of experienced security researchers and tested against real outcomes.

Security researchers identified the questions and relationships that a human investigator checks reflexively. Data scientists translated those lessons into tools, context, guidance, and repeatable evaluation workflows. The shared loop between those disciplines — run, inspect, correct, measure — moved the agent forward.

The goal isn't to replace human judgment. It's to move analysts away from manually gathering context and toward reviewing evidence, making consequential decisions, and containing threats before the damage spreads.

What’s next for Varonis MDDR

Alert volumes aren't slowing down. If anything, attackers using AI of their own are pushing them higher. The Triage Agent gives Varonis’ MDDR experts room to write broader, more sensitive detection rules without flooding analysts, because the agent absorbs the added volume and filters for what matters.

It's one piece of the ongoing work at Varonis to keep pace with that shift, and MDDR customers get it automatically as part of the service.

Varonis Named a Pace Setter in the September 2026 Gartner® Emerging Market Quadrant for AI Application Security

rsobers@varonis.com (Rob Sobers) — Mon, 21 Sep 2026 12:55:47 GMT

Varonis is proud to be named Pace Setter in the Gartner® Emerging Market Quadrant for AI Application Security, recognized for our approach to securing AI applications across the entire development and deployment lifecycle.

We believe this recognition is especially meaningful for organizations that need AI security they can use now, not capabilities that are still on the roadmap. Pace Setters are vendors with strong existing capabilities across mandatory AI application security functions, including discovery and inventory, runtime defense, and AI security testing. This matters because enterprises moving quickly with AI need security controls that can deliver rapid time to value, provide immediate coverage for enterprise AI use, and support production environments with reliability and readiness.

As organizations push to rapidly adopt AI-powered applications, the attack surface is expanding faster than most security programs can keep up. Sensitive data now flows through training pipelines, system prompts, agent permissions, and the dozens of tools developers use to build and ship AI, often with little to no visibility or control. We believe this recognition reflects Varonis Atlas's ability to close that gap and validates the growing demand for security platforms that can discover, govern, and protect data across the full AI lifecycle.

Varonis Atlas is purpose-built to address this shift, bringing deep data visibility, automated remediation, and contextual intelligence to AI environments, from the first line of training code to production runtime.

The new AI attack surface: data, prompts, models, and agents

AI applications introduce risks that extend beyond infrastructure and identities and into data, prompts, models, and outputs. Hundreds of thousands of organizations are now building AI applications, and the pace of development is outrunning the pace of security.

Unlike traditional software, data isn't just an input for AI applications; it determines how those applications behave. That reshapes the attack surface. Credentials that authenticate AI services, the system prompts that define agent behavior, and the training data that shapes model output all flow through the development cycle and into production, often outside the reach of conventional AppSec tooling.

The security risks show up in a few consistent ways:

Training data and retrieval sources pull from production, so a single leaked credential can expose everything an AI agent is trained on or can query, not just one database.
System prompts and model configurations, stored in repos and wikis, describe internal policies and data schemas, effectively handing attackers a roadmap of what they can exploit.
AI agents are overprivileged by design. The broad access scopes granted during development often persist unchanged into production, where they carry real consequences. This is already happening, with a recent example that involved an AI agent with excessive permissions and no runtime guardrails that deleted its own operator's inbox, despite explicit instructions to ask first.

Traditional security approaches lack visibility into how sensitive data is used by AI, cannot enforce policy across dynamic AI workflows, and were never designed to detect misuse or overexposure in AI-driven environments. Legacy AppSec tools are good at finding secrets in code and scanning for known vulnerabilities, but they have no visibility into system prompts pasted into Confluence, excessive permissions granted to agents, or proprietary configurations pasted into ChatGPT for debugging.

Securing AI development means protecting sensitive data and configurations everywhere developers actually work: repos, wikis, issue trackers, artifact registries, and AI assistants, not just source code.

Securing AI through data-first architecture with Varonis

Every one of those insights, from a leaked credential in a repo an overprivileged agent in production, feeds into the same data security posture management (DSPM) functions your team already relies on through Varonis DSP. AI risk doesn't sit in a separate silo; it shows up alongside the rest of your sensitive data risk, with the same automated remediation and reporting you get across the platform.

Varonis Atlas: built to disrupt AI security

Atlas represents Varonis' next evolution in data security, designed to address the complexity of AI-driven environments end to end. It provides:

Unified visibility across AI data flows, from development through production.
Context-aware risk detection that understands how sensitive data, credentials, and permissions move through AI systems.
AI security testing, including AI pen testing that proactively stress-tests systems for vulnerabilities like prompt injection and jailbreaks.
Real-time runtime guardrails through an AI Gateway that inspects prompts, responses, and agent actions before they reach the model.
Automated enforcement and integration with the broader Varonis platform.

Across the board, Varonis gives security teams a single place to answer the questions that matter: What sensitive data sits in the repos where an AI system was built? What credentials are embedded in the images running AI agents? What data have developers shared with external AI assistants? Who can access the documentation describing an agent's permission scopes? If those questions can't be answered today, the underlying AI systems most likely carry baked-in vulnerabilities.

AI is transforming how organizations build and operate, and security has to evolve just as quickly. Varonis is committed to leading that shift with Atlas, and to continuing to innovate at the intersection of data, AI, and security.

Gartner, Emerging Market Quadrant for AI Application Security — Established Vendors, Meghan Hollis, Dionisio Zumerle, Dennis Xu, Marissa Schmidt, 14 September 2026.

Gartner and Magic Quadrant are trademarks of Gartner, Inc. and/or its affiliates.

Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.

Teaching a Machine to Think Like an Incident Responder

Liav Alter — Fri, 18 Sep 2026 14:31:18 GMT

Key takeaways

The Varonis Triage Agent investigates alerts like an incident responder, forming hypotheses, gathering evidence, and testing benign explanations.
In one case, the agent connected three separate alerts — invisible to rule-based scoring alone — into a single incident spanning over 17,000 file downloads, giving Varonis MDDR a complete picture from the start.
In production, the agent has improved analyst efficiency while maintaining a recall rate above 96% on confirmed threats.

Every security incident starts as a story: a suspicious login, a user accessing sensitive data, or a weak signal buried inside thousands of noisy alerts. In today’s SOC, that story is hidden at an almost impossible scale considering the tens of thousands of alerts a team handles. Once an attacker gains a foothold, every minute matters because they can move laterally, expand access, and widen the blast radius before an analyst reaches the case.

This pressure is driving the growth of AI SOC systems designed to perform meaningful investigative work before a human analyst opens the case. And it’s the challenge guiding the Triage Agent: an autonomous AI agent Varonis built to investigate end-to-end alerts, surface the cases that matter most, and give analysts the context they need to act quickly.

Varonis Managed Data Detection & Response (MDDR) analysts have spent years refining that process — investigating, ruling out false leads, and escalating real threats for customers around the clock. The Triage Agent didn't replace that expertise; instead, it was built to encode it, so the same investigative reasoning can begin the moment an alert fires.

For Varonis, triage is about understanding the data through context: What sensitive information was accessed, by whom, whether the access was appropriate, and whether the activity represents normal work, insider misuse, or malicious exfiltration. This crucial information turns an alert into an actionable security decision.

Why we built the Varonis Triage Agent

Traditional triage relies on rules, hardcoded automations, and traditional machine-learning systems, all of which are an important foundation. But an agent can go further by selecting which evidence to gather next, adapting as new facts emerge, and connecting related findings into a broader incident.

Our challenge was not simply to rank alerts faster, but to give the agent the same context and adaptability our MDDR analysts already bring to every investigation — and let it apply that thinking before a human ever opens the case.

Varonis’ context advantage

An agent is only as useful as the context it can reason over. In security, context determines meaning. The same action can represent normal work, careless behavior, or an active attack depending on several different factors like the identity involved, the sensitivity of the data, the user’s permissions, their historical behavior, and the surrounding activity.

Varonis already had that context within its Data Security Platform (DSP). The agent could investigate identities, permissions, entitlements, behavioral patterns, sensitive data exposure, and related events instead of reasoning over an isolated alert. We also had a large repository of evidence from past incidents that offered real outcomes against which to evaluate the agent.

In other words, we weren’t teaching the system through abstract security theory alone. We could compare its assessments with years of real investigations, identify where its reasoning failed, and use those failures to improve it. But rich security data was not enough. Before the agent could investigate it, that data had to become consistent and available for querying.

How the agent investigates

Much of the work involved normalizing events from collaboration platforms, email, identity services, networks, and VPNs into a unified schema. This allowed the agent to reason over, for example, “a sensitive file was shared externally” without knowing which system emitted the signal.

The agent also has access to behavioral baselines, including precomputed summaries of how a user typically behaves and which destinations and volumes are expected. This lets it ask, “Is this normal for this user?” without rebuilding the baseline for every alert. A curated catalog explains what each table contains and how to query it.

Handling infinite context

Varonis has an enormous amount of useful context, but useful is not the same as relevant. Loading all available context into the agent for every alert makes the system slower, more expensive, and less accurate because important signals get buried.

To address this, we organized investigations into investigation scenarios, such as data exfiltration, privilege escalation, phishing, and identity attacks. Each scenario identifies the sources, behaviors, and tables most likely to matter, so the agent starts with relevant context and expands only when the evidence calls for it.

This dynamic approach allowed us to match context for more than 300 scenarios without writing tailored instructions for each one. Think of investigation scenarios as providing a focused starting point without turning the investigation into a rigid script.

Forging the mind of an incident responder

Once we had the data, the next challenge was teaching the agent how to investigate. Answering a question is one problem. Working through an open-ended security case is another.

A good incident responder forms an initial hypothesis, gathers evidence, looks for contradictions, and changes direction when the facts do not fit. Each finding influences the next step. That became our design target: not an alert explainer, but an agent that follows the reasoning process of an experienced incident responder.

The central tension we discovered was structure versus flexibility. Too little guidance produced shallow investigations, while too much created the same rigid playbook we were trying to overcome. The agent needed to gather enough evidence, consider alternative explanations, avoid treating every anomaly as malicious, and recognize when reassuring context was not enough to dismiss a real threat.

Building this required close collaboration between security researchers, who contributed investigative methodology and attacker mindsets, and data scientists, who built the orchestration and tool-calling infrastructure. We benchmarked early versions against real outcomes from our MDDR team, evaluating both the verdict and whether the investigation gathered enough evidence to justify it. Those failures became the roadmap.

How we improved the agent

Every run was traced as a step-by-step transcript. Using labeled outcomes, we could test the agent against cases where the answer was already known. Wrong verdicts were especially useful because the trace showed where the reasoning went off course.

The fixes rarely involved changing the model. They involved changing what the agent knew and how it was guided: Sharpening investigative guidance, improving how a table was described, or tightening a prompt so the agent did not jump to certainty too early.

The hard part was restraint. Every mistake invited another instruction, but too many instructions narrowed the agent until it could only follow a predefined path.

The takeaway: A good tip nudges the investigation — it does not script it. For example, the agent repeatedly flagged file downloads as suspicious without checking whether the files belonged to the user. A hard rule such as “access to your own files is benign” would have created a blind spot when an owner shared sensitive files externally. Instead, we added one nudge: “Before treating file activity as suspicious, establish the relationship between the user and the resource.”

The agent began checking ownership routinely, dismissing benign self-access while still escalating genuine exposure based on the evidence.

Another useful technique was comparing two runs on the same alert, one correct and one incorrect. The difference often came down to a single move: one run checked the source of a suspicious burst, while the other assumed it. That fork showed us exactly what to reinforce.

A real investigation, end to end

It began as an alert few analysts would have rushed to open: A sales employee had pulled thousands of sensitive data files in a short window from an unfamiliar external IP. Large downloads can accompany migrations, backups, and quarter-end reporting, and this detection is among the platform’s highest-volume and noisiest. Rule-based and traditional machine-learning scoring placed the alert below the high-priority threshold — the kind of moderate signal that's easy to deprioritize at scale, even for a strong team, when it's sitting in a queue of tens of thousands.

The agent did not treat the download count as the verdict. It selected which evidence to examine, tested benign explanations, and changed direction as new facts emerged. It started with identity: a known employee in a non-technical sales role, not an administrator or service account. That proved nothing on its own, but it made programmatic collection of thousands of financial documents difficult to explain as routine.

Raw events showed that the downloads came from a Node.js client rather than a browser or managed productivity app, indicating scripted collection. The files spanned thousands of locations the user did not own, and many were labeled confidential or highly confidential. The question changed from “Was there a spike?” to “Why is a sales user scripting the collection of sensitive financial material they do not own?”

A 30-day baseline sharpened the contrast. Before that day, the user’s peak activity was only a handful of files. Network intelligence identified the source as an anonymous consumer VPN endpoint hosted in data center infrastructure. No other user in the environment touched it during the window, ruling out shared corporate egress and tying the concealed origin to this account.

No single fact decided the case. Volume can be legitimate work. A new IP can indicate travel. A scripted client can be sanctioned automation. The combination is what mattered, and what allowed the agent to determine, “The combination of automated collection, concealment of origin, and targeting of highly sensitive financial data provides concrete evidence of mass data exfiltration.”

The agent classified the activity as malicious and critical while recording its limitation: authentication telemetry was unavailable, so it could not distinguish between stolen credentials, a hijacked session, or a deliberate insider.

From isolated alerts to connected incidents

The most consequential move came from looking beyond the ticket it was handed. The agent searched 14 days of detections on the same identity for impossible travel, external sharing, and uploads to personal cloud storage. None appeared. What did appear were two more alerts for the same download rule on the same day: an earlier burst of roughly 440 files and a later one of more than 11,500.

Together, the three windows totaled more than 17,000 downloads. A moderate spike below the priority threshold was one phase of sustained extraction escalating throughout the day.

The agent did not simply group alerts by user. It tested related attack behaviors, distinguished absent signals from contradictory evidence, and assembled the matching activity into a single timeline. This adaptive investigation and incident reconstruction, rather than any single indicator, was the agentic advantage.

The MDDR analyst opened the case with all of that evidence already gathered, confirmed the volume and consumer VPN source, and escalated it for customer action. The final disposition was a true-positive malicious external threat. The human still owned the decision, but instead of three disconnected tickets, they received one reconstructed incident.

What it took to make the agent useful

This was never simply a prompting project. The model, orchestration, tools, and data foundation all mattered. But the system only became useful when those pieces were grounded in the investigative methods of experienced security researchers and tested against real outcomes.

Security researchers identified the questions and relationships a human investigator checks by reflex. Data scientists translated those lessons into tools, context, guidance, and repeatable evaluation workflows. The shared loop between those disciplines, run, inspect, correct, and measure, moved the agent forward.

The result is the Varonis Triage Agent, a product in the emerging AI SOC category that does more than process alerts faster. It begins the investigation earlier, connects evidence across the environment, and gives analysts a richer and more comprehensive starting point.

In production, the agent has improved analyst efficiency, depending on each analyst’s baseline and experience working with it. Moving from machine-learning and playbook-based triage to agentic triage reduced the manual investigation time required before escalation by an average of 16.4 analyst-hours per malicious case.

Production recall is above 96%. Because Varonis MDDR analysts manually review every trace, fewer than 4% of confirmed attacks were not prioritized by the agent. The agent has already investigated dozens of production alerts, and that number continues to grow.

An accurate agent focused on triage also changes the calculus for detection engineering. When every new detection adds to an overwhelming queue, teams often keep rules narrow to avoid flooding analysts with false positives, sacrificing coverage. With a reliable agent absorbing the additional volume, detection engineers can write broader, more sensitive rules while the agent filters noise and surfaces the cases that warrant attention.

Ultimately, the goal is not to replace human judgment. It is to move analysts away from manually gathering context and toward reviewing evidence, making consequential decisions, and containing threats before the damage spreads.

This post was co-authored by Hadas Shalev. Thank you to Oren Tevet, Yonatan Haldarov, and Amit Daniel for their contributions on the topic.

TrustSink: How a Rogue External MFA Provider Steals Passwords

Elad Ghvarh — Wed, 16 Sep 2026 13:00:02 GMT

Varonis Threat Labs identified a credential-phishing technique we call TrustSink. It turns a trusted external authentication provider into a persistent credential trap within a legitimate sign-in flow.

While the technique can work in any provider, we demonstrated TrustSink end-to-end using Microsoft Entra. An attacker with high privileges can register a rogue External Authentication Method (EAM) and place a convincing password page inside the legitimate sign-in flow. The page captures the password in plaintext while the provider returns a valid signed token, completing the login without an error.

In our test tenant, every sign-in completed normally while our server received passwords with timestamps and source IP addresses. Resetting a captured password did not remove the rogue provider. It remained in the authentication flow and captured the replacement password at the user’s next sign-in.

We are sharing this research as a warning to defenders, and to help IT and security teams detect unauthorized changes to authentication infrastructure and remove rogue providers before resetting affected credentials.

TrustSink builds on a trust boundary highlighted by Dirk-jan Mollema in his x33fcon 2025 talk, “Bringing Your Own Identity in Entra ID.” His research showed how a rogue registered EAM provider could be used to bypass MFA by returning a signed JWT without performing a real authentication check.

Our research uses that same trust boundary for a different objective: capturing plaintext passwords. We focus on the provider-controlled page the user sees, which can resemble a Microsoft password prompt and be used to collect the password before the provider completes sign-in with a signed token.

TrustSink is a clever workaround for authentication. If we can’t trust authenticator apps, what can we trust?

Building the rogue provider

We first built the provider by hand: a minimal OpenID Connect (OIDC) server written in Python with FastAPI. It has two jobs that pull in opposite directions.

To the user, it must look exactly like the official Microsoft page.
To Entra, it must look exactly like a compliant EAM provider.

Both of these jobs play out in a single sign-in.

The user enters their real Microsoft password. MFA triggers, and Entra sends their browser to our provider for the second check. From that moment, the two audiences see different things. The user sees a copy of Microsoft’s password page, and whatever they type, our server keeps. Entra sees a signed token claiming the check passed, and the signature validates, so the sign-in completes.

Four endpoints in total carry the loop (two for each audience).

1. The discovery document

This is how Entra learns the provider exists. Its /.well-known/openid-configuration URL is registered in the Authentication Methods Policy and fetched before any user is redirected. Our implementation returns the minimum metadata Entra needs: the issuer, authorization endpoint, JWKS URI, and supported signing algorithm (RS256). If the document is unreachable or invalid, Entra rejects the provider and the user sees an error page.

2. The public key

This is how Entra believes the provider. The /jwks endpoint serves an RSA public key from a self-signed pair we generate at first launch. Entra retrieves this key to validate the tokens the provider returns and caches it, so fetches follow Microsoft's metadata refresh cycle rather than individual sign-ins. Microsoft checks only that the key ID matches and the signature is valid. It does not check the certificate chain or where the key came from.

3. The page the user sees

This is where the trap sits. When MFA triggers, Entra redirects the browser to /eam/authorize and sends along everything we need to answer: an id_token_hint identifying the user, a nonce tying the response to this request, and the callback URI to post back to. Our server replies with a pixel-accurate copy of Microsoft’s own password prompt.

4. The capture

This is where the password lands. When the user submits the form, /eam/complete writes it to a local credentials file with a timestamp and source IP. Then the server builds Microsoft's answer. It takes the user's identifier from the id_token_hint (Microsoft sends it deliberately expired. It takes the user’s identifier from the id_token_hint. Although Microsoft deliberately sends this token expired, our provider still validates its signature, issuer, audience, and relevant claims before using it) and adds the two claims that tell Entra a hardware-key check succeeded: acr: "possessionorinherence" and amr: ["hwk"]. It signs the token with the provider's private key, and an auto-submitting form posts it to Microsoft's callback.

What the user sees

The attack inserts one extra step into a routine the user has run hundreds of times. From their side of the screen, the sign-in looks like this.

They enter their email at login.microsoftonline.com.
They enter their password. This one goes to Microsoft.
MFA is triggered.
The browser lands on what looks like another Microsoft password page.
They enter their password again. This one goes to us.
The page moves on by itself.
They arrive at their application. Sign-in complete, no errors.

The page at step four is a pixel-accurate copy of the real thing. Same fonts, same layout, same blue button.

It also arrives at the one moment a password request makes sense: the user has just typed their real password on Microsoft’s domain, so a second prompt inside the same flow does not raise suspicion the way an emailed link would.

From the user’s perspective, they signed in normally.

From proof of concept to repeatable trap

Disclaimer: This proof of concept is provided strictly for educational and authorized security research purposes to help defenders understand and detect this attack vector. Do not use this tool against any environment without explicit written authorization.

At this point, everything has run successfully in our own tenant. An attacker in the real world would need it to work on every sign-in, for every targeted user, for as long as the provider stays registered. That takes two things: the privileges to register it, and a public address for it.

The privileges are the tricky part. Registering an external method means changing the Authentication Methods Policy, creating an application, a service principal, and a consent grant. Those actions require a Global Administrator or Authentication Policy Administrator account. TrustSink is therefore a post-compromise technique. It begins after an attacker has taken a privileged identity and decides to turn that one account into a standing credential trap.

The address is simpler. Entra fetches the discovery document and signing keys over HTTPS, and the victim's browser is sent to the same place during the redirect, so the provider needs a public URL. In our lab, that was ngrok, a tunneling service that exposes a local server behind a public HTTPS address.

A real attacker would choose something other than ngrok, perhaps a cloud VM behind something like auth-verify.microsoft-sso.com or a VPS with a free certificate. The domain appears in the address bar for a moment during the redirect, and most users never look. A well-chosen one is the difference between blending in and an analyst spotting an unfamiliar issuer in proxy logs.

Manual setup

In order to verify this setup, we ran the deployment through the Entra portal manually because a slow run shows exactly which artifacts the attack creates.

We first ran the FastAPI server locally and exposed it through ngrok, giving it the public HTTPS address (https://trident-sip-filter.ngrok-free.dev) that Entra and the victim's browser would both use.
In App registrations, we created an application named something innocuous (for example, "Security Verification"), scoped to accounts in this organizational directory only, set its Web redirect URI to Microsoft's external authentication callback (https://login.microsoftonline.com/common/federation/externalauthprovider), and enabled ID token issuance under Implicit grant.
We created a Service Principal for the app. This happens automatically when the application is registered in the same tenant. We verified it existed under Enterprise applications.
We added the delegated OpenID and profile permissions and granted admin consent so no consent prompt appears during the redirect.
In the Authentication Methods Policy, we added the provider under a display name chosen to blend in (ours was "User's Password"), entered the application (client) ID of the app registered in step 2, pointed the Discovery URL at https://trident-sip-filter.ngrok-free.dev/eam/.well-known/openid-configuration, and scoped it to a security group holding one test account.
We confirmed a Conditional Access policy required MFA for that group across all cloud apps. The trap was live.
We signed in as the target user. After entering the real password, Entra redirected us to our server, where the fake password prompt caught the second entry. We signed the JWT and posted it back, and the sign-in completed normally.

You can watch the manual deployment here.

Automated deployment

After the manual step, it was clear that the methodology worked, but it took a few minutes of clicking and left too much room for error. As a result, we packaged the same sequence of steps into a Python script (deploy.py) that drives it through Microsoft Graph in just one command:

For authentication, the script tries the Azure CLI first, which avoids creating a new sign-in event, and falls back to device code flow with Azure PowerShell’s client ID, which is pre-consented in most tenants.
It creates the application via POST /v1.0/applications with the correct redirect URI and required openid/profile permissions, then creates the Service Principal via POST /v1.0/servicePrincipals, making the app usable in the tenant.
It grants tenant-wide consent via POST /v1.0/oauth2PermissionGrants, scoped to AllPrincipals for openid and profile, so victims never see a consent prompt.
It registers the external method via POST /beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations, adding the provider to the Authentication Methods Policy scoped to the target group.
It saves everything it created to deploy_state.json, and rolls back automatically if any step fails. A companion script, cleanup_eam.py, reverses a full deployment in order, deleting the EAM config, removing admin consent, deleting the service principal, then the app registration, and only clears the state file once teardown fully succeeds.

You can watch the automated deployment here.

How to detect and mitigate TrustSink

Most stages of a TrustSink deployment leave a trace in the logs. Registering the provider writes the method configuration into the Authentication Methods Policy, and an automated run adds its own trail, creating the application, the service principal, and the consent grant back-to-back through scripted Graph calls.

Five places are worth watching:

1. Authentication Methods Policy changes

Registering the rogue provider wrote three audit events in sequence: the external method added, the user object updated, and the method confirmed as registered. It also appended a FIDO key to the test user’s SearchableDeviceKey property, a side effect we did not trigger deliberately. Any new externalAuthenticationMethodConfiguration entry outside a planned rollout is the clearest early warning.

2. Application registrations

The application we created used Microsoft’s external authentication callback, login.microsoftonline.com/common/federation/externalauthprovider, as its redirect URI, requested openid and profile permissions, and carried a display name chosen to blend in with a sign-in audience limited to the organization. Any application with no clear business purpose registering itself into the authentication path deserves review.

3. Service principals

Registering the application also created a service principal, and its creation event carries the specifics: the app ID, the sign-in audience, the reply URLs pointing at infrastructure the attacker controls (in our test, an ngrok domain, not a Microsoft one), and the key material registered for token signing. A service principal holding credentials for an application you do not recognize is part of the same chain and appears in the same audit window.

4. Sign-in logs

Every sign-in our provider handled recorded its issuer URL, and the claims are where the giveaway lives. A genuine hardware-key prompt produces them after a real ceremony. Ours were hardcoded as acr: "possessionorinherence" and amr: ["hwk"]. The record shows the first factor satisfied by token claims and the MFA requirement satisfied by the external provider. An unfamiliar issuer carrying hwk is the most reliable signal, because the provider cannot avoid leaving it.

5. Automated tooling

Our deployment tool stamped every Graph call with python-requests/2.33.1, and the events Add application, Add service principal, and Add delegated permission grant fired within seconds of each other. Real administrative work comes from the Azure portal or PowerShell, at human pace. The header is trivial to change, so treat it as a lead, not a signature.

Mitigation

Resetting the password doesn't work with TrustSink. The old credential dies, but the provider is still live, so it harvests the replacement on the next sign-in. You have to remove the provider, not only rotate the credential.

Area	Action
Provider	Disable the external method in the Authentication Methods Policy and remove its group assignments before any password reset
Application artifacts	Remove the app registration, the service principal, the signing keys, the openid and profile consent grant, and the callback redirect URI
Accounts	Use the sign-in logs to identify every user who authenticated through the provider, reset their credentials, and review what those accounts did afterward
Conditional Access	Alert on policies modified to target new groups, and review any policy edited after a suspicious registration
Authentication methods	Move users to FIDO2 or Windows Hello for Business, so a password prompt during MFA reads as suspicious
Privileged access	Restrict standing Global Administrator and Authentication Policy Administrator roles, the two roles that can alter this path

The bottom line

The TrustSink technique exists because Entra trusts a signed token from a registered EAM without verifying what the provider shows the user.

Microsoft hands a third party the one screen every user trusts, and never checks what that party shows or returns. Controlling what the user sees, combined with automatic validation of whatever comes back, is all that was needed. The result was a credential-capture mechanism that operated within normal sign-ins.

That mechanism has a cost on both sides. The entry cost is high because an attacker needs a privileged account before any of this works. What they get in return is a standing trap that captures plaintext passwords in real time and stays in place when those passwords are reset.

For a red team, that is persistence worth having. For a blue team, it is one more reason to watch identity infrastructure changes as closely as the sign-ins themselves.

Introducing Varonis Data Lifecycle Management

efeldman@varonis.com (Eugene Feldman) — Tue, 15 Sep 2026 12:55:00 GMT

Varonis Data Lifecycle Management (DLM) is a new capability that automatically finds and quarantines redundant, obsolete, and trivial (ROT) data across your entire data estate. Cut storage costs, improve AI outputs, and reduce risk, effortlessly.

ROT: The data you should not have

For the average enterprise, data volumes grow by 30% to 40% each year, and that growth is accelerating due to AI. Every modern business is creating mountains of data, but few have an automated way to remove data when it’s no longer useful.

As a result, at least 30% of enterprise data is ROT, which leads to problems such as:

Wasted storage costs: Industry estimates put storage costs at more than $650,000 per petabyte a year, before backup and replication, meaning you spend almost $200,000 per petabyte per year storing data that shouldn't exist.

Degraded AI quality: AI processes and analyzes all the data it can access, including ROT. That means data that shouldn't exist gets to shape your AI's actions and responses.

Elevated risk: Sensitive ROT data scattered across shares, drives, and forgotten data stores widens the blast radius of a breach. Data kept past its retention window can lead to fines under GDPR, CCPA, HIPAA, and other regulations.

Varonis Data Lifecycle Management: The power of automation

With Varonis DLM, you can automatically find ROT across every data source, as well as enforce governance, retention, and residency policies. DLM is built on the Varonis Data Security Platform (DSP), which already helps thousands of customers understand and control their data.

Varonis DLM also shows you which data should and shouldn't exist across your data estate. Since the context around sensitivity, permissions, and activity already lives in Varonis, the platform not only finds ROT but also acts on it.

Legacy lifecycle tools find data that might be ROT and then rely on data owners to manually review lists of hundreds or thousands of deletion candidates, one record at a time. Only Varonis knows what's stale, overexposed, duplicated, or past its retention window, and quarantines it automatically.

Unified ROT visibility

One dashboard shows the full scope of ROT data across every connected platform. View total ROT volume, duplicate clusters, stale files and folders and data past its retention window. Filter by platform, classification category, sensitivity, data source, file type or owner.

Prioritize ROT based on potential cost savings and risk: See what's driving storage spend and exposure, so you can prioritize cleanup efforts and keep track of progress.

Surface ROT hiding in plain sight: Aggregated visibility flags stale and aged data even when hidden inside active folders.

Full data context

Knowing how much ROT you have is important, but it’s not enough to know what to do about it. Varonis DLM adds the context you need to make informed decisions. For example, you can drill into any duplicate group and see which copy is the original, which is most recent, where copies are across different platforms, and whether they are sensitive, overexposed, or past retention.

Detect every duplicate, not just the readable ones: Find the duplicates and ROT that classification can’t read, such as media files, installers, DLLs, and archives.

Act based on the full lifecycle of data: Varonis tracks how long each data record has gone untouched and how old it is, so you know exactly what's safe to remove.

Complete lifecycle automation

Out-of-the-box policies govern duplicates, staleness, and retention, all fully configurable to your scope and logic. When data violates a policy, Varonis automatically moves it to a secure quarantine. The automation is fully reversible, and Varonis deletes nothing until you're sure.

Turn classification into enforcement: Don’t just label expired data — act on it. Retention policies map classification categories to legal windows, like financial and PCI over seven years old, PII and GDPR over two years old, PHI over six years old, and education data over five years old.
Remediate without risk: Quarantine the duplicates you don't need and choose which copy to keep, such as the original or the most recent. Every action is reversible, so cleanup never breaks something you need.

A security project that pays for itself

Most security spending is insurance you pay for and hope you'll never need. Varonis DLM is the exception: Not only does it deliver security and compliance outcomes, but it also cuts storage and backup costs. Varonis DLM is powerful because it's built on the Varonis DSP, so every lifecycle decision is driven by AI classification, complete permissions mapping, and full activity history on every data record, all correlated in real time across your whole environment.

The combination of classification, permissions, and activity is what allows Varonis to know "this is stale, overexposed, duplicate, past its retention," rather than "this might be ROT." Varonis automated remediation capabilities automatically quarantine ROT rather than having to rely on data owners for cleanup. Other solutions may be able to classify data, but only Varonis has the context to act on it automatically, safely, and at scale.

Schedule a free Varonis Data Risk Assessment to see how much ROT is hiding in your environment and find out exactly how much you could save.

Varonis Achieves Snowflake Premier Partner Tier and Is Now Available on Snowflake Marketplace

Nolan Necoechea — Tue, 01 Sep 2026 12:45:00 GMT

We're excited to share two milestones in our growing relationship with Snowflake. Varonis has achieved  Premier Partner  status in the Snowflake Partner Network and is now available on the  Snowflake Marketplace.  

AI agents, copilots, and LLMs now read, write, and act on data flowing through data lakes, warehouses, and everywhere in between at machine speed. Varonis helps enterprises secure Snowflake environments so they can innovate fast with confidence. 

Varonis integrates with Snowflake to continuously analyze data sensitivity, who can access sensitive data, and how data is being used. With Varonis, organizations can confidently use Snowflake for analytics, collaboration, and AI while maintaining security and compliance controls. 

Varonis and Snowflake are more connected than ever, helping customers secure the data and AI that power their business. 

What’s new with Varonis for Snowflake

Premier Partner Tier. Reaching Premier Partner status is further validation of Varonis' deep integration with Snowflake and enhances our ability to collaborate with Snowflake's teams on joint customer outcomes, co-selling, and roadmap alignment.

Varonis on the Snowflake Marketplace. Snowflake customers can now find Varonis directly on the Snowflake Marketplace and apply a portion of their committed capacity to Varonis via the Snowflake Marketplace Capacity Drawdown (MCD) program.

Why customers turn to Varonis to secure Snowflake

Organizations adopt Snowflake to accelerate their data and AI initiatives. Rather than stitching together separate systems for storage, warehousing, and analytics, teams can consolidate and spend less time on infrastructure and more time analyzing data, collaborating, and building AI applications and agents.

Security is important, but it must be balanced with the speed and flexibility that they adopted Snowflake for in the first place.

Customers adopt Varonis for Snowflake for the visibility and guardrails needed to move fast while staying secure, and map Snowflake permissions to clearly understand what data exists, who can access it, and how it is used.

That's exactly why customers like Webster Bank use Varonis to secure Snowflake:

Varonis and Snowflake: Better together

Varonis makes it easy to secure Snowflake environments without slowing innovation. Varonis provides the visibility and control security teams need to know where sensitive data lives, ensure access matches actual need, and catch misuse before it becomes a breach.

Automatically discover and classify sensitive data. Varonis discovers and classifies sensitive data across every Snowflake database, schema, table, and column to pinpoint PII, PHI, financial data, and more.

Map effective permissions for every user. Varonis cuts through nested role inheritance to show exactly who can reach what, and right-sizes access automatically.

Detect and stop threat. Varonis builds behavioral baselines for every user and system and monitors the access patterns that indicate risk. From a compromised account to an insider threat to an AI system reaching data it shouldn't, Varonis provides real-time, contextual alerts, rather than noise.

A stronger foundation for what's next

It's now faster and easier than ever to secure your Snowflake environment with Varonis and start gaining visibility and control without slowing down data and AI initiatives.

If you're running sensitive data in Snowflake, there's no better time to see where you stand. Varonis offers a free Snowflake Data Risk Assessment that shows you, within 24 hours, where your sensitive data lives, who can access it, and what's putting it at risk.

SIEM Is Not Enough: Why You Need DAM for Your Databases

efeldman@varonis.com (Eugene Feldman) — Mon, 31 Aug 2026 16:35:29 GMT

Database security has followed the same playbook for years. Pick your ten or twenty most critical databases, deploy Imperva or Guardium on them, and take the eighteen-month, seven-figure hit. For the other several hundred databases, turn on native audit, ship the logs to your SIEM, and call it monitoring.

That playbook made sense when Database Activity Monitoring (DAM) was hard, when the only databases anyone bothered to protect were the ones facing regulatory scrutiny, and when the riskiest users hitting them were humans.

None of those assumptions hold anymore, and security professionals are exhausted by the burdens and costs of Guardium and Imperva deployments. The "ship it to Splunk" part of the playbook (the part covering most databases) was never database security. It was compliance theater with a receipt. And now it's not a handful of human users hitting those databases, it's hundreds or thousands of autonomous agents, and a pile of logs in your SIEM does not secure any of it.

Varonis Next-Gen DAM brings every database into our unified Data Security Platform through native audit collection. All you need to do is point the logs your databases generated to Varonis and you get real findings instead of raw events piling up in your SIEM.

What "ship it to SIEM" actually delivers

Talk to any team pushing native database logs into a SIEM today, and the picture is the same:

The bill is enormous: Raw audit volume is massive, and SIEM ingest is priced by the gigabyte. No matter which SIEM you use, this quietly becomes the most expensive piece of database monitoring infrastructure your organization owns, and none of this money is buying security.
The alerts mean nothing: The SIEM has no idea which tables contain regulated data or the difference between a Select and a Show in SQL. Every event looks the same. Writing rules to find the activities that matter requires deep database knowledge the SOC does not have. Most teams give up and don't write the rules at all.
The audit report is still a manual process: Quarterly, someone runs custom queries against the log store, hand-formats the output, and prays the auditor accepts it. It does nothing to reduce risk or secure data.

Meanwhile, the databases under an agent-based DAM tool are stuck in their own trap. Agent deployments take years, cover a fraction of the estate, and drown teams in undifferentiated alerts. The people who built that category will tell you so themselves.

Ron Bennatan, VP of Strategy at Varonis, explains: "We built agent-based DAM in an era with real hardware constraints and a real need for inline controls like blocking, dynamic masking, and connection throttling. The hardware constraints have been closed for years with cloud and modern storage, and inline controls are now primarily needed for AI agents. Databases now need high-fidelity detection and a way to make sure AI agents don't cause unintended consequences. The interesting problem now is how you turn millions of activity records into a small number of findings that actually mean something and how you understand agent intent."

Prior to joining Varonis, Ron spent 25 years building agent-based DAM as co-founder of Guardium (acquired by IBM) and jSonar (acquired by Imperva). Native audit overhead on modern databases is now measured well under five percent on par with agent-based collection.

The industry ended up with two failed modes running in parallel: (1) legacy DAM monitors a small subset of databases at enormous cost, and (2) SIEMs cover the rest, but don’t provide any security.

Why the combination of legacy DAM + SIEM stopped working

The legacy DAM-SIEM compromise assumed the databases not covered by DAM weren't worth the effort. That assumption dies the moment an AI agent starts querying them.

Consider a customer support agent built on an internal LLM:

A user asks it a question

The model decides it needs three rows from a customer database

The MCP server runs the query under a shared service account
The native log records: svc_ai_support read 3 rows from customers.payment_methods at 14:02

Multiply that by ten thousand queries a day across a dozen AI workflows, and you have a feed that is both massive and useless. The human who triggered the request is invisible. The service account is doing things it wouldn't have been doing six months ago.

The SIEM has no context into the sensitivity of the data being accessed. Without that context, the SIEM has no way to tell whether any of this activity is normal. Multiply that by 100 or 1,000 agents, each capable of taking autonomous actions, prone to unintended behavior, or even going full "rogue," and now every database is at risk and not just the ten earmarked for legacy DAM coverage.

Secure every database with Varonis Next-Gen DAM

For years, the reason security teams didn't monitor every database was because monitoring every database was hard and came with a lot of overhead. Varonis Next-Gen DAM changes the math with two collection methods that share one SaaS platform:

Native Audit Collection for the vast majority of your databases. All you need to do is point the built-in audit streams that ship with SQL Server, Oracle, PostgreSQL, MySQL, Snowflake, Databricks, Amazon RDS, and every other major engine at a Varonis collector. Nothing to install on the database host, no agents, inline devices, or DBA tickets.

The Varonis Gatekeeper for the smaller set of hypercritical databases where you need inline enforcement like blocking, dynamic masking, and legacy database version support. This is the workload that used to justify agents in the first place.

Both feed the same SaaS platform. Which means every database, the ten critical ones and the several hundred that used to live in Splunk purgatory, get the same security treatment.

What Varonis Next-Gen DAM delivers

A log entry becomes a finding when the platform processing it knows three things: whether the data being touched is sensitive, whether the user should have access to it, and whether the behavior is normal for them.

Take a 2 a.m. SELECT against a customer table. To a SIEM ingesting raw audit, it is one event out of millions. To Varonis, three things happen in parallel:

The classification engine already knows the destination table holds PII, down to the column.

The identity graph resolves the database account back to a real corporate identity through Active Directory or Entra.

Then, by leveraging User Entity Behavior Analytics (UEBA), Varonis shows that this user has never touched this table or column and rarely works after hours.

The result is a clear alert that something is wrong: this account just read regulated data it has never touched before, off-hours, from a new endpoint.

Apply the same three-way intersection to the AI agent example above. Classification knows customers.payment_methods is PCI scope. The identity layer traces svc_ai_support back to the originating workflow and, ultimately, the user prompt. Behavior modeling knows whether this agent has any business hitting this table at this volume. The log becomes a finding the same way it does for a human user.

That is the difference between shipping logs somewhere for a report and securing databases.

Why DAM is easier than you think

Now, you can easily extend DAM to every database in your estate. The same database logs you've shipped to Splunk for years can now point at Varonis instead. Same stream, same effort, but now you get specific findings with complete data classification and identity resolution rather than a per-gigabyte bill for events that nobody reads.

Run a free Varonis Data Risk Assessment to get started. Bring in any combination of databases (SQL Server, Oracle, PostgreSQL, MySQL, RDS, Snowflake, Databricks, and more) alongside your unstructured data in OneDrive, SharePoint, Google Workspace, Box, Salesforce, NAS, and the rest. One classification model, one identity graph, one set of findings.

What you get:

A complete map of where sensitive data lives across every database and every file store, with exposure and access risk quantified

Identity mapping that resolves database accounts back to real corporate identities through Active Directory and Entra

Live activity alerts surfaced by Varonis UEBA, watched 24x7x365 by an MDDR analyst for the length of the assessment

An executive-ready report with a prioritized remediation path, yours to keep whether you become a customer or not

Setup takes less than an hour, with findings showing up within 24 hours.