MCP güvenliği nedir, pull request’te neye bakılır?

MCP sunucusu depoya nasıl girer?

Bu yazı, bir pull request’in kodlama ajanı için getirdiği yapılandırmaya bakıyor. Hook yazısında ajanın belirli anlarda kendiliğinden çalıştırdığı komutları, yapay zekânın yazdığı kodu inceleme yazısında da ajanın yazdığı kodu anlattık. Burada konu, ajana yeni bir araç kazandıran dosya.

MCP (Model Context Protocol), belirtimin kendi tanımıyla, yapay zekâ uygulamalarını dış veri kaynaklarına ve araçlara bağlayan açık bir protokoldür. Bir tarafta ajan, öbür tarafta bir MCP sunucusu durur. Sunucu, modelin çağırabileceği araçları (tools) tanımlar: bir issue’yu okumak, bir tarayıcı açmak, bir veritabanını sorgulamak gibi. 18 Ekim 2026 itibarıyla belirtimin en güncel sürümü 2026-07-28 tarihli.

Sunucu çoğu zaman sizin makinenizde çalışan bir programdır. Kodlama aracı, yapılandırma dosyasındaki command ve args satırlarıyla bu programı başlatır ve onunla programın standart girdisi ve çıktısı üzerinden konuşur; belirtim buna stdio der. Uzak bir sunucuda dosyada komut yerine bir adres (url) bulunur. Bu dosya kodla birlikte commit edilir: Claude Code’un belgesi, ekipteki herkes aynı araçları kullansın diye .mcp.json dosyasını sürüm kontrolüne koymanızı öneriyor. Araçların her biri başka bir dosyaya bakıyor:

Kaynak: her aracın kendi MCP belgesi, 18 Ekim 2026. Copilot CLI, VS Code’un .vscode/mcp.json dosyasını okumaz. Antigravity CLI’da depodaki dosya .agents/mcp_config.json.

MCP belirtimi bunun ne demek olduğunu tek cümleyle söylüyor: “Tools represent arbitrary code execution and must be treated with appropriate caution.” Belirtimin güvenlik rehberi de istemcilerden, MCP sunucularının istemciyle aynı yetkilerle çalıştığı konusunda kullanıcıyı uyarmasını istiyor. Yani .mcp.json dosyasına eklenen bir satır, ekipteki herkesin makinesinde onların yetkileriyle çalışacak bir programın adıdır.

Tool poisoning nedir?

Model bir aracı ne zaman ve nasıl çağıracağına, aracın adına ve açıklamasına bakarak karar verir. Invariant Labs, 1 Nisan 2025 tarihli yazısında buradaki açığı anlattı: model aracın açıklamasının tamamını okur, kullanıcı ise arayüzde çoğu zaman sadeleştirilmiş bir hâlini görür. Tool poisoning, bu açıklamaya kullanıcının görmediği ama modelin okuduğu talimatlar gizlemektir. Invariant’ın örneği iki sayıyı toplayan bir araç:

Sunucunun kodu kötü bir şey yapmıyor, iki sayıyı topluyor. Kötü işi model yapıyor: açıklamadaki talimata uyup iki dosyayı okuyor ve içeriklerini sidenote argümanıyla sunucuya gönderiyor. Talimat, bunu kullanıcıya söylememesini de istiyor. Invariant bu aracı Cursor’la denedi ve ajanın kullanıcının mcp.json dosyasını sızdırdığını gösterdi. MCP belirtimi de istemcilerden, veri sızmasın diye, sunucuyu çağırmadan önce araç girdilerini kullanıcıya göstermesini istiyor.

Invariant iki şeye daha dikkat çekiyor. Birincisi rug pull: kötü niyetli bir sunucu, istemci onu onayladıktan sonra aracın açıklamasını değiştirebilir. Belirtime göre de bir sunucunun araç listesi zamanla değişebilir. İkincisi önerdikleri önlem: sunucunun ve araçlarının sürümünü sabitlemek.

