Read-only database tools for AI: bound the query, role and result

A read-only AI database tool needs three bounds: the database role's real privileges, the permitted query surface and the resource budget for each result. Prefer curated operations when the workflow is known. If SQL is necessary, constrain it with database permissions and execution limits rather than relying on a prompt or a string check. Reads can still expose the wrong records or exhaust capacity.

Start with the business question

For a synthetic reporting assistant, define the allowed question as listing active workspace members and their current plan state. A curated list_workspace_members operation can accept a bounded filter and use a reviewed query. It need not expose arbitrary schema names, joins or free-form SQL. The server resolves workspace scope from verified identity and returns only fields required for the task.

Microsoft's postgres-mcp usage guide describes its own tools, connection options and security model. Review the installed revision and configuration before using its behavior as a reference. The guide's current overview identifies a specific stdio protocol revision; do not present it as proof of support for every modern HTTP lifecycle. A database tool's transport compatibility and database permissions are separate review items.

Microsoft postgres-mcp usage and security model

Compare curated reads with a constrained SQL surface

A curated tool is easier to document and evaluate because its inputs and returned fields are stable. A SQL tool provides flexibility for exploratory work but adds parser, schema, privilege and cost boundaries. Give it an application role that cannot write or read unrelated schemas. Inspect function execution privileges and views as well as table grants; classifying a statement as SELECT does not describe every effect available through database functions.

Use a disposable database with two synthetic schemas. Grant the reporting role access only to the intended view, then connect as that role rather than a table owner or administrator. Confirm that an attempted write and an unrelated-schema read are refused. A tool description saying read only is not an assertion of the actual database connection's authority.

-- Illustrative grants for a disposable reporting lab, not run here.
GRANT CONNECT ON DATABASE fixture_db TO fixture_reader;
GRANT USAGE ON SCHEMA reporting TO fixture_reader;
GRANT SELECT ON reporting.member_summary TO fixture_reader;
-- Review inherited roles, PUBLIC grants and callable functions separately.

Bound cost and disclosure together

Set an execution deadline, row limit, maximum serialized bytes and allowed concurrency. A LIMIT does not necessarily bound work before sorting or joining, and one row can hold a very large document. Inspect representative query plans under the same role and data distribution. If query cancellation occurs, return an explicit incomplete state and release the connection rather than allowing work to continue invisibly behind a timeout message.

Keep tenant predicates and column projection in reviewed database or application code. For a generic SQL surface, define the schemas and views that are reachable and test them with deliberately crossed fixture identifiers. Parameterize values in curated operations. Avoid returning raw query errors to the model when they reveal internal names or record contents; a stable category plus an operator correlation ID is usually more useful.

Evaluate denied requests without customer data

The acceptance suite should include a normal bounded report, an empty result, an over-budget query, an unauthorized schema and a write attempt. Verify returned data, database state and connection cleanup. Also test a synthetic row containing instructions: retrieved content must remain data and cannot widen the role or query budget. A model's confident explanation does not establish that the underlying database constraints held.

This article supplies a proposed SQL-and-tool review contract; no database-role experiment is executed here. Keep the deployment statement narrower than the design: source code for a curated roster query demonstrates an operation shape, not a complete database security assessment. Bring the actual role grants, inherited permissions, query inventory and one synthetic reporting task to a scoped review before exposing a flexible SQL surface.

Permission-aware RAG: keep private answers inside the right account

Evaluate the tool action, not just the answer.

Bring one tool workflow, supported hosts and a sanitized failure trace for a scoped AI integration review.

AptixLabs ai agent development