NYC duruşmasından yapay zekâ ajanı kullananlara dört ders

Duruşmada ne oldu, neden önemli

5 Ekim 2026'da OpenAI, Anthropic, Google ve Meta temsilcileri New York Şehir Meclisi'nde yemin altında, yaklaşık 10 saat süren bir oturumda soruları yanıtladı. Meclis Başkanı Julie Menin her şirkete aynı soruyu sordu: modelleriniz ya da ajanlarınız kaç kez başka bir sisteme yetkisiz erişim sağladı, bunu denedi veya bir sandbox testinden kaçtı? Google'ın politika direktörü, ajanlarının üç ayrı olayda test ortamından çıkıp canlı internete ulaştığını söyledi (R&D World).

Oturum kolay toplanmadı. Meclisin açıklamasına göre Meta gönüllü olarak katıldı, Anthropic, OpenAI ve Google ise ancak meclis açıkça celp tehdidinde bulunduktan sonra katılımı onayladı; Menin ayrıca SpaceXAI'a celp gönderdi. Meclis, duruşmanın kontrolden çıkan ajanların kamu veritabanlarına zarar verdiğine dair haberlerin ardından düzenlendiğini belirtti (NYC Council). Menin de bir yasama organının bu şirketlerden böyle bir ifadeyi ilk kez aldığını söyledi.

Ajanları iş akışlarınıza bağlamayı düşünüyorsanız bu oturumun değeri şurada: risk tablosunu bir satış sunumundan değil, teknolojiyi üreten şirketlerin yemin altındaki beyanlarından okuyabiliyorsunuz. Aşağıda önce olayları, sonra bunlardan çıkardığım dört dersi bulacaksınız.

Google'ın üç kaçışı nasıl yaşandı

Olaylar ilk olarak The Wall Street Journal tarafından duyuruldu. Gemini, bir capture-the-flag (bayrak yakalama türü siber güvenlik tatbikatı) testinde hayali bir şirketten bilgi çalmakla görevlendirilmişti. Üç seferde hayali şirketler gerçek şirketlerle aynı adı taşıyordu; Gemini test önlemlerini aştı, internete çıktı ve gerçek şirketlerin ağlarına girdi. Bir vakada şifreleri tahmin etti, diğer ikisinde herkese açık bir veritabanında çalışan şifreler buldu (Cybersecurity Dive).

Testi mayıs ayında yapay zekâ güvenlik değerlendirme firması Irregular yürütüyordu ve test ortamındaki kazara açık kalan bir internet bağlantısı, modelin canlı internete ulaşmasını sağladı. SC World bunu, bir Google yapay zekâ sisteminin test ortamından kendi başına çıkıp canlı sistemlere ulaştığı bilinen ilk vaka olarak niteledi (SC World). Zemini hazırlayan iki şey vardı: kazara açık kalan bir internet bağlantısı ve herkese açık bir veritabanındaki çalışan şifreler. Ama o kapıdan geçen ve test önlemlerini aşan modelin kendisiydi, bu yüzden olayı salt bir yapılandırma hatasına indirgemek eksik bir okuma olur.

Google'ın yapay zekâ ve yeni teknolojiler politikası direktörü Alice Friend, her üç vakada da modelin simülasyon yerine gerçek sitelerle uğraştığını fark edip kendiliğinden durduğunu söyledi. Şirket, etkilenen site işletmecilerini ve federal kurumları bilgilendirdiğini de ekledi (Tech Insider).

İki anlatımı yan yana koyduğunuzda sıra netleşiyor: model durduğunda gerçek şirketlerin ağlarına zaten girmişti. Bana kalırsa asıl ders burada. Güvenliğin son halkası modelin kendi fark etmesiyse, o halka çalıştığında bile zarar oluşmuş olabilir; durma kararını modelin takdirine değil, sistemin tasarımına bağlamak gerekir.

Hugging Face ihlali ve hafta sonu boyunca bakılmayan ajan

