AI-agenttien tuotantokäytön toimivat turvarajat

AI-agenttien tuotantokäytön turvarajojen on kestettävä muutakin kuin kohtelias prompti. Autonominen coding-agentti voi tulkita kohteen väärin, yrittää toimintoa uudelleen, paljastaa tunnistetiedon selityksessään tai jatkaa epäselvän vastauksen jälkeen. Tuotantoturvallisuuden on siksi oltava osa suoritettavaa rajapintaa, valtuutusmallia ja auditointipolkua – ei vain ohjeita.

Dockup yhdistää Claude Coden ja Codexin skillissä annetut toimintaohjeet CLI-tason valvontaan: salaisuudet peitetään, tuhoavat toiminnot edellyttävät --yes-lippua, virheet palauttavat vakaat koodit, käyttöönotot voivat odottaa pääteaseman saavuttamista ja muutokset näkyvät auditointilokissa.

Miksi turvarajat on valvottava promptin alapuolella?

Prompti on hyödyllinen toimintaperiaate, mutta se ei ole tietoturvaraja. Agentin kontekstia voidaan lyhentää, ohjeet voivat olla ristiriidassa keskenään ja malli voi valita väärän tulkinnan. Taustalla olevan työkalun pitäisi tehdä vaarallisesta toiminnasta vaikeaa tai mahdotonta.

Ajatellaan poistopyyntöä. Heikossa toteutuksessa käytössä on komento, joka poistaa kohteen välittömästi, ja agentin odotetaan muistavan pyytää vahvistusta. Vahvemmassa toteutuksessa toiminto hylätään, ellei erillistä vahvistuslippua ole annettu.

Dockup käyttää vahvempaa mallia:

dockup up production/api --prune --json

Ilman erillistä vahvistusta tuhoava siivous hylätään, ja JSON sisältää code:"needs_confirm". Mitään ei karsita. Agentin on välitettävä tulos ihmiselle, saatava hyväksyntä ja suoritettava komento sitten tietoisesti uudelleen:

dockup up production/api --prune --yes --json

Tämä on defense in depth -periaatetta. Dockup skill ohjeistaa agenttia pysähtymään, kun taas CLI estää tahattoman suorituksen, vaikka ohje jäisi huomaamatta.

Miten salaisuuksien peittäminen suojaa autonomisia agentteja?

Agentit sisällyttävät usein komentojen tulosteen päättelyynsä tai lopulliseen vastaukseensa. Jos lukuoperaatio palauttaa tuotantotunnisteen, salaisuus voi levitä keskusteluhistoriaan, lokeihin, telemetriaan, kuvakaappauksiin tai kopioituihin häiriötilanneraportteihin.

Turvallinen konfiguraatiorajapinta erottaa salaisuuksien metatiedot niiden arvoista. Dockup palauttaa ympäristömuuttujien avaimet ja isSecret-merkinnän, mutta tallennettujen salaisuuksien arvot ovat null tai peitettyjä.

dockup env list -s production/api --json

Agentti voi asettaa salaisuuden ilman, että se voi myöhemmin hakea sitä:

dockup env set API_KEY="$API_KEY" \
  --secret \
  -s production/api \
  --json

Salaisuuksien peittäminen ei poista huolellisen prosessikäsittelyn tarvetta. Alkuperäinen arvo on edelleen olemassa shell-ympäristössä asetustoiminnon aikana. Vältä set -x -asetusta, älä tulosta muuttujaa ja älä rakenna komentomerkkijonoja, jotka päätyvät verbose-lokiin.

Tietokantojen salasanat, API-avaimet, rekisteritunnisteet, SSH-tunnistetiedot ja Windows RDP -tunnistetiedot on käsiteltävä kertakäyttöisinä tai rajoitetusti palautettavina tulosteina. Agentin tulisi tallentaa ne hyväksyttyyn secret manageriin tai välittää ne suoraan seuraavalle prosessille toistamatta niitä tekstissä.

Laajempi sovellustason lähestymistapa kuvataan artikkelissa security best practices.

Miten tuhoavien toimintojen hyväksynnän pitäisi toimia?

Kaikkiin muutoksiin ei tarvita samanlaista hyväksyntäprosessia. Hyödyllinen autonomiamalli jakaa toiminnot niiden palautettavuuden ja vaikutuslaajuuden perusteella:

Taso	Esimerkki	Agentin oletustoiminta
Vain luku	Palveluiden luettelo, tilan lukeminen, lokien tarkastelu	Suorita ja tee yhteenveto
Palautettava kirjoitus	Muuttujan asettaminen, käyttöönoton käynnistäminen	Suorita hyväksytyn rajauksen puitteissa
Operatiivinen palautuminen	Uudelleenkäynnistys, vanhemman käyttöönoton suorittaminen uudelleen	Suorita, jos runbook sallii; raportoi näyttö
Tuhoava	Palvelun tuhoaminen, tietokannan poistaminen, projektista poistuminen	Pysähdy ja pyydä erillinen hyväksyntä
Laajasti tuhoava	--prune-toiminnon käyttäminen, omistajuuden siirtäminen	Edellytä kohdekohtaista ihmisen vahvistusta

