This is what DBSheriff actually does, described the way you'd explain it to your own team — not a feature checklist full of jargon. What counts as risky, what happens the moment it's seen, and what your auditors get to see afterward.
Grouped the way they actually work together: see everything, know what matters, catch the behavior that's dangerous, stop it, prove it happened, and keep the underlying settings honest.
👁 VisibilityThis isn't a generic "SQL injection scanner." These are the specific behaviors — insider misuse, a compromised credential, a runaway script, a slow and deliberate extraction — that a database security review is actually worried about, described in plain terms.
| Category | What it looks like |
|---|---|
| Bulk or unusual sensitive-data reads | A query touching a classified table — PII, financial records, credentials — at a volume or shape that doesn't match how that account normally uses the database, including a full scan of a table that's normally accessed narrowly. |
| Disguised repeats of a known-risky query | The same underlying read, wrapped in a comment, a sub-query, or rewritten just enough to dodge a naive text match — still recognized as the same behavior. |
| Data leaving through an export path | Bulk export functions, file writes, cross-account data sharing, or any mechanism the database itself provides for moving data out — not just a plain SELECT. |
| Operating-system or file access from inside SQL | Database functions or procedures that reach outside the database itself — reading server files, executing OS commands, or loading untrusted code. |
| Privilege escalation & impersonation | Granting elevated rights, switching to another account's identity mid-session, or otherwise expanding what an account can do beyond its normal footprint. |
| Tampering with the monitoring itself | Turning off audit logging, resetting statistics, or disabling the very controls that would otherwise catch what happens next — treated as one of the most serious signals there is. |
| Disabling data-protection controls | Switching off row-level security, dropping a masking policy, or otherwise removing a protection that was put in place on purpose. |
| Credential-stuffing & brute-force patterns | A burst of failed logins, especially one immediately followed by a successful one — read together as a single story, not two unrelated log lines. |
| Sleep-based denial-of-service | A query designed to do nothing but hold a connection open — a classic way to exhaust a connection pool and take an application down without ever touching real data. |
| Burst / rate-based evasion | Many small, individually-unremarkable queries fired quickly enough that no single one looks dangerous — caught in aggregate, not just one at a time. |
| Behavioral anomalies | Off-hours access, a brand-new source location, a dormant account suddenly active, or a never-before-seen client tool touching sensitive data. |
| Canary (honeytoken) table access | Any touch of a designated tripwire table — an absolute signal, with no exceptions for otherwise-trusted accounts. |
| Administrative privilege used for data work | An account meant for administration — not day-to-day data access — used to read or export ordinary business data. |
| Result sets far outside a user's normal pattern | Ten, a hundred, a thousand times more data returned than that identity's own history would predict. |
| Cost-abuse on cloud-billed warehouses | On Snowflake, BigQuery, and Databricks, a query burning far more compute or dollar cost than is normal — its own category of "risky," independent of what data it touches. |
Not every unusual-looking query deserves to be killed. DBSheriff scores every statement through three layers, in order, so a false alarm never becomes a false termination.
Your DBAs, monitoring accounts, and known service accounts are designated trusted and bypass ordinary scoring — so your legitimate high-volume work never trips a false kill. This trust is never absolute: touching a honeytoken table overrides it, with no exceptions, for any account.
Sensitive-table breaches, export patterns, privilege escalation, and monitoring-tamper attempts are caught by rules, not a probability score — so there's no waiting for a model to "decide" something that's already obviously wrong.
What the rules don't already catch is scored by a model trained on your actual historical traffic — what's normal for your people and your workloads, not a generic industry signature.
The right response to a first-time false-positive-shaped query is different from the right response to a confirmed, repeated attack. DBSheriff's response climbs a ladder instead of jumping straight to the most severe action every time.
Every action — terminate, revoke, lock — is a switch your team turns on per server. New installations run in detect-only mode: you see exactly what DBSheriff would have stopped before you ever let it act. Nothing changes your data, roles, or settings on its own, and every action taken is reversible and written to an audit trail you can read.
A DBA running a legitimate bulk migration shouldn't trigger the same response as an attacker running the identical-looking query. DBSheriff's policy engine recognizes the difference — without ever creating an account that's simply invisible to the system.
| Account type | How it's treated |
|---|---|
| Trusted / known-safe accounts | Ordinary risk is scored but suppressed — the query runs, the event is still recorded. A honeytoken touch overrides this without exception. An explicit setting can require even trusted accounts to be stopped on a genuine large-scale data-exfiltration pattern. |
| Privileged / administrative accounts | Judged more strictly, not less — administrative work is expected to look like administrative work, and is held to a higher bar, not exempted from one. |
| Narrow-access service accounts | Given kill-suppression only for the exact, specific access they were registered for — any query outside that narrow scope is judged like any ordinary account. |
| Everyone else | Scored on their own merits, with no assumptions either way. |
A honeytoken (canary table) touch is an absolute signal, for every account type, with no configuration that turns it off. It exists specifically to catch the scenario every other rule might miss.
How credentials are handled, what leaves your network (nothing), and how the detection engine itself is built to be trustworthy.
Read the security & architecture guide → Request a Demo