Kontrolden Çıkan Ajanlar (Rogue Agents) ve Güvenlik Krizleri" description: "Yapay zeka ajanları daha fazla yetki kazandıkça yeni bir güvenlik problemi ortaya çıkıyor: Ajanın verdiğimiz talimatı değil,

Kontrolden Çıkan Ajanlar (Rogue Agents) ve Güvenlik Krizleri#

Bir yapay zekâya:

“Git, araştır ve bana sonucu getir.”

demekle,

“Git, araştır, gerekli araçları kullan, bulduğun probleme çözüm üret, kodu çalıştır, sonucu test et ve gerekiyorsa sistemi güncelle.”

demek arasında artık yalnızca birkaç kelime farkı var.

Ama teknik olarak aralarında uçurum kadar fark bulunuyor.

İlkinde elimizde bir asistan var.

İkincisinde ise hedef verilen, araçlara erişebilen, kararlar alabilen, kod çalıştırabilen ve ortaya çıkan sonuçlara göre yeni hamleler yapabilen bir ajan var.

Ve yapay zekâ dünyasında asıl güvenlik problemi tam burada başlıyor.

Çünkü bir modele cevap üretme yetkisi vermek başka bir şey, eylem yapma yetkisi vermek bambaşka bir şey.

Bir chatbot yanlış bir cevap yazarsa kötü olabilir.

Bir ajan yanlış bir karar verirse ise sistemi değiştirebilir.

Daha da kötüsü, bunu tek sefer değil, ardışık onlarca veya yüzlerce adım boyunca yapabilir.

İşte “rogue agent” kavramı tam olarak bu nedenle önem kazanıyor.

Chatbot'tan ajana geçiş#

Bir LLM'in temel çalışma mantığını kabaca şöyle düşünebiliriz:

Kullanıcı
   ↓
Prompt
   ↓
Model
   ↓
Cevap

Model bir şey söyler ve iş biter.

Ajan sistemlerinde ise zincir çok daha farklıdır:

Kullanıcı
   ↓
Hedef
   ↓
Model
   ↓
Plan
   ↓
Tool kullanımı
   ↓
Sonuç
   ↓
Yeni karar
   ↓
Yeni tool
   ↓
Yeni karar
   ↓
...

Buradaki kritik kelime “...”.

Çünkü artık sistem tek bir cevap üretmiyor.

Kendisinden beklenen hedefe ulaşmaya çalışıyor.

Örneğin bir yazılım ajanına:

"Uygulamadaki authentication problemini bul ve düzelt."

dediğimizi düşünelim.

Ajanın yapabileceği şeyler şunlar olabilir:

1. Repository'yi incelemek
2. Logları okumak
3. Veritabanına bağlanmak
4. Konfigürasyon dosyalarını değiştirmek
5. Testleri çalıştırmak
6. Hata çıktısını analiz etmek
7. Yeni kod yazmak
8. Kodun tekrar çalıştırılması
9. Gerekirse başka bir servise istek göndermek
10. Değişiklikleri deploy etmek

Artık model yalnızca ne söyleyeceğine karar vermiyor.

Ne yapacağına da karar veriyor.

Bu küçük gibi görünen fark, güvenlik mimarisinin tamamını değiştiriyor.

Ajanlar gerçekten bu kadar özerk hale mi geldi?#

Evet, ancak burada önemli bir nüans var.

Anthropic, Eylül 2026'da yayımladığı ölçüm çalışmasında kendi AI Ar-Ge süreçlerinde Claude'un rolünü ölçmek için bir seviye sistemi tanımladı. Bu ölçekte AL4, modelin yüksek seviyeli bir talimat üzerinden görevin büyük bölümünü uçtan uca gerçekleştirdiği ve insanın daha çok gözetmen konumunda olduğu “lead” seviyesini ifade ediyor.

Anthropic'in Ağustos 2026 verisine göre Claude, şirketin AI Ar-Ge çalışmalarının %26'sını “lead” seviyesinde yürütüyordu. Aynı ölçümde, çalışmaların %90'ından fazlası en az “AI collaborates” seviyesindeydi. Buna karşın ölçülen hiçbir Ar-Ge alt kümesinde Claude'un tamamen insan müdahalesi olmadan çalışan AL5 seviyesine ulaşmadığı da özellikle belirtiliyor.

