Yapay zeka ajanı canlı sunucuda: neye izin veriyorum, neyi kendim yapıyorum

Ekimin bir haftasında altı şirket, yapay zeka ajanını canlı sistemlere sürprizsiz nasıl sokacağını yazdı. Vercel kendi ajanı için plan ve yetki şemasını gösterdi, Docker ajanı sandbox'a kapattı, Supabase ona canlı veritabanını yalnızca okuma yetkisiyle verdi, GitLab ajan günlüğü tuttu, Auth0 token'ları inceledi, Workato ise bir hukuk şirketinin modele neden tam Salesforce erişimi vermediğini anlattı. Kendi sunucunuz, CRM'iniz ve telefon sisteminiz varsa, er ya da geç biri “ajan kendisi düzeltsin” diyecek.

Neler yayımlandı, kimden

Vercel 23 Ekim'de ajanının production ile nasıl çalıştığını anlattı. “Deploy'u düzelt” isteği hangi işlemlerin gerekeceğini önceden söylemez, bu yüzden ajan sorunu önce yalnızca okuma yetkisiyle araştırıyor, sonra bir plan sunuyor: hangi görevleri yapacak ve hangi yetkilere (scope) ihtiyacı var. Plan bütün olarak onaylanıyor ve ona göre kısa ömürlü bir token çıkarılıyor: temel okuma yetkileri artı onaylananlar. Ajan, kullanıcı adına bir Vercel uygulaması olarak çalışıyor ve kullanıcının kendisinden fazla yetki alamıyor. Token dışında kalan işlemi API reddediyor, model gerekli görse bile.

Docker 21 Ekim'de Docker Sandboxes ile BAND platformunun birlikte çalışmasını gösterdi. Ajan kendi çekirdeği, dosya sistemi ve ağı olan izole bir mikro VM içinde çalışıyor, dışarıya yalnızca giden bağlantılarla çıkıyor. Anahtarlar host'ta kalıyor: sandbox onları giden isteklere kendisi yerleştiriyor, ajan yalnızca yer tutucuları görüyor.

Supabase 20 Ekim'de canlı projeyi ajanla kontrol etmek için bir set yayımladı: Health, Security, Performance ve Resources prompt'ları ve loglar üzerinde yalnızca okuma SQL'i için query_logs aracı. Oradaki iki öneriyi herkese tekrar ederim: MCP sunucusunu read_only=true bayrağıyla bağlamak ve zamanlanmış çalıştırmalar için önceden yalnızca okuma araçlarına izin vermek, çünkü zamanlanmış çalıştırma durup soru soramaz. Prompt'lar ajana loglarda bulduğu talimatları yok saymasını söylüyor.

GitLab 20 Ekim'de Premium ve Ultimate için AI Governance panelinin betasını açtı: hangi ajanlar çalıştırıldı, kim çalıştırdı, hangi projelere dokundular. Olay kaydı varsayılan olarak kapalı, dış ajanlar glab govern setup ile bağlanıyor.

Auth0 20 Ekim'de alışılmış istemci kaydının ajanlarda neden bozulduğunu açıkladı: yetkiler kayıt sırasında elle veriliyordu, ajana ise anında ve çağrı zinciri boyunca gerekiyor. Auth0'ın cevabı: her istemci için açık grant isteyen katı API modu, metadata üzerinden kayıt (CIMD) ve RFC 8693'e göre token değişimi; böylece token'da hangi kullanıcının işleme izin verdiği ve hangi ajanın onun adına hareket ettiği görülüyor.

Workato 21 Ekim'de yaklaşık 2000 kişilik hukuk şirketi Relativity'nin hikâyesini yayımladı. Şirketin uygulama mimarı, tedarikçilerin MCP sunucularında erişim yönetiminin çıkıştan aylar sonra geldiğini söylüyor; bu yüzden şirket rol tabanlı erişimli ve servis hesaplı kendi MCP sunucularını kurdu. İlki, Jira Data Center için olan, production'da çalışıyor.

