3 dk

Yapay Zeka ile Oluşturulan Uygulamalarda Güvenlik: Garantiler, Kör Noktalar, Koruyucular

Q: What security guarantees can I realistically claim for an AI-built app?

Herhangi bir “garanti”yi kapsamlı olarak ele alın. Sorun: - Hangi veri yolları kapsanıyor (promtlar, dosyalar, loglar, embeddings, yedekler)? - Gerçeğe dönüşmesi için hangi konfigürasyonların etkin olması gerekiyor? - Saklama süresi yazılı olarak ne kadar? - Paylaşılan sorumluluk dağılımı (satıcı vs. siz) nasıl? Eğer bunu ölçemiyorsanız (loglar, politikalar, belgelenmiş sınırlar), bu bir garanti değildir.

Q: How do I create a lightweight threat model for AI-assisted development?

Hızlı bir geçiş yapın: 1. Aktörleri listeleyin (geliştiriciler, ajanlar, kullanıcılar, saldırganlar, satıcılar). 2. Varlıkları yazın (PII, gizli anahtarlar, kod, promptlar, loglar, model çıktıları). 3. Giriş noktalarını sıralayın (chat/UI, API’ler, webhook’lar, yüklemeler, entegrasyonlar). 4. “Girdi saldırgan kontrollü olsaydı ne olurdu?” sorusunu özellikle araç kullanımı için sorun. 5. O özellik için rollback/kill switch kararınızı verin. Bu, değişiklikler hâlâ ucuzken en yüksek riskli varsayımları ortaya çıkarır.

Q: What are the most common security issues in LLM-generated code?

Sıradan, egzotik olmayan hatalar yaygındır: - Nesne düzeyinde yetkilendirme eksikliği (IDOR) ve tenant kapsamı sorunları. - İstemci tarafından gönderilen alanlara güvenme (ör. ) yerine sunucu tarafı kontrolleri olmaması. - Zayıf giriş doğrulaması ve tehlikeli sorgu yapıları. - Kriptografi hataları (özgün şifreleme, yanlış modlar, sabit anahtarlar). Mitigasyon: güvenli şablonlar, güvenlikle ilgili kod için zorunlu insan incelemesi ve otomatik kontroller (SAST/DAST + hedeflenmiş yetki testleri).

Q: How do I reduce dependency and supply-chain risk in an AI-built app?

Başlangıçta uygulaması kolay kontrolere odaklanın: - Sürüm sabitleme için lockfile kullanın. - Her PR’de ve düzenli aralıkla bağımlılık taraması yapın (SCA). - Olay sırasında “ne çalıştırıyoruz?” sorusunu cevaplayabilmek için bir SBOM oluşturun. - Mümkünse doğrulanmış/ imzalanmış artefaktları tercih edin (imajlar, CI eylemleri, yayıncılar). Ayrıca bir yama temposu belirleyin (ör. bağımlılıklar için haftalık, kritik CVE’ler için aynı gün) ve her servis için isimlendirilmiş bir sahibi atayın.

Q: What is prompt injection, and how do I prevent tool misuse?

Prompt enjeksiyonu, güvenilmeyen içeriğin modeli yönlendirmesi dir. Modelin araçları (DB sorguları, e-posta, iadeler, dağıtımlar) kullanabildiği durumlarda tehlikeli olur. Pratik savunmalar: - En az ayrıcalıklı araç izinleri. - Serbest forma izin vermek yerine izinli, parametreli işlemler kullanın (ör. yerine rastgele SQL). - Araç çağrısını çalıştırmadan önce doğrulayın (onaylı domainler, maksimum tutarlar, güvenli sorgu şablonları). - Geri dönüşü olmayan veya yüksek etkili eylemler için insan onayı şartı koyun.

Q: Where do privacy leaks happen in LLM apps besides the prompt itself?

