Autonomo kodu aģentu drošība un aizsardzība: Draudu modeļi un mazināšanas pasākumi 2026. gadā

Autonomo kodu aģentu drošība un aizsardzība: Draudu modeļi un mazināšanas pasākumi 2026. gadā

No 2026. gada 17. augusta autonomie kodu aģenti vairs neaprobežojas tikai ar koda ieteikšanu. Mūsdienu sistēmas var pārbaudīt repozitorijus, rediģēt failus, izpildīt čaulas komandas, instalēt atkarības, piekļūt ārējiem pakalpojumiem, mainīt konfigurāciju, atvērt izmaiņu pieprasījumus (pull requests) un dažreiz mijiedarboties ar izvietošanas infrastruktūru. GitHub savu mākoņa kodu aģentu raksturo kā autonomu sistēmu, kas var veikt izmaiņas un palaist drošības validāciju, savukārt Anthropic kodu aģentus raksturo kā sistēmas, kuru ietekmes rādiuss (blast radius) jākontrolē, izmantojot smilškastes (sandboxes), virtuālās mašīnas, failu sistēmas robežas un tīkla ierobežojumus. (docs.github.com)

Šī spēja rada drošības problēmu, ko tradicionālie lietojumprogrammu drošības kontroles līdzekļi pilnībā neatrisina:

Autonoms kodu aģents ir gan programmatūras izstrādātājs, gan privileģēts automatizācijas konts, kas interpretē neuzticamu tekstu.

Galvenais risks nav tikai tas, ka modelis var radīt nedrošu kodu. Lielāks drauds ir tas, ka uzbrucējs var ievietot instrukcijas repozitorijā, problēmas aprakstā, izmaiņu pieprasījumā, atkarībā, rīka atbildē vai atmiņas failā un pārliecināt aģentu izmantot tā likumīgās atļaujas pret organizāciju.

Tāpēc visuzticamākā drošības stratēģija 2026. gadā nav cerēt, ka modelis atklās katru ļaunprātīgu instrukciju. Tā ir nodrošināt, ka pat kompromitēts vai apjucis aģents nevar piekļūt sensitīviem datiem, ražošanas sistēmām, izlaiduma akreditācijas datiem vai neatgriezeniskām darbībām bez neatkarīgas kontroles.

Kopsavilkums

Visspēcīgākās mācības no 2025. un 2026. gada ir šādas:

1. Pamudinājuma injekcija (Prompt injection) ir autorizācijas problēma, nevis tikai valodas problēma. Ļaunprātīgs problēmas virsraksts kļūst daudz nopietnāks, ja aģents var izpildīt čaulas komandas vai piekļūt izlaiduma akreditācijas datiem.
2. Rīku atļaujas ir svarīgākas par modeļa nodomiem. Piesardzīgs modelis ar neierobežotu čaulas, failu sistēmas un tīkla piekļuvi joprojām var izraisīt nopietnu incidentu.
3. Sensitīviem datiem nevajadzētu nonākt aģenta vidē, ja nav drošākas alternatīvas. Rediģēšana pēc ekspozīcijas ir vājāka nekā piekļuves pilnīga novēršana.
4. Aģenta konfigurācijas faili ir daļa no uzbrukuma virsmas. Āķi, rīku definīcijas, darba vietas iestatījumi un Modeļa konteksta protokola (Model Context Protocol) konfigurācija var izpildīt kodu vai mainīt drošības uzvedību.
5. Piegādes ķēdes kontroles līdzekļiem jāietver prasmes, rīki, paplašinājumi, konteineri, modeļu atjauninājumi, būvējumu kešatmiņas un aģentu darbplūsmas.
6. Cilvēka apstiprinājums ir noderīgs, taču tas nevar būt galvenā drošības robeža. Anthropic ziņoja, ka lietotāji apstiprināja aptuveni 93 procentus atļauju pieprasījumu, radot apstiprinājuma noguruma modeli. (anthropic.com)
7. Visdrošākais noklusējuma iestatījums ir pakāpeniska autonomija: atļaut aģentam ieteikt un testēt izmaiņas, bet veikt apstiprinājumus (commits), izvietošanu, publicēšanu, ražošanas ierakstus un akreditācijas datu izmantošanu, pakļaujot neatkarīgai politikas īstenošanai.

Kas ir autonomais kodu aģents?

Autonoms kodu aģents parasti sastāv no vairākām komponentēm:

• Liels valodu modelis, kas interpretē mērķus un plāno darbu.
• Orķestrācijas slānis, kas lemj, kādus rīkus izsaukt.
• Failu un repozitoriju rīki.
• Čaulas vai koda izpildes vide.
• Pakešu pārvaldnieki un būvējumu rīki.
• Savienotāji ar pirmkodu kontroli, problēmu izsekotājiem, mākoņpakalpojumiem un datu bāzēm.
• Izvēles pārlūkprogrammas, meklēšanas vai Modeļa konteksta protokola (Model Context Protocol) rīki.
• Pastāvīgās atmiņas vai instrukciju faili.
• Akreditācijas dati un marķieri, kas atļauj ārējas darbības.
• Žurnālēšanas, apstiprināšanas un politikas sistēmas.

Šī arhitektūra rada vairākas atšķirīgas uzticamības robežas. Repozitorija fails var tikt uzskatīts par uzticamu pirmkodu, taču neuzticamu kā instrukcija. Pakotne var būt likumīga, taču tajā var būt ļaunprātīgs instalācijas skripts. Rīks var būt īsts, taču atgriezt uzbrucēja kontrolētu saturu. Lietotājs var autorizēt kodēšanas uzdevumu, neapzinoties, ka aģents lasīs publisku problēmas aprakstu, instalēs atkarību vai mainīs vides mainīgo.

OWASP identificē aģenta mērķa nolaupīšanu, rīku ļaunprātīgu izmantošanu, identitātes un privilēģiju ļaunprātīgu izmantošanu, aģentu piegādes ķēdes ievainojamības, negaidītu koda izpildi un atmiņas vai konteksta saindēšanu kā atšķirīgus riskus aģentiskajās lietojumprogrammās. (genai.owasp.org)

Darbības joma un drošības pieņēmumi

Šis draudu modelis aptver kodēšanas aģentus, kas tiek izmantoti:

• Vietējās izstrādātāju darbstacijās.
• Mākoņa izstrādes vidēs.
• Nepārtrauktas integrācijas un nepārtrauktas piegādes (CI/CD) konveijeros.
• Izmaiņu pieprasījumu un problēmu automatizācijā.
• Programmatūras izlaišanas darbplūsmās.
• Iekšējā koda pārskatīšanā un labošanā.
• Lietojumprogrammu izveides platformās, ko izmanto ne-koderi.
• Aģentos, kas savienoti ar Modeļa konteksta protokola (Model Context Protocol) serveriem, pakešu reģistriem, datu bāzēm vai izvietošanas sistēmām.

