Varonis Blog

IBM’s Cost of a Data Breach Report 2026: AI Is Now the Attacker and the Target

Ron Bennatan — Wed, 14 Oct 2026 14:21:52 GMT

Key takeaways

AI-driven attacks rose 56% since last year's Report, with shadow AI incidents more than doubling to 43%.

The majority of AI-related breaches (92%) involved no proper AI access controls, making access and governance gaps the real driver of AI breach costs.
Organizations that applied AI and automation extensively across their security lifecycle cut breach costs by $1.93 million.

What is the IBM Cost of a Data Breach Report?

IBM's Cost of a Data Breach Report 2026, researched independently by Ponemon Institute, is the security industry's longest-running benchmark for breach economics.

This year's edition studied 602 organizations across 17 industries, drawing on interviews with 3,558 security and C-suite leaders with firsthand knowledge of a breach at their organization between March 2025 and February 2026.

The global average cost of a data breach reached a new record this year — $4.99 million, up 12% from last year.

The rise of machine-speed attacks

The rise of AI has brought about the rise of AI-driven attacks, which increased by 56%. More than one in four organizations that experienced a malicious attack this year said it resulted from AI.

Deepfake impersonation and AI-generated malware were behind most of that volume, and the financial consequence was direct, adding an average of $1 million per breach.

How AI lowered the bar for a convincing attack

Generative AI has lowered the cost, time, and skill required to launch a convincing attack, and attackers are now running them continuously and at scale rather than as isolated attempts.

It's a pattern Varonis Threat Labs has been tracking this year, including Reprompt, a single-click Copilot exploit that silently exfiltrated data, and CoSnitch, which showed how a compromised AI assistant could be turned into its own data leak. Both attacks required a single click to succeed, and neither relied on stolen credentials or custom malware — a sign of how little technical skill a modern AI exploit now demands.

The most expensive attacks target what surrounds the model

Among organizations that reported an AI-related breach, the root cause was rarely the model itself. Instead, it turned out to be the environment around it: compromised APIs, connected applications, and cloud misconfigurations.

The costliest security incidents were inversion attacks, which averaged $6.07 million, and prompt injection attacks, which averaged $5.89 million. These are attacks on trust in the system itself, which pushes remediation past technical recovery into governance and disclosure.

Varonis Threat Labs has also documented this pattern — its SearchLeak research found that a Copilot exploit let an attacker inherit the victim’s full permissions, not because the model was flawed, but because of what it was connected to.

Most AI-related breaches had no AI access controls

This year's report found that 92% of AI-related breaches involved no proper AI access controls, and only 40% of organizations reported using access controls on AI models and data at all. That gap should carry the most weight with security leadership, since it points to the single clearest driver of AI breach costs.

Still, it persists despite identity and access management being reported as one of the most effective cost reducers across breaches overall, suggesting the issue has more to do with execution than awareness.

Governance gaps compound the access control problem

AI governance — covering access controls for models, agents, and applications, plus monitoring for data leaks — was absent at 68% of breached organizations this year (up from 63% last year). Only about a third of organizations with any AI policy had strict approval processes for deploying it, and just 19% reported that governance and security teams actually coordinate with each other.

AI systems have outpaced the access models meant to govern them. But it's access control that determines whether an AI system can reach sensitive data in the first place — which is exactly the gap Varonis’ guidance on least privilege for AI agents is built to close.

Shadow AI incidents more than doubled

Security incidents involving shadow AI — employees using AI tools that were never approved or reviewed — more than doubled to 43% this year (up from 20% last year), and these incidents also got more expensive, averaging $5.39 million compared to $4.63 million last year. Nearly half led to data loss or compromise, and regulators are starting to respond: about one in five shadow AI incidents this year resulted in a reported fine.

Shadow AI is less an AI problem than a visibility problem AI has made urgent. The fix isn’t a policy memo telling employees to stop — it’s visibility into what’s touching sensitive data, approved or not, paired with the ability to act on that in real time.

Critical infrastructure and on-premises data remain high-risk targets

By industry, financial services and energy accounted for 62% of all AI-driven breaches studied, with average costs of $6.29 million and $5.2 million respectively. Both sectors identify and contain breaches roughly four weeks faster than the global average, but their deep interdependence with the rest of the economy means a disruption in one doesn’t stay contained to a single balance sheet.

