अपने ऐप में Unknown ट्रैफ़िक को कैसे संभालें

क्या Unknown एक error है या एक result?

जब आप interactions को Human, Human + AI, Agent या Unknown के रूप में classify करना शुरू करते हैं, तो Unknown bucket अक्सर लोगों की अपेक्षा से बड़ा होता है. इसे छिपाने के लिए gap की तरह treat करना आसान लगता है, चाहे Unknown को Human में मिला दिया जाए या उसे suspicious मान लिया जाए. दोनों विकल्प समस्याएँ पैदा करते हैं.

Unknown का मतलब है कि उपलब्ध evidence किसी भरोसेमंद determination का समर्थन नहीं करता. ऐसे client से आया request जो कोई JavaScript नहीं चलाता, ऐसे endpoint पर call जहाँ आप कोई signals नहीं जुटाते, या ऐसा session जो एक page के बाद समाप्त हो गया: ये सभी बिल्कुल वैध हो सकते हैं, और इनमें से कोई भी आपको यह कहने के लिए पर्याप्त नहीं देता कि कौन या क्या act कर रहा था.

Unknown को ईमानदारी से report करना ही बाकी classes को trustworthy बनाए रखता है. अगर आपका system कभी Unknown नहीं कहता, तो हर Human result आंशिक रूप से एक guess होता है, और आप यह नहीं बता सकते कि कौन-सा हिस्सा. AI traffic को classify करते समय Unknown एक valid result क्यों है, इस पर हमारा post (/blog/why-unknown-is-a-valid-result-for-ai-traffic) और गहराई से reasoning बताता है.

यह guide बताती है कि व्यवहार में Unknown को कैसे संभालें: explicit per-route fallbacks, वे rules जो इसे दूसरी classes में leak होने से रोकते हैं, इसे कैसे monitor करें, और जहाँ ज़रूरत हो वहाँ इसे कैसे कम करें.

चरण 1: कभी भी Human पर default न करें

सबसे आम गलती ऐसी classification function है जो automation signal न मिलने पर Human return कर देती है. यह reasonable लगता है और गलत है. bot signal का न होना human signal का होना नहीं है.

// 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" };
}

जहाँ भी results generate होते हैं, वही नियम लागू करें: timeout, error, stale cache entries और missing telemetry, सभी Unknown produce करें. इन हर path के लिए test लिखें ताकि व्यवहार quietly regress न हो सके. नीचे दिया गया example built-in Node.js test runner का उपयोग करता है.

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");
});

चरण 2: हर route को एक explicit fallback दें

Unknown के लिए परिभाषित behavior चाहिए, और सही behavior route पर निर्भर करता है. इसे route के स्तर पर तय करें, लिखकर रखें, और configuration में बनाए रखें. ये fallbacks broader policy model में कैसे fit होते हैं, इसके लिए humans और AI agents के लिए app-level policies design करना देखें.

Pattern सरल है. कम risk वाले routes पर Unknown सामान्य traffic की तरह behave करता है. अधिक risk वाले routes पर Unknown को वही protection मिलती है जो route के पास पहले से है. दोनों ही मामलों में actor result किसी unclassified लेकिन legitimate user के लिए स्थिति को खराब नहीं करता.

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",
};

चरण 3: timeout और error को एक ही तरह से treat करें

Actor evaluation request path पर sit करती है, इसलिए उसके पास सख्त time budget होना चाहिए. जब budget पार हो जाए, Unknown produce करें और route fallback लागू करें. Evaluation धीमी होने पर request को कभी block न करें.

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" });

यह रिकॉर्ड करें कि result Unknown क्यों है: no evidence, timeout, evaluation error या stale evidence. ये reasons बताते हैं कि आपको क्या ठीक करना है.

चरण 4: Unknown को suspicious न मानें

