Harsh Singhal leads AI and Data Security at Glean, applying machine learning and agentic systems to endpoint defense and data governance.gettyFor decades, data loss prevention (DLP) has been sold as a detection problem. By writing enough regex and licensing enough built-in detectors, you'll catch the Social Security numbers, API keys and card patterns moving through your enterprise. Today, the pitch remains the same, but the core problem still hasn't been solved. With or without a DLP tool, human judgment is still required on both ends of the process. Throughout my career, including my current work developing agentic AI security systems, I’ve built platforms to reduce data risk at scale. Over all those years, a detector has never handed a security team a decision. What it hands them is a queue, and queues are where good security programs go to die. This isn't because analysts are lazy, but the work they do doesn't match what the tool promised.The tool promises to "find sensitive data." The analyst still decides, alert by alert, whether this string, in this document, owned by this person, shared with this audience, is an incident, a non-event, a broken detector or a systemic issue the business needs to fix.Better pattern-matching won't close the gap between what DLP detects and what a human must still judge, but an architecture that treats context as the foundation can. Why Pattern Matching Hit Its CeilingIn Feburary, I conducted a study by pulling roughly 27,000 public, enterprise-like documents including mailing lists, issue trackers, public code, chat logs and technical docs from open-source projects and public datasets. I wanted to know if an LLM is the most effective evaluator of an enterprise's safety posture that can be encoded in the form of rules and guidelines from the security/CISO team. To understand this, I ran three families of detectors over the data: regex, a PII-focused named-entity model and an open-source privacy filter from a frontier lab. The detectors generated over 120,000 candidate findings.Then I put those findings in front of a rubric-governed frontier language model and asked it to adjudicate. About four out of five were false positives. I don't mean close calls, but noise like a Git commit hash flagged as a high-entropy secret, a version number read as an IP address and a field named SECRET_KEY mistaken for the secret itself. The detectors found strings that look sensitive, but they couldn't know that a committer's email on a public list isn't a customer record or that a staging password in a QA ticket isn't a production breach. These are reading-comprehension questions about your organization, which DLP tools were traditionally not built to answer.The Floor And The BandThe reason is that "sensitive" is part fact and part judgment your organization has made about itself. The line between them is the most useful thing a security leader can draw.Start with the fact. There's a floor, set by regulation and physics. A live production credential is high-severity at every company on earth. A real payment-card number is high everywhere, because PCI DSS says so. A government identifier, a HIPAA-covered record, a GDPR Article 9 field—these are top of the scale, full stop. When I built my severity rubric, I literally couldn't synthesize a "medium-severity real SSN." The rubric kept routing it to high. Operational regulated data is high, or it's nothing. You have to encode that floor as close to hardcoded as you can.Above the floor sits the band—where two competent CISOs look at the identical string in the identical document and reach opposite conclusions because they run different organizations with different blast radii and different things to lose. Most real DLP volume lives here, and it's exactly what legacy detection can't touch.Consider how three different companies evaluate the exact same finding. A test credential in a Jira ticket is fine at an early-stage startup. However, it's a policy violation at a regulated fintech, where tolerating the fake case erodes the habit that protects the real one. Employee phone numbers in a directory are mundane at a SaaS company but an exposure risk at a hospital, where the threat model includes impersonating an on-call clinician. A credential in a marketing drive versus an SRE runbook is the same secret, but only one team is supposed to touch it.What drives the variance is not the string, but risk appetite, blast radius, role expectation, sharing scope and regulatory exposure. These five dimensions are the CISO's mores, and they've historically lived in one place: the leader's head, applied inconsistently, one ticket at a time, by tired analysts.This is the case for AI-first design, and why a faster detector doesn't help. You can't regex "this owner's team is expected to handle this data," but you can write that judgment into a rubric in plain language, allowing a model to apply it to a hundred thousand findings with the same standard. From A Queue Of Alerts To A Map Of RoutesOnce findings carry context, DLP stops being an alert firehose and becomes an organizational sensor. It can finally see the category legacy DLP couldn't: the aggregate signal. If a hundred tickets contain test credentials, no single one warrants paging anyone, but the pattern does tell you your QA workflow depends on pasting passwords into tickets. Detection only surfaces incidents, not a missing secrets broker. Only adjudication rooted in context can surface that. Why AI-First Is More GovernableThe objection I hear: putting a model in the loop means losing control. Built right, the opposite is true. Every adjudication records the detector event, the rubric version, the model identity, the structured output and the explanation—a decision record you can audit, replay and challenge. High-impact and low-confidence findings should still route to humans. If analysts keep overriding the model on a class of findings, the problem is an underspecified rubric, not the model. You'll have to fix the policy rather than the label.DLP's next decade depends less on detecting more strings and more on building the layer that evaluates a finding in context and knows who owns it, where it lives, who can see it and what your organization considers a true risk. Traditionally, detection has told a team, "This looks like a credential." Judgment asks, "Is this your credential, in the wrong place, under your rules?" Only the latter gives security teams actionable control over their data exposure.Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
Why Data Loss Prevention Needs Judgment, Not Just Detection
Only judgment can give security teams actionable control over their data exposure.