En büyük sızıntılar genellikle dolaylı olanlardır: - Sohbet geçmişi/belleği süresiz saklanması, - Ham promptları/araç çıktısını yakalayan uygulama logları ve hata izleri, - İstek gövdelerini kaydeden APM/tracing, - Metin alanlarını kaydeden analiz/oturum tekrar oynatma araçları, - Silme isteklerinde unutulan embeddings/vector store’lar. Maruziyeti azaltmak için veri minimize edin, logging öncesi agresif redaksiyon yapın, sıkı erişim kontrolleri uygulayın ve her sistem için belgelenmiş saklama süreleri belirleyin (mümkünse yedekleri de dahil ederek).

Q: What’s the safest way to implement tenant isolation in a multi-tenant app?

İzolasyonu sunucu tarafında uygulayın: - Her sorgu ile sınırlandırılmalı. - kimlik doğrulama oturumundan alınmalı, isteğin gövdesinden değil. - Okuma/güncelleme/silme işlemlerinde nesne düzeyinde sahiplik kontrolleri ekleyin. IDOR testi yapın: bir kullanıcı tahmini ID’lerle başka bir tenant’ın kaydına erişememelidir.

Q: How should we handle secrets when using copilots and agents?

Üç kuralı uygulayın: - Gizli anahtarları promptlara, kaynak koda veya tarayıcıya koymayın. - Bir secrets manager kullanın ve çalışma zamanında enjekte edin. - Kısa ömürlü kimlik bilgilerini tercih edin (dönebilen tokenler) ve hızlı iptal yolu sağlayın. Operasyonel olarak, gizli anahtarlara erişimi denetleyin (audit trail), düzenli döngüde döndürün ve olası sızıntıda hemen iptal/döndürme yapın.

Q: What monitoring and incident readiness do we need before shipping?

Üretimde “işe yarayan” sinyallerin asgari seti: - Kimlik olayları, yetkilendirme kararları, araç çağrıları ve veri erişimi için aranabilir bir denetim izi (gerekirse hassas alanlar redakte edilmiş). - Ani artışlar için uyarılar: toplu okuma/dışa aktarmalar, tekrar eden reddedilme olayları, alışılmadık araç kullanımı, ayrıcalık değişiklikleri. - Bir runbook: riskli araçları devre dışı bırakma, anahtar döndürme, oturumları iptal etme, sürümü geri alma. “Kim ne yaptı, hangi araçla, hangi veriye?” sorusuna hızlı cevap veremiyorsanız olay müdahalesi yavaş ve tahmine dayalı olacaktır.

AI destekli uygulamalarda hangi güvenlik vaatlerinin gerçekçi olduğu, hangi kör noktaların bulunduğu ve daha güvenli sürümler göndermek için uygulanabilir koruyucular hakkında pratik rehber.

Bu Yazı Neyi Kapsar (Ne Kapsamaz)

“Yapay zeka ile oluşturulan uygulama” birkaç şeyi ifade edebilir; bu yazıda terim geniş tutuluyor. Şunları kapsar:

Kodun önemli bölümlerinin bir LLM tarafından (prompt, spesifikasyon veya ticket üzerinden) üretildiği uygulamalar
Kod yazmayı, refactor etmeyi ve hataları düzeltmeyi hızlandırmak için copilot’lar kullanan ekipler
Araç çalıştırabilen ajan tarzı iş akışları (PR oluşturma, API çağırma, veri tabanı sorgulama, dağıtım)
Kullanıcı deneyiminin bir parçası olarak sohbet, özetleme, öneri gibi yapay zeka özellikleri sunan ürünler

Amaç basit: mükemmel güvenlik vaadinde bulunmadan riski azaltmak. Yapay zeka geliştirme ve karar vermeyi hızlandırır, fakat aynı zamanda hataların nasıl oluştuğunu ve ne kadar hızlı yayılabileceğini değiştirir.

Kimler için

Bu yazı, tam zamanlı bir güvenlik fonksiyonu olmayan—veya güvenlik desteği olsa da gönderim (shipping) gerçeğine uyan pratik rehbere ihtiyaç duyan—kurucu, ürün lideri ve mühendislik ekipleri için yazıldı.

