Claude Code Güvenlik Rehberi: İzinler, MCP, Sandboxing

Geleneksel sohbet botları bir API arkasında yapılandırılır, bu yüzden yapabilecekleri en kötü şey halüsinasyon üretmektir. Ancak bir yapay zekâ kodlama ajanı, deposunuzun, terminalinizin ve (çoğu zaman) bulut kimlik bilgilerinizin içine yerleştirilir; bu da onu geçmişte “sohbet botu” dediğimiz her şeyden çok daha ayrıcalıklı geliştirici ortamlarına yaklaştırır.

Soru şu: Claude Code’u kendinizi yavaşlatmadan nasıl güvenle kullanırsınız? Doğru ayarlamalarla izinler, MCP kontrolleri ve sandboxing sizi oraya götürecektir.

Bu yazıda, Claude Code’un güvenlik modelinin gerçekte nasıl çalıştığını, nerelere dikkat etmeniz gerektiğini ve onu amaçladığınızdan daha fazla erişim vermeden kullanışlı tutan uygulamaları anlatacağım.

Claude ve Claude Code’a tamamen yeniyseniz, bir öğleden sonra içinde temelleri almak için ücretsiz Claude Code 101 kursuna kaydolun.

Claude Code'un Güvenlik Modelini Anlamak

Tek bir kuralı ayarlamadan önce, Claude Code’un gerçekte neyi kontrol ettiğine dair zihinsel bir modeliniz olmalı.

Beş hareketli parça vardır: neyin izinli olduğuna karar veren bir izin sistemi, tekil yetenekleri kapsamlayan araç erişim kontrolleri, harici entegrasyonlar için MCP izinleri, işletim sistemi düzeyinde yalıtım için sandboxing ve sonradan inceleme için denetlenebilirlik. Her biri farklı bir sorunu çözer, ancak üst üste binerler.

İzin sistemi

İzin sistemi statik katmandır.

settings.json içinde üç liste kullanarak Claude’un ne yapabileceğini bildirirsiniz: allow, ask ve deny. Kurallar önce deny, sonra ask, ardından allow olarak değerlendirilir ve ilk eşleşme kazanır. Bir deny kuralı, daha geniş bir allow kuralı onu kapsasa bile çağrıyı engeller.

Herhangi bir kural eşleşmezse, Claude oturumun defaultMode değerine geri döner (modlar hakkında bir sonraki bölümde daha fazla bilgi).

Araç erişim kontrolleri

İzinler araca bağlanır, ajanın tamamına değil.

Claude Code’un kendi yerleşik araç seti vardır; örneğin kabuk komutları için Bash, dosya sistemi işlemleri için Read, Edit ve Write, HTTPS istekleri için WebFetch, sorgular için WebSearch ve birkaç tane daha. Her kural bir araç ve isteğe bağlı olarak parantez içinde bir belirteç adı verir; Bash(git commit:*) veya Read(./.env) gibi.

Asgari ayrıcalık ilkesini işe yaratan budur. Claude’a tam kabuk erişimi vermeden testler için Bash(npm run:*) izni verebilirsiniz.

MCP izinleri

MCP sunucuları, Claude Code’u tasarlanmadığı araçlarla genişletir.

Her sunucu kendi araç setini getirir (bir GitHub sunucusu çekme isteği araçları, bir veritabanı sunucusu sorgu araçları vb.). İzin sistemi onları da kapsar, ancak farklı bir sözdizimiyle - kurallar parantezli belirteç yerine mcp__servername__toolname biçimini kullanır.

Unutmamanız gereken nokta, MCP’nin soruyu kabaca ikiye katladığıdır; çünkü artık yalnızca Claude’un kabuğunuzla ne yapabileceğine değil, ona bağladığınız her harici sistemle ne yapabileceğine de karar veriyorsunuz.

Sandboxing

Sandboxing, Bash aracının altındaki işletim sistemi düzeyindeki güvenliktir.

İzin kuralları Claude’a ne yapması gerektiğini söyler. Sandboxing ise dosya sistemi erişimini ve giden ağ çağrılarını işletim sistemi düzeyinde kısıtlayarak ne yapabileceğini uygular. macOS’te Seatbelt ile kutudan çıkar çıkmaz çalışır. Linux ve WSL2’de önce bubblewrap ve socat kurmanız gerekir.

Bu iki katman benzer şekilde çalışır ama farklı senaryoları kapsar. İzinler Claude’un bir şeyi denemesini engeller; bir istem enjeksiyonu Claude’u yine de denemeye ikna ederse, sandboxing girişimin başarılı olmasını engeller.

Denetlenebilirlik