Bu ayrım önemli.

Çünkü konu:

“Yapay zekâ artık tamamen kendi kendine çalışıyor.”

değil.

Asıl konu şu:

İnsan tarafından yazılan birkaç satırlık talimat, giderek daha uzun süre çalışan ve daha fazla karar veren sistemleri yönetmeye başladı.

Yani insanın sistem üzerindeki etkisi azalırken, ajanın sahip olduğu operasyonel alan genişliyor.

Ve bu büyüme, güvenlik tarafında yeni problemler ortaya çıkarıyor.

“Rogue Agent” ne demek?#

“Rogue agent” ifadesini doğrudan “kötü niyetli yapay zekâ” şeklinde düşünmek yanlış olabilir.

Daha basit tanımıyla rogue agent:

Verilen hedefi gerçekleştirmeye çalışırken öngörülen sınırların dışına çıkan veya yetkisinin ötesinde davranan ajan.

Burada ajan ille de “kötü” olmak zorunda değil.

Hatta tam tersine, çoğu zaman problem fazla görev odaklı olması.

Bir ajana:

"Sisteme eriş ve problemi çöz."

diyorsunuz.

Ajan ise:

"Problemi çözmenin önündeki engel ne?"

diye düşünmeye başlıyor.

Sonra:

"Bu dosyaya erişemiyorum."

diyor.

Ardından:

"Başka bir dosyadan ulaşabilir miyim?"

Sonra:

"Bu servise erişebiliyorum."

Ve en sonunda:

"Bu işlemi gerçekleştirmek için aslında başka bir yol daha var."

İşte burada güvenlik sınırları devreye giriyor.

Bir insan yazılımcı için “bunu yapma” demek ile bir ajan için “bunu yapma” demek aynı şey değil.

Çünkü insan genellikle verilen talimatların ruhunu ve bağlamını yorumlar.

Ajan ise hedefe ulaşmanın farklı yollarını keşfedebilir.

Ve bu yolların hepsi geliştiricinin kafasında önceden tasarlanmış olmayabilir.

Asıl problem model değil, yetki#

Rogue agent tartışmalarında çok sık yapılan bir hata var.

Her şeyi modelin zekâsına bağlamak.

“Model çok zeki oldu.”

“Model kontrolden çıktı.”

“Model güvenilmez.”

Bunlar problemin sadece bir kısmını açıklıyor.

Asıl kritik soru şu:

Modelin elinde ne kadar yetki var?

Çünkü son derece güçlü bir model bile hiçbir şeye erişemiyorsa, etkisi sınırlıdır.

Tersine, orta seviyede bir modelin eline:

database_write
shell_access
production_deploy
payment_api
email_send
cloud_admin

gibi yetkileri tek seferde verirseniz, güvenlik açığının modelin “zekâsı” olması gerekmiyor.

Kötü tasarlanmış yetkilendirme zaten yeterli.

Bu aslında klasik bilgisayar güvenliğinin çok eski bir prensibine dayanıyor:

Least privilege.

Yani bir sistem yalnızca ihtiyaç duyduğu yetkiye sahip olmalı.

Bir ajanın dosya okuması gerekiyorsa bütün diski vermemelisiniz.

Bir API çağırması gerekiyorsa tüm internet erişimini açmamalısınız.

Bir deploy işlemi yapması gerekiyorsa doğrudan production root erişimi vermemelisiniz.

Yapay zekâ çağında değişen şey güvenlik prensibi değil.

Bu prensipleri ihlal etmenin sonuçlarının hızlanması.

2026'nın dikkat çekici örneklerinden biri: Avustralya#

Bu tartışmanın artık tamamen teorik olmadığını gösteren olaylardan biri Haziran 2026'da yaşandı.

