Varonis Blog

Why AI Agents Are Making Database Activity Monitoring Critical Again

Manav Mital — Fri, 29 May 2026 01:17:44 GMT

Database security and AI security are converging. Neither can function effectively in isolation. A modern solution requires combining execution‑level truth from DAM with intent, actor, and task context from AI‑aware security platforms.

Agents change how databases are used

Database security has historically been built on two key assumptions:

Human DBAs and operators execute most administrative actions
Workloads have clear temporal boundaries (sessions, jobs, change windows)

These assumptions held because monitoring who did what was usually enough to explain why the action was taken. Database Activity Monitoring (DAM) became the cornerstone of the database security stack. More sophisticated enterprises went one step further, incorporating workflows to tie actions against a database to a user (monitored by DAM) with change request tickets filed against those users.

DAM defined how teams think of identity, which is often the cornerstone of security policy management. In traditional enterprises, identity resolution was largely local and sufficient. A database user or service account could usually be traced directly to a human operator, a team, or a well-defined automation. When intent was unclear, it could usually be recovered out-of-band by asking the operator or correlating the action with a change request.

In the agentic era, identity is no longer flat or proximal. DBAs are increasingly replaced by agentic harnesses and autonomous service operators acting on behalf of enterprise users, and temporal boundaries become ambiguous, with database actions being enveloped inside agentic workflows that are themselves long-lived, event-driven, and recursive. Database actions are executed through layers of delegated identities — originating from a human prompter, mediated by applications or agents, executed via MCP servers, and finally mapped onto database roles. Each hop attenuates accountability and strips away context unless it is explicitly carried forward.

The outcome? Agents dramatically shifts the security model for databases, which are based on user identity, access modalities, and intent.

Standalone DAM is no longer sufficient

Traditional DAM products needed to answer one question: “What happened in the database?”

While superficially simple, answering this question proved complex, requiring the audit of a highly critical, sprawling, and performance-sensitive component of an enterprise’s tech stack. DAM tools were built to observe and stitch together artifacts like SQL statements, connection properties, and metadata to provide a meaningful context for security teams, while ensuring there was no performance or deployment overhead for the database and infrastructure teams to worry about.

But in an agentic system, figuring out what happened is not the hardest problem to solve.

In an agentic system, the client issuing the command itself has no intrinsic understanding or context for why an action is being taken, whether the side effects are intended and if the results are acceptable. In such a setup, a conventional DAM produces accurate but context‑free reporting. This creates the dangerous illusion of perfect visibility without interpretability.

Moreover, when DBAs do the work, we trust them from a performance lens and verify them from a security lens — exactly what DAM is all about. When it is an AI agent, we cannot blindly trust it. AI agents are not accountable to anyone. You can’t fire them. They can be confused. They can hallucinate. Therefore, it’s not enough to just “put a camera” and warn them. They don’t care. In the human world, DAM is for the most part a “deterrent control” — don’t do anything bad because we’re watching you.

This hands-off trust mentality must be replaced in an agentic world with real controls. Partly because agents cannot be fired and have no accountability and, more importantly, because agents can still do a lot of damage if given the keys to the kingdom.

Identity collapse compounds the problem. From the database perspective, vastly different actions (initiated by different users, applications, or agent workflows) can appear indistinguishable when they are executed through the same delegated roles or service accounts. DAM faithfully records the execution identity, but that identity is often no longer the authority that made the decision. Therefore DAM must evolve into higher-value controls as well as controls that live in the agentic guardrails layer.

Signals are moving upstream, but the truth remains downstream

The agentic era shifts security questions from “What ran?” to “Should this have happened, in this context?”

Having recognized the limitations, much of the industry is shifting security upstream into the agentic layer. Moreover, the controls must shift from RBAC to Intent-Based Access Control (IBAC). It’s no longer a question of, “Is what was done allowed?” but rather “Is what was done justified and correct?”

We want AI agents to be autonomous — we want to reap these benefits, but we also want to ensure we don’t get burned.

AI security platforms now reason for prompts, agents plan and use runtime guardrails to prevent undesirable, and sometimes unintended, consequences of using LLMs. While always necessary, this is often not sufficient with databases. Databases operate with their own query languages, RBAC, and execution logic, thereby creating a structural tension between upstream layers that understand intent but not execution, and downstream systems that execute but do not understand intent.

In parallel, identity information is also moving upstream. The database no longer sees the user who requested the action, but rather it sees the agent or tool delegated to act on the user’s behalf. Resolving who is responsible, therefore, requires stitching together multiple identities across the agent layer, tooling infrastructure, and database execution context.

Why prompt-layer guardrails can’t catch database side effects

Consider a developer building a new app tasking an agent with a directive to “Apply a schema migration to support feature X.”

At the agent layer, the task appears narrow (a handful of DDLs are involved) and legitimate. However, in the database, the migration may touch shared tables that the agent can access due to its overall responsibilities. Additionally, the agent may be subtly overeager to perform certain tasks, like dropping an index to make the migration run faster.

It may even make an honest mistake, like creating new roles and grants that persist after the task ends and become backdoors into the database. Reasoning these problems at the prompt layer is extremely difficult because it entails not only the commands and grammar, but also the target state. The database remains the final execution boundary. It is the only place where one can observe what actually ran, what data and identities were affected, and what state persisted after the task is completed.

These challenges are more benign when AI services operate on files, such as documents, source code, knowledge bases, etc. In these domains, AI risk often takes the form of exposure, corruption and leakage. Databases are different. Actions mutate authoritative, system‑of‑record state, side effects are often durable and impact system behavior, and mistakes are persistent and compounding.

The agent layer understands intent but not effect. The database understands effect but not intent. Neither alone can safely govern the system.

The only viable option: combining DAM and AI Security

An effective security solution closes the loop between intent and execution by combining two complementary capabilities:

Execution truth, provided by DAM
What commands ran
What objects, identities, and privileges were affected
An immutable record of reality
Context and intent, provided by AI security
Actor classification (human, agent, pipeline)
Task intent
Expected scope and boundaries

Together, they enable real security inspection:

Did execution match intent?
Did effects exceed task scope?
Did transient intent lead to a durable state?

In the schema migration scenario, the AI security layer captures the request's intent and the user's identity, passing them along to the DAM layer as the request flows to the database. The DAM service can then detect if the tables being modified are in scope for the user or if persistent grants have been made.

TL;DR

Monitoring without context is running blind, and context without control is toothless. In the agentic world, database security must reason across intent and execution.

Curious how your security stack measures up? See Varonis Next-Generation DAM in action.

What is AI Security Posture Management (AI-SPM)?

Shawn Hays — Tue, 26 May 2026 16:06:11 GMT

From forecasts to watches and warnings...Meteorologists do not issue warnings for every cloud they see. They issue them when a meaningful set of conditions crosses a threshold and signals a credible chance of impact. Most organizations now accept a basic truth about AI security: you can’t protect what you can’t see.

That realization has driven a wave of investment in AI inventory and visibility to discover where AI exists, how it’s being used, and what systems and components enable it. But visibility alone doesn’t reduce risk. Native solutions are also rolling out to provide visibility while adding a single vector of risk analysis, primarily through misconfigurations.

That’s where dedicated AI Security Posture Management (AI-SPM) comes in.

AI‑SPM is the discipline that turns AI visibility into action. It continuously assesses AI systems for multiple conditions (not just one) that create security, compliance, and operational risk, and helps teams fix those issues before they turn into incidents.

Weather or whether you need AI-SPM

Modern weather forecasting isn’t about looking out the window.

It’s about instrumentation — radar, satellites, atmospheric models, and early‑warning systems. Meteorologists don’t prevent storms, but they prevent surprises. They track conditions long before a storm forms, model how those conditions evolve, and issue watches and warnings while there’s still time to act.