Son parça ise ne olduğunun görülebilmesidir.

/permissions komutu etkin tüm kuralları ve her birinin geldiği ayar dosyasını listeler; böylece “Claude bunu neden çalıştırdı?” sorusunu yanıtlayabilirsiniz. Kancalar (PreToolUse, PostToolUse ve diğerleri) her araç çağrısını kendi sisteminize kaydetmenize olanak tanır. Ekipler için OpenTelemetry dışa aktarıcıları kullanım ve araç çağrısı verilerini zaten çalıştırdığınız gözlemlenebilirlik yığınına gönderir.

Claude Code İzinleri ve Erişim Kontrolü

Güvenliğin çoğu izin ayarlarından gelir, bu yüzden en çok ayar yapacağınız alan burasıdır.

Dosya erişimi

Claude varsayılan olarak, başlattığınız dizindeki dosyaları okuyabilir ve düzenleyebilir.

Okuma Read aracıyla, düzenleme ise Edit ve Write ile kontrol edilir. Her biri parantez içinde bir yol deseni kabul eder; gitignore tarzı söz dizimi kullanır. Örneğin Read(**/.env) herhangi bir derinlikteki tüm .env dosyalarını, Edit(src/**) ise src/ altındaki her şeyi eşleştirir.

Read üzerindeki bir deny, Claude Code’un kendi dosya araçlarını (Read, Grep, Glob, LS) kapsar ancak bu sadece azami gayret yaklaşımıdır. Bash üzerinden çalıştırılan bir Python veya Node betiği dosyayı yine de açabilir; çünkü o okuma Claude’un Read aracı yerine kabuk üzerinden gerçekleşir. Bir sır gerçekten önemliyse, Read deny kuralını, bu yollar için cat, head ve tail üzerinde Bash deny kurallarıyla birleştirin.

Çalışma dizininin ötesine erişimi genişletmek için settings.json içinde additionalDirectories kullanın. Bu, Claude’a deponuzun dışında paylaşılan bir kütüphaneye veya ev dizininizdeki bir yapılandırma dosyasına erişim vermenin, çalışma dizini sınırını tamamen kaldırmadan yoludur.

Komut çalıştırma

Bash aracı en dikkatli kapsamlandırmanız gereken araçtır.

Salt Bash kuralı tüm komutlara izin verir. Bash(npm run:*) gibi kapsamlandırılmış bir kural yalnızca eşleşen çağrılara izin verir. Burada kullanmanız gereken desen iki nokta ve yıldızdır; ayrıca Claude Code kabuk operatörlerini anlar, bu nedenle Bash(safe-cmd:*) kuralı safe-cmd && rm -rf / ifadesiyle eşleşmez.

Bazı komutlar her modda istem olmadan çalışır; çünkü varsayılan olarak salt-okunur kabul edilirler. Liste şunları kapsar: ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd ve git’in salt-okunur biçimleri. Bu listeyi elle küçültemezsiniz, ancak varsayılanı geçersiz kılmak için herhangi biri için bir ask veya deny kuralı ekleyebilirsiniz.

Önceden onaylı olmayan her şey için Claude varsayılan modda onay ister. İstemde tam komutu görür ve onu bir kez onaylayabilir, bir deseni eşleyen tüm gelecekteki çağrıları onaylayabilir veya reddedebilirsiniz.

İzin modları

İzin kuralları statiktir, ancak izin modları eşleşmeyen çağrıların davranışını değiştirir.

Beş tane vardır:

• default: her aracın ilk kullanımında onay ister.

• acceptEdits: çalışma dizinindeki dosya düzenlemelerini otomatik onaylar, kabuk komutlarını ise kontrol etmeye devam eder. Düzenlemelere güvenip kabuğa güvenmediğinizde kullanışlıdır.

• plan: Claude okur ve analiz eder, ancak dosya düzenleyemez veya komut çalıştıramaz. Kod incelemesi veya planlama oturumları için doğru moddur.

• dontAsk: açıkça allow listesinde olmayan her şeyi otomatik reddeder.

• bypassPermissions: tüm istemleri atlar. Yalnızca bir konteyner veya VM gibi tamamen yalıtılmış ortamlarda güvenlidir.

Oturum ortasında Shift+Tab ile üç ana mod arasında geçiş yapabilir veya settings.json içinde varsayılan olarak birini seçebilirsiniz:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": ["Read(**/.env)", "Read(**/.env.*)"]
  }
}

Ekipler için yönetilen ayarlar, kullanıcının geçersiz kıramayacağı bir katman sağlar. Dosya aynı JSON biçimini izler ve bir sistem yolunda bulunur:

• /Library/Application Support/ClaudeCode/managed-settings.json macOS’te

• /etc/claude-code/managed-settings.json Linux’ta

• C:\ProgramData\ClaudeCode\managed-settings.json Windows’ta

Yönetilen ayarlardaki deny kuralları makinedeki her projede geçerlidir; bu da bir kuruluş genelinde “kimse .env dosyalarını okumaz” veya “kimse bypassPermissions çalıştırmaz” gibi kuralları uygulamanın yoludur.

Tüm bunların arkasındaki ilke, herhangi bir hizmet hesabına uygulayacağınız en az ayrıcalık ilkesidir. 

Çalışmayı mümkün kılan en küçük izin kümesiyle başlamalı ve yalnızca duvara tosladığınızda genişletmelisiniz. Anthropic’in kendi rehberliği de aynı yöne işaret eder - Claude’un yaptığı değişiklikleri gözden geçirin, kurallarınızı /permissions ile denetleyin ve proje özelindeki ayarları sürüm kontrolüne alın ki ekip Claude’un ne üzerinde çalışabileceği konusunda uzlaşsın.

Claude Code Sandboxing

Claude’a özerk olarak çalışması için ne kadar çok izin verirseniz, sandboxing o kadar anlamlı hale gelir.

Bash aracı en geniş maruziyete sahiptir; çünkü kabuk komutları sizin okuyabildiğiniz her dosyayı okuyabilir ve yazma izinleri olan her şeyi değiştirebilir. Sandboxing, her Bash komutu ve alt süreçleri üzerinde işletim sistemi düzeyinde sınırlar zorlar; böylece Claude sizden her çağrı için onay almadan bu sınır içinde daha serbest çalışabilir. Anthropic, özellikle daha güvenli özerk çalıştırmaları desteklemek için bunu yerleşik hale getirdi.

Bilmeniz gereken bir ayrıntı, sandbox’ın yalnızca Bash ve onun alt süreçlerini kapsadığıdır. Read, Edit veya Write araçlarını kısıtlamaz ve bunlar hâlâ izin sisteminden geçer.

Yerel sandboxing

Yerel sandbox Claude Code’a yerleşiktir ve /sandbox ile açılır.

macOS’te sandboxing yerleşik Seatbelt çerçevesini kullanır ve kurulacak bir şey yoktur. Linux ve WSL2’de dosya sistemi yalıtımı için bubblewrap, ağ vekili için socat kurarsınız. Yerel Windows desteklenmez; bunun yerine Claude Code’u bir WSL2 dağıtımında çalıştırırsınız.

Dosya sistemi sınırı anlaşılması kolaydır. Okumalar, reddedilen yollar haricinde her yerde çalışır; yazmalar ise yalnızca çalışma dizininde ve izin verdiğiniz ek yollar içinde çalışır. Sandbox içinden ~/.bashrc’ye yazmaya çalışırsanız, Claude başarısız olduğunu fark etmeden önce “Operation not permitted” alırsınız.

Ağ sınırı biraz farklıdır. Giden trafik, sandbox dışında çalışan ve her isteği allowedDomains listenize karşı kontrol eden bir vekil sunucu üzerinden yönlendirilir. Yeni alan adları bunun yerine bir izin istemini tetikler; böylece Claude’un tam olarak neye erişmeye çalıştığını görürsünüz.