MCP belirtimi “tool poisoning” adını kullanmıyor, ama soruna aynı yerden bakıyor: araçların davranışını anlatan açıklamalar, güvenilir bir sunucudan gelmedikçe güvenilmez sayılmalı. Microsoft’un güvenlik blogu da aynı şeyi söylüyor: aracın açıklamasındaki bir değişiklik, ajanın davranışını sistem prompt’undaki bir değişiklik kadar etkili biçimde yönlendirebilir.

Bu saldırının ne sıklıkla tuttuğunu ölçen bir çalışma da var. MCPTox, 45 gerçek MCP sunucusunun 353 aracı üzerine 1.348 zehirli test kurdu ve 20 model ayarında denedi. Ortalama saldırı başarısı %36,5; en yüksek oran o1-mini’de %72,8. Saldırıyı en sık reddeden model Claude-3.7-Sonnet’ti ve onda bile ret oranı %3’ün altındaydı. Bunlar makalenin ilk sürümünün yazıldığı 2025 yılının modelleri; bugünün modelleri bu çalışmada ölçülmedi.

OWASP’ın beta aşamasındaki MCP Top 10 listesinde de üçüncü madde (MCP03) Tool Poisoning. Maddenin ayrıntı sayfası, böyle bir açıklamanın kurulumdan önce okunarak fark edilebileceğini söylüyor ve beş işaret sayıyor. Aşağıdaki listede “sunucunun kendi kodu” sorusu bu işaretlerden çıktı.

Ajan bir issue’yu okurken neden yanlış iş yapar?

İkinci yol, sunucunun getirdiği içerikten geçer. Aracın açıklaması temiz olabilir; ama araç bir issue, bir web sayfası ya da bir sohbet mesajı getiriyorsa o metin de modelin bağlamına girer ve içindeki talimat da okunur. Buna dolaylı prompt injection denir.

Invariant Labs’in 26 Mayıs 2025 tarihli örneği bunu GitHub’ın resmî MCP sunucusuyla gösterdi. Saldırgan herkese açık bir depoya bir issue açıyor. Kullanıcı ajanından açık issue’lara bakmasını istediğinde ajan o issue’yu okuyor, kullanıcının özel depolarındaki bilgiyi bağlamına çekiyor ve herkese açık depoda kendi açtığı bir pull request’e yazıyor. Yazarlar bunun GitHub MCP sunucusunun kodundaki bir hata olmadığını, sorunun ajan sisteminin mimarisinde olduğunu yazıyor.

Tehlike tek bir yetenekte değil, yeteneklerin bir arada durmasında: aynı ajan dışarıdan gelen metni okuyabiliyor, özel veriye erişebiliyor ve herkesin göreceği bir yere yazabiliyor. Invariant’ın önerisi, ajanı bir oturumda tek bir depoyla sınırlamak. Her araç çağrısını onaylamak da tek başına yetmiyor; yazarlara göre birçok kullanıcı “Always Allow” seçeneğini açıp işlemleri tek tek izlemeyi bırakıyor. Claude Code’un belgesi de aynı uyarıyı yapıyor: “Servers that fetch external content can expose you to prompt injection risk.”

Aynı yol, ajanın kendi MCP yapılandırmasını yazmasına da çıkabilir. NVD’nin CVE-2025-54135 kaydına göre Cursor 1.3.9 öncesinde, .cursor/mcp.json henüz yoksa, dolaylı prompt injection ajanı bu dosyayı yazmaya yönlendirebiliyor ve kod kullanıcı onayı olmadan çalışabiliyordu. Bugün Claude Code .mcp.json dosyasını korunan dosyalar arasında sayıyor ve bu dosyaya yazmayı, bütün izin sorularını atlayan mod dışında, kendiliğinden onaylamıyor. Cursor da ajanın yapılandırma dosyalarını onaysız değiştirmesine izin vermiyor. Bir ajanın açtığı pull request MCP dosyasına dokunuyorsa, bu değişikliği kimin istediğine bakın.

