Letting an AI agent write to your database, safely

Reads are the easy half. An agent that fetches the wrong record wastes a call. An agent that writes the wrong record has changed something somebody now has to find and undo, and the finding is usually the expensive part.

What follows is the write path as it actually has to be built, including the two failures that are easy to design past and expensive to hit.

1. Writes go through your API, not your database

Your API already validates input, enforces authorisation, fires the side effects and keeps the audit trail. A tool that writes SQL directly bypasses every one of those, which means you now maintain two definitions of what a valid write is. They agree on the day you write them and not much longer.

Route through the endpoint your own front end calls. The agent becomes another client of rules you already trust.

2. Classify, and treat destructive as its own class

Read, write, destructive. Three classes, not two. Creating a project and deleting a customer are different kinds of event and deserve different friction, different wording, and in most products different default states: destructive tools should not be in the list at all until somebody has asked for one twice.

The classification also gives you something to put in the log later, which is what makes “what has this thing been doing” answerable in one query.

3. The confirmation must show real arguments

A gate that says “Confirm this action?” teaches people to click through it. A gate that says Cancel order 1041 makes them read. The difference is not politeness, it is whether the confirmation does any work at all: the entire value of the step is that a human looked at the specific thing about to happen.

This means the card has to be rendered by your interface from the pending call, with the arguments the call will actually run with. Not a summary. Not the model’s paraphrase. The values.

4. Verify the write. Do not take the model’s word for it

This is the failure worth designing the whole system around, and it is not exotic. The call fails, is denied, or times out, and the model reports the turn as complete because a helpful summary is what it was trained to produce. Nothing errored. Nobody was attacked. The user simply believes something happened that did not.

So keep two separate facts: what the API returned, and what the model said. Log the first. Show the user the first. A system that cannot tell “verified” from “claimed” is a system whose logs cannot answer the only question anybody will ever ask them.

5. Make retries safe

Agents retry. Users press the button twice. Connections drop between the write landing and the response arriving, which is the case that produces duplicates while looking exactly like a failure. An idempotency key on write endpoints turns that ambiguous case into a safe one, and it is much cheaper to add before you need it.

The failure this all exists to prevent

Not a breach. A quiet, confident report that something is done when it is not. Breaches are rare and loud; false completions are common and silent, and they are what make people stop trusting an assistant after using it twice.

Every rule above is downstream of that: route through the API so failures are real failures, confirm with real values so somebody saw it, verify from the response so the record is true, and make retries safe so the ambiguous case has an answer.