AI Ajanına Hesap Erişimi Vermek Güvenli mi?
Kısa cevap: duruma göre. Bir yapay zeka (AI) ajanına Google Ads raporlarını okuma yetkisi vermekle, ödeme veya müşteri verisine dokunan bir işlemi ona bırakmak aynı risk kategorisinde değil. Güvenliği belirleyen iki eksen var: ajanın ne yapabildiği (sadece okuyor mu, yoksa işlem de yapıyor mu) ve hangi veriye eriştiği (genel performans verisi mi, kişisel/finansal veri mi). Salt okuma + genel veri düşük risktir; yazma yetkisi + hassas veri ciddi disiplin ister. Bu çerçeveyi ve 43 reklam hesabı yönetirken gerçekte uyguladığım kuralları, Agentic AI Rehberi’nin bu sayfasında anlatıyorum.
AI Ajanında Risk Seviyeleri: Salt Okuma vs Yazma Yetkisi
Bir AI ajanına erişim verirken sorulacak ilk soru güvenli mi değil; ne yapabiliyor ve neye dokunuyor sorusudur. Bu iki soru riski iki kutuya ayırır.
Düşük risk — salt okuma (read-only): Ajan veriyi görüyor, rapor üretiyor, analiz yapıyor ama hiçbir kaydı değiştiremiyor. Örnek: Google Ads’in resmi MCP sunucusu salt okuma çalışır — ajan kampanya performansını, anahtar kelime raporunu, GAQL sorgusunu görebilir ama bütçe değiştiremez, kampanya duraklatamaz. Yanlış bir yorum en kötü ihtimalle yanlış bir rapor üretir; hesaba zarar vermez.
Yüksek risk — yazma/işlem yetkisi: Ajan kayıt oluşturuyor, güncelliyor veya siliyor. Örnek: Meta’nın resmi Ads MCP sunucusu yazma yetkilidir — kampanya oluşturabilir, reklam seti güncelleyebilir, özel kitle silebilir. Aynı şekilde bir WordPress sitesine SSH/veritabanı erişimi veren bir ajan, yanlış bir komutla siteyi çökertebilir veya veritabanını bozabilir. Buradaki hata geri dönüşü olmayan bir hasara dönüşebilir.
Pratik sonuç: aynı AI ajanı etiketi altında birbirinden çok farklı risk profilleri var. Platform seçerken ilk kontrol edeceğiniz şey, o platformun resmi entegrasyonunun salt okuma mı yazma yetkili mi olduğu.
| Erişim türü | Risk | Örnek | En kötü senaryo |
|---|---|---|---|
| Salt okuma (raporlama, analiz) | Düşük | Google Ads MCP, GA4 raporlama, Search Console okuma | Yanlış yorum/rapor |
| Yazma/işlem (oluşturma, güncelleme, silme) | Yüksek | Meta Ads MCP, WordPress veritabanı erişimi, ödeme entegrasyonu | Veri kaybı, hesap/site hasarı, finansal işlem hatası |
Güvenli Kurulumun 5 Kuralı
Erişim vermeden önce uyguladığım beş kural var. Hiçbiri karmaşık değil, ama atlanması en sık gördüğüm hata.
- En az yetki prensibi. Ajana hesabın tamamını değil, işi görecek en dar kapsamı verin — tüm portföy değil tek bir property, tüm sunucu değil tek bir dizin, admin değil salt okuma rolü. Kapsamı sonra genişletmek, baştan geniş verip daraltmaktan her zaman daha kolay.
- Kritik işlemlerde insan onayı. Bütçe değiştirme, kampanya durdurma, veritabanı yazma gibi geri dönüşü zor işlemler, ajanın öneri sunup onayı benim verdiğim bir akışta kalmalı — ajan tek başına tetiklememeli.
- API anahtarlarını güvenli saklayın. Anahtarları koda gömmeyin, sohbet geçmişine yapıştırmayın, düz metin dosyada tutmayın. Bir secret manager veya ortam değişkeni kullanın ve anahtarı düzenli aralıklarla yenileyin.
- Erişimi düzenli gözden geçirin. Üç ay önce verdiğiniz bir yetkinin hâlâ gerekli olup olmadığını sorun. Kullanılmayan entegrasyonlar sessizce açık kalan kapılardır.
- Kaynağı belirsiz üçüncü parti aracı kurmayın. MCP sunucusu adıyla dağıtılan her paket denetlenmiş değil. Resmi platform entegrasyonunu (Google, Meta, Microsoft gibi) tercih edin; bağımsız bir araç kuracaksanız kodunu veya en azından hangi izinleri istediğini önce inceleyin.
KVKK ve Müşteri Verisi: Nelere Dikkat Etmeli
Bir AI ajanına müşteri verisi (e-posta, telefon, sipariş geçmişi, ödeme kaydı) işlettiriyorsanız KVKK kapsamına giriyorsunuz demektir. Dikkat edilmesi gereken üç nokta:
- Verinin nereye gittiği. Ajanın arka planda kullandığı model sağlayıcısı veriyi nerede işliyor, ne kadar süre saklıyor, eğitim verisi olarak kullanıp kullanmadığı sözleşme/gizlilik metninde açık olmalı.
- Aktarım gerekçesi. Kişisel veriyi üçüncü bir sisteme (AI sağlayıcısı dahil) aktarmanın KVKK’da bir hukuki dayanağı olmalı — açık rıza, sözleşmenin ifası veya meşru menfaat gibi.
- Anonimleştirme mümkünse tercih edin. Ajan işini isim/telefon olmadan da yapabiliyorsa (örn. 342 numaralı müşteri gibi bir referansla), veriyi anonimleştirip vermek riski büyük ölçüde azaltır.
Bu bölüm genel bir çerçeve sunar, hukuki tavsiye değildir — KVKK uyumluluğunda netlik için bir hukuk danışmanına başvurun.
43 Hesap Yönetirken Uyguladığım Disiplin
43 reklam hesabını AI ajanlarıyla yönetirken erişim konusunda tek bir kural belirleyici oldu: yetkiyi hesap veya müşteri seviyesinde değil, en dar kapsamda veriyorum. Bir ajan tek bir müşterinin tek bir hesabına, o an gereken işlem için erişir; bir ajanın tüm portföye erişip gerekeni kendisinin bulduğu bir kurulum hiç yok.
İkinci kural: okuma ve yazma katmanları ayrı. Rapor çekmek, performans yorumlamak gibi işler salt okuma erişimiyle günlük akışta çalışıyor. Bütçe değiştirme, yayına alma gibi geri dönüşü zor işlemler ayrı, daha kısıtlı bir kimlik üzerinden ve her seferinde önce mevcut durumu kaydedip sonradan geri dönebileceğim bir adımla yapılıyor. Bu, tek bir yanlış komutun 43 hesabın tamamını değil, o anki tek işlemi etkilemesini sağlıyor.
Üçüncü kural: sunucu/veritabanı seviyesinde çalışan işler için yedek almadan hiçbir yazma işlemi yapılmıyor. Bu kural özellikle web sitesi yönetiminde geçerli — bir ajan yanlış bir veritabanı komutu çalıştırırsa, geri dönüş yolu önceden alınmış bir yedekten başka bir şey değil.
Ne Zaman Erişim Vermemelisiniz
Dürüst olmak gerekirse, her iş AI ajanına devredilmemeli. Şu durumlarda erişim vermemeyi tercih ederim:
- Ödeme bilgisi ve finansal işlem yetkisi. Kredi kartı numarası, banka hesabı, doğrudan para transferi yetkisi bir ajana verilecek bir şey değil — insan onayı olmadan asla.
- Hassas kişisel veri (TC kimlik, sağlık verisi, biyometrik veri). Bu kategoriler KVKK’da özel nitelikli sayılır ve işlenme koşulları daha ağırdır; riski göze almaya değmez.
- Tek seferlik, düşük hacimli işler. Yılda bir kez yapılan bir işlem için entegrasyon kurmanın güvenlik yükü, elle yapmanın maliyetinden daha fazla olabilir.
- Geri alma yolu olmayan işlemler. Kalıcı silme, yayına alma, yasal belge onayı gibi adımlarda ajan öneri sunar, karar insanda kalır.
Bu İşi Benden İsteyebilirsiniz
Erişim ve yetkilendirme kurulumunu doğru yapmak bir kere kurup unutulacak iş değil — hangi platformun ne tür erişim istediğini bilmek, en az yetki prensibini uygulamak ve kritik işlemler için onay akışı kurmak deneyim ister. Bu işi benden isteyebilirsiniz: genelde 2 saat–2 hafta arası süren, uzaktan, saatlik ücretli bir iş. Yapay zekada veri güvenliği hizmetime göz atabilir veya doğrudan iletişime geçebilirsiniz.
Sıkça Sorulan Sorular
Yapay zeka ajanına hesap erişimi vermek gerçekten güvenli mi?
Kısa cevap duruma göre değişir: ajanın salt okuma mı yazma yetkili mi olduğuna ve hangi veriye eriştiğine bakılır. Google Ads raporlarını okuyan bir ajan düşük risklidir; ödeme veya veritabanı işlemi yapan bir ajan yüksek risklidir. Bu sayfadaki risk çerçevesi ve 5 kural, kararı somutlaştırmak için.
AI ajanına API anahtarı vermek güvenli mi?
Anahtarın kendisi değil, taşıdığı yetki önemli. Salt okuma kapsamlı, süresi sınırlı, tek kaynağa özel bir anahtar düşük risktir. Yönetici yetkili, süresiz, birden çok sisteme geçerli bir anahtar riski büyütür. Anahtarı düz metinde paylaşmayın, düzenli yenileyin.
ChatGPT veya benzeri bir asistana şirket verisi yüklemek KVKK’ya aykırı mı?
Otomatik olarak aykırı değil, ama kişisel veri içeriyorsa (müşteri adı, telefon, sipariş bilgisi) bir hukuki dayanağınız olmalı ve verinin nereye gittiğini bilmeniz gerekir. Mümkünse veriyi anonimleştirip yükleyin; netlik için bir hukuk danışmanına danışın.
MCP sunucusu ile normal API entegrasyonu arasında güvenlik açısından fark var mı?
MCP (Model Context Protocol), bir AI ajanının bir platforma nasıl bağlanacağını standartlaştıran bir protokol — kendisi güvenlik garantisi vermez. Güvenliği belirleyen, o MCP sunucusunun salt okuma mı yazma yetkili mi olduğu ve kimin (resmi platform mu, bağımsız geliştirici mi) yayınladığı.