Varonis Blog

Varonis Atlas Now Integrates with Claude Inference Hooks to Extend Real-Time AI Data Protection

Nolan Necoechea — Fri, 07 Aug 2026 23:47:27 GMT

Varonis Atlas now integrates with Claude Inference hooks, routing prompts through an AI security server for real-time allow-or-deny verdicts before inference runs.

That inspection happens ahead of Claude ever seeing the prompt — the request is sent off for review and policy evaluation first. If it violates policy, it never reaches the model. Support for Inference hooks helps security teams prevent sensitive data exposure, prompt injection attempts, and other risky activity.

As Anthropic continues to expand the Claude ecosystem, AI security platforms have to move quickly to keep data secure. Just a few weeks ago, we brought Atlas coverage to the entire Claude enterprise suite, including Claude Enterprise, Claude Platform, Claude Code, and Claude Cowork. Atlas has also enhanced support for Claude Chat and Claude Design.

How Atlas prevents prompts that fall outside policy

Atlas now sits in the request path itself. When a user submits a prompt, Anthropic sends the conversation transcript to Atlas, which evaluates it against an expansive set of customizable policies, including PII exposure, malicious URL, and prompt injection. Atlas then returns a verdict — allow or deny— before inference proceeds. A denied prompt never reaches Claude at all.

How Atlas enforces the verdict

Because Atlas understands sensitivity, permissions, and access across an organization's data, prompts aren't evaluated in a vacuum. That context determines the risk and informs an appropriate response. For example, a prompt asking Claude to summarize a spreadsheet depends on whether the spreadsheet contains public marketing copy or unmasked customer PII.

With Inference hooks, that context now drives inline decisions:

AI runtime guardrails. Atlas inspects the transcript and attachment text on every prompt and takes action in real time, including denying requests that would expose regulated, classified, or sensitive data before a response is generated.

A consistent verdict, everywhere Claude runs. Atlas enforces consistent policies and guardrails across the entire Claude enterprise suite, including Claude Chat, Claude Design, Claude Enterprise, Claude Platform, Claude Cowork, and Claude Code.

Complete audit trail. Atlas creates a record of every prompt and response alongside the actions it took, leveraging Inference hooks to provide an intuitive audit trail for security, governance, and compliance teams.

Complete security for the Claude enterprise suite

Most AI security solutions tell you which AI systems exist, not whether data is at risk. Varonis Atlas connects AI risk to data — where the damage happens. That same context now applies to every Claude interaction, from a governed prompt in Claude Chat to a multi-step Claude Cowork task to an agent running in Claude Code.

With Inference hooks, that connected view extends into the request path itself, including posture management and security testing before an AI system goes live, runtime guardrails and inline enforcement, and compliance reporting.

AI security cannot live in silos or point solutions. Atlas support for Claude is one piece of an end-to-end approach to AI security. As organizations scale AI, they also increase exposure. The only way forward is security that understands both how AI behaves and what data it can access. AI isn’t the risk, uncontrolled AI is.

RovoBlast: How One Click Triggered Atlassian’s AI Assistant to Leak Data

Dolev Taler — Fri, 07 Aug 2026 22:15:00 GMT

Varonis Threat Labs uncovered a vulnerability in Rovo, Atlassian's enterprise AI assistant. Dubbed RovoBlast, a single click on a link triggers the attacker's embedded instructions and forces Rovo to accept externally supplied parameters as trusted inputs within a user's session. No jailbreaks, no permission bypass, and no warnings or confirmation.

The same capabilities that make Rovo a powerful tool also make RovoBlast especially dangerous. Rovo operates as an AI layer across the core products in the Atlassian platform, including Jira, Confluence, Bitbucket, as well as other connected SaaS tools like Slack, Microsoft 365, and Google. Atlassian also features autonomous-agent capabilities that can carry out multi-step actions without user involvement.

When AI can search, connect, and act across business systems, the blast radius of a mistake or attack grows significantly, a risk that CISOs and security teams are increasingly concerned about.

Rovo operates within the trust boundary that security teams rely on to enforce controls, visibility, and accountability. Actions executed under a legitimate user identity inherit existing access and blend into normal AI-assisted workflows, leaving little to distinguish abuse from routine use.

We responsibly disclosed RovoBlast to Atlassian, which was fixed and published via Crowd Source in Bug Crowd, then debuted at DEF CON 34. Continue reading to discover how combining trusted input, broad data access, and built-in automations create a low-friction path to organizational data exposure.

Meet Rovo

Atlassian's Rovo is an "AI teammate" that unifies search, chat, and agent actions across Jira, Confluence, and connected SaaS apps. It's powered by Atlassian's Teamwork Graph and a growing set of connectors and agent capabilities.

Rovo's value comes from context: federated search across Atlassian and third-party tools, conversational answers in Rovo Chat, and task-taking Rovo Agents. The capabilities that make Rovo helpful also create an expansive attack surface if external inputs aren't treated as untrusted throughout execution.

Parameter to Prompt strikes again

In January 2026, Varonis Threat Labs uncovered Reprompt in Copilot, showing how a single click on a crafted link could turn a benign URL parameter into a Parameter-to-Prompt (P2P) pathway that executes inside the user's trusted AI session. RovoBlast presents a similar opportunity.

Like other AI assistants, Rovo accepts externally supplied parameters that run automatically, meaning a link is infused with data and instructions. Rovo uses the "rovoChatPrompt" parameter to inject content directly into its chat entry. For example, Rovo's chat entry can be invoked with a route and a pre-filled prompt via the following pattern:

https://home.atlassian.com/chat?rovoChatPathway=chat&rovoChatPrompt=<prompt>

When a user clicks a link formatted this way, the content is surfaced directly inside Rovo Chat. Without proper guardrails, this P2P technique can be abused to seed attacker instructions into a trusted session — exactly the primitive needed to start a one-click exfiltration chain.

Importantly, the severity of this problem is heightened by the fact that Rovo cannot be fully uninstalled. Organizations attempting to remove the risk may not be able to eliminate Rovo's presence in their environment or the associated attack surface, making robust input validation and security controls even more critical.

What can Rovo actually access?

Once we discovered we could reliably run arbitrary instructions as the user, the next question became unavoidable: What exactly does Rovo have access to inside the organization?

Rovo isn't just a chat interface; it's a federated access layer glued onto Atlassian's ecosystem and every connected SaaS source. And unlike traditional search engines that tend to stay in their own lane, Rovo happily blends data from multiple systems, interprets it, and summarizes it on demand. We made a simple request for it to list all available data sources. The results speak for themselves:

Rovo confidently enumerated every major surface it could read from, including Jira, Confluence, Bitbucket, Slack, Google Workspace, Microsoft 365, relational databases, uploaded files, web pages, and even archives. No jailbreak, filter bypass, or friction just an honest list of everywhere it can look into.

The full list is even larger due to Rovo Connectors that allow more than 50 different platforms to be connected.

Finding the perfect exfiltration path through the ResearchAgent

At this stage, we knew two things:

Rovo will happily run attacker-supplied instructions
Rovo has access to essentially everything an organization stores across its connected platforms

