Vendor Viability Assessment for DLP and Insider Risk Platforms

In May 2025, Coinbase was breached not by a technical exploit but by bribed support agents who used access they were already authorized to have. In both cases, the organizations almost certainly ran a vendor evaluation at some point, checked the compliance boxes, and scored the demos. None of that process was built to ask the one question that would have mattered: does this platform understand a trusted insider abusing legitimate access, or an exfiltration method that changes faster than any rule can be written for it?

Standard RFPs evaluate stated capabilities rather than operational ones.

A platform selected this way does not simply end up with a weaker security posture. It produces a security posture that looks complete on paper while the exfiltration that matters most passes through undetected, logged, and unflagged, because nothing in the evaluation ever tested for it.

How the threat landscape broke the assumptions behind legacy DLP and rule-based detection

Legacy DLP and rule-based detection were built for conditions that have since disappeared, and the failure is architectural rather than a matter of insufficient tuning or incomplete coverage. Three assumptions underpinned that generation of tooling, and each one has given out.

The first assumption was that data takes stable, predictable shapes. Static rules and regex patterns depend on anticipating the form sensitive information will take before writing a policy to catch it. But cloud-native environments spread that same data across endpoints, SaaS applications, and AI tools, so there is no single chokepoint left to monitor. The third assumption was that a human could keep the rules current. Rule-based systems require someone to anticipate a threat and write a policy for it ahead of time, and the threat surface now shifts faster than any team can keep pace with manually.

Safetica's H1 2026 data captures how quickly that environment moves: Tawk.to, an embedded third-party chat widget, went from a negligible share of instant messaging blocks to the majority of them within a single quarter. One widget rewrote the entire top of a blocked-category list in a matter of weeks, and a static rule list has no mechanism for catching a shift that fast.

The gap between how quickly organizations adopt AI and how quickly they govern it compounds the problem. Enterprise AI adoption has reached a large majority of organizations, but real-time security governance over that adoption is only beginning to take shape. Exfiltration happens inside that gap. At Charter Communications, the Spectrum breach on April 1, 2026, began when the threat group ShinyHunters voice-phished an employee into handing over credentials for a Microsoft Entra account, then pivoted through that access into Salesforce to exfiltrate customer data. Both the social engineering vector and the cross-system pivot depended on legitimate credentials moving through legitimate systems in a sequence no one had written a policy for, so no static DLP rule could catch either one.

What behavioral, context-aware detection does differently and what it still cannot do alone

Behavioral, context-aware detection replaces the question "did this action match a rule?" with a different one: is this action normal for this specific person, in this specific context, right now? That shift addresses the core failure modes described above, because you no longer have to anticipate the exact shape a threat will take before it happens.

Mechanically, these systems baseline normal behavior for each individual user and then score deviations from that baseline dynamically. These systems combine unsupervised anomaly detection with sequential behavioral modeling, so they catch static deviations and deviations that only appear across time, and they fold both into one probabilistic risk score instead of a binary alert that fires or doesn't. Explainable AI techniques, including SHAP, provide feature-level risk attribution so an analyst can see exactly which signals drove a given score, a capability that matters both for day-to-day trust in the system and for legal defensibility if the case ends up in front of HR, legal counsel, or a regulator.

This is the mechanism that catches cases like the silent cloud sync: a senior engineer who synced source code and design documents to a personal cloud account through a background process running quietly for weeks, with no suspicious command-line activity to trigger a conventional alert. It flags the pattern of access and movement across that timeline instead of waiting for a single exfiltration event to match a known signature.

That capability has real limits. If an insider operates entirely within their authorized access patterns and at ordinary volume, that risk is statistically normal, so it will never generate a behavioral anomaly, because it was present from day one without ever deviating from the baseline. AI agents operating with employee credentials present the hardest case, because there is no established human baseline for their behavior to deviate from. Candor builds behavioral patterns out of the full timeline a user generates across systems instead of scoring isolated actions, so it reads a single anomalous event inside the pattern it belongs to, not as a standalone signal. That architecture takes on the collapse of static rule-based detection head on, because reading context across a timeline is a structurally different exercise than waiting for an action to match a pre-written policy.

AI Agents and Copilots as a New Insider Risk Category

AI agents and copilots now constitute a distinct insider risk category, and most DLP and insider risk management platforms were architecturally designed before that category existed. If a vendor cannot govern non-human identities, it carries a structural liability no matter how well it performs against human users, because those agents hold access that is functionally identical to what a trusted employee holds.

AI agents differ from human users in ways that matter specifically to detection architecture. They operate with employee credentials and act on behalf of the people who deployed them. From the vantage point of an access log, they look exactly like a trusted insider. They have no behavioral baseline a UEBA model can establish, because their actions vary according to the task at hand and the prompts they receive rather than settling into a stable personal pattern the way a human user's behavior does over time. And a single well-crafted prompt injection can co-opt an organization's most powerful and most trusted AI tool, handing an adversary what amounts to an autonomous insider capable of silently executing transactions, deleting backups, or pivoting toward the customer database, all without ever touching a human credential.

The highest-risk AI agents share three capabilities at once: access to sensitive data, the ability to communicate externally, and exposure to untrusted content. Insider risk programs need to start treating AI agents as operational identities with defined access controls of their own, separate from the human user who happens to have deployed them. If a vendor's policy engine was built exclusively for human user accounts, it has no mechanism to enforce that kind of governance, no matter how sophisticated its human-focused detection has become.

