Uygulamanızda Unknown trafiği nasıl ele alınır

Unknown bir hata mı, yoksa bir sonuç mu?

Etkileşimleri Human, Human + AI, Agent veya Unknown olarak sınıflandırmaya başladığınızda, Unknown havuzu çoğu zaman insanların beklediğinden daha büyük olur. Bunu saklanması gereken bir boşluk gibi görmek, ya Unknown'u Human içine katlayarak ya da onu şüpheli sayarak cazip gelebilir. İki yaklaşım da sorun yaratır.

Unknown, mevcut kanıtın güvenilir bir belirlemeyi desteklemediği anlamına gelir. Hiç JavaScript çalıştırmayan bir istemciden gelen istek, hiçbir sinyal toplamadığınız bir endpoint'e yapılan çağrı, tek bir sayfadan sonra sona eren bir oturum: bunların hepsi tamamen meşru olabilir ve hiçbiri size kim ya da neyin hareket ettiğini söylemeye yetecek kadar veri vermez.

Unknown'u dürüstçe raporlamak, diğer sınıfları güvenilir tutan şeydir. Sisteminiz hiç Unknown demiyorsa, her Human sonucu kısmen bir tahmindir ve hangi kısmın öyle olduğunu anlayamazsınız. AI trafiğini sınıflandırırken Unknown neden geçerli bir sonuçtur başlıklı yazımız bu gerekçeyi daha ayrıntılı açıklar.

Bu kılavuz, pratikte Unknown'u nasıl ele alacağınızı kapsar: rota bazında açık yedek davranışlar, bunun diğer sınıflara sızmasını önleyen kurallar, bunu nasıl izleyeceğiniz ve önemli olduğu yerlerde nasıl azaltacağınız.

Adım 1: Varsayılanı asla Human yapmayın

En yaygın hata, hiçbir otomasyon sinyali bulamadığında Human döndüren bir sınıflandırma fonksiyonudur. Makul görünür ve yanlıştır. Bot sinyalinin olmaması, insan sinyalinin var olduğu anlamına gelmez.

// Wrong: silence becomes Human
function classifyWrong(e: Evidence) {
  if (e.signatureValid) return { actor: "agent", basis: "verified" };
  if (e.declaredAgent) return { actor: "agent", basis: "declared" };
  return { actor: "human", basis: "inferred" };
}

// Right: Human requires positive evidence, otherwise Unknown
function classify(e: Evidence) {
  if (e.signatureValid) return { actor: "agent", basis: "verified" };
  if (e.declaredAgent) return { actor: "agent", basis: "declared" };
  if (e.interactiveSession) return { actor: "human", basis: "inferred" };
  return { actor: "unknown", basis: "unknown" };
}

Sonuçların üretildiği her yerde aynı kuralı uygulayın: zaman aşımı, hata, eski önbellek girdileri ve eksik telemetri hepsi Unknown üretmelidir. Bu yolların her biri için bir test yazın ki davranış sessizce geriye gitmesin. Aşağıdaki örnek, yerleşik Node.js test runner kullanır.

import { test } from "node:test";
import assert from "node:assert/strict";

test("missing evidence is unknown, not human", () => {
  const r = classify({ signatureValid: false, declaredAgent: false, interactiveSession: false });
  assert.equal(r.actor, "unknown");
});

Adım 2: Her rotaya açık bir yedek davranış verin

Unknown için tanımlı bir davranış gerekir ve doğru davranış rotaya bağlıdır. Bunu rota bazında kararlaştırın, yazılı hale getirin ve konfigürasyonda tutun. Bu yedek davranışların daha geniş bir politika modeline nasıl oturduğu için uygulama düzeyinde insan ve yapay zeka ajanları için politika tasarlama bölümüne bakın.

Kalıp basittir. Düşük riskli rotalarda Unknown normal trafik gibi davranır. Yüksek riskli rotalarda Unknown, rotanın zaten sahip olduğu korumayı alır. Her iki durumda da actor sonucu, sınıflandırılmamış ama meşru bir kullanıcı için durumu kötüleştirmez.

type Fallback = "allow" | "standard_limit" | "existing_checks" | "review";

const unknownFallback: Record<string, Fallback> = {
  "GET /docs/*": "allow",
  "GET /api/catalog": "standard_limit",
  "POST /signup": "existing_checks",
  "POST /account/password": "existing_checks",
  "POST /exports": "review",
};

Adım 3: Zaman aşımı ve hataları aynı şekilde ele alın

Actor değerlendirmesi request yolunda yer alır, bu yüzden sıkı bir zaman bütçesi olmalıdır. Bütçe aşıldığında Unknown üretin ve rota yedeğini uygulayın. Değerlendirme yavaş olduğu için bir request'i asla engellemeyin.

