Yirmi yılı aşkın meslek hayatımda, yeni bir aracın gelişinde iki ayrı şeyi izlemeye alıştım. Bir yanda demo var: temiz ışık, sivri köşelerin yerini bilen sunucu. Öbür yanda ilk salı sabahı: biri o aracı kendi düzeninde açıyor ve o sivri köşeler artık onun dizini buluyor. Bu iki hâlin arasındaki boşluk, bizim gibi insanların ekmeğini kazandığı yerdir.
Bu yazıyı, bir slayt ya da toplantı masasında “yapay zekâ ajanı kurumsal bir WordPress sitesinde güvenle çalışır” denileni dinleyen kişi için yazıyorum. Söz konusu platform WordPress VIP, yani Automattic’in kurumsal WordPress sunumu; söz konusu özellik Secure MCP. Vaat şu: ajan platformu okur, içerik yazar, yayına alır, önbelleği temizler, her hareket denetime kayıtlı olur. Vaat büyük ölçüde doğru. Ama vaat, belgelerde doğrudan yazmayan birkaç davranışla sessizce şekilleniyor. Bunları üretimde keşfedersen bir günü yanlış yerde arayarak geçiriyorsun.
Biz kendi kum havuzumuzu Secure MCP’ye bağladık, transkript tuttuk, bulguları Automattic’e geri rapor ettik. Aşağıdakiler, eklentiyi yapılandıran kişiye değil, sözleşmeyi imzalayan kişiye yazılmış. Dipteki inşa bölümü ise, yapay zekâ operasyonlarına dokunan her WordPress VIP işinde fiyata kattığımız kısım.
Vaat ile İlk Saat Farklı İki Yazılım
Secure MCP, 2 Temmuz 2026’da tüm WordPress VIP müşterilerine açıldı. Customer Hub duyurusu özelliği “ajanlar için denetlenebilir, yönetilen bir uç nokta” olarak tanımlıyor; organizasyon düzeyinde bir acil durum anahtarı, “her değiştirici hareketin yetkilendirilmiş kullanıcıya atfedilerek loglanması” vaadiyle beraber. Biz VIP ajans ortaklık programına başvurduk ve bir ajan bu uç noktaya gerçekten bağlandığında ne yaşadığını görmek için bir sandbox uygulaması provizyonladık (The WP Clan organizasyonu, thewpclan-sandbox uygulaması). Bağlanan istemci kullanıcı kapsamında çalışan Claude Code idi. Zaman damgaları UTC olarak transkriptten alındı.
Hakkını teslim edelim. Kurulum gerçekten tek satır. Bağlantı sayfası şu komutu veriyor: claude mcp add --scope user --transport http vip-platform https://api.wpvip.com/mcp. Well-known uç noktalarındaki OAuth meta verisi Dynamic Client Registration ve PKCE’yi birlikte sunuyor. Yani elle client_id/secret kopyalama, yapılandırma dosyasına yapıştırma yok. Böyle çok sayıda entegrasyona bakmış bir ekibe bu ilk izlenim iyi geliyor. Sonra dikişler görünmeye başlıyor.
Bağlandıktan sonra istemciye 66 tool geliyor: app_*, environment_*, organization_* altında platform işlemleri; GraphQL kaçış yolları (search, execute, introspection); ve kasten ince tutulmuş WordPress MCP yüzeyi, yalnız üç tool (wordpress_discover_abilities, wordpress_get_ability_info, wordpress_execute_ability) üzerinden sitenin WP Abilities API’sini proxyliyor. Bizim kum havuzumuzda 55 yetenek çözüldü: core bilgi tool’ları, sayfa/yazı/etiket/medya/menü/pattern yetenekleri, tema preset ve allowed-blocks, Jetpack Forms. Çoğu kurumsal MCP’nin açtığından geniş bir yüzey. Burada okumak, yazmaya güvenip güvenmeyeceğine karar verdiğin ândır.
Belgelerde Doğrudan Yazmayan Dört Davranış
Bu dördünün her biri bize en az bir saat yanlış yönde arama yaşattı. Hata mesajı başka katı gösteriyordu. Automattic’e rapor ettiğimiz sıra, yeni bir ekibi en çok ısıracak olandan başlayarak. Sıralama bizim, onların değil.
Bir. Plain permalink, WordPress MCP bağlantısını sessizce bozuyor. 2026-08-26 UTC 11:11:49, 11:12:17 ve 11:14:27’de üç wordpress_discover_abilities çağrısı art arda WordPress MCP integration error: Failed to connect to WordPress MCP server döndü. WordPress tarafı sağlamdı: ?rest_route=/ REST indeksi mcp ve wp-abilities/v1 ad alanlarını listeliyordu. Ama /wp-json/ endpoint’i 301 ile sonu-slash’lı URL’ye yönleniyor, HTML servis ediyordu. Sebep: Ayarlar → Kalıcı Bağlantılar Plain‘de duruyordu, ki bu VIP’in yeni provizyonladığı uygulamaların varsayılanı. VIP’in WordPress MCP konektörü siteye /wp-json/ üzerinden konuştuğu için, kalıcı bağlantılar Yazı adına çekilip edge cache temizlenene kadar uç noktaya ulaşamadı. WordPress MCP ön koşullar sayfası Global MCP aktivasyonu, toolset etkinleştirme, e-posta eşleşmesi ve çok siteli site üyeliğini sıralıyor. Kalıcı bağlantıdan hiç söz etmiyor. Her yeni uygulamada bu bir kez karşına çıkacak.
İki. Eşlenen WordPress kullanıcısında, hiçbir yazma işlemi başlamadan önce 2FA açık olmalı. 11:43:27 ile 11:53:58 UTC arası altı ardışık çağrı, WordPress’in kendi yetki metnini döndürdü: Sorry, you are not allowed to create posts as this user. Kimlik doğruydu. core/get-user-info yanıtı 01clan, administrator; aynı hesap wp-admin’de her şeyi yapabiliyordu. Tek değişen, kullanıcı profilinde Email 2FA’nın açılması oldu. Bir sonraki çağrı aynı metinle değil, bir alan doğrulama hatasıyla döndü. İzin kapısının geçildiğini böyle anladık. Davranış VIP’in 2FA zorlama sayfasıyla tutarlı: Two-Factor Authentication eklentisi tüm VIP sitelerinde etkin ve Editor / Administrator / Super Admin rollerinde 2FA zorunlu. Ama Secure MCP sayfalarının hiçbiri oraya işaret etmiyor. Ajana dönen hata ise standart WordPress yetki metni; administrator olduğunu bilen biri buna saatlerce inanmıyor ve yanlış yerde arıyor.
Üç. Aynı e-postayı taşıyan iki WordPress kullanıcısı varsa, ajan yanlış kullanıcıya bağlanıyor. İlk core/get-user-info çağrıları Permission denied dönüyordu. Kum havuzunda iki kullanıcı [email protected]‘u paylaşıyordu: 01clan (administrator) ve thewpclan (subscriber, ağustos ayında bir WXR demo içerik içe aktarmasıyla oluşmuş). VIP’in eşlemesi subscriber’a düşüyordu. Düşük yetkili kullanıcının e-postası değiştirildiğinde sorun kapandı. WordPress MCP ön koşullar sayfası “e-postalar eşleşmeli” diyor; sitede iki kullanıcı eşleşirse ne olacağını söylemiyor. Cevap şu: biri sessizce seçiliyor ve hata metni sebebi ima bile etmiyor. WXR içe aktarmaları bu senaryoyu düzenli üretiyor, dolayısıyla migrasyonlarda sıklıkla karşımıza çıkacak bir durum.
Dört. environment_run_wpcli başarılı bir yanıt gövdesi döndürüyor, ama komutu tek başına çalıştırmıyor. 11:40:02, 11:55:21 ve 11:57 UTC’de üç komutun hepsi başarılı görünümlü döndü (tool, WebSocket ve SSH kimlik bilgileriyle bir oturum kuyruğa aldı). Ama komut geçmişini çekince (AppEnvironment.commands) üçü de status: preparing, startedAt boş. Hiçbiri koşmamış. Tool aslında bir oturum kuyruğa alıcı: bir istemcinin o WebSocket veya SSH oturumuna bağlanması gerekiyor. Aynı komut, resmi @automattic/vip CLI’da (4.1.1) ilk denemede koştu: vip @thewpclan-sandbox.production --yes -- wp eti-sandbox seed_home → Success: Seeded page 34886. Yani otonom bir ajan, bu tool’u ilan edildiği gibi kullanamaz: başarı mesajı alır, ama komut sonsuza kadar kuyrukta kalır.
Denetim İzi, Denetçinin Soracağı Şeyi Kapsamıyor
Bu, alıcı için en çok önemli olan maddedir, çünkü bir güvenlik incelemesinde fark edilen boşluktur. Secure MCP genel bakış sayfası aynen şöyle diyor: “Her MCP tool çağrısı kaydedilir. MCP Call Log, bir organizasyondaki tüm uygulamalar arası Secure MCP tool çağrılarını listeler; ortam bazlı görünüm tek bir ortamın çağrılarını listeler. Ortama yönelik tüm MCP etkinliği, VIP personeli tarafından yapılan hareketler dahil, MCP denetim günlüğüne kaydedilir.” Customer Hub duyurusu sözü tekrar ediyor: her değiştirici hareket loglanır, kullanıcıya atfedilir.
2026-09-15’te aynı uygulama üzerinde, aynı kullanıcı, aynı dakika, aynı tool ile kontrollü bir ikili test çalıştırdık. 09:25 UTC’de başarılı bir core/get-site-info çağrısı Call Log’a düştü. 09:25’te geçersiz id 999999999 ile bir vip/pages-update çağrısı, ki WordPress’in kendisi Invalid post ID. yanıtıyla döndü (yani çağrı siteye ulaştı ve cevap üretti), Call Log’a düşmedi. İkincisi iz bırakmadı.
26 Ağustos kayıtlarına geri gidince boşluk daha keskin. İki saat içinde dokuz başarısız çağrı iz bırakmamış: permalink düzeltmesinden önce üç başarısız wordpress_discover_abilities, 2FA düzeltmesinden önce altı başarısız yazma (dört pages-create, bir tags-create, bir pages-update). En sıkışık pencere örüntüyü gösteriyor: 11:41:18’de pages-list logluydu, 11:43:27, 11:45:06 ve 11:45:35’teki pages-create denemeleri logsuz, 11:46:30’daki deployments loglu, 11:53:10’daki pages-create logsuz, 11:53:18’deki core/get-user-info loglu, 11:53:49’daki tags-create ve 11:53:58’deki pages-update logsuz. Loglu bir çağrı ile iz bırakmayan bir reddedilme arasındaki fark sekiz saniye. “Sunucuya ulaşmadan başarısız oldu” açıklaması bu tabloyu açıklamıyor, çünkü reddedilmelerin gövdesi WordPress’in kendi REST yanıtı. Çağrı siteye ulaştı. Site cevapladı. Loga yazılmadı.
Aynı test, başarı tarafında da tutarsızlık gösterdi. app_list iki kere çağrıldı, ikisi de başarılı, ikisi de logsuz. app_list_environments loglu. search hiç loglanmıyor. GraphQL introspection ile mcpAuditLog, mcpCallLog, auditLog arandığında hiçbir tip veya alan yok. Yani Call Log programatik olarak dışa aktarılamıyor, bir SIEM’e otomatik yollanamıyor. Yalnızca Dashboard arayüzünden okunabiliyor.
Alıcı için pratik sonuç belirgin. “Reddedilen erişim denemeleri loglanıyor mu?” kurumsal güvenlik anketlerinin rutin sorusudur. Secure MCP’de bugün dürüst cevap “hayır”dır. “Denetim loglarını otomatik olarak SIEM’imize aktarabilir miyiz?” ikinci rutin sorudur. Bugün dürüst cevap yine “hayır”dır. İkisi de çözülebilir; ikisi de şu an çözülmemiş; ve yayımlanmış vaat, bir alıcının her ikisini de bekleyerek imza atmasına yetecek kadar güçlü.
Bir Ajanı Üretime Yazdırmadan Önce Yaptığımız Dört Şey
Bu bölüm inşa bölümüdür. Yapay zekâ ajanı barındıracak her WordPress VIP kurulumunda provizyon şablonuna gömdüğümüz dört madde, slayt için yuvarlanmış değil dürüst efor tahminleriyle.
- Her ortamda kalıcı bağlantılar “Yazı adı” ve betikleştirilmiş edge cache purge. Provizyon playbook’una tek satır, yazmak ve test etmek yaklaşık 20 dakika. Yoksa her uygulamada plain-permalink hatasını bir kez bulacaksın, ve asla boş bir öğle sonrasına denk gelmeyecek.
- Ajanın yazacağı her WordPress kullanıcısında 2FA açık. Dashboard kullanıcısının MFA’sı değil, farklı katman. Sitedeki WordPress kullanıcısının kendi 2FA’sı,
two-factoreklentisi üzerinden. Sandbox için Email yeterli; üretim için TOTP doğru varsayılan. Ajana token verilmeden önce etkinleştir. Editör başına on dakika. - Sorumluluğa göre toolset ayırımı. VIP MCP (platform işlemleri) ve WordPress MCP (site içeriği) her uygulamada bağımsız aktive oluyor. Yapay zekâ içerik ajanı yalnız WordPress MCP alır; platform değişiklikleri farklı bir, daha yüksek güven düzeyli ajana veya insana kalır. VIP’in belgelenmiş modelinde bu zaten var; sadece kullanılması gerekiyor.
- Reddedilen ajan hareketleri için orkestratör tarafında ayrı kayıt. Ajanı çalıştıran her neyse (iş akışı aracı, kuyruk, kendi kodun) reddedilen deneme logunu orada tutmalısın, çünkü Call Log tutmayacak. Tool çağrısı başına bir satır yapılandırılmış log, diğer güvenlik olaylarını gönderdiğin yere. Belki bir günlük iş, orkestratör zaten denemeleri loglıyorsa daha az.
Bir dahaki sefere farklı yapacağımız: kontrollü ikili testi üç hafta sonra değil, ilk gün koşmak. Eğer ilk saatte core/get-site-info ile anlamsız id’li bir vip/pages-update yan yana çağrılmış olsaydı, denetim boşluğunu permalink hatasından önce yakalardık. Doğru sıra oydu.
Alıcı, WordPress VIP Ajansı Seçerken Neyi Kanıtlatmalı
Broşür okumuş bir ajans ile platformu gerçekten işletmiş bir ajansı ayıran üç talep. Yapay zekâ çağı operasyonları için bir WordPress VIP ajansı değerlendiren alıcıya yazıldı.
- Demoyu değil, transkripti iste. Adlandırılmış bir sandbox uygulaması üzerinde tool çağrıları, yanıtlar ve başarısızlıklardan oluşan yazılı kayıt bir kalifikasyondur. Sohbet penceresi ekran görüntüsü değildir.
- Automattic’e ne rapor edildiğini sor. Biz VIP’e üç bulgu geçtik: plain-permalink’in WordPress MCP’yi bozması, eşlenen kullanıcıda 2FA zorunluluğu, Call Log denetim boşluğu. “Ne zaman neyi yukarı taşıdın?” adil bir sorudur.
- Platform tool’u ile içerik tool’unun nasıl ayrıldığını sor. İki toolset farklı risk taşıyor.
WordPress MCPveVIP MCP‘nin neden ayrı aktive edildiğini senin dağıtımında açıklayamayan bir ajans, yanlış ilk telefondur.
Kümedeki ilgili sayfalar: WordPress VIP nedir, güvenlik ve uyumluluk, platforma geçen ekipler için WordPress VIP geçiş.
Bizde hâlâ açık kalan: dağıtım ve geri alma üzerinde step-up doğrulama, ki sandbox’ı bozmamak için tetiklemedik; bölge sabitleme, çünkü sandbox datacenter: DFW‘ye düştü ve VIP, AB ile Türkiye bölgelerinin provizyonda sabitlenip sabitlenemediğini henüz söylemedi; ve ajansın müşteri organizasyonunda bulunduğu, yani Org admin’in müşteri olduğu ve ajans kullanıcılarının o sınırın içine düştüğü senaryo. Sıradaki üç soru bunlar. Yapay zekâ çağı operasyonları için WordPress VIP’i değerlendiriyorsan ve tam transkripti ya da Automattic’e giden üç e-postayı görmek istersen, bize yaz. Kum havuzunda şaşırmış biz olmayı, üretimde ilk yazma işi “başarılı” dönüp sitenin boş kaldığını fark ettiğinde gece yarısı aranan sen olmaya tercih ederim.
Last modified: Kasım 8, 2026
