Skip to content

Security FAQ

Last updated

View as Markdown

This document describes the controls that limit what DBGorilla, and engineers using DBGorilla, can do to a production database. It covers the collector, the MCP integration, natural-language queries and the GitHub CI bot, and states the current status of each control.

Questions about any control described here may be directed to security@dbgorilla.com.

  • DBGorilla has no direct network path to your database. Everything goes through the collector, which runs in your network, connects with a read-only role you create, and makes outbound connections only.
  • The agents interact with your database only through a fixed set of tools. None of those tools can write.
  • You can turn off command execution entirely from the collector config, in your infrastructure, and DBGorilla cannot turn it back on.
  • Anything DBGorilla proposes is a recommendation. A person still reviews and applies every change.

The collector connects with a dedicated read-only database role that you create and control. The grants are pg_monitor, plus USAGE and SELECT on the schemas you want captured, which is the same class of access a database monitoring agent already has in most environments. The collector cannot escalate beyond the privileges of that role. The exact grants are in Collector Installation.

What does the collector read, and what load does it add?

Section titled “What does the collector read, and what load does it add?”

Host, network, storage and I/O metrics, query statistics from pg_stat_statements, topology and schema. The additional load on the instance is negligible; in most environments it reads the same statistics that existing monitoring already reads.

Can the agent write to my database through the collector?

Section titled “Can the agent write to my database through the collector?”

No. The agent only interacts with your database through tools, and none of the tools it has can write. There is no tool for arbitrary SQL, no tool for DDL, and no tool that modifies or removes data. The collector is the single choke point for everything DBGorilla reads or runs, and it is entirely under your control.

Can command execution be disabled entirely?

Section titled “Can command execution be disabled entirely?”

Yes. The [commands] block in collector.toml is optional and lives in your infrastructure. When it is disabled, the collector will not execute any command on your behalf: the agents are limited to the metrics and metadata the collector reports. When it is enabled, it permits exactly two read-oriented operations:

  • explain: plan-only EXPLAIN. The query is never executed.
  • execute_query: a single SELECT, capped at 1,000 rows with a 30-second statement timeout.

It can be restricted further with allowed = ["explain"]. In both cases, anything that runs is bounded by the privileges of the read-only role. Disabling [commands] also disables natural-language queries entirely.

What network access does the collector need?

Section titled “What network access does the collector need?”

Outbound to otlp.dbgorilla.com and auth.dbgorilla.com on port 443, and no other destinations. The collector accepts no inbound connections. Connections to your database use TLS; verify-full is the recommended mode.

Can an agent in my IDE run arbitrary SQL against my database?

Section titled “Can an agent in my IDE run arbitrary SQL against my database?”

No. No raw SQL tool is exposed over MCP. Agents in your IDE cannot compose and execute arbitrary statements against your database through the integration.

Context only: query performance data, index usage, run frequency, topology and schema. This removes the need for an engineer to run EXPLAIN ANALYZE against the primary on an agent’s behalf.

Can DBGorilla run EXPLAIN ANALYZE on production?

Section titled “Can DBGorilla run EXPLAIN ANALYZE on production?”

No. DBGorilla SaaS runs plan-only EXPLAIN through the collector, and only when you have enabled [commands]. EXPLAIN ANALYZE executes the query, and DBGorilla does not do that against your database.

MCP keys are scoped to a single user. Each user has one MCP key at a time; it is shown in the app, and regenerating or deleting it there revokes the previous one immediately. API keys are scoped to a single tenant. Both are encrypted at rest.

Yes. Clients that support it, such as Claude Desktop connectors, authenticate to the DBGorilla MCP server with OAuth rather than a bearer key. Other clients use a per-user bearer key.

This path is typically used by analysts to query production data that has not yet reached the warehouse. Three controls apply before a query runs, and a fourth disables the path entirely:

  • The generated query is shown for preview before it executes.
  • Destructive-operation checks reject any statement that would modify or remove data. Only a single SELECT can run.
  • Results are capped at 1,000 rows and a 30-second statement timeout, enforced at the collector.
  • Disabling [commands] in the collector config disables natural-language queries entirely.

It reviews pull requests and posts comments. It does not open, modify or merge pull requests, and it does not apply changes to any database. Its findings are advisory; a person approves and merges every change.

Are recommendations tested before I see them?

Section titled “Are recommendations tested before I see them?”

Yes. Recommendations are validated in an experiment before they are surfaced. Experiments run in DBGorilla infrastructure, at our cost, not against your production instance.

Metadata, schema and query patterns. Database row content is not sent to the model layer and is not written to logs.

No. Customer data is never used to train models.

Control Status
Collector connects read-only, with permissions equivalent to a database monitoring agent Enforced today
DBGorilla has no direct network path to your database; collector is outbound-only Enforced today
Command execution can be disabled entirely from the collector config, in your infrastructure Enforced today
No raw SQL tool exposed over MCP Enforced today
EXPLAIN is plan-only; EXPLAIN ANALYZE is not run Enforced today
Destructive-operation checks on generated statements; only a single SELECT can run Enforced today
Query preview before a generated query executes Enforced today
Row-count limit (1,000) and 30-second timeout on natural-language query results Enforced at the collector. Not yet configurable in the application.
Recommendations validated in an experiment before they are surfaced Enforced today
MCP keys scoped to a single user; API keys scoped to a single tenant; both encrypted at rest Enforced today
OAuth authentication for MCP clients that support it Available today
GitHub CI bot posts review comments only; it does not open, modify or merge pull requests Enforced today. Automated pull requests are on the roadmap.
Audit log, with export Available today on Business and Enterprise plans.
Single sign-on (SAML / OIDC) Available today on Business and Enterprise plans. SCIM and custom roles on Enterprise.

Security questions, vulnerability disclosures and requests for further review: security@dbgorilla.com.