Unknown कोई risk score नहीं है. कई legitimate clients कुछ routes पर हमेशा Unknown रहेंगे: command-line tools, बिना signatures वाले server-side integrations, accessibility tools, privacy-focused browsers और सरल feed readers. आज बड़े AI operators भी अपने fetchers को ज़्यादातर user agent और published IP ranges से identify करते हैं. उदाहरण के लिए, OpenAI की crawler documentation नवंबर 2026 तक अपने प्रत्येक bot के लिए एक user agent string और एक published IP address file सूचीबद्ध करती है.

अगर आप suspicious behavior पर action लेना चाहते हैं, तो उसे उस behavior पर आधारित करें जिसे आप describe कर सकते हैं, जैसे request rates, failed login patterns या abuse reports, और उसके लिए अपना अलग evidence रखें. उस logic को actor class से अलग रखें ताकि दोनों एक-दूसरे को distort न करें.

चरण 5: आप अपनी Unknown rate को कैसे monitor करते हैं?

Unknown rate उन interactions का हिस्सा है जिन्हें Unknown classify किया गया है. इसे route के अनुसार, integration context के अनुसार और समय के साथ track करें. यह आपके पास मौजूद सबसे उपयोगी health metrics में से एक है.

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 }));
}

संख्याएँ आपको यह बताती हैं:

• किसी route पर उच्च, स्थिर rate आम तौर पर मतलब है कि वहाँ कोई signal छूट रहा है. ऐसा page जो आपकी browser integration कभी लोड नहीं करता, या ऐसा API जो कभी signed requests नहीं देखता, वह ज़्यादातर Unknown ही रहेगा.
• अचानक बढ़ोतरी अक्सर बताती है कि आपके stack में कुछ बदल गया है, उदाहरण के लिए ऐसा release जिसने header हटा दिया, ऐसी CDN rule जो signature headers strip कर देती है, या ऐसा frontend change जिसने आपकी app की declarations भेजना बंद कर दिया.
• अचानक गिरावट भी जाँचने लायक है. अगर Unknown गिरता है जबकि Human बढ़ता है, तो पुष्टि करें कि नया evidence आया है, न कि कोई fallback quietly बदल गया है.

तेज़ बदलावों पर alert करें, absolute levels पर नहीं. हर application का अपना normal होता है.

चरण 6: जहाँ मायने रखता है वहाँ Unknown को कैसे कम करें?

आपको Unknown को zero तक ले जाने की ज़रूरत नहीं है. आपको उन routes पर पर्याप्त evidence चाहिए जहाँ decisions महत्वपूर्ण हैं. प्रभाव के क्रम में इन पर काम करें:

1. उच्च-impact routes पर पहले evidence जोड़ें. अगर account changes ज़्यादातर Unknown हैं, तो वहीं browser integration या server-side check सबसे अधिक उपयोगी होगा.
2. Automated clients को खुद को identify करने के लिए आमंत्रित करें. अपनी API के लिए documentation publish करें जो बताए कि agents HTTP Message Signatures और IETF Web Bot Auth conventions के साथ requests कैसे sign कर सकते हैं, और verified clients को बेहतर experience दें, जैसे higher limits या structured responses. जो clients verify कर सकते हैं, वे ऐसा करना शुरू करेंगे.
3. अपने application ज्ञान का उपयोग करें. अगर users आपके built-in assistant के साथ interact करते हैं, तो उसे declaration के रूप में record करें. आपका app अक्सर network से ज़्यादा जानता है.
4. Plumbing ठीक करें. सुनिश्चित करें कि proxies वे headers forward करें जिन पर आप निर्भर हैं, और evaluation के पास पूरा होने के लिए पर्याप्त time budget हो.

Unknown से traffic को बाहर निकालने वाले signals पर व्यावहारिक नज़र के लिए, कैसे पता करें कि website traffic AI agents से आता है पढ़ें.

चरण 7: Dashboards में Unknown को ईमानदारी से दिखाएँ

