Yapay zekâ asistanına “çalışma dosyalarımı görsün” izni vermek, görev tanımı değildir. Hangi dosyaları okuyacağı, hangi reklam hesabında neyi göreceği, neyi değiştirebileceği, hangi eylemde insan onayı isteyeceği ve erişimin ne zaman biteceği ayrı kurallardır. Bu ayrım yapılmadığında kolaylık, gereksiz yetkiye dönüşür.

Meta, Ağustos 2026'da küçük işletmelere yönelik Meta AI özelliklerinde Instagram ve Facebook analitiği, Meta Ads ve Google Workspace içindeki Gmail, Docs, Sheets ve Slides ile bağlantı senaryolarını duyurdu.[1] Böyle entegrasyonlar reklam analiziyle çalışma dosyalarını aynı asistan akışında buluşturuyor. Değer açık: ekip bağlam değiştirmeden veri toplayabiliyor. Risk de aynı nedenle büyüyor: tek görev, birden fazla sistemin birleşik erişimine sahip olabiliyor. AI ajanları satın alma kararına girerken markanın karşılaştığı riskleri ayrı bir yazıda ele almıştık; buradaki konu o ajanın hangi kapıdan içeri girdiğidir.

İlk sınır neden “hangi veriye?” değil, “hangi görev için?” sorusuyla çizilmelidir?

Yetki tasarımı araç listesinden başlamamalıdır. Önce asistanın yaptığı iş tek cümleyle yazılmalıdır. “Kampanya performansından haftalık özet çıkar” görevi için reklam verisini okumak gerekebilir; kampanya bütçesini değiştirmek gerekmez. “Toplantı notundan aksiyon çıkar” görevi seçilmiş bir dokümanı okumayı gerektirir; bütün Drive'ı taramak zorunda değildir.

Microsoft 16 Temmuz 2026 tarihli AI agent least-privilege rehberinde ajanlara ayrı kimlik, görev bazlı rol, kontrollü araç erişimi ve uçtan uca denetlenebilirlik verilmesini öneriyor.[2] Aynı rehber, kapsamın kaynak, veri ve işlem sınırında ayrı ayrı daraltılmasını savunuyor.[2] Bu sınırların ticari sistem tarafındaki karşılığını agentic commerce için e-ticaret altyapısının nasıl hazırlanacağı yazısında ele aldık. Bu yaklaşım güvenlik ekibinin soyut ilkesi değil, işletim tasarımıdır. Görev cümlesinde bir fiil bulunmalıdır: oku, özet çıkar, karşılaştır, taslak oluştur, güncelle. “Yönet” gibi geniş fiiller uygulamada kaç farklı eyleme izin verildiğini saklar.

Okuma izni ile yazma izni neden aynı pakette verilmemelidir?

Bir asistanın veriyi analiz etmesi ile canlı sistemde değişiklik yapması farklı risk sınıflarıdır. Microsoft, 30 Haziran 2026 tarihli güvenlik yazısında pasif özet üreten araçtan eylem yapan ajana geçişte saldırı etkisinin değiştiğini; araç kullanımının yanlış veya manipüle edilmiş talimatları gerçek işleme çevirebildiğini belirtiyor.[3] Aynı kaynak yüksek etkili eylemlerde insan onayı ve sınırlı araç erişimi öneriyor.[3]

Reklam hesabında salt okuma yetkisi performans özetine yeterliyse bütçe güncelleme, kampanya durdurma veya yeni reklam oluşturma hakkı kapalı kalmalıdır. Drive tarafında dosya okuma ihtiyacı varsa silme, taşıma veya paylaşım değiştirme izni ayrı değerlendirilmelidir. Temsili bir yetki hesabında asistanın 6 araçla çalıştığını ve her araçta 4 eylem türü bulunduğunu varsayalım: oku, oluştur, değiştir, sil. “Her şeye izin ver” yaklaşımı 24 eylem yüzeyi açar: 6×4 = 24. Görev yalnız 4 araçta okuma ve bir araçta taslak oluşturma gerektiriyorsa 5 eylem yeterlidir. Potansiyel yetki yüzeyi 24'ten 5'e iner. Bu sayı güvenlik benchmark'ı değildir; görev bazlı izin tasarımının etki alanını nasıl küçülttüğünü gösterir.

Google Drive’da dosya bazlı erişim neden tüm sürücüyü açmaktan daha doğru olabilir?

