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

Introduction

AI agents need to read data from production databases, but exposing connection strings to those agents creates a serious security risk. The db-mcp-gateway solves this problem by acting as a trusted intermediary that enforces credential isolation, SSO-driven authentication, and a complete audit trail. This article walks through the core security model, configuration, and practical usage for Platform/SRE teams, backend developers, and security officers.

Core Security Principles

Credential Isolation

The gateway stores all database passwords inside its container. AI agents never receive a URL or credential; they only send MCP protocol requests and receive query results. This eliminates the chance of credential leakage in logs, error messages, or responses.

Identity & Access Control

Authentication is performed via SSO providers such as Okta, Google Workspace, Entra, Authentik, or Keycloak. The flow is browser-based, requiring no embedded browsers inside the agent. Permissions are expressed as grants in a YAML file, for example:

grants:
  - group: backend-devs
    databases: [production_postgres]
    actions: [query_read]
    constraints:
      schemas: [public, analytics]
      row_limit: 1000
      require_reason: true

Each grant ties a user group to a set of allowed actions, schemas, and optional constraints such as row limits. The gateway validates the user’s group membership in real time before executing any query.

Audit Trail

All queries are logged to a PostgreSQL table that records the SSO user, group, grant, timestamp, and the exact SQL statement. This immutable log can be queried via the get_query_history endpoint, providing the evidence needed for compliance reviews.

Config-as-Code

Permissions live in a YAML file that is version-controlled. Because there is no in-band admin UI, changes must be reviewed through pull requests, ensuring that any modification to database access is auditable. The gateway’s state and audit logs also reside in PostgreSQL, making it easy to back up and restore.

Deployment

Deploying the gateway is straightforward: a single Docker container and a configuration file. The following commands illustrate a quick start:

# Pull the latest image
ocker pull ghcr.io/developerz-ai/db-mcp-gateway:1.1.1

# Run with your config
 docker run -p 8080:8080 \
  -v $(pwd)/config.yaml:/app/config.yaml \
  ghcr.io/developerz-ai/db-mcp-gateway:1.1.1

The gateway supports PostgreSQL and MongoDB as backend databases. Attempts to start with MySQL or MSSQL are rejected, reducing the attack surface.

Use Cases

Platform / SRE Teams

Teams can grant AI agents read-only access to production databases without ever distributing passwords. The audit trail satisfies internal security policies and simplifies incident investigations.

Backend Developers

Developers can query production data using natural language through the run_query endpoint, knowing that each request is attributed to their SSO identity and constrained by the grant’s row limit.

Security Officers

The combination of credential isolation, SSO authentication, and immutable audit logs provides a strong foundation for compliance readiness. While the gateway itself is not certified, it supports compliance efforts by delivering the required controls.

Conclusion

db-mcp-gateway offers a pragmatic approach to secure database access for AI agents. By keeping credentials inside a hardened gateway, enforcing SSO-based identity, and recording every query, it addresses the core concerns of Platform/SRE teams, developers, and security officers. The self-hosted nature gives organizations full control over the deployment and audit data. For the latest code and documentation, visit the GitHub repository:

https://github.com/developerz-ai/db-mcp-gateway

---

This article was written by a practitioner who uses db-mcp-gateway in production environments.