Unknown को अपनी अलग series के रूप में दिखाएँ, और उसे अन्य classes के बराबर visual weight दें. इसे "other" bucket में न छिपाएँ, और न ही alert जैसी रंग-योजना दें. जब stakeholders बड़ा Unknown share देखते हैं, तो सही प्रतिक्रिया होती है "हमें और evidence कहाँ चाहिए", न कि "bots कहाँ हैं".

चरण 8: Assumptions नहीं, outcomes के साथ Unknown की समीक्षा करें

हर कुछ हफ्तों में, अपने सबसे महत्वपूर्ण routes से Unknown interactions का एक sample लें और देखें कि वास्तव में क्या हुआ. क्या session ने purchase पूरा किया, project बनाया, तीन articles पढ़े, या login पर बार-बार fail हुआ? Outcomes आपको बताते हैं कि bucket में किस तरह का traffic है, बिना उस पर जल्दबाज़ी में label लगाए.

जो आप पाते हैं, उसे तीन practical categories में बाँटें:

1. Legitimate और low risk. Feed readers, link previews, monitoring tools और privacy settings वाले लोग. Route fallback जैसा है वैसा रखें.
2. Legitimate automation जो खुद को identify कर सकती है. Integrations और agents जो structured path का उपयोग करेंगे या requests sign करेंगे, अगर आप उन्हें ऐसा विकल्प दें. Guidance publish करें और जहाँ संभव हो संपर्क करें.
3. ऐसा behavior जिसे अपने control की ज़रूरत है. Credential stuffing या scraping patterns, दोनों को OWASP Automated Threats to Web Applications project में catalogued किया गया है. इन्हें behavior-based controls से address करें जिनका अपना evidence हो, जैसे login failure rates, और इन्हें actor class से अलग रखें.

यह review आपके fallbacks को वास्तविक traffic से जोड़े रखता है और आपको evidence जोड़ने के अगले स्थानों की स्पष्ट सूची देता है.

सामान्य प्रश्न

क्या Unknown को rate limits में count करना चाहिए? अपने standard limits का उपयोग करें. Verified agents के लिए class के आधार पर rate limiting ठीक है, क्योंकि वे higher limits कमा सकते हैं, लेकिन Unknown को सामान्य limit मिलनी चाहिए, punitive limit नहीं.

क्या हम Unknown users को challenge कर सकते हैं? केवल वहाँ जहाँ route पहले से ही उस स्थिति में सभी को challenge करता है. केवल इसलिए challenge जोड़ना कि result Unknown है, legitimate users को दंडित करता है जिनके clients कम signals भेजते हैं.

क्या standards mature होने पर Unknown कम होगा? जैसे-जैसे अधिक automated clients requests sign करेंगे, अधिक agent traffic Unknown या declared से verified की ओर जाएगा. आपका monitoring यह बदलाव route दर route दिखाएगा.

Proof of Actor कहाँ fit होता है

Proof of Actor Unknown को first-class result के रूप में, कारण के साथ report करता है, और उसे कभी Human में convert नहीं करता. आपका application हर route के लिए fallback चुनता है, और analytics दिखाते हैं कि coverage कहाँ समाप्त होती है ताकि आप जहाँ ज़रूरत हो वहाँ evidence जोड़ सकें.

हमारी team के साथ production application पर यह setup करने के लिए, early access के लिए apply करें. यह समझने के लिए कि evidence वास्तव में क्या स्थापित कर सकता है, Detection & Limitations पढ़ें.

स्रोत

• RFC 9421: HTTP Message Signatures: वह standard जिसका उपयोग automated clients requests sign करने के लिए कर सकते हैं
• draft-ietf-webbotauth-httpsig-protocol: signed automated traffic के लिए IETF Web Bot Auth draft (नवंबर 2026 तक work in progress)
• OpenAI: Overview of OpenAI Crawlers: OpenAI के bots के लिए user agent strings और published IP address files
• OWASP Automated Threats to Web Applications: credential stuffing और scraping जैसे automated threats की taxonomy
• Node.js test runner: उदाहरण में उपयोग किया गया node:test module