Google'ın Drive API dokümantasyonu, uygulamaların mümkün olan en dar OAuth kapsamını istemesini öneriyor.[4] drive.file kapsamı, kullanıcının uygulamayla açtığı veya özellikle paylaştığı dosyalara erişim verir. Buna karşılık drive ve drive.readonly gibi kapsamlar bütün Drive dosyalarına geniş erişim sağladığı için “restricted” sınıfında yer alıyor.[4]

Bu ayrım pazarlama ekibi için somut bir tasarım kararıdır. Asistanın aylık medya planı ile üç kampanya raporunu analiz etmesi gerekiyorsa kullanıcı bu dört dosyayı seçebilir. İnsan kaynakları, sözleşme veya başka müşteri klasörlerinin aynı erişim içinde görünmesi gerekmez. Google'ın OAuth consent rehberi aynı tarihte kapsamları non-sensitive, sensitive ve restricted olmak üzere üç sınıfta topluyor; kısıtlı kapsamların ek doğrulama ve bazı durumlarda güvenlik değerlendirmesi gerektirdiğini belirtiyor.[5] Üç sınıfın varlığı bile “erişim var/yok” ikiliğinin neden yetersiz olduğunu gösterir.

E-posta erişimi neden dosya erişiminden daha geniş risk taşıyabilir?

E-posta tek bir belge değildir; müşteri, tedarikçi, finans, hukuk ve kişisel yazışmaların aynı kutuda birleştiği sürekli veri akışıdır. “Gelen kutumdan özet çıkar” talebi, görevin gerektirdiğinden çok daha geniş bilgiye temas edebilir. Gönderen, etiket, klasör, tarih aralığı veya konu bazlı sınırlama yoksa asistanın bağlamı hızla büyür.

Bu nedenle e-posta senaryosunda önce arama filtresi ve erişim amacı tanımlanmalıdır. Örneğin yalnız belirli kampanya etiketi, yalnız son 7 gün veya yalnız belirli proje gönderenleri. Ardından taslak oluşturma ile gönderme yetkisi ayrılır. Asistan taslak yazabilir; dışarıya gönderim insan onayında kalabilir.

Meta'nın Ağustos 2026 duyurusu Google Workspace bağlantılarının doküman ve e-posta üzerinde üretken iş akışları kurabildiğini gösteriyor.[1] Bu imkân, veri minimizasyonunu daha değerli hâle getirir. Asistan ne kadar çok sistemi aynı anda okuyabiliyorsa amaç dışı bağlamın birleşme olasılığı o kadar artar.

Ajanın ayrı kimliği neden “kim yaptı?” sorusunu çözer?

İnsan hesabının token'ını paylaşan ajan, yaptığı işlemi kullanıcıdan ayırmayı zorlaştırır. Microsoft, AI ajanının ilk sınıf bir principal, yani ayrı güvenlik öznesi gibi ele alınmasını; kendine ait kimlik, açık sahip ve yaşam döngüsü bulunmasını öneriyor.[2] 14 Mayıs 2026 tarihli savunma katmanları yazısı da ajan kimliğini yetkilendirme ve denetlenebilirliğin temel bileşeni olarak tanımlıyor.[6]

Ayrı kimlik, her iş için yeni kullanıcı oluşturmak anlamına gelmez. Kimlik sabit kalabilir; yetkiler görev veya süre boyunca yükseltilip sonra geri alınabilir. Microsoft bu modeli zaman sınırlı yetkiler ve gerektiğinde just-in-time yükseltme ile açıklıyor.[2] İkinci temsili senaryoda aynı şirket hesabını 4 otomasyonun kullandığını düşünelim. Bir kampanya kaydı değiştiğinde log yalnız ortak hesabı gösterirse dört aday vardır. Her otomasyon ayrı kimlikle çalıştığında olay tek kaynağa iner. Hata çözümünün süresi doğrudan dörtte bire inmez; fakat kök neden aramasındaki kimlik belirsizliği ortadan kalkar. Bu örnek operasyonel izlenebilirliği anlatır, performans garantisi değildir.

İnsan onayı hangi eylemlerde zorunlu tutulmalıdır?

