Bir kullanıcı yapay zeka asistanına "bana 42 numara, su geçirmez, bütçemi aşmayan bir yürüyüş botu bul ve sepete ekle" dediğinde, asistan bu işi bir insan gibi yapmaya çalışır: arama yapar, mağaza sitelerini açar, ürün sayfalarını karşılaştırır, bedeni seçer ve ödeme adımına kadar ilerler. Çoğu zaman da bir yerde durur. Ürün sayfası yerine bir doğrulama ekranı gelir, sepete ekleme isteği reddedilir ya da ödeme sayfası şüpheli işlem uyarısı verir. Kullanıcının gözünde asistan başarısız olmuştur; mağazanın gözünde ise bir bot durdurulmuştur.
Bu yazıda AI alışveriş ajanının ne olduğunu, sitelerin bu ajanları neden engellediğini ve sorunun özünü, yani bir sitenin insanı, kötü niyetli botu ve kullanıcı adına yetkiyle hareket eden bir ajanı birbirinden ayırmasının neden zor olduğunu anlatıyoruz. Ardından bu soruna yönelik ortaya çıkan çözümleri (imzalı ajanlar, Web Bot Auth ve ödeme tarafındaki yeni protokolleri) ve satıcılar ile ajan geliştiriciler için doğru yolu ele alıyoruz. Bu yazı ajanları bot korumasından geçirmenin yollarını anlatmaz; ajan trafiğinin kendini doğru tanıtması üzerine kuruludur.
AI alışveriş ajanı nedir?
AI alışveriş ajanı, bir kullanıcının alışveriş hedefini alıp bunu gerçekleştirmek için web sitelerinde kendisi işlem yapan yapay zeka sistemidir. Genel çalışma mantığı, AI Ajanları Nasıl Çalışır? yazımızda anlattığımız algıla-planla-uygula-değerlendir döngüsüdür; alışveriş ajanında bu döngünün araçları mağaza siteleri ve ödeme sistemleridir.
Bir alışveriş ajanının yaptığı işler üç düzeyde toplanabilir:
- Araştırma: Ürün arama, fiyat ve özellik karşılaştırma, yorumları okuma.
- Hazırlık: Beden, renk ve adet seçimi, sepete ekleme, kargo seçeneklerini değerlendirme.
- İşlem: Ödeme bilgilerini kullanarak siparişi tamamlama.
Her düzey siteye farklı bir risk taşır. Araştırma, bir scraper'ın yaptığı işe benzer. Sepete ekleme sitenin stok ve oturum sistemlerini etkiler. Ödeme ise para ve sahtecilik riski demektir. Siteler de ajanlara bu düzeylere göre farklı tepkiler verir.
Siteler ajanı neden engeller?
Bir e-ticaret sitesinin ajan trafiğini durdurması çoğu zaman ajanlara karşı özel bir tutumdan değil, yıllardır var olan savunmaların ajanları da yakalamasından kaynaklanır.
Bot koruması. E-ticaret siteleri fiyat kazıma, stok toplama (sınırlı ürünleri sepete ekleyip başkalarının almasını engelleme), hesap ele geçirme ve kart doğrulama saldırılarına karşı bot yönetim sistemleri kullanır. Bu sistemler istekleri hız, IP itibarı, tarayıcı parmak izi ve davranış gibi sinyallerle puanlar. Bir alışveriş ajanı çoğu zaman bir veri merkezinden, headless bir tarayıcıyla, insan hızının çok üstünde sayfa açarak çalışır; yani bot koruma sistemlerinin aradığı sinyallerin neredeyse hepsini taşır. Bu sinyallerin nasıl değerlendirildiğine bir örnek Cloudflare Precursor yazımızda.
Ödeme sahteciliği riski. Ödeme sistemleri, kartın kart sahibi tarafından kullanıldığını çeşitli sinyallerle doğrular: cihaz, konum, alışkanlık ve 3-D Secure gibi ek doğrulama adımları. Bir ajan kart bilgisiyle ödeme yapmaya çalıştığında bu sinyallerin çoğu kart sahibinin normal profiliyle eşleşmez. Ödeme sistemi açısından bu tablo, çalınmış kartla yapılan otomatik alışverişe benzer.
Hizmet şartları. Birçok e-ticaret sitesinin kullanım şartları otomatik erişimi, otomatik sipariş vermeyi veya sitenin içeriğini otomatik araçlarla toplamayı kısıtlar. Sitenin kendi kurallarına göre bir ajan, kullanıcı adına hareket etse bile yetkisiz bir otomasyon aracıdır.
Müşteri ilişkisi ve veri. Satıcı açısından ajan, müşteriyle kendisi arasına giren bir aracıdır. Ürün sayfası, öneriler, kampanyalar ve sadakat programı gibi satış deneyiminin önemli kısmı ajanın kullanıcıya yalnızca özet göstermesiyle devre dışı kalır. Bazı satıcılar bu yüzden ajan trafiğine temkinli yaklaşır.
Sorumluluk belirsizliği. Ajan yanlış bedeni sepete eklediğinde, kullanıcının onaylamadığı bir ürünü satın aldığında ya da fiyatı yanlış okuduğunda iadenin ve itirazın muhatabı kimdir? Bu soruların net cevabı olmadığı sürece satıcılar ve ödeme kuruluşları riski azaltmak için engellemeyi tercih edebilir.
İnsan, bot ve yetkili ajan ayrımı neden zor?
Bir sitenin bot koruması tarihsel olarak iki kategoriyle çalışır: insan ve bot. Alışveriş ajanı bu ikiliğe uymayan üçüncü bir kategoridir.
| Özellik | İnsan ziyaretçi | Kötü niyetli bot | Kullanıcı adına çalışan ajan |
|---|---|---|---|
| Kim adına hareket eder? | Kendisi | Saldırgan | Gerçek bir kullanıcı |
| Trafik biçimi | Tarayıcı, insan hızında | Otomasyon, yüksek hız | Otomasyon, yüksek hız |
| IP kaynağı | Ev veya mobil bağlantı | Genellikle veri merkezi veya proxy | Genellikle ajan sağlayıcısının sunucuları |
| Niyet | Alışveriş | Kazıma, stok toplama, sahtecilik | Alışveriş |
| Ödeme | Kart sahibi | Çalıntı veya test kartı | Kart sahibinin yetkisiyle |
| Site açısından istenen | İzin ver | Engelle | İzin ver, ama doğrula |
Sorun, tablonun ilk dört satırında ajanın kötü niyetli bota, son iki satırında ise insana benzemesidir. Bot koruma sistemleri yalnızca davranışa ve ağ sinyallerine bakabildiği için ajanı bottan ayırması için gereken bilgi, yani "bu otomasyonun arkasında kim var ve yetkisi ne", HTTP isteğinde yer almaz.
Bu boşluğu User-Agent başlığıyla doldurmak mümkün değildir, çünkü bu başlık düz metindir ve herkes herhangi bir değeri yazabilir. Bir sitenin "BilinenAlısverisAjani/1.0" diyen bir isteği gerçekten o şirketin ajanından geldiğine inanması için doğrulanabilir bir kanıta ihtiyacı vardır. Aynı şekilde IP adresi listeleri de bir ölçüde işe yarar, ama bulut altyapısında adresler paylaşılır ve değişir.
Bu yüzden ajanın kendini gizlemesi ya da insana benzemeye çalışması sorunu çözmez; sorunu büyütür. Tarayıcı parmak izini sahteleyen, proxy havuzlarıyla IP değiştiren bir ajan, bot koruma sistemlerinin tam olarak engellemek için tasarlandığı trafiğe dönüşür. Çözüm yönü tam tersidir: ajanın kendini doğrulanabilir biçimde tanıtması.
İmzalı ajanlar ve Web Bot Auth
Bu yönde ortaya çıkan başlıca yaklaşım, ajanın her HTTP isteğini kriptografik olarak imzalamasıdır. Temelinde IETF'in HTTP Message Signatures (RFC 9421) standardı vardır. Bu standart, bir HTTP mesajının seçilen bileşenlerinin (yöntem, adres, belirli başlıklar) bir özel anahtarla imzalanmasını ve alıcının bu imzayı açık anahtarla doğrulamasını tanımlar.
Web Bot Auth, bu standardı botların ve ajanların kimlik doğrulaması için kullanan yaklaşımın adıdır. Cloudflare'in Web Bot Auth belgesine göre işleyiş şöyledir:
- Ajan işletmecisi bir anahtar çifti oluşturur ve açık anahtarını kendi alan adında,
/.well-known/http-message-signatures-directoryadresinde bir anahtar dizini olarak yayımlar. - Ajan her isteğe üç başlık ekler:
Signature-Input(imzanın kapsadığı bileşenler, anahtar kimliği, oluşturma ve geçerlilik zamanı, tek kullanımlık değer),Signature(imzanın kendisi) veSignature-Agent(anahtar dizininin adresi). - Site veya önündeki CDN imzayı doğrular: anahtar dizinini okur, imzayı açık anahtarla kontrol eder ve imzanın süresinin dolmadığından emin olur.
- Doğrulanan istek bilinen bir ajana atfedilir. Site bu bilgiye göre isteğe izin verebilir, hızını sınırlayabilir ya da belirli yollara erişimini kısıtlayabilir.
Bu yaklaşımın önemli bir özelliği, doğrulamanın IP adresine bağlı olmamasıdır: ajan hangi sunucudan çalışırsa çalışsın, imza aynı işletmeciye işaret eder. Anahtar dizininin kendisi de imzalanır; böylece başka birinin sahte bir dizinle o işletmeciyi taklit etmesi zorlaşır.
Cloudflare, bu tür kendini kriptografik olarak tanıtan ajanları 1 Temmuz 2026'dan itibaren doğrulanmış bot sınıflandırması altında ele alıyor. Pratikte bu, site sahiplerinin doğrulanmış ajanlara bot koruma kurallarında ayrı bir yol açabilmesi anlamına geliyor.
Ödeme tarafındaki yeni protokoller
Bir ajanın siteye erişebilmesi sorunun yarısıdır. Diğer yarısı, ajanın ödeme yapma yetkisinin doğrulanmasıdır. Bu alanda da 2025'ten itibaren birkaç protokol ortaya çıktı. Bunlar birbirinin rakibi olmaktan çok, sürecin farklı adımlarına odaklanır:
- Visa Trusted Agent Protocol: Visa'nın Ekim 2025'te duyurduğu protokol, Visa'nın açıklamasına göre HTTP Message Signatures standardı üzerine kuruludur, Web Bot Auth ile uyumludur ve Cloudflare ile birlikte geliştirilmiştir. Amacı, satıcıların Visa tarafından tanınan ve alışveriş niyetiyle hareket eden ajanları kötü niyetli otomasyondan ayırabilmesidir.
- Agentic Commerce Protocol (ACP): OpenAI ve Stripe tarafından yürütülen açık bir spesifikasyondur. Proje sayfasına göre alıcı, ajan, satıcı ve ödeme sağlayıcı arasındaki satın alma akışını standartlaştırır; ajan ödeme arayüzünü kullanıcıya gösterir, satıcı ise kendi altyapısını ve ödeme işleme sürecini korur.
- Agent Payments Protocol (AP2): Google'ın ortaklarıyla duyurduğu protokol, ajanın kullanıcı adına ödeme yapma yetkisini kriptografik olarak imzalanmış yetki belgeleriyle taşımayı hedefler. Böylece satıcı ve ödeme kuruluşu, işlemin kullanıcının onayladığı sınırlar içinde olduğunu doğrulayabilir.
Bu protokollerin bir kısmı hâlâ beta aşamasında ve kapsamları hızla değişiyor. Bir entegrasyon planlıyorsanız ilgili protokolün güncel belgesini kontrol edin.
Kim neyi çözüyor?
| Taraf | Yaşadığı sorun | Ortaya çıkan çözüm |
|---|---|---|
| Satıcı (e-ticaret sitesi) | Ajanı kötü niyetli bottan ayıramıyor | İmzalı ajan trafiğini doğrulayıp ayrı kurallarla yönetmek |
| CDN ve bot yönetim servisi | Kimliği doğrulanamayan otomasyon | Web Bot Auth imza doğrulaması, doğrulanmış bot sınıflandırması |
| Ödeme ağı | Ajanın kart sahibi adına yetkisi bilinmiyor | Tanınan ajan protokolleri, doğrulanabilir yetki belgeleri |
| Ödeme sağlayıcı | Ajan ile satıcı arasında standart ödeme akışı yok | Açık satın alma protokolleri |
| Ajan geliştirici | İstekler engelleniyor, işlemler yarıda kalıyor | İsteklerini imzalamak, resmi entegrasyonları kullanmak |
| Kullanıcı | Ajanın ne satın alacağını kontrol edememe | Harcama sınırları, onay adımları, doğrulanabilir yetki |
Satıcılar ne yapabilir?
Ajan trafiğini tamamen engellemek de tamamen serbest bırakmak da satıcı için doğru olmayabilir. Kademeli bir yaklaşım daha sağlıklıdır:
- Trafiği ölçün. Sitenize gelen otomatik trafiğin ne kadarının arama motoru, ne kadarının bilinen yapay zeka tarayıcıları, ne kadarının kimliği belirsiz otomasyon olduğunu görün.
- Politikanızı yazın. Hangi ajanların hangi sayfalara (katalog, sepet, ödeme) erişebileceğine karar verin. Katalog sayfalarını açık, ödemeyi doğrulanmış protokollere bağlı tutmak yaygın bir başlangıçtır.
- robots.txt ve şartları güncelleyin. Ajanlar için tercihlerinizi hem makine tarafından okunabilir biçimde hem kullanım şartlarında açıkça belirtin. Dosyanın nasıl yazıldığını robots.txt Dosyası Nedir, Nasıl Okunur? yazımızda anlattık.
- İmzalı ajanları tanıyın. Bot yönetim servisinizin doğrulanmış ajanlar için sunduğu ayarları kullanın; kimliği doğrulanmış ajan trafiğini kimliği belirsiz trafikten ayrı değerlendirin.
- Yapılandırılmış veri sunun. Ürün sayfalarındaki schema.org verisi ve varsa resmi ürün akışları, ajanların sayfayı kazımak zorunda kalmadan doğru bilgiye ulaşmasını sağlar.
- Ödeme ortaklarınızın ajan protokollerini takip edin. Ödeme sağlayıcınız bu protokolleri destekliyorsa, ajan kaynaklı işlemleri sahtecilik kurallarından ayrı bir akışta ele almak mümkün hâle gelir.
Kendi sitenizde ajan ve bot trafiğini izleme, reklam ve fiyat görünümünü farklı ülkelerden doğrulama gibi işlerde e-ticaret proxy çözümü ve reklam doğrulama çözümü sayfalarımızdaki senaryolara bakabilirsiniz.
Ajan geliştiriciler için doğru yol
Bir alışveriş ajanı geliştiriyorsanız, engellenme sorununa verilecek yanlış cevap ajanı daha iyi gizlemektir. Tarayıcı parmak izini sahtelemek, doğrulama ekranlarını çözdürmek ya da trafiği proxy havuzlarıyla dağıtarak bot korumasını aşmaya çalışmak hem sitelerin kurallarına aykırıdır hem de ajanınızı tam olarak engellenmesi gereken trafik sınıfına sokar. Tarayıcı parmak izinin nasıl çalıştığını Tarayıcı Parmak İzi yazımızda, doğrulama ekranlarının neden çıktığını Puppeteer ve CAPTCHA yazımızda anlattık.
Doğru yol şu adımlardan geçer:
- Ajanınızı tanıtın. Tanımlı bir ürün adı ve iletişim adresi içeren bir
User-Agentkullanın; mümkünse isteklerinizi Web Bot Auth ile imzalayın. - Resmi entegrasyonları önceliklendirin. Satıcının API'si, ürün akışı veya desteklediği satın alma protokolü varsa sayfa kazımak yerine onları kullanın.
- robots.txt ve şartlara uyun. Bir sitenin ajanlara kapattığı yolları kullanıcı adına bile olsa zorlamayın.
- Kullanıcı onayını sürecin parçası yapın. Ödeme gibi geri alınamayan adımlardan önce kullanıcıdan açık onay alın; harcama sınırlarını ajanın değil kullanıcının belirlemesini sağlayın.
- Hızı sınırlayın. Bir kullanıcının alışverişi için onlarca sayfayı saniyeler içinde açmanız gerekmez.
- Başarısızlığı kabul edin. Bir site ajanınızı engelliyorsa kullanıcıya bunu açıkça söyleyin ve alternatif sunun; engeli aşmaya çalışmayın.
Ajanların web erişimini hız sınırı, izin listesi ve kayıt tutmayla güvenli hâle getirmeyi LLM'e Güvenli Web Erişimi: Hız Sınırı ve İzinler yazımızda anlattık. Bu yapıda proxy, ajanı gizlemek için değil, ajan trafiğinin hangi adresten ve hangi konumdan çıktığını kontrol etmek ve kaydetmek için kullanılır.
Sık yapılan hatalar
- Ajanı insan gibi göstermeye çalışmak. Sahte parmak izi ve IP rotasyonu, ajanı kötü niyetli botlarla aynı sınıfa sokar.
- Satıcı olarak bütün otomatik trafiği aynı kategoride görmek. Doğrulanmış ajanlarla kimliği belirsiz botları ayırmamak, meşru satış kanallarını kapatabilir.
- User-Agent başlığını kimlik doğrulama sanmak. Başlık herkes tarafından yazılabilir; doğrulama için imza gerekir.
- Kullanıcı onayı olmadan ödeme yapmak. Hem sahtecilik kurallarını tetikler hem kullanıcıyla ciddi bir güven sorunu yaratır.
- Protokol durumunu kontrol etmeden entegrasyon planlamak. Bu alandaki protokollerin çoğu hızla değişiyor.
- Engellenmeyi teknik bir hata gibi ele almak. Çoğu zaman sitenin bilinçli bir politikasıdır.
Karar rehberi
| Durumunuz | Öneri |
|---|---|
| Ajanınız yalnızca ürün araştırıyor | Kendini tanıtan User-Agent, robots.txt, hız sınırı; varsa ürün API'si |
| Ajanınız sepete ekleme ve ödeme yapacak | Satıcının desteklediği satın alma protokolü, kullanıcı onayı |
| Ajanınız sık engelleniyor | İstekleri Web Bot Auth ile imzalayın; engeli aşmaya çalışmayın |
| Satıcısınız, ajan trafiği artıyor | Trafiği ölçün, politika yazın, imzalı ajanları ayrı kurallarla yönetin |
| Satıcısınız, ödemede ajan işlemleri reddediliyor | Ödeme sağlayıcınızın ajan protokollerini değerlendirin |
| Ajan trafiğinizin çıkışını kontrol etmek istiyorsunuz | Sabit ve kayıt tutulan çıkış adresi, izin listesi |
Sık sorulan sorular
AI alışveriş ajanları neden doğrulama ekranına takılıyor?
Bot koruma sistemleri ajan trafiğini hız, tarayıcı özellikleri ve IP kaynağı gibi sinyallere göre değerlendirir. Ajanlar bu sinyallerde kötü niyetli otomasyona benzediği için doğrulama ekranı veya engelleme ile karşılaşır. İstek, arkasında kimin olduğunu doğrulanabilir biçimde taşımadığı sürece site ikisini ayıramaz.
Web Bot Auth nedir?
Botların ve ajanların HTTP isteklerini kriptografik olarak imzalayarak kimliklerini kanıtlamasını sağlayan yaklaşımdır. RFC 9421 HTTP Message Signatures standardını kullanır. Ajan açık anahtarını kendi alan adında yayımlar; site veya CDN her isteğin imzasını bu anahtarla doğrular.
İmzalı bir ajan bütün sitelerde çalışır mı?
Hayır. İmza yalnızca ajanın kim olduğunu kanıtlar; siteye erişim izni vermez. Her site imzalı ajanlara ne kadar izin vereceğine kendisi karar verir. İmzayı doğrulamayan sitelerde ise imzanın etkisi olmaz.
Ajanım proxy kullanarak engelden kurtulabilir mi?
Proxy ile IP değiştirerek bot korumasını aşmaya çalışmak, sitenin açık bir tercihini yok saymak anlamına gelir ve ajanınızı kötü niyetli otomasyonla aynı kategoriye sokar. Proxy'nin bu alandaki meşru kullanımı, ajan trafiğinin çıkışını kontrol etmek, kaydetmek ve gerektiğinde belirli bir konumdan görünmektir.
Satıcılar ajan trafiğini tamamen engellemeli mi?
Bu bir iş kararıdır. Tamamen engellemek sahtecilik riskini azaltır ama ajan kullanan müşterileri kaybettirebilir. Birçok satıcı için dengeli yol; katalog sayfalarını açık tutmak, doğrulanmış ajanları ayrı kurallarla yönetmek ve ödemeyi desteklenen protokollere bağlamaktır.
Bu protokoller Türkiye'de kullanılıyor mu?
Bu protokollerin çoğu yeni ve kapsamları ile bölgesel desteği hızla değişiyor. Türkiye'deki bir satıcı veya geliştirici olarak kendi ödeme sağlayıcınızın ve CDN'inizin hangi ajan doğrulama ve ödeme protokollerini desteklediğini doğrudan onlardan öğrenmeniz en doğru yoldur.
Özetle
AI alışveriş ajanları sitelerde engelleniyor, çünkü bot koruma sistemleri kullanıcı adına çalışan bir ajanı kötü niyetli otomasyondan ayıramıyor ve ödeme sistemleri ajanın kart sahibinin yetkisiyle hareket ettiğini doğrulayamıyor. Çözüm ajanı gizlemekte değil, kendini doğrulanabilir biçimde tanıtmasında: RFC 9421 tabanlı Web Bot Auth ile imzalı istekler, Visa Trusted Agent Protocol gibi tanınan ajan çerçeveleri ve ACP ile AP2 gibi satın alma ve ödeme yetkisi protokolleri bu yönde ilerliyor. Satıcılar ajan trafiğini ölçüp politika belirlemeli, ajan geliştiriciler de resmi entegrasyonlara ve kullanıcı onayına dayanmalı. Fiyat ve içerik görünümünü farklı konumlardan kurallara uygun biçimde doğrulamak için fiyat takibi çözümü sayfamıza göz atabilirsiniz.