Bu yazıdan ne elde edeceksiniz

Hangi “güvenlik garantilerini” gerçekçi olarak iddia edebileceğinizi (ve hangilerinden kaçınmanız gerektiğini), AI destekli geliştirmeye uygulayabileceğiniz hafif bir tehdit modelini ve LLM’lerin kod, bağımlılıklar, araçlar ve verilerle etkileştiğinde ortaya çıkan en yaygın kör noktaları öğreneceksiniz.

Ayrıca sıkıcı ama etkili koruyucuları göreceksiniz: kimlik ve erişim kontrolleri, tenant izolasyonu, gizli bilgiler yönetimi, güvenli dağıtım iş akışları ve erken tespit sağlayan izleme ile kötüye kullanım kontrolleri.

Bu yazı ne yapmaz

Bu bir uyumluluk rehberi, güvenlik incelemesinin yerine geçen bir döküman veya herhangi bir uygulamayı sihirli şekilde güvenli hale getiren bir kontrol listesi değildir. Güvenlik; insanlar (eğitim ve sahiplik), süreç (incelemeler ve sürüm kapıları) ve araçlar (tarayıcılar, politikalar, loglar) arasında paylaşılan bir meseledir. Amaç bu paylaşımı açık ve yönetilebilir kılmaktır.

Güvenlik Garantileri: Gerçekçi Beklentiler

AI ile oluşturulan uygulamalar etrafındaki “garantiler” genellikle açıkça belirtilmez, ima edilir. Ekipler “model sır saklamaz” ya da “platform uyumlu” gibi ifadeler duyduğunda bunları kapsamlı vaatlere çevirirler. Beklentilerin gerçeklikten sapması burada başlar.

İnsanların varsaydığı yaygın garantiler

Sıklıkla şu tür varsayımlar görülür:

Varsayılan olarak güvenli: üretilen kod otomatik olarak en iyi uygulamaları takip eder.
Koda gizli bilgi girmez: anahtarlar/tokenler promptlarda, çıktılarda veya repolarda asla görünmez.
Uyumlu: “SOC 2 / ISO / HIPAA-ready” ifadesi uygulamanızın uyumlu olduğu anlamına gelir.
Veri gizlidir: promptlar ve yüklenen dosyalar asla saklanmaz veya yeniden kullanılmaz.
Araç kullanımı güvenlidir: ajan tehlikeli komut çalıştırmaz veya yanlış tenant’a erişmez.

Bunların bazıları kısmen doğru olabilir—ama nadiren evrenseldir.

Garantilerin neden hep sınırlı olduğuna dair

Gerçek garantilerin sınırları vardır: hangi özellikler, hangi konfigürasyonlar, hangi ortamlar, hangi veri yolları ve ne kadar süre için geçerli olduğu gibi. Örneğin “verileriniz üzerinde eğitim yapmıyoruz” ifadesi “veriyi saklamıyoruz”dan farklıdır; her ikisi de “yöneticileriniz onu kazayla açamaz” iddiasından farklıdır. Benzer şekilde “varsayılan olarak güvenli” starter şablonlar için geçerli olabilir, ancak birkaç yinelemeden sonra üretilen her kod yolu için geçerli olmayabilir.

Faydalı bir zihinsel model: eğer bir garanti sizin doğru toggleyi açmanıza, belirli bir şekilde dağıtım yapmanıza veya belirli bir entegrasyonu kullanmaktan kaçınmanıza bağlıysa, bu kapsamlı bir garanti değil—koşullu bir garantidir.

Güvenlik özellikleri vs. güvenlik çıktıları

Özellik: disk üzerinde şifreleme, SSO, denetim logları, gizli tarama.
Çıktı: “müşteri verileri tenantlar arasında erişilebilir değil”, “gizli bilgiler açığa çıkmadı”, “RCE önlendi”.