Onay eşiği eylemin geri alınabilirliği ve etkisiyle belirlenmelidir. Bir rapor taslağı oluşturmak kolay geri alınır. Kampanya bütçesi değiştirmek, müşteriye e-posta göndermek, dosya silmek veya erişim paylaşmak dış etki yaratır. Bu eylemler tek bir “asistan yetkili” kutusuyla otomatikleştirilmemelidir. Microsoft 30 Haziran tarihli çalışmasında “least agency”, yani yalnız en az yetki değil, en az eylem özerkliği yaklaşımını öneriyor.[3] Araç erişimi sınırlı olsa bile ajan kendi başına yüksek etkili adımlar seçebiliyorsa risk devam eder. Kritik eylemlerde deterministic human-in-the-loop, yani kurala bağlı insan onayı, prompt içindeki “dikkatli ol” talimatından daha güçlü kontroldür.[6] Onay ekranı da anlamlı bilgi vermelidir: hangi hesap, hangi nesne, eski değer, yeni değer, gerekçe ve geri alma yolu. “Devam etmek istiyor musunuz?” sorusu gerçek onay değildir.

Prompt talimatı neden erişim kontrolünün yerine geçmez?

“Asla sözleşme dosyalarını okuma” demek, o dosyalara teknik erişimi açık bıraktığınız sürece güvenlik sınırı değildir. Microsoft, yalnız prompt'a veya “ajan bunu yapmaz” anlatısına güvenmenin araç kapsamı ve aşağı akış yetkilendirmesi olmadan yetersiz olduğunu açıkça yazıyor.[2] 14 Mayıs rehberi de izinlerin varsayılan olarak sıfırdan başlamasını ve eylemlerin açıkça etkinleştirilmesini öneriyor.[6]

IETF'nin OAuth 2.0 Security Best Current Practice belgesi, erişim ve yenileme token'larının saldırı yüzeyini azaltmak için kapsam ve bağlama uygun korumalar önerir.[7] Belge AI ajanlarını özel olarak düzenlemez; OAuth kullanan uygulama ve ajan bağlantılarının temel yetkilendirme katmanına uygulanır. Doğru sıra şudur: önce sistem yetkisi sınırlandırılır, sonra prompt çalışma davranışını yönlendirir. Prompt, güvenlik duvarı değildir.

Denetim kaydı hangi soruları cevaplayabilmelidir?

İyi log yalnız “tool called” yazmaz. Kim çağırdı, hangi kullanıcı adına, hangi izinle, hangi kaynağa, hangi parametreyle, hangi sonucu aldı ve hangi değişikliği yaptı sorularını cevaplar. Microsoft 16 Temmuz rehberi uçtan uca auditability'yi dört temel uygulamadan biri olarak sayıyor.[2]

Microsoft 20 Mart 2026'da güvenlik altyapısının günlük 100 trilyondan fazla sinyal, 1,6 milyon müşteri, 1 milyar kimlik ve 24 milyar Copilot etkileşimi gibi ölçeklerde çalıştığını açıkladı.[8] Bunlar Microsoft ekosisteminin kendi ölçek metrikleridir; tek bir şirketin log ihtiyacını belirlemez. Fakat ajanların çok sayıda sistemle çalıştığı ortamda olay kaydının neden ayrı bir veri katmanı olduğunu gösterir. Denetim kaydı sonsuza kadar tutulmamalıdır. Saklama süresi veri sınıfı, mevzuat ve olay çözme ihtiyacına göre belirlenir. Gereksiz log da gereksiz veri kopyasıdır.

Yetki matrisi pratikte nasıl görünmelidir?

Araç bazlı liste yerine görev × veri × eylem matrisi daha kullanışlıdır. Her satırda sahip, geçerlilik süresi ve onay eşiği bulunmalıdır. Aşağıdaki örnek genel çerçevedir; gerçek şirket yetkileri kurumun güvenlik ve hukuk politikasıyla doğrulanmalıdır.

Görev	Veri sınırı	İzin	Otomatik eylem	İnsan onayı
Haftalık reklam özeti	Seçili reklam hesabı, rapor metrikleri	Salt okuma	Özet oluşturma	Gerekmez
Kampanya önerisi	Reklam verisi + onaylı ürün dosyası	Salt okuma	Taslak plan	Yayın/değişiklik öncesi gerekir
Toplantı özeti	Kullanıcının seçtiği Docs dosyaları	Dosya bazlı okuma	Aksiyon taslağı	Harici paylaşımda gerekir
Bütçe güncelleme	İlgili kampanya	Sınırlı yazma	Öneri oluşturma	Canlı değişiklikte gerekir
E-posta yanıtı	Etiketli proje yazışmaları	Okuma + taslak	Taslak oluşturma	Gönderimde gerekir
Dosya silme/paylaşma	Varsayılan erişim yok	Kapalı	Yok	Ayrı yetkilendirme gerekir