Breaches involving on-premises data storage also grew this year, now present in 30% of breaches, up from 28% last year and 20% in 2024. Although many organizations still treat on-premises storage as inherently safer than the cloud, this year’s data doesn’t support that belief. On-prem environments place the full burden of patching, physical security, and access management on internal IT with no shared responsibility model to offset it.

AI and automation remain the most effective cost reducer

Combating AI-driven attacks requires AI and automation. Organizations that used both extensively across their security lifecycle shortened breach timelines by 65 days and reduced average costs by $1.93 million compared to those that did not — the strongest cost-reduction signal in this year's report.

But the catch is “extensively.” Only 36% of breached organizations applied these tools across prevention, detection, investigation, and response, and most of that use clustered in detection and investigation.

Half of breached organizations have deployed AI agents in their SOC, yet only 18% have applied them to vulnerability scanning and management — exactly where frontier model capabilities are shifting the advantage toward attackers. Varonis’ own Triage Agent research points to the same conclusion: Agentic AI delivers the most value when it’s applied across the full investigation lifecycle, not merely one stage of it.

What this means for security teams building AI programs

Taken together, these findings point to one conclusion: control over where AI systems run, how they process data, and who can access them has become a baseline security requirement.

More than half of organizations now plan to invest in AI security and governance tools following a breach — an 88% increase from last year — and 85% plan to increase security spending specifically in response to frontier AI model threats.

How Varonis helps close the AI access control gap

The report’s clearest signal is also its most actionable: access control, not model sophistication, is what separates costly AI breaches from contained ones. Varonis addresses that gap directly, treating AI security as data security, so access decisions account for both what an AI system can do and what sensitive data it can reach:

Varonis Atlas continuously discovers every AI model, agent, and tool in your environment — including shadow AI — and enforces real-time policy through an inline AI Gateway, closing the visibility gap behind this year’s doubling in shadow AI incidents.

Agent intent-based access control compares what an agent was asked to do against what it actually reaches for, enforcing least privilege at runtime rather than only at provisioning — directly addressing the 92% access-control gap behind this year’s costliest AI breaches.

The Varonis Data Security Platform discovers and classifies sensitive data, maps blast radius, and automatically remediates excessive and stale permissions, so access controls are grounded in what data an identity — human or AI — can actually reach.

Varonis automatically executes more than 200 million remediation actions every month, giving security teams the automated, continuous enforcement this report shows most organizations still lack.

Least Privilege for AI Agents: A Practical Guide for Security Leaders

Amanda Wicks — Wed, 07 Oct 2026 18:59:54 GMT

Key takeaways

Least privilege for AI agents gives each agent its own identity and only the access a specific task needs, for only as long as that task runs.
Human-centric access models break down for agents, which inherit user permissions, run on shared service accounts, and act at machine speed. OWASP names excessive permissions as a root cause of excessive agency.
Scoping access at provisioning is only the start. Pair it with runtime enforcement, human approval for high-impact actions, and continuous right-sizing of the data each agent can reach.

As AI agents further integrate into day-to-day workflows, the question of access becomes a critical one. Currently, adoption is moving faster than governance. A SailPoint survey of 353 professionals, conducted by Dimensional Research, found that only 44% of organizations reported having policies in place to secure agents.

Most identity and access controls were built for people, and agents are non-human identities created in code that can act independently at machine speed. For an agent, the access it inherits is the exposure.

What is least privilege for AI agents?

Least privilege for AI agents is the practice of granting every agent, tool, and connection only the minimum access necessary to perform its operation. In practice, each agent has its own identity, access scoped to a specific task, permissions that expire when the task ends, and runtime checks on high-impact actions.

Guidance around AI systems already outlines the importance of least privilege. Deploying AI Systems Securely guidance, developed with multi-country agencies including the FBI and the National Security Agency, recommends that organizations "Enforce strict access controls and API security for the AI system, employing the concepts of least privilege and defense-in-depth."

Given that AI security starts with data security, it's important to add a data dimension to that definition: An agent's least privilege needs to be measured by the sensitive data it can reach, as well as by the tools it can call. As David Gibson has written, "AI doesn't create data risk. It finds it, surfaces it, and acts on it — faster and more thoroughly than any human ever could."

