Security

Built for teams that cannot put shadow AI on production databases.

DBGorilla is a centralized, IT-managed agent runtime. Your security team sets the policies. Agents mediate access. Changes are proven on clones before they touch production.

AI next to your database should not mean unmanaged AI in your database

Most “chat with your database” setups put a model one hop from production credentials. That is easy for a developer and hard for security to live with.

DBGorilla is an intelligent layer between your team and your infrastructure: a runtime IT controls. People and tools talk to agents that already understand the environment. They do not get a free-form session on production by default.

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

Earn production trust the way a new hire would

You would not hand a new engineer unrestricted write access on day one. The runtime should work the same way: observe, explain, prove, then act only where you allow it.

Transparency

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

Production-affecting change requires the approval path you configure.

Auditability

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

Boundaries

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

Reversibility

Prefer change paths you can describe how to undo; clones exist to test before you commit.

Isolation options

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

Observe first. Act only where you unlock it.

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 gets production-shaped without production data. On-prem and air-gapped installs build clones on your own hardware.

You stay responsible for backups, change control, and production readiness. We give you proof and rollback paths, not a black box that “just ships the fix.”

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. Humans decide what ships.

03 Act (where you enable it)

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

Your databases stay yours.

Where your data goes, and where it does not. The shape of your database crosses the line. The contents stay put 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, 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 are not here to harvest
  • 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.

Meet the environment you already have.

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

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 are why many of our best-fit customers cannot “just move everything to a managed cloud.” DBGorilla supports deployment postures that match that reality:

SaaS

Fastest path to value with 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.

Built for the questionnaire, not around it.

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 Terms. We can discuss coordinated testing under NDA 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)

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) instead of hoping a personal AI tool stays inside policy.