Asistanın gördüğü veriyi başka yere kopyalaması neden ayrı izin sayılmalıdır?

Okuma yetkisi ile veriyi dışarı aktarma yetkisi aynı şey değildir. Bir dosyanın içeriğini çalışma bağlamında okuyabilen asistanın aynı veriyi başka bir tabloya, e-postaya veya harici araca taşıması yeni bir işlem sınırı oluşturur. Microsoft'un 16 Temmuz rehberi kaynak sınırı kadar operasyon sınırının da açık tanımlanmasını öneriyor.[2] “Read” izni bu nedenle “export” iznini otomatik içermemelidir.

Temsili bir dosya akışında asistanın 20 proje belgesini okuyup yalnız 5 ölçümü anonim bir rapora taşıması gerekiyor olsun. Tüm 20 belgenin tam metnini yeni sisteme kopyalamak veri minimizasyonuna aykırıdır; gerekli 5 alanı taşımak yeterlidir. Buradaki 20 ve 5 örnek sayılardır. Yönetim ilkesi basittir: erişilen verinin tamamı, üretilen çıktının tamamı olmak zorunda değildir. Çıktı alanı ayrıca izinlendirilir, alıcı doğrulanır ve gereksiz ham veri yeni bir sisteme taşınmaz. Bu kontrol, özellikle müşteri ve ticari dosyaların farklı araçlarda çoğalmasını sınırlayan temel, güvenli ve ölçülebilir veri yönetişimi kuralıdır.

Erişim ne zaman otomatik sona ermelidir?

Görev bittiğinde yetkinin devam etmesi, geçici erişimi kalıcı riske çevirir. Microsoft, zaman sınırlı entitlement ve hızlı revocation mekanizmalarını ajan yaşam döngüsünün parçası olarak tanımlıyor.[2] Kampanya analizi için verilen erişim proje sonundan aylar sonra hâlâ açıksa sistem görev bazlı çalışmıyordur.

Periyodik gözden geçirme üç şeyi sorar: Ajan hâlâ gerekli mi? Bu araç hâlâ gerekli mi? Bu kapsam hâlâ en dar seçenek mi? “Bir gün lazım olur” gerekçesi yetki tutma nedeni değildir. Kapatma testi de gerçek yapılmalıdır. Token iptal edildiğinde ajan erişimi gerçekten kaybediyor mu, önbellekteki dosyalar ne kadar tutuluyor, eski görevler tekrar çalışabiliyor mu? Erişimin verildiği kadar geri alınabildiği de kanıtlanmalıdır.

Yeni bir connector açılmadan önce hangi dört soru cevaplanmalıdır?

Connector, yani harici sistem bağlantısı eklemek yalnız teknik kurulum değildir. Önce hangi veri sınıfına erişeceği, hangi görev için gerektiği, hangi eylemleri çalıştıracağı ve bağlantının sahibi belirlenmelidir. Microsoft'un ajan güvenliği yaklaşımı kimlik, rol, kaynak kapsamı ve araç izinlerini birlikte ele alıyor.[2][3] Google ise OAuth kapsamlarını seçerken minimum gerekli erişimin istenmesini ve geniş Drive erişimi yerine dosya bazlı seçeneklerin değerlendirilmesini öneriyor.[4][5]

Temsili bir onay kartında bağlantı 4 veri grubuna dokunuyor olsun: reklam, müşteri, finans ve genel çalışma dosyaları. Görev yalnız reklam performansını okuyup seçilmiş rapor dosyasına taslak eklemekse müşteri ve finans gruplarının ikisine de ihtiyaç yoktur. Dört veri grubunun tamamını açmak yerine ikisiyle çalışmak veri yüzeyini yarıya indirir; bu oran güvenlik riski yarıya iner anlamına gelmez, yalnız erişim kapsamının küçüldüğünü gösterir.

Bağlantı onayında ayrıca “hangi durumda yeniden onay gerekir?” alanı bulunmalıdır. Salt okuma bağlantısına yazma eklenmesi, yeni bir hesap/tenant açılması, dışarı veri aktarımı veya otomatik gönderim gibi değişiklikler material change olarak görülmelidir. İlk genel onay bu yeni yetkilere taşınmamalıdır. Böylece connector listesi teknik envanterden gerçek yetki kayıt sistemine dönüşür.

