Ajan güvenliği model seçimiyle bitmez: METR’nin iki güvenlik olayından dersler

Bir ajan uygulamasını Google ile girişin arkasına koymak, içindeki API anahtarını ve erişebildiği veriyi korumaya yetmeyebilir. METR (Model Evaluation and Threat Research), yapay zekâ modellerini değerlendiren ve bu modellerin oluşturabileceği tehditleri araştıran kâr amacı gütmeyen bir kuruluştur. Kurumun iki güvenlik olayı, kimlik doğrulamadan harcama sınırına kadar uzanan işletim kararlarının bir hatanın sonuçlarını nasıl değiştirdiğini gösteriyor.

Mart 2026’da bir METR araştırmacısı, kişisel EC2 sunucusunda ajanları yöneten bir uygulama çalıştırıyordu. Uygulama internete açıktı, ancak erişim Google ile kimlik doğrulama gerektiriyordu. Sunucuda, kurumun kamuya açık modelleri kullanmak için aldığı bir API anahtarı bulunuyordu.

Uygulamadaki bir hata kimlik doğrulamayı sessizce devre dışı bıraktı. Sistem birkaç gün boyunca internetteki herkesin erişebileceği durumda kaldı. Bir saldırgan uygulamayı buldu, ajandan model sağlayıcısının API anahtarını göstermesini istedi ve anahtarı ele geçirdi.

METR, bu olayı ve mayıs ayında yaşadığı ikinci olayı 31 Ağustos 2026 tarihli güvenlik açıklamasında anlatıyor. Olayların ayrıntıları, kurumun ve birlikte çalıştığı güvenlik danışmanının incelemesine dayanıyor. METR, iki olayda da hassas bilgilere erişilmediğine inanıyor. Bu değerlendirme, aşağıdaki teknik derslerin yanında korunması gereken bir kanıt sınırı.

Fail-open: Kontrol hata verdiğinde erişimin açık kalması

Fail-open, bir güvenlik kontrolü hata verdiğinde erişimi durdurmak yerine sistemi açık bırakan davranıştır. Kimlik doğrulama bağlamında, kullanıcının kimliği doğrulanamadığı hâlde isteğin kabul edilmesi buna örnektir.

Karşılığı olan fail-closed yaklaşımında, kimlik veya gerekli yetki doğrulanamıyorsa korunan işlem reddedilir.

METR’nin anlattığı ilk olayda, AI yardımıyla geliştirilen uygulamadaki fail-open açığı kimlik doğrulamayı devre dışı bırakmıştı. Google ile giriş kullanılması, uygulamanın kendi erişim kontrolündeki hatayı engellememişti.

Buradan çıkan tasarım sorusu somut: Kimlik doğrulamanın çalıştığı durumda uygulamanın davranışını görmek yeterli mi? Oturum doğrulanamadığında, gerekli yapılandırma eksik olduğunda veya doğrulama bileşeni hata döndürdüğünde ne olacağı da sınanmalı.

Bu örneklerin her birinde METR’de ne olduğunu bilmiyoruz. Bunlar, aynı hata sınıfını kendi sisteminde araştıracak bir ekibin incelemesi gereken durumlar. Her fail-open açığı mutlaka sömürülür diye bir sonuç da çıkmıyor. Ancak erişim kontrolünün başarısızlığı, erişim iznine dönüşmemeli.

İlk olay: Bir anahtarın erişebildiği kaynaklar

Saldırgan, API anahtarını aldıktan sonra kalıcı erişim için sunucuya bir SSH anahtarı ekledi. Çalınan kimlik bilgileriyle üç hafta boyunca kamuya açık modellerde yaklaşık 600.000 dolar değerinde kredi tüketti.

Bu tutar, METR’nin ödediği bir fatura değildi. Model geliştiricisi kredileri kuruma ücretsiz vermişti. Olayı “600.000 dolar nakit kayıp” diye anlatmak, rapordaki ekonomik gerçeği değiştirir. Yine de kurum adına kullanılabilen bir kaynağın yetkisiz tüketildiği açık.