AI security is a similar discipline.

AI inventory and visibility are the radar and satellites of AI security. They answer foundational questions:

What AI systems exist?
What models, pipelines, and agents are in use?
Where does data flow in and out of AI systems?

AI‑SPM builds on that foundation by asking a harder question: Given what we’ve discovered, what is most likely to go wrong next?

Seeing a storm on radar doesn’t tell you whether it will strengthen, where it will land, or how severe the impact will be. For that, you need forecasting, turning raw visibility into risk signals, and risk signals into prioritized action.

Risk signals could include several vectors:

Known vulnerabilities in AI code and models
Misconfigurations in AI‑supporting cloud infrastructure or endpoints
Sensitive data embedded in AI development artifacts
Potentially poisoned tools
Misaligned behavior from MCP servers

These aren’t theoretical threats. They’re the AI‑specific equivalents of atmospheric instability— conditions that may look benign in isolation, but dangerous in combination.

How AI‑SPM differs from DSPM and CSPM

AI‑SPM can often be misapplied as a label to existing posture management solutions, but the distinction matters.

Data Security Posture Management (DSPM) mostly focuses on data: where sensitive data lives, how it’s classified, and who can access it. AI‑SPM overlaps with DSPM when sensitive data appears inside AI assets. But AI systems don’t just store data; they reason over it, retrieve it, and generate new data. That creates exposure paths DSPM alone can’t remediate.

Cloud Security Posture Management (CSPM) focuses on cloud infrastructure: identity, networking, storage access, and baseline configuration. AI‑SPM includes those checks, but extends posture management into areas CSPM wasn’t designed for, such as AI code dependencies, model artifacts, inference endpoints, and agent toolchains.

In weather terms, AI‑SPM models the entire storm system and weather patterns.

Why AI‑SPM matters to governance and regulation

AI‑SPM isn’t just a security best practice. It’s becoming a governance requirement.

Frameworks like ISO/IEC 42001 emphasize lifecycle‑based AI risk management. That assumes organizations can continuously identify and mitigate technical risk, not just write policies about it.

The NIST AI Risk Management Framework depends on posture management for its Measure and Manage functions. You cannot measure AI risk, or manage it meaningfully, without ongoing assessment of vulnerabilities, misconfigurations, and unsafe behavior.

And under the EU AI Act, posture becomes enforceable. High‑risk AI systems must demonstrate cybersecurity resilience, logging, and protection against exploitation. AI‑SPM provides the evidence that those controls actually exist in practice.

What AI‑SPM applies to

One of the most common misconceptions about AI security is that it’s “just about the model.”

In reality, AI systems are composed of multiple components, and therefore, effective AI‑SPM must span four layers:

AI applications: Chatbots, copilots, agents, and embedded applications.
Models and inference endpoints: Commercial, open‑source, fine‑tuned models, and hosted APIs.
Agentic components and tools: Agents and MCP servers, the tools they can invoke, and orchestration frameworks.
Data, code, and supporting infrastructure: Datasets, notebooks, pipelines, storage, credentials, and cloud services.

If a component influences AI behavior, it contributes to AI risk and falls within the scope of posture management.

The risks AI‑SPM is designed to catch

AI‑SPM solutions should look for both individual vulnerabilities and patterns.

AI‑SPM solutions should be able to identify how seemingly isolated issues combine into meaningful risk. For example, outdated dependencies paired with permissive cloud identities can expand an attacker’s path to exploitation.

Sensitive data embedded in notebooks that feed retrieval pipelines can expose information in ways teams may not immediately recognize. And agents with access to tools beyond their intended purpose can introduce misuse or unintended actions.

On their own, these issues may appear low severity, but together they create the conditions for high‑impact failures.

That is why AI‑SPM surfaces findings across categories such as CVEs, misconfigurations, data exposure, model integrity issues, endpoint vulnerabilities, and agentic threats, then connects those findings back to the systems they affect. The goal is not just to enumerate problems, but to help teams understand which combinations of risk matter most and where action is needed first.

Then, AI-SPM solutions need to take action. Varonis Atlas gives security teams the ability to execute remediation from the platform or provides instructions and guidance if teams want to execute changes within the specific environment impacted.

From forecasts to watches and warnings

Meteorologists do not issue warnings for every cloud they see. They issue them when a meaningful set of conditions crosses a threshold and signals a credible chance of impact.

AI‑SPM brings that same discipline to AI security by helping teams distinguish between background noise and the combinations of conditions that warrant attention. It turns inventory into insight, visibility into prioritization, and risk into action while there is still time to respond.

As AI systems become more autonomous, more interconnected, and more regulated, AI‑SPM is no longer optional for complete AI security platforms. It’s the mechanism that turns AI security from reactive cleanup into proactive risk management.

Radar tells you what exists.
Forecasting tells you what’s coming.

Meteorologists take action based on the information.

AI Security Posture Management does all the above — and that’s why it matters.

How Enverus Secures Salesforce Data and Prevents Data Breaches with Varonis

Nolan Necoechea — Fri, 22 May 2026 15:21:28 GMT

As Enverus expanded, its security team needed visibility into the entire data estate, the controls in place, and whether those controls were being enforced, especially within Salesforce, one of its most business-critical platforms.

Enverus partnered with Varonis to gain deep visibility into sensitive data, access, permissions, and activity. Our partnership strengthened security, accelerated investigations, improved threat detection, and helped prevent a major data breach tied to a large-scale SaaS supply chain attack.

Who is Enverus?

Enverus is a decision-support platform serving organizations across the energy and energy infrastructure space, from small independent operators to the world’s largest supermajors. The company manages large volumes of data spanning geophysical, petrophysical, operational, and infrastructure workloads, combining proprietary intellectual property with large public and third-party datasets.

Visibility across a distributed data estate

With data spread across cloud platforms, SaaS applications, and on-premises data centers and databases, each with its own permissions model, configurations, and operational team, Enverus needed consistent data security across its entire environment.

The security team needed to answer fundamental questions:

What sensitive data exists across the enterprise?
Where does it live?
Who can access it?
Are controls consistently enforced across environments?

A unified platform and security partner

Varonis provided Enverus with unified data security across multiple platforms, including AWS, Azure, Salesforce, and Microsoft 365. Varonis gives the security team a comprehensive view of what sensitive data exists, where it lives, who can access it, and whether controls are consistently enforced.

Varonis mapped identities across platforms and greatly reduced the blast radius. What had previously been difficult to operationalize became straightforward: identify the highest-risk access, right-size permissions, and report progress against enterprise policy. Enverus was able to move beyond static reviews and spreadsheet-driven analysis.

At Enverus, the security and GRC teams define enterprise-wide security and data policies, while application teams own day‑to‑day platform operations. Varonis helps bridge these teams, providing dashboards and reporting, aligning platform controls to enterprise policy, and delivering consistent controls and visibility. The result is a unified approach that supports both security requirements and business objectives.

Simplifying Salesforce data security

Salesforce sits at the center of Enverus’ operations, with numerous integrations, workflows, and data flows moving in and out of the platform. Salesforce combines business-critical data with complex identity controls and numerous integration points, making data security challenging.

Over time, overlapping profiles, permission sets, roles, sharing rules, and connected apps can accumulate, making it difficult to understand a user’s effective permissions or identify excess access. The challenge is compounded by the multitude of apps, agents, APIs, and sandboxes that can move data in and out of production and often retain long-lived tokens or create backdoors.

Enverus needed:

Complete insight into identity-based permissions within Salesforce
Clear visibility into data flows and workflows
Confidence that access controls were aligned with enterprise security and compliance policies

Without a centralized view, answering these questions required manual analysis and spreadsheet-driven reviews that were difficult to operationalize.