Taken together, these pieces point to the same conclusion: least privilege for agents isn't just about limiting what they can do — it's about limiting what they can reach.

How least privilege for agents differs from least privilege for employees

Least privilege is one principle now applied to two different identities. While employees sign in as themselves, agents often run on shared credentials that don't map cleanly to any individual. Here's how that gap plays out:

What it looks like in practice: Consider an internal IT help desk agent connected through a shared admin service account. The agent was built to reset passwords and troubleshoot login issues, but that service account also has standing access to the company's HR system and finance records. The agent was never designed to touch either. But now it can, and because it reasons over whatever data it's handed, it's only a matter of time before it does.

The risk least privilege addresses

The OWASP GenAI Security Project lists excessive agency as its sixth most critical LLM risk, stating that the root cause is often "excessive functionality; excessive permissions; excessive autonomy":

Excessive functionality: The agent has tools the task doesn't need.
Excessive permissions: Limit extension permissions to other systems.
Excessive autonomy: Require a human to approve any high-impact actions prior to execution.

These controls matter most under prompt injection. Varonis Threat Labs' SearchLeak research found that because Copilot Enterprise operates with the user's full graph permissions, "the attacker effectively inherits the victim's access to the organization's data." In that case, least privilege limits what an attacker who has manipulated the agent can reach.

Why AI agents break traditional access controls

The risk of agentic access isn't a hypothetical concern. In the SailPoint survey, 80% of respondents said their AI agents had taken unintended actions. Token Security commissioned a Cloud Security Alliance survey of 418 IT and security professionals, which found that 65% had experienced AI agent-related incidents in the past year.

Varonis' 2025 State of Data Security Report measured the data layer directly, examining the blast radius of 1,000 organizations. It found that "1 in 10 user or service accounts can freely export any and all data." Put an agent on one of those accounts, and you've effectively hired a new employee — one with no onboarding and no sense of what it shouldn't touch.

Human-centric identity and access management wasn't built for that, and it breaks down for agents in the following ways:

Inherited permissions: An agent acting for a user inherits that user's full access, including any excessive permissions that have sat dormant.
Shared service accounts and API keys: Actions can't be traced to one accountable identity.
Standing access that outlives its purpose: Consider a service account that was provisioned years ago with broad read access for a reporting tool, but the tool has since been decommissioned even though access was never revoked.
Unknown agents: You can't scope access for agents you haven't found. The CSA finding on unknown agents shows how common that blind spot is.

Agents need controls that account for what they do, as well as what they can reach.

4 best practices for scoping agentic AI access

Four controls keep an agent in check: identity, task scope, runtime enforcement, and human approval for high-impact actions. Here's how each one works.

1. Give every agent its own identity and an accountable owner

Every agent needs a distinct identity. Shared tokens and reused human credentials make it hard to tell one agent's actions from another's — or from the user's.

Identity gets harder in multi-agent and MCP setups, where a human's broad access shouldn't automatically extend to the agent acting on their behalf. MCP servers should enforce per-agent authentication rather than shared tokens, apply explicit role boundaries for each agent, and require continuous reauthentication in long-running sessions.

Because agents aren't accountable, a named human owner has to be. That owner approves the agent's scope and answers for what it does.

2. Scope access to the task, then let it expire

Task scoping sets how much access an agent gets. The OWASP AI Agent Security Cheat Sheet advises: "Grant agents the minimum tools required for their specific task. Implement per-tool permission scoping (read-only vs. write, specific resources)."

Ephemeral access sets how long the agent keeps it. Access is granted for a task or session and ends when the task does, so no standing grants remain. Standing grants are the wrong default because stale access accumulates. A summarization agent needs read access to one account's records — it doesn't need the full customer database, and it doesn't need write access at all.

3. Enforce least privilege at runtime

Static permissions can't stop an agent that finds ways to work around them — for example, by elevating its own privileges or acting on data it was never meant to touch.

Intent-based access control compares what an agent was asked to do with what it reaches for. Say a user asks an agent to summarize a customer account, and the agent starts pulling records for a much larger set of accounts. Runtime enforcement can flag that scope creep for human approval before it proceeds. But monitoring also requires context to answer whether an agent should be allowed to take action on the data it accesses.

4. Require human approval for high-impact actions

