Güvenlik modeli

Bir agent bir görevi üstlendiğinde, daemon bir yapay zekâ kodlama aracını (Codex, Claude Code ve benzerleri) alt süreç olarak başlatır. Bu sürecin neye dokunabildiğini anlamak, güvenlik modelinin tamamıdır.

Sınır, daemon kullanıcısıdır

Varsayılan olarak bir görev, daemon'u çalıştıran işletim sistemi kullanıcısının tam izinleriyle yürütülür. O kullanıcının okuyup yazabildiği her dosyayı okuyup yazabilir, o kullanıcının kimlik bilgilerini kullanabilir ve ağa sınırsız erişebilir.

Multica hiçbir dosya sistemi sandbox garantisi vermez. Bugün tek dar istisna — Windows'ta, Codex'in yerel sandbox'ına açıkça izin verdiğinizde — ama hangi platform/yapılandırma kombinasyonlarının bir şeyi sandbox'ladığı, araç sürümleriyle birlikte değişen bir uyumluluk detayıdır. Her görevi sandbox'sız kabul edin ve sınırı daemon'un dışına koyun.

Bu bilinçli bir tercihtir. Agent'lardan bağımlılık kurmaları, build çalıştırmaları, bulut CLI'larınızı kullanmaları ve normal bir ev dizini bekleyen araçları çalıştırmaları istenir. Kısmi bir dosya sistemi sandbox'ı bu işi teşhisi zor şekillerde bozar — araç "oturum açılmamış" der veya sessizce yanlış hesabı kullanır — üstelik en önemli şeyi, yani bir görevin kimlik bilgilerini okuyup ağ üzerinden göndermesini engellemeyi de yine de yapmaz.

Yani Multica kendini sınır gibi göstermez. Sınırı onun etrafına siz koyun.

Önerilen kurulumlar

Altyapınıza uyanı seçin — en hafiften en güçlüye sıralandı:

1. Ayrılmış bir Unix kullanıcısı. Bir multica kullanıcısı oluşturun, ona yalnızca agent'ların ihtiyaç duyduğu depoları ve kimlik bilgilerini verin ve daemon'u o kullanıcı olarak çalıştırın. Kendi hesabınız dokunulmamış kalır.
2. Container. Daemon'u yalnızca agent'ların ihtiyaç duyduğu bağlama noktaları ve sırlarla bir container içinde çalıştırın.
3. Sanal makine. Bir makine kurmanın maliyetiyle, tam izolasyon.

Hangisini seçerseniz seçin, o ortamdan erişilebilen kimlik bilgilerini agent'ın kullanabileceği kimlik bilgileri olarak değerlendirin: token'ları dar kapsamlandırın, kişisel SSH anahtarınız yerine amaca özel deploy key'leri tercih edin ve o kullanıcının ana dizininde ilgisiz üretim kimlik bilgileri bırakmaktan kaçının.

Multica'nın izole ettiği şeyler

Bunlar gerçektir, ama aktif olarak kaçmaya çalışan bir göreve karşı bir güvenlik sınırı değil — kolaylık ve etki alanını azaltma önlemleridir:

• Göreve özel çalışma dizini. Her görev ~/multica_workspaces/ altında kendi çalışma dizinini alır, böylece eşzamanlı görevler aynı checkout üzerinde çakışmaz.
• Göreve özel agent durumu. Codex görevleri, yapılandırma, oturum ve skill'leri tutan göreve özel bir CODEX_HOME alır, böylece göreve özel ayarlar kendi ~/.codex/'inizi kirletmez.
• Göreve kapsamlı API token'ları. Bir göreve verilen MULTICA_TOKEN, sunucu tarafından o agent'a ve o göreve bağlanır, böylece bir görev Multica API'si üzerinden siz veya başka bir agent gibi davranamaz.

Sınır olmayan şeyler

• Kodlama aracının kendi sandbox'ı ve onay ayarları. Multica agent'ları gözetimsiz çalıştırır, bu yüzden onay istemleri otomatik olarak yanıtlanır. Varsayılan yolda dosya sistemi sandbox'ı da kapalıdır: Codex sandbox_mode = "danger-full-access" ile, Claude Code ise --permission-mode bypassPermissions ile çalışır. İstisna Windows'tur — Codex'in yerel sandbox'ını açıkça yapılandırırsanız (windows.sandbox = "unelevated" veya "elevated"), Multica bu tercihi onurlandırır ve o görevler için workspace-write'ı korur. Uyduğu yerde yapmaya değer, ama bu tek bir platformdaki tek bir araçtır ve daemon kullanıcısını nasıl kapsamlandırmanız gerektiğini değiştirmez.
• HOME dizin yapınız. Görevler, daemon kullanıcısının gerçek HOME ve XDG_* değişkenlerini devralır — bu da host CLI'larının (gh, aws, kubectl, gcloud, glab) bir görev içinde tam olarak kabuğunuzdaki gibi çalışmasını sağlayan şeydir. Ayrıca o ana dizin altındaki her şeyin erişilebilir olduğu anlamına gelir.

Bir görevin neyle çalıştığını kontrol etme

Daemon, bir görev sandbox'sız başladığında etkin sandbox modunu warn düzeyinde loglar:

multica daemon logs --lines 200 | grep "codex sandbox"

Etkin Codex yapılandırmasını doğrulamak için, görevin CODEX_HOME'u altındaki config.toml'daki yönetilen bloğu okuyun — # BEGIN multica-managed ve # END multica-managed işaretleri arasındaki bölüm, daemon tarafından her görevde yazılır.