How to Recover After an AI Agent Modified Your Database

When an AI agent executes unauthorized database operations — dropping tables, deleting rows, modifying schemas, or inserting bad data — recovery depends on your backup strategy and how quickly you respond. SafeClaw by Authensor prevents this by gating all database-related actions through deny-by-default policies, blocking agents from executing SQL commands, running migrations, or connecting to database endpoints without explicit permission. If database damage has already occurred, follow the recovery steps below immediately.

Immediate Response

1. Stop the Agent

Terminate the agent to prevent further database modifications.

2. Assess the Damage

Connect to your database and evaluate what changed:

-- Check recently modified tables (PostgreSQL)
SELECT schemaname, relname, last_autovacuum, last_autoanalyze
FROM pg_stat_all_tables
ORDER BY greatest(last_autovacuum, last_autoanalyze) DESC NULLS LAST
LIMIT 20;

-- Check for dropped tables
-- Compare against your schema migration files

3. Preserve Evidence

Before any recovery actions, snapshot the current database state:

# PostgreSQL
pg_dump -Fc your_database > damage_snapshot_$(date +%s).dump

MySQL
mysqldump your_database > damage_snapshot_$(date +%s).sql

Also preserve the SafeClaw audit log:

npx @authensor/safeclaw audit --export --output incident_audit.json

Recovery Options

Option 1: Restore from Backup (Best Case)

# PostgreSQL - point-in-time recovery
pg_restore -d your_database --clean latest_backup.dump

MySQL
mysql your_database < latest_backup.sql

If using managed services (AWS RDS, Cloud SQL)
Use the cloud console to restore to a point in time before the incident

Option 2: Restore Specific Tables

If only specific tables were affected:

# Restore a single table from backup (PostgreSQL)
pg_restore -d your_database --table=affected_table latest_backup.dump

Option 3: Reverse the Changes

If the agent ran identifiable SQL commands, reverse them:

-- If rows were deleted, restore from backup for that table
-- If data was updated, use your backup to find original values
-- If tables were dropped, restore from backup or re-run migrations

Option 4: Replay WAL/Binary Logs

For PostgreSQL WAL or MySQL binary log recovery:

# PostgreSQL - restore to point in time
recovery_target_time = '2026-02-13 14:30:00'

MySQL - replay binary logs up to the incident
mysqlbinlog --stop-datetime="2026-02-13 14:30:00" binlog.000001 | mysql

Review the Audit Trail

npx @authensor/safeclaw audit --filter "action:database" --last 50
npx @authensor/safeclaw audit --filter "action:shell.exec" --filter "resource:sql" --last 30

The hash-chained audit trail shows the exact database commands the agent executed, their timestamps, and their sequence.

Install SafeClaw and Protect Your Database

npx @authensor/safeclaw

Block All Database Operations by Default

Add these rules to your safeclaw.policy.yaml:

rules:
  # Block direct database access
  - action: database.query
    resource: "*"
    effect: deny
    reason: "Direct database queries require human review"

- action: database.execute
    resource: "*"
    effect: deny
    reason: "Database mutations are forbidden for agents"

# Block shell access to database tools
  - action: shell.exec
    resource: "psql *"
    effect: deny
    reason: "Direct psql access blocked"

- action: shell.exec
    resource: "mysql *"
    effect: deny
    reason: "Direct mysql access blocked"

- action: shell.exec
    resource: "mongo *"
    effect: deny
    reason: "Direct mongo access blocked"

- action: shell.exec
    resource: "sqlite3 *"
    effect: deny
    reason: "Direct sqlite3 access blocked"

# Block migration commands
  - action: shell.exec
    resource: "migrate"
    effect: deny
    reason: "Database migrations require human review"

# Allow read-only database access if needed
  - action: database.query
    resource: "SELECT *"
    effect: allow
    read_only: true
    reason: "Agent can run read-only queries"

Protect Database Connection Strings

rules:
  - action: file.read
    resource: "*/database*"
    effect: deny
    reason: "Database config files are off limits"

- action: file.read
    resource: "*/.env"
    effect: deny
    reason: "Env files with DB credentials are off limits"

Block Network Access to Database Ports

rules:
  - action: network.request
    resource: "*:5432"
    effect: deny
    reason: "Block direct PostgreSQL connections"

- action: network.request
    resource: "*:3306"
    effect: deny
    reason: "Block direct MySQL connections"

- action: network.request
    resource: "*:27017"
    effect: deny
    reason: "Block direct MongoDB connections"

Prevention Strategy

Database operations are among the highest-risk actions an AI agent can take. SafeClaw's deny-by-default model ensures no database access is possible without an explicit allow rule. The 446-test suite validates database action gating across both Claude and OpenAI integrations.

1. Block all database writes by default — this is SafeClaw's default behavior.
2. If agents need database access, allow only read-only queries to specific tables.
3. Block shell access to database CLIs.
4. Maintain regular database backups — agent safety does not replace backup strategy.
5. Review audit logs for any database-adjacent actions after agent sessions.

Related Resources

• Prevent Agent Database Drop
• How to Recover Files Deleted by an AI Agent
• AI Agent Sent Data to External Server: Response
• Workflow: Rollback AI Agent Changes