A lot of what I keep reading online about shipping LLM agents to production skips over the database layer, and I think that is going to be the awkward part of the whole wave. Not because anyone is doing anything stupid. Because the assumptions baked into how we secure databases were written for a caller that does not really exist anymore.
A traditional service hits the database with a small, predictable set of queries. You can review them, unit test them, put them behind stored procedures and call it a day. Even a messy web app has at most a few hundred query shapes total, and most of them rhyme.
An LLM agent does not work like that. It generates queries. The shape distribution is wide and you cannot enumerate it ahead of time. "Show me revenue by region" can come out as fifteen different valid SQL statements depending on the model, the temperature, and whether it decided a CTE would be cleaner today.
This breaks a few things at once.
Least privilege is the first one. The usual playbook is to give the service a role with exactly the permissions it needs. With an agent, "exactly the permissions it needs" is a moving target, because the set of legitimate questions is not known in advance. So in practice the agent gets a role closer to "read most things" and the system prompt is asked to hold the line.
The prompt does not really hold. Tell the agent not to query table X and it will respect that, until someone asks a tangential question and the agent reaches the same data through a join from a table that was not on the deny list. Not adversarial. Just goal-directed.
Logging gets weird too. Most audit setups assume queries arrive at human or app-service rates, in shapes a person can scan. An agent can run two hundred queries in a session, all individually unremarkable, and produce a pattern that no single line would flag.
The thing I keep coming back to is that read-only is a permissions concept. It is not a behavior concept. The caller on the other end is creative, patient, does not get tired, and most of the tooling around databases assumes it is none of those things.
If you are running agents against a real database right now, I would like to hear how you are thinking about it. Keeping notes.
Top comments (0)