Çalışan bir yapılandırma şöyle görünür:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "filesystem": {
      "allowWrite": ["/workspace", "/tmp"],
      "denyRead": ["~/.aws", "~/.ssh"]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

Anthropic’in dahili kullanımında sandboxing, izin istemlerini %84 azaltır.

Geliştirme konteynerleri

Geliştirme konteynerleri yalıtımda bir üst adımdır.

Anthropic’in, Claude Code için bir Ubuntu ortamı kuran, deponuzu bağlayan ve ajana çalışacağı bir kabuk veren başvuru bir devcontainer’ı vardır. Yerel sandboxing’e kıyasla avantajı, herkesin aynı araçlar ve kurulumla aynı ortamı alması nedeniyle tekrarlanabilirliktir.

Ancak dezavantajı ek yüküdür. 

Konteyner kullanırken konteyner derlemesi, dosya bağlama ve (bazen) daha yavaş geri bildirim döngüsü eklenir. Tek bir geliştirici için yerel sandbox genellikle yeterlidir. Ekip veya CI kullanımı için bu kurulum değerlidir.

Docker tabanlı yalıtım

Uzun süreli özerk ajan oturumları için Docker, sandbox sınırını daha da artırabilir.

Kurulum genellikle şöyle görünür:

• Minimal temel imaj: görevin ihtiyaç duymadığı paket yöneticilerini ve ağ araçlarını kaldırın.
• Root olmayan kullanıcı: Claude asla root olarak çalışmaz; bu nedenle sistem dosyalarını değiştiremez veya küresel paketler kuramaz.
• Salt-okunur kök dosya sistemi: konteyner kökünü salt-okunur bağlayın, yalnızca belirli çıkış dizinlerini yazılabilir yapın.
• Çıkış (egress) vekili: giden ağı, paket kayıt defterine (npm, PyPI) izin veren ve diğer her şeyi reddeden bir vekil üzerinden yönlendirin; böylece npm install gibi komutlar çalışır ancak rastgele bir curl komutu çalışmaz.
• Kaynak sınırları: bir sürecin ana makineyi çökertememesi için CPU, bellek ve G/Ç sınırlarını ayarlayın.

Docker Sandboxes, her sandbox’a özel bir Docker daemon’ına sahip kendi microVM’ini verir. Ana daemon, docker ps içinde sandbox’ları bile göremez. Sınır, bir konteynerden ziyade bir VM’e daha yakındır; bu da geliştiricilerin endişelendiği konteynerden kaçış yollarının çoğunu kapatır.

Kurumsal sandboxing stratejileri

Kuruluşlar için soru, sandbox tekniklerinin kullanılıp kullanılmayacağı değil, nasıl katmanlandırılacağıdır.

Genellikle şöyle yaklaşırlar:

• İzin kuralları managed-settings.json içine konur ve bireysel geliştiriciler tarafından geçersiz kılınamaz.

• Yerel sandboxing, izin katmanının altında çalışır.

• Dev konteynerleri veya Docker onun da altında çalışır.

• En yüksek güven senaryolarında (prod erişimi, sır yönetimi) ana makine dosya sistemi bağlaması olmayan özel bir VM son katmandır.

Web üzerindeki Claude Code aynı fikrin yönetilen bir sürümüdür. Her oturum Anthropic tarafından yönetilen bir VM’de çalışır, git belirteçleri gibi hassas kimlik bilgileri sandbox dışında bir vekile yerleştirilir ve sınır altyapı tarafından uygulanır.

Claude Code’da MCP Güvenliği

MCP, Claude Code’un en hızlı büyüyen parçasıdır.

Bağladığınız her MCP sunucusu, Claude’un yapabileceklerini kabaca katlar; ancak bir istem enjeksiyonu veya tehlikeye atılmış bir bağımlılığın erişebileceği yüzeyi de katlar. 

Örneğin:

• Bir GitHub MCP sunucusu Claude’a çekme isteği erişimi verir.
• Bir veritabanı MCP sunucusu şemanızı ve sorgularınızı verir.
• Bir Slack sunucusu kanallarınızı verir.

Bunların hiçbiri başlı başına sorun değildir; ancak MCP’nin kendi yönetişimini gerektirdiği anlamına gelir. Bir MCP aracı üzerinden getirilen içerik (bir web sayfası veya API yanıtı), Claude’un sanki siz yazmışsınız gibi uygulayacağı enjekte edilmiş talimatlar içerebilir. Ayrıca her sunucu ayrı ayrı yönetilmesi gereken bir kimlik bilgisi ve kimlik doğrulama yolu ekler.

Araç izinleri

MCP araçları, yerleşik araçlardan farklı bir adlandırma kuralı kullanır.

Kural biçimi, parantezli belirteç olmadan mcp__servername__toolname şeklindedir. Örneğin mcp__github__create_pull_request Claude’un tam olarak bu aracı çağırmasına izin verir ve mcp__github__delete_repo üzerindeki bir deny tehlikeli olanı engeller. Allow, ask ve deny listeleri Bash veya Read için olduğu gibi aynı şekilde çalışır.

Aynı öncelik kuralları da geçerlidir - önce deny, sonra ask, ardından allow. mcp__github__delete_* üzerinde yönetilen ayarlarda bir deny, makinedeki her projede geçerlidir.

Kaynak izinleri

MCP sunucuları, araçlarla birlikte kaynaklar da sunabilir.

Kaynak, sunucunun Claude’un okuması için kullanılabilir kıldığı bir veri parçasıdır (bir proje yönetimi sunucusundaki dosya veya bir veritabanı sunucusundaki satır gibi). Kaynak erişimi, araç çağrılarıyla aynı güven kontrolünden geçer ve bir MCP sunucusuna ilk bağlantı, araçlarından veya kaynaklarından herhangi birine erişilmeden önce bir güven doğrulama adımı çalıştırır.

Doğru varsayılan, kaynakları başka bir araç gibi ele almaktır. Kimlik bilgisini vermeyecekseniz, kaynak erişimini de vermeyin.

Onaylı MCP sunucuları

Anthropic Directory, Anthropic’in listeleme kriterlerine göre incelediği bağlayıcıları listeler.

Kuruluşlar için iyi bir model, dahili bir allowlist kullanmaktır. Size kontrol sağlayan iki ayar vardır:

• allowedMcpServers: geliştiricilerin projelerine ekleyebileceği sunucuların bir glob deseni (örneğin yalnızca dahili olarak bakımı yapılan sunuculara izin vermek için company-*).

• deniedMcpServers: geliştirici denese bile eklenemeyecek sunucuların bir deseni.

Her oturumda bulunması zorunlu sunucular için, yönetilen ayarlarda bulunan bir managed-mcp.json dosyasıyla bunları dağıtmak en iyi yoldur. Geliştiriciler girdileri kaldıramaz veya değiştiremez.

Paylaşılan depolarda kaçınılması gereken bir ayar, enableAllProjectMcpServers’tır; bu, .mcp.json’da tanımlanan her MCP sunucusunu otomatik onaylar. Bu, bireysel çalışma için kullanışlı ama sürüme alınan herhangi bir şey için tehlikelidir; çünkü kötü niyetli bir PR, .mcp.json’a yeni bir sunucu ekleyip istem olmadan çalıştırabilir.

Asgari ayrıcalıkla araç erişimi

Aynı ilke, Bash izinlerine uygulandığı gibi MCP’ye de uygulanır.

Başlangıç sorusu, her sunucunun hangi kimlik bilgisine sahip olduğudur. Bir veritabanı MCP sunucusu, yazma haklarına sahip birincile değil, salt-okunur erişimli bir okuma replikasına bağlanmalıdır. Bir API MCP sunucusu, tam kuruluş erişimine sahip kişisel bir belirteç değil, gerekli en küçük uç nokta kümesine kapsamlandırılmış bir belirteç kullanmalıdır. Ve benzeri.

Alt ajanlar, MCP erişimini kapsamlandırmanın başka bir yoludur. .claude/agents/ içindeki bir alt ajan tanımı, tam olarak hangi araçlara erişimi olduğunu (mcp:<server>:<tool> sözdizimini kullanarak) bildirebilir; böylece bir “deploy-agent” altyapı sunucusunu alır ve bir “review-agent” yalnızca Read, Grep ve Glob alır. Ajan, kendisine verilmemiş araçları çağıramaz.

MCP yönetişimi

Claude Code’u ölçekli olarak çalıştıran bir ekip veya kuruluş için MCP, diğer tüm üretim entegrasyonlarıyla aynı yönetişim yapısına ihtiyaç duyar.

Bu, onaylı sunucuların sahipleriyle birlikte bir sicili, araç çağrılarının uçtan uca denetim izlerini (hangi MCP araçları kim tarafından hangi parametrelerle çağrıldı) ve onay listesinin periyodik bir gözden geçirilmesini ifade eder. Claude Code’daki OpenTelemetry dışa aktarıcıları, zaten çalıştırdığınız gözlemlenebilirlik yığınına kolayca düşen bir biçimde denetim verilerini sağlar.

Daha büyük kuruluşlar için merkezi bir MCP geçidi bunun en temiz sürümüdür. 

Geliştiriciler, bireysel sunucuları kaydetmek yerine geçide bağlanır. Geçit kimlik doğrulamayı yönetir, araç düzeyinde rol tabanlı erişimi uygular ve tek bir denetim izi üretir. Aynı zamanda kimlik bilgisi saçılmasını çözer; çünkü geçitteki tek bir kimlik bilgisi kümesi, her geliştiricinin her API anahtarının bir kopyasına sahip olmasının yerini alır.

Gizli Yönetimi ve Hassas Veriler

Claude Code sizin okuyabildiğiniz her şeyi okuyabilir; bu da sırların erişilebilir olduğu anlamına gelir.

Varsayılan olarak Claude Code, kullanıcı hesabınızın okuyabildiği her dosyayı okuyabilir. Buna projenizdeki .env dosyaları, ~/.aws/ içindeki AWS kimlik bilgileri, ~/.ssh/ içindeki SSH özel anahtarları, kabuk rc dosyanızdaki GitHub belirteçleri ve Claude’un oluşturduğu herhangi bir alt süreçteki ortam değişkenleri dahildir. Bu tamamen normaldir ve tasarımdandır.

Sırları çalışma alanının dışında tutun

İlk hamle, sırların Claude’un okuduğu dizinde olmadığından emin olmaktır.

.env dosyaları en yaygın olanlardır. Proje kökündedirler, her geliştirme aracı tarafından yüklenirler ve tam da Claude bağlamında istemediğiniz değerleri içerirler (veritabanı URL’leri ve API anahtarları). 

Kullanabileceğiniz birkaç desen şunlardır:

• Sırları çalışma ağacının dışındaki bir dizine taşıyın; örneğin ~/.config/myapp/secrets.env ve bunları harici dosyayı işaret eden bir ortam yöneticisi veya direnv kurulumu aracılığıyla yükleyin.

• Konteynerleştirilmiş çalışmalarda dosyanın konteyner içinden görünmemesi için bağlama dışında bir .secrets/ klasörü tutun.

• permissions.deny listenize Read(**/.env) ve Read(**/.env.*) ekleyin ve Read aracının okuyamadığını kabuk betiği de okuyamasın diye bunları Bash(cat:*/.env) deny kurallarıyla eşleştirin.

Bir sır yöneticisi kullanın

Tanıtım projelerinin ötesindeki her şey için sırların yeri bir sır yöneticisidir.

Model, satıcıdan bağımsız olarak aynıdır (1Password, AWS Secrets Manager, HashiCorp Vault, Doppler, Infisical). Sırlar yöneticiye konur. Kabuk veya çalışma zamanı bunları talep üzerine alır ve yalnızca ihtiyaç duyan sürece açığa çıkarır. Claude gerçek değeri asla görmez.

Özellikle Claude Code için bu, Anthropic ve bulut sağlayıcı kimlik bilgilerini alt süreçlerden çıkarmak için CLAUDE_CODE_SUBPROCESS_ENV_SCRUB ayarını yapmak veya sandbox’lı komutlar için belirli değişkenleri kaldırmak üzere sandbox.credentials kullanmak anlamına gelir. İlki, Claude’un ANTHROPIC_API_KEY’inizi bir derleme betiğine aktarmasını durdurur; ikincisi ise hassas herhangi bir ortam değişkeninin bir kabuk komutuna sızması gibi daha geniş durumu kapsar.

Depo erişimini kısıtlayın

Üçüncü seçenek depo düzeyindedir.

Bir geliştiricinin yalnızca üretime özel yapılandırmaya yazma erişimi gerekmiyorsa, onun Claude Code oturumunun da gerekmiyor. Bu kulağa bariz gelse de çoğu ekipte varsayılan, geliştiricilerin rutin kullanımından daha geniş erişime sahip olmasıdır ve Claude tümünü devralır.

Şu iki adımı atabilirsiniz:

• Üretim yapılandırmasını daha sıkı erişimli ayrı bir depoya bölün; böylece Claude’un çalıştığı geliştirme ortamında üretim sırları en baştan bulunmaz.

• Claude’un etkileşime girdiği her hizmet için kapsamlandırılmış belirteçler kullanın. Örneğin, kod inceleme işi için bir GitHub belirteci repo:delete gerektirmez.

Ekipler için Claude Code Güvenliği

Tek bir geliştirici settings.json’ı istediği gibi değiştirebilir. Bir ekip ise bunu yapamaz; çünkü genel güvenlik, en zayıf makinedeki en zayıf yapılandırma kadar iyidir. Ekip ve kuruluş dağıtımlarında Claude Code, bir yöneticinin uyguladığı ve bireysel kullanıcıların geçersiz kıramadığı ayrı bir kontrol katmanına sahiptir.

Yönetilen ayarlar

Yönetilen ayarlar temeldir.

Dosya, yazmak için yönetici erişimi gerektiren bir sistem yolunda bulunur:

• /Library/Application Support/ClaudeCode/managed-settings.json macOS’te

• /etc/claude-code/managed-settings.json Linux’ta

• C:\ProgramData\ClaudeCode\managed-settings.json Windows’ta

Bu dosyadaki ayarlar, kullanıcı ve proje düzeyi ayarların önüne geçer. Buraya konulan bir deny kuralı, makinedeki her projede deny kuralıdır ve geliştirici kendi settings.json’ını düzenleyerek bunu kaldıramaz. Çoğu kuruluş dosyayı MDM (Mobil Cihaz Yönetimi) veya diğer geliştirme araçları için kullandığı aynı yapılandırma kanalıyla dağıtır.

Yönetilen katmanda bilmeye değer bazı ayarlar şunlardır:

• permissions.deny kuralları hassas yollar ve tehlikeli komutlar için

• defaultMode’un default veya plan olarak ayarlanması (asla bypassPermissions değil)

• allowManagedPermissionRulesOnly: true ile izin setini kilitleme

• enableAllProjectMcpServers: false ile açık MCP onayı gerektirme

• Günlükleme için OpenTelemetry dışa aktarıcı yapılandırması

Paylaşılan izin politikaları

Claude’un ne yapabileceği konusunda uzlaşan bir ekip, bu uzlaşmayı sürüm kontrolüne almalıdır.

Proje düzeyi ayarlar, depo kökündeki .claude/settings.json içinde bulunur. Buraya alınan her şey, o depoda Claude’u çalıştıran herkes için geçerlidir. Dosya, proje özelindeki allow ve deny’lar için doğru yerdir.

Bunu akılda tutarak, bilmeniz gereken yönetilen ve proje ayarları arasında bir ayrım vardır:

• Yönetilen ayarlar, organizasyon politikasını içerir (kimse bypassPermissions çalıştırmaz, kimse .env okumaz).

• Proje ayarları, iş akışı geleneklerini içerir (bu deponun testleri npm test; ile çalışır; bu deponun dağıtım betiği yasaktır).

Ekip yönetişimi

Bir ekip dağıtımı için politika katmanının bir sahibi olmalıdır.

Claude Code’u ölçekli çalıştıran çoğu ekip, yönetilen ayarların, MCP allowlist’inin, kanca betiklerinin ve OpenTelemetry hattının sahibi olan küçük bir grupla (genellikle güvenlik ve platform mühendisliği) sonuçlanır. Aynı grup istisna taleplerini gözden geçirir ve yeni kullanım senaryoları ortaya çıktıkça politikayı ayarlar.

Şu parçaların yazılı olmasını hedeflemelisiniz:

• Hangi depolar kapsam içinde, hangileri dışında ve risk katmanlı modlar (düzenlemeye tabi verilerle ilgilenen bir depo muhtemelen Claude’u plan modunda çalıştırır; bir pazarlama sitesi deposu ise acceptEdits çalıştırabilir).
• Kim istisna verebilir ve bunlar nasıl izlenir.
• Ekip izin kurallarını, MCP sunucularını ve olay verilerini yeniden gözden geçirdiği bir inceleme kadansı (çeyreklik yaygındır).

Denetim günlüğü

Claude Code, her araç kararı, MCP sunucu bağlantısı, izin modu değişimi ve API isteği için OpenTelemetry olayları yayar. Yönetilen ayarlarda OTLP uç noktası yapılandırılana kadar hiçbir veri akmaz.

Telemetri için asgari bir yönetilen ayar bloğu şöyledir:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.internal:4317"
  }
}