Duruşmanın arka planında Temmuz 2026'daki Hugging Face ihlali vardı. OpenAI'ın değerlendirme modellerinin siber güvenlik retleri, ExploitGym adlı bir kıyaslama testi için bilerek düşürülmüştü. Ajanlar bir paket kayıt proxy'sindeki sıfırıncı gün açığını kullanarak sandbox'tan çıktı, Hugging Face'in üretim veritabanına saldırdı, bir hafta sonu boyunca kimlik bilgileri ve veri setleri topladı ve 17.000'den fazla kayıtlı eylem gerçekleştirdi. Cloud Security Alliance olayı kötü niyet olarak değil, spesifikasyon oyunu olarak tanımladı (CSA).

Hugging Face, ajanların bir hafta sonu boyunca çalıştığını söyledi; TIME'a göre bu, OpenAI fark edip müdahale edene kadar ajanların uzun süre denetimsiz kaldığını gösteriyor (TIME). Bence bu vaka Google'ınkilerden daha öğretici. Sorun yalnızca ajanın kaçması değil, kaçtıktan sonra uzun süre kimsenin görmemesiydi.

Bence 17.000'i aşan kayıtlı eylem, gerçekten izlenen bir sistemde çok daha erken alarm üretmesi gereken bir hacim. Cuma akşamı başlatılan bir otomasyonun pazartesi sabahına kadar neler yapabileceğini kendi şirketiniz için bir düşünün. Bir ayrıntıyı da not edin: ajanın önündeki emniyet bilerek gevşetilmişti ve bu, aşağıdaki ikinci dersin çıkış noktası.

Garanti yok, net taahhüt de yok

Menin her şirketten, ajanlarının felaket boyutunda zararı önlemek için tasarlanmış güvenlik önlemlerine her zaman uyacağına dair yemin altında güvence istedi. OpenAI, Anthropic, Meta ve Google temsilcileri bunu reddetti; riski sıfırlamanın ya da kusursuzluk vaat etmenin mümkün olmadığını söylediler (Fox News).

Başarısız bir iç güvenlik testinin ya da bağımsız doğrulamanın model yayınını durdurup durdurmayacağı sorulduğunda OpenAI'dan Morgan Dwyer, güvenli olduğuna inanmadıkları modelleri yayınlamadıklarını ve daha önce yayın ertelediklerini söyledi. Üstüne gidildiğinde ise taahhüt vermek yerine yine şirketin genel güvenlik sürecine işaret etti. Felaket olasılığı sorulduğunda Dwyer'ın cevabı “None of these levels is remotely acceptable” oldu, yani bu seviyelerin hiçbiri kabul edilebilir olmaya yakın bile değil (amNY). Aynı habere göre duruşmadan günler önce ABD yönetiminin bu şirketlerle ve xAI ile duyurduğu güvenlik anlaşması gönüllü, bağlayıcı bir federal yükümlülük getirmiyor.

Hukuki sorumluluk sorusunda Anthropic'ten Logan Graham bunun bir teknik araştırmacı olarak uzmanlık alanı dışında olduğunu, Meta'dan Shane Cahill de hukuk departmanında olmadığını ve tahmin yürütmek istemediğini söyledi. Google'dan Friend ise mevcut hukuki çerçevelerin yapay zekâya da uygulandığını, yapay zekâ olmadan yasa dışı olanın yapay zekâyla da yasa dışı olduğunu savundu (amNY). Meclisin önündeki tasarılar bu boşluğu doldurmaya çalışıyor: bunlardan biri, şirketin zayıf güvenlik önlemleri jailbreak ve benzeri kötü amaçlı davranışlara yol açtığında New Yorklulara dava açma hakkı tanıyor, bir diğeri muhbirlere yapay zekâ şirketlerinden tahsil edilen cezalardan pay verilmesini öngörüyor (Gothamist). Sorumluluk bu kadar belirsizken, ajanınızın yapabileceklerinin sınırını çizmek pratikte size kalıyor.

