DEV Community: Mads Hansen

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.

MCP tool descriptions are part of your security model

Mads Hansen — Tue, 05 May 2026 01:20:41 +0000

Most API documentation is written for humans.

MCP tool descriptions are different.

They are read by the model that decides what to call next.

That means tool names, descriptions, schemas, and error messages are not just documentation garnish. They are part of the safety boundary.

A bad tool asks the model to guess

A risky MCP tool often looks like this:

name: query
input: free-form string
description: “Run SQL against the database”

Technically simple.

Operationally vague.

The model has to infer when to use it, what is safe, which tables matter, and what failure means.

That is not a production boundary. That is a shrug with JSON around it.

A better tool is boring on purpose

For database workflows, the tool should make the safe path obvious:

query_customer_usage_readonly
approved schemas or views
structured filters instead of arbitrary commands
explicit “do not use for exports or personal data lookup” guidance
clear result limits
audit logging
useful access-denied errors

The database permissions still need to enforce the boundary.

But the model-facing contract matters too.

If the description does not say when not to use the tool, the model will often try anyway.

Errors matter too

“Permission denied” is technically correct.

It is not very helpful for an agent.

A better error explains the safe next step:

This request tried to access a table outside the approved reporting scope. Ask an administrator to add the table to the approved view set, or reformulate the question using customer_usage_summary.

That keeps the agent inside the workflow instead of nudging it toward improvisation.

Conexor focuses on this MCP infrastructure layer: controlled tools for databases and APIs across Claude, ChatGPT, Cursor, n8n, Continue, and other MCP clients.

Longer post: MCP tool descriptions are a security boundary, not documentation garnish

Treat MCP descriptions like the model-facing part of your access policy.

Not comments in code.

Your PostgreSQL MCP demo has three possible futures

Mads Hansen — Tue, 05 May 2026 01:19:35 +0000

The first PostgreSQL MCP demo is usually quick.

The production decision is not.

Once an AI agent can query live Postgres data, the team has to answer harder questions:

who owns the schema context?
which tables are allowed?
where are queries logged?
how do credentials rotate?
what happens when one user becomes ten teams?

That is where the implementation path matters.

Path 1: build your own MCP server

Maximum control.

Also maximum ownership.

A useful Postgres MCP server is not just a query wrapper. It needs authentication, schema discovery, scoping, audit logs, rate limits, environment separation, and clear tool contracts.

If your workflow is deeply proprietary and you have a platform team ready to own it, custom can be right.

If not, it quietly becomes another internal platform.

Path 2: run open-source tooling

Great for learning, local workflows, and fast prototypes.

But production still needs the surrounding operating model:

read-only database users
approved views and schemas
query logging
schema descriptions
review paths for sensitive data

Open source gives you a starting point. It does not automatically give you governance.

Path 3: managed MCP infrastructure

This makes sense when Postgres access becomes shared infrastructure.

The same database may need to support Claude, ChatGPT, Cursor, n8n, and internal automations.

At that point, teams need a consistent place to manage connections, clients, scopes, schemas, and audit trails.

That is the layer Conexor focuses on: MCP infrastructure for AI-ready engineering teams connecting databases and APIs to AI clients.

Longer comparison: PostgreSQL MCP alternatives: build, open source, or managed infrastructure?

Pick the path based on who will own it six months from now.

The fastest demo is not always the fastest production rollout.

Connecting ChatGPT to your database is the easy part

Mads Hansen — Mon, 04 May 2026 01:20:41 +0000

The question sounds simple:

Can we connect ChatGPT to our database?

Usually, yes.

But that is not the question that decides whether the setup survives production.

The better question is:

Which access pattern do we want to live with three months from now?

Most teams compare three options.

1. SQL chatbot

Fast demo. Useful for exploration.

Also easy to over-trust.

If the model lacks schema context, joins the wrong table, or can see too much data, the answer can look confident while being wrong or overexposed.

2. Custom API

Very controlled.

Also slow when the questions keep changing.

Every new workflow can become another endpoint, response shape, deployment, and maintenance surface.

Great for stable product flows. Less great for exploratory business questions.

3. MCP database connector

This is the middle path for AI-native teams.

Instead of giving ChatGPT raw database access, engineering exposes a scoped tool layer:

approved schemas and tables
read-only roles where appropriate
business context for columns and joins
audit logs for prompts, tool calls, SQL, and answers
ownership over scope changes

That is the difference between “the model can query data” and “the company has a governed data access pattern for AI.”

Conexor focuses on that MCP infrastructure layer for ChatGPT, Claude, Cursor, n8n, Continue, and other MCP-compatible clients.