Saldırı zincirinde birkaç farklı kontrolün eksikliği birleşiyordu. İnternetten gelen kişi ajanı kullanabiliyor, ajan üzerinden bir sırra ulaşabiliyor ve elde ettiği anahtarı uygulamanın dışında kullanabiliyordu. SSH anahtarı da saldırgana sunucuya yeniden bağlanmak için bir erişim yolu sağlıyordu.

Kullanımı fark etmekte de sorun vardı. O tarihte METR’nin kullanım paneli, rate limit’e takılan isteklerin verisini bütün kullanıcılara göstermiyordu. Ücretsiz krediler nedeniyle doğal bir harcama tavanı oluşmamıştı. Rapora göre, bu tür anahtarlara harcama sınırı koyma imkânı da bulunmuyordu.

Kimlik doğrulama açığı ilk erişimi açıklıyor. Anahtarın erişilebilir olması saldırganın eline ne geçtiğini, kullanımın görünürlüğü ve sınırları ise bu erişimin ne kadar sürdürülebildiğini açıklıyor. Bunlar farklı mühendislik kararları.

METR müdahalede araştırmacının erişimlerini iptal etti, sunucuyu durdurup disk imajını aldı ve üzerindeki kimlik bilgilerini değiştirdi. Araştırmacının dizüstü bilgisayarı da imajlandıktan sonra silindi. İlgili model sağlayıcısı bilgilendirildi, güvenlik danışmanı incelemeye katıldı ve kurum dışı cihazlarda kimlik bilgisi kullanımıyla kamuya açık uygulama dağıtımına ilişkin politikalar değiştirildi.

Bu müdahale dizisi, bir araştırma uygulamasının güvenlik sorununun neden yalnızca o uygulamayı kapatmakla bitmeyebileceğini gösteriyor.

İkinci olay: Salt okunur erişim ve gizli veri

Mayıs 2026’da METR, kamuya açık altyapısını sistematik biçimde yoklayan saldırganlar gözlemledi. Faaliyetler arasında ele geçirilmiş kullanıcı adı ve parola çiftlerini deneme, OAuth üzerinden erişim elde etmeye çalışma, yeni servisleri tarama ve çalışanlara yönelik oltalama girişimleri vardı. Kurum, açık arama faaliyetlerinde ajanlarla otomasyon kullanıldığını da belirtiyor.

Aynı dönemde, model konuşma kayıtlarını gösteren bir uygulama üzerinden salt okunur SQL sorguları çalıştırılabilen bir mekanizma yanlışlıkla açığa çıkmıştı. Sorgular varsayılan olarak kamuya açık verilerle sınırlıydı. Ancak bir hata, yayımlanmamış değerlendirme verilerine erişmeyi mümkün kılıyordu. Veritabanına bazı hassas model çıktıları da yanlışlıkla eklenmişti.

Açığı bağımsız bir güvenlik araştırmacısı bulup bildirdi. METR ilgili servisi kapattı. Kurumun incelemesinde, saldırganların bu açığı keşfettiğine veya kamuya açık olmayan verilere eriştiğine dair kanıt bulunmadı.

Salt okunur yetki, verinin değiştirilmesini engelleyebilir. Gizliliği korumak için ayrıca hangi verinin okunabildiğini sınırlamak gerekir. Bir kullanıcıya yanlış kayıtları gösteren servis, hiçbir satırı değiştirmeden de veri sızıntısına yol açabilir.

Bu olayda sorgu kapsamındaki hata ile verinin yanlış yerde bulunması birlikte değerlendirilmek zorunda. Sorgu beklenmedik biçimde genişlediğinde erişilebilen veri, servisin yayımlamak için tasarlandığı verinin ötesine geçiyordu.