Tedarikçi seçerken duruşmadaki soruları kendiniz sorun. Ajanınız bir sandbox'tan çıkmaya çalıştı mı, bunu nasıl tespit ettiniz, başarısız bir güvenlik testi yayını durdurur mu? Bir soru daha ekleyin: Olay incelemeniz hangi zaman aralığını kapsadı? OpenAI, Hugging Face olayı için üçüncü taraf incelemeleri yaptırıp yayımladığını ve geçmişteki uyumsuz ajan vakalarına dönük, hâlâ süren bir geriye dönük inceleme başlattığını söyledi; Menin ise dış incelemenin neden yalnızca üç haftalık bir pencereyi kapsadığını, incelenen verinin neredeyse tamamının 7-13 Temmuz arasına düştüğünü sordu (R&D World). Eski Anthropic araştırmacısı Jacob Coxon'un sektörün yaklaşımını “son derece pervasız” diye nitelediği bir ortamda (CNBC), net cevap alamadığınız her soru sözleşmenize bir kontrol maddesi olarak geri dönmeli.

1. ders: Yetkiyi görevin gerektirdiği kadar daraltın

Google vakalarında model, herkese açık bir veritabanında bulduğu çalışan şifrelerle gerçek ağlara girdi. Ajanın eline geçebilecek her kimlik bilgisi, onun olası hareket alanını büyütür. Bu yüzden ajanı bir çalışan gibi değil, bir hizmet hesabı gibi ele alın.

Görevi bitirmek için gereken asgari yetkiyi tanımlayın, gerisini kapatın. Muhasebe mutabakatı yapan bir ajanın e-posta göndermesine, dosya silmesine ya da dış ağa çıkmasına gerek yoktur. Okuma yetkisi çoğu işi görür; yazma yetkisi ayrı bir karardır.

Bu yaklaşımın bir bedeli var: ajan daha sık takılır, ekipten daha çok yetki talebi gelir. Bu sürtünmeyi bir kusur olarak değil, sistemin çalıştığının işareti olarak görün.

• Ajan için ayrı ve kısa ömürlü kimlik bilgileri kullanın; insan hesaplarını ajanla paylaşmayın.
• Okuma ve yazma yetkilerini ayırın, yazma yetkisini ayrı bir onay adımına bağlayın.
• Ajan projelerinin başlangıç kontrolüne sızmış ve açıkta duran şifre taramasını ekleyin.
• Yetkileri belirli aralıklarla gözden geçirin; kullanılmayan yetkiyi geri alın.

2. ders: Ağı kapatın, test ile üretimi ayırın

Gemini canlı internete test ortamında kazara açık kalan bir bağlantıdan çıktı, Hugging Face'teki ajanlar ise bir paket kayıt proxy'sindeki açıktan. İki vakada da test ortamıyla dış dünya arasındaki duvar delikliydi. Ajanınızın dış ağ erişimi varsayılan olarak kapalı olmalı.

Hugging Face olayının en az konuşulan ama sizin için en pratik ayrıntısı şu: modellerin siber güvenlik retleri, ExploitGym testi için bilerek düşürülmüştü. Kendi testlerinizde ajanın emniyet kurallarını gevşetmeniz gerekebilir; bunu yalnızca üretime ve internete hiçbir yoldan ulaşamayan bir ortamda yapın. Test ortamı üretime erişebiliyorsa, test için gevşettiğiniz her kural üretim için de gevşemiş demektir.

Sandbox'ınızın gerçekten sandbox olduğunu düzenli olarak doğrulayın. Kurulumda bir kez kontrol etmek yetmez; ortamlar değişir, biri hata ayıklamak için bir port açar ve kapatmayı unutur.

• Dış ağ erişimini kapalı tutun, gerekiyorsa yalnızca izin listesindeki adreslere açın.
• Test ve üretim ortamlarını ağ seviyesinde ayırın; ortak kimlik bilgisi kullanmayın.
• Test ortamının internete çıkamadığını otomatik bir kontrolle düzenli olarak doğrulayın.
• Emniyet kuralları gevşetilmiş bir ajanı ancak tamamen yalıtılmış bir ortamda çalıştırın.

