AI Agent Guardrails: Stop It Wiping Your Database

If you are letting an AI agent touch your hosting, the single most important thing you can do is give it a scoped account that cannot drop tables, delete files or wipe backups. Create a limited database user, hand the agent read-only access by default, and put your backups somewhere the agent has no credentials for. Do that and the worst-case run becomes an annoyance, not a funeral.

This is not hypothetical. There are now documented cases of coding agents running a destructive command against a live database during what the operator thought was a safe session. The agent did exactly what an over-privileged account allowed it to do. The lesson is old and boring: least privilege. The twist is that an AI agent acts fast, acts confidently, and will happily chain ten steps before you can read the first one.

So let's skip the theory and go setting by setting. Here is what to turn on today, in the order that matters.

Give the agent its own account, never your admin login

The first rule: an AI agent gets a dedicated, named account with the least access that still lets it do the job — never your own credentials and never a root or administrator role.

When you reuse your own login, you lose the one thing that saves you later: the ability to tell what the agent did versus what you did. A separate account gives you a clean audit trail and a kill switch you can pull without locking yourself out. Name it something obvious like ai-agent-readonly so it stands out in your logs.

For WordPress, this means creating a new user and resisting the urge to make it an Administrator. Most agent tasks — auditing content, suggesting fixes, drafting posts — need Editor or less. If the agent genuinely needs to install a plugin, do that step yourself and hand the result back. A plugin like Members or User Role Editor lets you build a custom role that can read everything but cannot touch users, plugins or settings.

Scope database access to read-only by default

Default to a read-only database user and only grant write or delete permissions for the specific tables a task actually needs, for the length of that task.

In MySQL or MariaDB this is a two-minute job. Create a user that can look but not break:

CREATE USER 'ai_ro'@'%' IDENTIFIED BY 'a-long-random-password';
GRANT SELECT ON yourdb.* TO 'ai_ro'@'%';
FLUSH PRIVILEGES;

Notice what is missing: no DROP, no DELETE, no TRUNCATE, no ALTER. That single GRANT SELECT is the difference between an agent that reads your orders table and one that empties it. When a task truly needs to write, grant only what it needs and nothing wildcard:

GRANT SELECT, INSERT, UPDATE ON yourdb.wp_posts TO 'ai_rw'@'%';

Grant per table, not yourdb.*. And never hand an agent account the GRANT OPTION or any admin privilege — an agent that can rewrite its own permissions has no guardrails at all.

Turn on dry-run mode and demand a plan first

Make the agent show you what it intends to do before it does it — dry-run output, a diff, or a written plan you approve — so nothing destructive runs unseen.

Most serious agent tools support this; use it. In Claude Code or Cursor, turn off auto-accept for anything that writes or deletes, so every file change and shell command waits for your yes. For database work, ask the agent to produce the exact SQL it would run and paste it back to you first — then you run it, or you approve it. The ten seconds this costs is the cheapest insurance you will ever buy.

A practical habit: before any bulk operation, make the agent answer three questions in plain English. What will this change? How many rows or files? How do I undo it? If it cannot answer the third one, you are not ready to run it.

• File operations: require a diff or preview, no blanket "apply all"
• Shell commands: no auto-run for anything with rm, mv, DROP, DELETE or --force
• Deployments: stage first, review, then promote — never straight to production
• Bulk edits: cap the batch size and run once, check the result, then continue

Put a backup gate between the agent and disaster

The non-negotiable rule: your backups must live somewhere the agent has zero credentials for, and you take a fresh one before any run that can write.

This is the exact failure mode behind the scary headlines — an agent with broad access wipes the database and the backups in the same run, because both sat behind the same account. Separate them. If the agent can authenticate to your backup storage, it is not a backup, it is just a second copy waiting to be deleted.

Build a simple gate into your routine: snapshot, then work. On your own server, a one-liner before you start:

mysqldump yourdb > backup-$(date +%F-%H%M).sql

Store that copy off the box, on storage the agent cannot reach. With TPC Hosting, your backups are kept separate from the account an agent would ever touch, so a bad run on your site does not take your recovery copy with it. Combine that with our 30-day window to back out and a free migration if you are moving in, and getting a clean, protected baseline before you experiment is genuinely low-effort.

Sandbox first, then widen access slowly

Give a new agent a staging copy of your site before it ever touches production, and only widen its access once you have watched it behave.

Spin up a staging environment, point the agent at it, and let it run the real task against throwaway data. You will learn its habits — whether it over-reaches, whether it reads instructions literally, whether it tries to "clean up" things you did not ask it to. A staging site is the one place a mistake costs you nothing but time.

When you do move to production, widen access in steps rather than all at once. Here is a sane progression:

Skipping straight to stage four is how people end up writing incident post-mortems. Each step takes minutes.

Keep a short, honest checklist you actually use

The whole approach fits on one card, and the point is to run through it every single time rather than trusting your memory under pressure.

• Dedicated agent account, never your admin login
• Read-only database access by default; write granted per table, temporarily
• No DROP, TRUNCATE, ALTER or GRANT on the agent user
• Dry-run or plan-first on every destructive step
• Fresh backup taken, stored where the agent cannot reach it
• Tested on staging before production
• Access widened one step at a time, then revoked when the task ends

None of this slows you down in a way you will notice. It slows down the one run in a hundred that would otherwise ruin your week. If you are setting any of this up on our platform and want a second pair of eyes, TPC Hosting's chat has AI available at any hour and real engineers who follow up in business hours — handy when you are trying to work out whether a permission is too broad before you hand over the keys.

FAQ