Hassas dosyalar için etiketleme neden asistan ayarından önce gelmelidir?

Asistan yalnız erişebildiği sistemi değil, o sistemdeki veri sınıflandırmasını da devralır. Dosyalar “genel”, “müşteri”, “finans”, “hukuk” veya “kişisel” gibi işaretlenmiyorsa dar kapsamlı erişim kurmak zorlaşır. Google'ın dosya bazlı drive.file yaklaşımı kullanıcıya belirli dosyaları seçme kontrolü verir;[4] kurum içi etiketleme ise hangi dosyanın seçilmemesi gerektiğini operasyon seviyesinde görünür kılar.

Temsili bir klasörde 200 dosyanın 30'u müşteri sözleşmesi, 20'si finans kaydı ve 150'si genel proje dokümanı olsun. “Klasörü aç” yaklaşımı 200 dosyayı erişim alanına sokar. Görev yalnız 12 raporla çalışıyorsa seçili dosya modeli gerçek çalışma alanını 12 kayıtla sınırlar. Bu sayılar örnektir; risk azalması doğrudan 200/12 oranına eşit değildir. Değer, gereksiz dosyaların görev bağlamına hiç girmemesidir.

Bu ne zaman geçersiz?

Tamamen yerel, kişisel ve hassas olmayan bir taslak akışında kurumsal düzeyde ayrı ajan kimliği ve çok aşamalı onay gereksiz olabilir. Risk düşükse kontrol de hafifletilebilir. Ancak “düşük risk” varsayımı veri envanteri görülmeden yapılmamalıdır; kişisel Drive içinde çalışma dosyasıyla bordro belgesi aynı klasörde bulunabilir. Ayrıca fazla dar izinler iş akışını sürekli insan müdahalesine bağlıyorsa kullanıcılar sistemi baypas etmeye başlayabilir. Amaç işi durdurmak değil, gerekli minimum erişimi doğru yerde vermektir. Kapsam daraltma kullanılabilirliği bozuyorsa görev yeniden tasarlanmalı veya güvenli bir ara veri katmanı kurulmalıdır.

Roilab değerlendirmesi

Roilab önce iş amacını, sonra gerekli veri kaynaklarını, ardından her kaynak için okuma-yazma sınırını tanımlar. Canlı ticari eylemler ayrı onay katmanına alınır. Ajanın yapabildiği her şey değil, yapması gereken en küçük eylem seti işletim kapsamı sayılır. Yapay zekâ entegrasyonunda olgunluk daha fazla bağlantı kurmak değildir. Gereksiz bağlantıyı açmadan aynı işi yapabilmek, yapılan her eylemi açıklayabilmek ve ihtiyaç bittiğinde erişimi gerçekten kapatabilmektir.

Başvurun, değerlendirelim.

Kaynaklar

[1] Meta, New Meta AI features for small businesses, Ağustos 2026 — https://www.facebook.com/business/news/meta-ai-for-small-businesses

[2] Microsoft Security, Least privilege for AI agents: Identity, access, and tool binding, 16 Temmuz 2026 — https://www.microsoft.com/en-us/security/blog/2026/07/16/least-privilege-for-ai-agents-identity-access-and-tool-binding/

[3] Microsoft Security, Securing AI agents: When AI tools move from reading to acting, 30 Haziran 2026 — https://www.microsoft.com/en-us/security/blog/2026/06/30/securing-ai-agents-ai-tools-move-from-reading-acting/

[4] Google for Developers, Choose Google Drive API scopes, erişim 15 Eylül 2026 — https://developers.google.com/workspace/drive/api/guides/api-specific-auth

[5] Google for Developers, Configure the OAuth consent screen and choose scopes, erişim 15 Eylül 2026 — https://developers.google.com/workspace/guides/configure-oauth-consent

[6] Microsoft Security, Defense in depth for autonomous AI agents, 14 Mayıs 2026 — https://www.microsoft.com/en-us/security/blog/2026/05/14/defense-in-depth-autonomous-ai-agents/

[7] IETF, RFC 9700: Best Current Practice for OAuth 2.0 Security, Ocak 2025; sayfa güncellemesi 20 Mayıs 2026 — https://datatracker.ietf.org/doc/rfc9700/

[8] Microsoft Security, Secure agentic AI end-to-end, 20 Mart 2026 — https://www.microsoft.com/en-us/security/blog/2026/03/20/secure-agentic-ai-end-to-end/