Satıcılar özellik sunabilir; çıktıların sağlanması hâlâ sizin tehdit modelinize, konfigürasyonunuza ve operasyonel disiplininize bağlıdır.

Basit bir kural

Eğer ölçülemiyorsa, garanti değildir.

Doğrulayabileceğiniz şeyleri isteyin: yazılı saklama süreleri, belgelenmiş izolasyon sınırları, denetim log kapsamı, penetrasyon testi kapsamı ve net bir sorumluluk ayrımı (satıcı neyi güvenli tutar, siz neyi güvenli tutarsınız).

Eğer Koder.ai gibi sohbet tabanlı uygulama üretim platformu kullanıyorsanız, aynı merceği uygulayın: “biz sizin için üretiyoruz” ifadesini hızlandırma olarak görün, güvenlik iddiası olarak değil. Sorgulanması gereken: hangi parçalar standartlaştırılmış ve tekrarlanabilir (şablonlar, dağıtım hatları, geri alma), ve hangi parçalar hâlâ sizin kontrollerinizi gerektiriyor (authZ, tenant scoping, gizli bilgiler, inceleme kapıları).

AI ile Oluşturulan Uygulamalar için Basit Bir Tehdit Modeli

Daha iyi kararlar almak için 40 sayfalık belgeye gerek yok. Hafif bir tehdit modeli basitçe paylaşılan bir haritadır: kim uygulamayla etkileşir, neyi koruyorsunuz ve işler nasıl ters gidebilir—özellikle kod ve iş akışları kısmen AI tarafından üretildiğinde.

1) Aktörleri belirleyin (kim sonuçları etkileyebilir)

Değişiklik yapabilen veya tetikleyebilen tarafları listeleyin:

Geliştiriciler: kod yazma, entegrasyon bağlama, AI tarafından önerilen değişiklikleri onaylama.
AI araçları/ajanlar: kod üretme, araçları çağırma, dosyaları okuma, konfigürasyonları düzenleme.
Son kullanıcılar: normal kullanım, uç durum girdileri, hesap kurtarma akışları.
Saldırganlar: dış aktörler, ele geçirilmiş hesaplar, kötü niyetli içeriden kişiler.
Üçüncü taraf hizmetler: ödeme, e-posta, analiz, depolama, kimlik sağlayıcıları.

Bu, konuşmayı temellendirir: “Hangi aktör ne yapabilir ve hangi izinlerle?”

2) Temel varlıkları eşleyin (korumanız gerekenler)

Açıldığında zarar verecek küçük seti seçin:

Müşteri verisi (PII, dosyalar, mesajlar)
Kimlik bilgileri ve sırlar (API anahtarları, tokenler, imzalama anahtarları)
Kaynak kodu ve altyapı konfigürasyonları
Promptlar ve sistem talimatları (sıklıkla iş mantığı içerir)
Loglar ve izler (hassas girdileri/çıktıları kazara saklayabilir)
Model çıktıları (veri sızdırabilir veya eylem tetikleyebilir)

3) Tipik giriş noktalarını tanımlayın (riskin girdiği yerler)

Girdinin bir sınırı geçtiği yerleri listeleyin:

UI formları ve sohbet arayüzleri
Açık ve dahili API’ler
Webhook’lar (çoğu zaman fazla güvenilir kabul edilir)
Dosya yüklemeleri (dokümanlar, resimler, CSV’ler)
Entegrasyonlar (CRM’ler, ticketing, drive’lar, veri tabanları)

4) Tekrar kullanılabilir tehdit-model kontrol listesi (10 dakika)

Her yeni özellik için bu hızlı geçişi kullanın:

Hangi aktörler dokunuyor ve en kötü kullanım ne olur?
Hangi varlıklar dahil ve nerede saklanıyor veya önbelleğe alınıyor?
Giriş noktaları nereler ve hangi doğrulama yapılıyor?
AI aracı/ajanın hangi izinleri var, tam olarak?
Bir saldırgan girdiyi ele geçirirse ne olur (promptlar/dosyalar dahil)?
Hangi loglar üretiliyor ve hassas veri içeriyor mu?
Bir şey ters giderse geri alma planı nedir?