Sunucunun kendi kodu da bu metne karşı dayanıklı olmalı. MCP belirtimine göre araçları model çağırır; yani araç argümanlarını da model yazar. Modeli okuduğu bir metin yönlendirebiliyorsa, argümanı da o metin belirleyebilir. Referans Git MCP sunucusu (mcp-server-git) için NVD’de yayımlanan kayıtlar, böyle bir kodda aranacak iki hatayı gösteriyor:

Kaynak: NVD kayıtları, 18 Ekim 2026. İlk iki kaydı NVD 17 Aralık 2025’te yayımladı.

Düzeltmeler de neye bakılacağını söylüyor: - ile başlayan argümanı reddetmek, istenen yolu sembolik bağları izleyerek çözmek ve izin verilen klasörün içinde kalıp kalmadığını denetlemek.

Araçlar depodaki MCP sunucusunu ne zaman başlatır?

Depoya giren bir sunucuyu her araç başka bir kapıdan geçiriyor. Aşağıdaki tablo, 18 Ekim 2026 günü her aracın kendi belgesinde okuduklarımız:

Kaynak: her aracın kendi belgesi, 18 Ekim 2026. “Belgede yazmıyor”: o gün okuduğumuz sayfalarda bu durumu anlatan bir cümle bulamadık. Gemini CLI’da klasör güveni kapalıyken depodaki sunuculara ne olduğu da belgede yazmıyor. Cursor’ın 1.3 sürümünden beri her değişiklikte yeniden sorduğunu Check Point yazıyor; Cursor’ın belgesinde bu cümle yok.

Tabloda en sık geçen kelime güven. Çoğu araç depodaki sunucuyu tek tek değil, klasöre ya da çalışma alanına verilen güvenle birlikte açıyor. VS Code’un belgesi bu yüzden bir depoya güvenmeden önce MCP yapılandırmasına bakmanızı söylüyor, çünkü yerel MCP sunucuları makinenizde kod çalıştırabilir.

Güven sorusunun kaç tıkla geçildiği de önemli. Adversa AI, 7 Mayıs 2026 tarihli TrustFall yazısında, test ettiği dört CLI’ın (Claude Code, Gemini CLI, Cursor CLI ve Copilot CLI) klasör güveni onaylandığı anda depoda tanımlı MCP sunucularını çalıştırabildiğini ve dördünde de varsayılan seçeneğin “Evet/Güven” olduğunu yazıyor. Yazıya göre Claude Code 2.1.129 sürümünde bunu sağlayan, depoya commit edilmiş enableAllProjectMcpServers ve enabledMcpjsonServers ayarlarıydı. Claude Code’un bugünkü belgesi, güvenilmeyen bir klasörde depodaki bu ayarların yok sayıldığını söylüyor; klasöre güvendikten sonra ne olduğu belgede yazmıyor.

Google, 18 Haziran 2026’da ücretsiz kullanıcılar ile Google AI Pro ve Ultra aboneleri için Gemini CLI’ın hizmetini durdurup onları Antigravity CLI’a yönlendirdi; ücretli API anahtarıyla ya da şirket lisansıyla Gemini CLI’ı kullanmaya devam edebilirsiniz. Antigravity CLI’ın belgelerini 28 Ekim 2026 günü okuduk. MCP belgesine göre depodaki sunucular .agents/mcp_config.json dosyasında, kullanıcınınkiler ~/.gemini/config/mcp_config.json dosyasında duruyor; pull request’te dikkat edilecek dosya ilki. İzin kurallarınızda geçmeyen bir MCP aracı, varsayılan olarak çağrılmadan önce onay istiyor. CLI, klasöre güvenip güvenmediğinizi de soruyor. Depodaki sunucuların bu onayı bekleyip beklemediği ve yapılandırma değişince yeniden sorup sormadığı belgede yazmıyor.

Onaydan sonra sunucu değişirse ne olur?

