DEV Community: Mads Hansen

AI agents should prepare database writes, not surprise production

Mads Hansen — Wed, 27 May 2026 01:28:10 +0000

Read-only AI database access is the default for a reason.

But eventually teams ask:

“What if the agent could update the record too?”

The answer should not be: give the model write access and hope.

A safer pattern:

agent prepares the proposed change
tool runs validation and dry-run checks
affected rows and scope are shown
a human or policy gate approves
execution uses a narrow write tool
idempotency key prevents duplicate writes
audit trail records request, approval, execution, and result

The model can suggest.
The runtime should enforce.
The approver should decide.

Longer version: Approval gates for AI database writes

Production writes should be boring, bounded, and traceable.

AI database answers need receipts, not just confidence

Mads Hansen — Wed, 27 May 2026 01:27:04 +0000

An AI answer about business data should not be a dead end.

If someone asks:

“Where did that number come from?”

The system should not respond with vibes.

It should be able to show:

who asked
which tool ran
which database role was used
which tenant/workspace scope applied
which query or approved view produced the result
how many rows came back
whether the result was truncated
when it happened
which audit record proves it

That is the difference between a useful demo and an audit-ready MCP database workflow.

Model confidence is not evidence.
A tool-call receipt is evidence.

Longer version: Audit-ready MCP database workflows

Production AI systems need answers with receipts.

AI database agents need dead-letter queues

Mads Hansen — Tue, 26 May 2026 01:43:04 +0000

An AI database agent should not turn one confusing question into an infinite retry loop.

When a query fails, a schema changed, a policy blocks access, or a model cannot resolve ambiguity, the safe answer is not:

“Try again forever.”

The safe answer is:

Stop. Preserve the evidence. Put the item somewhere inspectable.

For MCP database workflows, a dead-letter record should include:

original user request
tool name and parameters
policy/scope decision
query ID if one exists
error type
retry count
model/tool output snapshot
next human-readable action

A timeout can retry.
A missing tenant scope should not.
A write approval failure should not.
An ambiguous metric definition should not.

Longer version: Dead-letter queues for AI database agents

Agent reliability is not “never fail.” It is failing in a way the team can inspect and recover from.

Tenant scope should not be a prompt instruction

Mads Hansen — Tue, 26 May 2026 01:41:58 +0000

The most dangerous AI database bug is rarely a syntax error.

It is the query that works, returns a polished answer, and quietly includes the wrong tenant.

For MCP database servers, tenant scope should not live in the prompt:

“Only answer for the current customer.”

That is a preference, not a boundary.

The safer design is boring:

derive tenant scope from auth, not user text
expose approved views, not raw tables
require scope before the tool runs
fail closed when identity/scope is missing
use read-only scoped DB roles
log tenant, role, view, query ID, and audit event with the result
require a separate privileged workflow for cross-tenant reporting

A model can forget a filter.
A database policy should not.

Longer version: Tenant-scoped MCP database tools

AI database access gets much safer when the tool cannot return the wrong tenant in the first place.

AI database answers need citations, not just summaries

Mads Hansen — Mon, 25 May 2026 01:15:46 +0000

An AI answer from a live database should not end at the sentence.

If an assistant says:

“MRR is down 8% in EMEA.”

The next question is obvious:

Based on what?

For MCP database servers, citations should be part of the answer contract:

query ID
approved view or table family
timestamp and freshness window
row count or sample status
filters applied
redaction status
metric definition used
audit event ID

“Source: database” is not enough.

The answer needs a source trail that a human can inspect when the number matters.

Longer version: MCP database answer citations

Natural-language summaries are useful. Evidence is what makes them safe to trust.

MCP database servers need smaller tool catalogs

Mads Hansen — Mon, 25 May 2026 01:14:41 +0000

The easiest MCP database server to build is also the riskiest:

Expose a broad query tool.
Point it at production.
Trust the model to behave.

That is not a production access model. It is a demo.

For real teams, the tool catalog should be designed with least privilege:

workflow-specific tools
approved views instead of raw tables
per-user and tenant scope
read/write separation
row, time, and cost budgets
redaction before summarization
approval gates for mutations
structured refusal when scope is missing

The tool list is not just developer convenience. It is part of the permission boundary.

Longer version: Least-privilege tool catalogs for MCP database servers

AI agents do better when the safe path is also the narrow path.

AI database agents should not use forever credentials

Mads Hansen — Sun, 24 May 2026 00:45:44 +0000