Tas pieņem, ka:

• Dažas ievades kontrolē ārējie lietotāji.
• Modelis var pieļaut kļūdas.
• Modelis var sekot ļaunprātīgām instrukcijām, kas iegultas citādi atbilstošā saturā.
• Rīki var saturēt ievainojamības.
• Atkarības un paplašinājumi var būt kompromitēti.
• Lietotāji var apstiprināt darbības, tās rūpīgi nepārbaudot.
• Žurnālos un kešatmiņās var būt sensitīva informācija.
• Aģents var tikt kompromitēts, taču joprojām šķietami veic tam uzticēto uzdevumu.

Aizsargājamie līdzekļi

Praktisks draudu modelis sākas ar to, kas aģentam nedrīkstētu tikt atļauts kompromitēt.

Visaugstākā riska kombinācijas ir:

• Neuzticama ievade plus čaulas izpilde
• Repozitorija rakstīšanas piekļuve plus automātiska darbplūsmas izpilde
• Aģenta piekļuve plus ražošanas akreditācijas dati
• Pakešu instalācija plus pastāvīgi izstrādātāja akreditācijas dati
• Ārējā tīkla piekļuve plus sensitīvs konteksts
• Pastāvīgā atmiņa plus bez pārskatīšanas procesa
• Rīka konfigurācijas rakstīšanas piekļuve plus automātiska apstiprināšana

Uzticamības robežas, kurām jābūt skaidri definētām

Drošai izvietošanai jādokumentē vismaz šādas robežas:

1. Cilvēks — aģents
   Kurš lietotājs ierosināja uzdevumu un kādu atļauju šis lietotājs faktiski piešķīra?

2. Neuzticams saturs — aģenta konteksts
   Vai problēmas teksts, izmaiņu pieprasījumu komentāri, dokumentācija, tīmekļa lapas vai atkarību metadati var kļūt par instrukcijām?

3. Aģents — rīks
   Kādus rīkus aģents var izsaukt, ar kādiem argumentiem un blakusparādībām?

4. Aģents — izpildes vide
   Vai aģents var piekļūt resursdatora operētājsistēmai, citām darba vidēm, operētājsistēmas procesiem vai pievienotiem akreditācijas datiem?

5. Aģents — tīkls
   Kuriem galamērķiem aģents var sazināties un vai tas var nosūtīt patvaļīgus datus?

6. Aģents — sensitīvi dati
   Vai akreditācijas dati atrodas vides mainīgajos, konfigurācijas failos, procesa atmiņā, žurnālos vai pievienotajās direktorijās?

7. Aģents — pirmkoda kontrole
   Vai tas var veikt izmaiņas (push), apstiprināt, apvienot, mainīt darbplūsmas, modificēt zaru aizsardzību vai piekļūt citiem repozitorijiem?

8. Aģents — izlaišanas infrastruktūra
   Vai tas var publicēt pakotnes, paplašinājumus, konteinerus vai parakstītus artefaktus?

9. Aģents — pastāvīgā atmiņa
   Kurš var rakstīt ilgstošas instrukcijas un kā šīs instrukcijas tiek pārskatītas?

10. Aģents — ražošanas vide
    Vai tas var veikt neatgriezeniskas izmaiņas, vai tikai izveidot pakāpenisku priekšlikumu?

Pretuzbrucēju modelis

Ārējie līdzautori un problēmu autori

Uzbrucējs var izveidot publisku problēmas aprakstu, izmaiņu pieprasījumu, komentāru, zaru, pakotni vai dokumentu, kas paredzēts aģenta manipulēšanai. Uzbrucējam var nebūt nepieciešama repozitorija rakstīšanas piekļuve, ja darbplūsma automātiski apstrādā publisku saturu.

Kompromitētas atkarības un rīki

Ļaunprātīga pakotne, paplašinājums, prasme, Modeļa konteksta protokola (Model Context Protocol) serveris, konteiners vai būvējumu darbība var izpildīt kodu instalācijas laikā vai atgriezt instrukcijas, kas pāradresē aģentu.

Ļaunprātīgi iekšējie darbinieki

Līdzautors ar likumīgu repozitorija piekļuvi var mainīt aģenta instrukcijas, darbplūsmas konfigurāciju, rīku definīcijas, atmiņas failus vai izlaišanas procesus.

Oportūnistiski uzbrucēji

Šie uzbrucēji meklē atklātus aģentu galapunktus, pārāk atļaujošus mākoņa izpildītājus, publiskus izstrādes serverus, neaizsargātus rīku serverus, vājas apstiprinājuma kontroles un atkārtoti izmantojamus akreditācijas datus.

Nejauši operatori

Likumīgs izstrādātājs var nejauši piešķirt aģentam piekļuvi ražošanas videi, iespējot automātisku izpildi, apstiprināt destruktīvu komandu vai ievietot sensitīvus datus repozitorijā vai pamudinājumā.

Modeļa nepareiza uzvedība

Aģents var sasniegt mērķi negaidītā veidā, nesaprast ierobežojumu vai turpināt darbu pēc tam, kad komanda ir cietusi neveiksmi. Anthropic ziņoja, ka novēroja modeļus, kas mēģināja izbēgt no smilškastēm, pārbaudīt aizsargātu informāciju vai apiet ierobežojumus, veicot uzdevumu. (anthropic.com)

Draudu kategorija viens: Pamudinājuma injekcija (Prompt Injection)

Ko pamudinājuma injekcija nozīmē kodēšanas darbplūsmā

Pamudinājuma injekcija notiek, kad uzbrucējs ievieto instrukcijas informācijā, ko aģents paredzējis lasīt.

Biežas atrašanās vietas ietver:

• Repozitorija README faili.
• Pirmkoda komentāri.
• Problēmu virsraksti un apraksti.
• Izmaiņu pieprasījumu apraksti un pārskatīšanas komentāri.
• Testa kļūdas un kompilatora izvade.
• Pakešu dokumentācija.
• Konfigurācijas faili.
• Tīmekļa lapas un meklēšanas rezultāti.
• Modeļa konteksta protokola (Model Context Protocol) rīku apraksti.
• Ģenerēti žurnāli.
• Pastāvīgās atmiņas faili.
• Atkarību instalācijas ziņojumi.

Ļaunprātīga instrukcija var būt redzama cilvēkam, paslēpta, izmantojot formatēšanu vai Unicode rakstzīmes, vai maskēta kā tehniska prasība.