Bu, tam bir güvenlik incelemesinin yerini almaz—ama en yüksek olasılıklı, en yüksek etkili varsayımları erken ve ucuzken ortaya çıkarır.

Kör Nokta #1: Üretilen Kod Kalitesi ve Güvensiz Varsayılanlar

Practice Incident Readiness

Deploy and host your app, then validate logging, alerts, and rollback paths in staging.

Deploy Now

AI çok miktarda çalışan kod taslağı oluşturabilir—ama “çalışıyor” olmak “güvenli” olmakla eş anlamlı değildir. AI ile oluşturulan uygulamalardaki birçok güvenlik hatası egzotik değildir; modelin inandırıcılık ve hız için optimize etmesi, organizasyonunuzun güvenlik standartları için optimize etmemesi sonucu ortaya çıkan sıradan hatalardır.

Üretilen kod nerede yanlış yapıyor

Kimlik doğrulama ve yetkilendirme sık hata noktalarıdır. Üretilen kod şunları yapabilir:

“Giriş yapılmış” olmayı “izinli” olmakla eş tutup rol kontrollerini veya nesne düzeyi izinleri atlayabilir.
isAdmin: true gibi istemci tarafından sağlanan alanlara güvenebilir; yerine sunucu tarafı kontrolleri olmalıdır.
Tenant scoping’i unutabilir; böylece kullanıcı bir ID değiştirerek başka bir müşterinin kayıtlarına erişebilir.

Girdi doğrulama başka bir sık tekrar eden hatadır. Kod mutlu yolunu doğruluyor olabilir ama uç durumları kaçırabilir (dizi yerine string, Unicode oyunları, çok büyük girdiler) veya SQL/NoSQL sorgularına string birleştirme yapabilir. ORM kullansa bile dinamik filtreler güvensiz olabilir.

Kripto yanlış kullanımı şu şekilde ortaya çıkar:

İyi test edilmiş kütüphaneler yerine özel şifreleme yöntemleri yazma.
Eski algoritmalar, sabit IV/nonce kullanımı veya hash’leri “şifreleme” gibi gösterme.
Gizli bilgileri konfigürasyon dosyalarına, loglara veya ön uç paketlerine koyma.

Kopyala-yapıştır riski ve güncelliğini yitirmiş parçalar

Modeller sık sık kamu örneklerine benzeyen kalıpları tekrarlar. Bu, aldığınız kodun:

Eski olması (bilinen güvensiz varsayılanlara sahip framework sürümleri).
Bağlam, lisans veya güvenlik sertifikası olmadan bilinmeyen kaynaklardan stil olarak kopyalanmış olması.
Üretimde güvenli yapmak için gereken “sıkıcı” parçaları (rate limiting, CSRF koruması, güvenli header’lar) içermemesi anlamına gelir.

Gerçek riskleri gerçekten azaltan koruyucular

Önce güvenli şablonlar ile başlayın: kimlik, logging, hata yönetimi ve güvenli varsayılanlarla önceden onaylanmış proje iskeletleri. Ardından tüm güvenlik açısından kritik değişiklikler için insan incelemesi şartı getirin—auth akışları, izin kontrolleri, veri erişim katmanları ve sırlarla ilgili her şey.

Mükemmel insanlara güvenmek yerine otomatik kontroller ekleyin:

CI’da linter’lar ve bağımlılık denetimleri.
Yaygın güvensiz kalıplar (enjeksiyon, güvensiz deserializasyon, gömülü gizli bilgiler) için SAST.
Statik araçların kaçırdıklarını yakalamak için çalışan bir yapı üzerinde DAST veya API taraması.