Full comparison here: ChatGPT database connector alternatives: MCP, SQL chatbots, and custom APIs compared

The demo asks: can it connect?

Production asks: can we control it?

REST APIs were built for apps. AI agents need tools.

Mads Hansen — Mon, 04 May 2026 01:19:36 +0000

REST APIs are excellent for applications.

They are not automatically excellent for AI agents.

That difference matters once an agent needs to answer questions from live data.

A normal app calls an endpoint because a developer already decided the flow: click this button, call this route, render that response.

An AI agent works differently. It receives intent, chooses a tool, calls it, reads the result, and may continue.

That loop needs more than an endpoint.

It needs a tool contract.

The production problem

If you give an agent a pile of REST endpoints, the model may technically be able to call them.

But can your team clearly answer:

which endpoint the agent should use for which workflow?
what data it can never touch?
which credentials it uses?
where tool calls and answers are logged?
who owns changes to scope and context?

If those answers live in scattered docs, prompts, and tribal knowledge, the system is fragile.

Why MCP fits this layer

MCP gives AI clients a structured way to use tools.

A good MCP tool has a name, description, parameters, permissions, schema context, and auditability. That makes it much easier to govern than “here are 19 endpoints, good luck.”

For database access, that is the whole point.

The goal is not to let an agent do anything.

The goal is to give it the smallest useful tool for a real workflow.

Conexor is built for that infrastructure layer: exposing databases and APIs to Claude, ChatGPT, Cursor, n8n, Continue, and other MCP-compatible clients through controlled tools.

Longer comparison here: MCP vs REST API for AI agents: why tools beat endpoints for live data

The app needs an endpoint.

The agent needs a governed tool.

An MCP server for PostgreSQL is not just another SQL shortcut

Mads Hansen — Sun, 03 May 2026 01:21:28 +0000

Most teams do not need another way to paste SQL into a chat box.

They need a safer way for AI tools to answer real questions from live data.

PostgreSQL often already holds the context: accounts, subscriptions, events, product usage, operational state.

The problem is not that the data is missing.

The problem is that every useful question still becomes a handoff.

What MCP changes

Without a governed access layer, the workflow usually looks like this:

Someone asks a data question.
Someone else writes SQL.
Someone checks whether the query is safe.
Someone pastes the answer back.
The same question returns next week with different wording.

An MCP server for PostgreSQL changes the pattern.

The AI client can use a defined database tool through a standard interface. Engineering can decide what the tool sees, which role it uses, what schema context it gets, and how queries are logged.

That is very different from giving an agent a master key and hoping prompts behave.

The first rollout should be boring

A good first PostgreSQL MCP rollout is narrow:

one workflow
one read-only role
one scoped set of tables
clear schema descriptions
one audit trail

For example: let customer success ask which accounts had usage drops in the last 14 days.

That is useful, specific, and small enough to secure properly.

Conexor exists for that infrastructure layer: turning databases and APIs into controlled MCP tools for Claude, ChatGPT, Cursor, n8n, Continue, and other MCP-compatible clients.

Longer version here: MCP server for PostgreSQL: how AI agents can query live data safely

The shortcut is SQL generation.

The scalable pattern is governed access.

Secure AI database access starts before the connection string

Mads Hansen — Sun, 03 May 2026 01:20:22 +0000

The easy part is connecting an AI tool to a database.

The hard part is explaining, six weeks later, which tables it can see, what credentials it uses, where the queries are logged, and who owns the access model.

That is where most AI database demos quietly become production risks.

The mistake

Teams ask:

Can we connect AI to the database?

That question is too broad.

A better question is:

Which team needs which answers from which tables, and what should the AI never be able to do?

A customer success usage-drop workflow, a finance revenue workflow, and an engineering incident workflow should not all have the same database scope.

The checklist I would want before rollout

Before connecting production data to Claude, ChatGPT, Cursor, n8n, or another AI client, decide:

the allowed database, schema, and tables
whether the role is read-only
which sensitive columns are excluded
what schema context the model gets
where prompts, SQL, tool calls, and answers are logged
who owns permission changes

Read-only is a good baseline.

But read-only access to every table is still too broad for many workflows.

Why MCP matters here

MCP does not magically make database access safe.

What it does give teams is a structured place to define tools, permissions, context, and auditability instead of scattering one-off scripts and credentials across every experiment.

That is the layer Conexor is built for: helping teams expose databases and APIs to AI clients through governed MCP infrastructure.

I wrote the longer checklist here: Secure AI database access: the checklist before you connect production data

The demo gets attention.

The access model decides whether it survives production.