How do I give AI agents access to my database safely?
Updated · DBShifts
Short answer
Don't give the agent a connection string. Put a governed layer in between: a scoped, revocable token per agent, only the tables and columns it needs, PII masked on the server, limits on how much it can read, returned data scanned for prompt injection, and every request logged so you can see exactly what it accessed.
Key facts
- A connection string gives an AI agent every table its database user can see.
- The model is the untrusted party, so access rules must be enforced outside the prompt.
- Default-deny allowlists fail safe; blocklists fail open when a new table appears.
- Per-agent tokens let you revoke one agent without rotating anything else.
- Read limits need to work over time, not only per request, or slow reads add up to the whole table.
Why the connection string is the wrong default
It is the fastest way to a demo and the hardest thing to take back. Every agent that holds the password reads with the same rights, the log records the database user rather than the agent, and stopping one agent means rotating the password for every service that shares it.
Read-only is necessary, not sufficient
Read-only access stops an agent changing data. It does nothing about an agent reading every customer's personal data, paging out a table a few hundred rows at a time, or following instructions an attacker left in a support ticket. Those need masking, limits and content scanning on top.
Where writes fit
If an agent must change data, do not give it write access. Give it named, parameterised actions it can propose, and have a person approve each one before it runs, with a way to undo it afterwards.
Checklist
- 1
Create a read-only database user for the gateway, not for the agent
- 2
Allow only the tables and columns each agent needs
- 3
Mask PII on the server, and block filtering or grouping on masked columns
- 4
Issue one token per agent; make it expire and bind it to known IP addresses where you can
- 5
Set row caps, a per-minute rate limit and daily budgets
- 6
Scan returned rows for prompt injection before the model reads them
- 7
Log every request, review the log, and keep a way to stop one agent instantly
Common mistakes
Using an admin user 'just for the demo'
Demos become production. Start with the read-only user and the allowlist; it takes minutes and never has to be undone.
Letting the model write SQL
A generated query can join anything and scan everything. Structured tools — filter, aggregate, follow a real foreign key — bound what a request can do.
No way to stop one agent
If the only off switch is rotating the database password, people hesitate to use it. A per-agent pause gets used.
How DBShifts does it
- Register the database read-only; DBShifts introspects the schema and scans sampled values for PII on connect.
- Set the policy: table and column allowlists, masking, row caps, rate limits and daily or monthly budgets.
- Issue an agt_ token per agent for MCP or REST. Tokens can expire and can be bound to an IP allowlist.
- Writes exist only as named actions an agent proposes; a person approves them in the app or from Slack, and executed actions can be undone.
- Before tightening a policy, preview its effect on up to 50,000 recorded agent requests without saving anything.
Questions people also ask
Can the agent change or delete data?
Not through reads, which are read-only by construction. Changes happen only through named actions a person approves, and each executed action has an undo.
Which AI clients can connect?
Any MCP client — Claude Desktop, Cursor, Windsurf, Cline or your own agent — or anything that can call a REST endpoint.
Related questions
Give AI agents data access you can defend
Scoped tokens, PII masked on the server, every request audited. Free to start.
Start free18 answers in this series. See all.