Applying identity security to Salesforce

With Varonis, Enverus began applying identity threat detection and response (ITDR) principles directly to Salesforce and other SaaS platforms.

What had once been complex, static spreadsheet reviews became:

Clear prioritization of high‑risk access
Actionable insights into who and what needed remediation
Simple, repeatable reporting aligned to enterprise policy

This transformation empowered both the security team and Salesforce operators to focus on what mattered most.

Improved Salesforce threat detection

In 2025, Enverus’ security operations team processed hundreds of alerts per day across its environment. Salesforce emerged as a particularly important attack surface due to its scale, connectivity, and data sensitivity.

While most observed activity aligned with legitimate business workflows, a small subset required deeper investigation.

Varonis helped to improve threat detection and reduce the deluge of alerts:

Salesforce‑specific detections and monitoring
Guidance from a dedicated threat research team
New detection strategies that had not previously been on Enverus’ radar

This partnership enabled Enverus to investigate novel activity more effectively, validate behavior, and proactively design new detections to reduce future risk.

“It felt like Salesforce‑specific MDR. We gained a trusted partner with deep Salesforce security expertise that we could lean on as an advisor.”
— Alex Acosta, Vice President of Security, Enverus

Spotlight: Protecting against a large-scale SaaS supply chain attacks

In early 2025, by compromising Salesloft’s GitHub repos, a threat actor known UNC6395 stole the OAuth tokens that allowed Drift, a widely used chatbot owned by Salesloft, to connect to customers' Azure, Salesforce, Google Workspace, and other integrated platforms.

Between August 8 and 18, UNC6395 used those tokens to impersonate the trusted Drift application, bypass MFA, and systematically exfiltrate data from more than 700 organizations including Cloudflare, Zscaler, Palo Alto Networks, and Proofpoint.

For most victims, the attack went unnoticed because OAuth abuse appears as normal API traffic, and attackers deleted query jobs to cover their tracks. The majority of affected organizations only learned of the breach when Salesforce and Salesloft notified them more than two weeks after the attack.

Enverus was the exception. With Varonis deployed across the environment, Enverus detected, contained, and neutralized the attack before it fully materialized:

Step 1: Cross-platform detection. Varonis initially flagged Drift activity in Azure as abnormal since its OAuth token refreshes originated from unusual IP addresses and its API call volumes exceeded Drift's baseline for Enverus. As a result, Varonis issued an alert and started checking Drift activity in other systems.

Step 2: Salesforce telemetry confirms the threat. Salesforce Shield Event Monitoring provided detailed logs that allowed Varonis to identify abnormal activity in Salesforce by the Drift connected app, like logins from suspicious IPs and unusual API queries.

Step 3: Varonis MDDR responds. Varonis correlated the Azure and Salesforce signals, and its Managed Data Detection and Response (MDDR) team engaged alongside Enverus' security operations to immediately take a series of actions to prevent a breach:

Suspended the compromised identity and revoked OAuth tokens
Classified sensitive fields and attachments to assess potential exposure
Removed excess high-risk permissions, including Export Reports and Create Public Links
Remediated overly permissive sharing rules and misconfigured Salesforce Sites

Within two hours, Enverus had full containment and forensic proof that no sensitive data had been exfiltrated.

Looking ahead

Following the success across Enverus’ environment, the team continues to expand its partnership with Varonis. They plan to further build on Salesforce-specific detections, monitoring, and threat prevention strategies while extending visibility and governance across additional platforms.

“Varonis has been highly impactful for us, and it’s something we’re continuing to build on moving forward,” Alex shared.

Varonis Announces Integration with the Claude Compliance API

Nolan Necoechea — Thu, 21 May 2026 17:00:07 GMT

Today, we're announcing an integration with the Claude Compliance API, bringing Claude Enterprise and Claude Platform activity into Varonis' Atlas AI Security Platform.

Organizations across industries rely on Claude Enterprise for day-to-day knowledge work and analysis, and Claude Platform to build, deploy, and operate applications, tools, and AI agents. Varonis Atlas provides the visibility and oversight that enterprises need to adopt AI with confidence.

The Compliance API integration deepens Varonis' support for Claude, enabling security and governance teams to monitor usage, investigate misuse across full sessions, and assess AI-related risk with data context.

Extending visibility and oversight to Claude Enterprise

Claude Enterprise is used across departments, including legal, engineering, marketing, finance, and support for everything from analyzing documents and summarizing research to drafting content and generating code.

Varonis Atlas monitors Claude Enterprise usage, detects potential misuse and threats, and helps ensure compliance.

Continuous AI Monitoring: Continuously monitor conversation content, including chats, uploaded files, and projects for centralized investigations and oversight.

AI Detection and Response: Detect sensitive data exposure, jailbreak attempts, and suspicious prompt patterns as they occur across a session — not as standalone events.

Session-level investigations: View complete Claude chat sessions in chronological order to understand activity, intent, and misuse in full context.

Supporting secure development on Claude Platform

Claude Platform embeds Claude into custom applications, products, and agents — powering AI-driven features such as assistants, workflows, and internal tools.

Varonis Atlas provides visibility into admin, configuration, and resource activity.

AI Observability: Visibility into audit and admin events from Claude Platform stored for investigation.

Real-Time Alerts: Surface risky behavior tied to policy violations and session activity as it happens.

Proactive AI Pen Testing: Stress-test assistants and agents for vulnerabilities such as prompt injection and jailbreaks.

In addition, Varonis Atlas can stress-test assistants and agents for vulnerabilities such as prompt injection and jailbreaks.

Secure AI and the data that powers it  

Varonis Atlas connects AI activity to the underlying data, including permissions, sensitivity, classification, and access. Security teams understand not just what AI systems exist, but what data they can reach and whether that access is safe.

Complete Data Context. Atlas is built on the Varonis Data Security Platform, combining AI security with deep data context — sensitivity, permissions, and access activity. Organizations can discover AI risk, remediate exposures proactively, enforce guardrails, and manage governance at scale.

Complete Coverage. Atlas is designed to cover any AI system you build or run, including hosted AI platforms, custom LLMs, chatbots, MCP, and every major agentic framework.

Complete Lifecycle. Atlas secures AI across the entire lifecycle, from posture management and security testing to runtime protection and governance.

Varonis Atlas is available today. Watch the demo or, with a free trial, get full access to Atlas’ AI inventory, posture management, security testing, runtime guardrails, and compliance reporting functionality. 

How Webster Bank Strengthens Customer Trust and Accelerates Secure AI Adoption with Varonis

Nolan Necoechea — Thu, 21 May 2026 13:00:00 GMT

Webster Bank is a highly regulated financial institution serving a diverse customer base, from first-time account holders to long-standing institutional clients. With more than one million data resources stored in multiple formats across the organization, the bank needed to protect sensitive and regulated data while continuing to innovate, including the adoption of Snowflake and Microsoft Copilot.

Webster Bank partnered with Varonis to gain unified visibility and automated risk reduction across its most critical data stores and applications and to leverage data security as an accelerator for the business.

Data sprawl in a highly regulated industry

Webster Bank manages large volumes of sensitive customer and transactional data across numerous platforms, including Microsoft 365, Salesforce, Snowflake, AWS, and legacy data stores — each with its own permission model and security complexity. As a regulated financial institution, the bank must comply with GLBA, SOX, and the New York DFS, which require provable controls, auditable oversight, and enforcement of least‑privilege access.

At the same time, Webster Bank is modernizing its data and analytics capabilities. Without strong data controls in place, adopting technologies like a cloud data warehouse and AI-powered tools would significantly increase the risk of data overexposure.

Webster Bank’s data security challenges at a glance:

