# KeeperDB
## KeeperDB KeeperDB is a secure, multi-protocol database management tool built on the Keeper zero-knowledge platform. It ships in two forms — an **embedded session** launched automatically from KeeperPAM records, and a **standalone desktop application** for macOS, Windows, and Linux.
Privileged database access has historically been the weakest link in an enterprise security posture. Database credentials sprawl across laptops on plaintext files, keychains, sticky notes, and shared password vaults that nobody rotates. Connections go over unmonitored TCP. Actions inside the session are invisible to the security team. KeeperDB closes every one of those gaps while still feeling like the database client a DBA wants to use. {% hint style="success" %} **At a glance** * **Supported protocols** — PostgreSQL, MySQL / MariaDB, SQL Server, Oracle, Amazon Redshift, SQLite * **Zero credentials on the client** — passwords delivered encrypted from the Keeper Vault through the Gateway; never typed, never stored locally * **Embedded KeeperAI** — conversational DBA co-pilot that runs read-only queries autonomously, writes DML/DDL only with explicit consent, and is scope-guarded against off-topic code generation * **Built-in real-time monitor** — process list, blocking chains, lock analysis, and one-click session termination across all supported engines * **Runs anywhere** — native desktop application and fully embedded inside KeeperPAM-launched RBI sessions {% endhint %} ### What Is KeeperDB? KeeperDB is a full-featured database client and operational monitoring tool built into the Keeper platform. **Zero-knowledge integration with the Keeper Vault**
Sessions can be launched directly from the Keeper Vault for passwordless access. Credentials for a database record are decrypted inside the customer's Gateway and delivered to KeeperDB over an encrypted channel. Connections can be configured for session recording and KeeperAI session analysis. When a user launches a PAM Database connection, the Keeper Gateway spawns KeeperDB as a sidecar process, streams it into the user's browser through Keeper's Remote Browser Isolation (RBI) layer, and records the entire session alongside every other privileged action.
**Multi-protocol from a single UI** The same query editor, data grid, ER diagram, scratchpad notebook, and performance monitor work across PostgreSQL, MySQL, SQL Server, Oracle, Redshift, and SQLite — so a DBA managing a heterogeneous fleet doesn't have to context-switch between different applications. **KeeperAI as a built-in DBA co-pilot** An embedded assistant with full schema context answers natural-language questions, writes and runs queries on the user's behalf, generates charts from result sets, and is constrained by server-side guardrails that forbid off-topic code generation and destructive actions without explicit approval.
### Two Deployment Modes, One Experience KeeperDB is delivered two ways: Embedded in the Keeper Vault and Standalone Desktop App. Both forms share an identical interface, feature set, and security model. Visual themes provide a custom experience based on user preference.
#### Embedded in KeeperPAM (Privileged Sessions) This is the deployment method for regulated, zero-trust environments. A user browses the Keeper Vault, finds a record (e.g. *"Production Postgres"*), and clicks **Launch KeeperDB**. {% hint style="info" %} **The user never handles the credential.** Not on the wire, not in memory, not in a config file. The credential's lifetime is: Vault (encrypted) → Gateway (decrypted briefly in-memory) → KeeperDB (in-memory, zeroized on disconnect) → never written to disk on the client, ever. {% endhint %} #### Standalone Desktop App (Mac / Windows / Linux) The standalone app is a cross-platform native desktop application. This application targets the following use cases: * **Keeper customers who don't yet have KeeperPAM** but want a modern, secure database client that integrates with the Vault for credential retrieval. * **DBAs, data engineers, and developers** who need a day-to-day client that isn't "janky shareware that stores my password in plaintext." * **Consultants and contractors** who connect to many customer databases and want per-customer credential isolation without cross-contamination.
{% hint style="info" %} The KeeperDB desktop app installers are coming soon {% endhint %} | Platform | Install Link | | --------------------- | ------------ | | macOS (Apple Silicon) | Coming Soon | | Windows (x64) | Coming Soon | | Linux | Coming Soon | The desktop app can connect to a database three ways: 1. **Direct connection** with credentials the user enters once and stores in an OS-native secure store — the simplest workflow, familiar to anyone who has used DBeaver, but with secure storage of credentials. 2. **Keeper Vault integration** — the app authenticates with a user's Keeper account, enumerates their PAM database records, and launches a session using ephemeral or static credentials fetched at click-time (never cached). 3. **KeeperDB Proxy on a PAM record** — described in its own section below. ### Use Case: KeeperDB Tunnels For customers who already use **Keeper Tunnels** to expose internal databases through the Gateway, KeeperDB is the natural front end. A tunneled database looks local to the user's machine — it's reachable at `127.0.0.1:` — but every byte flows through Keeper's zero-trust and zero-knowledge encryption, with no inbound firewall rules and no VPN.
The desktop KeeperDB app can connect to a tunneled endpoint the same way it connects to any direct-connect database. Combined with the Keeper Vault integration, the workflow becomes: 1. User clicks **Start Tunnel** on a PAM Database record in the Vault. 2. The Keeper Gateway establishes a zero-trust tunnel and returns the local port to the Vault. 3. User enters the localhost and local port into the KeeperDB app. 4. All traffic between the user's laptop and the target database is authenticated, end-to-end encrypted, and recorded as a Keeper privileged session. {% hint style="success" %} **Why Tunnels + KeeperDB beats a jump host.** No bastion server to maintain, no SSH key distribution. The tunnel is authenticated per user, the database session is recorded, and when the engagement ends you just revoke the Vault share. {% endhint %} ### Use Case: KeeperDB Proxy on a PAM Record Some customers want the best of both worlds — the tactile responsiveness of a desktop app, plus the zero-credential and recorded-session guarantees of KeeperPAM. That combination is enabled by enabling the **KeeperDB Proxy** option on a PAM Database record.
When KeeperDB Proxy is active on a record: * The Gateway stands up a **KeeperDB Proxy** listener for that record's protocol (MySQL / PostgreSQL / MSSQL wire protocol). * Connection traffic from the user's desktop KeeperDB app is routed to the proxy, which authenticates with Keeper, fetches the credentials Gateway-side, injects them into the protocol handshake, and then forwards traffic to the target database. * The user's desktop KeeperDB app is pointed at the proxy endpoint — **it never sees the real credentials, and the user never types them** — but they still get native desktop-app performance, native OS-level keyboard shortcuts, unmetered bandwidth, and the ability to run long exports without RBI overhead. This is the recommended configuration for **internal DBAs and SREs** who work with the same set of production databases every day: * No password in their keychain. * No password on their terminal history. * Full session recording for compliance. * Desktop performance (huge ER diagrams, long-running exports, multi-gigabyte result grids, offline notebook work on the local file system). ### Supported Databases KeeperDB supports six protocols out of the box, each with a native driver — no ODBC, no JDBC bridge, no driver-install step on the user's machine. | Database | Notes | | --------------- | ------------------------------------------------------------------ | | PostgreSQL | TLS, SCRAM-SHA-256, all modern auth modes | | MySQL / MariaDB | Text protocol for DDL compatibility, binary protocol for data | | SQL Server | Azure SQL, AWS RDS, on-prem; Windows and SQL Server authentication | | Oracle | Including Autonomous DB and Exadata Cloud | | Amazon Redshift | Redshift-specific quirks handled | | SQLite | File-based or in-memory; ideal for local scratch work | ### The User Experience Regardless of how the session was launched, the user lands in the same interface. A sidebar lists schemas and tables. A top tab bar switches between **Query**, **Data**, **Notebook**, **Monitor**, and **Graph**. A gear icon opens Settings. A chat bubble opens KeeperAI. #### Query Editor The Query tab is the SQL workspace. Provides syntax highlighting, autocomplete, multi-statement execution, and a toggle between tabular and record views. * **Multi-statement execution** — paste a migration script, hit **Run**, get per-statement status. * **Destructive-query confirmation** — any non-SELECT syntax triggers a modal listing exactly what's about to be executed before it runs. * **Per-session query history** — scoped to the current user's session; user-based or resource-based session persistence is available based on the PAM Settings of the database record. #### Data Grid Click any table in the sidebar and the Data tab opens the full paginated table browser. * **Pagination** — 50 rows per page default, configurable up to several thousand. * **In-place cell editing** — double-click a cell, edit the value, and KeeperDB generates a previewed `UPDATE` statement you confirm before it executes. * **Export to CSV, JSON, or SQL INSERT** — straight from the current filter / page state. #### Schema Explorer & ER Diagram The sidebar is a searchable, sortable tree of schemas and tables. Click a schema to see its tables, hover a table to see its row count and size, click overflow \[...] to view the table schema and CREATE syntax. #### Notebook (Scratchpad) Not every database task is a single query. The Notebook is a persistent, per-user scratchpad with SQL cells and Markdown cells, auto-saved every 2 seconds. * Build up a set of reusable queries for an investigation. * Document findings in-line in Markdown alongside the SQL that produced them. * Re-run any cell individually without losing the others' state. * Per-user or per-record session persistence based on the PAM Database configuration. #### Performance Monitor The Monitor tab is a real-time operational dashboard — the moment your database is on fire, this is the view you want open. {% hint style="info" %} **"The site is slow, what's happening?"** The Monitor tab answers this in under five seconds: who's connected, what they're running, what's blocking what, and which long-running query to kill. {% endhint %} Monitor support varies slightly by database: | Capability | PostgreSQL | MySQL | SQL Server | Oracle | Redshift | SQLite | | --------------------------- | :--------: | :---: | :--------: | :----: | :------: | :----: | | Active process list | ✅ | ✅ | ✅ | ✅ | ✅ | — | | Blocking chains | ✅ | ✅ | ✅ | ✅ | ✅ | — | | Lock analysis | ✅ | ✅ | ✅ | ✅ | ✅ | — | | Kill session | ✅ | ✅ | ✅ | ✅ | ✅ | — | | Server parameters inspector | ✅ | ✅ | ✅ | ✅ | ✅ | — | | AI-assisted triage | ✅ | ✅ | ✅ | ✅ | ✅ | — | Every live process shows its connection ID, user, database, the exact SQL it is currently executing, and elapsed time. Click a blocker in the blocking chain to see its full context. Click **Kill** to terminate a session (confirmation required). ### KeeperAI — Your Embedded DBA Co-Pilot KeeperAI is KeeperDB's integrated AI assistant. It opens as a chat panel on the right side of the UI, has full knowledge of the schema you're connected to, and can operate in three modes: 1. **Chat mode** — you ask a question in natural language, it answers in prose and (if appropriate) SQL. 2. **Autonomous mode** — you ask for an outcome, not a query. KeeperAI writes SQL, runs it against the database, reads the results, iterates if needed, and reports back. Read-only statements run without prompting; write statements surface the same destructive-query confirmation modal as a human-authored statement. 3. **Explain mode** — paste a SQL query and ask for an explanation. Useful for code review of a teammate's migration or for onboarding a new engineer into a legacy schema.
#### Supported AI Providers KeeperAI is provider-pluggable. Administrators choose the model vendor that fits their data-governance posture: * OpenAI * OpenAI-compatible endpoints (self-hosted, etc) * Anthropic * Google Gemini * Microsoft Azure OpenAI * AWS Bedrock (Claude, Llama, Titan, etc.) * Google Vertex AI [Learn More](/en/keeperpam/privileged-access-manager/keeperai.md#llm-provider-setup-instructions) on activation of KeeperAI on the Keeper Gateway {% hint style="info" %} **Your data stays in your walled garden.** Enterprise customers can wire KeeperAI to their own Azure OpenAI or AWS Bedrock endpoint so prompts and schema never leave their network perimeter. {% endhint %} #### KeeperAI Chart Generation Ask *"show me revenue by product category for the last 30 days"* in autonomous mode and KeeperAI will: 1. Query the schema to find the relevant tables. 2. Write and execute the aggregation SQL. 3. Emit a `chart` JSON spec describing the result as a bar chart. 4. Render the chart inline in the chat panel. Supported chart types: bar, line, pie, area, scatter. The underlying data comes directly from the live query — no hallucinated numbers. #### KeeperAI in the Performance Monitor From the Monitor tab, a **Triage with KeeperAI** action packages the current process list, blocking chains, and server parameters into a prompt and asks the AI to summarize *"what's wrong and what should I do next."* The AI suggests which queries to kill, which indexes are missing, and which parameters are misconfigured. #### KeeperAI Scope Guardrails KeeperAI is strictly scoped to database work. It will answer questions about SQL, schema design, indexing, query optimization, performance tuning, troubleshooting, and database theory. {% hint style="warning" %} **Defense in depth.** KeeperAI's guardrail is two layers deep: a hoisted, imperative refusal clause at the top of the system prompt, plus a post-response validator that replaces any blocked response with a canned "I'm a database assistant…" refusal. Even when a user crafts a prompt injection, the AI cannot be used to generate arbitrary code inside a KeeperPAM session. {% endhint %} ### KeeperAI and Session Recording / Monitoring KeeperPAM already records every keystroke and frame of a privileged session. KeeperAI activity lives inside that same recording boundary — but it also carries its own structured audit trail so security teams can reason about AI-initiated actions specifically: * **Every AI-executed SQL statement** is logged the same way a human-typed statement is, with the session ID, the statement text, the success flag, and the timestamp. * **Every AI-initiated destructive statement** surfaces through the same confirmation modal a human must click — the user remains the explicit authorizer of any write. * **Every chart, explanation, and autonomous iteration** is attributed to the session recording, so a compliance reviewer can reconstruct *"the DBA asked KeeperAI to find accounts with zero activity in 30 days; KeeperAI ran queries X, Y, Z; the DBA approved statement W"* from a single pane of glass. ### Security Benefits #### Credentials Never Live on the Endpoint | Threat | How KeeperDB neutralizes it | | ------------------------------------ | -------------------------------------------------------------------------------------------------- | | Stolen laptop, forensic disk image | No credentials on disk. `zeroize`-on-drop for in-memory password material. | | Shell history or config-file leakage | No local credentials stored on disk | | Git-committed connection strings | There is no connection string to commit. | | Shared-password sprawl | Every launch pulls the current password from the Vault. Rotate once — everyone gets the new value. | | Contractor offboarding | Revoke the Vault share. Done. No need to rotate the database password. | #### Zero-Knowledge and Per-User Isolation KeeperDB inherits Keeper's zero-knowledge architecture: secrets are only ever decrypted on a user's device or inside the customer's Gateway, never on Keeper's servers. When a Gateway is shared across multiple users, each user's scratchpad, settings, and schema cache are isolated. #### Audit Everywhere * **Privileged session recording** (via KeeperPAM) captures every rendered frame. * **Structured audit log** (in-memory ring buffer, per-session) captures every query action. * **KeeperAI scope log** captures every guardrail decision. * **KSM access log** (via Keeper's normal KSM audit trail) captures every credential fetch from the Vault. Collectively, these answer the regulated-industry question *"who ran what, against which database, when, and who approved any change?"* without a forensic investigation. ### Why Not Just Use DBeaver / DataGrip / TablePlus? General-purpose database clients are great for a developer on their laptop connecting to their own sandbox. They fall apart at enterprise scale: | Concern | Typical 3rd-party client | KeeperDB | | -------------------------- | ----------------------------------------- | ----------------------------------------------- | | Credential storage | Local keychain / JSON workspace file | Never stored on the client | | Credential rotation | Every user re-enters manually | One Vault change, everyone's current | | Contractor offboarding | Rotate database password | Revoke Vault share | | Session recording | No | Yes, via KeeperPAM | | DBA assistant AI | Paid add-on, sends schema to vendor cloud | Included, can pin to customer's own AI provider | | Multi-database coverage | Varies; often fragmented plugin ecosystem | Multiple protocols, one UI | | Performance monitor | Separate tool or missing | Built in | | Zero-trust network posture | Requires VPN / bastion | Works with Keeper Tunnels | | Install-on-endpoint burden | Drivers, JDBC jars, ODBC bridges | Zero local drivers — all bundled | | Compliance audit | Client-side logs, if any | Centralized, server-enforced, tamper-evident | {% hint style="danger" %} **Audit gaps create compliance risk.** If an auditor asks for every query run against a production database over the last 90 days, most database clients cannot provide a complete answer. KeeperDB can return that activity from a centralized audit trail. {% endhint %} ### Getting Started #### From a KeeperPAM `pamDatabase` record 1. In the Keeper Vault, navigate to the PAM Database record. 2. Click **Launch KeeperDB**. 3. An RBI tab opens with KeeperDB already connected. No setup on the user side. Administrators configure the record once (host, port, protocol, credentials, JIT, Workflow, KeeperAI) and Gateway-side policy controls who can launch it. ### Frequently Asked Questions
Does KeeperDB require a Keeper Enterprise subscription? The embedded KeeperPAM experience requires KeeperPAM. The standalone desktop app works for any Keeper account tier that supports Secrets Manager record retrieval and can also be used in a purely local mode without any Keeper account at all.
Where is data stored? Row data is never persisted by KeeperDB — it is streamed from the database to the UI and held in memory only while the session is active. User-specific artifacts (notebook cells, UI preferences) are stored either in the Keeper Secrets Manager vault (default for enterprise deployments), in the user's local file system (desktop app), or in memory (ephemeral mode).
Can we point KeeperAI at our own Azure OpenAI endpoint? Yes. KeeperAI supports Azure OpenAI, AWS Bedrock, Vertex AI, and any OpenAI-compatible self-hosted endpoint as first-class providers. Configuration is per-deployment; no traffic is routed to a Keeper-hosted AI service.
What happens if the AI provider is unavailable? KeeperDB continues to work normally. The AI chat panel surfaces an "unavailable" state, but every other feature — query editor, data grid, monitor, ER diagram, scratchpad, import/export — continues to operate.
Can the standalone desktop app connect to databases that aren't in Keeper? Yes. The desktop app supports direct connections with user-entered credentials (stored in the OS secure store with `zeroize`-on-drop discipline), connections through Keeper Tunnels, and connections to PAM-record-proxied databases. A single installation can use all three simultaneously.
How does the destructive-query confirmation work with KeeperAI autonomous mode? Identically to a human-typed statement. KeeperAI can freely run read-only queries (`SELECT`, `SHOW`, `EXPLAIN`, `DESCRIBE`) without prompting. Any write statement — `INSERT`, `UPDATE`, `DELETE`, `DROP`, `CREATE`, `ALTER`, `TRUNCATE`, and dialect-specific variants like `BULK INSERT` / `COPY … FROM` / `LOAD DATA` — triggers a modal that shows the exact SQL before it executes. The user is always the approver.
What's the difference between KeeperDB Tunnels and KeeperDB Proxy? A **Tunnel** exposes the database's native wire protocol at a local port on the user's machine. The user's desktop app talks to `127.0.0.1` as if the database were local, and the credentials come from the user (either entered, or pulled from the Vault at the app layer). A **KeeperDB Proxy** adds credential injection at the Gateway. The user's desktop app connects to the proxy, the proxy authenticates against Keeper and fetches the credentials server-side, and the database handshake is completed without the user's machine ever touching the password. KeeperDB Proxy is the stricter, more zero-trust configuration.
Can I audit KeeperAI's behavior? Yes. AI interactions appear in the session recording and in the audit log tied to the user who approved them.
--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.keeper.io/en/keeperpam/privileged-access-manager/keeperdb.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.