Tekoälyagentti tuhosi tietokannan: 7 minuutin palautussuunnitelma

Käytännön tietoa Ailootin käytöstä on dokumentaatiossa.

Mitä tehdä ensimmäisen minuutin aikana: PYSÄHDY, älä panikoi#

Kun näin käy sinulle, ensimmäiseksi sinun on pysäytettävä agentti. Älä yritä perua sen toimia itse, älä käske sitä ”palauttamaan kaikkea” äläkä suorita uusia prompteja. Jokainen agentin seuraava toiminto voi ylikirjoittaa levyn lohkot, joihin tietosi saattavat yhä olla tallennettuina.

1. Pysäytä todellinen tuhoava kirjoittaja

   Keskeytä vaarallinen komento heti Ctrl+C:llä. Älä odota poiston valmistumista. Agentin pysäyttäminen ei välttämättä pysäytä sen lapsikomentoja, etätöitä tai tietokantakyselyjä. Tunnista todellinen kirjoittaja ja pysäytä tai peru juuri tämä toiminto. Tehosta lopettamista, jos tuhoaminen jatkuu. Säilytä muut prosessit, joilla voi olla palautettavia tiedostoja avoinna.

2. ÄLÄ käynnistä kannettavaa tietokonettasi uudelleen

   Poistettu data voi olla palautettavissa, mutta se riippuu tallennuksesta, tietokannan toiminnasta, SSD:n discard/TRIMistä ja myöhemmistä kirjoituksista. Minimoi kirjoitukset vahingoittuneelle taltiolle äläkä oleta tavujen olevan yhä olemassa.

3. Säilytä muut hyödyllisiä avoimia tiedostoja pitävät prosessit

   Säilytä muut prosessit, joilla on poistettuja tiedostoja avoinna, koska palautus voi onnistua tiedostokuvaajien kautta. Tämä ei koske tuhoavaa kirjoittajaa: pysäytä se ensin. Älä pidä poistoa käynnissä vain avoimen kahvan säilyttämiseksi.

4. Kirjaa tapahtuman näyttö erilliselle laitteelle

   Kirjaa täsmällinen aika, vahingoittuneet polut ja näkyvä komentotuloste. Tallenna mahdollinen tallennus tai lokikopio erilliselle todennetulle laitteelle vahingoittuneen taltion sijaan. Säilytä siellä elossa olevat seuratut, seuraamattomat ja ohitetut tiedostot sekä Git-metadata ennen palautusyritystä.

Seuraavaksi on 6 minuuttia aikaa palautukseen. Aloitetaan.

Minuutit 2–3: dokumentoi tarkasti, mikä meni pieleen#

Avaa uusi pääteikkuna. Älä käytä sitä, jossa agentti on käynnissä – avaa toinen. Suorita nämä kolme komentoa peräkkäin.

1. Kirjaa tarkasti, mikä git-repositoriossa muuttui:

git status
git log --since="30 minutes ago" --all --oneline

Poistettu seurattu tiedosto voi yhä olla indeksissä tai commitissa. Säilytä nykyinen työpuu seuraamattomine ja ohitettuine tiedostoineen ennen mitään palautusta, sillä palautus paikalleen voi ylikirjoittaa säilyneitä muokkauksia. Tarkista ja palauta erillisessä kopiossa.

2. Tarkista, mitkä agenttiprosessit ovat käynnissä:

ps aux | grep -i claude
ps aux | grep -i cursor

Tunnista yhä vaarallisia kirjoituksia tekevä prosessi. Pelkkä nimiosuma ei riitä. Pysäytä kirjoittaja ja varmista sen pysähtyminen. Säilytä muut prosessit, joilla on hyödyllisiä avoimia tiedostoja. Jos hallittu lopetus ei onnistu ja tuho jatkuu, pakotettu lopetus voi olla tarpeen.

3. Tallenna agentin istuntoloki:

Claude Code tallentaa JSONL-istunnot kansioon ~/.claude/projects/. Cursor tallentaa ne kansioon ~/.cursor/. Tee kopio heti:

cp -r ~/.claude/projects /external/incident-evidence/claude-projects

Korvaa /external/incident-evidence/ olemassa olevalla näyttöhakemistolla erillisessä todennetussa liitetyssä laitteessa. Älä kirjoita varmuuskopiota vahingoittuneelle taltiolle tai ylikirjoita olemassa olevaa näyttöä. Tämä kansio sisältää sanatarkan keskustelun agentin kanssa – mitä komentoja se suoritti, mitä se vastasi ja missä järjestyksessä. Se on tärkein lähteesi tapahtuman tutkimiseen ja mahdollisesti poistettujen tiedostojen palauttamiseen agentin kontekstista (katso vaihe 4).

