# What BasaltDB won't catch

The honest list of mistakes BasaltDB does not stop, and what you can do about each one.

BasaltDB sees what happens in your database. It records every change an agent makes there, refuses what it should never do, and lets you undo a run. Some mistakes happen elsewhere, or look fine to a database. This page lists six, with what to do about each.

For the numbers and defaults, see [Limits and defaults](/reference/limits/).

## 1. A change that is allowed but wrong

An update of one row to the wrong value is valid SQL, inside the limits, and nothing in the database says it is wrong. It goes through and is saved with the reason the agent gave. You can undo it. Nothing stops it first.

What helps:

- Read the reason on each run with `basalt log`. See [See what it did](/guides/see-what-it-did/).
- Keep an agent's role to the tables its job needs.
- Larger changes are held for you, and more than 50 rows never run. A small wrong change is not held.

## 2. Emails sent or payments made because of bad data

BasaltDB restores rows. It cannot unsend an email or refund a payment your app made after reading a row the agent had changed. The same goes for a webhook, a sync or a report that ran on the bad data.

If your app has triggers that act on a changed row, such as sending a message, an undo can fire them too, when it puts the old values back. Check those before you undo a run that touched such a table.

What helps: undo soon, and look at what ran after the agent's change.

## 3. Data your agent already read and passed on

An agent that read a row can repeat it anywhere it can write or send text: a chat, a file, a web request. A prompt injection can make it do that. BasaltDB limits the damage and leaves a trail. It does not solve prompt injection, and nothing un-leaks data.

What it does do:

- Reads are recorded, so `basalt log` shows what the agent looked at.
- A read returns at most 1,000 rows by default and has a time limit.
- The agent sees only the tables its role allows.

## 4. Undo after 30 days

BasaltDB keeps the old values of a change for 30 days. After that a row cannot be restored. An undo skips it and lists it as `VALUES_PRUNED`. The rest of the record, such as who did what and why, stays for 1 year.

What helps: undo a bad run within the window. If you find a problem later, the record still tells you which rows an agent changed and what the reason was.

## 5. An agent that holds your own admin password

The guard is a boundary for the agent's role. It is not a boundary against the person who owns the database. An agent that has your admin connection string, your own credential or `sudo` on the engine's machine can drop the guard, change its rules or approve its own changes.

If an agent running as the same OS user as the engine can reach the engine's credential, writes are still guarded, but reads over a direct connection are not recorded.

What helps:

- Type the admin connection string only at the `basalt init` prompt, on your own computer. Never paste it into a chat or a file the agent can read.
- Run the engine as its own OS user.
- If the admin password was ever shown to an agent or put in a chat, reset it with your host.

## 6. Time-critical or mission-critical systems

BasaltDB is not built for them. It adds a check to every agent write, and an undo is a new set of changes, not a switch that makes the past not have happened. If a wrong write would cost more than you can fix by undoing it, do not give an agent write access.

It is built for internal tools, back-office data and small-business bots.

## Next

- [Limits and defaults](/reference/limits/): the numbers.
- [Undo a run](/guides/undo/): how to use the 30 days.