METR, kamuya açık uygulamalar için iç altyapıdan mimari olarak ayrılmış bir üretim ortamı oluşturduğunu açıklıyor. Kurum ayrıca yetki kapsamlarını daralttığını, kimlik bilgilerinin ömrünü kısalttığını ve uç nokta, sunucu güvenliği ile harici siber güvenlik desteğini artırdığını belirtiyor.

Güven sınırı ve bir hatanın etki alanı

Bu iki olayı birlikte okumak için iki kavram yeterli: güven sınırı ve etki alanı.

Güven sınırı, bir sistemin farklı erişim ve yetki kurallarına tabi bölümleri arasındaki ayrımdır. İnternetten gelen bir isteğin ajan araçlarını çalıştırabilmesi, ajanın bir API anahtarına ulaşması ve kamuya açık bir servisin iç veriyi okuyabilmesi ayrı ayrı denetlenmesi gereken geçişlerdir.

Etki alanı, yani blast radius, bir bileşen ele geçirildiğinde saldırganın ulaşabileceği kaynakların ve yapabileceği işlemlerin kapsamıdır. Uygulamanın küçük olması, etki alanının da küçük olduğu anlamına gelmez. Kişisel bir sunucudaki araştırma aracı, kurum adına yüksek miktarda kaynak kullanabilen bir anahtar taşıyabilir.

İlk olayda uygulamaya erişmek, kurumun model kullanımına uzanan bir yol açtı. İkinci olayda kamuya açık bir servisteki hata, yayımlanmaması gereken verilere erişim ihtimali doğurdu.

Bu olaylardan çıkarılabilecek tasarım ilkesi, bir kontrolün başarısızlığından sonra hangi kontrolün hâlâ ayakta kalacağını belirlemek. Kimlik doğrulama bozulduğunda sır yönetimi, veri izolasyonu ve kullanım sınırları çalışmaya devam edebilmelidir.

Ajanı devreye almadan önce işletim sınırlarını kurmak

Bu olaylardan hareketle bir dağıtım kararı verirken, kontrolleri azalttıkları risk üzerinden değerlendirmek mümkün. Aşağıdaki önerilerin uygun kapsamı, ajanın yaptığı işe ve erişeceği kaynaklara göre değişir.

Kimlik doğrulamanın hata durumunda korunan işlemi reddetmesi başlangıç noktasıdır. Erişim kararı, sunucu tarafında ilgili uç noktada uygulanmalı. Bir giriş ekranının varlığı, arka plandaki bütün işlevlerin korunduğunu göstermeye yetmez. Bu kontrollerin hata senaryoları, uygulama internete açılmadan önce sınanmalı. Fail-closed davranışının meşru işi durdurabileceği durumlar için de işletim planı gerekir.

Kimliği doğrulanan kullanıcının ve onun adına çalışan ajanın yetkileri ayrıca sınırlandırılmalı. Bir görevin yalnızca belirli kayıtları okuması gerekiyorsa, veritabanının tamamına erişim vermek o görevin gereksinimini aşar. Benzer biçimde, model çağrısı yapan bir ajanın sunucudaki erişim ayarlarını değiştirebilmesi ayrı bir yetkidir. Her izin, hangi iş için gerektiği üzerinden gerekçelendirilmeli.

Sır yönetiminde, anahtarın nerede saklandığı kadar hangi bileşenin onu okuyabildiği de belirleyicidir. Ajan aynı sürecin ortam değişkenlerini okuyabiliyorsa, anahtarı kaynak kodundan çıkarıp ortam değişkenine taşımak bu erişimi kesmez. Mümkün olduğunda sağlayıcıyla iletişim kuran bileşen, ajanın okuyabildiği çalışma alanından ayrılmalı. Dar kapsamlı ve kısa ömürlü kimlik bilgileri de ele geçirilen erişimin kullanılabileceği alanı ve süreyi azaltır.