The OWASP cheat sheet says to "Require explicit approval for high-impact or irreversible actions." It also says to "Set autonomy boundaries based on action risk levels." This aligns with OWASP's guidance around excessive autonomy.

Good candidates for approval include scenarios like deleting data, changing permissions, and creating roles and grants. Exporting sensitive records and sending data to external destinations belong on the list, too, because those types of incidents continue to occur.

Keep the approval set small so agents stay useful. Approval tiers work best when they follow data sensitivity as well as the type of action.

How to implement least privilege for AI agents

The steps below are a sequence, rather than a checklist, so skipping ahead leaves gaps later steps can't close.

Discover and inventory every agent, including unsanctioned ones: You can't scope access for agents you haven't found.
Map what each agent's identity can reach: Measure access by the data behind it.
Assign a unique identity and an accountable owner to each agent: Retire shared service accounts and API keys. Every action should trace to one agent and one responsible person.
Remove excessive and stale permissions, and automate it: Agents often create exposures faster than teams can address them. Use automated least privilege enforcement to keep pace.
Scope access per task, time-box it, and gate high-impact actions: Grant per-tool access, read-only by default, and let it expire when the task ends. Require approval for deletions, permission changes, and exports.
Monitor at runtime, re-certify continuously, and test revocation: Log every prompt, response, and tool call, with data context. Revisit scopes whenever an agent's tools, data connections, or model change. Confirm you can quarantine or revoke an agent's identity quickly.

Common mistakes that undermine least privilege for AI agents

Watch out for the following five mistakes:

Using the invoking user's permissions as the agent's ceiling: Consider a Claude agent connected to a company's file storage through an MCP server. The agent was set up to answer questions about open projects, but the MCP server grants access to every file the connecting service account can reach, including HR and legal documents.
Sharing service accounts and API keys across agents: Shared credentials remove attribution. No one can tell which agent took which action.
Scoping once and never revisiting: Because AI components change so frequently, their configurations drift out of date faster than traditional infrastructure does.
Treating logs as governance: Logs record activity without stopping it. Monitoring that lacks context can't tell friend from threat, and context that can't trigger a response can't stop one.
Securing the AI layer but not the data: When a fully authorized agent reaches millions of customer records, that data was simply exposed and available in the first place.

How Varonis helps enforce least privilege for AI agents

Least privilege for AI agents depends on two kinds of context: what the agent is doing, and which data it can reach. Varonis Atlas secures AI and the data that powers it.

Here's what it covers on the agent side:

Continuous discovery of all AI models, agents, and tools, both approved and unsanctioned
Visibility into what sensitive data they can access and which identities use them
Real-time policy enforcement through an inline AI Gateway
Audit trails and lineage graphs
Agent IBAC, with intent drift detection, quarantine, and runtime guardrails that can "alert, block, modify, log, or route an action to a person for approval"

The other half of that context is the data itself — what's sensitive, who can reach it, and how it's being used. That's where the Varonis Data Security Platform comes in, with:

Discovery and classification of sensitive data
Blast radius mapping
Automated removal of excessive permissions and fixes for misconfigurations
Monitoring of all data activity, with normalized, searchable audit trails

Together, automated remediation and inline runtime enforcement let you apply least privilege continuously — not just at the moment an agent is provisioned, but for as long as it keeps running.

Access Governance: Reducing Attacker Reach in the Age of AI-Accelerated Threats

Collaborative Article — Mon, 05 Oct 2026 14:10:07 GMT

Key takeaways

You won't patch your way out of AI-accelerated threats. Reducing attacker reach matters more than ever.
Blast radius is the metric that matters. The less an identity can access, the less damage an attacker can do.
Every AI agent is an identity problem. New AI-powered access paths require the same visibility, governance, and control as human users.

Why data security and access governance are foundational to modern resilience

AI is reshaping what adversaries can accomplish in a short period of time. Models that help defenders write code, summarize logs, and triage alerts can also help adversaries discover vulnerabilities, generate exploit paths, and orchestrate campaigns across multiple targets. The pace of attack is no longer constrained by human effort alone.

Organizations are rightly investing in vulnerability, exposure, and patch management. Closing the window between disclosure and exploitation is increasingly important, but no program can address each exposure before it is tested. The defining question is not only whether an identity can be compromised, but what it can reach afterward. Leaders should therefore strengthen the zero-trust foundation beneath resilience: a current view of sensitive data, disciplined access, and visibility into its use.

