AI Kod Asistanları Secret'lara Nasıl Erişir ve Nasıl Sınırlandırılır?

Kod asistanları yalnızca yazdığınız prompt'u görmez. Dosya arama, terminal komutu, hata ayıklama, repository taraması veya MCP tool çağrısı için verdiğiniz izinler; çalışma alanındaki daha geniş bir bağlama erişebilir. Risk, aracın adı değil hangi veriye, hangi yetkiyle ve hangi çıkış kanalından eriştiğidir.

Bu rehber, Cursor, Claude Code, Copilot veya benzeri bir araç için geçerli olan koruma modelini anlatır. Sağlayıcıların veri saklama ve eğitim politikaları planlara, ayarlara ve sözleşmelere göre değişir; güvenlik kararı bu politikalara dair varsayıma değil, ölçülebilir teknik sınırlara dayanmalıdır.

Secret'ın Ajan Bağlamına Girdiği Dört Yol

Yol	Tipik örnek	Kontrol
Dosya erişimi	.env, SSH anahtarı, cloud config, üretim dump'ı	Workspace'i küçültün; secret dizinlerini bağlam dışına alın.
Terminal ve environment	Ajanın başlattığı komutun environment değişkenlerini devralması	Ayrı, kısa ömürlü servis kimliği ve allowlist kullanın.
Tool/MCP erişimi	Git, ticket, cloud veya veritabanı tool'u	Tool başına en az yetki, onay ve ayrıntılı audit log uygulayın.
CI/CD ve repository	Commit, PR, build logu veya artifact	Push protection, secret scanning ve branch koruması ekleyin.

Bir ajanın .env dosyasını okuması, her durumda dışarı sızdırdığı anlamına gelmez. Ancak secret belleğe, prompt bağlamına, komut çıktısına veya tool çağrısına girdiyse etki alanı büyür. Bu yüzden amaç, "ajan doğru davranır" varsayımı değil, secret'ın yanlış bağlama hiç girmemesidir.

Güvenli Varsayılanlar

1. Secret'ı dosyadan ayırın

Geliştirme konfigürasyonu ile credential'ı aynı dosyada tutmak pratik görünür; ancak kod asistanına açılan her proje için risk alanını genişletir. Mümkün olduğunda secret manager, yerel credential store veya kısa ömürlü kimlik bilgisi kullanın. OWASP da secret'ların kaynak koda veya düz metin konfigürasyona gömülmemesini önerir. OWASP Secrets Management Cheat Sheet

.env kullanımı zorunluysa:

• Gerçek üretim credential'ını yerel geliştirme dosyasına koymayın.
• Örnek değerler için .env.example kullanın; gerçek değerleri ayrı ve erişimi kısıtlı yerde tutun.
• Ajanın açık olduğu workspace'e yalnızca gerekli proje klasörünü açın.
• Secret içeren klasörleri indeksleme, dosya arama ve tool erişiminden hariç tutun; bu ayarın çalıştığını kontrollü bir test dosyasıyla doğrulayın.

2. Ajanı ayrı bir kimlik olarak yönetin

Kod asistanı, geliştiricinin kişisel token'ı veya geniş cloud yetkisiyle çalışmamalıdır. Okuma, test çalıştırma ve deploy gibi işlevleri ayırın. Yüksek etkili eylemler—production'a yazma, secret okuma, dış servise veri gönderme, git push—insan onayı gerektirmelidir.

İyi bir başlangıç matrisi şöyledir:

Eylem	Varsayılan	İstisna koşulu
Kaynak kodu okuma	İzinli	Secret ve müşteri verisi dizinleri hariç
Test çalıştırma	İzinli	İzole environment ve sınırlı network
Git commit/PR	Onaylı	Branch policy ve secret scanning sonrası
Cloud, ödeme, production tool'u	Engelli	Ayrı servis kimliği + yazılı onay

3. Çıkış kanallarını görünür kılın

Bir agent'ın yaptığı network isteği, eklediği dosya veya çağırdığı tool denetlenemiyorsa güvenlik ekibi yalnızca sonuca bakar. Proxy/DLP, egress allowlist, IDE telemetry ve tool audit loglarını aynı olay kimliği altında ilişkilendirin. Agent tool permission modeli için ajan yetki rehberine bakın.

4. Secret sızıntısını CI/CD'de durdurun

Yerel çalışma alanı kusursuz korunamaz. Bu nedenle son güvenlik katmanı repository ve pipeline'dır:

• Pull request ve push aşamasında secret scanning çalıştırın.
• Tespit edilen değeri yalnızca maskelemeyin; revoke/rotate akışını başlatın.
• CI logları, build artifact'ları ve container layer'ları için retention ve erişim politikasını tanımlayın.
• Uzun ömürlü deploy token'ları yerine OIDC veya kısa ömürlü credential kullanın.

30 Dakikalık Ekip Kontrolü

1. En çok kullanılan iki kod asistanı ve etkin MCP/tool entegrasyonunu envantere alın.
2. Her araç için açılan klasörleri, terminal yetkisini ve dış network erişimini kaydedin.
3. Production secret içeren en az bir klasörü workspace dışına taşıyın veya erişimden hariç tutun.
4. Test bir credential ile dosya, terminal çıktısı ve PR diff'i üzerinden sızıntı senaryosu çalıştırın.
5. Tespit edilirse kimin revoke/rotate yapacağını ve hangi logların inceleneceğini belirleyin.

Knostic'in yayımladığı araştırma, .env dosyaları ve agent izinlerinin dikkatle ele alınması gerektiğine dair yararlı bir örnektir; ancak burada anlatılan ürün davranışları zamanla değişebilir ve kendi ortamınızda doğrulanmalıdır. Araştırmayı inceleyin.

Olay Olduysa

Bir secret'ın ajanın bağlamına, commit'e veya harici bir tool'a girdiğinden şüpheleniyorsanız önce secret'ı geçersiz kılın, sonra erişim kayıtlarını inceleyin. Commit'i silmek tek başına yeterli değildir. Ayrıntılı sıralama için Git history'deki secret sızıntısı olay müdahalesi rehberini izleyin.

Kod asistanlarını yasaklamak yerine, veri erişimini ve yetkiyi tasarlayın. Gerçek müşteri verisi, üretim erişimi veya otonom tool çağrıları varsa bu sınırları AI security assessment ile test etmek gerekir.