Database PAM: Why Statement-Level Control Is Only Half the Answer
Your PAM vendor can (probably) tell you exactly who logged into your production database at 2:14 a.m. on a Tuesday, from what device, using which credential. Ask it what that person actually did once they were inside, and the confidence disappears.
That gap between controlling the door and controlling what happens behind it is the subject of a sharp piece Bytebase published recently, “What Is Database PAM (Privileged Access Management)?”
Their argument: the unit of risk in a database isn’t the connection, it’s the SQL statement.
We think that’s the right diagnosis (although we see connection as a risk as well, but we won’t discuss it in this article). We’ve spent the better part of a decade building the part of the cure they left out.
TABLE OF CONTENTS
1. What Bytebase Gets Right about the Database PAM Gap
2. Why “Statement-Level Control” Undersells the Problem
3. What Full Database PAM Actually Requires
4. Mamori Case Studies: Real Deployments, Real Results
No Cost, Big Protection.
Download Mamori Freemium and begin securing your network, users, and databases with zero-trust.
What Bytebase Gets Right About the Database PAM Gap
Traditional privileged access management was built for servers. CyberArk, BeyondTrust, Delinea, StrongDM, Teleport: different generations of the same idea. Vault the credential, rotate it, broker the session, record it. On a server, that playbook works, because the dangerous moment with SSH is the connection itself.
Point that same playbook at a database and nothing visibly breaks. The credential gets vaulted. The session gets recorded. The compliance box gets checked.
But as Bytebase puts it, the database has quietly been treated as just another server, and it isn’t one. On a server, the unit of risk is the connection. On a database, it’s the statement: a single missing WHERE clause on an otherwise fully authorized, fully recorded session can still take production down.
We agree with that framing completely within this context, and it’s the same gap we’ve been advocating since 2021 calling DBPAM: Database Privileged Access Management. Specifically, DBPAM consists of PAM controls that follow a user all the way into the database rather than stopping at the network or the server.
It also matches what the threat data has been saying for a while. CrowdStrike’s 2026 Global Threat Report found that 82% of detections logged in 2025 involved no malware at all, just valid-looking activity from valid-looking identities.
Attackers increasingly don’t break in. They log in, using a credential nobody thought to lock down, and everything after that point looks routine right up until it isn’t.
IBM’s 2025 Cost of a Data Breach Report puts the global average cost of a breach at $4.99 million. A meaningful share of that cost doesn’t come from the intrusion itself. It comes from what an attacker, or an insider with too much access, does once they already have a working, “authorized” session sitting inside your database.
Why “Statement-Level Control” Undersells the Problem
Bytebase compares database security to code review: a pull request needs approval before it's merged, so a database query should need approval before it runs. It's a smart analogy, especially for engineers.
But three things are missing from that picture.
First, most database break-ins don't start with someone typing a risky query. They start earlier: a shared login, an old account nobody deactivated, a credential that was never tied to one person. Reviewing the query after someone already has access is like checking what a burglar (or a team of burglars) did after they're already inside. It doesn't stop them from getting in. Identity has to be locked down before the query even matters.
Second, a database is more than a list of queries to approve one by one. It also involves who can see which rows and columns, service accounts, and traffic from BI tools like PowerBI or Tableau that doesn't look like a single query at all. Reviewing each query works well for planned changes, like updating a table structure. It works less well for the constant, everyday querying that DBAs and analysts do all day.
Third, a tool that only reviews queries is still a separate tool. It's another login and another system layered on top of whatever you already use for servers and networks. That's fine if you specifically want a database change-review tool. It's a problem if your goal is fewer tools, not more.
None of this means Bytebase is wrong. Query review is genuinely useful. It just isn't the full answer once you ask where these incidents actually start.
What Full Database PAM Actually Requires
This is the model we’ve built into Mamori’s DBPAM capability, and it has five parts.
Identity before anything else. Every database session is tied to an individual, verified with SSO and 2FA, not a shared or local database credential. Disable someone’s directory account and their database access will be removed as well. In most environments today, it doesn’t: local database credentials quietly outlive the directory account that was supposed to control them.
Least-privileged access to the data itself, not just the database. Role-based policies that define what a user can see and do - down to the table, column, row, and objects - not just whether they can connect.
On-demand, time-sensitive access. Users request access to a specific resource. A DBA or manager approves it. Access expires automatically. No standing privilege sitting around waiting to be misused, no “zombie” accounts left over from a project that ended a year ago. This is Zero Trust's Just-In-Time (JIT) and Just Enough Access (JEA) principles at work. Zero Trust assumes no user or system is inherently trustworthy, so access isn't granted once and left standing, it's evaluated every time. JIT means access exists only for the window it's needed. JEA means it's scoped to exactly the resource required, nothing broader.
Statement-level control and masking. A SQL Firewall that allows or blocks specific statements/command types, plus dynamic data masking that hides sensitive fields like PII from anyone without explicit, logged authority to see them. This is a feature that most directly overlaps with Bytebase’s statement-level argument, and it’s a real point of agreement in how we both think about this problem.
One audit trail, not three. Every session recorded and attributable to who, what, when, where, which device, and what was masked. Not spread across a separate DAM tool, a jump host log, and an application server log that someone has to reconcile manually during an audit.
That last point is why security teams so often end up buying a PAM tool and a DAM (Database Activity Monitoring) tool separately. PAM manages the credential. DAM watches the queries. Neither one does both, so most organizations buy both.
Or, as we put it: why do organizations with PAM also buy DAM?
Because PAM alone doesn’t give a DAM!
See how the full model comes together on our database PAM solution page or download our free white paper Why Your PAM Needs to Give a DAM*!
Mamori Case Studies: Real Deployments, Real Results
Here's what Mamori DBPAM looks like in production.
A Critical Information Infrastructure(CII) needed its SCADA systems (Wonderware, Ignition) and SQL Server databases compliant with government cybersecurity rules. We added identity-based MFA, session recording, anomaly detection, and data masking, with zero disruption. Result: full CCoP compliance, including access control it lacked before.
A financial services firm's PAM tool stopped at the server, leaving users to reach systems via shared application IDs nobody could trace. In a POC against two vendors, only Mamori met every criterion and coexisted with the existing PAM setup. Audit time dropped from days to minutes.
A major Philippine hospital network's shared database (prescriptions, lab results, patient records) had vendor access that they cannot monitor. Mamori deployment took two weeks; access is now role-based down to the technician.
See our list of case studies: mamori.io/case-studies.
Compliance as a Byproduct, Not the Goal
I’ve spent 25 years in database engineering, data migration, and security, first at Dell and Quest Software, then building and exiting my own companies, before starting Mamori in 2019. I’ve sat on the other side of a breach. I’ve also sat across the table from auditors enough times to notice the same pattern: the fastest path to certification isn’t a documentation exercise. It’s actually being secure.
When access is identity-based, least-privileged, and fully logged by default, most of what an auditor asks for is already sitting in the system. That’s how organizations we’ve worked with have gone from SOC 2 certification timelines measured in years down to as little as three months.
Singapore’s Cybersecurity Code of Practice makes this concrete: section 5.13.2 specifically requires segregating database administrator duties from server administrator duties. A PAM tool that stops at the server cannot satisfy this requirement on its own.
My view, and it shapes everything we build: compliance should be a natural result of actually being secure from cyber threats and data theft.
Closing the Gaps with Minimal Disruption
None of this requires replacing what you already have. The financial services deployment above is proof. Mamori’s DBPAM layered directly onto an existing PAM helped closed the database gap without a single required change to the existing system.
If your organization manages under $10 million in revenue or has 20 staff or fewer, you’d qualify for Mamori freemium, which gives you this DBPAM tool for free (yes, completely free). It’s part of why more than 800 organizations worldwide have downloaded it as of Q3, 2026.
For larger environments, especially ones already running a PAM tool that stops at the server, schedule a sales call with us.
Bytebase’s original piece is worth the ten minutes read. They got the diagnosis right. We just think the cure needs identity at the center of it.
What is database PAM, and how is it different from regular PAM?
Regular privileged access management (PAM) was built for servers: vault the credential, rotate it, record the session, since the dangerous moment is the connection itself. Database PAM (DBPAM) follows the user past that point, into the database, because on a database the real risk is the individual SQL statement, not just who logged in. A single missing WHERE clause on a fully authorized, fully recorded session can still take production down, which is why databases need their own layer of control beyond server-level PAM.
What does statement-level SQL review miss in database security?
Reviewing and approving each query like a pull request catches risky changes before they run, but most database break-ins don't start with a risky query. They start earlier: a shared login, an old account nobody deactivated, or a credential never tied to one person. Reviewing a query after someone already has access is like checking what a burglar did after they're already inside; it doesn't stop them from getting in. Full database security has to lock down identity before the query is even a question.
What are "zombie accounts" and why are they a security risk?
Zombie accounts are old database credentials or access grants left over from a project or employee that ended, still sitting active and waiting to be misused. They're a common entry point for attackers because nobody is watching them, and often no one remembers they exist. On-demand, time-sensitive access closes this gap: access is requested for a specific resource, approved, and expires automatically, so nothing is left standing around.
What are Just-In-Time (JIT) and Just Enough Access (JEA) in Zero Trust?
JIT and JEA are core Zero Trust access principles. Zero Trust assumes no user or system is inherently trustworthy, so access isn't granted once and left standing, it's evaluated every time. JIT means access exists only for the window it's actually needed; JEA means it's scoped to exactly the resource required, nothing broader. Together they replace standing privilege with access that's requested, approved, and expired automatically.
How does Mamori's DBPAM close the gap that statement-level tools like Bytebase leave open?
Mamori's DBPAM ties identity to every database session with SSO and 2FA, applies least-privileged access down to the table, column, and row, and layers in on-demand JIT/JEA access, statement-level SQL filtering and masking, and one unified audit trail. It agrees with Bytebase that the SQL statement is a real unit of risk, but treats it as one layer of five rather than the whole answer. In one financial services deployment, Mamori's DBPAM layered directly onto an existing PAM tool without requiring any changes to it.
About Mamori.io
Mamori.io is an all-in-one solution that prevent ransomware by offering multiple layers of security – from the network, servers, all the way down to the database. The same system can also help organizations comply with privacy regulations, reduce cyber insurance premiums, and automate ISO 27001.
For small businesses, Mamori.io has all the features to completely secure their data. For large businesses, Mamori.io covers security gaps, secures external vendor access, and provides access controls to the database.
Schedule a demo with Mamori.io or request your free trial. If you’re a small business with $10 million USD in gross revenue or less, you can use 20 free Mamori.io licenses.