Why reframing the foundation matters now

AI-assisted vulnerability discovery is increasing the volume of findings entering patch pipelines while the interval between disclosure and exploitation shrinks. Backlogs will likely remain a reality and a priority for security leaders.

When an exposure yields a credential, access governance often determines whether the exploit becomes an incident. That layer is shaped by three questions each executive team should be prepared to answer:

Locate: Where does our sensitive data live across cloud, SaaS, on-premises, and AI training and retrieval stores? Establish a current baseline of sensitive data and exposure.
Govern: Who, human or non-human, has access to it, and is that access still justified today? Identify stale, excessive, or inherited access before it expands into an incident.
Detect: Would we know quickly if someone began accessing it in a way that did not fit normal patterns? Connect data-layer behavior to timely investigation and containment.

What the reframed foundation means in practice

Sensitive data moves continuously into collaboration platforms, SaaS, AI training sets, vector stores, and third-party integrations, often faster than inventories can keep up. Continuous discovery creates a defensible baseline of where that data lives, who can reach it, and how exposed it is, frequently surfacing enough risk to justify prompt action.

Visibility also enables data minimization. Removing duplicated, outdated, or no-longer-relevant data lowers risk before additional controls are applied: less data to safeguard, govern, and lose.

Access is the next layer of leverage. At machine speed, what a compromised identity can reach may matter more than how it was compromised. Reducing excess access to high-risk data stores can deliver early gains and should extend to service accounts, API keys, non-human identities, and AI agents, an area that often remains under-addressed.

AI agents make access governance more dynamic because they may operate through delegated user permissions, service identities, APIs, and connected tools. As agentic use cases expand, programs should govern the agent’s identity, authorization scope and duration, and audit trail. When agents retrieve enterprise information, the effective boundary reflects both what the user requests and what the agent and its tools may access or act upon.

Endpoint and network telemetry remain important, but they are stronger when paired with data-layer signals such as anomalous reads, unusual sharing, exfiltration patterns, and permission changes outside approved windows. Feeding these signals into the SOC with pre-authorized, reversible containment can shift the measure of progress from patch velocity toward exposure reduction.

Together, these capabilities allow the foundation to do its job so that if an exposure does occur, the blast radius is as small as possible.

Let's look at an exa mple, with an AI agent operating through delegated user permissions that retrieves information from enterprise stores . If its service identity or connected tools have broader access than intended, the effecti ve boundary is shaped not only by what the user requests, but also by what the agent and its tools are permitted to retrieve and act upon. Authorization scope, duration, and auditability, therefore, belong in the same access-governance program.

A practical operating sequence includes:

Discover: Maintain a live inventory of sensitive data and exposure.
Minimize: Reduce duplicated, outdated, or no-longer-relevant data.
Govern: Remove excess access for human and non-human identities.
Detect and Contain: Monitor data-layer behavior and prepare reversible response.

Where Varonis comes in

Visibility is foundational, but the current threat environment also rewards platforms that can act on what they see. Varonis combines both the ability to find, fix, and alert on risks at the data layer quickly enough to matter.

As AI agents and copilots increasingly read, write, and act on enterprise data, the line between AI security and data security is disappearing. Varonis extends this same find-fix-alert model to AI: discovering each AI system, tying that usage back to the sensitive data, and applying runtime guardrails to help address risk before it becomes exposure.

Four contributions stand out within a layered defense program:

Continuous discovery and classification: Sensitive data across cloud, SaaS, on-premises, and AI systems, operating as a real-time inventory rather than a quarterly exercise.
Automated reduction of excess access: At a pace that complements human-led entitlement reviews, turning least privilege for humans and agents from a policy statement into a measurable, sustained state.
Data-centric threat detection: With behavioral analytics tuned to ransomware staging, insider exfiltration, account compromise, non-human identity misuse, and out-of-policy behavior, broadening the SOC’s line of sight into data-layer activity.
Managed data detection and response: For organizations seeking to operationalize data detection and response without building a continuous data-layer practice in-house.

PwC helps clients shape the operating approach, frame risk for board engagement, and bring the program to life, often in collaboration with Varonis. This combination is resonating with organizations navigating the shift.

In early phases of remediation, clients often see meaningful reductions in over-exposed data and excess access. Results vary by environment, and they are more useful when measured against a tailored baseline.