async function withBudget<T>(work: Promise<T>, ms: number, onTimeout: T): Promise<T> {
  let timer: NodeJS.Timeout;
  const timeout = new Promise<T>((resolve) => {
    timer = setTimeout(() => resolve(onTimeout), ms);
  });
  try {
    return await Promise.race([work, timeout]);
  } finally {
    clearTimeout(timer!);
  }
}

const result = await withBudget(evaluateActor(req), 150, { actor: "unknown", basis: "unknown" });

Bir sonucun neden Unknown olduğunu kaydedin: kanıt yok, zaman aşımı, değerlendirme hatası veya eski kanıt. Bu nedenler neyi düzeltmeniz gerektiğini söyler.

Adım 4: Unknown'u şüpheli saymayın

Unknown bir risk skoru değildir. Birçok meşru istemci bazı rotalarda her zaman Unknown olacaktır: komut satırı araçları, imza olmayan sunucu tarafı entegrasyonlar, erişilebilirlik araçları, gizliliğe odaklanan tarayıcılar ve basit feed reader'lar. Büyük AI operatörleri bile bugün fetcher'larını çoğunlukla user agent ve yayımlanmış IP aralıklarıyla tanımlar. Örneğin, OpenAI's crawler documentation, Kasım 2026 itibarıyla botlarının her biri için bir user agent string ve yayımlanmış bir IP adresi dosyası listeler.

Şüpheli davranışa tepki vermek istiyorsanız, bunu request oranları, başarısız login kalıpları veya abuse raporları gibi tanımlayabildiğiniz davranışlara dayandırın ve bunun için kendi kanıtınızı kullanın. Bu mantığı actor sınıfından ayrı tutun ki biri diğerini bozmasın.

Adım 5: Unknown oranınızı nasıl izlersiniz?

Unknown oranı, Unknown olarak sınıflandırılan etkileşimlerin payıdır. Bunu rota bazında, entegrasyon bağlamı bazında ve zaman içinde takip edin. Elinizdeki en yararlı sağlık metriklerinden biridir.

type Row = { route: string; actor: string };

export function unknownRate(rows: Row[]) {
  const byRoute = new Map<string, { total: number; unknown: number }>();
  for (const r of rows) {
    const s = byRoute.get(r.route) ?? { total: 0, unknown: 0 };
    s.total += 1;
    if (r.actor === "unknown") s.unknown += 1;
    byRoute.set(r.route, s);
  }
  return [...byRoute].map(([route, s]) => ({ route, rate: s.unknown / s.total, total: s.total }));
}

Sayıların ne anlattığı:

• Bir rotada yüksek ve istikrarlı oran genellikle orada bir sinyal eksik olduğunu gösterir. Browser entegrasyonunuzu hiç yüklemeyen bir sayfa ya da signed request hiç görmeyen bir API çoğunlukla Unknown kalır.
• Ani bir artış çoğu zaman stack'inizde bir şeylerin değiştiği anlamına gelir. Örneğin header düşüren bir sürüm, signature header'larını silen bir CDN kuralı veya uygulamanızın beyanlarını göndermeyi durduran bir frontend değişikliği.
• Ani bir düşüş de kontrol edilmeye değerdir. Unknown düşerken Human artıyorsa, sessizce değişen bir yedek davranış yerine yeni bir kanıtın gelip gelmediğini doğrulayın.

Mutlak seviyeler için değil, keskin değişimler için alarm kurun. Her uygulamanın kendine özgü normali vardır.

Adım 6: Unknown'u önemli olduğu yerlerde nasıl azaltırsınız?

Unknown'u sıfıra indirmeniz gerekmez. Kararın önemli olduğu rotalarda yeterli kanıta ihtiyacınız vardır. Bunları etki sırasına göre ele alın:

1. Önce yüksek etkili rotalara kanıt ekleyin. Hesap değişiklikleri çoğunlukla Unknown ise, browser entegrasyonu ya da sunucu tarafı kontrolün karşılığını en çok verdiği yer orasıdır.
2. Otomatik istemcileri kendilerini tanıtmaya teşvik edin. API'niz için, ajanların request'leri HTTP Message Signatures ve IETF Web Bot Auth conventions ile nasıl imzalayabileceğini açıklayan dokümantasyon yayınlayın ve verified istemcilere daha iyi bir deneyim sunun. Örneğin daha yüksek limitler veya yapılandırılmış yanıtlar. Doğrulanabilen istemciler bunu yapmaya başlayacaktır.
3. Kendi uygulama bilginizi kullanın. Kullanıcılar yerleşik asistanınızla etkileşime giriyorsa, bunu bir declaration olarak kaydedin. Uygulamanız çoğu zaman ağın bildiğinden fazlasını bilir.
4. Altyapıyı düzeltin. Proxy'lerin güvendiğiniz header'ları ilettiğinden ve değerlendirme işleminin tamamlanması için yeterli zaman bütçesine sahip olduğundan emin olun.