Data sprawl across more than one million shared data resources enterprise-wide.
Stringent regulatory requirements (GLBA, SOX, NYDFS) demanding evidence of access controls, auditing, and least privilege.
The need to innovate quickly and securely, including implementing Snowflake and rolling out Microsoft Copilot at scale without exposing sensitive data or violating policy

Automated data security and compliance at scale

To reduce risk while meeting regulatory requirements, Webster Bank uses Varonis as its centralized data security platform across its most critical environments. Varonis provides unified visibility into sensitive and regulated data. Varonis shows what data exists, where it lives, who can access it, and how it is being used across Microsoft 365, Salesforce, Snowflake, AWS, and Microsoft Copilot.

By combining deep visibility, automation, and audit-ready reporting within a single platform, Varonis enables Webster Bank to treat security as a business enabler, supporting secure growth, faster innovation, and customer trust.

Automated risk reduction and compliance

Varonis automation enables Webster Bank to consistently right-size access and enforce least‑privilege permissions consistently across data stores, even those with vastly different permission structures, such as AWS and Salesforce. With Varonis, Webster Bank automatically reduced data exposure risk to under 1% across more than one million data resources shared throughout the organization.

For compliance, Varonis delivers a detailed audit trail of all data activity, along with ready-made reports for GLBA, SOX, and NYDFS. Security and audit teams can clearly see who accessed what data, when, and how. The audit trail supports continuous compliance, faster audits, and defensible proof of control effectiveness.

Accelerating the business, securely

Importantly for Webster Bank, security is an enabler for the business, not an inhibitor. Security architects work closely with business teams to understand priorities and ensure that protections are built directly into the data sources and tools that help to support innovation.

Snowflake is a key example. Varonis provides the visibility and guardrails Webster Bank needs to move fast while staying secure, unraveling Snowflake’s complex permission model to clearly understand what data exists, who can access it, and how it is used.

As the bank adopts Microsoft Copilot, Varonis ensures sensitive data remains locked down, and permissions are properly right‑sized to prevent unintended exposure. Varonis also monitors AI prompts and provides the evidence regulators require for safe, compliant AI usage.

Outcomes at a glance:

Unified visibility into sensitive and regulated data across Microsoft 365, Salesforce, Snowflake, AWS, and Microsoft Copilot.
Automated risk reduction, enforcing consistent privileges and least‑privilege access while reducing exposure risk to under 1%across more than one million data resources.
Streamlined compliance with detailed audit trails, compliance‑ready reports, and centralized dashboards.
Confident adoption of Snowflake and Microsoft Copilot, with built‑in guardrails and security.

Partners today and into the future

Webster Bank and Varonis have partnered since 2019, building a relationship defined not only by a leading Data Security Platform but also by proactive support teams and close collaboration with Varonis leadership.

Looking ahead, Webster Bank continues to expand its use of the Varonis platform. The bank recently added Varonis Interceptor, an AI‑native email security solution, to strengthen its email defenses. Webster Bank also plans to extend Varonis coverage across additional platforms while leveraging automation and analytics to scale secure AI adoption and support continued growth and acquisitions.

“There aren’t many solutions that deliver Varonis’ breadth and depth at this performance level— and with a team that’s truly a partner,” said Patricia.

Ready to get the Varonis? Book a demo today.

Hear more from Patricia in the video below.

Varonis Joins AWS Security Hub Extended to Power Unified, Data-Centric Security

Nolan Necoechea — Wed, 20 May 2026 19:07:54 GMT

As organizations accelerate cloud adoption and embrace AI-driven innovation, security teams are facing a growing challenge: too many tools, too many signals, and not enough unified insight to act with confidence.

AWS and Varonis help security teams cut through the noise, focus on critical threats, and stop breaches that put sensitive data at risk.

That’s why Varonis is excited to announce that we are available on AWS Security Hub Extended — providing data security across SaaS applications, multi-cloud, and hybrid environments while continuing to grow our partnership with AWS and expand our ecosystem of partnership offerings.

Security Hub Extended: A unified security solution

AWS Security Hub Extended represents a major evolution in how organizations approach security.

Built on the foundation of AWS Security Hub, the Extended plan brings together full-stack security operations and procurement, bridging AWS-native services and curated partner solutions into a single, unified experience.

Security Hub already aggregates findings across threats, vulnerabilities, misconfigurations, and sensitive data into a centralized view. With the Extended plan, AWS takes this further by enabling customers to integrate and operationalize a broader ecosystem of security tools—without adding complexity.

Security Hub Extended allows organizations to:

Unify security signals across environments for a consolidated view of risk
Operate from a single console instead of managing multiple tools and dashboards
Leverage near real-time analytics and prioritized insights to focus on what matters most
Extend protection beyond AWS through curated partner solutions across identity, endpoint, network, data, AI, and more

It also simplifies how security is consumed and managed:

Unified procurement and billing through AWS
Pay-as-you-go pricing with no long-term commitments
Pre-integrated solutions that reduce deployment and operational overhead

With Security Hub Extended, security teams spend less time integrating tools and managing vendors and more time reducing risk.

Why Varonis + Security Hub Extended matters

Varonis brings a critical capability to this unified model: unified data security.

Security Hub Extended aggregates signals across infrastructure, identity, and endpoint layers. Varonis complements this by ensuring organizations have deep visibility into their most critical asset—sensitive data—and how it is accessed and used.

Varonis ingests prioritized findings from AWS Security Hub and enriches them with data sensitivity, identity, and user behavior to deliver a single view of risk. That visibility extends across SaaS, multi‑cloud, and hybrid environments.

Bringing data context to security operations

Varonis continuously discovers and classifies sensitive data across AWS environments and monitors access and usage. This provides essential context that enhances Security Hub findings, helping teams understand not just that something happened, but what data is at risk and why it matters.

Turning signals into actionable risk

AWS Security Hub correlates and prioritizes security signals, like threat detection and vulnerability findings, from AWS services using a common data model. Varonis connects those signals to sensitive data, abnormal access patterns, and risky data activity. This enables security teams to focus on real threats where data is at risk, not alerts without impact.

Reducing risk, not just detecting it

While Security Hub helps prioritize risk, Varonis helps eliminate it. By automating remediation of excessive permissions, misconfigurations, and exposure risks, Varonis enables organizations to proactively reduce their attack surface and enforce least privilege.

Accelerating response across the attack surface

With Varonis integrated into Security Hub workflows, security teams can investigate and respond to threats across identity, infrastructure, and data from a single pane of glass across the entire data environment, leading to faster, more effective responses.

Looking ahead

Security teams don’t need more tools. They need better, faster outcomes.

Joining AWS Security Hub Extended is more than a technical integration; it’s a strategic step in how Varonis delivers value through its partnership with AWS. We are committed to embedding data security into the platforms and ecosystems our customers rely on every day.

Varonis is excited about our continued partnership with AWS and the opportunity to be part of Security Hub Extended.

Together, we’re enabling organizations to shift from fragmented security operations to a unified, data-centric approach to protecting what matters most — across AI, cloud, SaaS, and multicloud environments.

Ready to get started? Check out Varonis on Security Hub Extended now.

GitHub Breach via Malicious VS Code Extension: What You Need to Know

Chen Levy Ben Aroy — Wed, 20 May 2026 14:55:03 GMT

How long would it take you to notice if a single developer’s endpoint had quietly siphoned thousands of your most sensitive internal repositories? GitHub had to answer that question this week.

On May 20, 2026, the Microsoft-owned platform confirmed a poisoned Microsoft Visual Studio Code extension installed on an employee’s device gave an attacker access to roughly 3,800 GitHub-internal repositories. The disclosure landed hours after a familiar threat actor — TeamPCP — listed “GitHub’s source code and internal orgs” for sale on a cybercrime forum, with a floor price of $50,000.

