Teknoloji ve İnovasyon

Model koruması aracı korumuyor: Bedrock’ta üç kontrol noktası

|Yazar: QUASA Editör Ekibi|5 dk okuma| 3
Model koruması aracı korumuyor: Bedrock’ta üç kontrol noktası

Bir Strands ajanında Bedrock Guardrails’ı model çağrısına bağlamak, aracın çalıştırılacağı parametreleri veya harici araçtan dönen içeriği kendiliğinden korumaz. Bu boşluğu kapatmak için kullanıcı mesajını model çalışmadan önce, araç parametrelerini dış işlem başlamadan önce ve araç sonucunu ajan bağlamına dönmeden önce ayrı ayrı doğrulamak gerekir.

Bu üç sınır Strands’taki BeforeInvocationEvent, BeforeToolCallEvent ve AfterToolCallEvent olaylarıyla denetlenebilir. Engelleme kararı ilgili aşamadaki akışı kesmeli; doğrulama servisine ulaşılamadığında özellikle yazma, gönderme, ödeme veya silme yetkisi olan araçlar güvenli biçimde durmalıdır.

Model sınırı neden araç sınırına ulaşmıyor?

Model kontrolünden geçen Strands ajanında araç parametrelerinin hâlâ ayrı doğrulama beklemesi

Model çağrısına eklenen guardrail, modele sunulan içerik ile modelin ürettiği yanıtı değerlendirir. Oysa ajan daha sonra modelin seçtiği parametrelerle bir API, veritabanı, dosya sistemi veya MCP sunucusu üzerinde işlem yapabilir. Araçtan gelen harici veri de yeni bir güven sınırını geçerek ajan bağlamına döner.

AWS Security Blog’daki uygulama, model düzeyindeki korumanın araç parametrelerine ve harici sonuçlara erişmediğini; kullanıcı girdisi, çağrı öncesi parametre ve çağrı sonrası sonuç için üç kontrol noktası gerektiğini açıklıyor. Dolayısıyla güvenli bulunan bir model çıktısı, bu çıktıdan türetilen gerçek dünya eyleminin de güvenli olduğu anlamına gelmez.

Örneğin izin verilen bir kullanıcı isteği, e-posta aracında yanlış alıcıya veya politika dışı bir metne dönüşebilir. Bir web aracı da zararlı yönlendirmeler içeren harici metni geri getirebilir. İlk risk araç çalışmadan, ikincisi sonuç yeniden modele veya başka bir sisteme aktarılmadan ele alınmalıdır.

Önkoşul: Guardrail’dan önce en az yetki

Guardrail bir yetkilendirme sistemi değildir. Ajanın IAM rolünü gerekli Bedrock işlemleriyle, her aracın erişimini de kendi işi için gereken kaynak ve eylemlerle sınırlandırın. Yalnızca kayıt okuması gereken bir aracın yazma veya silme izni olmamalıdır.

Kurulum için çalışan bir Strands ajanı, yapılandırılmış guardrail kimliği ve sürümü, doğru AWS Bölgesi ve uygun çalışma kimlik bilgileri gerekir. AWS’nin örnek mimarisinde rol için bedrock:ApplyGuardrail ve model çağrısında bedrock:InvokeModel izinleri bulunur; aracın veritabanı, kuyruk veya üçüncü taraf API izinleri bunlardan ayrı tutulur.

Guardrails değerlendirmesinden önce deterministik kontroller çalıştırın: araç adını izin listesiyle karşılaştırın, parametreleri JSON şemasına göre doğrulayın, uzunluk ve biçim sınırlarını uygulayın. Guardrail politikasını da araç riskine göre ayırabilirsiniz; müşteri kaydı aracı için hassas veri denetimi, dış web içeriği alan araç için istenmeyen içerik denetimi daha belirleyici olabilir.

Üç hook veri akışına nasıl yerleştirilir?

Kullanıcı mesajı, araç parametresi ve araç sonucunun üç Strands hook’ında doğrulanması

Strands hook belgeleri, BeforeInvocationEvent sırasında invocation’ın, BeforeToolCallEvent sırasında tekil araç çağrısının iptal edilebildiğini ve AfterToolCallEvent içinde araç sonucunun değiştirilebildiğini belgeliyor. Bu özellikleri aynı doğrulama işlevinin çevresinde şu sırayla kullanın:

  1. Kullanıcı mesajı: BeforeInvocationEvent içinde yeni invocation’a ait kullanıcı içeriğini çıkarın ve değerlendirin. Politika müdahale ederse invocation’ı iptal edin; özgün metni değiştirilmiş bir kullanıcı mesajı olarak modele göndermeyin.
  2. Araç parametresi: BeforeToolCallEvent içinde araç adını ve yapılandırılmış input nesnesini alın. Önce izin listesi ile şemayı denetleyin, ardından güvenlik kararını etkileyen metin alanlarını Guardrails’a gönderin. Müdahalede cancel_tool değerini ayarlayarak dış etki oluşmadan çağrıyı kesin.
  3. Araç sonucu: AfterToolCallEvent içinde sonucu ajan bağlamına eklenmeden önce değerlendirin. Sakıncalı içerikte event.result değerini nötr bir hata sonucuyla değiştirin; özgün sonucu konuşma geçmişine, kullanıcı yanıtına veya sonraki ajana taşımayın.