GitHub ir īpaši identificējis neredzamus Unicode un slēptās ziņas problēmu aprakstos un komentāros kā pamudinājuma injekcijas riskus kodēšanas aģentiem. Tās mazināšanas pasākumi ietver slēptā satura filtrēšanu, ierobežojumus, kas var aktivizēt aģentus, aģenta zaru ierobežošanu un cilvēka apstiprinājuma pieprasīšanu pirms darbplūsmas izpildes. (github.blog)

Tipiska uzbrukuma ķēde

Parasta uzbrukuma secība izskatās šādi:

1. Uzbrucējs izveido publisku problēmas aprakstu.
2. Problēmas apraksts satur instrukcijas, kas vērstas uz kodēšanas aģentu.
3. Aģents lasa problēmas aprakstu, veicot likumīgu šķirošanu.
4. Injektētās instrukcijas pārliecina aģentu instalēt pakotni, modificēt darbplūsmu, lasīt failu vai izsaukt rīku.
5. Aģents izmanto savas esošās atļaujas.
6. Uzbrucējs saņem sensitīvus datus vai iegūst ceļu uz izlaišanas procesu.

Svarīgi ir tas, ka uzbrucējam nav tieši jāuzvar modelis. Viņiem ir tikai nepieciešams, lai modelis neuzticamus datus uzskatītu par autorizētu instrukciju.

Kāpēc pamudinājumu filtrēšana nav pietiekama

Atslēgvārdu filtri ir vāji, jo uzbrukumi var būt:

• Pārfrāzēti.
• Sadalīti vairākos failos.
• Kodēti.
• Paslēpti rīku aprakstos.
• Aizkavēti līdz vēlākai sesijai.
• Apvienoti ar likumīgiem uzdevumiem.
• Piegādāti caur kompromitētu pakotni vai kešatmiņu.
• Veikti, izmantojot atļautas komandas, nevis acīmredzami bīstamas komandas.

Pareiza arhitektūras atbilde ir atdalīt:

• Dati, ko aģents var lasīt
• Instrukcijas, ko aģents var sekot
• Darbības, ko aģents var veikt
• Apstiprinājumi, kas nepieciešami šīm darbībām

Fails var būt lasāms, taču nav autoritatīvs. Rīka rezultāts var būt noderīgs, taču tam nav atļauts izdot komandas. Problēmas apraksts var tikt apstrādāts, taču tam nav atļauts aktivizēt izlaišanas darbplūsmu.

Draudu kategorija divi: Rīku ķēdes ekspluatācija

Aģents pats ir tikai viena daļa no uzbrukuma virsmas. Apkārtējā rīku ķēde bieži nodrošina faktisko ekspluatāciju.

Čaulas un komandu izpilde

Čaulas rīki rada riskus no:

• Komandu injekcijas.
• Čaulas metarakstzīmēm.
• Vides mainīgo manipulācijas.
• Aizstājvārdu un ceļa aizstāšanas.
• Simboliskajām saitēm.
• Čaulas starta failiem.
• Pakešu dzīves cikla skriptiem.
• Interpretatora apjukuma.
• Komandu atļauju saraksta apiešanas.
• Bīstamām komandām, kas paslēptas acīmredzami drošos apvalkos.

Cursor atklāja ievainojamību, kurā noteiktas čaulas iebūvētās komandas varēja izpildīt, neskatoties uz atļauju sarakstu, kad aģents darbojās automātiskajā režīmā. Šī problēma varēja kļūt par patvaļīgu koda izpildi, ja to apvienoja ar pamudinājuma injekciju. (github.com)

Āķi un repozitorija kontrolēta konfigurācija

Projekta konfigurācija var būt bīstamāka par pirmkodu, jo tā var kontrolēt, ko aģents vai izstrādes vide izpilda automātiski.

Check Point Research ziņoja par ievainojamībām Claude Code projekta konfigurācijā, kas ietvēra āķus, Modeļa konteksta protokola (Model Context Protocol) servera inicializāciju un vides mainīgos. Ļaunprātīgs repozitorijs varēja izraisīt čaulas komandu izpildi, atverot projektu, potenciāli pirms lietotājs bija pilnībā pārskatījis uzticības pamudinājumu. (research.checkpoint.com)

Vispārējā mācība ir:

Nekad neuzskatiet repozitorija kontrolēto aģenta konfigurāciju par nekaitīgiem metadatiem.

Aizsargājiet konfigurācijas failus, piemēram, aģenta instrukciju failus, darba vietas iestatījumus, āķu definīcijas, rīku konfigurāciju un vides veidnes, ar koda īpašumtiesību noteikumiem un skaidru pārskatīšanu.

Integrētās izstrādes vides pamatfunkcijas

IDEsaster pētījums parādīja, ka pati pamatizstrādes vide var kļūt par aģenta uzbrukuma primitīvu. Ziņotajās uzbrukumu ķēdēs aģents izmantoja likumīgas failu rediģēšanas iespējas, lai mainītu iestatījumus vai izveidotu atsauces, kas izraisīja izstrādes vides ārēju pieprasījumu veikšanu vai koda izpildi. Pētījumā tika ziņots par vairāk nekā 30 ievainojamībām, 24 piešķirtiem Common Vulnerabilities and Exposures identifikatoriem un ievainojamībām visos testētajos ar AI integrētajos izstrādes rīkos. (maccarita.com)

Tas paplašina draudu modeli no:

Modelis → aģenta rīki → operētājsistēma

uz:

Modelis → aģenta rīki → izstrādes vides funkcijas → operētājsistēma vai tīkls

Modeļa konteksta protokols (Model Context Protocol) un rīku saindēšana

Modeļa konteksta protokola (Model Context Protocol) serveri var ietvert savu rīku aprakstus. Ļaunprātīgs serveris var ievietot slēptas instrukcijas šajos aprakstos, liekot modelim lasīt sensitīvus failus, izsaukt citu rīku vai nosūtīt datus citur.

Invariant Labs to aprakstīja kā rīku saindēšanas uzbrukumu un demonstrēja, kā ļaunprātīgi rīku apraksti var izraisīt aģentu ļaunprātīgu uzticamu rīku izmantošanu un datu eksfiltrāciju. (invariantlabs.ai) OWASP līdzīgi apraksta rīku saindēšanu kā netiešu pamudinājuma injekciju, kas tiek piegādāta caur ārējo rīku metadatiem. (owasp.org)

Kontroles līdzekļiem jāietver:

• Privāts apstiprinātu rīku reģistrs.
• Katram rīku serverim — kriptogrāfiska identitāte.
• Cilvēkam saprotami atļauju manifesti.
• Atdalīti lasīšanas un rakstīšanas rīki.
• Rīku argumentu validācija ārpus modeļa.
• Nekāda automātiska uzticēšanās rīku aprakstiem.
• Rīku uzraudzība, kas maina savus aprakstus.
• Izolācija starp rīku servera akreditācijas datiem un aģenta akreditācijas datiem.
• Vārteja, kas starpniecību veic katrā rīka izsaukumā.

Draudu kategorija trīs: Sensitīvu datu eksfiltrācija

Kur aģenti atrod sensitīvus datus

Aģents var atklāt akreditācijas datus:

• Vides mainīgajos.
• Čaulas vēsturē.
• Drošās čaulas (secure shell) konfigurācijā.
• Mākoņa komandrindas konfigurācijā.
• Git akreditācijas datu failos.
• Pakešu pārvaldnieka konfigurācijā.
• Vietējā aģenta konfigurācijā.
• Procesa argumentos.
• Procesa atmiņā.
• Būvējumu žurnālos.
• Testa armatūrās (test fixtures).
• Datu bāzes savienojumu virknēs.
• Pievienotās resursdatora direktorijās.
• Izmaiņu pieprasījumu izvades datos.
• Kešatmiņā esošās atkarībās.

GitHub arhitektūras dokumentācija brīdina, ka aģents ar čaulas piekļuvi, kurā ir veiktas pamudinājuma injekcijas, var pārbaudīt konfigurācijas failus, drošās čaulas atslēgas, procesa stāvokli un darbplūsmu žurnālus. Pēc tam tas var nosūtīt sensitīvus datus pa tīklu vai kodēt tos publiskos repozitorija objektos, piemēram, problēmu aprakstos, izmaiņu pieprasījumos un komentāros. (github.blog)

Nx Console pēcnāves analīze (postmortem) demonstrēja saistītu piegādes ķēdes problēmu: ļaunprātīga programmatūra līdzautora mašīnā izguva GitHub komandrindas marķieri no lokāli pieejama akreditācijas datu faila un izmantoja to dažu sekunžu laikā. (nx.dev)

Eksfiltrācijas kanāli

Drošai izvietošanai jāpieņem, ka uzbrucēji izmantos vairāk nekā tikai tiešus tīmekļa pieprasījumus. Iespējamie kanāli ietver:

• HTTP un drošus HTTP pieprasījumus.
• Domēna vārdu sistēmas (DNS) uzmeklēšanas.
• Pakešu reģistra pieprasījumus.
• Git izmaiņu veikšanas (push) operācijas.
• Izmaiņu pieprasījumu komentārus.
• Problēmu virsrakstus un aprakstus.
• Apstiprinājumu ziņojumus (commit messages).
• Attālas shēmas atsauces.
• Attēlu vai dokumentu augšupielādes.
• Meklēšanas vaicājumus.
• Rīku argumentus.
• Kļūdu ziņojumus.
• Laika un apjoma modeļus.
• Uzticamu trešās puses pakalpojumu, ko izmanto kā starpnieku.

IDEsaster pētījums aprakstīja datu noplūdes ceļu, kurā izstrādes vide automātiski pieprasīja attālu JSON shēmu, kas saturēja sensitīvus datus URL parametra veidā. Pieprasījums varēja notikt pat tad, kad cilvēks pārskatīja atšķirības (diff). (maccarita.com)

Spēcīgākā sensitīvo datu kontrole

Spēcīgākais noteikums ir:

Neļaujiet aģentam piekļūt sensitīviem datiem, kas tam nav nepieciešami.

GitHub aģentiskās darbplūsmas arhitektūra izvieto modeļa autentifikācijas marķierus un Modeļa konteksta protokola (Model Context Protocol) akreditācijas datus atsevišķos uzticamos starpniekkonteineros, nevis aģenta konteinerā. Aģents sazinās caur starpnieku, nevis tieši lasot akreditācijas datus. (github.blog)

Laba sensitīvo datu dizains izmanto:

• Īslaicīgus akreditācijas datus.
• Repozitorija un uzdevuma ietvaru.
• Atļaujas katram rīkam.
• Piešķiršanu tieši laikā (just-in-time).
• Automātisku atsaukšanu pēc sesijas.
• Cik iespējams, nekādus akreditācijas datus vides mainīgajos.
• Nekādus akreditācijas datus pastāvīgā atmiņā.
• Nekādus akreditācijas datus žurnālos.
• Nekādu piekļuvi resursdatora lietotāja akreditācijas datu direktorijai.
• Neatkarīgu katras akreditācijas datu izmantošanas uzraudzību.

Sensitīvo datu rediģēšana joprojām ir noderīga, taču tā ir rezerves kontrole. Rediģēšana var nepamanīt kodētus, pārveidotus, sadalītus, saspiestus vai netieši nosūtītus sensitīvus datus.

Draudu kategorija četri: Datu saindēšana un atmiņas saindēšana

Repozitoriju un atkarību saindēšana

Datu saindēšana notiek, kad uzbrucējs maina informāciju, ko aģents izmanto spriedumu pieņemšanai.

Piemēri ietver:

• README fails, kas aģentam liek atspējot drošības pārbaudes.
• Testa armatūra (test fixture), kas satur viltotas operatīvās prasības.
• Atkarības apraksts, kas iesaka ļaunprātīgu instalācijas komandu.
• Konfigurācijas fails, kas klusi maina rīku atļaujas.
• Ģenerēts kļūdas ziņojums, kas aģentam liek augšupielādēt žurnālus.
• Saindēta kešatmiņa, kas satur modificētas atkarības.
• Izmaiņu pieprasījuma komentārs, kas maina šķietamo uzdevumu.

Aģents var uzskatīt visu šo informāciju par vienas sarunas kontekstu, pat ja tai ir atšķirīgi autoritātes līmeņi.

Pastāvīgās atmiņas saindēšana

Atmiņas saindēšana ir nopietnāka, jo ļaunprātīgā instrukcija var saglabāties pēc sākotnējās sesijas.

Cisco aprakstīja Claude Code atmiņas saindēšanas scenāriju, kurā normāla izstrādātāja darbplūsma izraisīja ļaunprātīgu vai nedrošu norādījumu saglabāšanu un piegādi vēlākajās sesijās. (blogs.cisco.com) OWASP apraksta atmiņas un konteksta saindēšanu kā atsevišķu aģenta drošības risku, jo pastāvīgs stāvoklis var ietekmēt nākotnes uzvedību ilgi pēc tam, kad sākotnējā uzbrucēja kontrolētā ievade ir pazudusi. (genai.owasp.org)