Kullanım takibi, başarılı istek sayısını göstermekle sınırlı kalmamalı. Tüketimin hangi anahtardan, hangi işten ve hangi zaman aralığında geldiği görülebilmeli. Rate-limit hataları ile beklenmedik kullanım değişimleri, o sırada yürütülen işler bağlamında değerlendirilmeli. Bir alarmın kime ulaşacağı ve o kişinin kullanımı nasıl durduracağı da bu tasarımın parçasıdır.

Harcama uyarısı ile harcama sınırı farklı iş yapar. Uyarı birinin müdahalesini bekler. Uygulanan sınır tüketimi durdurur veya kısıtlar. Sağlayıcı tarafında sınır konulamıyorsa, yalnızca kendi uygulamanızdaki sayaç çalınan anahtarın başka bir yerden kullanılmasını engellemez. Üretim kararı bu açığı hesaba katmalı.

Kamuya açık servislerin veri erişimi de amaçlarıyla sınırlanmalı. Yalnızca yayımlanmış kayıtları gösteren bir uygulamanın, iç değerlendirme verilerine doğrudan erişmesi gerekmeyebilir. Ayrılmış veri deposu ve sınırlı servis kimliği, uygulamadaki bir hatanın ulaşabileceği veriyi azaltır. Bu ayrımın korunması, dışarı aktarılacak verinin doğru seçilmesine de bağlıdır.

Olay sonrasında ne olduğunu anlayabilmek için denetlenebilir kayıtlar gerekir. Kullanıcı isteği, ajanın çalıştırdığı araç, ilgili servis kimliği ve yapılan veri erişimi birbirine bağlanabilmeli. Kayıtlara anahtarların veya gereksiz hassas içeriğin yazılması ise yeni bir erişim sorunu yaratır. Logların içeriği, erişim izinleri ve saklama koşulları birlikte düşünülmeli.

Son olarak erişimi kimin keseceği, hangi kimlik bilgilerinin değiştirileceği ve inceleme kanıtlarının nasıl korunacağı önceden belirlenmeli. Olay sırasında aynı anda hem saldırıyı durdurmaya hem ne olduğunu anlamaya çalışılır. Servisi yeniden açma kararının hangi bulgulara dayanacağı da müdahale planında yer almalı.

Bu raporun gösterdiği ve açık bıraktığı alan

METR’nin açıklaması, iki olayda hangi erişim yollarının oluştuğunu ve kurumun bunlara nasıl karşılık verdiğini anlamak için değerli. Bununla birlikte, kurum ve güvenlik danışmanının incelemesini aktaran bir olay raporu. Kamuya açık bağımsız bir denetim raporu sunulmuyor.

Hassas veriye erişildiğine dair kanıt bulunmaması ile erişimin kesin olarak dışlanması farklı iddialar. METR kendi değerlendirmesini bu sınır içinde ifade ediyor.

İki olaydan, ajan sistemlerinin ne sıklıkta ele geçirildiğini hesaplayamayız. Saldırganların ajan kullanmış olması da bu araçların sektör genelinde saldırı başarısını ne kadar artırdığını göstermiyor. Bunun için karşılaştırmalı veriler gerekir. Rapor, farklı modellerin aynı saldırı karşısındaki güvenliğini de karşılaştırmıyor.

Özerkliği, kurulmuş sınırlar içinde artırmak

Bir ajanı üretime alma kararında, hatalı bir isteğin hangi veriye ulaşabileceği ve ne kadar kaynak tüketebileceği açıklanabilmeli. Modelin davranışını değerlendirmek bu kararın bir parçası. Kimlik, yetki, veri ve kullanım kontrolleri de kendi sorumluluklarını taşımalı.

Başlangıçta verilecek özerklik, bu kontrollerin kurulabildiği ve doğrulanabildiği alanla sınırlı tutulabilir. Yeni bir araç, veri kaynağı veya işlem yetkisi eklendiğinde etki alanı yeniden incelenir. Böylece ajanın yapabilecekleri genişlerken, kurumun hatayı fark etme ve durdurma kabiliyeti de onunla birlikte gelişir.