Onay bir kez verilir, sunucu ise değişmeye devam eder. Check Point Research’ün MCPoison adını verdiği açık bunun neye yol açabileceğini gösterdi: Cursor güveni sunucunun adına bağlıyor, komutun ya da argümanların değişip değişmediğine bakmıyordu. NVD kaydına göre (CVE-2025-54136) Cursor 1.2.4 ve öncesinde, ortak bir depoya yazabilen biri, ekip arkadaşının bir kez onayladığı zararsız sunucuyu hiçbir uyarı ya da yeni onay sorusu olmadan kötü niyetli bir komutla değiştirebiliyordu.

Check Point açığı 16 Temmuz 2025’te Cursor’a bildirdi, Cursor da 29 Temmuz 2025’te 1.3 sürümüyle düzeltti. Check Point’e göre artık yapılandırmadaki her değişiklik, bir boşluk eklemek bile, yeniden onay istiyor. Cursor’ın kendi belgesinde bu davranışı anlatan bir cümle bulamadık.

Diğer araçların belgeleri bu soruya ya farklı bir yanıt veriyor ya da hiç değinmiyor. VS Code açık: güvendiğiniz bir çalışma alanında .vscode/mcp.json ve kökteki .mcp.json sunucuları ayrı bir MCP onayı istemeden başlayabilir, “including after their configuration changes”. Claude Code’da onay listesi (enabledMcpjsonServers) sunucuların adlarını tutar; aynı ad altında komut değişince yeniden sorup sormadığı belgede yazmıyor. Cursor’ın, Codex’in ve Gemini CLI’ın MCP belgelerinde de bu konuda bir cümle yok.

Karşılaştırmak için: Codex ve Gemini CLI aynı soruyu hook’lar için yanıtlıyor. Codex, depodan gelen bir hook’u çalıştırmadan önce tanımın tam hâlini incelemenizi ve onaylamanızı ister. Gemini CLI, adı ya da komutu değişen bir hook’u yeni ve güvenilmeyen bir hook sayar ve çalıştırmadan önce uyarır. MCP sunucuları için bu iki belgede benzer bir cümle yok.

Sunucunun araçları da çalışırken değişebilir. Sunucu bunu bir bildirimle (list_changed) haber verir; Claude Code etkileşimli oturumda bu bildirim gelince araç listesini yeniden çeker. Değişen açıklamaların kullanıcıya gösterilip gösterilmediği belgede yazmıyor.

Kısacası dizüstünüzdeki onay sunucunun ilk hâlini gördü. Adı aynı kalsa bile sonraki hâlini görebileceğiniz yer, pull request’in diff’i.

CI’da çalışan ajan depodaki MCP sunucusunu yükler mi?

Etkileşimsiz bir koşuda onay verecek kimse yoktur. Claude Code’un belgesi bunu açıkça yazıyor: claude -p koşularında, Agent SDK oturumlarında ve bulut oturumlarında Claude Code onay sorusunu gösteremez ve proje sunucularını sormadan yükler. İzin belgesindeki tablo, hiç güvenilmemiş bir klasördeki claude -p koşusu için .mcp.json sunucularını tek cümleyle anlatıyor: “Connected without asking, approved or not.”

Claude Code’un belgeleri, yazmadığınız bir depoda claude -p çalıştırmadan önce şu yolları gösteriyor:

• --setting-sources user: projenin ayar dosyalarını ve .mcp.json dosyasını hiç okumaz.
• --bare: projeden hook, skill, alt ajan, eklenti ve .mcp.json sunucusu okumaz; projenin env bloğu yine de uygulanır.
• --strict-mcp-config: yalnızca --mcp-config ile verdiğiniz sunucuları kullanır.
• disabledMcpjsonServers: bir sunucuyu adıyla, her izin modunda reddeder.

Diğer araçlar farklı davranıyor. Copilot CLI’ın prompt modu (copilot -p), klasöre zaten güveniliyorsa proje sunucularını kendiliğinden yükler, güvenilmiyorsa atlar. Cursor CLI’da --approve-mcps bayrağı bütün MCP sunucularını otomatik onaylar, --trust da headless modda çalışma alanına sormadan güvenir. Bir iş akışı dosyası bu bayraklardan birini ekliyorsa, onu da bir MCP değişikliği gibi okuyun. Codex’in ve Gemini CLI’ın belgeleri, etkileşimsiz koşuda depodaki sunucuya ne olduğunu yazmıyor.

