SecurityJul 13, 2026 · 8 min read

AI database access review checklist: what to approve before agents query production data

AI database access should not be approved with a vibe check.

The demo is easy: connect a model to a database, ask a natural-language question, get an answer. The production decision is harder. Who is the model acting for? Which tables can it touch? What happens when it guesses the wrong join? Can you reconstruct what happened after the fact?

Before an agent or AI client queries production data, the access path needs a review. Not a six-month governance program. A practical checklist.

1. Identity: who is the request really from?

Do not review “the AI” as the actor. Review the human, service, team, or workflow behind the request.

Is every request tied to a user or service identity?
Can the MCP layer distinguish teams and roles?
Are shared tokens avoided?
Can access be revoked without redeploying the whole integration?

If the audit trail says only “agent,” it will not be useful when something goes wrong.

2. Permissions: is read-only the default?

For most AI database workflows, read-only should be the starting point. Write access is a separate product and security decision.

Approve read-only credentials first. Then verify that the database user cannot create tables, alter schema, run maintenance commands, or call unsafe functions. If an agent needs to prepare a change, it can produce a draft or recommendation. A human or separate approval workflow should decide whether anything changes in production.

3. Surface area: are tools scoped to the workflow?

The safest MCP database server is not the one with every possible tool exposed. It is the one where the approved path is smaller than the dangerous path.

Review the tool catalog:

Which tools are exposed?
Which schemas, tables, or views are reachable?
Are sensitive columns excluded or masked?
Does each role get only the tools it needs?

A finance workflow and a customer success workflow should not see the same database surface by default.

4. Data model: are approved views available?

Raw tables leak implementation details. They also invite incorrect joins.

For recurring questions, expose approved views that encode business logic: active customer definitions, revenue recognition rules, renewal windows, usage summaries, tenant boundaries, or support severity rollups.

This makes the AI layer less magical and more reliable. The model can still help users ask better questions, but it does not need to rediscover the business model every time.

5. Query controls: what stops an expensive mistake?

Natural language makes database access feel lightweight. The query underneath may not be lightweight at all.

Review these controls before launch:

maximum rows returned,
statement timeout,
query cost or complexity limits,
blocked operations,
pagination behavior,
rate limits per user, team, and workflow.

These are not just performance settings. They are safety boundaries.

6. Result handling: where does the answer go?

Database security does not end when the query returns.

Review whether results can include personal data, secrets, credentials, customer-specific records, financial details, or internal notes. Then decide how the MCP layer should redact, summarize, cap, or block those results.

If a user would not be allowed to export a field manually, an AI answer should not quietly expose it either.

7. Auditability: can you replay the decision path?

Good audit logs answer more than “which SQL ran?”

For production AI database access, capture:

user or service identity,
timestamp,
prompt or request summary,
selected MCP tool,
generated query,
database role used,
row count and execution time,
result metadata,
approval or denial reason when blocked.

This is what makes natural-language access operationally credible. Without it, every answer becomes hard to trust and harder to investigate.

8. Change management: who can expand the catalog?

The first version of the tool catalog will not be perfect. That is fine. What matters is how it changes.

Require review when adding new schemas, sensitive views, write-like tools, higher row limits, new roles, or new external destinations. Treat MCP tool expansion like permission expansion, because that is what it is.

A review checklist you can actually use

Every request maps to a real identity.
Default database credentials are read-only.
Tool catalogs are role-based.
Recurring questions use approved views.
Sensitive fields are excluded, masked, or blocked.
Row limits, timeouts, and rate limits are enforced.
Prompts, tools, queries, and result metadata are logged.
Catalog changes require review.
Write access is handled by a separate approval flow.

That is the difference between “we connected AI to prod” and “we approved an AI data access path.”