Trafiği Unknown dışına çıkaran sinyallere pratik bir bakış için web sitesi trafiğinin AI agent'lardan gelip gelmediği nasıl anlaşılır yazısını okuyun.

Adım 7: Dashboard'larda Unknown'u dürüstçe gösterin

Unknown'u, diğer sınıflarla aynı görsel ağırlıkta ayrı bir seri olarak gösterin. Bunu bir "other" kovasının içine gizlemeyin ve alarm gibi renklendirmeyin. Paydaşlar büyük bir Unknown payı gördüğünde doğru tepki "nerede daha fazla kanıta ihtiyacımız var" olmalıdır, "botlar nerede" değil.

Adım 8: Unknown'u varsayımlarla değil, sonuçlarla gözden geçirin

Birkaç haftada bir, en önemli rotalarınızdan bir örnek Unknown etkileşimi alın ve gerçekte ne olduğunu inceleyin. Oturum bir satın alma ile mi tamamlandı, bir proje mi oluşturdu, üç makale mi okudu, yoksa girişte tekrar tekrar mı başarısız oldu? Sonuçlar, üzerine erken bir etiket zorlamadan, bu kovada ne tür trafik olduğunu gösterir.

Bulduklarınızı üç pratik kategoriye ayırın:

1. Meşru ve düşük riskli. Feed reader'lar, link preview'leri, izleme araçları ve gizlilik ayarları olan kişiler. Rota yedeğini olduğu gibi bırakın.
2. Kendini tanıtabilen meşru otomasyon. Yapılandırılmış bir yolu memnuniyetle kullanacak veya bir seçenek sunarsanız request'leri imzalayacak entegrasyonlar ve ajanlar. Yönerge yayınlayın ve mümkün olan yerlerde iletişime geçin.
3. Kendi kontrolünü gerektiren davranış. Kimlik bilgisi doldurma veya scraping kalıpları, ikisi de OWASP Automated Threats to Web Applications projesinde kataloglanmıştır. Bunları, örneğin login başarısızlık oranları gibi kendi kanıtına sahip davranış tabanlı kontrollerle ele alın ve actor sınıfından ayrı tutun.

Bu gözden geçirme, yedek davranışlarınızı gerçek trafiğinize dayandırır ve bir sonraki kanıtı nereye eklemeniz gerektiğine dair net bir liste verir.

Sık sorulan sorular

Unknown rate limit'lere dahil edilmeli mi? Standart limitlerinizi kullanın. Sınıfa göre rate limiting, daha yüksek limitler kazanabilen verified agent'lar için uygundur, ancak Unknown cezalandırıcı değil, normal limiti almalıdır.

Unknown kullanıcıları challenge edebilir miyiz? Yalnızca rota zaten o durumda herkesi challenge ediyorsa. Sadece sonuç Unknown olduğu için challenge eklemek, istemcileri daha az sinyal gönderen meşru kullanıcıları cezalandırır.

Standartlar olgunlaştıkça Unknown küçülür mü? Daha fazla otomatik istemci request'leri imzaladıkça, daha fazla agent trafiği Unknown veya declared durumundan verified durumuna geçer. İzlemeniz bu değişimi rota bazında gösterecektir.

Proof of Actor burada nereye oturur?

Proof of Actor, Unknown'u birinci sınıf bir sonuç olarak, nedeni ile birlikte raporlar ve onu asla Human'a dönüştürmez. Uygulamanız her rota için yedek davranışı seçer ve analitik, kapsamanın nerede bittiğini gösterir, böylece önemli olan yerde kanıt ekleyebilirsiniz.

Bunu ekibimizle üretim ortamındaki bir uygulamada kurmak için erken erişim için başvurun. Kanıtın tam olarak neyi ortaya koyabildiğini anlamak için Detection & Limitations bölümünü okuyun.

Kaynaklar

• RFC 9421: HTTP Message Signatures: otomatik istemcilerin request'leri imzalamak için kullanabileceği standart
• draft-ietf-webbotauth-httpsig-protocol: imzalı otomatik trafik için IETF Web Bot Auth taslağı (Kasım 2026 itibarıyla çalışma aşamasında)
• OpenAI: Overview of OpenAI Crawlers: OpenAI botları için user agent string'leri ve yayımlanmış IP adresi dosyaları
• OWASP Automated Threats to Web Applications: credential stuffing ve scraping gibi otomatik tehditlerin taksonomisi
• Node.js test runner: örnekte kullanılan node:test modülü