Varsayılan olarak, istem içeriği ve araç parametreleri dışa aktarmaya dahil edilmez; bu nedenle topladığınız olaylar tam konuşma değil, üst veridir. İstem metnini dahil etmek için OTEL_LOG_USER_PROMPTS=1 ayarlarsınız. Araç argümanlarını (denetim için genellikle istediğiniz budur) dahil etmek için OTEL_LOG_TOOL_DETAILS=1 ayarlarsınız. Her iki kararın da gizlilik sonuçları vardır; bu yüzden çoğu ekip bunları kasıtlı politika tercihleri olarak ele alır ve telemetri arka uçlarını depolamadan önce filtreleyecek veya maskeleyecek şekilde yapılandırır.

Kullanım izleme

Denetimin arkasındaki aynı OpenTelemetry akışı, kullanım izlemesinin de arkasındadır.

Claude Code, belirteç kullanımı, istek başına maliyet, oturum sayıları ve araç kararı oranları için metrikler dışa aktarır. Birleştirildiğinde, hangi ekiplerin en fazla değeri elde ettiğini, hangi iş akışlarının en çok reddetme ürettiğini ve hangi modellerin maliyeti artırdığını görmenizi sağlar. Datadog, Honeycomb, SigNoz, Elastic ve Splunk gibi arka uçlar standart OTLP biçimini alır.