Minuutti 4: git reflog – paras mahdollisuutesi#

git reflog kirjaa paikallisten viitteiden liikkeet tietueiden säilyessä. Vanhentuminen ja siivous vaihtelevat, ja tavoittamattomat objektit voidaan poistaa. Se ei ole taattu arkisto jokaisesta menneestä commitista. Tee alla olevat palautusvaiheet erillisellä laitteella säilytetystä repositoriokopiosta.

Vaihe 1. Näytä loki:

git reflog --all

Saat esimerkiksi tällaisen luettelon:

1a2b3c4 HEAD@{0}: reset: moving to HEAD~3
9z8y7x6 HEAD@{1}: commit: working version of the dashboard
5w4v3u2 HEAD@{2}: commit: added admin panel

Etsi tila ennen kuin agentti aiheutti vahingon. Jokainen merkintä on ”tilannevedos” repositoriosi tilasta kyseisellä hetkellä.

Vaihe 2. Palauta erilliseen työpuuhun:

Kun olet kopioinut repositorion ja kaiken säilyneen työn erilliselle laitteelle, suorita tämä säilytetystä repositoriokopiosta. Korvaa arvo reflogista tarkistamallasi täsmällisellä commit-SHA:lla ja valitse käyttämätön haara sekä kohde:

RECOVERY_COMMIT='replace-with-verified-commit-sha'
git worktree add -b recovery-check ../recovery-check "$RECOVERY_COMMIT"

Tarkista palautetut tiedostot kansiossa ../recovery-check ja vertaa säilytettyihin commitoimattomiin tiedostoihin ennen kopioimista takaisin. Komento hakee valitun commitin erikseen eikä nollaa vahingoittunutta työpuuta. Linkitetyt työpuut jakavat kopioidun repositorion Git-objektivaraston, joten tämä on palautustyötila, ei riippumaton varmuuskopio. Katso virallinen git-worktree-dokumentaatio.

Jos reflog on myös siivottu (agentti ehti suorittaa git gc -komennon):

git fsck --lost-found

Tämä komento etsii ”kadonneita” committeja ja blob-objekteja (tiedosto-objekteja), joita ei enää ole liitetty mihinkään haaraan. Ne näkyvät kansioissa .git/lost-found/commit/ ja .git/lost-found/other/. Näin palautat tiedoston sieltä:

git cat-file -p <SHA1-blob> > recovered-file.ext

Milloin git reflog ei auta:

• Tiedosto oli vain työhakemistossa, eikä siitä ollut tehty committia tai stashia → reflog ei löydä sitä
• Yli 90 päivää on kulunut (vakioarvo gc.reflogExpire), ja git gc on suoritettu
• Koko repositorio poistettiin (rm -rf .git) – silloin tarvitset Time Machinen tai tilannevedoksen

Minuutti 5: palauta tietokanta varmuuskopiosta#

Tietokanta poistettiin komennolla DROP DATABASE, DROP TABLE tai DELETE FROM ... WHERE ... (ilman WHERE-ehtoa). Mitä sinun pitäisi tehdä?

Vaihe 1. Selvitä, tarjoaako palveluntarjoajasi PITR:ää:

Vaihe 2. Palauta uuteen instanssiin, älä vanhan päälle:

Älä koskaan palauta aktiivisen tietokannan päälle. Luo varmuuskopiosta uusi instanssi ja vaihda sitten sovellus käyttämään sitä. Jos jokin menee pieleen, voit palauttaa DNS-asetuksen ennalleen.

Vaihe 3. Jos PITR ei ollut käytössä, käytä viimeisintä tilannevedosta:

# AWS RDS, list snapshots:
aws rds describe-db-snapshots --db-instance-identifier my-db

# Restore from a snapshot:
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier my-db-restored \
  --db-snapshot-identifier rds:my-db-2026-05-28-12-00

Supabasea koskeva huomio, joka yllätti monet vuonna 2026: kun PITR on käytössä, päivittäisten varmuuskopioiden luominen loppuu. Toiminta on epäintuitiivista; voit päätyä täysin ilman varmuuskopioita. Tarkista Dashboard → Database → Backups ja varmista, että PITR on aktiivinen JA että sinulla on tilannevedos, josta palauttaa.

Minuutti 6: Time Machine, lsof ja levyn tilannevedokset#

macOS – Time Machine:

# List snapshots:
tmutil listbackups