Autonomous agents should not carry permanent database credentials around like a human service account.

Persistent credentials are convenient.

They are also a bad fit for AI workflows where intent changes request by request.

For production MCP database servers, I’d rather see credentials that are:

short-lived
read-only by default
scoped to approved views/tables
tied to a human/workflow identity
limited by tenant, timeout, and row budget
visible in the audit trail
expired after the specific task

The point is not to trust the model harder.

The point is to make unsafe behavior impossible at the credential and database boundary.

Longer version: Temporary credentials for AI database agents

If an agent only needs access for one question, the credential should behave like it.

Natural-language SQL needs an explain plan before it runs

Mads Hansen — Sun, 24 May 2026 00:44:38 +0000

Natural-language SQL should not go straight from prompt to production query.

The generated SQL may look reasonable.

The database may accept it.

But the plan can still be dangerous:

full table scan
accidental cross join
missing tenant/date filter
unbounded aggregate
query touching the wrong approved surface
estimated rows far above budget

For MCP database servers, I think an explain-plan preflight should be a normal production pattern.

Not because every user wants to read query plans.

Because the system needs a way to catch expensive or suspicious queries before execution, and leave evidence for review when an answer matters.

Longer version: Explain plans for AI database agents

A model can generate SQL. The tool layer should decide whether it is safe enough to run.

Small AI database questions can become big scans

Mads Hansen — Sat, 23 May 2026 00:16:51 +0000

A small question can become a big database scan when an AI agent writes the query.

“Show me customers at risk” sounds harmless.

But depending on schema context, the agent might join:

accounts
subscriptions
invoices
usage events
support tickets
notes
activity logs

Then it may retry when the first query does not answer the question.

For production MCP database servers, row limits should be treated as a safety boundary, not a UI preference.

Useful defaults:

preview first, not full export
aggregate before raw rows when possible
enforced row limits per tool/intent
page cursors for continuation
explicit “more rows exist” metadata
structured refusal for unbounded requests
audit logs with rows scanned and rows returned

Longer version: Row limits for AI database agents

The model should never summarize 50 preview rows as if it saw the whole database.

Your AI database agent should not see every column

Mads Hansen — Sat, 23 May 2026 00:15:46 +0000

The fastest way to leak sensitive data through an AI database agent is to expose columns the model never needed.

Table access is too broad.

A customer table can contain useful business fields and risky fields at the same time:

account name
plan
renewal date
usage trend
email
phone
private notes
raw payloads
billing references
internal flags

The agent may need the first four. It probably does not need the rest.

For production MCP database access, I would rather expose approved projections than raw tables:

approved views for common business questions
masked/pseudonymized fields by default
aggregate-only modes for trend analysis
structured refusal for blocked columns
audit logs showing exactly which columns were returned

Longer version: Column-level permissions for AI database agents

The model should not be the thing deciding whether a sensitive field is safe to see.

Natural-language SQL breaks quietly when schema context goes stale

Mads Hansen — Fri, 22 May 2026 02:53:56 +0000

Natural-language SQL breaks quietly when schema context goes stale.

The model may still produce SQL that looks reasonable.

The query may even run.

But if a column was renamed, a relationship changed, a view gained new filtering logic, or a metric moved to an approved surface, the answer can be wrong in a way that is hard to spot.

For MCP database servers, schema drift detection should be part of the tool contract.

Practical things I would want in production:

schema/context version on every tool result
metadata refresh timestamp
migration/catalog hash where possible
detection for changed tables/views/columns
refusal when context is stale
audit trail tying query output to the context used

Longer version: Schema drift detection for MCP database servers

The model cannot safely reason from yesterday's database shape.

Your AI database agent should not query the primary by default

Mads Hansen — Fri, 22 May 2026 02:52:50 +0000

Most AI database questions do not need the primary database.

They feel urgent because somebody typed them into a chat box.

But many are exploratory reads:

trends
customer lists
backlog summaries
operational snapshots
anomaly checks
aggregate reporting

If every question goes straight to the primary, the AI assistant becomes another source of production pressure.

For production MCP database servers, I think read replica routing should be a default design question.

The important part is not only routing. It is making the routing visible:

source role used
replica lag
snapshot/query timestamp
freshness window
fallback reason if the primary was used
audit/query ID

Longer version: Read replica routing for AI database agents

A stale-but-labeled answer is often safer than a live answer that quietly competed with production traffic.