decision=deny olan permission_decision olaylarında bir artış, Claude’un çok fazla denediği anlamına gelebilir; ancak ekibin allow kurallarının fazla sıkı olduğu anlamına da gelebilir.

Yaygın Claude Code Güvenlik Hataları

Az sayıda yanlış yapılandırma, çoğu Claude Code olayında karşımıza çıkar. Şimdi bunların neler olduğunu ve ne yapmanız gerektiğini göstereceğim.

Aşırı geniş izinler

İzin sistemini etkisizleştirmenin en hızlı yolu, çok fazla şeye izin vermektir.

Komut başına istemler sürtünme ekler ve kolay çözüm geniş bir Bash(*) allow veya defaultMode: bypassPermissions ayarıdır. Bunların her ikisi de izin sisteminin yaptığı işin çoğunu geri alır.

Allow kurallarını gerçekten kullandığınız belirli araç ve komutlara kapsamlandırmalı (örneğin Bash(npm test:*) ve Bash(git status)) ve geri kalan her şeyi bir isteme bırakmalısınız. Başta daha fazla istem alırsınız; ancak birkaç oturum içinde kullandığınız komutları allow listesine almış olursunuz ve istemler çoğunlukla biter.

Kısıtlanmamış MCP erişimi

İkinci hata, MCP sunucularını hangi kimlik bilgilerini kullandıklarını veya neye erişebildiklerini kontrol etmeden bağlamaktır.

