Secure Database Access for AI Agents with db-mcp-gateway

Artificial intelligence agents increasingly need to read data from production databases to generate accurate responses. Providing that access without exposing credentials is a hard problem for Platform and Security teams. The db-mcp-gateway project offers a self-hosted Model Context Protocol gateway that isolates credentials, integrates with enterprise SSO, and records a complete audit trail. This article explains how the gateway works, how to configure it, and why it fits a zero trust security posture.

The gateway stores all database passwords internally. AI agents never receive a connection string, and no log line ever contains credentials. The data flow looks like this:

AI Agent → MCP Protocol → Gateway → Database Enter fullscreen mode Exit fullscreen mode The gateway performs authentication and then forwards only the query result to the agent. This eliminates the risk of credential leakage through developer laptops, CI pipelines, or error messages.

Authentication is driven by SSO providers such as Okta, Google Workspace, Entra, Authentik, or Keycloak. The login flow happens in the browser, so no embedded browsers are required. Permissions are expressed as grants in a YAML file and are tied to groups defined in the SSO system.

grants: - group: backend-devs databases: [ production_postgres ] actions: [ query_read ] constraints: schemas: [ public, analytics ] row_limit: 1000 require_reason: true Enter fullscreen mode Exit fullscreen mode Each grant can restrict the schemas that may be queried, cap the number of rows returned, and require a reason field for compliance reporting. Because the YAML file lives in version control, every change is auditable through pull requests.

Every request that passes through the gateway is logged with the following fields:

These logs are stored in a PostgreSQL table inside the gateway container, providing an immutable record that can be queried for security reviews or compliance audits.

The permission model lives entirely in code. A typical workflow is:

This approach aligns with GitOps practices and removes the need for an in-band admin UI, reducing the attack surface.

The gateway is distributed as a single Docker image. A quick start looks like this:

# Pull the latest image docker pull ghcr.io/developerz-ai/db-mcp-gateway:1.1.1 # Run with your configuration docker run -p 8080:8080 \ -v $( pwd ) /config.yaml:/app/config.yaml \ ghcr.io/developerz-ai/db-mcp-gateway:1.1.1 Enter fullscreen mode Exit fullscreen mode The container uses a PostgreSQL instance for its own state and audit logs. It supports PostgreSQL and MongoDB as target databases; other engines are rejected at boot time, which simplifies security hardening.

They can grant AI agents read-only access to production databases without ever storing passwords on the host. The audit trail satisfies internal compliance requirements.

Developers write natural language prompts that the AI agent translates into safe SELECT statements. Because the gateway enforces row limits and schema filters, accidental data exposure is prevented.

Full attribution of each query to an SSO user enables detailed investigations. The immutable logs can be exported for external audits if needed.

db-mcp-gateway provides a practical way to let AI agents query production databases while keeping credentials hidden, enforcing least privilege, and delivering a complete audit log. Its reliance on standard SSO providers and a simple Docker deployment makes it a good fit for organizations that already practice GitOps and zero trust security. To get started, clone the repository and follow the quick start guide.