# Restore a file from the latest backup:
tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx

Time Machine ottaa tilannevedoksia tunnin välein, säilyttää tuntikohtaiset tilannevedokset päivän ajan, päivittäiset viikon ajan ja viikoittaiset tilannevedokset määräämättömän ajan. Jos kannettava tietokoneesi on yhdistetty Time Capsuleen tai ulkoiseen levyyn, projektisi on siellä tunnin tarkkuudella.

Linux – tiedosto poistettiin, mutta prosessilla on se yhä avoinna:

# Find all “deleted” files that a process still has open:
sudo lsof | grep deleted

# You'll get lines like:
# node 12345 user 24w REG 8,1 4096 1234567 /path/to/deleted/file.txt (deleted)

# Copy the file directly from /proc/PID/fd/N:
sudo cp /proc/12345/fd/24 ~/recovered-file.txt

Onnistumisen mahdollisuus on ~95 %, jos prosessia ei ole suljettu. Toimii ext4-, xfs- ja btrfs-tiedostojärjestelmissä.

macOS – vastaava tapa lsof-komennolla:

lsof | grep deleted

Tiedoston kopiointi on hankalampaa (koska /proc/-hakemistoa ei ole), mutta sen voi tehdä lldb:llä:

lldb -p 12345
(lldb) memory read --outfile recovered.txt --binary 0xADDRESS 0xSIZE

Koko levyn tilannevedos (Linux, viimeinen keino):

sudo dd if=/dev/sda1 of=/external/disk-image.img bs=4M status=progress

Tämä tallentaa koko osion levykuvaksi. Palauta tiedot sitten extundelete- tai photorec-ohjelmalla. Palautuksen onnistumismahdollisuus riippuu siitä, kuinka paljon levylle on kirjoitettu poistamisen jälkeen. Jos mitään ei ole kirjoitettu, mahdollisuus on 80–90 %. Jos järjestelmä on ollut käynnissä jo tunnin ajan, se on 20–30 %.

Minuutti 7: mitä tehdä, jos varmuuskopiota ei ole#

Vaihtoehto 1 – palveluntarjoajan tuki:

AWS, Yandex Cloud, Google Cloud ja DigitalOcean palauttavat ajoittain tietoja sisäisestä tallennustilastaan myös asiakkaan katastrofin jälkeen, erityisesti maksullisilla sopimuksilla. Avaa tukipyyntö, ilmoita tapahtuman tarkka ajankohta ja liitä mukaan kuvakaappauksia tilanteesta. Tämä onnistuu useimmiten suurten palveluntarjoajien kohdalla, sillä ne säilyttävät automaattisia varmuuskopioita omassa järjestelmässään. Mahdollisuus on 40–60 %; vastausaika on 24–72 tuntia.

Vaihtoehto 2 – S3-versionointi:

Jos tiedostot olivat S3:ssa (tai Yandex Object Storagessa) ja versionointi oli käytössä, kaikki versiot ovat fyysisesti olemassa; ne on vain merkitty ”poistetuiksi”.

# AWS—list versions:
aws s3api list-object-versions --bucket my-bucket --prefix files/

# Restore a version:
aws s3api copy-object \
  --bucket my-bucket \
  --copy-source my-bucket/files/data.json?versionId=ABC123 \
  --key files/data.json

Tärkeä huomio: Claude Code ei säilytä istuntoja ikuisesti – vanhat JSONL-tiedostot poistetaan automaattisesti muutaman viikon kuluttua. Varmista, että sinulla on kuukauden JSONL-historia katastrofin varalta, kopioimalla ~/.claude/projects/ ulkoiselle levylle kerran viikossa yksinkertaisella cron-työllä:

# In crontab, every Sunday at 03:00:
0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/

Se on ilmaista ja pelastaa sinut tilanteessa, jossa ”kaikki on poissa, varmuuskopiota ei ole ja reflog on tyhjä”.

7 sääntöä, joilla varmistat, ettei näin tapahdu enää koskaan#

1. Plan Mode ennen tuhoavia toimia. Claude Codessa:

claude --plan

Agentti laatii suunnitelman ennen toimimista. Luet sen, näet DROP TABLE users ja peruutat. Ilman Plan Modea agentti päättää itse ja suorittaa toiminnon millisekunneissa. Lue lisää Claude Coden Plan Mode -oppaasta.

