User agent allowlist, web üzerindeki en eski kalıplardan biridir. Güvendiğiniz crawler ve istemci adlarının bir listesini tutarsınız. Bir istek eşleşen bir User-Agent üstbilgisiyle geldiğinde, onu geçirir, bir challenge'ı atlarsınız ya da daha hafif bir sayfa sunarsınız. Kurulumu dakikalar sürer ve ekipteki herkes bunu anlar.
Bu kalıp, ana otomatik ziyaretçilerin bir avuç arama crawler'ı ve birkaç izleme aracı olduğu dönemde daha anlamlıydı. Bugün AI ajanları, asistanlar ve otomatik istemciler uygulamalara giderek artan sayılarda ulaşıyor ve birçoğu bir ad duyuruyor. Bu adların bazıları gerçektir. Bazıları kopyadır. Üstbilgi hangisinin hangisi olduğunu söyleyemez.
Proof of Actor farklı bir yaklaşım izler. Bir User-Agent dizesini olduğu gibi, yani bir beyan olarak ele alır ve bu kanıt mevcutsa onu daha güçlü kanıtla birlikte raporlar. Bu sayfa, ada göre allowlist yapmanın sınırlarını, ağ düzeyindeki kontrollerin nerede yardımcı olduğunu ve doğrulanmış imzalar ile açık bir Unknown sınıfının tabloyu nasıl değiştirdiğini açıklar.
Kısa versiyon
| User agent allowlist | Proof of Actor | |
|---|---|---|
| Ana kanıt | User-Agent üstbilgisindeki bir ad | Her biri kendi temeliyle etiketlenmiş imzalar, beyanlar ve sinyaller |
| İstemci bunu taklit edebilir mi? | Evet, aynı dizeyi göndererek | declared bir temel iddia edilebilir; verified bir temel imzalama anahtarını gerektirir |
| Çıktı | Listede var ya da yok | Human, Human + AI, Agent veya Unknown, artı bir temel |
| Belirsiz trafik | Allowlist'te değil sayılır ya da varsayılan olarak izin verilir | Unknown, rota bazında sizin seçtiğiniz bir yedek davranışla |
| AI destekli insanlar | Görünmez; sıradan tarayıcılar kullanırlar | declared veya observed olduğunda ayrı bir sınıf, Human + AI |
| Bakım | Adlar değiştikçe manuel liste güncellemesi | Ajan operatörleri tarafından yayımlanan anahtarlar; politikalar sizin kodunuzda |
| Kurulum sonrası varsayılan | Listenin izin verdiği her şey | Observation; siz bir politika ekleyene kadar hiçbir şey değişmez |
| En iyi olduğu alan | Uyumlu, bilinen istemcilerin ucuz yönlendirilmesi | Ürün ve politika kararları için kanıta dayalı aktör bağlamı |
Sayfanın geri kalanı her satırı açıklar.
User-Agent'e göre allowlist neden taklit edilebilir?
User-Agent üstbilgisi istemci tarafından ayarlanır. Bir tarayıcı ayarlar, bir script ayarlar ve bir ajan çerçevesi ayarlar. HTTP içinde değerin doğru olduğunu kontrol eden hiçbir şey yoktur. Allowlist'iniz bir dizeye güveniyorsa, o dizeyi kopyalayan herkes aynı muameleyi görür.
Buna user agent spoofing denir ve bunun basit bir nedeni vardır: maliyeti sıfıra yakındır. Bir challenge'dan kaçınmak isteyen bir scraper, güvendiğiniz bir crawler'ın adını ödünç alabilir. Kötü davranan bir istemci kendini popüler bir asistan olarak tanıtabilir. Meşru bir araç bile, bir kütüphane varsayılanı bunu yaptığı için genel bir tarayıcı dizesi gönderebilir.
Sonuç olarak, bir user agent allowlist'in iki hata modu vardır:
- Yanlış güven: güvenilmeyen bir istemci güvenilen bir adı iddia eder ve geçer.
- Yanlış şüphe: meşru bir istemci beklenmeyen ya da genel bir dize gönderir ve başarısız olur.
Bu hataların hiçbiri sadece üstbilgiden görünmez. Temel sınırlama budur ve hiçbir liste bakımı bunu ortadan kaldırmaz.
Üstbilgi yine de ne işe yarar?
Bunların hiçbiri User-Agent dizelerini yok saymanız gerektiği anlamına gelmez. Uyumlu crawler'lar ve ajanlar kendilerini dürüstçe tanıtır ve ad, yönlendirme, analitik ve hata ayıklama için yararlı bir ipucudur. Size bir istemcinin kendini ne olarak tanımladığını söyler.
Bu bilginin doğru yeri, erişimi tek başına açan bir anahtar olarak değil, başka kanıtlarla birlikte değerlendirilen bir beyan olarak yeridir. Proof of Actor bunu tam da bu şekilde kaydeder.
Reverse DNS ve IP listeleri: kısmi önlemler
Birçok ekip allowlist'i ağ denetimleriyle güçlendirir. Bunlar yardımcı olur ve tam olarak anlaşılmaya değerdir.
Reverse DNS doğrulaması
Bazı crawler operatörleri bir doğrulama süreci belgeleyerek şunu yapar: isteğin IP adresi için host adını sorgulayın, bunun operatörün alan adına ait olduğunu kontrol edin, ardından o host adını sorgulayın ve aynı IP'ye çözüldüğünü doğrulayın. Bu ileri-geri işlem başarılı olduğunda, isteğin operatörün altyapısından geldiğine dair gerçek kanıt elde etmiş olursunuz.
Sınırlamalar pratiktir. Bu yöntem yalnızca belgeleyen ve destekleyen operatörler için çalışır. Önbelleğe alınması gereken DNS sorguları ekler. Ve size ağ hakkında bilgi verir, bu ağ üzerinde hangi ürünün ya da ajanın isteği yaptığı hakkında değil.
Yayımlanmış IP aralıkları
Diğer operatörler, otomatik istemcilerinin kullandığı IP aralıklarını yayımlar. Bir isteği bu aralıklarla eşleştirmek hızlıdır ve reverse DNS'e benzer kanıt sağlar. IP aralıklarını yayımlamak için standart bir biçim konusunda süren bir IETF tartışması vardır, ancak Kasım 2026 itibarıyla uzlaşılmış bir standart yoktur ve kapsama, her operatörün yayımlamayı seçmesine bağlıdır.
IP kanıtı, daha fazla ajanın paylaşımlı bulut altyapısında, proxy'lerin arkasında veya kullanıcının kendi cihazından çalışmasıyla da zayıflar. Bir bulut adresi, birbiriyle ilgisiz birçok istemciyi barındırabilir ve bir kişinin tarayıcısından çalışan bir ajan, o kişinin ağına benzer.
Ağ denetimleri toplamda ne sağlar?
Reverse DNS ve IP listeleri, bazı tanınmış operatörler için kimi beyanları daha güçlü bir şeye dönüştürür. Ajanların ve araçların uzun kuyruğunu kapsamazlar ve AI ile birlikte çalışan insanlar için hiç yardımcı olmazlar. Bunlar kısmi önlemlerdir: kullanmaya değer, tek başına yeterli değil.
İmzalar ve beyanlar
Kanıtın daha güçlü biçimi kriptografik bir imzadır. RFC 9421'de tanımlanan HTTP Message Signatures ile bir istemci, her isteğin seçili parçalarını özel bir anahtarla imzalar. Doğrulayıcı, operatörün yayımladığı genel anahtarı alır ve imzayı kontrol eder. Doğrulanırsa, istek o anahtarın sahibi tarafından imzalanmıştır ve imzalanan parçalar yolda değiştirilmemiştir.
IETF Web Bot Auth çalışma grubu, otomatik istemcilerin bu imzaları nasıl kullanacağını ve anahtarlarını nasıl yayımlayacağını standartlaştırıyor. Ürün ekipleri için Web Bot Auth açıklamamız mevcut durumu kapsar.
Proof of Actor, geçerli bir imzayı verified kanıt olarak kullanır. Bir User-Agent dizesi, bir client hint ya da istek gövdesindeki öz tanım declared sayılır. Davranışsal ve bağlamsal sinyaller inferred sayılır ve bu şekilde etiketlenir. Her sonuç, hangi temele dayandığını açıkça belirtir; böylece ekibiniz hiçbir zaman bir iddiayı bir kontrol ile karıştırmaz. Tam tanımlar için evidence basis girdisine bakın.
Doğrulanmış kanıt için bile bir sınır vardır. Geçerli bir imza, isteği hangi anahtarın imzaladığını kanıtlar. Ajanın yapmaya çalıştığı şeyi yapmaya yetkili olduğunu kanıtlamaz. Bu, bir agent authorization sorusudur ve uygulamanızda kalır.
Tahmin etmek yerine Unknown'u ele almak
Bir allowlist her isteği iki kutudan birine zorlar: listede ya da değil. Pratikte bu, belirsiz trafiğin varsayılanınız neyse onu aldığı anlamına gelir ve varsayılan genellikle tüm site için bir kez seçilir.
Proof of Actor, Unknown'u birinci sınıf bir sonuç olarak ele alır. Kanıt güvenilir bir belirlemeyi desteklemiyorsa, tahmin etmek yerine bunu söyler. Sonrasında politikalarınız Unknown'un her rota için ne anlama geldiğine karar verir:
- Genel dokümantasyon ya da pazarlama sayfalarında izin verin.
- Arama ya da listeleme endpoint'lerinde normal rate limit'lerinizle izin verin.
- Hesap değişikliklerinde mevcut kontrollerinizi koruyun.
- Yüksek etkili eylemlerde review'a gönderin ya da daha güçlü bir sinyal isteyin.
handling Unknown traffic rehberi ve unknown classification girdisi kalıpları adım adım açıklar. Unknown oranınızı zaman içinde izlemek de trafiğinizin ne kadarının hâlâ zayıf kanıta dayandığını gösterir.
Peki AI destekli insanlar?
Bir user agent allowlist, sıradan bir tarayıcı içinde AI asistanı kullanan bir kişi hakkında hiçbir şey söylemez. Onların User-Agent'i normal bir tarayıcı dizesidir. Yine de birçok ürün bu etkileşimi tanımak ister, örneğin AI ile oluşturulmuş gönderimleri etiketlemek ya da AI destekli kullanıcıların onboarding boyunca nasıl ilerlediğini anlamak için.
Proof of Actor, desteklenen bir entegrasyon aracılığıyla yardım beyan edildiğinde ya da gözlendiğinde bu etkileşimleri Human + AI olarak raporlar. Yalnızca yazı stilinden tahmin etmez. Daha fazlası için AI-assisted interaction bölümüne bakın.
Bir allowlist'ten kanıta dayalı politikalara geçmek
Allowlist'inizi ilk günde kaldırmanız gerekmez. Güvenli bir yol şu şekilde görünür:
- İzleme modunda kurun. Proof of Actor hiçbir şeyi değiştirmez. Allowlist'iniz çalışmaya devam eder.
- Karşılaştırın. Her rota için, hangi allowlist'li isteklerin verified kanıt taşıdığını, hangilerinin yalnızca bir beyan taşıdığını ve hangilerinin Unknown'a düştüğünü görün.
- Politikaları önizleyin. Verified ajanları, declared ajanları ve Unknown'u farklı ele alan bir politika taslağı hazırlayın ve gerçek trafikte etkisini önizleyin.
- Rota bazında uygulayın. Taklit edilmiş bir adın en çok fark yaratacağı rotalardan başlayın.
- Allowlist'i bir ipucu olarak tutun. Adlar yönlendirme ve analitik için hâlâ yararlıdır; artık temelleri görünürdür.
rolling out actor-aware policies safely rehberi her adımı kapsar ve verified automated requests imzalı istemcilerin nasıl uyduğunu açıklar.
Bir allowlist ne zaman yeterlidir?
Düşük riskli yönlendirmelerde, örneğin genel içerikte bilinen bir crawler için daha hafif bir sayfa sunarken, bir user agent allowlist çoğu zaman yeterlidir. Taklit edilmiş bir adın maliyeti küçüktür.
Kararın sonuçları varsa, örneğin bir challenge'ı atlamak, daha zengin veri açmak ya da bir yazma işlemini izin vermek gibi, kontrol edebileceğiniz kanıt istersiniz. Proof of Actor tam burada yer alır ve zaten çalıştırdığınız ağ kontrolleri ve edge kontrolleriyle birlikte çalışır.
Başlayın
Proof of Actor özel beta aşamasındadır. Seçilmiş founding developer ekipleri, üzerinde anlaşılan kullanım limitleri dahilinde, otomatik faturalandırma olmadan 12 aya kadar ücretsiz erişim alabilir. Erken erişim için başvurun ve bugün hangi istemcileri allowlist ettiğinizi ve hangi rotaları daha iyi kanıtla korumak istediğinizi bize anlatın.