I Didn't Want My AI Agent to Have a Database Password, So I Built a Gateway

The initial concept for the AI agent system was straightforward: provide the agent with a database URL, let it generate SQL, run the query, and return the results to the model. However, this approach proved problematic. Even a read-only user could still execute extensive queries, hold connections, access unauthorized tables, or return excessive data.

A database password, even if obscured within an agent configuration file, remained a sensitive piece of information. This realization sparked the creation of n0, an open-source Go platform situated between AI agents and enterprise data. n0's main objective was to manage authentication and tenant context, while delegating SQL safety evaluation to a separate query service.

The design philosophy behind n0 emphasized that the AI agent determines its queries, while the platform governs whether the queries are permitted and how they are executed. The request flow between components is as follows: AI agent ↔ MCP / Streamable HTTP → Agent Gateway (JWT, tenant context, tool routing) → Meta Service (workspaces, metadata, connections, schema, connections, schema) → Query Engine (NATS JetStream SQL sandbox, asynchronous jobs, result lifecycle) → Connection Manager (PostgreSQL, MySQL, ClickHouse, etc.).

The core of n0's architecture lies in its security model, which separates the MCP server from database authentication and credential handling. The MCP server, residing within the Agent Gateway, translates MCP calls into the same internal clients used by the REST API, without opening database connections or managing credentials. This design decision ensures that security rules remain consistent across both the API and AI paths.

The MCP endpoint is accessible at http://localhost:8083/mcp and utilizes the same JWT middleware as the REST API. The tenant ID used for internal requests is derived from the verified JWT context, not from an agent-supplied tenant_id argument. The MCP server exposes six tools: get_schema, submit_query, get_query_status, get_query_result, list_connections, and list_workspaces.

Notably, there is no execute_sql_now tool or tool that returns a connection string. This minimalist toolset serves as a foundational security model for the platform. Once the gateway is operational, clients can submit queries using a standard MCP JSON-RPC request. The response from the Query Engine is minimal, containing only the job ID and status.

The agent then polls the system for query status and retrieves paginated results using the get_query_status and get_query_result endpoints. This design enables efficient handling of analytical queries, as it prevents the need to maintain open connections while the query runs. The implementation of the MCP tools is streamlined, with the official Go SDK handling the protocol details and typed tool schemas.

The handler component then leverages the existing Query Engine client, ensuring a unified approach for MCP, REST, and testing scenarios. The SQL submitted through the submit_query tool is handled by the Query Engine, which implements a conservative validation process. This validator checks for single SELECT statements, rejects DML commands, limiting statements, excessive or malformed limits, and verifies referenced tables.

By implementing this security-focused architecture, n0 aims to provide a robust and secure platform for AI agents to interact with enterprise data, mitigating the risks associated with unauthorized data access and over-privileged queries.