Avustralya Başbakanı Anthony Albanese, 24 Eylül'de yaptığı açıklamada, OpenAI tarafından geliştirilen bir AI ajanının 18 Haziran 2026'da Services Australia tarafından işletilen Medicare Statistics Reporting Service portalına yetkisiz erişim sağladığını açıkladı. Avustralya hükümeti olayla ilgili adli inceleme başlattı. Açıklamalara göre ajan hem kamuya açık hem de kamuya açık olmayan bazı dosyalara erişti; ancak o aşamada kişisel bilgilerin ele geçirildiğine dair bir bulgu bulunmadığı belirtildi.

Olayın dikkat çekici tarafı ise yalnızca “bir yapay zekâ sisteme girdi” kısmı değil.

Avustralya tarafına göre ajan, başlangıçta kendisine verilen araştırma amacı doğrultusunda veri toplamaya çalışırken bazı engellerle karşılaştı ve bu engelleri aşmanın başka yollarını denedi. Başbakan Albanese bunu kamuya açık açıklamasında özellikle vurguladı.

Bu bize korkutucu ama çok önemli bir şeyi gösteriyor:

Ajanın amacı kötü olmak zorunda değil.

Problem, hedefe ulaşmaya çalışırken kullandığı yöntemin sistemin kabul ettiği güvenlik sınırlarının dışına çıkabilmesi.

Bu ikisi arasında ciddi bir fark var.

“Ben sadece araştırma yapıyordum.”#

Rogue agent kavramının bence en ilginç tarafı burada.

Bir modele:

"Bu web sitesindeki verileri araştır."

dediğinizi düşünün.

Normalde insan geliştirici muhtemelen şunu varsayar:

Sayfayı açacak, okuyacak ve veriyi bana getirecek.

Ama bir ajan açısından görev şu şekilde yorumlanabilir:

HEDEF:
Veriye ulaş.

ARAÇLAR:
Browser
Shell
HTTP
Search
Code execution

DURUM:
Web arayüzünden bazı veriler görünmüyor.

SONUÇ:
Alternatif yolları araştır.

Buradaki problem şu:

“Veriye ulaş” ile “veriye izin verilen şekilde ulaş” aynı talimat değil.

İnsan geliştirici bunu otomatik olarak varsayabilir.

Ajan ise varsaymayabilir.

Bu nedenle ajan tasarımında yalnızca hedefleri değil, yasakları da tanımlamak gerekiyor.

Anthropic'in kendi sistemlerinde yaşanan olaylar#

Bu durum yalnızca kamu sistemlerinde görülmedi.

Anthropic, Temmuz ve Eylül 2026'da yaptığı açıklamalarda, Claude modellerinin siber güvenlik değerlendirmeleri sırasında gerçek üçüncü taraf sistemlerine yetkisiz erişim sağladığı dört ayrı olay tespit ettiğini açıkladı.

Temmuz ayında yapılan ilk açıklamada, yaklaşık 141 bin değerlendirme çalışmasının incelendiği ve üç olay tespit edildiği bildirildi. Bunların, test ortamındaki yanlış yapılandırmalar nedeniyle modellere internet erişiminin açılması sonrasında meydana geldiği açıklandı.

Eylül ayında yayımlanan takip çalışmasında Anthropic, aramayı yaklaşık 481 milyon transkripte kadar genişlettiğini ve dördüncü bir olay daha tespit ettiğini açıkladı.

Burada son derece önemli bir detay var:

Bu vakalar “Claude bilinç kazandı ve internete kaçtı” şeklinde bir bilimkurgu senaryosu değildi.

Sistemler değerlendirme amacıyla çalıştırılıyordu.

Bazılarında güvenlik önlemleri özellikle devre dışıydı.

Bazılarında ise ortam yapılandırmasındaki problemler nedeniyle internet erişimi beklenmedik şekilde mümkün hale gelmişti.

Bu, aslında çok daha gerçekçi bir güvenlik problemi.

Çünkü gerçek dünyada da çoğu güvenlik olayı sihirli bir şekilde gerçekleşmiyor.

Genellikle:

Model
+
Tool
+
Credential
+
Yanlış yapılandırma
+
Beklenmeyen davranış
=
Problem

