MCP Database Security: Seven Boundaries Every AI Agent Needs

Connecting an AI agent to a production database can turn a slow investigation into a short conversation. The agent can inspect a schema, generate a query, and help explain a failed migration or an unexpected metric. The same connection can also expose sensitive records or modify production data if the access path is treated as a single trusted pipe.

The Model Context Protocol gives AI clients a standard way to discover and call tools. It does not, by itself, decide which user may connect, which tables the agent may see, which SQL statements may execute, or how the database enforces tenant boundaries. Those decisions belong to separate security controls.

A useful design therefore treats database access as a chain of independent boundaries. Each boundary should reduce the authority passed to the next one. If one control is misconfigured, the remaining controls should still limit the result.

1. Identify the client before exposing tools

A remote MCP endpoint should not treat possession of its URL as authorization. The service needs a way to identify the connecting client or user before it returns tool definitions or accepts calls.

API keys can provide a simple client identity for automation and controlled internal use. OAuth can provide a user-oriented authorization flow when the client supports it. In either case, authentication answers only one question: who is connecting?

It does not answer which database objects that identity may access. It also does not replace the database account used by the server. Keeping identity separate from permission makes revocation and investigation much easier. One MCP credential can be disabled without rotating every database password, and a database credential can be rotated without updating every AI client.

2. Narrow the MCP link policy

After the client is identified, the MCP layer should expose only the operations required for that client’s workflow. A reporting assistant may need schema discovery andSELECT. A migration workflow may need additional write or DDL operations. Those two clients should not receive the same policy simply because they connect to the same database.

Useful link policies distinguish between read-only, ordinary data changes, administrative operations, and custom resource-level permissions. A custom policy can narrow access by table and operation rather than granting one broad database capability.

This is the practical distinction between MCP authentication and authorization. Authentication establishes the caller’s identity. Authorization evaluates whether that identity may request a particular tool, operation, or resource.

3. Reduce the visible schema

Schema visibility is a capability of its own. An agent often needs table names, columns, keys, relationships, views, and indexes before it can formulate useful SQL. It does not necessarily need to discover every object in a production cluster.

Reducing the visible schema improves both security and accuracy. Sensitive or irrelevant tables do not enter the model’s working context, and the agent has fewer similarly named objects to confuse. This matters in databases that contain internal administration schemas, legacy tables, billing data, authentication records, and multiple application domains.

The MCP policy should hide resources the client does not need. Database grants should independently enforce the same or a narrower boundary. Hiding a table from discovery is useful, but it is not a substitute for revoking access to that table at the database layer.

4. Use a dedicated database role

The database credential defines the maximum authority available after a request passes the MCP layer. It should belong to a dedicated role created for the agent workflow, not to the database owner, application administrator, or a developer’s personal account.

For a PostgreSQL reporting assistant, the role might receiveCONNECT, schemaUSAGE, andSELECTon a limited set of tables or views. It should not inherit ownership, superuser privileges,BYPASSRLS, broad function execution, or unnecessary write grants.

A hosted PostgreSQL MCP service can keep this credential on the server side instead of copying it into every desktop client. For example, a hosted PostgreSQL MCP server with scoped permissions can provide a remote endpoint, link-level policy, encrypted credential storage, and reviewable query activity. The database role must still remain the final authority.

5. Enforce tenant boundaries inside PostgreSQL

Table grants answer whether a role may query a table. They do not automatically restrict which rows that role may read. Multi-tenant applications therefore need a row-level boundary as well.

PostgreSQL Row-Level Security can apply a policy to each command and evaluate the effective database role and session context. A reliable setup requires more than enabling RLS. The agent must connect as a non-owner role withoutBYPASSRLS, the table must have row security enabled, and every permitted command must have an explicit policy.

The application also needs a trustworthy method for setting tenant context. A value supplied by the model should never become trusted merely because it arrived through an authenticated MCP connection. The complete setup should be tested for allowed rows, cross-tenant reads, writes, missing context, owner behavior, and roles that can bypass policy.

A practical PostgreSQL Row-Level Security setup for AI agents treats RLS as one layer in a wider authorization path, not as a replacement for client identity or MCP permissions.

6. Put operational limits around query execution

A query can be authorized and still be unsafe operationally. An unbounded join, an accidental full-table scan, or a function with unexpected behavior can consume resources or expose far more data than the user intended.

Database-connected agent workflows should define query timeouts, result-size limits, connection limits, and transaction behavior appropriate for interactive use. Read-only transactions can reduce risk for analytical workflows, but the label “read-only” should not be treated as proof that every allowed statement is harmless.

Functions deserve special attention. ASELECTcan call a function, and a function may perform work beyond returning rows. Review executable functions, security-definer behavior, extensions, and search paths as part of the role design.

7. Record enough activity to investigate and revoke

Database logs remain an important source of truth, but they may identify only the shared database role. The MCP layer should record enough context to connect an operation with the client identity, MCP link, connection, outcome, and time.

These records help answer practical questions after an incident or unexpected result:

• Which client requested the query?
• Was the request allowed or denied?
• Which database connection and object were involved?
• Did the failure happen at the MCP policy or database boundary?
• Can one client be revoked without disrupting other users?

Logging is not preventive authorization. It should not justify broad permissions, and sensitive result data or credentials should not be copied into logs merely to make an event easier to inspect. Its purpose is attribution, debugging, and policy review.

Test the complete access path

A successful query proves very little. Security testing should begin with denied behavior and cover every boundary in the chain.

1. Connect without a valid client credential and confirm that tools are not exposed.
2. Request a hidden table and confirm that discovery and execution both reject it.
3. Attempt write and DDL statements through a read-only link.
4. Run the same statements directly with the effective database role.
5. Test permitted and forbidden tenant rows under Row-Level Security.
6. Exercise timeouts, large results, revoked links, and rotated credentials.
7. Confirm that successful and denied operations can be traced to the expected client.

This approach catches configuration gaps that are invisible in a happy-path demo. It also gives the team a repeatable test suite for permission changes.

Security comes from intersecting controls

No single label makes database access safe. OAuth does not replace table grants. A read-only MCP preset does not prevent sensitive reads. Row-Level Security does not identify the AI client. Activity logs do not stop an unauthorized operation.

The useful security property comes from the intersection of client identity, narrow link policy, reduced schema visibility, a dedicated database role, row-level enforcement, operational limits, and reviewable activity. Each layer has a smaller job, and each layer limits the consequences of a mistake in another.

That is the right standard for database-connected AI agents: not unrestricted access followed by monitoring, but the smallest reliable path to one defined workflow.