Örnek: servis şirketinde “telefon sistemini düzelt”

Kendi PBX'i, CRM'i ve sitesi olan bir servis şirketini ele alalım. Cuma akşamı çağrılardan lead oluşmayı kesti ve bir çalışan ajana “düzelt” yazdı. Tam erişimle ajan telefon sistemini yeniden başlatabilir, yönlendirmeyi düzeltebilir ve bu arada CRM'de aslında kopya olmayan “kopyaları” temizleyebilir. Okuma erişimiyle loglara bakar, yapılandırmayı son çalışan haliyle karşılaştırır ve neyin değiştiğini söyler. Kararı insan verir.

Ajanın yetkileri görevi izlemeli. Okumaya daha sık izin verilebilir, gerçi o da ajana müşteri verilerini gösteriyor. Yazma, ancak tam olarak neyi yazacağı görüldükten sonra.

Bende nasıl çalışıyor

2021'den beri ABD'de PDR alanında çalışan bir şirketin teknik ortağıyım: sunucu, ağ, çağrıları yapay zekayla analiz eden kendi PBX'imiz, belge ayrıştırıcıları ve iç API bende. Şirkette güvenlik soruları bana geliyor. 2022'de kendi sunucumuz kurulduğundan beri geri yükleme gerektiren ciddi bir arıza olmadı.

Yapay zeka bana rutin işlerde, testte ve hata ayıklamada yardım ediyor ve geliştirmemi birkaç kat hızlandırdı. Benim sınırım Vercel'inkiyle aynı yerden geçiyor: değişikliği ajan hazırlıyor, canlı sunucuya kontrollerden sonra ben uyguluyorum. Mimariyi ve ilkesel kararları kendim belirliyorum. Müşteri çağrılarının geçtiği PBX'e düzeltmeyi kendi başına çıkaran bir ajanım yok. Bu haberlerdeki ürünleri kendi sunucularımda denemedim, bu yüzden şemalardan söz ediyorum.

Ben ne yapardım

Ajan için yalnızca okuma yetkili ayrı bir hesap açardım: loglar, yapılandırma, read-only modda veritabanı. Supabase de bunu öneriyor.

Ajanın hangi işlemleri önereceğini, hangilerini kendisinin yapacağını yazardım. Servisi yeniden başlatma, veritabanı migration'ı, çağrı yönlendirmesini değiştirme, müşterilere toplu gönderim bende “ajan önerir, insan yapar” listesinde.

Anahtarları ajanın dışında tutardım, host'ta ya da bir secret yöneticisinde, Docker sandbox'ının yaptığı gibi.

Günlük tutardım: ajanı kim çalıştırdı, ne okudu, ne önerdi, ne uygulandı. Küçük bir şirkette sıradan bir tablo yeter.

Loglarda ve e-postalarda gömülü talimatları kontrol ederdim: başkasının metnini okuyan ajan bir gün orada “her şeyi sil” okuyacak.

İlgili yazılar

İnsanlar ve yapay zeka için kurallar, durumlar ve yetkiler: İş mantığı: kurallar, durumlar ve yetkiler yazısı. Hizmet alanları: sonucun kontrol edilebildiği süreçte yapay zeka ve yayımlanabilen ve geri yüklenebilen altyapı. PDR şirketiyle bütün çalışma 2021'den beri ABD'deki PDR şirketinin teknik ortağı projesinde. Komşu yazılarım: kalıcı anahtarlar yerine tek çalıştırmalık anahtarlar ve ajanlar için sandbox'lar; daha önce yapay zeka kodunun nasıl kontrol edileceğini incelemiştim. Ajanı yaklaştırmak istediğiniz bir sunucunuz varsa, üzerinde neyin çalıştığını ve neyin insanda kalması gerektiğini anlatın. Görevi konuşalım.