This breach is a continually evolving incident. Here’s what Varonis Threat Labs is watching, and what defenders should be doing while GitHub finishes its review.

What we know about the GitHub breach

The initial-access vector. A malicious VS Code extension installed on a GitHub employee’s device got the threat in. GitHub detected and contained the device, removed the malicious extension version from circulation, and isolated the endpoint. The specific extension has not been publicly named.
The scope. GitHub’s current assessment is that the activity involved exfiltration of GitHub-internal repositories only. The actor’s claim of ~3,800 repositories is, in GitHub’s words, “directionally consistent” with the investigation so far.
Customer impact. GitHub stated it has no evidence of impact to customer information stored outside of its internal repositories — customer enterprises, organizations, and repositories included. Affected customers, if any, will be alerted through GitHub’s established incident-response channels.
The response. Overnight, GitHub rotated critical secrets in priority order — highest-impact credentials first — and continues to analyze logs and validate the rotation as the investigation runs.
The actor. TeamPCP is a familiar name in the developer-tooling, supply-chain space, previously linked to compromises of Aqua Security’s Trivy scanner, the Checkmarx KICS project, and the LiteLLM Python library. Their forum listing offered samples to interested buyers and threatened a free leak if no buyer materialized.

Why this breach matters

The headline is “GitHub got breached.” The real story is bigger.

This incident fits a pattern supply-chain defenders have been calling out for the better part of a year: a single trusted extension, running with a developer’s privileges, becomes the foothold into a high-value engineering environment. The blast radius isn’t measured in machines — it’s measured in repositories, tokens, and the secrets that live inside them.

The IDE is the new endpoint. It runs unsigned code on demand, holds credentials with broad reach, and sits one extension-marketplace decision away from the rest of your source tree.

The unanswered questions are exactly what every security team should be asking about their own environment:

Which extensions, plugins, and binaries are silently installed across our developer endpoints, and who governs that inventory?
If one of those tools turned malicious tomorrow, would we see the lateral movement — or only the headline?
Could we tell the difference between a developer doing their job and an attacker quietly cloning thousands of private repos?

How Varonis can help

Varonis customers can use our platform’s DSPM, CDR, and MDDR capabilities to compress the window between “compromised endpoint” and “contained incident.” That’s done automatically by:

Finding sensitive data first. Varonis discovers and classifies code, secrets, and proprietary data across SaaS and cloud platforms, including source-code platforms like GitHub, so you know what an attacker could reach before they try.
Spotting anomalous data access. Behavioral baselines on repository and SaaS activity flag the high-volume clone, the unusual principal pulling private repos, the off-hours read pattern, and the unusual origins that don’t fit a developer’s profile.
Surfacing secret sprawl. Hardcoded credentials, embedded API keys, and stale tokens inside repositories are exactly what an attacker monetizes after a foothold. Varonis surfaces them so they can be rotated before they are exfiltrated, not after.
Respond in minutes, not days. Varonis Managed Data Detection and Response service investigates suspect activity around the clock and can trigger containment without waiting for the next morning’s standup.

Actions to take this week

To ensure your GitHub environment is secure, we recommend the following:

Inventory VS Code (and other IDE) extensions across engineering endpoints. Remove anything that isn’t pinned, signed, and business required.
Treat every token, key, or secret reachable from a developer endpoint as potentially exposed. Rotate on a risk-weighted basis the way GitHub did — highest-impact credentials first.
Add behavioral detections for anomalous repository read, clone and download volume.
Watch for follow-on activity. TeamPCP has historically used initial footholds to seed second-stage supply-chain attacks against downstream consumers.

Need additional help? If you are not currently using Varonis and need assistance securing and monitoring your data, please reach out to our team.

Same story, bigger scale

Remove the brand name and this incident is a familiar story told at the largest possible scale: a developer endpoint, a trusted-looking tool, and a quiet exfiltration of the data that powers the business.

GitHub’s response — rapid containment, prioritized secret rotation, transparent status updates — is the playbook every organization should already have rehearsed.

We will continue to update this article as GitHub publishes its full incident report.

GhostTree: Unveiling Path Manipulation Techniques to Bypass Windows Security

Dolev Taler — Tue, 19 May 2026 19:33:14 GMT

Most security teams think of NTFS junctions and symbolic links as niche file system features. They let one directory point to another, like a shortcut that the OS treats as real. They exist for backward compatibility, storage management, things that rarely come up in a SOC. But they have a property that makes them interesting from an offensive perspective: any user can create them. No admin privileges are required, and no special permissions beyond write access to the target folder.

We discovered that by pointing a junction back at its own parent directory, an attacker can create recursive loops that generate effectively infinite file paths. Tools that try to scan the directory recursively, including EDR products, could follow the loop and never finish. The malicious files sitting in the same folder go unexamined, creating a technique we've dubbed GhostTree.

How NTFS junctions work

Windows file paths are a fundamental part of the operating system, but they come with complexities. While most users interact with simple folder structures, the NTFS file system introduces advanced capabilities like junctions and symbolic links. These features serve legitimate purposes, such as redirecting directories, maintaining backward compatibility with legacy applications that expect files to be in specific locations, or reorganizing files without physically moving them.

A junction is a type of NTFS reparse point that redirects one directory to another. Creating one requires only write permissions and a single command in CMD:

This creates a junction named "LinkToFolder" that transparently points to "TargetFolder." Any application accessing files through the junction sees the contents of the target directory as if they were local.

One constraint matters here though. Classic Windows systems impose a maximum path length of 260 characters, which is rooted in legacy software and file system design. It is technically possible to extend this limit up to 32,767 characters via a registry key, but many applications and utilities are not equipped to handle paths beyond 260.

Even though NTFS supports longer paths, practical usage remains restricted by existing software. That limit determines how deep the recursive loops can go, and how many unique paths GhostTree can produce.

GhostBranch

GhostBranch is the simpler of the two techniques. Any user can create a folder junction, setting both the junction’s name and destination. Consider this folder structure:

Run the command:

This creates a logical loop by pointing a child folder back to its parent folder. The child directory now contains everything the parent does, including itself. The result is an unlimited number of valid paths to the same file:

Due to the loop, you can add multiple "Child" folders to the path, and it remains valid. Every one of these paths resolves to the same executable.

GhostTree

GhostTree builds on the GhostBranch concept by creating multiple child folders instead of one. For example, you can create two child folders:

Now every level in the path can branch through either Child1 or Child2, and both loop back to the parent. This allows various paths:

Path calculations

Both GhostBranch and GhostTree produce paths that can extend to the maximum length Windows allows. The difference is in path diversity, which is where GhostTree’s additional child folder changes things considerably.

GhostBranch

Within Windows, the maximum traditional path length is 260 characters. To maximize the number of directories, one can create single-letter folders (e.g., "P") directly under the C: drive and employ an executable named 1.exe.

Example paths include:

This configuration allows for approximately 126 unique directory structures due to path length limitations.

GhostTree

The GhostTree method introduces two parent folders, "P" and "B", in contrast to the single-folder structure used previously. Examples include:

While the maximum depth remains around 126 folders, each level may be named either "P" or "B," effectively creating a binary tree-like structure. With this configuration, each node represents a distinct path, and the total number of possible nodes is calculated as:

How big is that? It’s vastly larger than the number of grains of sand on Earth (8.5 × 10^18) or even the atoms in your body (10^27).

Why this matters for defenders

With just two lines of code, a user can generate endless valid paths, making it impossible to finish scanning parent directories with the dir command recursively. The same applies to EDR products that scan folders for malicious files. An attacker places malware in the parent directory, sets up the GhostTree structure, and the containing folder becomes effectively unscannable. The scan hangs. The malicious files go unexamined.