Erillisen hyväksynnän pitäisi sisältää tarkka kohde ja seuraus. ”Kyllä, jatka” on heikompi kuin ”Poista staging/old-api ja siihen liittyvät palveluresurssit.” Agentin ei pidä käyttää uudelleen toiselle komennolle tai kohteelle annettua hyväksyntää.

Dockup config as code on oletusarvoisesti lisäävä. dockup up ei poista manifestista puuttuvia ympäristömuuttujia tai domaineja. Poistaminen edellyttää erillistä --prune-lippua:

dockup plan production/api --json
dockup up production/api --prune --json

Plan on vain luku -toiminto, ja se pitäisi tarkistaa ensin. Myös --prune-lipun kanssa salaisuudet, palvelut, tietokannat ja volumet on suojattu tältä manifestin siivouspolulta. Katso koko työnkulku artikkelista dockup.yaml config as code.

Miten rakenteiset virheet pitävät autonomian rajattuna?

Agentti tarvitsee rajatun joukon turvallisia haaroja. Vapaamuotoiset viestit ovat hyödyllisiä ihmisille, mutta vakaat virhekoodit tekevät ensimmäisestä vastauksesta deterministisen.

Koodi	Oikea vastaus
not_logged_in	Pysähdy ja hanki kelvollinen tunnistetieto
not_linked	Selvitä kohde tai anna se eksplisiittisesti
no_target	Suorita palveluiden etsintä; älä koskaan keksi slugia
needs_confirm	Pyydä ihmisen hyväksyntä
deploy_trigger_failed	Raportoi, miksi toimintoa ei voitu käynnistää
deploy_failed	Tarkastele build-lokeja
deploy_timeout	Raportoi, ettei pääteasemasta ole varmuutta

Käyttöönotossa pitäisi käyttää pääteaseman odottamista:

dockup deploy production/api --wait --json

Oletusaikakatkaisu on 900 sekuntia. Exit-koodi 0 osoittaa, että käyttöönotto saavutti onnistuneen tilan. Nollasta poikkeava exit-koodi estää agenttia jatkamasta domain-muutoksiin, migraatioihin tai ilmoituksiin ikään kuin tuotanto olisi valmis.

Tätä suunnittelua käsitellään artikkelissa AI agent CLI design. Periaate on yksinkertainen: työkalun on tehtävä epäselvästä tuloksesta eksplisiittinen.

Mitä auditointilokiin pitäisi tallentaa?

Attribuutio ilman autonomiaa synnyttää operatiivista velkaa. Tuotannon auditointipolun pitäisi vastata siihen, kuka toimi, mitä rajapintaa hän käytti, mihin kohteeseen muutos kohdistui, oliko kyse luku- vai kirjoitustoiminnosta, milloin se tapahtui ja onnistuiko se.

Dockup tallentaa CLI-, UI- ja API-toiminnot. Ylläpitäjät voivat tarkastella viimeisimpiä muutoksia:

dockup audit --writes --json
dockup audit --number 30 --json
dockup audit --search domains --json

Agentin oman raportin pitäisi täydentää alustan tietoja. Sisällytä:

1. Selvitetty project/service-kohde.
2. Komentoluokka ilman salaisuuksien arvoja.
3. Alustan palauttamat käyttöönotto- tai resurssitunnisteet.
4. Exit-koodi ja rakenteinen tila.
5. Muutoksen jälkeen kerätty näyttö.
6. Tuhoavaa työtä varten saatu hyväksyntä.
7. Jäljellä oleva epävarmuus tai jatkotoimet.

Auditointilokit eivät ole vain jälkikäteistä syyllisten etsimistä varten. Niiden avulla toinen agentti tai ihminen voi muodostaa tilasta kokonaiskuvan toistamatta riskialttiita komentoja.

Miten tiimit voivat lisätä agentin autonomiaa turvallisesti?

Aloita lukuoikeuksista ja yhdestä matalan riskin palvelusta. Laajenna käyttöoikeuksia vasta, kun agentti osoittaa kohteiden löytyvän oikein, salaisuuksien käsittelyn olevan asianmukaista, virhehaaroituksen toimivan ja raportoinnin olevan luotettavaa.

Käytännöllinen eteneminen on seuraava:

Vaihe 1: Tarkkaile

Salli palveluiden luettelointi, tilan tarkastelu, käyttöönottohistoria, build-lokit, runtime-lokit, uptime-, usage- ja security scan -luvut. Vertaa agentin yhteenvetoa raakaan JSON-dataan.

Vaihe 2: Ota käyttöön kiinteään kohteeseen

Salli yhden palvelun käyttöönotto --wait-lipulla. Edellytä health checkiä ja rakenteista valmistumisraporttia. Älä anna poisto- tai tiimikäyttöoikeuksia.

Vaihe 3: Hallitse palautettavaa konfiguraatiota

Salli ei-salaiset ja salaiset muuttujapäivitykset, health check -konfiguraatio ja custom domainin määritys tarkistetun runbookin puitteissa. Edellytä uutta käyttöönottoa ympäristömuutosten jälkeen.

Vaihe 4: Suorita palautumistoimia