2. Hookit lisälaukaisimena. Käytä testattua PreToolUse-hookia, joka lukee tapahtuman JSONin stdinistä ja palauttaa 2 havaitusta korkean riskin toimesta. Alla oleva täydellinen esimerkki kattaa Bashin, Writen ja Editin. Se ei ole turvallisuusraja ja voi ohittaa epäsuoria toimia. Pidä tietokantaoikeudet ja hiekkalaatikko rajoittavina.

3. Agentille tietokantakäyttäjä, jolla on vain lukuoikeudet. Luo agentille erillinen käyttäjä, jolla ei ole DROP-, TRUNCATE- tai DELETE-oikeuksia:

CREATE USER claude_readonly WITH PASSWORD 'xxx';
GRANT CONNECT ON DATABASE myapp TO claude_readonly;
GRANT USAGE ON SCHEMA public TO claude_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO claude_readonly;

Kun agentin täytyy kirjoittaa tietokantaan, vaihda käsin toiseen käyttäjään. Pelkät lukuoikeudet riittävät päivittäisiin tehtäviin (data-analyysiin, raportteihin ja koontinäyttöihin).

4. Tallenna tarkistetut muutokset Gitiin. Tiedoston .claude/settings.json PostToolUse-hook voi tulostaa muistutuksen Write- ja Edit-toimintojen jälkeen:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'Tarkista diff ja tee käsin commit vain sovituista tiedostoista.' >&2"
          }
        ]
      }
    ]
  }
}

Tämä esimerkki tulostaa vain muistutuksen; se ei lisää tiedostoja indeksiin eikä tee committeja. Tarkista diff ja tee käsin commit vain sovituista tiedostoista. Reflog ei tallenna muutoksia, joista ei ole tehty committia.

5. Hiekkalaatikkoprojekti kokeiluja varten. Älä koskaan anna agentin työskennellä projektissa, jossa on oikeita asiakastietoja. Luo erillinen ~/sandbox-projects/-kansio, jossa on kopio projektista ja synteettistä dataa. Käytä sitä uuden promptin, agentin tai MCP-palvelimen kokeilemiseen. Jos jokin rikkoutuu, vahinkoa ei synny.

6. Levyn tilannevedokset restic-ohjelmalla tunnin välein.

# Install:
brew install restic  # macOS
sudo apt install restic  # Linux

# Create repository:
restic init --repo /external/backups

# Back up the current project:
restic --repo /external/backups backup ~/projects

# Schedule cron every hour:
crontab -e
# Add:
0 * * * * restic --repo /external/backups backup ~/projects

Seitsemän päivän tuntikohtaiset varmuuskopiot ja neljän viikon päivittäiset varmuuskopiot – ja voit aina palata mihin tahansa aiempaan ajankohtaan. Se on ilmaista ja kestää 10 minuuttia ottaa käyttöön.

7. Arkistoi Claude Code JSONL -istunnot. Tämä mainittiin jo edellä, mutta toistetaan erillisenä sääntönä: ajasta ~/.claude/projects/-kansion viikoittainen rsync-kopio ulkoiselle levylle. Se on ilmaista ja vaatii yhden rivin crontabiin.

Valmiit hookit vaarallisten komentojen estämiseen#

Yhdistä tämä kohta olemassa oleviin hookeihin tiedostossa .claude/settings.json korvaamatta niitä:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/check-risk.py\""
          }
        ]
      }
    ]
  }
}

Luo .claude/hooks/check-risk.py seuraavalla Python 3 -skriptillä:

import json
import re
import sys
from pathlib import Path

try:
    event = json.load(sys.stdin)
    tool = event["tool_name"]
    data = event["tool_input"]
    blocked = False
    if tool == "Bash":
        command = data["command"]
        blocked = bool(re.search(
            r"drop\s+(database|table)|truncate\s+table|"
            r"delete\s+from.*where\s+1|rm\s+-rf|"
            r"git\s+reset\s+--hard|git\s+push.*(--force|-f)|"
            r"chmod\s+-R\s+777",
            command, re.IGNORECASE | re.DOTALL))
    elif tool in ("Write", "Edit"):
        path = Path(data["file_path"]).resolve()
        blocked = (".git" in path.parts or path.name.startswith(
            (".env", "credentials", "secrets")))
except (ValueError, KeyError, TypeError, OSError):
    print("BLOCKED: invalid hook input", file=sys.stderr)
    sys.exit(2)

if blocked:
    print("BLOCKED: high-risk command or sensitive path", file=sys.stderr)
    sys.exit(2)
sys.exit(0)

