Forem: Mads Hansen

Natural language SQL needs query budgets

Mads Hansen — Mon, 11 May 2026 03:00:21 +0000

Read-only access is necessary for AI database agents.

It is not enough.

A read-only agent can still:

scan too much data
run expensive queries
return more rows than needed
touch sensitive tables
answer from a scope the user did not intend

That is why production natural language SQL needs query budgets.

What is a query budget?

A query budget defines what an AI database workflow is allowed to spend or touch before a query runs.

It can include:

maximum rows returned
maximum runtime
approved tables or views
allowed columns
maximum date range
cost or warehouse limits
rate limits per user/workflow
approval requirements for exceptions

The point is not to make agents less useful.

The point is to make useful access predictable.

Natural language hides query shape

A user asks:

Which customers are at risk this quarter?

That may be a perfectly reasonable business question.

But the generated query might be much broader than the user expected.

So the system needs boundaries outside the model’s wording.

Budget by workflow:

support lookup: one customer, short date range, redacted fields
sales analysis: approved CRM views, aggregate output, row cap
finance reporting: approved revenue model, scheduled run, owner review
diagnostics: operational metrics, no customer PII, time-boxed queries

Full piece: AI database query budgets: the missing control for natural language SQL

Conexor helps teams connect databases and APIs to MCP-compatible AI clients.

Read-only access is the starting point.

Query budgets make the boundary visible, enforceable, and reviewable.

MCP Tool Search does not replace permission design

Mads Hansen — Mon, 11 May 2026 03:00:20 +0000

MCP Tool Search is a good answer to a very real problem: tool catalogs are getting too large to dump into every agent conversation.

Loading fewer tool definitions means less token waste, less confusion, and fewer irrelevant capabilities competing for the model’s attention.

But for database-connected agents, discovery is only half the problem.

The harder question is:

What is this tool allowed to do once the model finds it?

Discovery is not authorization

A searchable tool catalog can help an agent find the right capability.

It should not become a shortcut around the permission model.

For database MCP servers, I would rather expose narrow workflow tools:

get_monthly_revenue_summary
list_overdue_invoices
find_customers_with_usage_drop
get_support_escalation_context

Than broad tools like:

run_sql
query_table
execute_statement

Tool Search can make safe capabilities easier to find.

It can also make unsafe capabilities easier to reach if the catalog is poorly designed.

Metadata becomes production interface

With Tool Search, names, descriptions, tags, and schemas matter even more.

A useful tool definition should make clear:

what business question it answers
whether it is read-only or write-capable
which approved view or source it uses
what limits are enforced
when the model should not use it

That metadata is not decoration.

It shapes model behavior.

Full piece: MCP Tool Search for database agents: discovery is not permission design

Conexor is MCP infrastructure for connecting databases and APIs to AI clients like Claude, ChatGPT, Cursor, n8n, and Continue.

Discovery should make safe capabilities easier to find.

It should not make unsafe capabilities easier to reach.

Your AI database workflow needs evidence, not just answers

Mads Hansen — Sun, 10 May 2026 02:37:24 +0000

If an AI agent answers questions from live production data, the answer should not be the only artifact.

Teams also need evidence.

Who asked? What was the intent? Which tool ran? Which data source was touched? How much data came back? Were limits applied? Was approval required?

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

A chat transcript is not an audit trail

A final answer can be useful and still be impossible to review.

A better trail captures:

original user request
selected MCP tool
database connection or approved view
operation type
row count returned
limits, filters, and redaction rules
final answer delivered to the user

This lets teams review both the result and the path that produced it.

Log scope, not unnecessary raw data

Auditability should not become a second data exposure problem.

Often, the audit log should capture metadata:

view/table group
columns returned
row count
filters applied
redaction policy
normalized query shape

You need enough evidence to review access without copying sensitive production data everywhere.

Full piece: Audit-ready MCP database workflows: what evidence to capture

Conexor helps teams connect databases and APIs to MCP-compatible AI clients.

The important question is not only: “can the agent answer?”

It is: “can we explain how the agent answered?”

MCP tool schemas are contracts, not comments

Mads Hansen — Sun, 10 May 2026 02:37:23 +0000

An MCP tool schema is not just documentation.

It is part of the model’s operating environment.

The model reads the tool name, description, input schema, and output shape to decide:

whether to use the tool
what arguments to send
what the result means
whether the tool is safe for the user’s intent