A baseline can surface overexposed sensitive data, unjustified access, broad non-human permissions, and gaps in data-layer monitoring, a defensible starting point for prioritized remediation.

At Varonis, we believe AI makes visibility and control at the data layer critical. Agents, chatbots, and models introduce new access paths that attackers can use to compromise data at machine speed. Without continuous visibility and control, sensitive data may be exposed the moment an agent or AI system touches it.

A closing note

Data security and access governance have moved from supporting disciplines to foundations of resilience.

Organizations that establish clear ownership, maintain a live view of sensitive data, enforce disciplined access, and operationalize data-centric detection can be better positioned for the next phase of attacker capability. PwC and Varonis are helping organizations put this foundation into practice.

Continue the conversation with Varonis and PwC on October 7 at 11 a.m. ET, where they will explore how organizations can identify, prioritize, integrate, and define their data security strategies moving forward. Register today to save your spot.

Varonis and Cohesity: Improving Cyber Resilience with Data Security

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

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

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

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

How Varonis and Cohesity reduce risk and strengthen resilience

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

Discover and classify sensitive data

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

Lock down access and shrink the blast radius

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

Detect and stop threats in real time

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

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

Contain ransomware and recover fast

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

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

Optimize cost

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

Complete visibility, protection, and recovery

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

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

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

AI Security Fundamentals: The Real Industry Shift Taking Place

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

Key takeaways

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

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

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

Security for AI vs. AI for security

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

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

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

Why AI exposes existing weaknesses

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

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

AI vs. AI: The new security arms race

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

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

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

Using AI to supercharge security

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

With AI, security teams can easily:

Investigate alerts

Correlate signals

Add context

Reduce false positives
Surface only meaningful threats

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

Vulnerability prioritization

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

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

Security fundamentals still win

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

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

The real AI security shift

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

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

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

Watch their full conversation:

Meet AvisLoader: A Windows Loader Built to Outlast a Takedown

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

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

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

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

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

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

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

Delivery through ClickFix and Cloudflare

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

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

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

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

Inside the loader

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

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

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

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

Escalation, persistence, and stealth

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

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

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

The AvisLoader command center

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

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

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

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

Defenses and takeaways

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

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

What we learned from AvisLoader

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

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

MITRE ATT&CK

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

Indicators of compromise

File indicators

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

Host and analysis artifacts

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

How Varonis can help

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

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

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

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

Key takeaways

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

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

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

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

What is the Varonis Triage Agent?

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

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

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

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

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

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

In production, Varonis has measured:

Up to 100% improvement in analyst efficiency.

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

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

How the Triage Agent investigates an alert

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

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

Why the Triage Agent can be trusted in production

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

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

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

What’s next for Varonis MDDR

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

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

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

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

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

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

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

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

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

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

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

The security risks show up in a few consistent ways:

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

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

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

Securing AI through data-first architecture with Varonis

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

Varonis Atlas: built to disrupt AI security

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

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

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

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

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

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

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

Teaching a Machine to Think Like an Incident Responder

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

Key takeaways

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

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

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

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

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

Why we built the Varonis Triage Agent

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

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

Varonis’ context advantage

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

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

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

How the agent investigates

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

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

Handling infinite context

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

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

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

Forging the mind of an incident responder

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

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

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

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

How we improved the agent

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

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

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

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

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

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

A real investigation, end to end

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

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

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

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

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

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

From isolated alerts to connected incidents

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

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

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

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

What it took to make the agent useful

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

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

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

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

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

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

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

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

TrustSink: How a Rogue External MFA Provider Steals Passwords

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

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

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

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

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

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

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

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

Building the rogue provider

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

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

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

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

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

1. The discovery document

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

2. The public key

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

3. The page the user sees

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

4. The capture

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

What the user sees

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

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

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

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

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

From proof of concept to repeatable trap

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

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

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

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

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

Manual setup

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

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

You can watch the manual deployment here.

Automated deployment

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

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

You can watch the automated deployment here.

How to detect and mitigate TrustSink

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

Five places are worth watching:

1. Authentication Methods Policy changes

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

2. Application registrations

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

3. Service principals

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

4. Sign-in logs

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

5. Automated tooling

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

Mitigation

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

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

The bottom line

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

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

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

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