The natural next step was to figure out how to turn that access into actionable leakage. We went hunting for agent capabilities that could turn seeded instructions into a full data exfiltration chain. Rovo didn't disappoint.

While enumerating its available tools, ResearchAgent immediately stood out.

ResearchAgent looks like a standard "internet research" tool at first glance, but when you read what it can do — specifically what it can do autonomously — the implications become clear. The first two bullets in the chat below highlight a turnkey leakage engine:

Let's break these bullets down further:

Deep multi‑source open web research: If an attacker can seed a prompt, Rovo can pull data from internal sources and then push it to the public web as part of its "research"
Multi‑step browsing and navigation across arbitrary websites: Multi‑step autonomy means fetch → transform → upload is just a chain of actions away

In other words, ResearchAgent isn't just a browsing tool. It's everything an attacker needs to convert internal organizational knowledge into an externally reachable payload-with zero user interaction beyond the initial click.

We didn't need jailbreaks or prompt‑surgery exploits. Just a single Rovo link pre-filled with a crafted prompt.

This is where the threat escalates from, "Rovo can leak data if misused" to "Rovo includes built‑in automation that accelerates exfiltration once misused."

Where are my safeguards?

Enterprise AI assistants such as Rovo or Microsoft Copilot operate at the intersection of highly privileged data, automated actions, and untrusted inputs, including links, documents, connectors, and comments. That is a powerful and risky mix.

The same features that make assistants helpful — pre-filled prompts, auto-context, agent tools, federated search — also create paths for instruction injection, context confusion, and silent data leakage if strong guardrails aren't in place.

In our testing, Rovo's guardrails around untrusted prompts were almost non-existent:

A crafted link using rovoChatPrompt (e.g., https://home.atlassian.com/chat?rovoChatPathway=chat&rovoChatPrompt=<prompt>) auto-surfaces content directly into Rovo Chat
The organization ID from "/o/< ID>/chat" can be empty in the URL and Atlassian will redirect it directly into the default organization ID of the user:
No warning, confirmation, and taint label indicating the session was seeded by an external parameter
Rovo searched across organizational content (Jira, Confluence, connected SaaS) when asked and summarized sensitive information with ease. In fact, we were able to successfully exploit this behavior with minimal to no guardrail bypasses in most cases. The lack of meaningful barriers allowed untrusted input to flow directly into trusted sessions and exfiltrate data.
Since the session is already saved in the user's browser, all the attacker needs is a click to obtain the desired data.

Double request and chain request are not needed

Our exploit path does not rely on chain request to bypass guardrails, one P2P click was usually enough to get Rovo to retrieve and summarize sensitive data. However, once seeded, chaining autonomous steps via ResearchAgent (e.g., multistep browsing and posting) reduces visible touchpoints and keeps actions within a single agent running.

Practically, that means fewer user-facing interactions, fewer opportunities for the UI to warn or interrupt, and a cleaner audit surface that looks like "normal research" rather than repeated user prompts.

As a reference to our original Reprompt research, double-request was not required here; the leakage path worked without it.

RovoBlast in action

Recommendations

For Atlassian customers, the most effective defense is to shrink Rovo's blast radius within your organization.

Limit which systems Rovo can access, disconnect unused integrations, and keep high sensitivity areas (legal, HR, finance, IR) out of scope entirely. The less the assistant can see, the less it can leak, regardless of prompt injection or agent abuse.

Our second recommendation is to reduce Rovo's capabilities that are unnecessary for your use. Disable browsing agents, multistep automation, or any AI features your teams don't actively rely on. Pair that with basic monitoring tasks such as reviewing assistant logs, alert on unusual agent runs, and periodically test how your environment reacts to seeded prompts. These lightweight steps go a long way toward containing the damage if (or when) a malicious prompt finds its way in.

The AI hacking trifecta

While analyzing RovoBlast, we noticed a pattern that extended far beyond Atlassian Rovo. Similar attacks have appeared across multiple AI platforms, each using different technologies but following the same underlying path.

Simon Willison describes the "Lethal Trifecta" for AI agents as the combination of access to private data, exposure to untrusted content, and the ability to communicate externally. RovoBlast clearly fits that model, but our research showed something interesting: direct internet access is not always required. In SearchLeak, for example, the assistant itself could not reach the internet, yet data still escaped through trusted services and browser behavior.

As a result, we started thinking about these attacks through a different lens: Enter, Evade, Escape.

Enter

Every attack starts with turning data into instructions.

In RovoBlast, that entry point was the rovoChatPrompt parameter. In other platforms, it might be an email, document, web page, knowledge base entry, repository, connector, or agent memory. The common theme is that content crosses a trust boundary and is later interpreted as a command.

A useful rule of thumb: If the model can read it, it can potentially become an instruction.

Evade

Once inside, attackers must bypass whatever controls are intended to stop them.

Sometimes that means prompt smuggling, role confusion, encoding tricks, or carefully crafted wording. In other cases, it is much simpler. During our testing, Rovo often required little to no guardrail bypassing to retrieve and summarize sensitive information. The challenge is not that controls do not exist, but that security checks and execution paths do not always interpret the same data in the same way.

Escape

Finally, the data needs a way out.

Direct internet access is the obvious route, but it is rarely the only one. ResearchAgent demonstrated how built-in browsing capabilities can create a natural exfiltration channel. Other systems may provide alternative paths through trusted domains, image fetches, link previews, webhooks, logs, third-party connectors, or other agent actions.

The key lesson is that blocking one exit does not eliminate the risk. Attackers look for the next trusted pathway capable of carrying data beyond the intended boundary.

RovoBlast wasn't just a vulnerability in Atlassian Rovo. It was another example of a broader AI security pattern where untrusted inputs, autonomous behavior, and trusted communication paths combine to create new opportunities for data exposure.

The bottom line

What RovoBlast exposes is not just a prompt injection flaw but a trust gap at the heart of enterprise AI. Organizations are racing to connect AI systems to more data to drive productivity, but every new connection increases the blast radius when something goes wrong.

Rovo didn't expose this risk recklessly. It did so because it operates deeply inside the enterprise trust boundary, with access, identity, and autonomy by default. In that environment, a single misclassified input can quietly turn productivity into data exposure.

Reprompt first showed this risk in consumer AI. RovoBlast shows how much higher the stakes are when the same patterns move into the enterprise.

Learn more about assessing AI security risk in your environment with more findings from Varonis Threat Labs.

Introducing Agent Intent-Based Access Control

Nolan Necoechea — Mon, 03 Aug 2026 12:55:00 GMT

Today, we’re announcing Agent Intent-Based Access Control (IBAC), a new capability in Varonis Atlas that lets businesses connect AI agents to their enterprise data with safeguards that stop dangerous or out-of-policy behavior.

Agents are making headlines for going rogue, exposing sensitive company data and, in one case, deleting an entire production database.

Agent IBAC compares the instruction an agent received to its reasoning and the tools and data it reaches for, then responds in real time to actions that don't align, including alerting or blocking. When an agent crosses the line, Atlas can quarantine the identity behind it and block everything that follows for a defined window.

Agent IBAC can be tuned to take appropriate action based on the potential impact. For example:

Clear deviation puts data at risk: A user asks an agent to check the weather. Instead, it invokes a migration tool. This is a clean mismatch between intent and action. Agent IBAC can automatically block the tool call.
Drift but nothing at stake: A user asks an agent to check the weather. The agent sets up a recurring daily reminder instead of providing a one-time answer. The agent's action has drifted, but no data is at risk. Agent IBAC can simply log the deviation rather than interrupt an over-eager attempt to help.

With Agent IBAC, Varonis Atlas gives enterprises confidence that their agents are acting within the intended scope, without unnecessarily slowing productivity. Agent IBAC is a critical component of agentic security and a core part of Atlas's end-to-end approach to AI security.

At Varonis, we are building the security layer that lets enterprises say 'yes' to agents. Watch this quick 3-minute demo to see Agent IBAC in action.

Agents don't wait for permission

Agents need broad access to data and tools to be useful, which is precisely what makes them risky. Role-based access control was never built to judge what a non-human identity does with the access it has.

Static controls can't stop an agent that finds ways to circumvent them entirely, like elevating its own privileges, calling tools, and acting on data it was never meant to touch. Agent permissions must be enforced at runtime.

Varonis Atlas Agent IBAC

Agent IBAC closes the gap between what an agent is allowed to do and what it was designed to do. Drift is determined in part by monitoring behavior.

Agent IBAC evaluates every action an agent takes across a session and compares those actions to the instruction that set the agent in motion, whether that instruction came from a person, system prompt, or another agent.

Because Atlas sees the full context around an action, it doesn't rely on blanket restrictions. The sensitivity of detection and the action taken in response can each be tuned appropriately.

Agent IBAC at a glance:

Intent drift detection: Compares the instruction an agent received to its reasoning and the tools it calls, with lenient, balanced, and strict sensitivity settings.
Full-session evaluation: Reviews every prompt, response, and tool call in a session to catch drift that builds gradually, including multi-turn jailbreak attempts. Teams can also write their own session policies in plain language.
Runtime guardrails: Alert, block, modify, log, or route an action to a person for approval, configured per policy.
Quarantine: Blocks an identity or session for a window the customer sets, with admin controls to lift, extend, or make it permanent.
Complete audit trail: Records every prompt, response, and tool execution alongside the action Atlas took, for security, governance, and compliance teams.

Importantly, Atlas sits inline between the agent and the model that drives it. Every prompt, every model response, and every tool call flows through Atlas before it reaches its destination. That’s what makes enforcement possible in real time. Atlas is not reading logs after the fact. It is in the path, and it can stop an action before it executes.

Intent drift detection

Agent IBAC uses an LLM evaluator, the same engine behind all Atlas guardrails, to judge whether an agent's action follows from the instruction it was given. Intent drift detection includes determining whether the agent is accessing data it shouldn’t, attempting unauthorized exfiltration or download of data, or expanding the scope beyond what the user intended.

The evaluator reads the agent loop: the reasoning the agent produces, the tools it selects, and the parameters it passes to them. It then asks a simple question: “Do these steps align with the request?”

Sensitivity is tunable across three levels. Lenient gives agents room to improvise and flags only clear mismatches. Balanced is the default. Strict requires close alignment between the request and the action, and is the right setting for agents that touch regulated or high-value data.

Full-session evaluation

Agent IBAC evaluates the agent's action across the entire session: every prompt, response, and tool call. That's what allows Agent IBAC to catch intent drift that unfolds gradually, where no single action looks alarming, but the cumulative path leads somewhere the user never intended.

The same full-session view also makes it possible to detect multi-turn attacks, such as jailbreak attempts spread across several prompts that appear benign individually.

Sessions are tracked by the conversation ID the AI tool assigns, so a single evaluation can span everything from the first prompt to the last. That matters because agents carry memory forward. A later prompt can lean on context established several turns earlier, which is precisely how a patient attacker assembles a jailbreak out of pieces that each look harmless. Teams can also write their own session policies in plain language and set how many events must accumulate before evaluation runs.

Runtime guardrails & quarantine

Every intent-based detection is paired with AI runtime guardrails that take action in real time. The actions are customizable, including alerting, blocking, modifying (e.g., redacting sensitive data), logging activity, or requiring human-in-the-loop approval.

Runtime guardrails can be customized to allow low-risk drift while stopping high-risk actions. For example, a user asks an agent to summarize a customer account. The agent starts pulling records for a much larger set of accounts than requested. This isn't necessarily malicious, but the scope creep touches more sensitive data than the request warrants. In this case, Agent IBAC can flag it for human-in-the-loop approval before it proceeds.

Quarantine goes one step further. When a violation warrants more than stopping a single action, Atlas can quarantine the identity behind the session. Every prompt that follows is blocked for a window the customer sets, from a couple of minutes to a full day. Administrators see every quarantined identity in one place and can lift a quarantine, extend it, or make it permanent. Detection tells you an agent went off course. Quarantine stops the next attempt.

Complete audit trail

Atlas records every action and the intent behind it, giving investigators a complete trail: what the agent did, whether each action followed from the request, and which guardrails fired.

A conversation view shows the exchange the way the user experienced it. An execution view expands it to include the tool calls underneath, the steps that never surface in the chat window and where most agent risk actually lives.

Trust is the ultimate metric for agentic success

Agentic success in the enterprise won't be measured by how many agents get deployed. It will be measured by how many of them can be trusted.

Agent IBAC is part of how Varonis Atlas makes that possible, giving security teams a way to confirm agents are acting as intended, in real time, without slowing the business. It's one piece of Atlas' broader approach to securing the agents an organization builds and runs, alongside capabilities, like AI-SPM, AI Red Teaming, and AI Detection & Response.

Agent IBAC is available today to Varonis Atlas customers.

Data Security Scanning Performance: Why Full Coverage Doesn't Mean Slow Scans

Amanda Wicks — Fri, 31 Jul 2026 16:51:15 GMT

Key takeaways

Dynamic Data Concentration and Smart Scan work together to cut redundant scanning and surface high-risk data first.
Automated remediation is what actually closes exposure at scale — in one environment, 3 million overexposed records dropped to 2,000 in two days.
The real limit on scan speed is usually API rate limits set by the cloud provider being scanned.

Most conversations about data security scanning tend to start with one question: "How quickly can this data security platform scan our data?" It's a fair ask. Long scan times delay visibility and, therefore, the actions an organization can begin taking to reduce risk.

However, the real measure of performance is how much ground a platform covers, how quickly it surfaces the risk that matters most, and whether it features automated remediation to address what it finds.

The Varonis Data Security Platform: scanning capacity

The Varonis Data Security Platform (DSP) dynamically scales scanning capacity based on the customer's data estate. Capacity is measured in scan units, a standard measure that maps directly to compute resources. Performance scales predictably as more units are added, so doubling capacity means doubling throughput without having to guess at the underlying compute and memory requirements.

The best practice is to start small, monitor scan duration, and automatically add units only if performance doesn't meet requirements.

It's worth noting that, at Varonis, customers don't manage this math themselves. Varonis handles capacity planning and scaling in the background, so organizations see the result without needing to calculate compute requirements or provision infrastructure.

The real bottleneck is usually API throttling

Scan units are only half the story. What happens when the data itself is complex, repetitive, or sitting behind a service with its own rules about access? That's where the real gains, and the real limits, show up.

Cloud services such as Google Workspace, AWS, and Box each limit the number of API calls that can be made in a given window to protect their own systems and keep things fair across all customers. Hit that ceiling, and requests get delayed or retried. Scan duration increases, no matter how much compute is idle on the scanning side.

What that looks like in practice: A Google Workspace scan needs several API calls per file, including to download content, pull metadata, and check permissions. At a typical pace, a single collector generates roughly 342 API calls a minute. If an organization's rate limit with Google is 1,000 calls a minute, that ceiling becomes the real constraint once scanning scales past about three units. A fourth or fifth unit doesn't add speed at that point. It just runs into throttling.

This is exactly why "add more infrastructure" isn't a universal fix, and why Varonis surfaces throttling directly in the product instead of leaving a security team to guess why a scan slowed down.

Where data is being scanned also matters

The other important piece is where a scan actually runs. Some DSPs scan cloud-to-cloud by default, authenticating with an API key and pulling data across the internet into the vendor's cloud environment for scanning. Because there's no infrastructure to stand up, it can be a fast way to get started — but moving that data comes with real costs and data sovereignty concerns that DSPM vendors aren't always transparent about.

In a cloud-to-cloud model, data must cross the network to leave the customer's environment, so scanning is bound by WAN bandwidth rather than compute. It also adds egress costs, since cloud providers charge to move data out. And it means sensitive data is leaving the environment where it originated, which raises data privacy questions that matter in regulated industries.

Varonis supports cloud-to-cloud scanning for lightning fast deployment times, but many customers prefer a lightweight, Kubernetes-based private cloud collector that runs inside the customer's own cloud environment. The data being classified never leaves that environment, and only metadata returns to Varonis. That removes WAN bandwidth as a bottleneck, avoids egress fees, and keeps sensitive data within boundaries the customer already controls.

Plus, once it's deployed, the collector runs on its own. In other words, there's no ongoing tuning or manual routing decisions to make — the security and performance benefits of scanning in place are automatic.

In either case, cloud-to-cloud or private collector, scanning is agentless and does not require customers to install anything on the data stores they are scanning.

Turning data repetition into an efficiency advantage

Some of the largest data stores are also the most repetitive. Picture an organization that enables AWS CloudTrail for every account, region, and service. The logs pile up by the millions, and nearly all share the same schema and sensitivity profile.

A scanner that treats each of those files as brand new spends most of its time reconfirming what it already knows. Dynamic Data Concentration (DDC) takes a different approach. It recognizes the repeating pattern, scans enough files to be confident in the classification, and applies that finding across the rest, without reopening files that are already classified.

But let's be clear: this isn't sampling. Sampling scans a subset and extrapolates, risking the omission of rare, sensitive data hidden in the part that went unscanned. DDC still scans the full store. It just stops repeating work it's already done. In an environment where a quarter of the files qualify, that alone can lift effective throughput.

Being upfront about the tradeoffs

A few capabilities expand what a scan can see, at a cost worth knowing about upfront:

Optical character recognition reads text from scanned documents and images, closing a real blind spot, but it takes significantly more computing than native text.
Cloud Relay routes requests through a local collector to meet outbound-only connectivity requirements, adding a network hop and increased collector load that a direct connection wouldn't.
Rich permission structures and detailed metadata take longer to process, but they're also what make the resulting risk analysis trustworthy.

None of these is a reason to skip a capability. Instead, they are reasons to make the tradeoff deliberately, rather than being surprised by it later.

Speed to insight matters as much as speed to finish

Finishing a full scan quickly is nice, but finding the riskiest data sooner is better. Smart Scan prioritizes high-risk data, so the findings that matter most surface early. That means remediation can start before the scan finishes. Paired with DDC, the two work together comprehensively: Smart Scan shortens the time to the findings that matter, and DDC shortens the overall scan takes.

Both run automatically, with no configuration required. That means there's no threshold to set for what counts as repetitive and no priority list to build for what counts as high-risk. Varonis makes those calls in the background, and the customer simply sees a faster scan and the riskiest findings first.

Incremental scanning improves scan speed

Varonis uses real-time incremental scanning to dramatically reduce the time, compute resources, and cost required to classify and monitor data at scale. Rather than repeatedly scanning every object in a data store, Varonis leverages its audit trail to identify exactly which objects have been created or modified since the previous scan and then reclassifies only those changed items. This approach keeps visibility current while avoiding the inefficiency of full rescans.

Many DSP products rely on the underlying data store's delta APIs to provide a list of changed objects. However, those APIs can be inconsistent or unavailable depending on the data store.

When a reliable delta API doesn't exist, vendors are often forced to enumerate every object in the environment and check its last modified timestamp to determine what has changed, creating significant performance overhead and making large-scale scans slower, more expensive, and less reliable.

By using its own audit trail as the source of truth, Varonis maintains continuously updated classification results without depending on the limitations of each individual data store's change-tracking capabilities.

Speed to risk reduction matters most of all

Ultimately, fast scans and insights only matter if the risk they surface gets addressed at equal speed. Without automation, a scan that surfaces millions of overexposed records just creates a backlog. Now factor in AI agents, which can create new exposures faster than any security team can reasonably address, and manual remediation stops working.

Varonis addresses this with automated remediation: policy-driven actions that can close exposure across an entire environment, with scope defined by the organization rather than by the number of people available to click through tickets.

The reality is stark. In one environment, this is what automated remediation looked like:

Remediate 900,000 sensitive files within one day of a policy going into effect.
Reduce nearly 64,000 exposed folders to zero within one day.
Remove 3 million overexposed records within two days.

The scan detects the exposure, but it's automated remediation that actually reduces the risk at scale. A platform that's fast at one and slow at the other has only solved half the problem.

Varonis automatically executes more than 200 million remediation actions every month—securing more than 2 trillion sensitive data records. That’s 770,000 exposed data records protected every second.

Here are just some examples of Varonis customers who achieved rapid time-to-remediation (measured in days) with our automations.

From the first day to full scale

Getting Varonis up and running takes minutes, not days — that's the deployment story. But there's an important second chapter: what happens once data sources are connected and scanning runs continuously, at whatever scale the environment grows to. Fast onboarding helps an organization quickly find its first solution. Efficient, transparent scanning with automated remediation is what keeps that pace up as the data estate expands.

Frequently asked questions

Why factors impact data classification scanning performance?

Scan performance depends on data complexity, network conditions, and API rate limits set by the cloud provider being scanned. In many environments, those external limits constrain throughput more than compute does.

Does Varonis scan all data, or sample it?

Varonis scans the full data estate. Dynamic Data Concentration (DDC) reduces redundant reads across repetitive files while ensuring every file is accounted for. Nothing is skipped or extrapolated statistically.

Does adding more scan units always make scans faster?

Not past a certain point. API rate limits imposed by the source platform can become the binding constraint before compute does. Varonis surfaces throttling indicators directly, so organizations can find the actual bottleneck before adding infrastructure that won't help.

When AI Assistant Share Links Become Public Exposure

Varonis Threat Labs — Wed, 29 Jul 2026 17:03:24 GMT

Every major AI assistant likely includes a "Share" button. The mental model users hold is a private hand-off, like a link you paste to a colleague. However, the mental model the web holds differs and is worth exploring.

Why AI assistant share links are risky

A share link is an unauthenticated, permanent, crawlable HTTP resource sitting on a high-authority domain. The only things standing between the link and a search index is a header, a robots directive, and a vendor remembering to set both.

In corporate environments, the risk goes beyond "someone shared a link." The blast radius — how much damage is likely if a user is compromised — depends on what the user has access to before the prompt was written. Although the share link for enterprise licenses is limited, if an over-permissioned employee uses a personal AI account on a corporate device, a single shared conversation or artifact can accidentally carry sensitive files, customer context, code, tickets, or internal decisions into a public and durable surface.

The AI platform becomes the publishing layer, but the organization's permission model determines how much can leak through it.

The surface

Share endpoints are almost universally a fixed path plus a high-entropy identifier. The entropy defeats brute force — a v4 UUID is not guessable — which is irrelevant. Enumeration never happens by guessing; it happens because a crawler was allowed to fetch the page once. After the fetch, the identifier is in an index, not a namespace.

Claude share links have been indexed by various search engines, a topic that has been trending in the security industry because of its potential impact, but also because of how it was disclosed.

The findings were first discussed publicly on Reddit, which accelerated attention on the issue and prompted broader discussion around responsible disclosure practices. Attention to share links was amplified by similar exposures found in ChatGPT in 2025, and later across other AI platforms, leading many to believe the issue had been addressed industry-wide.

While major search engines reacted quickly and removed the exposed content from indexes, remediation efforts varied among platforms, with some taking longer to fully resolve the exposure.

Nearly every vendor now ships the correct headers. Share pages return <meta name="robots" content="noindex">, most add X-Robots-Tag: noindex at the edge, none publish sitemaps for the share path, and several disallow it in robots.txt. Run the baseline dorks today and the counts are a fraction of what they were.

"Noindex" is a discoverability control, not an access control. The page still resolves, unauthenticated, for anyone holding the URL.

The archives

The archives are where the story diverges from press coverage. The vendors negotiated with search engines, but almost none of them negotiated with archivists.

The Wayback Machine now excludes the bulk of the share paths for most platforms; requests were made, honored, and a large share of captures went dark. However, in some cases there are alternative domains for the same platforms that still work.

For example, https://chatgpt.com/share/* is excluded in the Wayback Machine, while https://chat.openai.com/share/* is not, and still shows the shared pages.

Look at Google: both the full https://gemini.google.com/share/* is excluded in the Wayback Machine, while the short link https://g.co/gemini/share/* is not excluded — though it is not delivering the content of the pages.

DeepSeek share pages are also still indexed and accessible via Google dorking, as mentioned in the table above.

Grok also has its shared chats indexed and accessible.

The bottom line

The share button in AI assistants was designed for quick collaboration, but in practice, it can behave like a publish button. AI-shared links can remain live for years, appear in public archives, expose sensitive topics via URLs, and survive deindexing or revocation efforts.

For organizations, the risk is not limited to whether a specific platform currently allows public conversations or artifacts. The broader issue is shadow AI usage combined with over-permissioned access. When sensitive organizational data enters personal or unmanaged AI tools, the potential blast radius depends on what that identity could access in the first place. That visibility is rarely monitored — the opposite of what it should be.

Thank you to Mark Vaitsman and Dor Yardeni for their contributions on the topic.

5 AI Security Challenges in 2026 and Why They Matter

Amanda Wicks — Fri, 24 Jul 2026 14:53:59 GMT

Key takeaways

In the AI era, AI security is data security.
AI agents access data directly, so app-level permissions no longer contain risk.
Security teams need an automated data security platform (DSP) that finds sensitive data, reduces risk, and stops threats in real time.

5 AI challenges in 2026

In 2026, the biggest AI security challenges all point to one reality: AI security is data security. AI models need broad access to enterprise data to deliver value, which opens the floodgates and increases risk. But the goal shouldn’t be to slow AI adoption. Rather, it should be to enable it safely.

Yaki Faitelson, Varonis CEO and Co-Founder, and Ron Bennatan, Varonis VP of Strategy and founder of AllTrue.ai, Guardium, and JSonar, recently sat down to discuss the evolving threat AI poses and why protecting data has become even more crucial as this technology continues accelerating. Here are five takeaways from their conversation and what they mean for security teams navigating AI adoption.

1. AI’s value poses a security conundrum

Enterprise AI requires access to data to deliver maximum value. But that access creates new risks. It’s a real conundrum: as Yaki puts it, companies that delay AI, or adopt it without proper controls, risk serious consequences. Companies can’t afford to sacrifice speed, but they also can’t afford to sacrifice security.

Why it matters: Safely enabling AI means organizations need real-time visibility into sensitive data and who — or what — can access it. Without automated data discovery, classification, and access control, AI adoption escalates risk faster than security teams can manage.

2. Applications are old-world security

Applications once served as an established control layer. They could enforce permissions, add friction, and limit direct access to data. Now, AI agents operate on behalf of users, accessing systems directly, often bypassing traditional app interfaces altogether.

Why it matters: Organizations need a data-centric approach that monitors identities, permissions, and activity across all data systems. When attackers log in using compromised identities, only data-level visibility can detect and limit the damage.

3. AI introduces non-deterministic behavior

Software is deterministic: During development and testing, a software engineer could define expected outputs and validate an app’s performance. With AI, that’s no longer the case. It’s not possible to fully validate behavior before deployment, just as it won’t be possible to anticipate every failure scenario.

Why it matters: Because AI behavior can’t be fully predicted, security teams need continuous monitoring and automated detection and response to catch abnormal activity in real time, rather than static policies that quickly become outdated.

4. AI expands the blast radius

Human error was once the primary concern. Now, organizations must contend with thousands of autonomous agents, each with access to large volumes of data, which expands the blast radius .

Why it matters: As AI expands the blast radius, a single compromised identity can expose massive amounts of data. Organizations can reduce their risk by automatically removing excessive access and right-sizing permissions.

5. Security teams need a dynamic control layer

Policies and governance provide a necessary foundation, but without automation, they create busy work rather than security. Organizations need an automated data security platform (DSP) that enforces policies, monitors agent behavior, and provides AI detection and response (AIDR) that moves as quickly as AI.

Why it matters: Policies without automation fall short of delivering real security outcomes. Only an automated data security platform can keep policies enforced as data changes, detecting and stopping threats at the speed AI operates.

Watch the full conversation:

Dolphin X Stealer Targets 300+ Apps and Profiles Users with AI

Daniel Kelley — Wed, 22 Jul 2026 13:00:01 GMT

Varonis Threat Labs discovered Dolphin X advertised on a cybercrime forum by a vendor using the alias “Kontraktnik.”

The listing claims the malware can target more than 300 applications and reaches far beyond browser passwords. Its collection capabilities include cryptocurrency wallets, .env files, SSH keys, cloud tokens, and other DevOps credentials.

A single archive can contain data from nine browsers, more than 100 wallet extensions, 65 desktop wallets, 10 password managers, and 30 cloud command-line tools. This gives the malware potential access to everything from a victim’s personal accounts to the credentials used to manage their employer’s cloud environment.

Another feature, called the “AI Profiler,” scores infected users based on their application usage, browsing activity, and installed software. Attackers receive the rankings in a daily summary, helping them identify high-value victims and decide where to focus next.

We obtained Dolphin X’s operator panel and analyzed it in an isolated lab, beginning with how the agent is built.

Remote build and mutation

The panel is a desktop client built around a configuration wizard, but nothing compiles on the operator's machine. The operator sets the agent's C2 address, installation path, persistence, and evasion options, then the client submits the configuration to backend.thedolphinx[.]top:8443, where compilation happens.

Routing every build through the vendor's server also gives the seller a place to modify each binary before it returns. The panel exposes this as an opt-in mutation engine with three tiers, the deeper two locked behind the PRO plan. The engine is off by default, and the panel itself notes that off means the same hash across all builds.

Dolphin X’s tiers are structured as follows:

The top tier claims to rewrite control flow, substitute instructions, and re-encrypt embedded strings with a fresh key, making stable byte sequences harder to identify.
The middle tier advertises shuffling the import table, which would change the binary's import hash between builds.
The lowest tier advertises rewriting PE timestamps, the Rich header, and section padding. These are the byte regions that brittle YARA rules and hash-based blocklists tend to anchor on.

Collection scope and AI profiling

The panel lists 329 features across ten categories. For defenders, however, the most important figure is the collection scope: more than 300 application targets appear under the credential-looter category. These targets range from browser logins and cryptocurrency wallets to SSH keys and cloud tokens, with the collected data staged in a single archive.

On a developer’s machine, .env files and SSH directories often contain over-scoped, long-lived credentials that can provide access to cloud consoles, build pipelines, and production data.

Beyond credential collection, the panel includes a surveillance tab containing the AI Profiler. The seller describes it as an “AI behavioral profiler with app usage tracking, risk score, and daily summary.”

In practice, the feature appears designed to help operators triage victims.

A cybercriminal may control thousands of infected machines, far more than they could review manually. The profiler acts like an automated warehouse sorter, scoring and tagging each victim before returning a ranked list of the most valuable machines to investigate first. The risk score and daily summary determine that order.

Defenses and conclusion

Dolphin X’s collection scope reaches well beyond browser passwords to SSH keys, cloud tokens, and DevOps credentials. On the wrong machine, a single infection could expose access to an entire production environment.

Its use of AI is also interesting because it shows us how AI is being integrated into more cybercrime tooling. We saw this with SpamGPT and Bluekit, and now with Dolphin X as well.

The practical response for security teams comes down to two things:

Keep long-lived credentials off disk wherever possible, especially out of project directories and local credential stores. Infostealers are designed to grab everything in one pass, so anything stored locally should be treated as potentially exposed.
Focus detection on behavior rather than file signatures. For example, explorer.exe running under a non-default desktop is a strong indicator of an HVNC session, regardless of how the malware binary is packed or what hash it uses.

Indicators of compromise

The controlled panel run and its traffic capture exposed several operator-side indicators.

MITRE ATT&CK techniques

The mapping below is a detection reference for this class of tool. Every row is a capability the listing advertises or the panel exposes, so it points to where to look.

Note: We analyzed the operator panel and its network traffic, not a sample running on an infected machine. Unless stated otherwise, agent capabilities described above are exposed by the builder or claimed in the vendor’s documentation rather than independently confirmed in execution.

Stay up to date on the threat landscape by following Varonis Threat Labs.

A Look Inside the Hugging Face Breach

Varonis Threat Labs — Mon, 20 Jul 2026 20:15:20 GMT

Key takeaways

On July 16, 2026, Hugging Face disclosed a security breach in which an autonomous AI attacker infiltrated its internal infrastructure.
The attacker chained two remote code execution (RCE) vulnerabilities in Hugging Face's dataset processing pipeline, leaked cloud and cluster credentials, moved laterally into internal clusters, and even generated decoy activity to slow investigators down.
Hugging Face caught it with its own AI: an anomaly-detection pipeline that uses LLM-based triage to correlate security telemetry. Attacker AI versus defender AI.
To investigate, Hugging Face moved to deploy an open-weight LLM on its own infrastructure because foundation-model guardrails refused to process the malicious payloads pulled from its logs.
What to do now: Rotate API access tokens, apply least privilege to AI workloads, treat downloaded models and datasets as untrusted code, and hunt for reconnaissance fingerprints inside your ML pipelines.

AI vs AI

For years, "AI security" meant defenders using machine learning to chase human attackers. The Hugging Face breach flips that script. This is one of the first public incidents where an autonomous AI attacker went head-to-head with an AI-driven defender, and both were moving at machine speed.

The attacker chained together classic vulnerabilities and drove them autonomously, compressing a weeks-long campaign into seconds. The defender answered with AI of its own. In the middle of that fight, Hugging Face hit a wall that every security team should think hard about: one that has nothing to do with how much talent or tooling you have, and everything to do with whether the AI on your side is allowed to help.

The attack chain is precise, reproducible, and targeted at the infrastructure that thousands of organizations rely on every day. It's worth understanding in detail.

What happened

Hugging Face recently disclosed that an autonomous AI attacker had infiltrated its internal infrastructure. A limited set of internal datasets were accessed, and several service credentials were leaked. The attacker didn't just smash and grab; it generated decoy activity designed to hide real impact in noise and stall the investigation.

Hugging Face's AI-assisted threat detection system flagged a compromise in its cloud infrastructure. HuggingFace ran LLM-driven analysis agents over the logs to extract indicators of compromise (IOCs) and separate genuine attacker impact from the decoy actions.

Hugging Face contained the attack, fixed the vulnerability that enabled initial access, and removed the attacker's foothold from the affected infrastructure. It's recommended that users rotate API access tokens and report any unusual account activity.

The how is where this incident stops being routine.

What we know so far

Once Hugging Face's analysis agents worked through the logs, the attack was attributed to an autonomous AI attack that exploited two remote code execution vulnerabilities in the dataset processing pipeline.

Remote-code dataset loader: ML datasets frequently ship with custom loading scripts that run automatically when the dataset is ingested. The attacker abused Hugging Face's remote-code loader to execute its own code, turning a routine ingestion step into arbitrary execution.
Template injection in a dataset configuration: The attacker injected a malicious configuration into a dataset config file. When the platform processed that file, it executed an attacker-controlled payload.

From that initial foothold, the attack escalated:

The attacker's framework operated as a distributed command-and-control (C2) environment, leveraging dynamic, short-lived endpoints.
It exfiltrated cloud and cluster credentials and moved laterally into several internal clusters.
It generated decoy activity to complicate attribution and impact analysis.

Why this matters

The Hugging Face attack exploits classic security vulnerabilities and shows how AI-assisted attackers can now rapidly exploit them to spread across entire cloud infrastructure. Attacks that once took weeks now take seconds.

It also lands on a uniquely dangerous target. Hugging Face is a shared AI platform where thousands of organizations download models and datasets every day. An attack against a hub like this doesn't have to be contained to the hub; the same malicious dataset or model could be delivered to anyone who pulls from it. The blast radius of a supply-chain-adjacent compromise here is enormous.

The question is no longer whether this threat exists. It is whether you would see it coming.

Guardrails cut both ways: the detail everyone should remember

Imagine a fire breaks out in your office building. The flames are spreading fast, consuming the first floor and moving toward your critical server room. You call the fire department, and they arrive with all their state-of-the-art equipment. However, the fire chief walks up to the front doors and pulls out a thermal sensor, reading that the temperature inside is too high. They tell you their safety protocols absolutely prohibit them from entering. Then they pack up and leave, and you're standing there alone with a bucket of water.

To investigate the attack, Hugging Face defenders found that the guardrails baked into commercial foundation models were triggered by the malicious payloads sitting in their own logs. The safety mechanisms designed to prevent misuse also prevented defensive use. The fire department wouldn't enter the building. Hugging Face's answer was to deploy an open-weight LLM on its own infrastructure and press on.

It is difficult for an organization to spin up a powerful, unguarded LLM on demand, feed it the right telemetry, and train a team to drive it against a live, machine-speed attacker, all while that attacker is still moving. Building that capability from scratch and in the moment is a losing race.

The realistic answer is to have the firepower ready before the alarm sounds. The same applies to a security platform whose AI is already built, trained, and not blinded by consumer guardrails.

Actions to take this week

Apply least privilege to AI workloads: Processing workers should not have access to cloud credentials, cluster tokens, or internal systems beyond what they strictly need. If a worker is compromised, the blast radius should stop there.
Don't treat the node boundary as a security boundary: Cluster nodes do not need an excess of cloud credentials. The access-control policy granted to a node is not a boundary for the jobs running inside it. Workloads should stay isolated from one another and from their underlying runtime.
Treat AI artifacts like untrusted code: Any model or dataset your team downloads from a shared platform should go through review before it touches your infrastructure, through the same process you would vet a third-party library or open-source dependency.
Hunt for unusual access patterns around AI infrastructure: Look for intent-drift. Unexpected reads of environment variables, cloud metadata endpoints, or secret stores from processes running inside ML workloads may indicate a compromise. Attackers who land on a processing worker typically probe the environment immediately to map what credentials and internal systems they can reach. That reconnaissance has a detectable fingerprint you should look out for.

How Varonis helps protect agentic workloads

Hugging Face had the talent and the infrastructure to improvise a defense. Most organizations don't and shouldn't have to.

Varonis operates with AI-driven analysis at the core of its detection engine. That gives security teams the same capability Hugging Face needed in the moment: the ability to surface, correlate, and investigate high-volume attacker activity fast. No waiting days for a human analyst to dig through logs. No guardrails that block you from investigating the payloads you need to understand.

Data is what attackers are looking for, and Varonis protects it wherever it lives, from cloud API usage to container data flows to agent prompts. Our DSPM-first approach means you can see when internal datasets, secret stores, and cloud credentials are accessed by processes that have no business accessing them, which is exactly what happened to HuggingFace's own infrastructure.

Varonis approaches agentic workload protection with Agent Intent-Based Access Control (IBAC), in which every AI agent action is evaluated against its approved business purpose, data boundaries, and prohibited operations. When an agent suddenly exports all data or retries after being blocked, the system flags it as behavioral drift, not an isolated incident. That's the same signal you'd see in a classic attack: an RCE on a HuggingFace compute node, where a routine worker starts behaving like an attacker, but this time against a much more volatile AI agent.

For multi-stage campaigns, Varonis also monitors session trajectories. If an AI agent's tool calls progressively escalate toward unauthorized operations, the pattern surfaces at machine speed, because the attacker is moving at machine speed too.

Update from July 21

Last week's incident looks more like an accident than an attack, OpenAI now says.

They found that one of the AI models participating in the attack included GPT-5.6 Sol with reduced cyber refusal guardrails for testing on ExploitGym, an AI benchmark of cyber capabilities.

OpenAI used a third-party proxy to allow the models the ability to install packages in their sandboxed testing environment without providing them with full internet access. These models sought free internet access and, in the process, discovered a zero-day vulnerability in this proxy. Exploiting this vulnerability allowed them to escalate privileges and move laterally in OpenAI’s testing environment until they reached a node with internet access.

The model acted like a real team of hackers. They chained together stolen credentials and zero-day vulnerabilities they identified on Hugging Face to execute code on internal Hugging Face servers. They were looking for ways to cheat the evaluation by hacking into Hugging Face and stealing the solutions for the ExploitGym benchmark. OpenAI is implementing controls in its testing environments to prevent similar incidents from occurring once more.

Following this incident, OpenAI plans to tighten controls on its testing environments. A company statement said, "AI is accelerating the discovery and exploitation of vulnerabilities... model security and safety must keep pace with rapidly advancing capabilities."

Don't wait for a breach to occur

The Hugging Face breach is a preview of the next phase of security. Autonomous attackers probing shared AI infrastructure, and defenders who win or lose based on whether their own AI is ready to fight back in real time.

We will update this post as Hugging Face shares more. If you are a Hugging Face customer who is not currently using Varonis and need assistance, please reach out to our team.

Thank you to Gavriel Fried, Cloud Security Researcher, and Tal Peleg, Cloud Security Team Lead, for sharing these insights.

Email Security Needs Proof, Not Static Detection: Takeaways from SACR's Email Security Report

Meagan Huebner — Mon, 20 Jul 2026 17:55:31 GMT

Varonis security brief

Perimeter-based email defenses miss AI-generated attacks that carry no obvious malicious link or attachment.
A new report from Software Analyst Cyber Research (SACR) says email security must shift from detecting bad messages to investigating how an attack unfolds.
SACR highlights Varonis Interceptor as an example of this shift because it uses an AI Phishing Sandbox that follows an attack through to the credential-harvesting page a user would actually land on.

Email security is undergoing a fundamental shift — from static defense to an approach built around identity, context, and evidence — now that attackers have learned to exploit trust, identity, and human judgment to circumvent traditional perimeter-based detection.

Software Analyst Cyber Research (SACR) illustrates why in a new report titled From Perimeter to Proof: The New Architecture of Email Security. In it, Anna Perrone, Research Associate/Business Process Analyst at SACR, examines a new generation of email security architectures designed to address the business workflows attackers now regularly exploit through email.

Perrone looks at key vendors that represent the new generation of email security, including Varonis Interceptor. The email security solution is highlighted for approaching phishing not as a standalone email problem, but as the first stage of a broader attack chain that can lead to credential theft, data exposure, privilege escalation, or business-process compromise.

Perimeter-based email security is not enough

Traditional email security was built around static detection and perimeter-based defenses. These solutions identify known threats, flag suspicious messages, and rely on users or downstream controls to respond. But this model is increasingly ineffective against modern attacks.

The report identifies context as the core gap in that model. Perimeter-based, content-detection-driven systems are designed to catch known indicators at the point of entry. These solutions have limited ability to evaluate attacks that lack obvious signals like malicious links or attachments. As attackers increasingly use AI to create novel attacks that abuse trusted relationships and communication patterns, context becomes the deciding factor in whether an interaction is legitimate or malicious.

Email security must move from binary blocking to contextual understanding

Because attackers have adapted to the controls organizations already deployed, SACR argues that email security must expand what it's expected to understand — from binary blocking to a contextual read on identity, relationships, workflow, intent, and behavior.

That context matters because many modern attacks are designed to look ordinary at the message level. A vendor invoice, password reset, shared document, or executive request may not contain an obvious malicious attachment or known-bad link. The risk comes from how the message fits into a broader pattern: who appears to be involved, what action is being requested, whether the workflow makes sense, and how the interaction could expose credentials, data, or business processes if the user engages.

Varonis Interceptor: from detection to investigation

The SACR report highlights Varonis Interceptor as a leading example of the shift it sees reshaping the email security market.

According to the report, Varonis approaches phishing not as a standalone messaging problem, but as the first stage of a broader attack chain that often culminates in credential theft, data exposure, privilege escalation, or business-process compromise. That framing, SACR argues, requires more than determining whether a single message is malicious — it requires understanding how attacks work, not simply whether they exist.

The report describes Interceptor's architecture as built around that premise. Rather than relying on one detection method, the platform analyzes inbound communications using multiple detection layers — language models, visual analysis, infrastructure inspection, URL detonation, and behavioral indicators — to build a fuller picture of an attack before reaching a verdict.

To illustrate why this matters, the report walks through a scenario: a QR-code phishing attack that starts in an email, directs the user toward a trusted cloud service, routes them through several redirects, and ultimately lands on a credential-harvesting page built to mimic a familiar business application. At each individual step, the infrastructure involved looks legitimate, which is why the report argues that understanding how the stages connect matters more than evaluating any one link or domain in isolation.

This exact challenge is one that SACR says Interceptor addresses with its AI Phishing Sandbox. The report notes it's designed to interact with phishing pages the way a person would. Interceptor follows every redirect, working through credential-capture forms, and surfacing multi-step attack paths to determine what a user would actually encounter if they followed the attack through to the end.

The report notes this extends beyond the inbox as well: Interceptor's browser-oriented capabilities let it observe what users encounter after clicking a link, rather than stopping at the message itself. This gives security teams visibility into the full user journey that message inspection alone would miss.

Why SACR says this matters now

Phishing is becoming an identity and data problem, not just an inbox problem.

The report points to Interceptor's data-security lineage as a distinct advantage: Varonis' data-centric background gives it a natural path into the questions that matter once an account is compromised — what sensitive data that account could reach, and whether the incident created broader exposure.
Attacks no longer stay in one place.

SACR's broader thesis is that today's attacks rarely stop at the inbox — a phishing email can lead to credential theft, identity compromise, and data exposure in the same incident. The report positions Interceptor as built to help teams answer the questions that follow: how the attack was delivered, what infrastructure was involved, whether users interacted with it, and what other systems may have been touched.
AI has changed what a "suspicious" email looks like.

The report ties this to its broader argument that generative AI has changed the cost structure of phishing, producing messages that are more personalized, more grammatically clean, and harder to distinguish from legitimate business communication. SACR frames Interceptor's multimodal, behavior-based analysis as a direct response to the fact that static, template-based detection struggles once every message can look slightly different.

The future of email security is proof-driven

SACR's report concludes that the future of email security won't be defined by a single architecture, but by how effectively different approaches help organizations understand attacks, respond efficiently, and reduce risk across an increasingly complex communication environment.

Central to that argument is a shift the report identifies across the market as a whole: explainability is becoming a procurement requirement. Organizations need to know why a platform reached a conclusion, what evidence backs it up, and how a response decision can be defended to executives, auditors, regulators, and cyber insurers.

Varonis Interceptor is presented in the report as one vendor built around that emerging generation of email security. Varonis applies an approach SACR characterizes as treating phishing detection, investigation, evidence generation, and remediation as connected parts of a single workflow, rather than isolated detection events.

AI Agents Are Creating a New Class of Employee Risk

Ron Bennatan — Tue, 14 Jul 2026 15:47:03 GMT

Key takeaways

AI agents are creating a new digital workforce, rapidly increasing the number of non-human identities accessing sensitive data.

As AI becomes more autonomous, security shifts from controlling access to controlling actions and intent.
Organizations need a data-centric security layer that enforces policy, reduces risk, and enables safe AI adoption.

AI agents: the new digital employee risk

Human error has traditionally posed the greatest risk in cybersecurity, fueling breaches through compromised identities and excessive access to sensitive data. Now imagine an employee who works around the clock unsupervised, has access to stores of private data, and acts without permission. Welcome to the era of the AI agent — a new class of digital employee actively changing the internal threat landscape.

AI agents are actively transforming how risk is created. Look at PocketOS for example. One morning, the founder woke up to discover that Cursor, a coding tool, had deleted the business, including the database and all backups. It was not acting maliciously. It had simply found a discrepancy while performing a routine task and had both the initiative and autonomy to make a decision with dire consequences.

Securing AI requires a fundamentally different approach, one that establishes additional guardrails, provides visibility into data access, and determines whether an action should be taken in the first place. To first understand the risk AI agents pose, it’s important to break down how they behave in enterprise environments.

AI agents act autonomously on data

AI agents are more intelligent than previous models and more autonomous. With access to enterprise data systems, they’re deciding how to use it and what actions to take next. This doesn’t just increase the speed of risk — it changes how risk is created.

When actions are executed at machine speed and scale, even small mistakes or misconfigurations can have an outsized impact. That’s why traditional, static controls fall short in an AI-driven environment.

AI agents execute without enough guardrails

AI agents reliably execute tasks. But they don’t inherently understand risk or policy. Without consistent guardrails, agents will act on incomplete or incorrect context, especially when interacting with large volumes of enterprise and external data.

Relying on model safeguards alone is not enough. Organizations need data-level controls that enforce policy across identities and systems in real-time, regardless of how agents behave.

You can’t measure AI risk without data access

Without visibility into data access, it’s impossible to fully measure AI risk — or understand the potential impact of an agent’s actions. Protecting enterprise data in the age of agentic AI means shifting from access-based questions to action-based ones. In other words, how data is used and whether those actions are appropriate in a given context.

Security must evolve from access to intent

Agentic AI systems operate dynamically, making decisions and taking action at unprecedented speeds. Static policies and predefined controls are no longer sufficient. Securing AI requires a data-centric approach that connects data sensitivity, permissions, identity, and activity to determine whether an action should be allowed. Without that context, organizations can’t reliably assess risk or stop unsafe behavior before sensitive data is exposed. This is why security must move closer to the data itself.

The organizations that succeed in this new era will be those ensuring AI adoption is secure, compliant, and trustworthy.