How should AI agents get access to Postgres?

A short Hacker News thread asks a question that becomes urgent as soon as an AI agent can touch real data: How are you giving AI agents access to Postgres? The visible discussion reduces the design choice to two paths — let a language model generate SQL, or expose defined operations with deterministic guards — and immediately points at the manual work required either way.

That is the right framing. Database access is not a tool checkbox. It is a permission system, an execution boundary, and an audit problem wrapped around a probabilistic planner.

Definition: Safe agent database access means giving an agent only the named data operations it needs, while the database and a server-side policy layer enforce permissions independently.

Example: Instead of handing an agent DATABASE_URL, expose list_overdue_invoices(account_id, limit) with a fixed parameterized query and a read-only role.

Key takeaway: Give an agent capabilities, not a terminal.

Business impact: Narrow access limits blast radius, makes actions reviewable, and turns a surprising model decision into a bounded operational event instead of an incident investigation.

Why raw SQL feels attractive — and why it scales badly

The raw-SQL approach is easy to demo. The agent receives a question, inspects a schema, writes a SELECT, runs it, and summarizes the rows. For exploratory analytics against a disposable copy, that may be a reasonable experiment.

Production systems add complications that a prompt cannot safely solve:

• the query may read tables or columns the agent did not need;
• an unbounded join may consume database resources or flood the model context;
• generated SQL is nondeterministic, so the same request can produce different access patterns;
• an injected instruction hidden in a database row can influence the next query;
• a write-capable connection can turn a mistaken plan into an irreversible action;
• the connection string or returned data may cross a model boundary you did not intend.

The problem is not that a model can never write valid SQL. The problem is that “valid SQL” is not the same as “authorized operation.” PostgreSQL permissions answer what a role may do. They do not, by themselves, know whether a particular query is appropriate for the user’s request, whether the result is too broad, or whether a later tool call is part of a prompt-injection chain.

The safer interface: tools with contracts

A tool is a named operation with an input schema, a server-side implementation, and a bounded output. The agent chooses the operation and supplies parameters; application code owns the SQL and the connection.

For example, an invoice lookup could be implemented as a server-side function whose query is fixed, whose values are bound parameters, and whose result count is capped:

list_overdue_invoices(min_days_overdue, limit)

The model never needs to see the connection string or improvise a table join. It receives rows shaped for the task. If the product later changes the schema, the tool contract can remain stable while its implementation is reviewed like any other application code.

This is also where MCP can fit: it can describe tools and their inputs to an agent host, but the protocol does not make an unsafe database operation safe by itself. The server behind the tool still needs authentication, authorization, validation, rate limits, and logging. Treat MCP as an interface layer, not as a substitute for database security.

Four layers that should not be delegated to the model

1. Database permissions

Create a dedicated role for the agent or its tool runtime. Do not reuse an application admin account, a developer credential, or a broad shared service user. PostgreSQL’s role and privilege model is the enforcement layer that still applies when a prompt, model output, or tool implementation behaves unexpectedly (PostgreSQL role management).

Grant only the schemas, tables, and operations required by the tools. A tool that lists product availability does not need access to customer identity data. A support agent that reads one tenant’s records should not rely on the model to remember a tenant filter.

2. Data scope inside the database

If access depends on tenant, user, or row sensitivity, enforce that boundary with the database. PostgreSQL row-level security lets policies determine which rows a role may see or modify (PostgreSQL row security). This is stronger than placing “always add WHERE tenant_id = ...” in a system prompt.

The same principle applies to columns and result shape. Return the minimum fields a tool needs. Mask or omit personal data by default. A successful query that returns an entire customer table is still a security failure if the task required one order status.

3. Runtime limits

Every tool should carry operational limits: a maximum row count, a statement timeout, a restricted date range, and a bounded number of calls per run. PostgreSQL supports statement_timeout to stop statements that exceed a configured duration (PostgreSQL runtime configuration). A timeout does not make a query correct, but it stops one confused plan from becoming an availability incident.