Parametreleri kararlı ve anahtarları koruyan bir biçimde serileştirin. Parola, erişim belirteci ve gereksiz ikili içerik gibi alanları değerlendirme isteğinden çıkarın; ancak hedef, alıcı veya sorgu gibi güvenlik kararını değiştiren alanları atlamayın.

AWS ApplyGuardrail belgeleri, önceden yapılandırılmış politikaların temel modeli çağırmadan uygulama akışındaki metne uygulanabildiğini; istekte INPUT veya OUTPUT kaynağı, yanıtta ise GUARDRAIL_INTERVENED veya NONE eylemi kullanıldığını belirtiyor. Kullanıcı mesajı ve araç parametresi INPUT, harici araç sonucu OUTPUT olarak ortak kontrol işlevine gönderilebilir.

Doğrulama başarısızsa hangi karar verilmeli?

ApplyGuardrail hatasında etkili araç çağrısının güvenli biçimde durdurulması

Politika müdahalesi ile altyapı hatasını aynı durum olarak işlemeyin. İlki içerik hakkında verilmiş bir karardır; ikincisi zaman aşımı, erişim reddi, ağ sorunu veya yanlış guardrail yapılandırması olabilir. Kullanıcıya her iki durumda da hassas ayrıntı içermeyen kısa bir hata gösterilebilir, fakat kayıt ve alarmlarda nedenler ayrılmalıdır.

  • Yerel şema veya araç izin listesi başarısızsa ApplyGuardrail çağrısını beklemeden aracı iptal edin.
  • Yanıt GUARDRAIL_INTERVENED ise bulunduğunuz sınıra göre invocation’ı durdurun, aracı iptal edin veya sonucu güvenli hata nesnesiyle değiştirin.
  • Yanıt NONE ise yalnızca o kontrol noktasından geçişe izin verin; bu karar aracın IAM yetkisini genişletmez.
  • API hata verir veya zaman aşımına uğrarsa etkisi yüksek araçları kapalı tutun. Düşük riskli bir araç için açık kalma istisnası gerekiyorsa bunu araç bazında, süre sınırı ve alarm koşuluyla tanımlayın.

AfterToolCallEvent kontrolünün araç çalıştıktan sonra gerçekleştiğini unutmayın: bu aşama sonucu ajan bağlamından uzak tutabilir, fakat oluşmuş dış etkiyi geri alamaz. Sonuç doğrulaması belirsiz kaldığında yan etkili çağrıyı körlemesine tekrarlamak yerine yürütme durumunu ve varsa idempotency anahtarını kontrol edin.

Dağıtımdan önce üç sınırı ayrı ayrı sınayın

Test planı yalnızca örnek bir istemin engellendiğini göstermemelidir. Her kontrol noktasında izin verilen içerik, politika müdahalesi ve ApplyGuardrail altyapı hatası ayrı senaryolar olarak çalıştırılmalıdır.

  • Temiz kullanıcı mesajı modele ulaşmalı; engellenen mesaj model çağrısından önce durmalıdır.
  • Geçerli parametre aracı çalıştırmalı; şema dışı veya engellenen parametre hiçbir dış etki üretmemelidir.
  • Temiz araç sonucu ajan bağlamına dönebilmeli; engellenen sonuç özgün veri taşımayan hata nesnesiyle değiştirilmelidir.
  • Zaman aşımı ve erişim reddi, politika müdahalesinden farklı hata kodlarıyla izlenmelidir.
  • Kontrol politikası atanmamış yeni bir araç üretimde varsayılan olarak çalıştırılmamalıdır.

Böylece model çağrısındaki koruma ile aracın çevresindeki kontroller farklı işleri üstlenir: BeforeInvocationEvent ajana giren isteği, BeforeToolCallEvent gerçek dünya eylemine dönüşecek parametreyi, AfterToolCallEvent ise dış sistemden geri gelen içeriği sınırlar.

Ayrıca okuyun:

Paylaş:

Bültenimize abone olun

En son Web3, yapay zekâ ve kripto haberleri doğrudan gelen kutunuza gelsin.

0