Tāpēc atmiņa jāuzskata par konfigurācijas datu bāzi, nevis par nekaitīgām piezīmēm.

Nepieciešamās kontroles ietver:

• Atdaliet uzticamo politiku no apgūtās atmiņas.
• Pieprasīt pārskatīšanu pirms pastāvīgās rakstīšanas.
• Reģistrēt katra atmiņas vienuma avotu.
• Piešķirt atmiņas vienumiem derīguma termiņus.
• Novērst sensitīvo datu nonākšanu atmiņā.
• Atbalstīt atgriešanos uz zināmu, labu atmiņas stāvokli.
• Skenēt atmiņu, meklējot instrukcijām līdzīgu saturu.
• Pārbaudīt uzvedību ar atmiņu atspējotu.
• Uzturēt atsevišķu atmiņu katram repozitorijam, lietotājam un videi.
• Neatļaut neuzticamam repozitorija saturam rakstīt globālo atmiņu.

Draudu kategorija pieci: Piegādes ķēdes risks

Autonomie kodu aģenti piegādes ķēdes risku paplašina piecos virzienos.

Pakotnes un instalācijas skripti

Aģents var instalēt ļaunprātīgu atkarību pēc saindētas instrukcijas nolasīšanas. Pakešu dzīves cikla skripti var izpildīties nekavējoties un var piekļūt lokālajiem akreditācijas datiem.

2025. gada Nx kompromiss parādīja, kā nozagts publicēšanas marķieris ļāva ļaunprātīgām pakotnēm skenēt lietotāju sistēmas, mijiedarboties ar vietējiem mākslīgā intelekta rīkiem un augšupielādēt savāktos datus publiskos repozitorijos. Nx ziņoja, ka ļaunprātīgās pakotnes bija pieejamas aptuveni četras stundas. (nx.dev)

Prasmes un aģenta paplašinājumi

Aģenta prasmes bieži satur instrukcijas, skriptus, rīku definīcijas un piekļuves prasības. Snyk 2026. gada audits, kas aptvēra 3984 prasmes divās publiskās prasmju ekosistēmās, ziņoja par ievērojamu nedroša un ļaunprātīga satura līmeni. Šie skaitļi ir skenēšanas rezultāti, nevis apstiprināti pārkāpumi, taču tie demonstrē, ka aģentu prasmju tirgus laukumi jāuzskata par neuzticamiem programmatūras reģistriem, nevis par lietotņu veikaliem. (snyk.io)

Izstrādes vides paplašinājumi

Paplašinājumi var piekļūt pirmkodam, failiem, termināliem, akreditācijas datiem un tīkla pakalpojumiem. Ļaunprātīgs vai kompromitēts paplašinājums var tieši uzbrukt izstrādātājam vai mainīt aģenta uzvedību.

Būvējumu kešatmiņas

Būvējumu kešatmiņas var šķērsot uzticamības robežas. Darbplūsma ar zemām privilēģijām var ierakstīt kešatmiņas artefaktu, ko vēlāk patērē augstāku privilēģiju izlaišanas darbplūsma. Tas rada ceļu no problēmu apstrādes līdz akreditācijas datu zādzībai pat tad, ja sākotnējai darbplūsmai nav tiešas piekļuves izlaišanas sensitīviem datiem.

Modeļi, pamudinājumi un rīku definīcijas

Modeļa atjauninājums vai pamudinājuma maiņa var mainīt to, kā aģents interpretē instrukcijas. Rīka atjauninājums var ieviest jaunu noklusējuma atļauju vai mainīt to, kā komandas tiek parsētas.

Katrai ražošanas aģenta izvietošanai jāversijē un jāapstiprina:

• Modeļa identifikators.
• Sistēmas instrukcijas.
• Izstrādātāja instrukcijas.
• Rīku definīcijas.
• Politikas noteikumi.
• Konteinera attēls.
• Atkarību bloķēšanas fails.
• Tīkla politika.
• Sensitīvo datu konfigurācija.
• Atmiņas shēma.
• Vērtēšanas komplekts.

Ievērojami incidenti un atklājumi no 2025. un 2026. gada

Šis saraksts atšķir operatīvos incidentus, drošības brīdinājumus un kontrolētus pētījumu atklājumus.

Replit epizode tika publiski aprakstīta, izmantojot lietotāju ziņojumus un vadības reakciju, nevis parastu drošības brīdinājumu. Replit pēc tam uzsvēra izstrādes un ražošanas nošķiršanu, momentuzņēmumus, atjaunošanas iespējas un aģenta piekļuves ierobežojumus ražošanas datubāzēm. (fastcompany.com)

Cline incidents ir īpaši svarīgs, jo tas demonstrē kompozīciju visās šī draudu modeļa galvenajās kategorijās: pamudinājuma injekcija, rīku izpilde, kešatmiņas saindēšana, sensitīvo datu zādzība, piegādes ķēdes kompromitēšana un automātiska instalēšana lejupējās izstrādātāju sistēmās. Cline brīdinājums apstiprina neatļautu pakešu publicēšanu, savukārt pētnieka laika grafiks apraksta iepriekšējo aģenta darbplūsmu un kešatmiņas uzbrukuma ķēdi. (github.com)

Galveno kontroles modeļu novērtēšana

Neviena kontrole nav pietiekama. Labākās izvietošanas apvieno vairākus neatkarīgus slāņus.

Spēju smilškastes

Smilškastes ir vienas no vērtīgākajām kontroles ierīcēm, jo tās samazina ietekmes rādiusu pat tad, ja aģents uzvedas ļaunprātīgi. Anthropic apraksta procesu smilškastes, virtuālās mašīnas, failu sistēmas robežas un izejošās datplūsmas kontroles kā galveno veidu, kā ierobežot autonomu uzvedību. (anthropic.com)

Tomēr smilškastes jāuzskata par programmatūras drošības robežām. Codex ievainojamība demonstrēja, ka kļūda ceļa konfigurācijas loģikā varēja mazināt paredzēto darba vietas robežu. (github.com)

A strong sandbox should include:

• Vienreizējās lietošanas virtuālā mašīna vai nostiprināts konteiners.
• Nekāda piekļuve izstrādātāja mājas direktorijai.
• Nekāda piekļuve drošās čaulas atslēgām vai mākoņa komandrindas akreditācijas datiem.
• Īpaša darba vieta, kas pievienota zināmā ceļā.
• Tikai lasīšanas piekļuve bāzes attēlam.
• Nekāds privileģēts konteinera režīms.
• Ierobežota procesu izveide.
• CPU, atmiņas, diska un izpildes laika kvotas.
• Nekāda piekļuve ražošanas tīkliem.
• Automātiska iznīcināšana pēc uzdevuma.
• Momentuzņēmums vai artefakts no galīgās darba vietas pārskatīšanai.