For read-heavy analytical agents, a replica or isolated reporting database can add another layer of protection. It is not a permission replacement: a replica can still contain sensitive data, and a bad query can still be expensive. It does reduce contention with the primary write path.

4. Policy and approval outside the model

A model can propose an operation. A policy layer should decide whether the operation is allowed, denied, or paused for review. High-risk categories usually include bulk updates, deletes, schema changes, permission changes, and operations touching financial or personal data.

This is the practical meaning of deterministic guards. They are not a collection of prompts asking the model to behave. They are ordinary code and database policy that inspect the requested action regardless of the model’s explanation.

For prompt injection, this separation matters. OWASP’s guidance treats prompt injection as a core risk for LLM applications because untrusted content can influence an agent’s behavior (OWASP prompt injection). A database guard outside the model context can reject a destructive operation even when a malicious row, document, or user message convinces the agent to request it.

Read access and write access are different products

A read-only agent can still create serious problems: it can disclose sensitive rows, generate costly scans, or return a misleading answer because it queried the wrong slice of data. But writes add irreversibility and should not be treated as the same permission with a different SQL verb.

A useful production split looks like this:

• Read tools: automatically callable, narrow result schemas, read-only role, row limits, timeouts, and full logging.
• Reversible writes: explicit operation names, idempotency keys, validation, and an undo or compensating action where possible.
• Irreversible writes: dry-run preview, exact affected-record count, human approval, and a second authorization check at execution time.
• DDL and permissions: separate administrative workflow, never an incidental side effect of a conversational request.

A tool called cancel_subscription(subscription_id) is meaningfully safer than execute_sql(sql), even if both eventually issue a database mutation. The named tool can validate ownership, check current state, enforce idempotency, and emit a business event. The raw SQL interface delegates all of those decisions to the model and whatever prompt happens to be active.

Observability is part of authorization

Log every tool call as an operational event: agent identity, user identity, tool name, validated parameters, target resource, policy decision, rows returned or affected, duration, and approval identity where applicable. Keep secrets and unnecessary personal data out of the log, but do not make the audit trail so vague that it cannot answer what happened.

The log should support both real-time controls and post-incident reconstruction. A rate limit can stop an agent that loops. A statement timeout can stop a runaway query. A durable audit record can show whether the agent requested a read, which policy allowed it, and what data came back. Background: The Semantic Layer is the Ultimate Battlefield in the Era of Agentic AI.

Do not rely on the model’s own summary as the audit record. The model may omit a tool call, misunderstand its result, or be influenced by the same untrusted content that caused the action. Record at the tool and database boundary.

A practical rollout path

Teams do not need to solve every possible database action before running a useful agent. A safer sequence is:

1. Start with one read-only workflow and one dedicated role.
2. Expose a small set of typed tools instead of a general SQL terminal.
3. Add result limits, timeouts, tenant filters, and structured output.
4. Log every call and review real traces before expanding access.
5. Add narrow, reversible writes with idempotency and a dry-run mode.
6. Gate bulk changes, DDL, permissions, and sensitive data behind approval.
7. Test the policy layer with prompt-injection attempts and adversarial parameters.

That sequence turns access into an incremental engineering surface. Each new capability has a name, an owner, a test, a permission boundary, and an observable result.

The decision to make before connecting Postgres

The question is not whether an AI agent can write SQL. It can. The question is whether your organization wants a probabilistic system to choose arbitrary database authority at runtime.

For a prototype, raw SQL against synthetic or read-only data may be a useful learning tool. For production, the safer default is typed operations behind server-side credentials, least-privilege roles, database-enforced row scope, runtime limits, external policy checks, and an audit trail.

An AI agent is a goal-driven system that uses tools and checks results. Database access is therefore one of the places where the tool contract matters more than the model’s conversational fluency. Give the agent a menu of bounded capabilities, not a terminal and a hope that the prompt remains polite.