Yetki, görevden daha geniş
macOS'ta Full Disk Access (FDA), sandbox'ın okuma bariyerlerini tüm home dizini boyunca kaldıran tek bir TCC (Transparency, Consent, and Control) yetkisidir. Pratikte tek bir onay; Mail deposunu, Safari ve Chrome profil dizinlerini, login keychain'i, Messages veritabanını ve ~/.aws, ~/.ssh ya da ~/.config altında duran tüm geliştirici kimlik bilgilerini kapsar. Kullanıcı tek bir diyalog ve tek bir anahtar görür. Sistem tek bir bit görür.
Bu bit kalıcıdır. Yeniden başlatmalara dayanır, imzalı ikili dosyanın gelecekteki her çağrısına uygulanır ve sürecin nasıl başlatıldığına göre daraltılmaz. Salı günü tek bir proje klasörünü okuması gereken bir agent, Cuma günü bir indirme dizinindeki PDF'i özetlemesi istendiğinde hâlâ aynı yetkiye sahiptir.
Agent iş yükleri dönemseldir. Bir çalışmanın başlangıcı, bir planı, bir dizi tool call'ı ve bir sonu vardır. Çalışmanın ihtiyaç duyduğu şey ile yetkinin izin verdiği şey arasındaki fark risk yüzeyidir ve macOS'ta bu fark şu anda tüm home dizinidir.
Uygulama modeli neden uymuyor
Klasik macOS uygulamalarının sabit ve denetlenebilir bir özellik kümesi vardır. Bir fotoğraf düzenleyici görüntüleri okur. Bir mail istemcisi mail deposunu okur. İnceleyiciler izin hakkında akıl yürütebilir çünkü davranış ürünün amacıyla sınırlıdır.
Bir agent'ın okuma kümesi çalışma zamanında bir planner tarafından belirlenir. Aynı ikili dosya, iki kez çağrıldığında bir oturumda bir elektronik tabloyu, sonrakinde bir keychain dosyasını okuyabilir; çünkü plan prompt'tan ve ortamdan üretilir. Sürecin neye dokunacağını tanımlayan statik bir manifest yoktur.
Bu, prompt injection'ın başarısızlık modunu değiştirir. Geleneksel bir uygulamada injection kötü bir çıktıya yol açabilir. FDA'ya sahip bir agent'ta injection, herhangi bir yetki yükseltmesi olmadan meşru bir yetkiyi bir sızdırma yoluna dönüştürür: model zaten kimlik bilgilerini okumaya yetkilidir ve ağ aracı zaten byte göndermeye yetkilidir. Saldırganın sandbox'ı kırması gerekmez; planı yönlendirmesi yeterlidir.
Bu arada kullanıcıdan, görev "bu klasörü özetle" iken "tüm dosyalara erişim" diyen bir diyalog hakkında akıl yürütmesi istenir. Diyalog görevi ifade edemez çünkü işletim sistemi görevi bilmez. Dolayısıyla onay, önemli olan o özel anlamda bilinçsizdir: kullanıcının gerçekte verdiği karara kapsamlandırılmamıştır. Apple'ın bu kontrolleri sıkılaştırmasına ilişkin haberler uygulama geliştirici deneyimine odaklanmıştır (The Verge, TechCrunch); agent durumu yapısal olarak farklıdır çünkü istekte bulunan varlık sabit bir özellik kümesi değildir.
Göreve kapsamlandırılmış bir alternatif
Kontrol, ikili bir işletim sistemi izninden göreve kapsamlandırılmış bir yetenek sözleşmesine taşınmalıdır. İşletim sistemi yetkisi bir tavan hâline gelir; agent framework'ü onu daraltan uygulama noktası olur.
Somut bir mekanizma: çalışma başına kapsamlandırılmış bir handle verin. Handle, dört alanlı küçük bir kayıttır.
- Yollar. Plan zamanında çözümlenen, yetki zamanında değil, açık bir dizin veya dosya allowlist'i. Symlink'ler çözümlenir ve kontrol edilen şey çözümlenmiş yoldur.
- Zaman penceresi. Bir duvar saati sona erme süresi. Sonrasında, süreç hâlâ canlı olsa bile handle etkisizdir.
- Byte bütçesi. Kümülatif bir okuma üst sınırı. Bütçe tükendiğinde, sonraki okumalar sessizce kesmek yerine fail closed yapar.
- Terminal durumu. Tamamlanınca iptal etme kuralı. Çalışma bir terminal duruma ulaştığında (başarı, başarısızlık, zaman aşımı, iptal), handle yok edilir ve denetim kaydı mühürlenir.
handle = broker.issue(
paths=["~/work/reports/q3"],
ttl_seconds=600,
byte_budget=64 * led"],
)
# her okuma dosya sisteminden değil, handle üzerinden geçer
blob = handle.read("~/work/reports/q3/summary.md")
Her okuma handle sınırında günlüğe kaydedilir; bu da denetim izini ikili dosya başına değil görev başına yapar. Bir şeyler ters gittiğinde, "bu çalışma neye dokundu" sorusunun süreç düzeyindeki telemetriden yeniden inşa edilmesi yerine doğrudan bir yanıtı olur.
Ödünleşim gerçektir ve açıkça belirtilmeye değer. Okumalara aracılık eden bir broker, başarısız olabilecek bir bileşen ekler ve çok dar bir byte bütçesi meşru uzun süreli işleri iptal eder. Bu nedenle framework, bütçeyi planner'a açmalıdır ki agent sınıra çarpmadan önce bir uzatma talep edebilsin, sınırı çalışma ortasında bir istisna olarak keşfetmesin. Bu, tek bir TCC anahtarından daha fazla hareketli parça demektir ve izni anlamlı kılmanın bedeli budur.
Bunun macOS agent geliştiricileri için anlamı
Geniş yetkinin caydırıldığı bir dünya için tasarlayın. Tek bir FDA onayı yerine belge seçicileri, security-scoped bookmark'ları ve dizin başına yetkileri tercih edin. Tek bir klasöre işaret eden bir bookmark, home dizini genelinde bir okumadan daha dar bir yetenektir ve her çalışmada kalıcı kılınıp yeniden doğrulanabilir.
Yetkinin kullanıcıya bir bildirimde görüneceğini varsayın ve o bildirimi anlamlı kılın. Sistem "bu agent Messages veritabanınızı okudu" diye gösteriyorsa, agent hangi görevin buna yol açtığını ve verinin ne için kullanıldığını söyleyebilmelidir. Kullanıcının üzerine işlem yapamadığı bir bildirim, onlara bildirimleri yok saymayı öğretir; bu da kontrolü diğer tüm uygulamalar için bozar.
Çalışma ortasında iptali planlayın. Bir handle sona erebilir, bir bookmark bayatlayabilir, kullanıcı agent çalışırken yetkiyi kapatabilir. Agent ölümcül değil, devam ettirilebilir olmalıdır: planı checkpoint'leyin, yeteneğini kaybeden adımı işaretleyin ve ya daha dar kapsamlı yeni bir handle isteyin ya da kısmi bir sonuçla temiz biçimde durun. İptali bir çökme olarak ele almak, bir güvenlik kontrolünü bir güvenilirlik olayına dönüştürür; kontroller bu şekilde devre dışı bırakılır.
Daha geniş nokta şu: güven birimi iş birimiyle eşleşmelidir. Bir agent çalışması iş birimidir. Bir ikili dosyanın ömrü değildir. İzin modeli bunu yansıtana kadar, macOS'taki her agent, görevinin hiç gerektirmediğinden fazlasını okumaya tek bir prompt injection uzaklıktadır.