That means schema drift can become behavior drift.

Why this matters for database tools

If a normal API changes, a typed client or test suite may fail.

If an MCP database tool changes, the agent might keep running but behave differently:

a parameter changes and the agent stops using the tool
a description becomes broader and the model overuses it
an output field disappears and the agent reasons from missing context
a tool name hides whether it is read-only or write-capable

For database-connected agents, the schema is part of the safety boundary.

Review the contract before runtime

Production teams should review MCP tool schema changes before agents see them:

removed tools
changed required fields
tightened constraints
changed descriptions on high-risk tools
new access to sensitive tables or fields
new write-capable operations

Not every change should be blocked.

But meaningful contract changes should be visible.

Full piece: MCP schema drift: why database agents need stable tool contracts

Conexor is MCP infrastructure for connecting databases and APIs to AI clients like Claude, ChatGPT, Cursor, n8n, and Continue.

Schema drift is inevitable.

Silent schema drift is optional.

Your AI database agent probably needs fewer rows, not more context

Mads Hansen — Sat, 09 May 2026 01:29:53 +0000

A lot of AI database safety discussions start and stop at read-only access.

Read-only is necessary.

It is not sufficient.

A read-only agent with broad table access can still return customer records, private notes, billing details, free-text fields, and operational data that was never needed for the question.

The agent did not mutate anything.

It still saw too much.

That is why data minimization matters for AI database workflows.

Most users want an answer, not a dump

A useful agent does not need unlimited rows.

It needs:

the right approved view
enough schema context
scoped permissions
row limits
redaction before data reaches the model
audit logs showing what was returned

The model should not receive every table just because the database role can technically read it.

Approved views beat raw tables

Approved views let teams encode:

safe columns
valid joins
source-of-truth metrics
default filters
fields that should never leave the database

That improves security and answer quality at the same time.

A model working against a clean semantic view is less likely to confuse implementation details with business meaning.

We wrote the full piece here: Data minimization for AI database agents: return less by default

Conexor helps teams expose databases and APIs as MCP tools for AI clients without turning “more context” into the default.

Returning less data is not friction.

It is what makes the workflow safe enough to repeat.

AI database agents need approval gates, not vibes

Mads Hansen — Sat, 09 May 2026 01:26:37 +0000

Read-only is the right default for AI database access.

Most teams do not need an agent to change production data. They need it to answer questions from live systems without waiting for a SQL handoff.

But eventually, useful workflows drift toward actions:

update a ticket
tag an account
refresh a derived table
draft a config change
trigger a downstream workflow

That is where “the prompt says ask first” stops being a real control.

The approval gate has to live in the tool layer.

Do not jump from read-only to full write access

The dangerous pattern is treating write access as one switch.

Read-only feels safe. Write access feels useful. So a team adds a broader credential, exposes a generic SQL tool, and relies on the model to be careful.

That is not production architecture.

Better intermediate states are:

draft-only tools
preview tools
approval-required tools
allowlisted stored procedures
rollback-aware workflows

The agent can help prepare the work without automatically crossing the final boundary.

Preview before execution

Every write-capable tool should be able to show:

the exact operation proposed
affected tables or APIs
estimated or exact affected row count
the permission being used
why the agent believes the action is appropriate
what approval is required

If the agent cannot clearly explain the change, it should not execute the change.

We wrote the full breakdown here: Approval gates for AI database writes: where automation should stop

Conexor is MCP infrastructure for connecting databases and APIs to AI clients like Claude, ChatGPT, Cursor, n8n, and Continue.

The goal is not to make agents powerful by default.

It is to make the boundary explicit:

read → draft → preview → approve → execute → audit.

Agent memory gets risky when the agent can query your database

Mads Hansen — Fri, 08 May 2026 01:42:11 +0000

Agent memory sounds harmless.

Remember my preferred report format. Remember which metrics I care about. Remember that we exclude test accounts from revenue.

Useful.

But once the same agent can query a database, memory stops being just convenience. It becomes part of the decision surface.

A recalled preference can influence which tool the agent chooses, what SQL it writes, what rows it returns, and what it treats as relevant.

That means memory needs governance.

Not all context is the same

For database workflows, I separate two kinds of context:

Curated schema context
- table meaning
- approved joins
- metric definitions
- source-of-truth notes
- safe default filters
User/session memory
- preferred formats
- recurring questions
- past feedback
- task-specific working notes