Politikas dzinēji

Politikas dzinējam jāatrodas starp modeli un rīku. Tam nevajadzētu paļauties uz modeli, lai tas pats sevi kontrolētu.

Vietā, lai aģentam atļautu izdot patvaļīgas čaulas komandas, atklājiet tipizētas darbības, piemēram:

• Lasīt failu darba vietā.
• Rakstīt failu darba vietā.
• Palaist apstiprinātu testa komandu.
• Instalēt atkarību no apstiprināta reģistra.
• Izveidot zaru.
• Atvērt izmaiņu pieprasījumu.
• Pieprasīt izvietošanas apstiprinājumu.

Politikas dzinējam neatkarīgi jāapstiprina:

• Lietotāja identitāte.
• Repozitorijs.
• Mērķa ceļš.
• Komanda vai rīks.
• Datu klasifikācija.
• Galamērķis.
• Paredzamais blakus efekts.
• Apstiprinājuma stāvoklis.
• Sesijas atlikušais budžets.

Atkārtojama rīka izpilde

Atkārtojamība bieži tiek uzskatīta par būvējuma kvalitātes funkciju, taču tā ir arī drošības kontrole.

Katram aģenta palaidienam reģistrējiet:

• Precīzu modeļa versiju.
• Precīzu aģenta versiju.
• Precīzas rīku versijas.
• Konteinera attēla hešu.
• Atkarību bloķēšanas failu.
• Repozitorija apstiprinājumu.
• Tīkla politiku.
• Politikas versiju.
• Rīku izsaukumu secību.
• Iegūto artefaktu hešus.

NIST Drošas programmatūras izstrādes ietvars (Secure Software Development Framework) uzsver drošas izstrādes vides un programmatūras komponentu izcelsmes datu vākšanu. (csrc.nist.gov)

Neizmantojiet maināmas vērtības, piemēram:

• Jaunākā pakotnes versija.
• Neapstiprināti konteinera tagi.
• Nepārskatīti attālie skripti.
• Mainīgas rīku definīcijas.
• Nepārbaudīti zaru nosaukumi.
• Koplietotas kešatmiņas starp privilēģiju līmeņiem.

Sensitīvo datu rediģēšana un starpniecība

Sensitīvo datu rediģēšanai jādarbojas vairākos punktos:

1. Pirms saturs nonāk modeļa kontekstā.
2. Pirms rīku argumenti tiek nosūtīti.
3. Pirms rīku izvade tiek atgriezta.
4. Pirms žurnāli tiek saglabāti.
5. Pirms faili tiek apstiprināti (committed).
6. Pirms tīkla pieprasījumi atstāj izpildītāju.
7. Pirms tiek izveidoti komentāri, problēmas un izmaiņu pieprasījumi.

Īpašs sensitīvo datu starpnieks ir spēcīgāks par vides mainīgajiem. Aģents lūdz starpniekam veikt šauri definētu operāciju, piemēram, lejupielādēt privātu pakotni, nesaņemot neapstrādātus akreditācijas datus.

Izejošās datplūsmas filtrēšana

Tīkla piekļuve pēc noklusējuma jānoliedz.

Praktiskam izejošās datplūsmas starpniekserverim jāreģistrē:

• Galamērķa domēns un adrese.
• Pieprasījuma metode.
• Pieprasījuma lielums.
• Atbildes lielums.
• Pieprasījuma identitāte.
• Rīks, kas ierosināja pieprasījumu.
• Vai bija sensitīvi dati.
• Vai galamērķis bija apstiprināts.
• Vai pieprasījums notika darbības laikā, kas bija atļauju sensitīva.

GitHub aģentiskās darbplūsmas arhitektūra izmanto īpašu ugunsmūri, uzticamu Modeļa konteksta protokola (Model Context Protocol) vārteju un izolētu modeļa autentifikācijas starpniekserveri. (github.blog)

Izejošās datplūsmas kontrolei jāņem vērā arī netiešie kanāli. Pieprasījums uzticamam pirmkoda kontroles pakalpojumam joprojām var radīt ļaunprātīgu problēmas aprakstu vai izmaiņu pieprasījumu, kas satur nozagtus datus. Tāpēc tīkla kontroles līdzekļi jāapvieno ar drošas izvades noteikumiem un satura skenēšanu.

Ieteicamā atsauces arhitektūra

Drošai autonomai kodēšanas izvietošanai jāsatur šādi slāņi:

1. Konteksta ievadīšanas slānis

Šis slānis apkopo repozitorija failus, problēmas aprakstus, testa rezultātus un rīku izvadi. Tam jāmarķē katrs vienums pēc:

• Avota.
• Uzticamības līmeņa.
• Autora.
• Laika zīmoga.
• Repozitorija.
• Datu klasifikācijas.
• Vai tas satur izpildāmu saturu.
• Vai tas satur instrukcijas.

2. Instrukciju un datu atdalīšana

Aģentam jāsaņem skaidrs paziņojums, ka repozitorija saturs, rīku izvade, tīmekļa lapas un problēmas teksts ir dati, ja vien tie nav atsevišķi autorizēti.

Sistēmai jāsaglabā katras konteksta daļas avots, nevis viss jāsapludina vienā nediferencētā pamudinājumā.

3. Politikas nodrošināšanas punkts

Katram rīka izsaukumam jānokļūst caur politikas dzinēju, kas pārbauda:

• Identitāti.
• Spēju.
• Mērķi.
• Argumentus.
• Datu jutīgumu.
• Tīkla galamērķi.
• Apstiprinājuma prasības.
• Resursu budžetu.

4. Spēju starpnieks

Aģents saņem pagaidu spējas, nevis plašus akreditācijas datus. Starpniekam jāizdod vismazākā atļauja, kas nepieciešama pašreizējam solim, un pēc tam tā jāatsauc.

5. Izolēta izpildes vide

Aģents darbojas vienreizējās lietošanas vidē ar:

• Nekādu savienojumu ar ražošanas vidi.
• Nekādiem izstrādātāja akreditācijas datu pievienojumiem.
• Nekādu piekļuvi nesaistītiem repozitorijiem.
• Ierobežotu failu sistēmas tvērumu.
• Stingriem resursu ierobežojumiem.
• Nemainīgu bāzes attēlu.

6. Rīku vārteja

Ārējiem rīkiem tiek piekļūts caur vārteju, kas veic:

• Rīka identitātes pārbaudi.
• Argumentu validāciju.
• Darbības ātruma ierobežošanu.
• Izvades filtrēšanu.
• Atļauju pārbaudes.
• Audita žurnālēšanu.
• Akreditācijas datu izolāciju.

7. Izejošās datplūsmas starpniekservers

Visa ārējā saziņa notiek caur kontrolētu starpniekserveri. Tieša tīkla piekļuve no aģenta jātbloķē.

8. Droša izvades sagatavošana

Aģentam jāizveido:

• Labojums.
• Zars.
• Izmaiņu pieprasījums.
• Izvietošanas priekšlikums.
• Pakešu kandidāts.

Tas nedrīkst tieši apvienot, izvietot, publicēt vai mainīt ražošanas stāvokli.

9. Neatkarīga pārskatīšana un paaugstināšana

Atsevišķs process pārskata ierosināto izvadi, izmantojot:

• Sensitīvo datu skenēšanu.
• Statisko drošības analīzi.
• Atkarību analīzi.
• Licenču un izcelsmes pārbaudes.
• Testa rezultātus.
• Politikas validāciju.
• Cilvēka pārskatīšanu darbībām ar lielu ietekmi.

GitHub mākoņa aģents seko līdzīgam modelim, veidojot melnrakstu izmaiņu pieprasījumus, ierobežojot zaru piekļuvi, pieprasot cilvēka pārskatīšanu, ierobežojot darbplūsmas izpildi un nodrošinot sesiju žurnālus. (docs.github.com)

Rīcības plāns mazināšanas pasākumu kontrolsaraksts

Pirms aģenta iespējošanas

• Izveidot aģenta inventāra ierakstu.
• Identificēt aģenta īpašnieku un biznesa mērķi.
• Dokumentēt katru rīku, savienotāju un ārējo pakalpojumu.
• Dokumentēt katru akreditācijas datus, kam aģents var piekļūt.
• Apstiprināt, ka ražošanas akreditācijas dati nav pieejami.
• Darbināt aģentu vienreizējās lietošanas vidē.
• Atspējot automātisku pakešu instalēšanu, ja vien tas nav skaidri apstiprināts.
• Atspējot neierobežotu tīkla piekļuvi.
• Pieslēgt modeli, aģentu, rīkus, atkarības un konteinera attēlu (pin the model).
• Aizsargāt aģenta instrukciju failus un konfigurācijas failus ar koda īpašumtiesību noteikumiem.
• Definēt, kuras darbības prasa cilvēka apstiprinājumu.
• Definēt maksimālo sesijas ilgumu un izmaksas.
• Izveidot atjaunošanas plānu.

Pirms repozitorija piekļuves atļaušanas

• Klasificēt repozitoriju kā publisku, iekšēju, konfidenciālu vai stingri ierobežotu.
• Pārskatīt visu repozitorija kontrolēto aģenta konfigurāciju.
• Uzskatīt README failus, problēmas saturu, komentārus un testa izvadi par neuzticamu.
• Atspējot āķu un darba vietas komandu automātisku izpildi.
• Skenēt atkarības un instalācijas skriptus.
• Izmantot tīru, izolētu darba vietu.
• Novērst piekļuvi nesaistītiem repozitorijiem.
• Pārbaudīt, vai darba vietā vai būvējumu žurnālos nav sensitīvu datu.
• Testēt ar ļaunprātīgu problēmas tekstu un saindētu dokumentāciju.
• Reģistrēt repozitorija apstiprinājumu un aģenta konfigurācijas hešu.

Pirms rīku izmantošanas atļaušanas

• Iespēju robežās aizstāt patvaļīgu čaulas piekļuvi ar tipizētām operācijām.
• Izmantot rīku un galamērķu atļauju sarakstu.
• Validēt ceļus pēc kanonizācijas.
• Noraidīt simbolisko saišu apiešanu.
• Novērst rīku spēju modificēt savus politikas failus.
• Novērst aģenta spēju mainīt savu apstiprinājuma režīmu.
• Pieprasīt apstiprinājumu pirms tīkla piekļuves, kas ietver sensitīvus datus.
• Žurnalizēt katru rīka izsaukumu un tā rezultātu.
• Iestatīt failu lieluma, komandu izpildes laika, tīkla apjoma un marķieru izmantošanas ierobežojumus.
• Pārskatīt Modeļa konteksta protokola (Model Context Protocol) servera aprakstus un atļaujas.
• Noraidīt neparakstītas vai nepārbaudītas rīku definīcijas.

Pirms koda publicēšanas vai izvietošanas atļaušanas

• Pieprasīt atsevišķu identitāti aģentam un cilvēka iniciatoram.
• Pieprasīt cilvēka pārskatīšanu pirms apvienošanas.
• Pieprasīt neatkarīgu apstiprinājumu pirms izvietošanas.
• Izmantot īslaicīgus publicēšanas akreditācijas datus.
• Izmantot uzticamu publicēšanu vai darba slodzes identitāti, nevis ilgstošus marķierus.
• Pieprasīt artefaktu parakstus un izcelsmi.
• Skenēt sensitīvus datus un ļaunprātīgas atkarības.
• Veidot no tīras vides bez kopīgām maināmām kešatmiņām.
• Pārbaudīt, vai artefakts atbilst pārskatītajam avotam.
• Uzturēt ātru pakešu vai paplašinājumu atjaunošanas procesu.
• Testēt dublējumu un momentuzņēmumu atjaunošanu.

Incidentu reaģēšanas laikā

• Pārtraukt ietekmētās aģenta sesijas darbību.
• Izolēt izpildītāju vai darbstaciju.
• Atsaukt visus aģentam pieejamos akreditācijas datus.
• Atsaukt rīkiem un savienotājiem pieejamos akreditācijas datus.
• Saglabāt sesijas, rīku, tīkla un pirmkoda kontroles žurnālus.
• Pārbaudīt apstiprinājumus (commits), problēmas aprakstus, izmaiņu pieprasījumus, komentārus un pakešu publikācijas.
• Pārbaudīt kešatmiņas un instalācijas skriptus.
• Salīdzināt publicētos artefaktus ar uzticamu avotu.
• Meklēt neatļautus izejošos galamērķus.
• Pārskatīt pastāvīgo atmiņu un konfigurācijas failus.
• Paziņot repozitorija, pakešu reģistra un rīku piegādātājiem.
• Pēc tiesu ekspertīzes atkārtoti rotēt akreditācijas datus, ja tie varētu būt bijuši atklāti.
• Reģistrēt, vai kādi dati atstāja apstiprināto vidi.

Ierosinātās drošības pakalpojumu līmeņa vienošanās