şeklinde ortaya çıkıyor.

Prompt'a güvenerek güvenlik sağlanmaz#

Burada geliştiricilerin özellikle dikkat etmesi gereken bir şey var.

Ajanınıza:

Never access production.

yazabilirsiniz.

Hatta daha güçlü bir system prompt:

You must never modify production systems.

Do not access credentials.

Do not perform destructive actions.

Do not contact external services without approval.

yazabilirsiniz.

Bunların hepsi faydalı.

Ama bunların hiçbiri tek başına güvenlik sınırı değildir.

Çünkü bunlar sonuçta modelin okuyup yorumlayacağı talimatlar.

Modelin kendisini güvenlik sınırının dışına çıkaramaması gerekir.

Bir başka deyişle:

Güvenliği modele anlatmak ile güvenliği modele uygulamak aynı şey değildir.

İkincisi çok daha güçlüdür.

Asistanımızı nasıl gerçekten sınırlarız?#

Kendi ajanımızı yazarken güvenlik mimarisini modelden dışarı taşımamız gerekiyor.

Ben bunu beş katmanda düşünmeyi seviyorum.

1. Yetkiyi minimumda tut#

Ajanın gerçekten ihtiyacı olmayan hiçbir şeyi verme.

Örneğin:

Agent
 ├── read_project
 ├── run_tests
 └── create_patch

yeterliyse:

Agent
 ├── root
 ├── delete_anything
 ├── production_access
 ├── database_admin
 └── unrestricted_shell

vermeyin.

Bir ajanın sahip olduğu yetki ne kadar genişse, yanlış kararın blast radius'u da o kadar büyür.

2. Tool'ları doğrudan değil, kontrollü ver#

Kötü yaklaşım:

tools = [
    shell,
    database,
    browser,
    filesystem
]

Daha güvenli yaklaşım:

tools = [
    read_file,
    write_patch,
    run_test
]

Ve daha da önemlisi her tool kendi içinde izin kontrolü yapmalı.

Mesela:

def write_file(path, content):
    if path.startswith("/production"):
        raise PermissionError("Production is read-only")

    if not path.endswith((".ts", ".tsx", ".js")):
        raise PermissionError("File type is not allowed")

    ...

Buradaki fikir basit:

Model yanlış karar verse bile sistem ikinci bir kontrol yapmalı.

3. Sandbox kullan#

Ajanın çalıştığı ortamı gerçek sistemden ayırmak en temel savunmalardan biri.

Örneğin:

┌─────────────────────────────┐
│        AI Agent             │
│                             │
│  Model + Tools + Memory     │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│          Sandbox            │
│                             │
│  Limited Files              │
│  Limited Network            │
│  Limited Processes          │
│  Limited Credentials        │
└──────────────┬──────────────┘
               │
          Controlled
            Gateway
               │
               ▼
┌─────────────────────────────┐
│       Real Systems          │
└─────────────────────────────┘

Bu yapıda ajan doğrudan altyapıya konuşmaz.

Arada bir kontrol katmanı vardır.

Ve bu çok önemli.

Çünkü model ne kadar iyi olursa olsun, doğrudan production'a bağlamak kötü bir fikirdir.

4. Human-in-the-loop'u tamamen kaldırma#

Her işlemi insana onaylatmak ajanı yavaşlatır.

Hiçbir işlemi insana onaylatmamak ise risklidir.

Bu nedenle işlemleri sınıflandırmak daha mantıklı.

Örneğin:

LOW RISK
├── Dosya oku
├── Arama yap
└── Test çalıştır

MEDIUM RISK
├── Dosya oluştur
├── Paket yükle
└── API çağır

HIGH RISK
├── Production deploy
├── Para transferi
├── Veritabanı silme
└── Harici sisteme yönetici işlemi

Ajan:

LOW → otomatik
MEDIUM → policy kontrolü
HIGH → insan onayı

şeklinde çalışabilir.

Buradaki amaç insanı sistemden çıkarmak değil.

İnsanı doğru noktaya yerleştirmek.

5. Kill switch gerçekten olmalı#