Hook lukee dokumentoidun JSON-tapahtuman stdinistä, tarkistaa tool_input.command- tai tool_input.file_path-arvon ja palauttaa osumasta koodin 2. Se tarkistaa sekä Writen että Editin. Testaa vaaraton sallittu syöte ja estetty syöte ennen tukeutumista ja varmista Pythonin sekä määritetyn skriptin todella käynnistyvän.

Tämä on sanallinen laukaisin: se voi ohittaa eri lippujärjestykset, skriptit, aliakset, peitetyt komennot, muut työkalut ja epäsuorat kirjoitukset sekä estää vaarattoman lainatun esimerkin. Se ei myönnä tai poista käyttöjärjestelmän tai tietokannan oikeuksia. Pidä tuotantotunnisteet agenttiympäristön ulkopuolella, käytä vain luku -tietokantaroolia ja pakotettua hiekkalaatikkoa ja suojaa hook-asetukset muokkaamiselta. Katso virallinen hook-syötteen ja paluuarvojen viite.

Katselmoi tarkoituksellinen poikkeusoperaatio ja suorita se agentin ulkopuolella asianmukaisella rajatulla tilillä. Komentotulkin ympäristömuuttuja ei ole dokumentoitu hookin poistoliittymä, eivätkä hookit hallitse tavallisia terminaalikomentoja.

Milloin tekoälylle kannattaa antaa oikeuksia (ja milloin ei)#

Anthropic dokumentoi --dangerously-skip-permissions-lipun (tunnetaan myös YOLO-tilana) vaihtoehtona ”luotetuille ympäristöille”. Vuoden 2026 todellisuudessa se on suora tie katastrofiin. Kun agentin ei tarvitse kysyä lupaa, se:

• Suorittaa minkä tahansa Bash-komennon ilman vahvistusta
• Kirjoittaa tiedostoja kysymättä
• Voi käynnistää ala-agentin, joka perii YOLO-tilan eikä voi poistaa sitä käytöstä

Kolmas kohta on kavalaimmillaan. Jos käynnistät pääagentin YOLO-tilassa, myös sen ala-agentit toimivat YOLO-tilassa, etkä voi kumota sitä. Yksi prompti – ja kymmenen rinnakkaisen agentin ketju voi tehdä järjestelmällesi mitä tahansa.

Sääntö:

Vaihtoehto – tarkasti rajatut oikeudet. Tiedostossa .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(git status:*)",
      "Bash(git log:*)",
      "Bash(npm run build:*)",
      "Read(*)",
      "Edit(src/**)"
    ],
    "deny": [
      "Bash(rm:*)",
      "Bash(git push:*)",
      "Edit(.env)",
      "Edit(prisma/migrations/*)"
    ]
  }
}

Agentti näkee, mikä on sallittua ja mikä ei. Sinun ei tarvitse napsauttaa ”kyllä” tai ”ei” joka kerta – agentti toimii nopeasti ja sinä hallitset rajoja.

Seuraavaksi: lisää kirjanmerkkeihin 7 minuutin tarkistuslista#

Tarkistuslista: ”Tekoäly poisti sen – mitä teen?”

1. Pysäytä todellinen tuhoava kirjoittaja heti ja varmista lapsi- tai etätoimintojen pysähtyminen
2. Älä käynnistä konetta uudelleen; säilytä muut poistettuja tiedostoja avoinna pitävät prosessit
3. Kirjaa tapahtuma-aika ja komentotodisteet erilliselle todennetulle laitteelle
4. Kopioi säilyneet tiedostot, Git-metadata ja olennaiset istuntolokit samalle erilliselle laitteelle
5. Tarkista säilytetyssä repositoriokopiossa git reflog --all ja palauta todennettu commit erilliseen työpuuhun
6. Jos git ei auttanut – git fsck --lost-found
7. Tietokanta: PITR (AWS/Yandex/Supabase) tai viimeisin tilannevedos
8. Tiedostot: Time Machine Macissa, lsof Linuxissa
9. Viimeinen keino: palveluntarjoajan tuki + S3-versionointi
10. Palautuksen jälkeen määritä tämän oppaan seitsemän ennaltaehkäisevää sääntöä

Seuraavaksi – järjestelmällinen suojaus:

• Plan Mode Claude Codessa – jotta agentti tekee suunnitelman ennen tuhoavaa toimintoa
• Hookit Claude Codessa – valmiit mallit vaarallisten komentojen estämiseen
• Muutosten palauttaminen Claude Codessa – yksityiskohtainen opas /rewind-komentoon, gitiin ja viiteen tavalliseen palautusmenetelmään
• Tietoturvatarkastus Claude Codessa – säännölliset koodin tietoturvatarkastukset

Avaa Ailoot.