Koder.ai ile uygulamalar oluşturuyorsanız (React ön yüzleri, Go arka uç, PostgreSQL), şablonları sözleşmeniz olarak değerlendirin: deny-by-default authZ, tenant scoping, güvenli header’lar ve yapılandırılmış logging’i bir kez yerleştirin, sonra AI’in bu sınırlar içinde çalışmasına izin verin. Ayrıca platform özelliklerini (ör. snapshots ve rollback) operasyonel riski azaltmak için kullanın—ama rollback’i önlemeyle karıştırmayın.

Önemli testler (ve sürekli önem taşıyanlar)

Güvenlik regresyonları çoğunlukla “küçük refactor” olarak gelir. Birkaç yüksek etkili testi yerleştirin:

Her rol ve hassas uç nokta için yetkilendirme testleri (nesne düzeyinde erişim dahil).
Kötü niyetli payload’lar ve sınır durumlarıyla giriş doğrulama testleri.
Her merge’de çalışan küçük bir güvenlik regresyon paketi—böylece model destekli bir değişiklik dünkü korumayı sessizce geri almaz.

SSS

What security guarantees can I realistically claim for an AI-built app?

Herhangi bir “garanti”yi kapsamlı olarak ele alın. Sorun:

Hangi veri yolları kapsanıyor (promtlar, dosyalar, loglar, embeddings, yedekler)?
Gerçeğe dönüşmesi için hangi konfigürasyonların etkin olması gerekiyor?
Saklama süresi yazılı olarak ne kadar?
Paylaşılan sorumluluk dağılımı (satıcı vs. siz) nasıl?

Eğer bunu ölçemiyorsanız (loglar, politikalar, belgelenmiş sınırlar), bu bir garanti değildir.

What’s the difference between security features and security outcomes?

Güvenlik özellikleri (SSO, şifreleme, denetim logları, gizli tarama) yeteneklerdir. Sonuçlar ise pratikte vaat edebileceğiniz durumlardır (çapraz-tenant erişimi yok, gizli bilgi sızmıyor, yetkisiz dışa aktarım yok gibi).

Sadece şu durumda sonuç elde edersiniz:

özellikler doğru yapılandırıldığında,
ilgili sistemlere (loglar ve araçlar dahil) uygulandığında ve
sürekli olarak sürdürülüp sapma/regresyon izleme yapıldığında.

How do I create a lightweight threat model for AI-assisted development?

Hızlı bir geçiş yapın:

Aktörleri listeleyin (geliştiriciler, ajanlar, kullanıcılar, saldırganlar, satıcılar).
Varlıkları yazın (PII, gizli anahtarlar, kod, promptlar, loglar, model çıktıları).
Giriş noktalarını sıralayın (chat/UI, API’ler, webhook’lar, yüklemeler, entegrasyonlar).
“Girdi saldırgan kontrollü olsaydı ne olurdu?” sorusunu özellikle araç kullanımı için sorun.
O özellik için rollback/kill switch kararınızı verin.

Bu, değişiklikler hâlâ ucuzken en yüksek riskli varsayımları ortaya çıkarır.

What are the most common security issues in LLM-generated code?

Sıradan, egzotik olmayan hatalar yaygındır:

Nesne düzeyinde yetkilendirme eksikliği (IDOR) ve tenant kapsamı sorunları.
İstemci tarafından gönderilen alanlara güvenme (ör. isAdmin) yerine sunucu tarafı kontrolleri olmaması.
Zayıf giriş doğrulaması ve tehlikeli sorgu yapıları.
Kriptografi hataları (özgün şifreleme, yanlış modlar, sabit anahtarlar).

Mitigasyon: güvenli şablonlar, güvenlikle ilgili kod için zorunlu insan incelemesi ve otomatik kontroller (SAST/DAST + hedeflenmiş yetki testleri).

How do I reduce dependency and supply-chain risk in an AI-built app?

Başlangıçta uygulaması kolay kontrolere odaklanın:

Sürüm sabitleme için lockfile kullanın.
Her PR’de ve düzenli aralıkla bağımlılık taraması yapın (SCA).
Olay sırasında “ne çalıştırıyoruz?” sorusunu cevaplayabilmek için bir SBOM oluşturun.
Mümkünse doğrulanmış/ imzalanmış artefaktları tercih edin (imajlar, CI eylemleri, yayıncılar).

Ayrıca bir yama temposu belirleyin (ör. bağımlılıklar için haftalık, kritik CVE’ler için aynı gün) ve her servis için isimlendirilmiş bir sahibi atayın.

What is prompt injection, and how do I prevent tool misuse?

Prompt enjeksiyonu, güvenilmeyen içeriğin modeli yönlendirmesidir. Modelin araçları (DB sorguları, e-posta, iadeler, dağıtımlar) kullanabildiği durumlarda tehlikeli olur.

Pratik savunmalar:

En az ayrıcalıklı araç izinleri.
Serbest forma izin vermek yerine izinli, parametreli işlemler kullanın (ör. lookup_order(id) yerine rastgele SQL).
Araç çağrısını çalıştırmadan önce doğrulayın (onaylı domainler, maksimum tutarlar, güvenli sorgu şablonları).
Geri dönüşü olmayan veya yüksek etkili eylemler için insan onayı şartı koyun.

Where do privacy leaks happen in LLM apps besides the prompt itself?

En büyük sızıntılar genellikle dolaylı olanlardır:

Sohbet geçmişi/belleği süresiz saklanması,
Ham promptları/araç çıktısını yakalayan uygulama logları ve hata izleri,
İstek gövdelerini kaydeden APM/tracing,
Metin alanlarını kaydeden analiz/oturum tekrar oynatma araçları,
Silme isteklerinde unutulan embeddings/vector store’lar.

Maruziyeti azaltmak için veri minimize edin, logging öncesi agresif redaksiyon yapın, sıkı erişim kontrolleri uygulayın ve her sistem için belgelenmiş saklama süreleri belirleyin (mümkünse yedekleri de dahil ederek).

What’s the safest way to implement tenant isolation in a multi-tenant app?

İzolasyonu sunucu tarafında uygulayın:

Her sorgu tenant_id ile sınırlandırılmalı.
tenant_id kimlik doğrulama oturumundan alınmalı, isteğin gövdesinden değil.
Okuma/güncelleme/silme işlemlerinde nesne düzeyinde sahiplik kontrolleri ekleyin.

IDOR testi yapın: bir kullanıcı tahmini ID’lerle başka bir tenant’ın /resource/{id} kaydına erişememelidir.

How should we handle secrets when using copilots and agents?

Üç kuralı uygulayın:

Gizli anahtarları promptlara, kaynak koda veya tarayıcıya koymayın.
Bir secrets manager kullanın ve çalışma zamanında enjekte edin.
Kısa ömürlü kimlik bilgilerini tercih edin (dönebilen tokenler) ve hızlı iptal yolu sağlayın.

Operasyonel olarak, gizli anahtarlara erişimi denetleyin (audit trail), düzenli döngüde döndürün ve olası sızıntıda hemen iptal/döndürme yapın.

What monitoring and incident readiness do we need before shipping?

Üretimde “işe yarayan” sinyallerin asgari seti:

Kimlik olayları, yetkilendirme kararları, araç çağrıları ve veri erişimi için aranabilir bir denetim izi (gerekirse hassas alanlar redakte edilmiş).
Ani artışlar için uyarılar: toplu okuma/dışa aktarmalar, tekrar eden reddedilme olayları, alışılmadık araç kullanımı, ayrıcalık değişiklikleri.
Bir runbook: riskli araçları devre dışı bırakma, anahtar döndürme, oturumları iptal etme, sürümü geri alma.

“Kim ne yaptı, hangi araçla, hangi veriye?” sorusuna hızlı cevap veremiyorsanız olay müdahalesi yavaş ve tahmine dayalı olacaktır.