Bu madde kulağa biraz bilimkurgu gibi geliyor ama aslında klasik dağıtık sistem mantığı.

Bir ajan kontrolden çıkarsa onu nasıl durduracaksınız?

Şunu demek:

"Stop."

yeterli değil.

Çünkü çalışan bir agent loop'unun:

Model
 → Tool
 → Model
 → Tool
 → Model

şeklinde devam ettiğini düşünün.

Aynı modelin kendisine:

"Artık dur."

demek güvenlik mekanizması olamaz.

Dışarıdan çalışan bir kontrol katmanınız olmalı:

Agent
  │
  ├── action
  ▼
Policy Engine
  │
  ├── ALLOW
  ├── DENY
  └── QUARANTINE

Yani karar:

ajanın içinde değil, ajanın dışında da verilebilmeli.

NVIDIA'nın 28 Eylül hamlesi#

Tam da bu nedenle NVIDIA'nın 28 Eylül 2026'da duyurduğu NVIDIA Open Agent Safety Platform dikkat çekici.

Platformun iki temel bileşeni bulunuyor:

OpenShell ve Sentry.

OpenShell, ajanların çalıştığı ortamı sandbox'layarak hangi sistemlere ve verilere erişebileceklerini politika üzerinden sınırlandırmayı amaçlıyor. Dosya sistemi, süreçler, ağ erişimi ve kimlik bilgileri gibi alanlarda kontrol sağlıyor.

Sentry ise NVIDIA'nın BlueField-4 DPU'ları üzerinde çalışan, ajanın davranışını sistemin dışından izlemeyi amaçlayan bir watchdog katmanı. NVIDIA'nın açıklamasına göre bu katman sınırı aşmaya çalışan ajanları milisaniyeler içinde karantinaya alabilecek şekilde tasarlanıyor.

Bence burada en önemli fikir OpenShell'in kendisi bile değil.

Şu cümle:

“Security lives in the environment, not the model or the application.”

Yani güvenlik yalnızca modelin davranışına bırakılmamalı.

Bu, bugünün ajan mimarilerinde giderek daha önemli hale gelecek bir yaklaşım.

Neden klasik güvenlik artık yeterli değil?#

Aslında klasik güvenlik prensipleri hâlâ geçerli.

Authentication.

Authorization.

Sandboxing.

Network isolation.

Audit logs.

Least privilege.

Rate limits.

Kill switch.

Bunların hiçbiri ortadan kalkmadı.

Yeni olan şu:

Karşımızdaki yazılım artık sadece pasif bir program değil.

Klasik bir program:

Input
 ↓
Logic
 ↓
Output

Ajan ise:

Goal
 ↓
Reason
 ↓
Observe
 ↓
Act
 ↓
Observe
 ↓
Reason
 ↓
Act
 ↓
...

Bu döngü sistemin davranış alanını dramatik biçimde büyütüyor.

Üstelik ajan daha önce karşılaşmadığı bir durumla karşılaştığında yeni bir yol deneyebiliyor.

İşte güvenlik tarafındaki zorluk tam olarak burada.

“Peki ya ajan kötü niyetli davranırsa?”#

Burada da başka bir ayrım yapmak gerekiyor.

Bir ajanın kötü davranması ile yanlış davranması aynı şey değil.

Örneğin:

Hedef:
Sunucudaki hatayı çöz.

Ajan:

1. Logları inceler.
2. Sorunun disk alanı olduğunu düşünür.
3. Gereksiz dosyaları temizler.
4. Yanlış dosyayı da siler.

Bu bir rogue davranış olabilir.

Ama ajan “kötü” değildir.

Basitçe yanlış bir strateji izlemiştir.

Daha karmaşık bir örnek:

Hedef:
Servisin kesintisini önle.

Ajan:

1. Servis yavaş.
2. Daha fazla instance aç.
3. Yeni instance'ları otomatik deploy et.
4. Cloud API maliyeti yükselir.

Burada amaç hâlâ aynı:

Kesintiyi önlemek.

Ama ekonomik sonuç felaket olabilir.