Pull request’lerde çalışan GitHub eylemi tarafında bir ayrım daha var. claude-code-action’ın güvenlik belgesi, eylemin bir pull request’te çalışırken Claude’un yapılandırma yollarından sabit bir listeyi (8 yol, .mcp.json dahil), Claude başlamadan önce taban daldan geri yüklediğini yazıyor; pull request’in getirdiği sürümler yalnızca başvuru için ayrı bir klasörde durur. Çalışma ağacının geri kalanı pull request’teki hâliyle kalır. Daha alt düzeydeki claude-code-base-action ise bu geri yüklemeyi yapmıyor. Adversa’nın TrustFall yazısı, resmî eylemin varsayılan kullanımında güven sorusunun hiç çıkmadığını ve saldırının pull request dallarına karşı kimse dokunmadan çalıştığını yazmıştı; eylemin bugünkü belgesi yukarıdaki geri yüklemeyi anlatıyor.

GitHub Copilot’un bulut ajanında ise MCP yapılandırması depoda bir dosya değildir; deponun GitHub.com’daki ayarlarına girilir ve Copilot code review de aynı yapılandırmayı kullanır. Bu yüzden pull request’in diff’inde görünmez. Belgeye göre ajan bu araçları onay sormadan kullanır; GitHub bu yüzden yalnızca okuma yapan araçları tek tek izin listesine almayı öneriyor.

OWASP’ın MCP risk listesinde neler var?

OWASP’ın MCP Top 10 listesi, MCP’ye özgü riskleri 10 başlıkta topluyor. Sayfanın kendisi listenin beta aşamasında olduğunu söylüyor. Başlıklar 18 Ekim 2026 günü owasp.org’da şöyle:

Kaynak: owasp.org, 18 Ekim 2026. Projenin GitHub deposu MCP06’yı “Intent Flow Subversion” adıyla veriyor ve bir sonraki sürümü Ekim 2026 olarak gösteriyor; adlar değişebilir.

Listeyi bir standart gibi değil, ortak bir sözlük gibi kullanın: bir bulguya ad koymaya yarar. Aşağıdaki soruların çoğu MCP01, MCP03, MCP04, MCP05 ve MCP06’ya denk geliyor.

MCP dosyasını değiştiren bir pull request’te neye bakmalı?

Buraya kadar anlatılanlar tek bir sonuca çıkıyor: onay ekranı sunucunun ilk hâlini gördü, sonraki her değişikliği ise pull request’te okuyabilirsiniz. Aşağıdaki örnek, bir pull request’in MCP dosyasında değiştirebileceği üç şeyi bir arada gösteriyor:

İlk değişiklik en kolay gözden kaçanı: docs adı aynı kaldı ama artık başka bir program çalışıyor, üstelik bu program depodaki bir betik. O betik de bu pull request’le ya da sonrakilerle değişebilir; sunucunun ne yaptığı artık o dosyanın incelenmesine bağlı. İkinci sunucu ise her başlatmada paketin o günkü sürümünü indirecek ve ortamdaki bir token’ı alacak.

Böyle bir diff’te sırayla şu sorulara bakın:

• Komut, argümanlar ve adres. MCP’nin güvenlik rehberi, tek tıkla sunucu kuran istemcilerden çalışacak komutu argümanlarıyla birlikte, kısaltmadan göstermesini istiyor. Pull request’te bu satırlar zaten önünüzde; komut depodaki bir betiği çalıştırıyorsa o betiği de okuyun. Uzak bir sunucuda adresin kime ait olduğuna ve https kullanıp kullanmadığına bakın. Rehber, kötü niyetli bir sunucunun verdiği OAuth adresinin istemcide kod çalıştırmaya kadar gidebileceğini de ayrıca anlatıyor.
• Sürüm. @latest ya da sürümsüz bir paket adı, her başlatmada başka kod getirebilir. Invariant’ın önerisi sunucunun ve araçlarının sürümünü sabitlemek; OWASP’ın listesinde de tedarik zinciri ayrı bir madde (MCP04).
• Aynı adla değişen sunucu. MCPoison bu satırdan çıktı. Onay bir isme bağlıysa, isim aynı kaldıkça yeni komut eski onayın arkasında durabilir. Böyle bir değişikliği yeni bir sunucu gibi okuyun.
• Pull request’le gelen onaylar. Claude Code, enableAllProjectMcpServers ve enabledMcpjsonServers ayarlarını siz onay verdiğinizde .claude/settings.local.json dosyasına yazar; bunlar kişisel bir seçimin kaydıdır. Paylaşılan .claude/settings.json dosyasında görünmeleri, bir kişinin onayının herkese dağıtılması demektir. Gemini CLI’da "trust": true o sunucunun bütün onaylarını atlar ve belge bunu yalnızca tamamen sizin denetiminizdeki sunucular için öneriyor; proje dosyasına yazıldığında geçerli olup olmadığı belgede yazmıyor.
• Sırlar. env ve headers alanlarına hangi değişkenin girdiğine ve o token’ın neye erişebildiğine bakın. Claude Code ve Cursor, anahtarı dosyaya yazmak yerine ortam değişkeninden okumayı destekliyor; bu sırrı dosyadan çıkarır, ama sunucuya gitmesini engellemez. Gemini CLI ana ortamdaki hassas değişkenleri sunucuya göndermez, ama env alanına açıkça yazılan bir değişkeni kullanıcının bilgilendirilmiş onayı sayar ve maskelemez. O satırı pull request’te okuyan kişi, bu onayı veren kişidir.
• Yardımcı komutlar. Claude Code headersHelper’ı “arbitrary shell command” olarak çalıştırır; Codex’te http_headers_helper da yerel bir komuttur. Bunları sunucunun kendisi gibi okuyun.
• Dışarıdan metin okuyan araçlar. Issue, web sayfası ya da sohbet okuyan bir sunucu, özel veriye erişen bir sunucunun yanına ekleniyorsa ikisine birlikte bakın. GitHub örneği bu ikilinin sonucuydu.
• Sunucunun kendi kodu. Kod pull request’teyse, - ile başlayan argümanlara ve depo dışına çıkan yollara bakın (yukarıdaki Git MCP kayıtları). Araçların açıklamalarında OWASP MCP03’ün saydığı işaretleri arayın: modele yönelik emir cümleleri, ~/.ssh ya da .env gibi gizli dosya yolları, bir adrese “gönder” diyen cümleler, sıfır genişlikli karakterler ve HTML yorumlarına gizlenmiş talimatlar.
• CI. İş akışı ajanı pull request’in dalında, proje ayarları yüklü olarak mı çalıştırıyor? Claude Code’da --setting-sources user ya da --strict-mcp-config, Cursor CLI’da --approve-mcps bayrağının olup olmadığına bakın.

Bu soruları bir kural dosyasına yazmak tek başına yetmez; değişiklik ancak incelemede okunur. Aynı inceleme .claude/settings.json dosyasındaki hook’lar için de geçerli; hook yazısında onlara ayrıca baktık. Claude Code’un güvenlik belgesinin hatırlattığı gibi, .mcp.json dosyasını okumak bir oturumun yükleyebileceği her sunucuyu göstermez: kullanıcı ayarlarından ve eklentilerden gelen sunucular da vardır.

Kod inceleme botu da bu sorunun dışında değil: o da pull request’in yazarının yazdığı metni okuyan bir modeldir. diffox’ta bir bulgunun “yazar bunu bilerek yaptı” gerekçesiyle düşürülüp düşürülmeyeceğine bakan adımda, pull request açıklaması etiketler arasına alınır ve modele bunun bir talimat değil veri olduğu söylenir; açıklamanın içine yazılmış bir etiket de etkisiz hâle getirilir. Her incelemede çalışan Security Agent, injection’ı, bozuk kimlik doğrulama ve yetkilendirmeyi, sızan sırları, SSRF’i ve güvensiz deserialization ya da dosya yolu işlemeyi arar (diffox’un nasıl çalıştığını ayrı bir yazıda anlattık).