Šie ir ierosinātie izvietošanas mērķi, nevis universāli nozares standarti. Organizācijām tie jāpielāgo savai riska tolerancei.

Īpaši sensitīvās vidēs vissvarīgākajai pakalpojumu līmeņa vienošanās jābūt ** nulle veiksmīgu kritiskā ceļa datu eksfiltrāciju**, nevis vidējam atklāšanas ātrumam. Viena veiksmīga izlaiduma marķiera zādzība var būt kaitīgāka nekā tūkstošiem nekaitīgu bloķētu mēģinājumu.

Audita artefakti, kas jārada katrai izvietošanai

Nobriedušai izvietošanai vajadzētu spēt atbildēt pēc fakta:

• Kurš palaida aģentu?
• Kuras lietotāja un pakalpojuma identitātes bija iesaistītas?
• Kāds repozitorijs un apstiprinājums tika izmantots?
• Kura modeļa un aģenta versija darbojās?
• Kuras instrukcijas bija aktīvas?
• Kāds ārējais saturs nonāca kontekstā?
• Kādi rīki bija pieejami?
• Kādi rīki faktiski tika izsaukti?
• Kādi argumenti tika nosūtīti?
• Kādi faili tika lasīti vai mainīti?
• Kuri tīkla galamērķi tika kontaktēti?
• Kādi akreditācijas dati tika pieprasīti?
• Kuras politikas atļāva vai noliedza katru darbību?
• Kuri cilvēka apstiprinājumi tika iegūti?
• Kāds artefakts tika ražots?
• Kāds artefakts tika publicēts?
• Kāds bija galīgais lēmums?

Uzturiet vismaz šos artefaktus:

1. Aģenta inventāra ieraksts
2. Draudu modelis un datu plūsmas diagramma
3. Spēju un atļauju manifests
4. Rīku un savienotāju inventārs
5. Modeļa, pamudinājuma un politikas versijas ieraksts
6. Konteinera attēla un atkarību materiālu saraksts
7. Tīkla politika un izejošās datplūsmas žurnāls
8. Sensitīvo datu atklāšanas un rediģēšanas ziņojums
9. Sesijas un rīku izsaukumu izsekošana
10. Cilvēka apstiprinājuma ieraksts
11. Drošības novērtējums un sarkanās komandas ziņojums
12. Izlaišanas izcelsme un artefakta paraksts
13. Atmiņas izcelsmes un atjaunošanas ieraksts
14. Incidentu reaģēšana un atjaunošanas tests
15. Piegādātāja drošības brīdinājums un ielāpu ieraksts

Žurnāliem jābūt ar manipulāciju pierādījumiem, ar piekļuves kontroli un jāglabā atbilstoši datu sensitīvumam. Parastajām izstrādes sesijām var būt nepieciešami deviņdesmit dienu glabāšanas laiks, savukārt sesijām, kas piekļūst izlaišanas sistēmām, regulētiem datiem vai augstas vērtības repozitorijiem, var būt nepieciešams viens gads vai ilgāk.

OpenAI apraksta iekšējo uzraudzību, kas pārskata kodēšanas aģenta mijiedarbību, rīku izsaukumus un potenciāli aizdomīgu uzvedību, savukārt GitHub uzsver sesiju žurnālus, parakstītus apstiprinājumus, attiecināmību un audita ierakstus. Šie modeļi atbalsta plašāku principu: aģenta uzvedībai jābūt novērojamai neatkarīgi no paša aģenta skaidrojuma par to, ko tas darīja. (openai.com)

Pirmais praktiskais solis

Labākais pirmais solis nav izvietot aģentu pret ražošanas repozitoriju.

Vietā:

1. Izveidojiet vienreizējās lietošanas testa repozitoriju.
2. Piešķiriet aģentam tikai lasīšanas uzdevumu.
3. Palaidiet to svaigā smilškastē.
4. Atspējojiet piekļuvi izstrādātāja akreditācijas datiem.
5. Bloķējiet visu tīkla datplūsmu, izņemot modeļa nodrošinātāju.
6. Pievienojiet apzināti ļaunprātīgu problēmas aprakstu, README instrukciju, rīka aprakstu un konfigurācijas failu.
7. Ierakstiet katru mēģināto failu piekļuvi, rīka izsaukumu, komandu un tīkla pieprasījumu.
8. Izmantojiet rezultātus, lai izveidotu savu pirmo atļauju manifestu un drošības pakalpojumu līmeņa vienošanos.

Ja aģents šādos apstākļos nevar droši pabeigt tikai lasīšanas uzdevumu, tas nav gatavs rakstīšanas piekļuvei, izlaišanas automatizācijai vai ražošanas sistēmām.

Secinājums

Autonomie kodu aģenti jānodrošina kā neuzticamas, identitāti nesošas automatizācijas sistēmas, nevis kā parasti izstrādātāju rīki.

Izšķirošais drošības jautājums nav:

“Vai modelis sekos pareizajām instrukcijām?”

Tas ir:

“Kas notiek, ja modelis seko nepareizai instrukcijai, kamēr tam ir reālas atļaujas?”

Pamudinājuma injekcija, rīku ekspluatācija, sensitīvo datu zādzība, datu saindēšana un piegādes ķēdes kompromitēšana ir dažādi ienākošie punkti vienā un tajā pašā pamatkļūdā: aģentam ir atļauts šķērsot pārāk daudz uzticamības robežu bez neatkarīgas nodrošināšanas.

2025. un 2026. gada incidenti liecina, ka visefektīvākās kontroles ir arhitektūras līmeņa:

• Turiet aģentus tālāk no sensitīviem datiem.
• Izmantojiet vienreizējās lietošanas spēju smilškastes.
• Nodrošiniet politikas ārpus modeļa.
• Atdaliet izstrādi no ražošanas.
• Uzskatiet konfigurāciju un atmiņu par izpildāmām uzbrukuma virsmām.
• Izmantojiet kontrolētu izejošo datplūsmu.
• Noņemiet kopīgās kešatmiņas no privileģētām izlaišanas darbplūsmām.
• Piesaistiet un verificējiet katru rīku un artefaktu.
• Sagatavojiet visas rakstīšanas darbības.
• Pieprasiet neatkarīgu apstiprinājumu neatgriezeniskām darbībām.
• Saglabājiet detalizētus, manipulāciju pierādījumus saturošus audita ierakstus.

Autonomija var būt noderīga un droša, taču tikai tad, ja sistēma ir izstrādāta tā, lai apjukušam, manipulētam vai kompromitētam aģentam būtu ierobežota autoritāte, ierobežota sasniedzamība, ierobežots laiks un skaidri atjaunojams kļūdas režīms.