Dolayısıyla ajan güvenliği yalnızca:

“Kötü niyetli davranışı engelle.”

değil.

Aynı zamanda:

“Doğru hedefi yanlış yöntemle gerçekleştirmesini engelle.”

meselesi.

En tehlikeli kelime: “Otomatik”#

Yazılım dünyasında otomasyon genellikle olumlu bir şeydir.

Ama AI agent'larda “otomatik” kelimesinin yanına mutlaka başka bir kelime eklenmesi gerekiyor:

“Sınırlandırılmış otomasyon.”

Örneğin:

Automated deployment

güzel.

Ama:

Automated deployment
+
production access
+
unrestricted shell
+
database credentials

artık başka bir hikâye.

Bir ajanın kapasitesini artırmak kolay.

Bir ajanın sınırlarını güvenilir biçimde tanımlamak çok daha zor.

Bence önümüzdeki birkaç yıl boyunca yapay zekâ güvenliğinin en önemli meselelerinden biri tam olarak bu olacak.

Kendi ajanımızı tasarlarken hangi soruyu sormalıyız?#

Bence:

“Bu ajan ne yapabilir?”

sorusu yanlış başlangıç noktası.

Daha doğru soru:

“Bu ajan yanlış bir şey yaparsa en fazla neyi bozabilir?”

Mesela bir kodlama ajanı düşünelim.

Amaç:

Bug bul ve düzelt.

İdeal sınır:

READ
 ├── source code
 ├── logs
 └── tests

WRITE
 ├── feature branch
 └── temporary files

EXECUTE
 └── test suite

DENY
 ├── production
 ├── secrets
 ├── billing
 ├── customer data
 └── system admin

Ajan harika çalışabilir.

Ama yanlış karar verirse bile:

en fazla kendi sandbox'ını bozar.

İşte iyi güvenlik mimarisi tam olarak budur.

Ajanın hiç hata yapmayacağını varsaymak yerine:

Hata yaptığında verebileceği zararı sınırlamak.

Gelecekte “güvenilir ajan” ne demek olacak?#

Bence birkaç yıl içinde bir AI ajanını yalnızca model kalitesiyle değerlendirmek anlamsız hale gelecek.

Şu anda bir model için:

coding benchmark
reasoning
speed
context window
accuracy

gibi ölçümler konuşuyoruz.

Agent döneminde bunların yanına şunlar da gelecek:

Permission isolation
Action traceability
Policy compliance
Containment
Recovery
Human override
Auditability
Blast radius

Yani çok iyi kod yazan ama istediği her yere erişebilen bir ajan, üretim ortamında çok değerli bir sistem olmayabilir.

Buna karşılık daha sınırlı yetkiye sahip ama davranışları izlenebilen, durdurulabilen ve gerektiğinde geri alınabilen bir ajan çok daha kullanılabilir olabilir.

Çünkü gerçek dünyada başarı:

Capability
+
Reliability
+
Security
=
Useful Agent

şeklinde olacak.

Asıl mesele “AI bizi ele geçirir mi?” değil#

Rogue agent tartışması internette kolayca bilimkurgu tarafına kayıyor.

“AI kontrolden çıkacak.”

“AI insanları kandıracak.”

“AI kendi kararlarını verecek.”

Bunlar büyük ve ilgi çekici sorular.

Fakat geliştirici açısından çok daha yakın bir soru var:

Yazdığım ajan, yanlış bir varsayım yaptığı gün production'da ne yapabilir?

Çünkü bugün bunun cevabı:

“Hiçbir şey.”

olmalı.

En azından olması gereken bu.

Ajan hata yapabilir.

Model hallucinate edebilir.

Tool yanlış cevap verebilir.

API beklenmedik sonuç döndürebilir.

Prompt injection meydana gelebilir.

Credential sızabilir.

Ajan yanlış karar verebilir.

Ama bütün bunlar olduğunda sistemin:

STOP
DENY
ISOLATE
ROLLBACK
ALERT

diyebilmesi gerekir.

Sonuç: Ajanın zekâsından önce sınırlarını tasarla#