Sıkça sorulan sorular

MCP tool poisoning nedir?

Tool poisoning, bir MCP aracının açıklamasına kullanıcının görmediği ama modelin okuduğu talimatlar gizlemektir. Invariant Labs’in örneğinde iki sayıyı toplayan bir aracın açıklaması, modelden kullanıcının SSH anahtarını okuyup bir argümanla sunucuya göndermesini ve bunu kullanıcıya söylememesini istiyor. OWASP MCP Top 10’da üçüncü madde (MCP03). Açıklama okunarak fark edilebilir: modele yönelik emir cümleleri, gizli dosya yolları ve görünmeyen karakterler en bilinen işaretler.

OWASP MCP Top 10 nedir, son sürümü hangisi?

OWASP’ın MCP’ye özgü 10 riski topladığı liste. 18 Ekim 2026 itibarıyla owasp.org’daki liste beta aşamasında ve maddeleri “MCP01:2025” biçiminde numaralanıyor; Token Mismanagement & Secret Exposure’dan Context Injection & Over-Sharing’e kadar uzanıyor. Projenin GitHub deposu bir sonraki sürümü Ekim 2026 olarak gösteriyor ve bir maddenin adı sitedekinden farklı. Bir maddeye atıf yaparken tarihini de yazın.

.mcp.json dosyası depoya commit edilmeli mi?

Claude Code’un belgesi, ekipteki herkes aynı araçları kullansın diye bunu öneriyor. Commit ettiğinizde dosya kodun bir parçası olur ve kod gibi incelenmelidir: komut, sürüm, ortam değişkenleri ve onay ayarları. Kişisel onaylar (enabledMcpjsonServers gibi) ise Claude Code’un kendisinin de yazdığı .claude/settings.local.json dosyasında kalmalı.

Claude Code depodaki MCP sunucularını sormadan çalıştırır mı?

Etkileşimli oturumda hayır: .mcp.json dosyasındaki her sunucu için ayrı onay ister ve güvenilmeyen bir klasörde depoya commit edilmiş onay ayarlarını yok sayar. claude -p koşularında, Agent SDK oturumlarında ve bulut oturumlarında ise onay sorusunu gösteremediği için proje sunucularını sormadan yükler. Bunu önlemek için --setting-sources user, --bare, --strict-mcp-config ya da disabledMcpjsonServers kullanılabilir.

CI’da kodlama ajanı çalıştırırken depodaki MCP sunucuları nasıl kapatılır?

Claude Code’da --setting-sources user proje ayarlarını ve .mcp.json dosyasını hiç okumaz; --strict-mcp-config yalnızca sizin verdiğiniz sunucuları kullanır. claude-code-action pull request’lerde .mcp.json dosyasını taban daldan geri yükler. Copilot CLI’ın -p modu güvenilmeyen klasörde proje sunucularını atlar. Cursor CLI’da --approve-mcps bütün sunucuları onaylar; bu bayrağı pull request’in dalında çalışan bir işte kullanmayın. Codex’in ve Gemini CLI’ın belgeleri bu durumu anlatmıyor.

Yapay zekâ kod inceleme aracı MCP değişikliğini yakalar mı?

Araca göre değişir. diffox pull request’in diff’ini okur ve Security Agent her incelemede çalışır: injection’ı, bozuk kimlik doğrulama ve yetkilendirmeyi, sızan sırları, SSRF’i ve güvensiz deserialization ya da dosya yolu işlemeyi arar. MCP’ye özel ayrı bir kuralı yok; bu yazıdaki soruları incelemeyi yapan kişi sorar. Bir kod inceleme aracı seçerken, pull request açıklamasını nasıl okuduğunu da sorun: diffox’ta bir bulgunun bilerek yapılmış olup olmadığına bakan adım, açıklamayı talimat olarak değil veri olarak okur.