We tested this technique against Windows Defender and confirmed it could be used to evade folder scans.

We reported the issue to Microsoft. The ticket was closed with the explanation that "bypassing Defender is not crossing a security boundary." The issue was subsequently patched regardless.

Techniques like GhostTree are a reminder that endpoint scanning is only one layer of defense. Monitoring file system activity at the data layer catches what scanners miss, including anomalous junction creation and recursive directory structures that should not exist in normal operations. Varonis monitors file access patterns and detects this kind of anomalous activity across file systems and cloud infrastructure.

Varonis: The Platform Advantage for Security

efeldman@varonis.com (Eugene Feldman) — Tue, 19 May 2026 13:52:31 GMT

Protecting sensitive data is a board-level imperative. Without strong data security, AI initiatives stall, innovation slows, and competitive advantages erode. AI models and agents with access to unsecured and poorly governed data create unacceptable risk, and weak data practices become a liability with regulators, prospects, and partners.

Most organizations try to protect their sensitive data by stitching together disparate tools. While always costly and inefficient, that approach was once viable when environments were simple. Now, modern attacks can't be stopped with siloed tools that only see parts of the environment. Today's threats span multiple data stores, applications, and AI tools.

In this blog, we’ll dive into Varonis’ platform advantage from improved outcomes to tool consolidation and lower TCO.

One platform for data security, AI security, and email security

The Varonis Data Security Platform provides an end-to-end approach to data security, bringing together the capabilities needed to protect data throughout its lifecycle, at rest, in use, or in motion. Gone are the days of point solutions and fragmented products that address structured and unstructured data separately.

Varonis goes beyond visibility, providing the capabilities needed to automate outcomes and reduce risk, enforce policies, and stop threats, including:

Data Security Posture Management (DSPM) provides continuous visibility into where sensitive data lives, who can access it, and how it’s being used. You can’t protect what you can’t see.
Database Activity Monitoring (DAM) detects threats and policy violations across databases with an agentless, fast-deploying solution. Your most valuable data needs dedicated monitoring.
Data Access Governance (DAG) maps and enforces least-privilege permissions at scale. Overprivileged access is one of the most common and exploitable security gaps.
Data Loss Prevention (DLP) prevents sensitive data from leaving through unauthorized channels. Visibility only matters if you can act on it and stop exfiltration in real time.
Data Detection and Response (DDR) uses behavioral baselines to detect ransomware, insider threats, and exfiltration in real time. Every breach raises one question: who touched the data?

AI Security

AI Security Posture Management (AI SPM) discovers and assesses AI agents, copilots,and models for misconfigurations that could expose sensitive data. You can't secure AIyou can't see.
AI Runtime Guardrails inspects every prompt, response, and agent action in real time through an AI gateway, blocking sensitive data exposure before it happens.
AI Governance automates audit reporting and compliance evidence for AI-specific regulations and frameworks. New mandates become configuration changes, not new projects.

Email security

Social Engineering Defense uses multi-layered AI to stop phishing, BEC, and impersonation attacks before they reach the inbox. AI-generated threats demand AI-powered protection.

The unified platform provides deeper visibility across the entire data estate with context that makes findings actionable. and makes every capability stronger. Sensitivity, access, and behavior are correlated in real time within a single platform rather than stitched together after the fact.

Datasecurity not only classifies and protects sensitive data, but also considers AI agent activity and email-borne threats. AI security not only evaluates agent guardrails, but also knows what data is sensitive, who should access it, and what normal behavior looks like. Email security not only identifies phishing messages, but also connects each phishing attempt to the recipient's blast radius. That context is only possible when data security, AI security, and email security are built together, not bolted on.

Unlike standalone solutions, the Varonis platform performs automated remediations to reduce risk, enforce policies, and stop active threats without relying on the interoperability of disparate tools. The result is fewer tools to manage, improved outcomes, and a lower total cost of ownership.

Varonis’ unified platform approach has delivered proven outcomes for thousands of customers around the world and earned accolades, including being named a Leader and Customer Favorite in The Forrester Wave™: Data Security Platforms, Q1 2025, with the highest scores for current offering, strategy, and customer satisfaction, and a Gartner® Peer Insights™ Customers' Choice for DSPM for two consecutive years with a 99% recommendation rate.

A platform approach stops data breaches

Modern attacks span multiple systems. Standalone tools provide siloed views of risk, create gaps, and make it difficult to detect attacks that involve lateral movement or the supply chain. A unified platform protects data across the entire data estate with the context needed to detect and neutralize threats.

Let’s look at an example.

Stopping the Salesloft Drift Breach

In early 2025, a threat actor known as UNC6395 compromised Salesloft’s GitHub repos and stole the OAuth tokens. Those tokens allowed Drift, a widely used chatbot owned by Salesloft, to connect to customers’ Azure, Salesforce, Google Workspace, and other integrated platforms.

Between August 8th and 18th, UNC6395 used those tokens to impersonate the trusted Drift application, bypass MFA, and systematically exfiltrate data from more than 700 organizations. The majority of affected organizations only learned of the breach when Salesforce and Salesloft notified them more than two weeks later.

Varonis customers were the exception.

Varonis’ end-to-end approach stopped this breach before any damage could happen. Here’s how it played out for one organization:

Step 1: Cross-platform detection. Varonis flagged Drift activity in Azure as abnormal. Its OAuth token refreshes originated from unusual IP addresses and API call volumes exceeded Drift’s established baseline. Varonis issued an alert and began checking Drift activity across other connected systems. 
Step 2: Salesforce telemetry confirms the threat. Salesforce Shield Event Monitoring provided detailed logs that allowed Varonis to identify abnormal Drift-connected app activity in Salesforce, including logins from suspicious IPs and unusual API queries. 
Step 3: Varonis MDDR responds. Varonis correlated the Azure and Salesforce signals, and its Managed Data Detection and Response (MDDR) team engaged the company’s security operations team to immediately act and prevent the breach.

For most companies, this attack was invisible. OAuth abuse looks like normal API traffic, and the attackers deleted query jobs to cover their tracks. Without a data security platform connecting unusual activity across Azure, Salesforce, and Drift, this breach is nearly impossible to catch.

And this is just one example. Consider some common attack scenarios that can only be prevented with a platform approach:

Phishing → Credential compromise → Data exfiltration

A finance employee clicks a convincing phishing link, and the attacker captures their credentials. The attacker accesses SharePoint and begins downloading sensitive financial documents.

Fragmented data security stack: The email gateway flags the phishing attempt but has no visibility into file activity. The DLP tool sees downloads but can’t tie them to a compromised identity.
Varonis: Correlates the compromised identity with abnormal file access patterns in SharePoint, detects bulk downloads that deviate from the user’s baseline, and triggers an alert before sensitive data leaves the environment.

AI agent exposes sensitive data

An employee asks the company’s AI assistant for average salary data. The agent pulls from multiple repositories and surfaces data the employee should not have access to, including individual salaries, bonuses, and stock compensation figures.

Fragmented data security stack: The AI tool has no awareness of data sensitivity or access policies. No alerts are triggered because the query looks like normal usage from an authorized user.
Varonis: Enforces least-privilege access on the underlying data so the AI agent can only retrieve what the user is authorized to see, preventing sensitive data from being surfaced in the first place.

Database exfiltration via compromised service account

A service account runs abnormal read queries against sensitive customer tables during off-hours. An egress event follows shortly after.

Fragmented data security stack: The database monitoring tool logs the queries but lacks user behavior context. The network tool sees the egress but can’t connect it to the database activity. Neither tool escalates.
Varonis: Detects the off-hours query spike against sensitive tables, correlates it with the subsequent egress event, flags the service account compromise as a single incident, and disables the service account while the team investigates.

