60 saniyede execution broker mimarisi
Yapay zeka destekli bir sızma testi sistemindeki asıl tehlikeli bileşen modelin kendisi olmak zorunda değildir. Asıl risk, modelin ürettiği yanıtı operasyonel yetkiye dönüştüren fonksiyondur.
Bir ajan, kiracılar arası (cross-tenant) bir yetkilendirme zafiyetini doğru şekilde tespit edip yine de bunu kanıtlamak için güvenli olmayan bir yöntem seçebilir. Active Directory ilişkilerini doğru analiz edebilir ancak devralınan ayrıcalıklı bir oturum altında yanlış bir komut çalıştırabilir. Gelişmiş muhakeme yeteneği bazı hataları azaltır; ancak olasılıksal bir planlayıcıya (probabilistic planner) genel amaçlı kimlik bilgileri teslim etmeyi asla güvenli kılmaz.
Bu serinin önceki yazısı temel çalışma kuralını ortaya koymuştu: model önerir, politika yetkilendirir, en düşük yetkili (least-privileged) worker yürütür ve bağımsız bir hat doğrular. Bu makale, söz konusu kuralı uygulanabilir somut bir güvenlik sınırına dönüştürüyor.
Makaleye eşlik eden Execution Broker Laboratuvarı, hedef bağımsız ve yalnızca tarayıcı üzerinde çalışan bir simülasyondur. Herhangi bir bulut API’si, dizin bağlantısı, kabuk (shell) veya kimlik bilgisi içermez. Bir referans politika modelidir; ticari bir güvenlik ürünü, ölçülmüş bir kıyaslama (benchmark) ya da bu kontrollerin canlı bir operasyonu koruduğuna dair kesin bir kanıt niteliği taşımaz.
Güvenlik özelliğini tanımlayarak başlayın
“Ajan her işlemden önce onay ister” ifadesi yeterli bir güvenlik özelliği değildir. Bir onay penceresi çözümlenen asıl hedefi gizleyebilir, yanlış kimliği devralabilir, geniş bir eylem sınıfına toptan izin verebilir veya sistem ayrıcalıklı bir token’ı elde ettikten çok sonra ekrana gelebilir.
Bizim aradığımız güvenlik özelliği çok daha nettir:
Model güdümlü bir worker, yalnızca kapsam dahilinde olduğu doğrulanmış bir hedef için; kimliği, etkisi, nesne sayısı ve geçerlilik süresi bağımsız olarak yetkilendirilmiş, kısa ömürlü bir capability aracılığıyla tiplenmiş (typed) bir operasyon yürütebilir.
Bu tanım dört farklı sorumluluğu birbirinden ayırır:
- Model bir eylem önerisi (proposal) ve gerekçe sunar.
- Broker güvenilir olguları çözümler ve deterministik bir karar verir.
- Worker yalnızca sınırları belirlenmiş tek bir görev için gereken capability’yi alır.
- Doğrulayıcı (verifier) kapsamı ve sistem durumunu tamamen ayrı bir kanaldan izler.
Model kendi hedefini kendisi çözümleyemez, kendi kapsamını belirleyemez, kendi efektif kimliğini seçemez, üreteceği yan etkiyi kendisi onaylayamaz veya kendi sonucunu kendisi puanlayamaz.
Dört katman, dört farklı güven kararı
Bir execution broker mimarisi dört düzleme (plane) ayrıldığında muhakeme etmek çok daha kolaylaşır.
Proposal Plane (Öneri Düzlemi)
Model yapılandırılmış niyetini üretir: operasyon, aday hedef, beklenen etki, gerekçe ve kanıt hedefi. Bu düzlemdeki her şey güvenilmezdir (untrusted). Bir öneri hatalı olabilir, erişilen harici içerik tarafından manipüle edilmiş (prompt injection) olabilir, eski bellek verilerine dayanabilir veya tamamen halüsinasyon ürünü olabilir.
Policy Plane (Politika Düzlemi)
Broker, takma adları (alias) güvenilir olgularla değiştirir. Kapsam kaydını kontrol eder, hedefi çözümler, operasyonu tiplenmiş bir tool contract ile eşleştirir, efektif kimliği belirler, izin verilen maksimum nesne sayısını hesaplar ve yan etkiyi sınıflandırır. Bu olgular modelin düzenleyemeyeceği korumalı kayıtlardan gelir.
Execution Plane (Yürütme Düzlemi)
İzole edilmiş bir worker, ancak politika bu isteğe izin verdiğinde dar kapsamlı bir capability alır. Operatörün kabuğunu (shell), tarayıcısını, SSH agent’ını, bulut CLI oturumunu, Kubernetes bağlamını veya dizin token’ını devralmaz. Her capability tek bir kaynak kitlesine (audience), operasyona, kapsama, süre sonuna ve göreve bağlanır.
Evidence Plane (Kanıt Düzlemi)
Orijinal öneri, çözümlenen olgular, karar, onay, capability, worker çıktısı, bağımsız durum gözlemi, negatif kontrol ve temizleme (cleanup) durumu; yalnızca eklenebilir (append-only) tek bir kayıt haline getirilir. Bir ret kararı da kanıttır: hiçbir capability verilmediğini ve hiçbir worker görevinin oluşturulmadığını belgelemelidir.
Araç kataloğu bir güvenlik sınırıdır
Bir ajan erişemediği bir işlevi kötüye kullanamaz. Bu durum, araç envanterini daraltmayı, sistem prompt’una fazladan bir yasaklama cümlesi eklemekten çok daha değerli kılar.
OWASP Excessive Agency rehberi, aşırı işlevselliği, aşırı izinleri ve kontrolsüz otonomiyi temel kök nedenler olarak sıralar. Aynı zamanda silme yeteneğine de sahip bir doküman okuyucu, veri yazma izinleri bulunan bir veritabanı bağlayıcısı ya da katalogda unutulmuş eski bir eklenti; model normalde hep güvenli işlemi seçse dahi olası bir manipülasyonda etki alanını katlar.
Her tool contract (araç sözleşmesi) en azından şunları beyan etmelidir:
- Kararlı bir operasyon adı,
- Kabul edilen ve reddedilen argüman şemaları,
- Yan etki sınıfı (side-effect class),
- İzin verilen ortamlar,
- Maksimum nesne ve sonuç üst sınırı,
- Gereken kimlik sınıfı,
- Yeniden denemenin (retry) güvenli olup olmadığı,
- Onay sınıfı,
- Başarı, hata ve zaman aşımı durumunda üretilen kanıtlar.
{
"operation": "directory.object.inspect",
"effect": "read",
"environments": ["lab", "production"],
"identity_class": "audit_reader",
"max_objects": 50,
"automatic_retry": false,
"approval": "none",
"evidence": ["scope_id", "query_id", "result_count", "verifier_result"]
}Genel amaçlı bir kabuk (shell) aracını, çalıştırılması planlanan komut sadece veri okuyor diye asla read_only olarak tanımlamayın. O capability; sürece açık olan her yürütülebilir dosyayı, yerel dosyayı, kimlik bilgisini, soketi ve devralınan oturumu içerir. Bu bir adlandırma meselesi değil, doğrudan bir worker izolasyonu sorunudur.
Güncel MCP Tools spesifikasyonu, kullanıcıların araç çağrılarını reddedebilmesi gerektiğini ve uygulamaların araçları açıkça göstermesini, çağrıları görüntülemesini ve onay mekanizmaları sunmasını önerir. Ayrıca görünür araç kümesinin istekteki yetkilendirmeye göre değişebilmesine izin verir. Bu durum mimari açıdan kritik bir tasarımı destekler: Modelin mevcut capability düzeyi L0 veya L1 iken, yüksek etkili araçları katalogda keşfetmesine dahi izin verilmemelidir.
Protokol desteği tek başına politika üretmez. Operasyonları sınıflandırmak, hedefleri çözümlemek, kimlikleri kısıtlamak ve neyin asla otonom çalışamayacağına karar vermek uygulamanın kendi sorumluluğundadır.
Onaydan önce çözümleyin
Model customer-backup, prod-east veya corp.local gibi hedefler önerebilir. Bunlar birer takma addır (alias), güvenli bir yetkilendirme girdisi değildir. Broker bu adları güvenilir kapsam ve varlık kayıtları üzerinden çözümler.
Bir onay ekranı gösterilmeden önce sistem şunları netleştirmiş olmalıdır:
| Önerilen değer | Broker tarafından çözümlenen olgu |
|---|---|
| Hedef takma adı (alias) | Kanonik kiracı (tenant), abonelik, hesap, etki alanı, host ve nesne tanımlayıcısı |
| Araç adı | Katalogdan sürümü belirlenmiş operasyon ve etki sınıfı |
| “Mevcut kullanıcı” | Efektif worker kimliği ve tanımlı yetki kapsamları (scopes) |
| “Birkaç nesne” | Net nesne kümesi ve uygulanan kesin üst sınır |
| “Geri alınabilir” | Test edilmiş kurtarma referansı ve mevcut kurtarma durumu |
| “Tekrar denenebilir” | Idempotency sözleşmesi ve istek tanımlayıcı semantiği |
Onay, çözümlenen somut olgulara bağlanır. Hedef, operasyon, kimlik, nesne sayısı, beklenen durum farkı, kurtarma referansı veya süre sonu değişirse, verilmiş olan onay anında geçersiz kalır.
Klasik “Emin misiniz?” onay kutularının çöktüğü nokta tam olarak burasıdır: Tehlikeli detaylar henüz çözümlenmemişken sadece niyeti onaylarlar.
Güvenli/güvensiz bayrağı yerine capability merdiveni kullanın
Tek bir dangerous: true bayrağı; çevrimdışı analiz, sınırlı envanter taraması, geri alınabilir bir laboratuvar değişikliği ve canlı ortamda veri silme arasındaki operasyonel farkı ifade edemez. Laboratuvar ortamı dört seviye kullanır:
L0 — Çevrimdışı (Offline)
Hedef sistemle hiçbir bağlantı veya kimlik bilgisi bulunmaz. Kayıtlı artefaktların analizi, hipotez üretimi, şema karşılaştırması, kod incelemesi ve rapor taslağı hazırlama bu seviyededir. Dışarıda hiçbir yan etki oluşturamayacakları için veri işleme kısıtları dahilinde tamamen otonom çalışabilirler.
L1 — Sınırlandırılmış okuma (Bounded read)
Hedef kapsamla eşleştiğinde, worker izole edildiğinde, operasyon kesin bir sonuç üst sınırına sahip olduğunda ve kapsam ile sonuç ayrı bir hat tarafından doğrulandığında broker kısa ömürlü bir okuma kimliği verebilir. Salt okunur (read-only) olmak, bir HTTP metoduna veya komut adına dayalı bir varsayım değil, somut bir operasyon sözleşmesidir.
L2 — Geri alınabilir laboratuvar işlemi (Reversible lab action)
Kontrollü bir laboratuvar ortamında, projeye ait tanımlı tek bir canary hedefi tek kullanımlık bir capability alabilir. Broker; doğrulanmış bir kurtarma yolu, parametrelere bağlanmış onay, otomatik yeniden denemenin devre dışı bırakılması, yalnızca laboratuvara özel bir kimlik ve hem durum değişikliğinin hem de geri almanın bağımsız doğrulamasını şart koşar.
L3 — Yüksek etki (High impact)
Kayıt silme, canlı ortam mutasyonu, kimlik bilgisi sıfırlama, yetki değişikliği, geniş çaplı veri erişimi ve yönetimsel kabuk (admin shell) erişimleri model güdümlü otonom yürütmeye tamamen kapalıdır (denied). Model bir plan veya kanıt paketi hazırlayabilir; ancak capability’yi elde edemez.
Bu bir politika kararıdır; L3 kapsamındaki bir işlemin yetkili bir insan tarafından asla yapılamayacağı anlamına gelmez. L3 yetkisinin sıradan otonom yürütme süreçleri için asla üretilmemesi gerektiğini ifade eder.
Yetkilendirme artımlı ve kaynağa bağlı olmalıdır
Güncel MCP yetkilendirme taslağı; korumalı kaynak metaverilerini, açık kaynak göstergelerini (resource indicators), en az yetki prensibine göre scope seçimini ve bir işlem daha fazla yetki gerektirdiğinde adım adım yükseltilen (step-up) yetkilendirmeyi temel alır. Ayrıca bir yetkilendirme hatasının ardından kontrolsüzce yinelenen denemeleri sınırlar.
Bu ilkeler bir pentest broker mimarisine doğrudan uyarlanabilir:
- Çevrimdışı planlama sırasında hedef kimlik bilgisi edinmeyin.
- Okuma yetkisini (read scope) yalnızca L1 operasyonu fiilen hazır olduğunda talep edin.
- Token’ı herhangi bir bağlayıcıda geçerli saymak yerine doğrudan hedeflenen kaynak sunucusuna bağlayın.
- Kısa ömürlü capability’leri öneri üretiminden önce değil, politika denetiminden sonra verin.
- Yetki yükseltmelerini takip edin; böylece planlayıcı bir kullanıcı onaylayana kadar döngüye giremez.
- Biriken yetkilerin sessizce bir L1 oturumunu L3 oturumuna dönüştürmesine asla izin vermeyin.
Aktarım katmanı yetkilendirmesi (transport authorization), bir istemcinin korumalı sunucuya ulaşıp ulaşamayacağını yanıtlar. Nesne ve test yetkilendirmesi ise bu kimliğin bu denetim sırasında çözümlenen hedef üzerinde bu operasyonu yapıp yapamayacağını belirlemek zorundadır.
Her yeniden deneme yeni bir eylemdir
Araç orkestrasyon mekanizmaları zaman aşımlarını çoğunlukla basit bir altyapı gürültüsü olarak görür. Oysa bu yaklaşım yalnızca operasyon idempotent olduğunda ve sunucu semantiği tam olarak bilindiğinde güvenlidir.
Değişiklik yapan (mutating) bir istek hedefe ulaşıp işlemi tamamlayabilir ancak yanıt ağda kaybolabilir. Eğer ajan bunu tekrar denerse; bir değişikliği tekrarlayabilir, durum makinesini iki kez ilerletebilir, fazladan bir nesne oluşturabilir veya önkoşulları zaten değişmiş bir hedef üzerinde işlem yapabilir.
Bu nedenle broker üç sonucu birbirinden net biçimde ayırır:
- Gönderim öncesi hata (failed before send) — Hedef üzerinde hiçbir işlem gerçekleşmemiştir; sınırlandırılmış bir yeniden deneme güvenli olabilir.
- Hedef tarafından kesin ret (definitive target rejection) — Durum değişikliği gerçekleşmemiştir; yetkilendirmenin revize edilmesi veya düzeltme yapılması gerekir.
- Gönderim sonrası belirsizlik (ambiguous after send) — Yürütme derhal durdurulur ve bağımsız bir okuma kanalı sistem durumunu teyit eder.
L2 için otomatik yeniden deneme devre dışıdır. L3 ise zaten hiçbir zaman capability alamaz. Bir model, belirsiz bir sonucu asla tekrar deneme izni olarak yorumlayamaz.
Onay ekranı gerçek etki alanını göstermelidir
Bir L2 onay ekranı şunları eksiksiz sunmalıdır:
- Test kapsamı ve politika sürümü,
- Kanonik hedef ve tanımlı canary sahibi,
- Operasyon ve yan etki sınıfı,
- Efektif worker kimliği,
- Kesin nesne sayısı ve uygulanan maksimum limit,
- Beklenen işlem öncesi ve sonrası durumlar (pre/post-state),
- Kurtarma referansı ve son doğrulama zamanı,
- Otomatik yeniden deneme durumu,
- Bağımsız doğrulama yolu,
- Geçerlilik süresi ve değiştirilemez onay tanımlayıcısı.
Onay kaydı bu parametrelere kriptografik özetle (hash) veya doğrudan bağlanır. Parametrelerdeki en ufak bir değişiklik yeni bir öneri oluşturur ve yeni bir karar gerektirir.
NIST’in yazılım ve yapay zeka ajan kimliği kavram belgesi, ajanların farklı araçlara, uygulamalara ve verilere erişim elde ettiğinde ortaya çıkan risklere dikkat çeker ve ajan kimliği ile yetkilendirmesini ayrı bir güvenlik denetimi problemi olarak tanımlar. Sızma testlerinde yazılı angajman kuralları (rules of engagement) nihai yetki kaynağı olmaya devam eder. Broker, bu kısıtların bir bölümünü makine tarafından uygulanabilir hale getirir; asla genişletmez.
Altı laboratuvar senaryosunu inceleyin
Etkileşimli laboratuvar altı sentetik öneri içerir:
- Çevrimdışı hipotez incelemesi (Offline hypothesis review), dış dünyaya hiçbir etkisi veya kimliği olmadığı için L0 onayı alır.
- Kapsam dahilinde dizin incelemesi (Scoped directory inspection), yalnızca kapsam, izolasyon, sayı limiti ve bağımsız doğrulama geçerli kaldığı sürece L1 okuma capability’si alır.
- Geri alınabilir laboratuvar canary’si (Reversible lab canary), tüm laboratuvar kapıları eksiksiz olduğu için tek bir L2 capability’si alır. Kurtarmayı, tanımlı canary’yi, parametreye bağlı onayı, worker izolasyonunu veya doğrulamayı devre dışı bıraktığınızda karar beklemeye (hold) geçer.
- Canlı bulut silme işlemi (Production cloud deletion) reddedilir; çünkü etki yıkıcıdır, kimlik aşırı yetkilidir, worker izole edilmemiştir, onay genel geçerdir ve tekrar deneme güvensizdir.
- Domain Admin kabuğu (Domain Admin shell) reddedilir; çünkü geniş ambient Domain Admin yetkisi altında çalışan genel amaçlı bir kabuk, otonom capability modelinin tamamen dışındadır.
- Prompt manipülasyonu kaynaklı kapsam kayması (Prompt-influenced scope drift), talep edilen işlem salt okunur olsa dahi reddedilir. Çözümlenen hedef, test kapsamı kaydının dışındadır.
Alanları teker teker değiştirin. Amaç simülatörü kandırıp silme işlemine izin vermesini sağlayacak bir açık bulmak değildir. Amaç, hangi olguların deterministik politikaya ait olduğunu ve hangi risklerin model güveniyle asla azaltılamayacağını görmektir.
Laboratuvar mevcut kararını JSON olarak indirebilir. Bu kayıt tamamen tarayıcıda yerel olarak üretilir ve yalnızca sayfadaki sentetik veya kullanıcı tarafından düzenlenen değerleri barındırır. Sayfaya asla gerçek kimlik bilgileri, token’lar, müşteri verileri veya canlı sistem tanımlayıcıları yapıştırmayın.
Saha kiti
Laboratuvara iki yeniden kullanılabilir kaynak eşlik eder:
- Politika sözleşmesi JSON — Capability seviyeleri, zorunlu kapılar, ret kuralları, öneri alanları, onay bağlama ve karar kayıtları.
- Kanıt çalışma sayfası CSV — Öneri, çözümlenen kapsam, kimlik, karar, capability, yürütme, doğrulama, negatif kontrol, geri alma ve kanıt sınırları için çalışma tablosu.
Bunlar kasıtlı olarak dağıtım mimarisinden bağımsız tasarlanmıştır. Belirteç üretmez veya bir hedefe bağlanmazlar. Bunları kurumunuzun kimlik sağlayıcısına, test yönetim sistemine, araç sunucusuna, worker izolasyonuna, kayıt tutma ve olay müdahale modeline uyarlayın.
Kanıt matrisi (Evidence matrix)
| Güvenlik iddiası | Pozitif kanıt | Negatif kontrol | Hata sinyali | Açık sınır |
|---|---|---|---|---|
| Model kendi araç çağrısını yetkilendiremez | Öneri kimlik bilgisi olmadan mevcuttur; broker kararı capability verilmesinden önce gelir | Karardan sonra onaylanan bir parametreyi değiştirin ve onayın geçersiz kaldığını doğrulayın | Politika çözümlemesinden önce bir worker token’ı oluşur | Tarayıcı laboratuvarı mantığı gösterir, canlı izolasyonu değil |
| Kapsam model bağlamı dışında çözümlenir | Kanonik hedef ve test ID’si korumalı bir kayıttan gelir | Kapsam dışına çözümlenen bir alias önerin ve reddedildiğini doğrulayın | Model tarafından sağlanan hedef sorgusuz kabul edilir | Kayıt bütünlüğü ayrı kontroller gerektirir |
| L1 okumaları sınırlandırılmıştır | Okuma kimliği, nesne üst sınırı, süre sonu, izole worker ve doğrulayıcı kaydedilir | Nesne üst sınırını aşın ve hiçbir capability üretilmediğini doğrulayın | Bir politika olayı olmadan sonuç kümesi büyür | Salt okunur olması kaynak tüketimi veya hassas veri sızıntısı olmayacağını kanıtlamaz |
| L2 değişiklikleri geri alınabilir lab eylemleridir | Tanımlı canary, işlem öncesi durum, bağlı onay, işlem sonrası durum, geri alma ve doğrulayıcı sonucu mevcuttur | Kurtarma doğrulamasını kaldırın ve işlemin beklemeye (hold) alındığını doğrulayın | Laboratuvar değişikliği genel bir onayla yürütülür | Laboratuvarda geri alma canlı ortamda kurtarılabilirliği kanıtlamaz |
| L3 yetkisi otonom yürütmeye ulaşamaz | Silme ve Domain Admin önerileri ret üretir; hiçbir capability/iş oluşmaz | İzin verilen bir L1 önerisi sunun ve normal worker yolunun çalıştığını doğrulayın | Yüksek etkili araç keşfedilebilir veya yürütülebilir kalır | İnsan kontrollü yüksek etkili iş akışları bu modelin dışındadır |
| Belirsiz mutasyon tekrar denenmez | Zaman aşımı durumu yürütmeyi durdurur ve bağımsız doğrulama hedef durumu belirler | Bilinen bir idempotent okumayı retry üst sınırı dahilinde tekrarlayın | Durum çözümlenmeden önce ikinci mutasyon gerçekleşir | Hedefe özgü idempotency bağımsız olarak belgelenmelidir |
Uygulama sırası
İşe mevcut ayrıcalıklı bir ajanın önüne sadece politika denetimi yapan bir prompt koyarak başlamayın. Kontrol hattını şu sırayla inşa edin:
- Şu anda açık olan her aracı ve efektif kimliği envantere alın.
- Kullanılmayan, çakışan, yıkıcı ve genel amaçlı işlevleri kaldırın.
- Sürümleri belirlenmiş operasyon sözleşmelerini ve yan etki sınıflarını tanımlayın.
- Kanonik hedefleri ve test pencerelerini çözümleyen bir test kayıt defteri (engagement registry) oluşturun.
- L0, L1 ve L2 worker’larını ve kimlik bilgilerini ayırın. L3’ü model güdümlü yürütmenin tamamen dışında tutun.
- Onay arayüzünden önce deterministik ret kurallarını uygulayın.
- Onayı çözümlenen parametrelere ve süre sonuna bağlayın.
- İzin verilen her iş için tek bir kısa ömürlü, kaynağa bağlı capability verin.
- Öneriyi, politikayı, onayı, capability’yi, worker sonucunu ve doğrulamayı ayrı ayrı kaydedin.
- Negatif kontrolleri test edin: Kapsam uyuşmazlığı, üst sınır aşımı, süresi dolmuş onay, ambient administrator, güvensiz tekrar deneme ve erişilemeyen kurtarma yolu.
- Yeni capability verilmesini engelleyen ve aktif kısa ömürlü erişimleri iptal eden bir acil durdurma anahtarı (kill switch) ekleyin.
- Kontrollü laboratuvar ortamında belirsiz sonuçları, temizleme adımlarını ve olay bildirim süreçlerini tatbik edin.
Kurumlar otomasyonu artırmayı ancak bu kontroller başarıyla geçtikten sonra düşünmelidir. Modelin kıyaslama (benchmark) başarımı, kontrol düzlemi testlerinin yerini tutamaz.
Bu tasarımın çözmediği konular
Bir execution broker mimarisi aşırı otonomi (excessive agency) riskinin belirli bir sınıfını azaltır. Ancak bağlı olan her sistemi sihirli bir şekilde güvenli kılmaz.
Test kayıt defteri hatalı olabilir. Bir araç kendi yan etkisini yanlış sınıflandırabilir. Kimlik sağlayıcı gereğinden fazla yetkili bir token üretebilir. Bir worker izolasyondan kaçabilir. Hedef API dokümantasyonundan farklı davranabilir. Günlük kayıtları belirleyici olayı atlayabilir. Kötü niyetli bir araç sunucusu kendi şeması veya sonucu hakkında yalan söyleyebilir. Bir operatör tehlikeli bir isteği dikkatsizce onaylayabilir.
Her sınır kendi özel testine ve kanıtına ihtiyaç duyar. Broker mimarisinin gerçek değeri, bu kararların uygulanabileceği ve gözlemlenebileceği merkezi bir denetim noktası yaratmasıdır. Tek başına evrensel bir güven çıpası değildir.
Operasyonel sonuç
En güvenli yapay zeka pentest ajanı, en uzun yasaklama prompt’una sahip olan ajan değildir. Sıradan yürütme yolunun geniş yetkiler üretemediği ajandır.
Modelin hipotezleri keşfetmesine ve yapılandırılmış öneriler hazırlamasına izin verin. Deterministik politikanın kapsamı, kimliği, etkiyi, sayıyı, yeniden denemeyi, onayı ve kurtarmayı çözümlemesini sağlayın. İzole worker’lara yalnızca onaylanan kanıtı elde etmeye yetecek en küçük, kısa ömürlü capability’yi verin. Sonucu bağımsız bir hat üzerinden doğrulayın. Ret kararlarını da en az başarılı yürütmeler kadar titizlikle kaydedin.
Model canlı ortamda veri silmeyi veya bir Domain Admin kabuğu açmayı önerirse, broker’ın görevi onu daha ikna edici bir dille uyarmak değildir. Görevi, o yetkinin sistemde hiçbir zaman var olmamasını sağlamaktır.
MITRE ATT&CK eşlemesi
| Taktik | Teknik ID | Teknik adı | Doğrulama sinyali |
|---|---|---|---|
| Execution | T1059 | Command and Scripting Interpreter | Deterministik broker, model planından gelen kabuk yürütmesini reddeder |
| Privilege Escalation | T1548 | Abuse Elevation Control Mechanism | Parametreye bağlı capability üretimi worker yetki yükseltmesini sınırlar |
| Defense Evasion | T1078 | Valid Accounts: Ambient Authority | Kısa ömürlü, tek kullanımlık kimlik bilgileri ambient kimliklerin yeniden kullanımını engeller |
Capability merdiveni kararlarını, politika kapılarını ve kapsam sınırlarını tekrarlanabilir yürütme senaryolarıyla tarayıcınızda etkileşimli olarak test edin.
Etkileşimli Broker'ı Başlat ↗Bu teknik not ne kadar güncel?
En son kaynak incelemesi, içerik güncellemesi veya yayın tarihi gösterilmektedir.
Yazar teknik incelemeyi tamamladı. Bu etiket tek başına laboratuvar yeniden üretimi iddiası taşımaz.