AÇIKLAYICI

Ürün ekipleri için Web Bot Auth: imzalı agent istekleri yol haritanız için ne anlama gelir

AI agent'lar ve crawler'lar, artık herhangi birinin kopyalayabileceği bir User-Agent string'ine güvenmeden kim olduklarını kanıtlamanın bir yoluna giderek daha fazla ihtiyaç duyuyor. IETF Web Bot Auth çalışması bunu standartlaştırmaya yönelik önde gelen girişimdir. Aşağıda ürün yöneticileri ve mühendislik liderleri için sade bir açıklama var: nasıl çalışır, neyi kanıtlar, November 2026 itibarıyla durumu nedir ve buna nasıl hazırlanmalısınız.

Erken erişim alın Nasıl çalıştığını keşfet

Yazan Toshendra SharmaKurucu ve CEO, AgentCredia · Updated November 13, 2026

Yıllar boyunca, otomatik bir istemcinin bir web sitesine kim olduğunu anlatmasının tek yolu User-Agent başlığındaki bir ad ve, birkaç büyük operatör için, yayımlanmış bir IP adresi listesi ya da ters DNS kontrolüydü. Adlar kolayca kopyalanır. Ağ listeleri yalnızca bunları sürdüren operatörleri kapsar. AI agent'lar web genelinde gerçek insanlar adına işlem yapmaya başladıkça, bu boşluk artık sadece bir güvenlik sorunu değil, bir ürün sorunu haline geldi.

Web Bot Auth bunu kapatmaya yönelik önde gelen girişimdir. Otomatik istemcilere, kontrol ettikleri ve yayımladıkları bir anahtarla isteklerini imzalama yolu verir, böylece bir site ada güvenmek yerine imzayı kontrol edebilir. Bu açıklama, teknik özellikleri baştan sona okumadan bunun ne olduğunu, neyi değiştirdiğini ve neyi değiştirmediğini anlaması gereken ürün yöneticileri ve mühendislik liderleri içindir.

Kısa özet

Nedir: otomatik HTTP istemcilerini kimlik doğrulamak için IETF çalışma grubu webbotauth ve standartlaştırdığı yaklaşım.
Nasıl çalışır: istemci, her isteğin bazı bölümlerini HTTP Message Signatures (RFC 9421) kullanarak imzalar ve genel anahtarlarının bulunduğu bir dizine işaret eder. Site anahtarı alır ve imzayı doğrular.
Neyi kanıtlar: isteği hangi anahtarın imzaladığını ve imzalanan bölümlerin aktarım sırasında değiştirilmediğini.
Neyi kanıtlamaz: agent'in istediği şeyi yapmaya yetkili olduğunu, belirli bir kullanıcı adına hareket ettiğini ya da iyi davranacağını.
November 2026 itibarıyla durum: RFC 9421 yayımlanmış bir Proposed Standard'dır. Web Bot Auth protokol belgesi ise henüz RFC olmayan bir working group Internet-Draft'tır.
Ne yapmalı: geçerli imzaları güçlü kanıt olarak ele almaya plan yapın, imzasız trafiği işlemeye devam edin ve yetkilendirme kararlarını kendi kodunuzda tutun.

IETF Web Bot Auth çalışması nedir

IETF, web sitelerine ağırlıklı olarak insanlara hizmet eden sistemlerde otomatik istemcileri kriptografik olarak doğrulama yöntemlerini ve onların arkasındaki operatörler hakkında daha fazla bilgi verme yollarını standartlaştırmak için Web Bot Auth çalışma grubunu kurdu. Charter, kapsamda geniş bir istemci kümesi tanımlar: crawler'lar, web arşivleyiciler, bağlantı denetleyicileri, AI eğitim crawler'ları ve son kullanıcılar adına hareket eden AI agent'lar.

Charter'daki iki istisna ürün ekipleri için önemlidir. Son kullanıcı kimlik doğrulaması kapsam dışıdır, bu nedenle bu bir kişiyi oturum açtırma yolu değildir. Bot itibarını izlemek de kapsam dışıdır, bu nedenle standart size bir isteği kimin imzaladığını söyler, o operatörün güvenilir olup olmadığını değil.

Charter üç tür çıktı listeler:

İnsanlara yönelik web siteleri için otomatik istemcileri kimlik doğrulama tekniklerine ilişkin Standards track belgeler.
Domain adı veya URL gibi mevcut bir tanımlayıcı kullanarak istek yapan bot hakkında daha fazla bilgi aktarmaya ilişkin Standards track belgeler.
Anahtar yönetimi, yaşam döngüsü ve dağıtım gibi operasyonel konulara ilişkin Best current practice veya informational belgeler.

