The most consequential commands in any enterprise are typed at a SQL prompt. A production database holds the customer records, the balances, the transactions - the substance of the business and the substance of every breach notification. Yet database administration has historically been the least governed privileged access of all: direct client connections, shared superuser accounts, and no record of the queries beyond whatever the database's own logging happened to capture. One mistyped DROP, one unauthorised bulk SELECT, and the difference between a routine Tuesday and a reportable incident is a single statement.
The enterprise challenge: SQL is both the work and the risk
Database sessions resist the usual controls precisely because SQL is the legitimate work. A DBA's job is to run powerful statements; the harmful ones are syntactically indistinguishable from the necessary ones without context. DROP TABLE is catastrophe on production and housekeeping on staging. A full-table SELECT against the customer table is a data theft in one context and a sanctioned migration step in another. Network controls cannot see into the session; database-native auditing records after the fact, in formats built for DBAs rather than investigators; and neither can stop anything.
Why generic PAM often stops at the database door
Many privileged access deployments govern the SSH session to the database host but go blind the moment a database client connects - the SQL stream is just traffic. Tanflow's own market comparison reflects this: database session control at the SQL level is a capability it identifies as unavailable in open-source stacks and limited in legacy suites. The result in most enterprises is a governance perimeter that ends exactly where the crown jewels begin.
The Tanflow approach: the gateway speaks SQL
Tanflow PAM carries database sessions natively through its zero-agent gateway - MySQL, PostgreSQL, MS-SQL and MongoDB sessions among a coverage of fifteen-plus database CLI and GUI clients - which means every control in the chain applies inside the SQL session, not just around it. The DBA authenticates to the portal with MFA, is authorised for the specific database target, receives a browser-based session with credentials injected from the vault, and works under real-time command inspection with the session recorded end to end.
Command Control's four verdicts map onto database risk with unusual precision:
- BLOCK + TERMINATE for the irreversible: DROP DATABASE and destructive statements on production targets stop the command, kill the session instantly and alert the SOC.
- BLOCK + NOTIFY for the recoverable-but-wrong: risky operations outside change windows are stopped while the session survives and administrators are informed.
- JUSTIFY for the sensitive read: exporting customer tables or accessing payment logs proceeds only after the user enters a business justification, which is logged with the event - accountability at exactly the moment data leaves.
- ALLOW + WARN for the discouraged: legacy patterns still permitted run with a caution to the user and a highlight in the audit trail.
Because policy distinguishes targets, production and staging databases operate under different regimes - strict where the data is real, permissive where it is not - which is what makes the control operable rather than exceptioned into irrelevance.
An enterprise scenario
Consider a banking organisation's month-end maintenance on a production database. The DBA's access exists as a Saturday-night Just-in-Time window - Tanflow's own change-window pattern. Inside the recorded session, routine statements flow untouched; a schema change outside the approved script draws a block-and-notify; the export of an account table for the reconciliation team requires a typed justification that lands in the log beside the recording. On Monday, the change file already contains the complete evidence: window, approvals, replayable session, command log, justifications. Nothing was assembled; it was generated.
Security and audit implications
SQL-level control produces the evidence class that data-protection reviews increasingly demand: not just who connected to the database, but what they asked it for, and what the control did about it. For frameworks Tanflow maps against - PCI DSS, the RBI Cyber Security Framework, ISO 27001 among them - the combination of individual attribution, command-level enforcement and tamper-evident recording addresses the privileged-database-access expectations that shared DBA accounts have failed for decades. And the deterrent effect is real: a bulk read that requires a written justification is a bulk read someone thought twice about.
Conclusion
Databases are where access risk and business value coincide completely, and they deserve better than governance that stops at the host login. Tanflow PAM extends the full privileged access chain - vaulting, recording, and graduated real-time command control - into the SQL session itself, so the most consequential prompt in the enterprise finally operates under policy, in daylight, on the record.