The only framework durable enough to keep up reasons about behavior and intent instead of enumerating thousands of allowed actions in advance. AI agents and the permissions they need change faster than any static rule list can track, and that is the same failure mode that already took down legacy DLP's handling of evolving human behavior, now playing out a second time with non-human identities. Any RFP that does not ask explicitly whether a platform can define and enforce access controls for AI agents, rather than simply monitor the human employees who happen to use them, has left out one of the two insider populations it is supposed to govern.

Alert Fatigue and Slow Investigation Cycles

Detection accuracy alone does not make a platform viable. A system that surfaces the right threats into an investigation queue analysts cannot clear has not protected the organization; it has simply moved the point of failure from detection to triage.

The investigation gap is the decisive failure mode in most insider risk programs today. Security teams have acknowledged ignoring alerts that later turned out to be genuine threats because investigative throughput could not keep pace with the volume arriving, even when the detection logic was correct.

Reducing alert volume does not solve this on its own. Fewer alerts do not translate into faster investigations if each one still requires an analyst to manually assemble context from scratch. The bottleneck sits in investigative throughput, in how long it takes an analyst to resolve an alert rather than in how many alerts a system generates.

This is why mean time to investigation (MTTI) belongs in a vendor evaluation alongside detection accuracy, not behind it. M-Trends 2026 found that the median time from initial access to attacker hand-off collapsed to 22 seconds in 2025, down from more than eight hours in 2022. The attacker's breakout window is now measured in seconds and minutes rather than hours. CrowdStrike's 2026 Global Threat Report puts average eCrime breakout time well under an hour, and an investigation concluded inside that window is still contained to a single host; miss it, and the blast radius expands well beyond what a single-system remediation can address. Case-based investigation tools built with an AI copilot at the center have become close to table stakes for any platform serious about operationalizing insider risk at this scale, because the alternative is asking analysts to win a race against a 22-second window using manual methods built for an era when that window was measured in hours.

The assessment dimensions most evaluations ignore: understanding both the data and the person behind it

A viable vendor assessment has to test whether a platform understands both the data and the person behind it at the same time, because protection that treats content, destination, identity, role, and behavioral context as separate problems will fail precisely where those dimensions meet.

On the data side, a company's most valuable intellectual property typically carries no label. It becomes sensitive because of what it means to the business, not because it matches a classification tag or a known regex pattern, and a platform that can only act on labeled data leaves the crown-jewel material exposed by design. A buyer should ask whether the platform can reason about unstructured content: AI prompts, paraphrased material, screenshots, and anything else that carries proprietary meaning without carrying a recognizable signature. For shadow AI specifically, controls should depend on the data involved, its destination, who owns the account sending it, and the surrounding context. Visibility into shadow AI usage is not governance on its own, and neither is a blanket ban that simply pushes the activity further out of sight.

On the human side, a single event is almost never the risk in isolation. The risk lives in the pattern across an entire user timeline, so the relevant question is whether a platform evaluates sequences of behavior over time or only scores individual actions one at a time. Behavioral baselines, as established earlier, are not sufficient by themselves: risk can exist from the first day of employment, stay statistically normal indefinitely, or occur entirely through access a person was authorized to have all along. A platform that depends solely on deviation from baseline will miss every one of those categories. IP theft is heavily concentrated in the period surrounding a resignation, with one widely cited pattern putting the figure at 70 percent of cases clustering around that window. If a platform does not adjust its risk posture based on departure context, it treats the single highest-risk period in an employee's tenure as business as usual.

On non-human identities, the question is direct: can the platform define and enforce access controls for AI agents, not merely observe the human employees who happen to use AI tools in the course of their work? A platform that monitors human AI usage but has no mechanism for governing the agents themselves has only solved half the problem described earlier in this assessment.

A black-box score carries no weight in an HR investigation, a legal review, or a regulatory inquiry, where the question asked is never just "what did the system conclude" but "what evidence supports that conclusion."

A rigorous RFP should demand to see how a platform operationalizes this intersection of data and person directly, as a demonstrated capability rather than one described in a sales deck. Platforms including Candor pair AI-powered insider threat detection with behavioral profiling drawn from multiple enterprise systems at once, so you can see that intersection made concrete and testable. An RFP should force this question into the open: was a vendor's underlying model built to reduce mean-time-to-investigation, or just to generate a longer list of alerts for someone else to sort through later?

Program structure and cross-functional ownership as viability criteria, not just operational preferences

A platform's technical architecture sets the limits of what it can detect, while program structure decides whether anyone acts on what it finds. Insider threat programs anchored inside a single department, usually security, routinely miss indicators that originate outside the systems that department monitors. A program that waits for the technical signal to appear has already ceded the early-warning period during which intervention is cheapest and least disruptive.

Cross-functional ownership, spanning security, HR, legal, and relevant business unit leadership, is what allows a platform's output to connect to the organizational context that actually explains it: a resignation, a performance review, a role change, a legal dispute. An RFP that evaluates only the technology, while leaving unanswered who owns the resulting cases and how findings move between departments, has assessed half a system and mistaken it for the whole one.