Summary: Most data breaches begin with seemingly routine activity. Learn the four scenarios every CISO should monitor and why precise, real-time alerting is essential for detecting sensitive data misuse before it becomes a breach.
Ask yourself a simple question. Right now, at this exact moment, is anyone accessing sensitive data they shouldn’t be? You probably don’t know. Most CISOs don’t. And that gap between what’s happening in your databases and what you actually know about it is where breaches live.
This isn’t a hypothetical exercise. It’s the question every security leader should be asking on a loop, because the answer changes the moment new users, new tools, and new automation get added to the environment. Let’s walk through a few scenarios that play out in real organizations every day, and think honestly about how long it would take you to notice.
A developer queries payroll
Developers touch a lot of systems. Most of the time it’s harmless: staging environments, test data, debugging a broken integration. But every so often, a developer runs a query against production payroll data because it was faster than asking for a sanitized copy, or because access controls were left too permissive after a project wrapped up.
Is that malicious? Usually not. Is it a problem? Absolutely. Payroll data is some of the most sensitive information a company holds. Salaries, bank details, social security numbers. If a developer can pull that data without anyone noticing, so can someone with worse intentions using that developer’s credentials.
The real question isn’t whether this happens. It does, more often than most security teams realize. The question is whether you’d know it happened five minutes later, five days later, or only when it shows up in an audit six months down the line. A rule that flags any non-HR user touching a payroll table, regardless of how the query was written or which tool it came through, closes that gap instantly. That’s a narrow, specific condition, not a broad net that buries the real alert under a hundred false ones.
A contractor exports customer data
Contractors are a fact of business life. They come in for a project, get access to what they need, and move on. The problem is that “what they need” tends to expand over time, and offboarding is rarely as clean as onboarding.
Picture a contractor wrapping up an analytics project. They export a dataset for one final report. Nothing unusual on the surface. But what’s actually in that export? How many records? Does it include fields that were never part of the original scope, like full customer names and payment details instead of aggregated totals?
Without visibility into what’s being accessed and how much data is moving, that export looks identical whether it’s completely appropriate or a serious data leak. Volume matters. Context matters. And most legacy monitoring tools were never built to catch either one in real time. This is where threshold logic earns its keep. A query that pulls a few hundred records looks nothing like one that pulls a hundred thousand, and a rule built around volume, not just identity, catches the second one even when the contractor’s access is technically valid.
An AI agent suddenly touches PHI
This is the scenario keeping a growing number of CISOs up at night, and for good reason. AI agents are being deployed across customer service, operations, and internal tooling at a pace that outstrips most organizations’ ability to govern them. These agents make decisions about what data to pull based on prompts, context, and sometimes their own reasoning about what’s relevant to the task.
That’s the problem. An agent built to answer billing questions might reasonably decide that pulling a patient’s health record helps it answer a related question more completely. It wasn’t explicitly told to access PHI. It just got there on its own, following a logical thread that a human reviewer never anticipated.
Traditional access controls assume a human is making the decision to query data, and that the human’s role determines what they should see. AI agents break that assumption. They act on behalf of a service account, often with broad permissions, and they move fast. If your monitoring is built around static role-based rules rather than actual behavior, an agent can quietly expand its own reach into sensitive data long before anyone reviews what it’s doing.
This is a case where a single high-risk action deserves its own alert, separate from everything else running through the pipeline. An agent identity querying a column tagged as PHI for the first time is worth flagging immediately and at high severity, not lumped in with routine batch traffic where it will get lost.
A service account behaves differently
Service accounts are supposed to be boring. They run the same jobs, at the same times, against the same tables, day after day. That predictability is exactly what makes deviations so telling, and exactly why so few organizations pay attention to them.
A service account that suddenly starts querying a table it’s never touched before, or pulling ten times its normal volume of records, or running queries at 3 a.m. instead of its usual 9 a.m. batch job, is telling you something. Maybe it’s a legitimate change tied to a new feature. Maybe the credentials were compromised. Either way, that shift in behavior is a signal, and signals only matter if someone is watching for them.
This is where pattern-based detection matters more than single-event rules. No individual query in that sequence looks alarming on its own. It’s the deviation from baseline, a new table, a volume spike, an odd hour, that makes it worth a second look, and that only works if the threshold is built around what’s normal for that specific account rather than a generic rule applied across every service account in the environment.
The question that actually matters
Every one of these scenarios has something in common: none of them require a sophisticated attacker or a dramatic breach story. They’re quiet. They’re the kind of activity that looks routine until you dig into the details, and most organizations never dig, because they don’t have the visibility to know where to look.
So here’s the question that matters more than any of the individual scenarios above. How long would it take your team to know?
Not eventually. Not “we’d find it in a quarterly access review.” Right now, in near real time, if someone with more access than they should have started reading sensitive data, would anyone notice before the damage was done?
For most organizations, the honest answer is uncomfortable. Logs exist, but they’re scattered across systems and rarely reviewed until something already went wrong. Alerts exist, but they’re tuned so broadly that real signals get buried in noise, or tuned so narrowly that new patterns of misuse slip through untouched. And the people best positioned to notice unusual activity, security teams, are usually looking at everything except the data layer, because that’s historically been the hardest place to get visibility.
That’s the gap. Access controls tell you who is allowed to see what. They don’t tell you who actually looked, how much they took, or whether that activity fits a normal pattern. Closing that gap requires monitoring that operates where the data actually lives, and alerting that’s precise enough to trust.
Precision is really the whole game here. Broad alerting rules generate so much noise that teams start ignoring them, which defeats the purpose entirely. Alert fatigue is a real phenomenon, and it’s the reason so many breaches show up in hindsight as “we did get an alert for that, it just didn’t get looked at in time.” The fix isn’t fewer alerts for the sake of fewer alerts. It’s rules specific enough to matter: a particular user against a particular table, a query volume that crosses a defined threshold, an access pattern that breaks from an account’s own baseline. Every one of the scenarios above needs a different kind of rule, and that only works if the underlying system lets you build conditions around users, query types, tables, columns, and volume, combined however the situation actually calls for.
Severity matters too. Not every flagged event deserves a 2 a.m. page. A contractor’s export that’s slightly larger than usual is worth logging and reviewing. An AI agent touching PHI for the first time is worth waking someone up for. Alerting that can distinguish between those two, and route each one to the right place, whether that’s a ticket in the queue or a message straight into the SOC’s Slack channel, is what turns visibility into actual response time. And because most security teams already live inside SIEM, ITSM, or collaboration tools, the alerts need to land there directly. Asking teams to babysit a separate dashboard on top of everything else they’re already watching is how good signals get missed.
None of this requires slowing teams down or rearchitecting the data environment. It requires monitoring built to classify sensitive data, watch consumption patterns in near real time, and route the right alert to the right person the moment something looks off, whether that’s a developer in payroll, a contractor’s export, an AI agent reaching for PHI, or a service account acting out of character. The goal isn’t friction. It’s making sure that when something unusual happens, you know about it in minutes, not months.
So ask yourself again. How long would it take you to know? If you don’t have a confident answer, that’s worth fixing before you need one.