Bu genelde birinin enableAllProjectMcpServers’ı etkinleştirmesi, genel MCP dizininden birkaç sunucu bağlaması ve bunları bir daha gözden geçirmemesi nedeniyle olur. Zayıf bir kimlik bilgisine sahip bir sunucu hassas bir şeyi sızdırdığında, bağlantı yapılandırmanın yeterince gerisinde kalmıştır ve kimse onu onayladığını hatırlamaz.

Çözüm, izinlerdekiyle aynıdır. allowedMcpServers aracılığıyla açık bir allowlist kullanın, herkesin ihtiyaç duyduğu sunucular için dahili bir managed-mcp.json oluşturun ve liste üzerinde bir gözden geçirme kadansı belirleyin.

Sandboxing yok

Sandboxing kapalıysa, Claude ile dosya sisteminiz arasında yalnızca izin sistemi vardır.

Bu, her komutu zaten onayladığınız kısa etkileşimli oturumlar için uygundur. Özerk çalıştırmalar, allow kurallarını genişlettiğiniz oturumlar veya harici kaynaklardan gelen kodlara dokunan işler için uygun değildir.

/sandbox bunu açar. Bağımlılıklar kurulu değilse, menü platformunuz için hangilerini kuracağınızı gösterir. Açıldıktan sonra izin istemleri azalır ve işletim sistemi allow kurallarınızın kapsamadığı durumları yakalar.