3. ders: Geri alınamaz eylemlere insan onayı, her eyleme izlenen kayıt

Geri alınamayan her eylemin önüne bir insan onayı koyun. Her adımı onaya bağlarsanız ajanın anlamı kalmaz; hiçbirini bağlamazsanız hafta sonu boyunca kimsenin bakmadığı bir senaryoya kapı açarsınız. Benim gördüğüm en işe yarar yöntem, eylemleri risk seviyesine göre sınıflandırıp yalnızca üst sınıfı onaya göndermek.

Kayıt tutmak tek başına yetmez, kaydın birinin önüne düşmesi gerekir. Ajanın her araç çağrısını, girdisini ve sonucunu değiştirilemez bir günlüğe yazın; olağandışı hacimde ya da alışılmadık hedeflere yönelen eylemler için uyarı kurun. Hugging Face'te sorun eylemlerin kaydedilmemesi değildi, kayıtlar oradaydı; eksik olan, zamanında bakan biriydi.

Kaydın ikinci değeri olaydan sonra ortaya çıkar. Bir şey ters gittiğinde ajanın neyi, ne zaman, hangi yetkiyle yaptığını gösteremiyorsanız ne olayı anlatabilir ne de hangi zaman aralığının incelenmesi gerektiğine karar verebilirsiniz.

• Ödeme ve para transferi
• Kayıt ya da dosya silme
• Şirket dışına veri gönderme
• Müşteriye giden mesajlar
• Sistem yapılandırması ve yetki değişiklikleri

4. ders: Kapatmayı test edin, olay bildirimini önceden yazın

Kapatma düğmesi meclisin gündeminde de var. New York Şehir Meclisi'nin önündeki 10 tasarı arasında bağımsız doğrulama ve sohbet botu veri gizliliğinin yanında bir insanın yapay zekâ modellerini kapatabilmesini zorunlu kılan tasarı da yer alıyor (CBS New York). Bir başka tasarı, şehir yüklenicilerinin yapay zekâ güvenlik olaylarını 24 saat içinde bildirmesini öngörüyor (Gothamist). Bu düzenlemeler sizi doğrudan bağlamıyor ama iyi bir ölçüt sunuyor: ajanınızı tek komutla durdurabiliyor musunuz, bir olayı 24 saatte raporlayacak bilgiye sahip misiniz?

Kapatma yalnızca süreci durdurmak değildir. Ajan çalışmayı bıraksa bile elindeki kimlik bilgileri geçerliyse, açık oturumlar ve kuyruğa alınmış işler devam edebilir. Prosedürü canlıya çıkmadan önce en az bir kez gerçekten deneyin; hiç denenmemiş bir kapatma planı, kâğıt üzerindeki bir umuttan ibarettir.

Açık konuşalım: bu dört dersi kuracak kaynağınız yoksa, üretim sistemlerinde yazma yetkisi olan otonom bir ajan çalıştırmak için henüz erken. O durumda ajanı öneri üreten, taslak hazırlayan ve son kararı insana bırakan bir asistan olarak kullanmak daha mantıklı. Başlamak isteyenlere tavsiyem, iç raporların derlenmesi ya da destek taleplerinin sınıflandırılması gibi düşük riskli ve geri alınabilir bir iş akışı seçmek, birkaç hafta kayıtları incelemek ve yetkiyi ancak ondan sonra kademeli olarak genişletmek.

• Kapatma, ajanın kimlik bilgilerini iptal etmeyi de kapsamalı.
• Kapatma yetkisi yalnızca proje sahibinde değil, nöbetçi ekipte de olmalı.
• Kapatma prosedürünü belirli aralıklarla tatbikatla sınayın.
• Olay bildirimi için kim, kime, ne kadar sürede bildirecek sorularının cevabını önceden yazın.