Ransomware spreads through overprivileged access

An employee opens a malicious attachment that deploys ransomware. The malware begins encrypting files across every share the user can access, which due to excessive permissions spans far beyond their role.

Fragmented stack: The endpoint tool detects encryption behavior on the local machine but has no visibility into network file shares. The storage team sees mass file modifications but can’t identify the source. Response is slow and the blast radius is massive.
Varonis: Detects the anomalous encryption pattern across file shares in real time, automatically disables the compromised account. Blast radius is minimum because least-privilege policies have already cut off all unnecessary access.

Platform approach lowers TCO

The Varonis Data Security Platform drives ROI across three dimensions: cost consolidation, operational efficiency, and measurable risk reduction. Because data security, AI security, and email security sharea single platform, organizations not only consolidate their tools but the context those tools need to beeffective.

Consolidation and TCO: the hard savings

Organizations can sunset separate licenses for numerous standalone security products that often incur additional costs in specialized resources and support services, including:

Data Security Posture Management (DSPM) for identifying and reducing exposure across cloud and on-prem data stores
Data classification for automated discovery and labeling of sensitive or regulated content and data
Data governance for policy enforcement for data access, retention, and lifecycle management
Standalone Database Activity Monitoring (DAM) for tracking and auditing database queries and transactions
Email security for threat detection, DLP, and policy controls for inbound and outbound email
Identity Threat Detection and Response (ITDR) for spotting compromised accounts and privilege escalation
IR/forensics retainers for incident response and forensic investigation services engaged on contractor DSPM, data classification, data governance, standalone DAM, email security, AI governance, ITDR, and IR/forensics retainers.
AI SPM for discovering and assessing AI agents, copilots, and models for misconfigurations and data exposure
AI Runtime Guardrails for inspecting prompts, responses, and agent actions to block sensitive data exposure
AI governance for oversight of AI model access, training-data exposure, and prompt-level risk

Typically, customers replace between five and eight licenses with one Varonis platform license, resulting in lower TCO from:

License rationalization: Consolidating point solutions into one platform eliminates redundant license fees, overlapping coverage, and duplicative support contracts.
Smaller infrastructure footprint: A shared telemetry layer using API and audit-log ingestion replaces duplicative sensors, scanners, collectors, and agents.
Zero integration debt: No more professional services or internal engineering hours spent writing and maintaining brittle glue code between incompatible tools.
Reduced training burden: Analysts learn one console instead of 5-8 disparate interfaces with separate workflows, query languages, and escalation paths.

Operational efficiency: the time dividend

With Varonis, customers reclaim thousands of hours that SOC analysts currently spend filing tickets, chasing false positives, and manually correlating alerts.

Reduced MTTR: Varonis presents a correlated incident with identity, sensitivity, behavior, and blast radius rather than isolated alerts. Analysts get the complete picture instead of assembling it manually across consoles.
Automated remediation: What previously required a cross-departmental meeting, and a help desk ticket now gets handled via automated policy or a single click, freeing security teams for strategic work.
Analyst time reclaimed: Hours spent on manual correlation, ticket management, and cross-console investigation are redirected to proactive risk reduction.

Risk reduction and compliance: quantifiable security outcomes

The Varonis Data Security Platform allows security leaders to report on metrics that measure risk, not just activity.

Measurable blast radius reduction: Track the drop in sensitive files accessible to "everyone," over-privileged accounts right-sized, and stale permissions removed. These metrics map to actual risk, not busywork.
Audit readiness: A single system of record for classification decisions, access changes, behavioral alerts, and remediation actions. When auditors ask for proof, the answer is a generated report, not a cross-functional project.
Regulatory defensibility: The platform maps controls to regulatory requirements (GDPR, DORA, CCPA, HIPAA, SOX) and continuously generates evidence. New regulations become configuration changes, not new initiatives.

How the Varonis Data Security Platform works

Varonis provides a much greater context for critical decision-making and automated outcomes compared to a stitched-together stack.

When discovery, access, and behavior live in separate tools, analysts become the integration layer. They switch between consoles, export CSVs, normalize timestamps, and try to piece together a coherent story from fragments. By the time they connect the dots, incidents escalate.

Varonis eliminates manual correlation by combining connectivity, context, and action.

Connectivity: One telemetry pipeline across the entire data estate

Varonis connects to your data wherever it lives: SaaS applications, cloud infrastructure, databases, on-premises file shares, email, browsers, identity providers, network devices, and endpoints as well as AI agents and models that interact with your data. Every identity, whether human, service account, application, or AI agent, is resolved across Active Directory, Entra ID, Okta, and SaaS platforms into a single graph. This unified connectivity means cross-system patterns that would be invisible to siloed tools become obvious. Because AI agents share the same telemetry pipeline and identity graph as human users and service accounts, AI security is native to the platform rather than a bolt-on.

Context: The intelligence that makes signals actionable

Raw telemetry isn’t enough. Varonis enriches every event with the context needed to make real-time decisions: data sensitivity and topic, attack paths, blast radius, user intent, toxic access combinations, and forensic detail. Every signal is weighted against effective permissions and behavioral baselines, so when something happens, Varonis already knows what data is at risk, who is involved, and how far the damage could spread. This transforms detection:

A stale admin account reactivates after months of inactivity. Varonis knows it still has access to 50,000 sensitive files, the reactivation came from an unfamiliar device, and the account was flagged for deprovisioning.
A new OAuth app requests broad permissions across Salesforce and SharePoint. Varonis maps exactly which sensitive data stores it could reach and scores the risk before a single query executes.
An AI copilot is deployed with access to a shared drive containing M&A documents. Varonis identifies the sensitive content, flags the overly broad permissions granted to the copilot, and calculates the exposure before any user prompts it.
A departing employee's download volume spikes during their final week. Varonis correlates the activity with HR-flagged offboarding status, identifies the sensitive files being accessed, and scores the exfiltration risk.

Action: Automated enforcement, not just alerts

Context without action is just a dashboard. Varonis closes the loop with automated responses calibrated to the severity and context of each event.

When a stale admin account reactivates and begins accessing sensitive files, Varonis disables the account and creates an incident with full scope of what was touched.
When an OAuth app with broad permissions starts querying data outside its stated scope, Varonis revokes the token and alerts the app owner.
When an AI copilot surfaces M&A documents to an unauthorized user, Varonis blocks the response, scopes down the copilot's permissions, and notifies the data owner.
When a departing employee's download volume spikes in their final days, Varonis restricts access to sensitive repositories and notifies their manager.

Every automated action includes dependency checks to avoid breaking production workflows and one-click rollback if something needs to be reversed. Athena AI streamlines investigations further, letting analysts query the full picture using natural language.

Complementing your existing security ecosystem

Varonis works with the native security capabilities built into the platforms you already run, including Microsoft Purview and E5 Security, AWS Security Hub, and Salesforce Shield.

Where these tools provide foundational controls within their own ecosystems, Varonis extends classification, access governance, and threat detection across your entire data estate and pairs static labels and permissions with real-time behavioral context.

Varonis also integrates directly with your broader security infrastructure:

SIEM. Surface Varonis’ data-centric, context-rich alerts in Microsoft Sentinel, Splunk, and IBM QRadar for faster triage and investigation.
SOAR. Incorporate Varonis alerts into automated playbooks in Cortex XSOAR and Splunk SOAR to accelerate threat response.
EDR. Correlate endpoint telemetry from CrowdStrike, SentinelOne, and Microsoft Defender for Endpoint with data-layer activity for complete attack visibility.
CSPM. Unify cloud misconfiguration findings from AWS Security Hub, Azure Policy, and Wiz with data risk context.
Ticketing. Route alerts and remediation recommendations directly into ServiceNow and JIRA workflows.
PAM. Manage Varonis credentials securely through CyberArk to meet compliance requirements and minimize risk.