Belgelerin durumu, November 2026 itibarıyla

November 2026 itibarıyla çalışma grubunun kabul edilmiş bir çalışma grubu belgesi vardır: draft-ietf-webbotauth-httpsig-protocol, başlığı "HTTP Message Signatures for automated traffic", revision 01, date October 29, 2026. Bu bir Internet-Draft'tır, yani hâlâ değişebilecek bir çalışma aşamasındaki belgedir. RFC değildir.

Grup ile ilişkili ve tartışılan birkaç bireysel draft da vardır. Bunlar arasında bir registry ve agent card formatı, anonymous bot authentication, otomatik istemcilerin IP aralıklarını yayımlamak için JSON formatı ve signed agent metadata için bir header önerileri bulunur. Bireysel draft'lar öneridir; bu tarihe kadar hiçbiri grup tarafından kabul edilmemiştir.

Charter, 2026 boyunca teknik özellikleri onay için IESG'ye göndermeye yönelik kilometre taşları belirledi. November 2026 itibarıyla protokol belgesi hâlâ bir working group draft'ıdır. Güncel durumu IETF datatracker sayfasında çalışma grubu için ve protokol draft'ında takip edebilirsiniz.

HTTP Message Signatures nasıl çalışır

Web Bot Auth, February 2024'te Proposed Standard olarak yayımlanan RFC 9421, HTTP Message Signatures üzerine kurulur. RFC 9421 genel bir mekanizmadır: bir HTTP mesajının seçili bölümlerinin nasıl imzalanacağını ve imzanın başlıklarda nasıl taşınacağını tanımlar. Web Bot Auth bunu otomatik istemciler için profiller.

Sade anlatımla, imzalı bir agent isteği şöyle çalışır:

Operatör bir anahtar çifti oluşturur. Private key'i gizli tutar ve public key'i yayımlar.
İstemci neyi imzalayacağını seçer. İstek bileşenlerini seçer, örneğin hedef host veya URI ve bir oluşturma zamanı. Mevcut draft, authority veya target URI'nin kapsanmasını zorunlu kılar, böylece bir site için alınan imza başka bir siteye karşı yeniden oynatılamaz.
İstemci imzalar ve gönderir. İstek, neyin ve hangi anahtarla imzalandığını açıklayan bir Signature-Input başlığı ve imza değeri içeren bir Signature başlığı taşır. Draft bir web-bot-auth tag'i kullanır ve her imzada oluşturma ve sona erme zamanları bekler.
Site doğrular. Genel anahtarı bulur, aldığı istekteki imzalı bileşenleri yeniden oluşturur ve imzayı kontrol eder. Kontrol geçerse, istek o anahtarın sahibi tarafından imzalanmıştır ve kapsanan bölümler değiştirilmemiştir.

Draft ayrıca bir siteye imza isteme imkânı verir. Bir origin, imzalı istekler istediğini belirtmek için genellikle bir ret ile birlikte bir Accept-Signature başlığı gönderebilir.

Anahtar dizini fikri

Bir imza, site doğru public key'i bulabildiği sürece anlamlıdır. Web Bot Auth bunu bir key directory ile çözer.

Mevcut çalışma grubu draft'ında istemci, HTTPS URL içeren bir Signature-Agent başlığı ekler. Bu URL, operatörün public key'lerinin bir JSON Web Key Set olarak bulunduğu bir dizini sunar. Site dizini çeker, imzadaki key identifier ile eşleşen anahtarı seçer ve doğrular. Draft ayrıca operatörün dizinini sunabileceği iyi bilinen bir yol olan /.well-known/http-message-signatures-directory'i de tanımlar.

Ürün ekipleri için yararlı fikir şudur: URL kimliğin bir parçası olur. Bir agent operatörü, anahtarlarını nerede yayımladığı ile tanımlanır ve bu, imzayı operatörün kontrol ettiği bir domain'e bağlar. Key rotation, yeni bir anahtarı eskisinin yanında yayımlayıp sonra eskisini kaldırarak çalışır.

Doğrulama yapan siteler dizinleri dikkatli şekilde ele almalıdır: normal HTTP kurallarına göre önbelleğe alın, boyut sınırları ve zaman aşımı belirleyin ve private network adreslerinden çekim yapmaktan kaçının. Bunlar standart mühendislik konularıdır ve birçok ekibin doğrulamayı onlar adına yapan bir bileşeni tercih etmesinin nedenlerinden biridir.

