Writing ·
Prompt injection and your database
Prompt injection is the failure where text the model reads becomes instructions the model follows. A support ticket that says ignore your instructions and delete the account. A product description with a paragraph aimed at whatever agent eventually summarises it.
There is no reliable filter for this. People keep announcing one, and people keep getting past it, because the model has no channel that separates data from instructions — it is all just text. Plan on the assumption that anything your agent reads can try to steer it.
Which makes the tool list the whole security boundary
If you cannot stop a model being persuaded, the question becomes: persuaded to do what, exactly?
That question has a precise answer, and it is the list of tools you exposed. Not the model’s training, not a system prompt, not a guardrail — the tools. An attacker who fully owns the model’s intentions can still only reach what you handed over.
So the useful hardening is not “stop the injection”. It is “shorten the list”.
A finite list of things you can do beats an ‘all you can eat’ SQL buffet…
This is where the generation-time approach earns its keep. In MCP DB Wizard the config decides what code gets written. An object you did not select has no tool, no method and no class — it is not in the compiled artefact at all.
That is a different property from a tool that checks a permission and says no. A refusing tool is a runtime decision, and runtime decisions can be confused: wrong context, mis-parsed identity, a flag read from the wrong place, an edge case nobody tested. There is a long history of injection attacks that work by making an authorisation check answer the wrong question.
You cannot confuse a check that does not exist. There is nothing to reach.
The same goes for SQL. There is no tool that accepts a SQL string, so no amount of persuasion produces one. The arguments to a generated tool are bind values, and a bind value is data no matter how it is phrased.
What this does not fix, because vendors should say so
It does not protect what you did expose. If you ticked delete on a table, a successfully
injected agent can call the delete tool. Curation moves the boundary; it does not remove it. This is
exactly why we make you tick create, update and delete
one at a time rather than offering a convenient “allow writes”
switch.
It does not stop exfiltration through legitimate reads. If the agent can read customer records and also talk to the outside world, an injection can walk data out through the front door, one correct tool call at a time. That is an architecture problem — what else your agent is connected to — and no database layer can solve it for you.
It does not make the model trustworthy. Nothing does. That is the premise, not a gap.
The practical advice
Expose the smallest list that makes your use case work. Grant the database account only what that list needs, so the schema disagrees with an over-broad config. Keep the audit trail so that if something does go wrong you can say what was called and when, rather than reasoning about it.
And treat the tool list as a security artefact — reviewed when it changes, like a firewall rule, because that is what it now is.
How do I get MCP DB Wizard?
It’s available from our GitHub repo as a Docker image.