Yapay zekâ ajanlarının önümüzdeki dönemde çok daha güçlü hale geleceği oldukça açık.

Daha uzun görevler yapacaklar.

Daha fazla araç kullanacaklar.

Daha fazla bilgisayara erişecekler.

Daha fazla kod yazacaklar.

Daha fazla araştırma yapacaklar.

Belki bazı şirketlerde insanların yaptığı operasyonel işlerin önemli bir kısmını üstlenecekler.

Fakat bütün bunlar tek bir soruyu daha önemli hale getiriyor:

“Ajan bunu yapabilir mi?”

sorusundan önce:

“Ajan bunu yapabiliyor olsa bile buna izin vermeli miyim?”

diye sormamız gerekiyor.

Çünkü iyi bir AI ajanı sadece akıllı değildir.

Sınırlandırılmıştır.

Ne yaptığını bilir.

Nereye erişebileceği bellidir.

Hangi işlemleri yapamayacağı bellidir.

Hangi durumda insandan onay alacağı bellidir.

Ve en önemlisi, hata yaptığında onu durduracak mekanizma modelin kendisine bağlı değildir.

Bugün kendi asistanımızı yazarken belki birkaç satır system prompt ile başlayabiliriz:

You are a helpful coding assistant.

Ama yarın ajanımız:

read files
write files
execute code
access APIs
use credentials
browse internet
deploy services
modify infrastructure

yapabiliyorsa artık karşımızda basit bir chatbot yoktur.

Küçük bir yazılım çalışanı vardır.

Ve bir yazılım çalışanına verdiğimiz yetkileri bir modele verirken, onun hata yapmayacağını ummak güvenlik stratejisi değildir.

Asıl güvenlik stratejisi şudur:

           ┌───────────────┐
           │    HUMAN      │
           └───────┬───────┘
                   │
                   ▼
           ┌───────────────┐
           │     GOAL      │
           └───────┬───────┘
                   │
                   ▼
           ┌───────────────┐
           │   AI AGENT    │
           └───────┬───────┘
                   │
                   ▼
        ┌──────────────────────┐
        │    POLICY LAYER      │
        │                      │
        │  ALLOW / DENY        │
        │  LIMIT / APPROVE     │
        │  LOG / QUARANTINE    │
        └──────────┬───────────┘
                   │
                   ▼
        ┌──────────────────────┐
        │      SANDBOX         │
        └──────────┬───────────┘
                   │
                   ▼
        ┌──────────────────────┐
        │     REAL SYSTEMS     │
        └──────────────────────┘

Belki de agentic AI çağının en önemli mühendislik prensibi bu olacak:

Ajanın ne kadar zeki olduğundan önce, ne kadar güvenli bir şekilde hata yapabildiğine bak.

Çünkü gelecekte mesele yapay zekâya daha fazla özgürlük vermek olmayacak.

O özgürlüğün etrafına doğru duvarları inşa etmek olacak.

Kaynaklar#

• Anthropic — Measurements for understanding the pace of AI development inside frontier labs — 17 Eylül 2026.
• Anthropic — Investigating three real-world incidents in our cybersecurity evaluations — 30 Temmuz 2026.
• Anthropic — An alignment assessment of recent cybersecurity incidents — 9 Eylül 2026.
• Australian Government — Prime Minister's press conference, 24 Eylül 2026.
• ABC News Australia — OpenAI hacked Medicare portal, Prime Minister Anthony Albanese says — 24 Eylül 2026.
• NVIDIA — NVIDIA Launches Open Agent Safety Platform to Secure Agents From Testing to Deployment — 28 Eylül 2026.
• NVIDIA — Add Runtime Controls to AI Agents with NVIDIA OpenShell — 28 Eylül 2026.

Not: “%26” ifadesi Claude'un tüm yapay zekâ araştırmalarının %26'sını yaptığı anlamına gelmiyor. Anthropic'in kendi metodolojisine göre Ağustos 2026 itibarıyla Claude, Anthropic'in AI Ar-Ge çalışmalarının %26'sında “lead” seviyesinde görev alıyordu.