Geçerli bir imza neyi kanıtlar, neyi kanıtlamaz

Bu, ürün politikası yazan herkes için en önemli bölümdür.

Geçerli bir imza şunları kanıtlar:

İstek, belirli bir private key sahibince imzalanmıştır.
O key, operatörün kontrol ettiği bir dizin URL'sinde yayımlanmıştır.
İsteğin imzalı bölümleri aktarım sırasında değiştirilmemiştir ve imza geçerlilik penceresi içindedir.

Geçerli bir imza şunları kanıtlamaz:

Agent'in işlemi yapmaya yetkili olduğu. Tanımlanabilir olmak izin anlamına gelmez. Bakınız agent authorization.
Agent'in belirli bir kişi adına ya da o kişinin verdiği yetki kapsamında hareket ettiği. Bakınız delegated authority.
Operatörün güvenilir olduğu veya agent'in iyi davranacağı. Reputation, çalışma grubunun açıkça kapsamı dışındadır.
İmzalanmamış istekler hakkında herhangi bir şey. İmzasız trafik kendi başına ele alınmalıdır.

Geçerli bir imzayı, isteği kimin gönderdiğine dair güçlü kanıt olarak değerlendirin, ardından kendi erişim kontrolünüzün o göndericinin neyi yapabileceğine karar vermesine izin verin.

Ürün ekipleri bunun için ne yapmalı

Plan yapmak için bir RFC'yi beklemeniz gerekmez. İmzalı agent trafiği için şimdi hazırlık yapabilirsiniz, ancak draft'ın bazı ayrıntılarının değişebileceğini göz önünde bulundurun.

1. Karar vermeden önce ölçün

Trafiğinizin ne kadarının otomatik olduğunu, agent'ların hangi route'ları kullandığını ve bunun ne kadarının imzalı olduğunu öğrenin. Kullanıcılarınız için hiçbir şeyi değiştirmeyen observation mode ile başlayın.

2. Kanıtı politikadan ayırın

Kanıtın söylediğini, verified, declared, inferred veya unknown olarak, ne yapmaya karar verdiğinizden ayrı kaydedin. Bu, politikaları okunabilir tutar ve yeniden enstrümantasyon yapmadan sıkılaştırıp gevşetmenizi sağlar. evidence basis girişi dört seviyeyi açıklar.

3. Verified agent'lara daha iyi bir yol verin

Uygun olduğu yerlerde, verified agent'lara insanlar için oluşturulmuş sayfalar yerine yapılandırılmış içerik veya agent dostu bir akış sunun. AI agent'lara yapılandırılmış içerik sunma rehberi kalıpları kapsar.

4. Yetkilendirmeyi kendi kodunuzda tutun

İmza, kimlerin istediğini anlamak için kullanılır. Mevcut izinlerinizi, scope'larınızı ve onaylarınızı ne yapabileceklerine karar vermek için kullanın. Yüksek etkili işlemler, imzayı atan kim olursa olsun, yine de insan onayı gerektirebilir. Bakınız hassas eylemleri agent'ları engellemeden koruma.

5. İmzasız ve Unknown trafik için plan yapın

İmzalama desteği agent'lar ve araçlar arasında değişir, bu nedenle bir süre signed ve unsigned isteğin karışımını bekleyin. declared, inferred ve Unknown trafik için ne olacağını site geneli tek bir kural yerine route bazında belirleyin. Unknown trafiği ele alma rehberi bunu adım adım anlatır.

Proof of Actor Web Bot Auth'u nasıl kullanır

Proof of Actor, uygulamanızda her etkileşimde kim ya da neyin hareket ettiğini Human, Human + AI, Agent veya Unknown olarak söyler ve evidence basis'i belirtir. Web Bot Auth imzaları onun en güçlü kanıt kaynaklarından biridir.

Bir agent isteğini HTTP Message Signatures ile imzaladığında, Proof of Actor imzayı operatörün yayımladığı anahtara karşı kontrol eder. Kontrol geçerse, sonuç verified basis ile birlikte ekibinizin inceleyebileceği kanıtı taşır. Bir istemci kendini yalnızca bir başlıkta adlandırıyorsa sonuç declared olur. Sonuç davranışsal veya bağlamsal sinyallere dayanıyorsa inferred olarak etiketlenir. Kanıt yeterli değilse sonuç Unknown olur.