The first should be reviewable and durable.

The second should be scoped, redacted, and easy to forget.

Mixing them casually is where the risk starts.

What should not become memory

For database-connected agents, I would avoid storing:

raw query result rows
credentials or secrets
copied customer data
tenant-specific details in global memory
unverified business assumptions
temporary exceptions that should expire

Long-term memory should not become a cache of everything the agent has ever seen.

It should be a controlled source of useful context.

We wrote the full piece here: Agent memory for database workflows: useful context or hidden risk?

And yes, this is exactly where MCP architecture matters. Conexor helps expose databases and APIs as MCP tools for AI clients without turning memory into permission.

Memory makes agents more useful.

Boundaries make that usefulness repeatable.

Short-lived credentials are not optional for AI database agents

Mads Hansen — Fri, 08 May 2026 01:42:10 +0000

The risky part of AI database access is not the first query.

It is the credential that keeps working after the demo.

Static service keys are convenient. They are also exactly how a harmless prototype turns into standing access to live business data.

AI agents are different from normal backend services. They can choose tools dynamically, retry tasks, carry context across steps, and chain actions in ways the original developer may not have listed one by one.

That does not mean agents are unusable.

It means credential lifetime is part of the architecture.

The better default

For database-facing agents, I would rather see:

per-session credentials for interactive users
per-task credentials for automation
separate roles for read/reporting tools vs write/admin tools
short TTLs for higher-privilege access
no credentials stored in prompts, traces, or long-term memory

Short-lived access reduces exposure time.

But TTL is only half the story.

A short-lived admin credential is still an admin credential.

The other half is scope.

Pair TTL with tool boundaries

A production MCP database server should not hand every workflow one generic database credential and one generic execute_sql tool.

Better patterns are narrower:

approved reporting views
read-only roles by default
named tools for recurring business questions
query timeouts and row limits
approval gates for write-capable actions
audit logs for every meaningful tool call

The model should not decide the credential scope.

The infrastructure should.

We wrote the full breakdown here: Short-lived credentials for AI database agents: reduce the blast radius first

Conexor is built around this MCP layer: connecting databases and APIs to AI clients while keeping access specific, temporary, observable, and governable.

The practical question is not: can the agent connect?

It is: what can this specific user, workflow, and tool do right now?

SELECT-only is the floor for AI analytics, not the finish line

Mads Hansen — Thu, 07 May 2026 01:22:00 +0000

Read-only database access is the right default for AI analytics.

It is also not enough.

That sounds weird until you watch what happens in production.

A team gives an AI agent a role that can only run SELECT. Everyone relaxes because the agent cannot mutate data.

Then it runs an expensive query.

Or returns 50,000 rows when a summary would have been enough.

Or exposes sensitive columns.

Or answers from the wrong table because the schema looked obvious and wasn't.

No data was modified.

The workflow can still be unsafe.

What SELECT-only actually solves

It prevents writes.

That is important. It should usually be the first boundary.

But it does not decide:

which rows can be viewed
which columns are sensitive
which tables are authoritative
which queries are too expensive
which metric definitions are correct
which answers need an audit trail

Read-only protects data integrity.

It does not automatically protect confidentiality, performance, or answer quality.

Governed read-only is the real goal

For AI analytics, the safer pattern is narrower:

approved reporting views
schema context in business language
row limits and timeouts
aggregate-first tools
separate paths for write-capable operations
audit logs for every meaningful query

The model should not have to remember all of that from a prompt.

The access layer should enforce it.

We wrote more here: Read-only AI analytics: why SELECT-only is necessary but not enough

Conexor is built around this exact MCP layer: connecting live databases and APIs to AI clients without turning every prompt into a production risk review.

The practical question is not "can the AI only SELECT?"

It is:

SELECT what, for whom, through which tool, with which context, under which limits, and with what audit trail?

Your AI database connector is a control plane, not a shortcut

Mads Hansen — Thu, 07 May 2026 01:21:59 +0000

The first successful AI database query is not the milestone.

It's the trap.

Because the demo question is always harmless:

What was revenue last month?

Then the connector spreads. More people use it. More clients get wired in. More tables become reachable. Suddenly, the thing you treated as a convenience layer is sitting between natural language and production data.

That is not a shortcut anymore.

It is a control plane.

The five boundaries that matter

Before connecting Claude, ChatGPT, Cursor, or an internal agent to live data, teams should define five things clearly:

