Security

What DBGorilla is, from a security standpoint

DBGorilla is a centralized, IT-managed agent runtime for database operations. Your security team sets the policies, agents mediate access to your databases, and changes are proven on clones before anyone applies them to production.

Most “chat with your database” tools place a model one hop from production credentials. DBGorilla places a runtime that IT controls between your team and your infrastructure. People and tools work through agents that already understand the environment; nobody receives a free-form session on production by default.

The runtime is built on five principles:

  • Centralized runtime, not a personal plug-in

  • Least privilege on every connection you attach

  • Human approval on the path to production change

  • Audit trail on investigations and actions

  • Clone validation before risky change

How access is granted

Access is granted the way it would be to a new engineer: observe first, explain, prove, and act only where you allow it.

Transparency

Findings are reported in plain language: what was examined, what was hypothesized, and what the proof showed.

Production-affecting change requires the approval path you configure.

Auditability

Who connected what, what was investigated, and what was approved are all available for review.

Boundaries

Roles, environments and deployment posture define where the runtime can operate.

Reversibility

Change paths you can describe how to undo are preferred; clones exist to test before you commit.

Isolation options

SaaS, private VPC or bring-your-own cloud, dedicated or on-prem, and air-gapped patterns for estates that need them.

Observe, recommend, act

Database changes must be explainable, reversible and auditable. DBGorilla validates solutions on isolated database clones with production-like workloads before anyone applies a change to the real system.

Clones are built for experimentation, not for copying your production estate into our cloud. A clone is built from your schema, your planner statistics and synthetic data shaped to match; it holds none of your rows. Collecting planner statistics is an on-request, audited step, because sampled column values appear inside them; it is how a clone becomes production-shaped without production data. On-prem and air-gapped installs build clones on your own hardware.

You remain responsible for backups, change control and production readiness. DBGorilla provides proof and rollback paths, not an opaque system that applies fixes on its own.

01 Observe

Connect with the least privilege required, typically read-oriented access for analysis unless a feature you enable needs more. Agents learn topology, workload shape, and what normal looks like for your systems.

02 Recommend

Investigations surface root cause, options, and clone-backed proof where relevant. People decide what ships.

03 Act (where you enable it)

Only the action classes you authorize, under your roles and policies, logged and attributable.

Where your data goes, and where it does not

The shape of your database crosses the boundary. The contents stay where they are unless you ask.

Diagram: your network holds your Postgres or MySQL and the dbg-collector, which strips literals before anything crosses the outbound-only boundary. Schema, normalized queries, plans and metrics arrive at DBGorilla’s private cloud, where analysis and models run over a private endpoint, never a public model API, and are never trained on your data. On request and audited: EXPLAIN, capped SELECT and planner statistics. Your tools receive findings; an agent you connect over MCP uses the model you picked.

Your rows never leave unless you ask for them: audited, capped, and off by default. Your queries are normalized before we see them. Models run in our private cloud and are never trained on your data.

DBGorilla processes the operational signals required to run the agent runtime: performance and workload metadata, investigation context, logs, and outputs tied to the features you use. We never hold a copy of your tables.

What we protect

  • Encryption in transit (TLS)

  • Encryption at rest on all platform storage (Azure storage-service encryption), with platform secrets in Azure Key Vault

  • Database credentials stay in your network, with the collector. The SaaS control plane never holds them; on-prem deployments hold their own configuration on your hardware

  • MFA and least privilege for privileged internal access

  • Retention aligned to plan (product data) plus minimum retention for security/audit logs

What we do not collect

  • Your row-level business content as a training corpus for other customers

  • Unrelated application secrets beyond the access you intentionally grant

Enterprise customers can negotiate DPAs, security addenda, retention, and dedicated tenancy under a signed agreement.

Deployment options

On-prem and air-gapped: your data never leaves your network. The database, DBGorilla and the models all run on your hardware. Nothing requires internet access.

Diagram: on-prem and air-gapped, everything runs inside your network: your database, DBGorilla installed by you from a checksum-verified bundle, and models you host on vLLM. Outside the perimeter, DBGorilla cloud and public model APIs are crossed out: nothing goes there. Optionally, bring your own model API key instead of hosting: your key, your egress, your choice.

With models you host, nothing derived from your data leaves either.

Privacy and compliance requirements mean many of our best-fit customers cannot move everything to a managed cloud. DBGorilla supports deployment postures that reflect that:

SaaS

Fastest path to value, with a DBGorilla-hosted control plane

Private VPC / bring-your-own cloud

Keep data paths inside your cloud boundary (Business+)

Dedicated / on-prem

Enterprise fleets and procurement-driven installs

Air-gapped

Environments that cannot depend on public network egress

Enterprise plans can include dedicated tenancy, custom data retention, custom security terms, and compliance documentation under a negotiated agreement.

Enterprise review

Security and procurement teams should not have to reverse-engineer an AI product from a demo. We support enterprise review with clear architecture answers, security documentation, and plan features that map to common controls (SSO, RBAC, audit export, dedicated deployment).

SOC 2

Enterprise plans include SOC 2 and compliance support. Ask for current certification status and the questionnaire packet.

Security questionnaire

One intake through contact sales, one standard packet back: architecture overview, data flow, and subprocessors.

Penetration testing

Customer-initiated testing of the Services requires prior written consent per our Terms. Coordinated testing under NDA is available for Enterprise.

Available today

  • IT-managed access: RBAC and SSO (OIDC/SAML) on Business+; Enterprise adds SCIM and custom roles

  • Audit log export on Business+

  • The deployment postures above, for regulated buyers

By arrangement

  • DPAs, custom retention, custom security terms, and compliance documentation on Enterprise

  • Coordinated penetration testing under written agreement (customer-initiated testing of the Services requires prior consent per our Terms)

Shared responsibility

We secure the platform. You secure the connections. DBGorilla is not a substitute for your security, compliance, or DBA teams. You remain responsible for:

  • Credentials, IAM roles, and database permissions you grant

  • Change control and production approvals

  • Backups, disaster recovery, and regulatory obligations on your data

  • How your organization uses the product’s output and connected third-party tools

The runtime is designed so those responsibilities are enforceable (roles, audit, least privilege, deployment choice) rather than dependent on a personal AI tool staying inside policy.

For each control in detail, including what is enforced today, see theSecurity FAQ.

Test driveStart free