Salli uudelleenkäynnistys tai rollback vain, kun agentti valitsee täsmällisen, tunnetun käyttöönoton tunnisteen ja säilyttää virhenäytön.

Vaihe 5: Hyväksynnän taakse rajattu tuhoava työ

Pidä tuhoavat liput erillisen ihmisen hyväksynnän takana, vaikka tunnistetieto teknisesti sallisi niiden käytön. Käytä mahdollisuuksien mukaan rajattuja API-avaimia ja tarkista auditointipolku säännöllisesti.

Agentin skillin asennus vahvistaa näitä toimintatapoja:

npm install -g dockup-cli
dockup skill install
dockup skill status --json

Dockup CLI reference dokumentoi valvotun komentojen toiminnan. Agentin pitäisi tarkistaa paikallinen schemansa sen sijaan, että se luottaisi muistamaansa esimerkkiin.

Turvarajojen tarkistuslista

Ennen tuotantokäyttöoikeuksien myöntämistä vastaa jokaiseen kysymykseen:

• Pystyykö agentti löytämään tarkat kohteet arvailematta?
• Peitetäänkö salaisuuksien arvot kaikissa lukupoluissa?
• Palauttaako jokainen epäonnistunut muutos nollasta poikkeavan exit-koodin?
• Voivatko pitkät toiminnot odottaa pääteaseman saavuttamista?
• Estetäänkö tuhoavat toiminnot ilman erillistä vahvistusta?
• Ovatko tunnistetiedot rajattuja ja toimitetaanko ne promptien ulkopuolella?
• Löytyykö jokainen muutos auditointilokista?
• Onko rollback- tai palautumismenettely testattu?
• Voivatko skillin ja suoritettavan ohjelman versiot eriytyä?
• Erottaako lopullinen raportti faktat epävarmuudesta?

”Ei” on suunnittelutehtävä, ei promptin kirjoittamiseen liittyvä tehtävä. Tuotantoautonomiaa pitäisi kasvattaa vain, kun taustalla olevat takeet vahvistuvat.

Testaa turvarajat virhetilanteina

Tarkistus on keskeneräinen, kunnes tiimi laukaisee rajat tarkoituksella. Suorita käyttöönotto virheellisellä tunnisteella, pyydä tuntematonta kohdetta, anna testibuildin epäonnistua, aseta hyvin lyhyt aikakatkaisu ja yritä tuhoavaa komentoa ilman vahvistusta. Jokaisen tapauksen pitäisi tuottaa nollasta poikkeava exit-koodi ja vakaa koodi ilman salaisuuksien vuotamista tai tahattomia muutoksia.

Näin AI-agenttien tuotantokäytön turvarajoista tulee havaittavia takeita. Toista testit CLI- tai policy-päivitysten jälkeen samalla tavalla kuin toistaisit sovelluksen authentication- ja authorization-testit. Turvaraja, joka on olemassa vain esityskalvoilla, ei suojaa valvomatta suoritettavaa julkaisua.

Ota työnkulku tuotantokäyttöön

Asenna skill, tarkista sen ohjeet ja testaa kaikki turvarajat – myös estetty tuhoava komento – ennen tuotantotunnisteen myöntämistä.

npm install -g dockup-cli
dockup skill install

Ensimmäinen komento asentaa CLI:n. Toinen asentaa yhteensopivan Dockup skillin Claude Codea ja Codexia varten. Aloita maksutta osoitteessa app.dockup.ai.

UKK

Riittävätkö promptiohjeet pitämään AI-agentin turvallisena tuotannossa?

Eivät. Promptit auttavat ohjaamaan toimintaa, mutta kriittiset kontrollit, kuten salaisuuksien peittäminen, vahvistukset, valtuutus, exit-koodit ja auditointilokitus, on valvottava työkalulla ja alustalla.

Miten Dockup estää tuhoavat toiminnot?

Tuhoavat komennot kieltäytyvät suorittamasta toimintoa ilman eksplisiittistä --yes-lippua ja palauttavat rakenteisen needs_confirm-koodin, jolloin agentti voi pysähtyä ja pyytää ihmiseltä hyväksyntää.

Voiko AI-agentti lukea Dockupiin tallennettuja salaisia ympäristömuuttujien arvoja?

Tallennettujen salaisuuksien arvot peitetään tulosteessa. Agentti näkee avaimen ja salaisuusmerkinnän ja voi korvata arvon, mutta se ei saa tallennettua salaisuutta haltuunsa.

Miksi rakenteiset virhekoodit ovat tärkeitä autonomialle?

Ne rajaavat agentin tunnettuihin palautumishaaroihin, kuten todennuksen pyytämiseen, tarkan kohteen löytämiseen, build-lokien lukemiseen tai vahvistuksen pyytämiseen.

Miten tiimin pitäisi aloittaa tuotantokäyttöoikeuksien myöntäminen?

Aloita vain luku -toiminnoista, salli sitten käyttöönotto yhteen matalan riskin kohteeseen ja laajenna palautettavaan konfiguraatioon ja palautumistoimiin vasta, kun agentti raportoi johdonmukaisesti todennettavaa näyttöä.