Identity — who is asking, through which client, and under which workspace?
Scope — which schemas, views, columns, and tools are in bounds?
Schema context — what does the data actually mean in business terms?
Execution limits — how much can be queried, returned, or attempted?
Auditability — what can be reviewed later when an answer matters?

If those boundaries are vague, the connector becomes a thin wrapper around credentials.

That might be fine locally.

It is not how production teams should expose business data to AI.

MCP helps, but it does not replace architecture

MCP gives AI clients a useful tool layer.

But an MCP database server still needs real product decisions: read-only defaults, approved views, result limits, tool descriptions, blocked operations, and logs.

The goal is not simply "let the model query the database."

The goal is: make the organization understand exactly what the model is allowed to do.

We wrote the full checklist here: AI database connector architecture: the five boundaries teams should define first

And if you're building this layer, Conexor connects databases and APIs to MCP-compatible clients like Claude, ChatGPT, Cursor, n8n, and Continue.

The connector is where the risk concentrates.

Treat it like infrastructure.

If an AI database question is asked twice, it probably should not live only as a prompt

Mads Hansen — Wed, 06 May 2026 00:38:28 +0000

The first impressive AI database moment is usually a one-off question.

What was MRR last month?

Which customers are at risk?

Where did usage drop this week?

That is useful.

But most reporting problems are not one-off.

They repeat.

The real bottleneck is recurring work

Teams do not only need one answer.

They need the same class of answer every Monday, after every release, before every board update, or whenever a metric crosses a threshold.

If a human has to remember the prompt, choose the right context, check the same tables, paste the same results, and verify the same assumptions every time, the AI helped.

But it did not remove the workflow.

The next step is a repeatable workflow

A repeatable AI reporting workflow defines:

which data sources are in scope
which MCP tools may be used
what the question means in business terms
how often it should run
who receives the result
what gets logged for review

This does not make the workflow less flexible.

It makes it dependable.

Example: weekly customer health

The one-off prompt is simple:

Show accounts where usage dropped more than 20% week over week.

The workflow is more useful:

query the approved usage summary view
join only approved account metadata
exclude test accounts
flag accounts with open high-priority tickets
summarize reasons for concern
send the result every Monday
store the query trail for audit/debugging

That is no longer just a clever answer.

It is operational reporting.

Conexor is working in this MCP infrastructure layer: helping teams expose databases and APIs as controlled tools for AI clients, so useful questions can become repeatable workflows instead of fragile prompt rituals.

Longer version: Repeatable AI reporting workflows: when one-off database questions are not enough

Practical rule:

If a database question is asked more than twice, it probably should not live only as a chat prompt.

Do not give AI agents cloud access when they only need database answers

Mads Hansen — Wed, 06 May 2026 00:37:22 +0000

Azure SQL often holds the answers teams ask for every week.

Customer usage. Billing events. Operational metrics. Support signals. Reporting data.

So the natural question is:

can Claude, ChatGPT, Cursor, or an internal AI agent query that data directly?

Yes.

But the safe version is not “give the agent Azure access.”

The safe version is an MCP layer that exposes narrow, auditable database tools.

The wrong abstraction is cloud access

When teams hear “connect AI to Azure,” they often start with subscriptions, resource groups, service principals, and broad operational APIs.

That may be useful for cloud operations.

It is the wrong default for business-data questions.

If the user asks, “which accounts expanded usage last month?”, the agent does not need wide Azure control.

It needs controlled access to approved Azure SQL views.

Cloud permissions answer what infrastructure can be touched.

Database tools answer what business questions can be asked.

Those are different boundaries.

What a safer Azure SQL MCP setup looks like

A production-facing MCP server should define boring, narrow tools:

query approved reporting views
inspect allowed schema context
summarize aggregate results
reject queries outside scope
log who asked, what ran, and what came back

Start read-only.

Use a dedicated database user.

Grant access only to approved schemas or views.

Describe fields in business language.

Enforce result limits.

Log the query trail.

If the workflow later needs actions, make those separate tools with separate approvals. Do not hide writes behind execute_sql.

Conexor focuses on this MCP infrastructure layer: exposing databases and APIs to AI clients through controlled tools, not broad credentials.

Longer version: Azure SQL MCP server: how to give AI agents useful access without broad cloud permissions

The practical rule:

Do not give an AI agent cloud access when it only needs business-data access.

Use MCP to expose the narrow tools the workflow actually needs.