Rather than adding another tool to monitor, Varonis becomes the connective tissue that makes your entire security ecosystem smarter. Every tool in your stack, from SIEM to EDR to SOAR, gains the data context needed to distinguish real threats from false positives and trace attacks from initial compromise through data exfiltration.

Security leaders are choosing the platform approach

The shift away from fragmented stacks to integrated data security platforms is accelerating and AI is compressing the timeline.

Gartner declared in 2024 that we've entered "the next phase of security platform consolidation." The urgency is growing: Gartner predicts that by 2026, 75% of organizations running GenAI initiatives will reprioritize data security spending toward unstructured data, and that through 2030, a third of all IT work will go toward remediating "AI data debt" caused by poorly secured and ungoverned data.

Security leaders see the shortcomings of fragmented security stacks where classification, access governance, threat detection, and AI security live in separate products:

Classification tools label data but have no visibility into who can access it or whether that access is normal.
Access governance tools manage permissions but can’t tell whether the data behind them is sensitive or high-risk.
Threat detection tools fire alerts but lack the data context to separate real attacks from routine activity.
AI security tools evaluate models, prompts, and agent behavior but have no insight into the underlying data, its sensitivity, who can access it, or whether exposure has already occurred.

The result is blind spots, false positives, and incidents that are only understood after they've done their damage. A fragmented security stack isn't just expensive, it's a liability. As organizations rush to deploy AI, bolting on yet another siloed tool only widens the gaps. Data security and AI security are inseparable: you can't protect AI without understanding the data it touches, and you can't protect data without accounting for the AI that accesses it. That's the platform advantage.

To see where your organization stands, request a complimentary Data Risk Assessment.

Feeding Frenzy: RCE on Azure Cosmos for PostgreSQL

Coby Abrams — Mon, 11 May 2026 14:26:18 GMT

Varonis Threat Labs uncovered a vulnerability in Azure Cosmos for PostgreSQL, leading to remote code execution (RCE). Due to an improperly validated server configuration value, it was possible to edit arbitrary PostgreSQL configurations through the Azure management API, including those managed by Azure and controlling sensitive server functions.

RCE, in this context, allows arbitrary commands to be run on the underlying operating system of the database server, possibly leading to data disclosure and/or destruction. Therefore, a threat actor with sufficient management privileges to edit parameter values on the cluster could gain unrestricted data access to the cluster, and compromise cloud-managed infrastructure.

Whenever cloud-managed infrastructure is compromised, there is the risk of a threat actor escalating privileges, either within the tenant or to cross-tenant access. In this case, we were unable to test for these issues. Let’s explore this vulnerability in more detail.

Background

Azure Cosmos for PostgreSQL

Azure Cosmos for PostgreSQL is a managed PostgreSQL service expanded with the Citus extension to allow for distributed tables. Clusters are made up of one or more PostgreSQL servers called nodes, and with one node being the coordinator.

Both the coordinator and worker nodes can be configured through the Azure management API, where certain PostgreSQL configurations can be set.

PostgreSQL configuration

It is possible to modify PostgreSQL parameters in a few different ways. Understanding the configuration file format is important, as this is how the parameters are managed in Cosmos DB.

The Postgres configuration file is a newline delimited list of parameters, where strings are defined with a single quote (‘). For example, the following configuration file sets two parameters: log_line_prefix and archive_command.

Code snippet:

The vulnerability

Our investigation started by looking for interesting configuration values that Azure allows us to set to arbitrary values. We were about to shift our focus when something caught our eye.

Whereas most of the editable parameters either have a list of allowed values or allow a closed set of characters, log_line_prefix was unique in the way and allowed any character apart from a single quotation mark.

The reason that they are interested in limiting that character is apparent from the Postgres config file format. If we could insert a single quote, we would be able to close the value string and start a new parameter in a new line.

The forgiving limitation gave us some room to get creative and insert characters that the original developers hadn’t thought of, and try to get unexpected results.

Surprisingly, trying to insert the control characters supported by the JSON format did not raise any problems, and after a few attempts, we discovered that putting a form feed (\f) in front of the single quotation mark allowed us to bypass the validation and insert the forbidden character.

At this point, the server logs indicate a syntax error related to a single apostrophe while trying to reload the configuration file.

Notice the “message” field:

The next step is to insert a new line so that we can inject a new configuration definition. For the proof of concept, we decided to use hello, a variable that does not exist in Postgres.

Getting the API to accept our payload required a double newline, or we would get an error regarding the second single quote. We did not completely understand why this double newline, or the form feed character, allowed us to bypass the server-side check. This new payload caused a new and exciting error, unrecognized configuration parameter, letting us know that we could now inject parameters of our choice.

At this point, it is clear that we can execute code with the <code>archive_command</code> parameter, whose value is a command periodically run to archive WAL logs. This would look something like this.

Since we could have been accessing critical infrastructure, we involved Microsoft and requested permission to test code execution before continuing. Our request was denied, but Microsoft tested itself and confirmed the issue as an important RCE.

Best practices for Azure managed databases

Misconfigurations and excessive permissions remain the most common root causes of cloud breaches. Vulnerabilities like Azure Feeding Frenzy highlight the importance of hardening both identity and data layers — not only to prevent exploitation, but also to reduce the blast radius if an issue is discovered in a cloud-managed component.

The following best practices help reinforce defense-in-depth across Azure environments.

Entra ID (Identity layer)

1. Enforce least privilege for all privileged users

Regularly audit all Entra ID roles, especially those with access to compute, data, and management-plane operations. Ensure that administrators, automation principals, and developers have only the exact privileges required for their tasks.

2. Secure common identity entry points

Malicious or over-permissioned applications

External or guest user

Highly privileged internal users

Apply tighter restrictions to these identities, review their assignments periodically, and remove any unnecessary access.

3. Require phishing-resistant MFA and conditional access

Protect access to all critical infrastructure, including Azure management, using phishing-resistant MFA options. Combine with Conditional Access to enforce device trust, location rules, and session restrictions.

Database Layer

1. Apply least privilege to database roles and application accounts

Ensure database roles map precisely to operational needs. Client-facing or application identities, especially those used by web apps or APIs, should have minimal permissions and never run under superuser or administrative roles. Also avoid enabling extensions, settings, or features unless absolutely necessary.

2. Use federated authentication instead of local credentials

Where possible, integrate PostgreSQL with Entra ID or other federated identity providers. This centralizes identity lifecycle management and reduces risk from long-lived or hard-coded database passwords.

3. Collect and actively monitor audit logs

Enable PostgreSQL and Azure-native audit logs and forward them to a SIEM for anomaly detection. Monitor for:

Unexpected configuration changes

Suspicious SQL commands

Newly created users or roles

Rapid visibility into unusual activity can significantly reduce detection and response time.

4. Use network isolation and private endpoints

Place managed databases behind private endpoints and restrict access to approved VNets, workloads, or identities. Avoid exposing PostgreSQL publicly.

Disclosure timeline and recommendations

We disclosed the vulnerability to Microsoft, and a fix was released in the summer of 2025. No further action is required by customers using Azure Cosmos DB for PostgreSQL.

While no action is required, this is another reminder for security teams to ensure that privileges — especially to data containers such as databases — are properly managed.

This vulnerability required privileges to the management API of a Cosmos DB for PostgreSQL to be exploited in a client environment. If the Azure Cosmos DB for PostgreSQL user had properly managed privileges, there would be a drastic reduction in the probability of the vulnerability being exploited within the user’s environment.

Stay up to date on the latest threats in Azure with Varonis Threat Labs by exploring more of our research.