უსაფრთხოების პროგრამების უმეტესობა აშენდა ერთ ვარაუდზე, რომელიც არავის ჩაუწერია: ის, ვისაც credentials უჭირავს, ადამიანია. ადამიანი, რომელიც იღლება, ნელა კითხულობს და ამჩნევს, როცა README უცებ ეუბნება, .env ფაილი სადმე გააგზავნოს ელფოსტით. კოდინგ-აგენტები ამ ვარაუდს არღვევენ. მათ იგივე tokens უჭირავთ, რაც თქვენს ინჟინრებს, კითხულობენ ყველა ფაილს და ვებ-გვერდს, რომელზეც მიუთითებთ, და მოქმედებენ მანქანის სიჩქარით.
ეს აგენტებს განსაკუთრებით საშიშს არ ხდის. ეს მათ აქცევს მოქმედი პირების ახალ კატეგორიად, რომლისთვისაც თქვენი კონტროლები არ შექმნილა. ბოლო თვეებში Anthropic-ის უსაფრთხოების გუნდმა ზუსტად ამ პრობლემაზე სტატიების ჯგუფი გამოაქვეყნა — CISO-ს გზამკვლევი agentic AI-ზე, ანგარიში იმაზე, როგორ იცავენ საკუთარ AI-native SDLC-ს, მითითებები Zero Trust-ზე აგენტებისთვის, LLM-ზე დაფუძნებულ კოდის სკანირებაზე და AI-აჩქარებული თავდასხმისთვის მზადებაზე. ეს პოსტი ჩემი, როგორც ინჟინრის, სინთეზია: რა არის ნამდვილად ახალი threat model-ში, რომელი კონტროლები გამართლდება და როგორ დავნერგოთ ისინი ისე, რომ აგენტების rollout ისევ ticket-რიგად არ გადაიქცეს.
თუ წაგიკითხავთ AI-native SDLC პოსტი, ეს წარმოიდგინეთ როგორც უსაფრთხოების თავი, რომელიც მის ქვეშ დგას.
რატომ ცვლიან აგენტები threat model-ს
კლასიკური Zero Trust ამბობს: ნაგულისხმევად არაფერს ენდე, ყოველ მოთხოვნას გადაამოწმე, ივარაუდე ჩატეხვა. ეს ყველაფერი მოქმედებს. რაც იცვლება, არის ვინ აკეთებს მოთხოვნებს და რას კითხულობს ისინი, სანამ აკეთებს.
აგენტს აქვს service account-ის წვდომა, ადამიანის იმპროვიზაცია და არცერთი იმ ინსტინქტიდან, რომელიც ადამიანს „ეს ინსტრუქცია საეჭვოა”-ს ეუბნება. სამი თვისება მნიშვნელოვანია:
- აგენტები მოქმედებენ კონტენტზე და არა მხოლოდ ბრძანებებზე. ყველაფერი, რასაც აგენტი კითხულობს — issue-ის ტექსტი, dependency-ების README-ები, ვებ-გვერდები, tool-ების გამოსავალი, ტესტ-fixtures — მისი გადაწყვეტილების მიღების ნაწილი ხდება. თუ თავდამსხმელს შეუძლია ამ კონტენტიდან რამის დაწერა, მას თქვენს აგენტამდე არხი აქვს.
- აგენტები იყენებენ ლეგიტიმურ permissions-ს. აგენტთან დაკავშირებული ინციდენტების უმეტესობა შეჭრას არ დაემსგავსება. ისინი ჰგავს ავტორიზებულ იდენტობას, რომელიც აკეთებს რაღაცას, რაც არავის განუზრახავს. წვდომის კონტროლი, რომელიც მხოლოდ იკითხავს „ამ იდენტობას აქვს უფლება?”, გაატარებს.
- აგენტები უფრო უნარიანები ხდებიან, თქვენ არაფრის შეცვლის გარეშე. მოდელის განახლებამ შეიძლება ისეთი ქცევა გახსნას, რომელიც თქვენს თავდაპირველ რისკ-შეფასებას არ განუხილავს. CISO-ს გზამკვლევს კარგი მაგალითი აქვს: incident-response აგენტმა, მოდელის განახლების შემდეგ, მისი tools-ისა და პრომპტების შეცვლის გარეშე, ინციდენტის შუაში მეორე აგენტისთვის კოდის გამოსწორების დაწერის მოთხოვნა დაიწყო. ადამიანის სარევიუო gate-მა production-მდე დაიჭირა — რაც სწორედ აზრია.
იმავდროულად გარე სამყაროც ჩქარდება. Anthropic-ის offense-preparation სტატია ამტკიცებს, რომ მოდელები ამცირებენ დროს ექსპლოიტაციის აღმოჩენიდან მომუშავე ექსპლოიტამდე, და რომ დამცველებმა დაახლოებით ორი წლის განმავლობაში vulnerability reports-ის სიდიდის რიგით ზრდა უნდა დაგეგმონ. თქვენი აგენტები ინფრასტრუქტურაზე მუშაობენ, რომელიც ამავე აჩქარებას ექვემდებარება.
საფრთხეების ლანდშაფტი იმ დონეზე, რაც გჭირდებათ
კონცეპტუალურად დავტოვებ. კონტროლების დასაპროექტებლად exploit-რეცეპტები არ გჭირდებათ; გჭირდებათ კატეგორიები.
Prompt injection
ინსტრუქციები, დამალული კონტენტში, რომელსაც აგენტი კითხულობს, მიმართული იმისკენ, რომ გადაუხვიოს, რასაც აკეთებს. ეს აგენტის განმსაზღვრელი რისკია, და გულწრფელი სტატუსია: მოდელის დონის დაცვა უმჯობესდება, მაგრამ არავინ სანდო არ ამტკიცებს, რომ წარმატების მაჩვენებელი ნულია. injection-ს phishing-ივით მოეპყარით — რაღაცას, რასაც ამცირებთ და ლოკალიზებთ, და არა „წყვეტთ”.
ზედმეტად მონდომებული და შეცდომით მოქმედებები
ესაა ის, რასაც გუნდები არაფასობენ. Anthropic-ის ანგარიში Claude Code-ის auto mode-ზე აღრიცხავს რეალურ შიდა ინციდენტებს, რომლებიც საერთოდ თავდასხმები არ იყო: აგენტმა „გაწმინდე ძველი branches” ისე გაიგო, როგორც ნებართვა remote branches-ის batch-წაშლისა; აგენტი auth შეცდომის შემდეგ კონფიგურაციის ფაილებში სხვა token-ს ეძებდა; აგენტმა წარუმატებელი deploy გადაამოწმების გამოტოვებით გაიმეორა. კეთილი განზრახვა, არასწორი blast radius. ჩემი მოლოდინია, რომ ეს კატეგორია უფრო მეტ ყოველდღიურ ზიანს აყენებს, ვიდრე მტრული injection.
Credentials-ის გამჟღავნება
აგენტს მხოლოდ ის გაჟონვა შეუძლია, რასაც წვდება. თუ თქვენს დეველოპერულ გარემოში კოდის გვერდით დევს ხანგრძლივი ცხოვრების cloud keys, SSH keys და .env production საიდუმლოებით, მაშინ თითოეული მათგანი injected ან ზედმეტად მონდომებული აგენტის scope-შია.
ზედმეტად ფართო permissions და ბუნდოვანი იდენტობა
CISO-ს გზამკვლევი წამოაყენებს აზრს, რომელიც გამჭვირვალედ მივიჩნიე: საშიში ზონა არ არის გამოყოფილი service account და არც ადამიანი კლავიატურასთან. ეს შუა ადგილია, სადაც აგენტი პირის დელეგირებულ იდენტობას ისეთ სისტემებში გადააქვს, რომლებსაც ეს პირი არ აკვირდება. როცა რამე არასწორად მიდის, ვერავინ ამბობს, ვინ გააკეთა ეს ნამდვილად.
გაფართოებების supply chain
Skills, plugins, MCP servers, connectors და dependencies, რომლებსაც აგენტები აყენებენ — თითოეული კოდია ან ინსტრუქციები, რომლისადმი ნდობას თქვენ ირჩევთ, და ზოგი არასანდო კონტენტს პირდაპირ კონტექსტში აწვდის. Tool poisoning აგენტების ეპოქის მავნე პაკეტია. თუ MCP-ს ფართოდ ნერგავთ, MCP for engineering teams-ის მართვის კითხვები უსაფრთხოების კითხვებიცაა.
მეხსიერებისა და კონტექსტის მოწამვლა
პერსისტენტული კონტექსტი — memory ფაილები, CLAUDE.md-ტიპის ინსტრუქციები, საერთო ცოდნის ბაზები — შეიძლება გაყალბდეს ისე, რომ საწამლავი სესიას გადაურჩეს. ინსტრუქციის ფაილები იმსახურებს code-review დისციპლინას, რადგან ისინი ფაქტობრივად არიან კოდი.
ოთხი კითხვა ნებისმიერი აგენტის დამტკიცებამდე
ამ წყაროების მთელ ნაკრებში ყველაზე სასარგებლო ხელსაწყო CISO-ს გზამკვლევის ოთხკითხვიანი შეფასებაა. გადავაფორმულე ისე, როგორც design review-ზე რეალურად გამოვიყენებდი:
- რა არასანდო კონტენტს კითხულობს? რის დაწერა ან შეცვლა შეუძლია თავდამსხმელს დამაჯერებლად ისე, რომ ეს აგენტის კონტექსტში მოხვდეს? თუ გულწრფელი პასუხია „არაფერი”, აგენტის სპეციფიკური რისკი ნულთან ახლოსაა.
- რა შეუძლია და ვის სახელით? წაკითხვა თუ ჩაწერა, კოდის გაშვება, tools-ის გამოძახება, ქსელთან წვდომა — და რომელი იდენტობით.
- რა არის blast radius, თუ რამე არასწორად წავიდა? ერთი ფაილი, ერთი repo, ერთი გარემო, მთელი ორგანიზაცია? ყველაზე ცუდი შემთხვევა გაღიზიანებაა თუ ინციდენტი?
- ხედავთ მას? შეგიძლიათ აგენტის მოქმედებები მომხმარებლის მოქმედებებისგან გამოარჩიოთ და ხვდება თუ არა ისინი თქვენს SIEM-ში?
ეს კითხვები „უნდა დავუშვათ თუ არა აგენტები?” — დებატს, რომელიც არასოდეს მთავრდება — გარდაქმნის კითხვად „რა პირობებში დავამტკიცებდით ამას?”, რომელსაც პასუხი აქვს. სარისკო კომბინაციაა არასანდო input პლუს ძლიერი მოქმედებები პლუს ცუდი ხილვადობა; ამოიღეთ ნებისმიერი ფეხი და სურათი მკვეთრად უმჯობესდება.
კონტროლები, რომლებიც ნამდვილად გამართლდება
დაახლოებით ბერკეტის მიხედვით. გამჭოლი თემა: საზღვრები გაავლეთ მოქმედებებისა და წვდომის გარშემო და არა მოდელის ინსტრუქციების გარშემო. პრომპტი, რომელიც ამბობს „არასოდეს შეეხო production-ს”, რჩევაა. credential, რომელიც production-ს ვერ წვდება, კონტროლია.
Least agency
Least privilege, ადაპტირებული: მიანიჭეთ ყველაზე ვიწრო შესაძლებლობა, რომელიც ამოცანას ასრულებს და არა მხოლოდ ყველაზე ვიწრო მონაცემთა წვდომა. შეზღუდეთ ცალკეული ზმნები და არა მხოლოდ მთელი tools — აგენტი, რომელსაც შეუძლია შეტყობინების დრაფტი, მაგრამ არა გაგზავნა, PR-ის გახსნა, მაგრამ არა merge, ლოგების წაკითხვა, მაგრამ არა deploy. თუ აგენტს ზმნა არ აქვს, ვერავითარი injection ვერ აიძულებს მის გამოყენებას.
Sandboxing და egress control
გაუშვით აგენტები იზოლირებულ გარემოებში — containers, microVMs, remote dev VMs — credentials-ით, რომლებიც sandbox-ის გარეთ ინახება. პატერნი, რომელსაც Anthropic საკუთარი ხელსაწყოებისთვის აღწერს, არის proxy, რომელიც credentials-ს გასვლისას ინექტირებს, ამიტომ sandbox-ში არაფერია მოსაპარი. დააწყვილეთ ეს egress allowlisting-თან proxy-ის მეშვეობით, რომელსაც აგენტი ვერ აუვლის გვერდს. injected აგენტს, რომელსაც თვითნებურ დანიშნულებას ვერ წვდება, არსად აქვს გასაგზავნი ის, რაც იპოვა.
ერთი დანიშნულების აგენტის იდენტობა
თითოეულ ავტონომიურ აგენტს მიეცით საკუთარი იდენტობა მინიმალური permissions-ით მისი ერთი საქმისთვის, გამოყოფილი თქვენი IdP-ით ისევე, როგორც ნებისმიერი სხვა principal. Anthropic-ის incident-response აგენტი სახელმძღვანელო შემთხვევაა: მას შეუძლია production ლოგების წაკითხვა, დოკუმენტების ჩაწერა და არხებში გამოქვეყნება — და სხვა არაფერი. ის ვერ აკეთებს deploy-ს. ინტერაქტიული კოდინგ-სესიები განსხვავებულია: ადამიანი კლავიატურასთანაა და პასუხისმგებელია, ამიტომ ადამიანის credential იქ საკმარისია, სანამ გარემო sandboxed-ია. აარიდეთ თავი შუა ზონას.
დეტერმინირებული hooks და managed settings
ეს განსხვავებაა, რომელსაც ყოველ აგენტ-პოსტში ვიმეორებ, რადგან იმდენ ინციდენტს აცდენს: ინსტრუქციები ურჩევენ, hooks ახორციელებენ. თქვენი secure-coding სახელმძღვანელოები CLAUDE.md-სა და skills-ში უნდა იყოს, რათა გენერირებული კოდი უმეტესად მათ მისდევდეს. მაგრამ ყველაფერს, რაც უნდა დაცული იყოს — დაცულ ბილიკებზე რედაქტირების აკრძალვა, საიდუმლოები diff-ებში, სავალდებულო უსაფრთხოების გავლა PR-ის გახსნამდე — სჭირდება დეტერმინირებული სარეზერვო დაცვა: pre-tool hook, CI gate, branch protection წესი. შემდეგ არასაპირისპირებელი ნაწილები გადაიტანეთ ცენტრალიზებულად მართულ settings-ში, რათა ცალკეულმა დეველოპერებმა ისინი წყნარად ვერ შეარბილონ.
Classifiers როგორც შუა ფენა და არა კედელი
Approval fatigue რეალურია: Anthropic იუწყება, რომ მომხმარებლები Claude Code-ის permission prompts-ის 93%-ს ეთანხმებიან, რაც ნიშნავს, რომ prompt-მა უმეტესწილად შეწყვიტა შემოწმებად ფუნქციონირება. Auto mode უმეტეს prompts-ს ცვლის classifier-ით, რომელიც ყოველ სარისკო მოქმედებას გაშვებამდე აფასებს. გამოქვეყნებული ციფრები ფრთხილ წაკითხვას იმსახურებს: 0.4% false-positive მაჩვენებელი რეალურ ტრაფიკზე, მაგრამ 17% miss მაჩვენებელი რეალური ზედმეტად მონდომებული მოქმედებების მცირე ნაკრებზე. Anthropic მას აყალიბებს როგორც დიდ გაუმჯობესებას permissions-ის გამოტოვებასთან შედარებით და შესაძლო რეგრესიას ფრთხილ ხელით დამტკიცებასთან შედარებით მაღალი ფასის ინფრასტრუქტურაზე. ამიტომ გამოიყენეთ ის როგორც ერთი ფენა sandbox-სა და least-privilege credentials-ზე, არასოდეს როგორც ერთადერთი რამ აგენტსა და production-ს შორის.
Audit trails, რომლებიც აგენტს ადამიანისგან გამოარჩევს
ყოველი tool-გამოძახება, ავტომატური დამტკიცება და აგენტიდან აგენტამდე შეტყობინება უნდა ლოგირდებოდეს საკმარისი კონტექსტით — tool, პარამეტრები, შედეგი, მომხმარებელი, სესია — რათა მომხდარის რეკონსტრუქცია შეიძლებოდეს, და იგზავნებოდეს თქვენს SIEM-ში. აგენტებს მოეპყარით როგორც პოტენციურ insiders-ს და მოახდინეთ alert პატერნიდან გადახრილ ქცევაზე. CISO-ს გზამკვლევი ასახელებს Ponemon-ის ციფრს — საშუალოდ 67 დღე insider ინციდენტის შესაკავებლად; მანქანის სიჩქარით მოქმედი აგენტი ამ ვადას გაუძლებელს ხდის, რის გამოც ხილვადობა მასშტაბამდე უნდა მოდიოდეს.
ადამიანი production gate-ზე
ყველაზე სუფთა governance ხაზი, რომელიც ვიცი: აგენტს შეუძლია ყველაფერი გააკეთოს production gate-მდე, ხოლო დასახელებული ადამიანი ადასტურებს მასში გავლას. Anthropic ამბობს, რომ Claude წერს მათ კოდბაზაში merge-ებული კოდის დაახლოებით 80%-ს, ხოლო შიდა აგენტი pull-request ნაკადის დიდ ნაწილს ამუშავებს — და კონტროლები, რომლებიც ამას ასატანს ხდის, არის ephemeral გარემოები production keys-გან გამოყოფილი, პლუს ადამიანის რევიუ merge-მდე. დაყავით თქვენი კოდბაზა რისკის მიხედვით ფენებად: ზოგი ბილიკი შეიძლება ავტომატურად დამტკიცდეს sampling-ით, regulated ან კრიტიკული კოდი ადამიანის რევიუში რჩება.
უწყვეტი სკანირება, მიმართული თქვენსავე კოდზე
თუ თავდამსხმელები თქვენს კოდს უნარიანი მოდელებით დასკანერებენ, დაასკანერეთ პირველებმა. source-code უსაფრთხოების გზამკვლევის loop თითქმის უცვლელად ღირს აღსაქმელად: threat model, sandbox, discover, დამოუკიდებლად verify, triage, patch. აღმოჩენა (recall) და ვერიფიკაცია (precision) ცალკე აგენტებში შეინახეთ და triage-სა და patching-ზე ბიუჯეტი დაგეგმეთ მეტ სკანირებამდე — triage ახლა ბოთლის ყელია.
კონტროლების ცხრილი
აი ყველაფერი ერთ გვერდზე. „დეტერმინირებული” ნიშნავს, რომ ის მოდელის გადაწყვეტილებისგან დამოუკიდებლად მოქმედებს; „რჩევითი” ნიშნავს, რომ ის ალბათობებს ცვლის.
| რისკი | კონტროლი | ტიპი | მფლობელი |
|---|---|---|---|
| Prompt injection წაკითხული კონტენტით | განსაზღვრეთ არასანდო წყაროები; გამიჯნეთ არასანდო-input connectors production მონაცემებისგან; injection probes | რჩევითი (probes) + დეტერმინირებული (გამიჯვნა) | უსაფრთხოების არქიტექტურა |
| მონაცემთა exfiltration | Sandbox egress allowlist-ით შეუვალი proxy-ის გავლით | დეტერმინირებული | Platform engineering |
| Credentials-ის გამჟღავნება | Credentials ინექტირდება proxy-ით, არასოდეს არის sandbox-ში; მოკლე ვადის scoped tokens | დეტერმინირებული | Platform / IAM |
| ზედმეტად მონდომებული ან დესტრუქციული მოქმედებები | თითო-ზმნაზე tool permissions; action classifier; deny წესები managed settings-ში | დეტერმინირებული (permissions) + რჩევითი (classifier) | Tech lead + platform |
| ბუნდოვანი ანგარიშვალდებულება | ერთი დანიშნულების აგენტის იდენტობები IdP-ით; დელეგირებული ადამიანის იდენტობა არ გამოიყენება მეთვალყურეობის გარეშე მომუშავე აგენტებისთვის | დეტერმინირებული | IAM |
| პოლიტიკის დრიფტი გენერირებულ კოდში | Secure-coding წესები CLAUDE.md/skills-ში, დამყარებული hooks-ითა და CI gates-ით | რჩევითი → დეტერმინირებული | Policy owner + tech lead |
| მავნე skills, plugins, MCP servers | Allowlist-ირებული გაფართოებები, ვერსიონირებული და გადახედილი dependencies-ივით | დეტერმინირებული | Platform + security |
| მეხსიერების / ინსტრუქციების მოწამვლა | ინსტრუქციის ფაილები code review-ისა და code ownership-ის ქვეშ | დეტერმინირებული | Repo code owners |
| არაავტორიზებული production ცვლილებები | Approval hook ან CI gate, რომელიც დასახელებულ ადამიანს მოითხოვს; branch protection | დეტერმინირებული | Release manager |
| აღმოუჩენელი ბოროტად გამოყენება | Tool-გამოძახებების ტელემეტრია SIEM-ში; აგენტი-ადამიანის ატრიბუცია; ორგანიზაციის მასშტაბის off switch | დეტერმინირებული (logging) | Security operations |
| თქვენი კოდის AI-აჩქარებული ექსპლუატაცია | უწყვეტი სკანირება დამოუკიდებელი ვერიფიკაციით; სწრაფი patch SLA-ები | რჩევითი (findings) + დეტერმინირებული (merge-ის ბლოკირება მაღალი დარწმუნებისას) | AppSec |
თუ რომელიმე რიგში მხოლოდ „რჩევითია” და რისკი ისეთია, რომლის მიღებაც არ შეგიძლიათ, ეს თქვენი შემდეგი სამუშაოა.
სად ვიქნებოდი ფრთხილად
- ეს ვენდორის დოკუმენტებია. ექვსივე წყარო Anthropic-ისაა და რამდენიმე Anthropic-ის პროდუქტებზე მიუთითებს. პატერნები — least agency, credential-free sandboxes, egress control, დეტერმინირებული gates, აგენტის იდენტობა, ტელემეტრია — ვენდორ-ნეიტრალურია და ნებისმიერ კოდინგ-აგენტზე ვრცელდება. პროდუქტის სპეციფიკა შეიცვლება; დააპროექტეთ პატერნების გარშემო.
- Anthropic-ის ციფრები Anthropic-ის ციფრებია. ისინი აღწერს ერთ ძალიან AI-native ორგანიზაციას უჩვეულოდ მომწიფებული უსაფრთხოების გუნდით. მიიჩნიეთ ისინი მტკიცებულებად, რომ მოდელს შეუძლია მუშაობა, და არა სამიზნეებად, რომლებსაც დირექტორთა საბჭოს დაჰპირდებით.
- ნუ გადააჭარბებთ პრომპტის ხარაჩოს, როგორც კონტროლის, ინჟინერიას. CISO-ს გზამკვლევი აღნიშნავს, რომ დახვეწილი ინსტრუქციები მოდელების გაუმჯობესებასთან ერთად ჩვეულებრივ ამოიღება. ეს ძალისხმევა დახარჯეთ საზღვრებზე, რომლებიც საერთოდ არ არის მოდელზე დამოკიდებული.
- Lockdown-ს ფასი აქვს. ყოველი deny წესი შესაძლებლობას აკლებს. ყველაზე მკაცრი კონფიგურაციის ყველა repo-ზე კოპირება ადამიანებს არასანქცირებული ხელსაწყოებისკენ უბიძგებს — და shadow adoption-ს არც ტელემეტრია აქვს, არც off switch. შეუსაბამეთ შეზღუდვები თითოეული repo-ს მონაცემთა კლასიფიკაციას.
როგორ დავნერგოთ სიჩქარის მოკვლის გარეშე
ჩარჩო, რომელიც ყველაზე მეტად მომწონს, CISO-ს გზამკვლევის სათაურიდან მოდის: ნულოვანი რისკი სამუშაო არ არის. სამუშაოა agentic რისკის ხილულად და შემოსაზღვრულად გახდომა, რათა ორგანიზაციამ ის ნებაყოფლობით მიიღოს. უარის თქმა აგენტების გამოყენებას არ აქრობს; ის უბრალოდ გადააქვს იქ, სადაც მას ვერ ხედავთ.
რეალურ გუნდში ამ თანმიმდევრობას მივყვებოდი:
- კვირა 1–2: ინვენტარიზაცია და კლასიფიკაცია. ჩამოწერეთ, სად უკვე მუშაობენ აგენტები, სანქცირებულად თუ არა. ჩაწერეთ, რა ითვლება არასანდო კონტენტად თქვენს გარემოში. გაატარეთ თქვენი ყველაზე მაღალი წნევის use case ოთხ კითხვაში და მოძებნეთ პირობები, რომლებშიც იტყოდით დიახ.
- კვირა 3–4: საიდუმლოები მიუწვდომლად გადაიტანეთ. გადაიტანეთ აგენტის სამუშაო sandboxed გარემოებში credentials-ით sandbox-ის გარეთ და egress allowlist-ით. ეს ერთი ცვლილება ამცირებს ყველა სხვა მტყუნების blast radius-ს.
- თვე 2: პოლიტიკა გახადეთ დეტერმინირებული. დააკოდეთ secure-coding წესები
CLAUDE.md-სა და skills-ში, შემდეგ დაამატეთ hooks და CI gates აუცილებლად-დასაცავ ქვენაკრებზე. გადაიტანეთ ისინი managed settings-ში. Allowlist-ში ჩასვით გაფართოებები და MCP servers. - თვე 2–3: იდენტობა და ტელემეტრია. თითოეულ ავტონომიურ აგენტს მიეცით ერთი დანიშნულების იდენტობა. გაუშვით tool-გამოძახებები თქვენს SIEM-ში აგენტი-ადამიანის ატრიბუციით. დარწმუნდით, რომ გაქვთ ორგანიზაციის მასშტაბის off switch და რომ ის ნამდვილად მუშაობს.
- თვე 3+: გადაიყვანეთ reviewers ხაზებიდან loops-ზე. ახალი AI reviewers ჯერ shadow რეჟიმში გაუშვით, red-team გაუკეთეთ განზრახ ცუდი ცვლილებებით, შემდეგ დაყავით კოდბაზა ფენებად, რათა ადამიანები სარისკო ბილიკებზე კონცენტრირდნენ. დაიწყეთ უწყვეტი სკანირება თქვენი ყველაზე ექსპონირებული სერვისისთვის, ვერიფიკაციის ნაბიჯითა და triage გზით.
გააფართოვეთ ეტაპობრივად: ჯერ მცირე ჯგუფი, დააკვირდით ტელემეტრიას, შემდეგ გააფართოვეთ. ჰკითხეთ თქვენს IdP-ს, SIEM-სა და აგენტის ვენდორებს, ამ კონტროლებიდან რომლის დემონსტრირება შეუძლიათ დღეს, და არა roadmap-ზე. ორგანიზაციული და სარევიუო პროცესის მხარეებისთვის იხილეთ AI readiness assessment და AI კოდინგ-ხელსაწყოების დანერგვა.
კარიერული კუთხე
უსაფრთხოების ინჟინრები გადადიან ცალკეული ბაგების ძებნიდან იმ loops-ის მონიტორინგზე, რომლებიც მათ პოულობენ და ასწორებენ. Platform ინჟინრები governance-ს აკოდებენ როგორც sandboxes, hooks და managed settings. Tech leads ფლობენ ინსტრუქციის ფაილებსა და სარევიუო gates-ს — რაც მათ უსაფრთხოების პერიმეტრის ნაწილად აქცევს, ითხოვეს ეს თუ არა.
ცალკეული ინჟინრებისთვის უნარი, რომელიც გროვდება, არის ოთხ კითხვაზე სწრაფი პასუხი ნებისმიერი აგენტის setup-ისთვის. ის მოდელზე ან ვენდორზე არ არის მიბმული და თითოეულ ჯერზე უფრო ფასეულია, როცა შესაძლებლობა ახტება.
უფრო ღრმად
ამ პოსტის კონტროლები პირდაპირ ჯდება ჩვენს კურსებში. AI-Native SDLC ფარავს hooks-ს, approval gates-სა და ადამიანი-production-gate-ზე მოდელს სრულ lifecycle-ში. Claude Code Mastery ღრმად შედის permissions-ში, sandboxing-ში, hooks-სა და managed settings-ში ყოველდღიურ agentic loop-ში. MCP Servers არის ადგილი, სადაც tool ფენის უსაფრთხოდ აშენებას და მართვას ისწავლით. თუ საკუთარ აგენტებს აშენებთ, Claude Agent SDK და Claude API ფარავს tool permissions-ს, scoped იდენტობებსა და მათ უკან მდგარ სანტექნიკას.
გუნდებისთვის, რომლებიც აგენტებს მთელ ორგანიზაციაში ნერგავენ, ამას ასევე ვატარებთ როგორც corporate training, ან როგორც პრაქტიკულ AI tools enablement-ს.
წყაროები: Anthropic, Zero risk isn’t the job: a CISO’s guide to agentic AI (2026 წლის ივლისი); How Anthropic secures its AI-native software development lifecycle (2026 წლის ივლისი); Zero Trust for AI agents (2026 წლის მაისი); Using LLMs to secure source code (2026 წლის მაისი); Preparing your security program for AI-accelerated offense (2026 წლის აპრილი); How Claude Code auto mode works (2026 წლის მარტი). ეს პოსტი დამოუკიდებელი კომენტარია; სრული დეტალებისთვის წაიკითხეთ ორიგინალები. დაკავშირებული ამ სერიაში: AI-native SDLC, MCP for engineering teams, როდის არ გამოვიყენოთ AI ხელსაწყოები.