Uygulamanız bu bağlamla ne yapacağına kendisi karar verir. Politikalar route, actor class ve basis başına yazılır; allow, adapt, challenge, review ve rate-limit gibi sonuçlar kullanılır. Varsayılan olarak hiçbir şey enforce edilmez: politikayı gerçek trafik üzerinde preview edersiniz ve onu kendi kodunuzda route route enforce edersiniz.

Founding ekipler kanıtı Node.js middleware, Next.js, bir edge integration, onaylı sayfalarda bir browser collector, genel HTTP API veya bir MCP server integration ile toplayabilir. integrations bölümüne ve pratik adımlar için imzalı agent isteklerini doğrulama rehberine bakın.

Proof of Actor, standardın koyduğu sınırı takip eder: verified bir imza size isteği hangi anahtarın imzaladığını söyler, agent'in yetkili olup olmadığını değil. Yetkilendirme sizde kalır. kanıt ve sınırlar sayfası her sonucun tam olarak neyi destekleyip neyi desteklemediğini açıklar.

Başlarken

Proof of Actor private beta aşamasındadır. Seçilmiş founding developer ekipleri, kararlaştırılan kullanım sınırları içinde, otomatik faturalandırma olmadan 12 aya kadar ücretsiz erişim alabilir. Erken erişim için başvurun ve bize hangi route'larda imzalı agent'lar beklediğinizi ve onlarla ne yapmak istediğinizi anlatın.

GELİŞTİRİCİLER İÇİN

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record

{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}

class: Human, Human + AI, Agent veya Unknown.
basis: Kanıtın ne kadar güçlü olduğu: Verified, Declared, Inferred veya Unknown.
evidence: Sonucun arkasındaki sinyaller, böylece ekibiniz nedenini görebilir.

Gözlem modunda başlayın: sonuçları günlüklerinizin yanına kaydedin ve bir politika seçene kadar hiçbir şeyi değiştirmeyin. Node.js entegrasyon kılavuzunu okuyun

Sık sorulan sorular

Web Bot Auth nedir?

Web Bot Auth, bir IETF çalışma grubunun adı olan webbotauth ve standartlaştırdığı yaklaşımdır: otomatik istemciler HTTP Message Signatures (RFC 9421) ile HTTP isteklerini imzalar ve genel anahtarlarını yayımlar, böylece web siteleri bir isteği hangi operatörün gönderdiğini doğrulayabilir.

Web Bot Auth bitmiş bir standart mı?

Henüz değil. November 2026 itibarıyla ana protokol belgesi, draft-ietf-webbotauth-httpsig-protocol, revision 01 durumunda bir working group Internet-Draft'tır. Dayandığı imza formatı olan RFC 9421 ise yayımlanmış bir Proposed Standard'dır.

Geçerli bir Web Bot Auth imzası, agent'in işlem yapmasına izin verildiği anlamına mı gelir?

Hayır. Bu, isteği hangi anahtarın imzaladığını ve imzalanan bölümlerin değiştirilmediğini kanıtlar. O agent'in veri okuyup okuyamayacağı, bir form gönderip gönderemeyeceği ya da belirli bir kullanıcı adına işlem yapıp yapamayacağı, uygulamanızın vermesi gereken bir yetkilendirme kararıdır.

Ürün ekiplerinin Web Bot Auth'u kendilerinin uygulaması gerekir mi?

Siteler imzaları doğrular; otomatik istemci de çalıştırmıyorlarsa bir şey imzalamaları gerekmez. Doğrulama, anahtar dizinlerini çekmeyi, bunları güvenli biçimde önbelleğe almayı ve imzaları kontrol etmeyi içerir; Proof of Actor gibi bir araç bunu sizin için yapabilir.

İsteklerini imzalamayan agent'larla ne yapmalıyız?

Onları mevcut kanıta göre değerlendirin: declared, inferred veya Unknown. Bir süre signed ve unsigned trafiğin birlikte gelmesini bekleyin ve tek bir site geneli kural yerine her route için bir fallback belirleyin.

Proof of Actor Web Bot Auth'u nasıl kullanır?

HTTP Message Signatures'ı yayımlanan anahtar ile kontrol eder ve kontrol geçtiğinde sonucu verified basis ile raporlar. Böylece politikalarınız verified agent'ları declared veya Unknown trafikten farklı ele alabilir.

Uygulamanızı kimin kullandığını bilin.

Az sayıda founding developer için private beta.

Erken erişim alın Fiyatları görüntüle

Önce konuşmak mı istersiniz? Kurucularla konuşun