Yapay zekaya Proxmox erişimi vermek: sınır nerede durmalı
Bir modelin gerçekten iyi yaptığı iş, uzun günlükleri okuyup neyin bozulduğunu bulmak, tam da yapmasına izin verilmeyen iştir. Sebebi şu: bugün elimizdeki tek yollar ona root veriyor, ve risk kötü niyet değil eksik bağlam.
AtlasPVE ·
Bu madde şunları karşılıyor
- proxmox mcp server
- yapay zeka proxmox yonetebilir mi
- proxmox'a yapay zeka erisimi guvenli mi
- llm'e sunucu erisimi vermek riski
- best proxmox mcp server
Burada gerçek ve biraz can sıkıcı bir asimetri var. İki bin satırlık günlüğü okuyup bir şeyin bozulduğu satırı bulmak, dil modelinin tam olarak iyi yaptığı iştir. Aynı zamanda çoğu insanın ona yaptıramadığı iştir, ve sebebi erişimin nasıl verildiğidir.
Soru bir modelin sunucuya dokunup dokunmaması değil. Sınırın nerede durduğu, ve bugün genelde yanlış yerde duruyor.
Alışılmış kurulum neden rahatsız edici
Bir asistanı Proxmox'a bağlamanın iki yaygın yolu var: SSH oturumu vermek ya da tam yetkili bir API jetonu vermek. İkisi de aynı kapıya çıkıyor. O andan itibaren modelle donanım arasında hiçbir şey durmuyor, ve bütün korumalar bir istem cümlesinin kelimelerinde yaşıyor.
İstem sınır değildir. Yardımcı olmak üzere tasarlanmış bir sisteme, zorlayıcılığı olmayan bir dille yapılmış bir ricadır.
Risk kötü niyet değil, eksik bağlam
Yanlış teşhis edilen kısım burası. Arıza biçimi nadiren "model zarar vermeye karar etti" olur. Genelde model eksik bir resim üzerinde doğru davranır.
Boş görünen bir disk. Model üstünde bağlı dosya sistemi olmayan bir aygıt okur ve onu boşta sayar. Aygıt aslında kapalı duran bir makineye aittir.
Bozulmuş bir havuz. Model bozulmuş durumu okur ve diziyi yeniden kurmayı önerir. Doğru adım tek bir diski değiştirmekti, ve yeniden kurmak kalan verinin kaybedilme yoludur.
"Çalışmayan" bir servis. Çalışmıyordur çünkü zamanlanmış çalışır ve işini bitirmiştir. Yeniden başlatmak zararsızdır; "sürekli duruyor" diye devre dışı bırakmak değildir.
Üçünde de komut doğru yazılmıştır. Yanlış olan öncüldür, ve yanlış öncül üzerine yazılmış doğru bir komut, iş işten geçtikten sonra sabotajdan ayırt edilemez.
Salt okuma işe yarar ve tek başına cevap değildir
Akla gelen ilk cevap salt okuma yetkisi vermektir, ve en kötü sonuçları gerçekten ortadan kaldırır. Geriye iki şey kalır.
Okumak bedava değildir. Yapılandırma, günlükler ve denetim kayıtları sunucu adları, adresler, kullanıcı adları ve bazen olmaması gereken yere yapıştırılmış jetonlar taşır. Tam okuma kapsamlı bir asistan, altyapınızın dışa aktarımıdır.
Eylemsiz teşhis yarı yolda durur. İşe yarayan cevap "şu tek servisi yeniden başlat" ise, salt okuma bulguyu bir insana geri verip yeniden yazdırır. Bu sorun değil, ve insanların izinleri sonradan sessizce genişletmesinin sebebi de tam olarak budur.
Yani salt okuma iyi bir başlangıç, kötü bir varış noktasıdır. Varış noktası insanın geçtiği kapılardan geçen dar yazma yetkisidir.
Sınır asıl nereye ait
İsteme değil, modelin içine de değil. İcra eden katmana, çünkü reddedebilen tek yer orasıdır.
Böyle bir katmanı güvenilir yapan üç özellik var, ve üçü de vaat değil denetlenebilir.
İzinler zaten sahip olan sistemden gelir. Asistan var olan bir hesapla bağlanıyorsa, o hesabın dokunabildiği şey asistanın dokunabildiği şeydir. İkinci bir izin modeli icat edilmez, dolayısıyla senkronda tutulacak bir şey ve ikisinin çelişebileceği bir yer olmaz.
Yıkıcı işlemler insanın geçtiği kapıdan geçer. Bir diski silmek insana onay soruyorsa, model istediğinde de sormalıdır. İnsan için güvenli, otomasyon için açık olan bir yol sınır değildir; güzel adı olan bir kestirmedir.
Her adım denetim kaydına düşer. Kim, ne, ne zaman, neye, hangi sonuçla. Bu olmadan olaydan sonra sorulan asıl sorunun ("bunu asistan mı yaptı") cevabı yoktur, ve cevabın yokluğu tek başına erişim vermemek için bir sebeptir.
Böyle bir araç hakkında sorulacak soru
"Güvenli mi" değil, "ne reddediyor ve o nerede yaşıyor?"
Cevap "modele yapmaması söylendi" ise ortada sınır yoktur. Cevap "icra eden katman hesabın izinlerine bakıyor ve yıkıcı adımları kapıya sokuyor" ise vardır, ve sınayabilirsiniz: kısıtlı bir hesapla bağlanın ve reddin gerçek olduğunu görün.
Atlas ne yapıyor
⚠️ Bu katman planlandı, henüz yayında değil. Aşağıdaki, inşa edilmekte olduğu tasarımdır; buraya yazılmasının sebebi yukarıdaki sorunun pazarlama cümlesini değil dürüst bir cevabı hak etmesidir.
Amaç, asistanın Proxmox'a değil Atlas'a bağlanması. Proxmox altta durur ve model ona doğrudan hiç ulaşmaz; yalnız Atlas'ın yapabildiğini kullanabilir, yani var olan her kapı yolun üstünde kalır.
Sınırı Proxmox izinleri çizer, ki bu yukarıdaki ilk özelliktir: bağlanan hesap neye dokunabiliyorsa asistan yalnız o kadarına dokunur, ve yeni bir izin kavramı ortaya çıkmaz. Yıkıcı işlemler zaten sahip oldukları onayı korur, ve denetim kaydı yetkili her eylem için kim, ne, ne zaman, neye, hangi sonuçla bilgisini zaten tutuyor, reddedilenler dahil.
Ayrıca kurulumun parçası değil ayrı bir bileşen olması amaçlanıyor: istemeyen bir makinede hiç bulunmaz. Bu, bu maddenin geri kalanıyla aynı sebepten önemli. Seçmediğiniz bir yetenek için en güvenli sınır, onun yokluğudur.
Kaynaklar
Proxmox'un kendi belgeleri. İngilizce, ve bu konuda son sözü onlar söyler.