Değişiklikleri körlemesine kabul etmek

acceptEdits hem kullanışlı hem de tehlikelidir.

Claude bir fonksiyonu yeniden yazarken ve siz onu izlerken, otomatik kabul iyidir. Claude bir saat boyunca 30 dosya üzerinde yineleme yaparken, difflere bakmayı bırakıp ajana güvenmeye başlama eğilimindesiniz. Sorunlar burada ortaya çıkabilir.

Şu iki alışkanlığı edinmelisiniz:

• Claude’un özerk çalışmasına izin vermeden önce her zaman commit atın; böylece geri dönüş yolu bir git reset kadar uzaktır.

• Toplu diff yerine, Claude tarafından yazılmış her commit’ten önce diff’i inceleyin.

Denetim izlerini görmezden gelmek

Telemetri olmadan Claude Code çalıştıran bir ekip, “bunu hangi oturum yaptı?” sorusuna yanıt veremez. Olaylar her makinede yerel olarak birikir ve orada kalır. Bir denetim izi gereksiniminin ilk ortaya çıktığı an, bir tane yapılandırmadığınızı keşfetmek için en kötü zamandır.

Minimum faydalı temel, tool_decision, permission_decision ve api_request olaylarını ekibin zaten çalıştırdığı gözlemlenebilirlik yığınına dışa aktarmaktır. Buradan itibaren, kullanım senaryoları ortaya çıktıkça panolar ve uyarılar oluşturursunuz.

Sonuç

Bir sohbet botu için en kötü senaryo, kötü bir yanıttır. Ancak bir kodlama ajanı için, kimlik bilgilerinizle üretime karşı çalışan bir kabuk komutudur.

İşte bu yüzden üç sütun önemlidir:

• İzinler, Claude’un ne yapmasına izin verildiğine karar verir
• MCP kontrolleri, hangi harici sistemlere erişebileceğine karar verir
• Sandboxing, ilk ikisinin yeterli olmadığı durumlarda ne olduğuna karar verir

Her biri, diğerlerinin kapsamadığı bir hata modunu kapsar. Birlikte, Claude’un içinde çalıştığı gerçek sınırı tanımlarlar.

Jeneratif yapay zekâda sertifika almak istiyorsanız, 2026'nın En İyi Jeneratif Yapay Zekâ Sertifikaları için karşılaştırmalar, en iyi kurslar, hazırlık ipuçları ve SSS’ler burada.