तुमच्या अॅपमध्ये Unknown ट्रॅफिक कसे हाताळायचे

Unknown ही चूक आहे की परिणाम?

तुम्ही जेव्हा interactions चे वर्गीकरण Human, Human + AI, Agent किंवा Unknown असे सुरू करता, तेव्हा Unknown bucket अनेकदा लोकांच्या अपेक्षेपेक्षा मोठा असतो. तो दडपण्यासाठीचा दरीसारखा वाटू शकतो, मग तो Unknown ला Human मध्ये मिसळून असो किंवा त्याला संशयास्पद मानून असो. दोन्ही पर्याय समस्या निर्माण करतात.

Unknown म्हणजे उपलब्ध evidence विश्वसनीय निर्धारणाला पाठबळ देत नाही. क्लायंटकडून आलेली अशी request जी JavaScript चालवत नाही, ज्या endpoint वर तुम्ही कोणतेही signals गोळा करत नाही, एका page नंतर संपलेली session: ही सगळी पूर्णपणे वैध असू शकतात, आणि यापैकी कोणतीही गोष्ट तुम्हाला नेमके कोण किंवा काय काम करत होते हे सांगण्यासाठी पुरेशी नसते.

Unknown ची प्रामाणिक नोंद ठेवणे हेच इतर वर्गांना विश्वसनीय ठेवते. जर तुमची system कधीच Unknown म्हणत नसेल, तर प्रत्येक Human परिणाम काही अंशी अंदाज असतो, आणि कोणता भाग आहे हे तुम्हाला कळत नाही. AI traffic चे वर्गीकरण करताना Unknown हा वैध परिणाम का आहे यावरील आमच्या post मध्ये यामागील reasoning अधिक सखोलपणे मांडले आहे.(/blog/why-unknown-is-a-valid-result-for-ai-traffic)

हा guide प्रत्यक्षात Unknown कसे हाताळायचे हे कव्हर करतो: explicit per-route fallbacks, त्याला इतर वर्गांत leak होऊ न देणारे नियम, त्यावर नजर कशी ठेवायची, आणि जिथे महत्त्व आहे तिथे तो कसा कमी करायचा.

पायरी 1: कधीही Human वर default करू नका

सर्वात सामान्य चूक म्हणजे अशी classification function जी automation signal न सापडल्यावर Human परत करते. ते वाजवी वाटते आणि ते चुकीचे आहे. 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" };
}

परिणाम निर्माण होतात त्या प्रत्येक ठिकाणी हाच नियम लागू करा: timeout, error, stale cache entries आणि missing telemetry या सगळ्यांमधून Unknown निर्माण झाले पाहिजे. या प्रत्येक path साठी test लिहा, जेणेकरून वर्तन शांतपणे मागे फिरू शकणार नाही. खालील उदाहरण 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 ला स्पष्ट fallback द्या

Unknown साठी निश्चित वर्तन हवे, आणि योग्य वर्तन route वर अवलंबून असते. ते route नुसार ठरवा, लिहून ठेवा, आणि configuration मध्ये ठेवा. हे fallback व्यापक policy model मध्ये कसे बसते ते पाहण्यासाठी मानवी आणि AI agents साठी app-level policies डिझाइन करणे पहा.

हा pattern सोपा आहे. कमी जोखमीच्या routes साठी Unknown सामान्य traffic प्रमाणे वागते. जास्त जोखमीच्या routes साठी Unknown ला route आधीपासून देत असलेलेच protection मिळते. दोन्ही परिस्थितीत actor result मुळे वर्गीकृत न झालेल्या पण वैध वापरकर्त्याला परिस्थिती वाईट होत नाही.

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 यांना एकाच प्रकारे हाताळा

Actor evaluation request path वर असते, त्यामुळे त्यासाठी कडक time budget असणे आवश्यक आहे. जेव्हा हा budget ओलांडला जातो, तेव्हा Unknown तयार करा आणि 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" });

परिणाम Unknown का आहे ते नोंदवा: evidence नाही, timeout, evaluation error किंवा stale evidence. ही कारणे तुम्हाला काय दुरुस्त करायचे आहे ते सांगतात.

पायरी 4: Unknown ला संशयास्पद मानू नका

Unknown हा risk score नाही. अनेक वैध 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 द्वारे देतात. उदाहरणार्थ, OpenAI's crawler documentation नोव्हेंबर 2026 पर्यंत त्यांच्या प्रत्येक bot साठी एक user agent string आणि प्रकाशित IP address file सूचीबद्ध करते.

जर तुम्हाला संशयास्पद वर्तनावर कृती करायची असेल, तर request rates, failed login patterns किंवा abuse reports यांसारख्या वर्णन करता येणाऱ्या वर्तनावर आधारित करा, आणि त्यासाठी स्वतःचे evidence ठेवा. हे logic actor class पासून वेगळे ठेवा, जेणेकरून एक दुसऱ्याला विकृत करणार नाही.

पायरी 5: तुमचा unknown rate कसा monitor करायचा?

Unknown rate म्हणजे Unknown म्हणून वर्गीकृत झालेल्या interactions चा हिस्सा. तो route नुसार, integration context नुसार आणि कालांतराने ट्रॅक करा. तुमच्याकडे असलेल्या सर्वात उपयुक्त 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 मध्ये काहीतरी बदलले आहे याचा अर्थ असतो, उदाहरणार्थ header काढून टाकणारा release, signature headers काढून टाकणारा CDN rule, किंवा तुमच्या app च्या declarations पाठवणे थांबवणारा frontend बदल.
• अचानक घट देखील तपासण्यासारखी असते. जर Unknown कमी झाले आणि Human वाढले, तर नवीन evidence आले आहे याची खात्री करा, फक्त fallback शांतपणे बदलला आहे असे गृहित धरू नका.

अचानक बदलांवर alert द्या, absolute स्तरांवर नाही. प्रत्येक application ची स्वतःची normal स्थिती असते.

पायरी 6: जिथे महत्त्व आहे तिथे Unknown कसा कमी करायचा?

तुम्हाला Unknown शून्यावर नेण्याची गरज नाही. ज्या routes वर निर्णय महत्त्वाचे आहेत तिथे पुरेसे evidence हवे. impact च्या क्रमाने त्यावर काम करा:

1. उच्च-प्रभाव routes वर आधी evidence जोडा. जर account changes बहुतेक Unknown असतील, तर browser integration किंवा server-side check तिथेच सर्वाधिक उपयोगी ठरते.
2. स्वयंचलित clients ना स्वतःची ओळख द्यायला प्रवृत्त करा. तुमच्या API साठी दस्तऐवजीकरण प्रकाशित करा जे agents HTTP Message Signatures आणि IETF Web Bot Auth conventions वापरून requests कशा sign करू शकतात हे समजावते, आणि verified clients ना चांगला अनुभव द्या, जसे उच्च limits किंवा structured responses. ज्या clients ना verify करता येते ते तसे करू लागतील.
3. तुमचे स्वतःचे application ज्ञान वापरा. जर users तुमच्या built-in assistant सोबत संवाद साधत असतील, तर ते declaration म्हणून नोंदवा. नेटवर्कपेक्षा तुमच्या app ला अनेकदा अधिक माहिती असते.
4. plumbing दुरुस्त करा. proxies तुम्ही अवलंबून असलेले headers forward करतात याची खात्री करा आणि evaluation ला पूर्ण होण्यासाठी पुरेसा time budget मिळतो याची खात्री करा.

Unknown मधून traffic बाहेर नेणाऱ्या signals चा व्यावहारिक आढावा घेण्यासाठी website traffic AI agents कडून येतो का हे कसे ओळखायचे वाचा.

पायरी 7: dashboards मध्ये Unknown प्रामाणिकपणे दाखवा

Unknown ला इतर वर्गांइतक्याच visual weight सह स्वतंत्र series म्हणून दर्शवा. त्याला "other" bucket मध्ये लपवू नका, आणि alert सारखा रंग देऊ नका. Stakeholders ना जेव्हा मोठा Unknown हिस्सा दिसतो, तेव्हा योग्य प्रतिक्रिया "आम्हाला आणखी कुठे evidence हवे" अशी असते, "bots कुठे आहेत" अशी नाही.

पायरी 8: assumptions नव्हे, outcomes सह Unknown चे review करा

दर काही आठवड्यांनी, तुमच्या सर्वात महत्त्वाच्या routes मधील Unknown interactions चा sample घ्या आणि प्रत्यक्षात काय झाले ते पहा. session ने खरेदी पूर्ण केली का, project तयार झाला का, तीन articles वाचले का, की login वर वारंवार अपयश आले? Outcomes तुम्हाला bucket मध्ये कोणत्या प्रकारचा traffic आहे हे सांगतात, त्यावर लवकर label लादल्याशिवाय.

तुम्हाला जे आढळते ते तीन practical categories मध्ये गटबद्ध करा:

1. वैध आणि कमी जोखीम. Feed readers, link previews, monitoring tools आणि privacy settings असलेली माणसे. route fallback जसाच्या तसा ठेवा.
2. वैध automation जी स्वतःची ओळख देऊ शकते. अशी integrations आणि agents जे तुम्ही structured path किंवा requests sign करण्याचा मार्ग दिलात तर आनंदाने वापरतील. मार्गदर्शन प्रकाशित करा आणि शक्य तिथे संपर्क साधा.
3. स्वतःचे control मागणारे वर्तन. Credential stuffing किंवा scraping patterns, जे दोन्ही OWASP Automated Threats to Web Applications project मध्ये नोंदलेले आहेत. हे behavior-based controls वापरून हाताळा ज्यांच्याकडे स्वतःचे evidence असते, जसे login failure rates, आणि त्यांना actor class पासून वेगळे ठेवा.

हे review तुमचे fallbacks प्रत्यक्ष traffic मध्ये grounded ठेवते आणि evidence पुढे कुठे जोडायचे याची स्पष्ट यादी देते.

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

Unknown ला rate limits मध्ये धरायचे का? तुमचे standard limits वापरा. class नुसार rate limiting verified agents साठी ठीक आहे, कारण त्यांना उच्च limits मिळू शकतात, पण Unknown ला सामान्य limit मिळायला हवी, दंडात्मक नाही.

आपण Unknown users ला challenge करू शकतो का? फक्त जिथे route आधीपासून त्या परिस्थितीत सर्वांना challenge करते तिथेच. एखादा result Unknown आहे म्हणून केवळ challenge जोडणे कमी signals पाठवणाऱ्या वैध users ला दंड देते.

Standards परिपक्व झाल्यावर Unknown कमी होईल का? अधिक स्वयंचलित clients requests sign करू लागल्यावर, अधिक agent traffic Unknown किंवा declared मधून verified मध्ये जाते. तुमचे monitoring हा बदल route नुसार दाखवेल.

Proof of Actor कुठे बसते

Proof of Actor Unknown ला first-class परिणाम म्हणून, कारणासह, दर्शवते आणि त्याला कधीही Human मध्ये रूपांतरित करत नाही. तुमचे application प्रत्येक route साठी fallback निवडते, आणि analytics coverage कुठे संपते ते दाखवतात, जेणेकरून जिथे महत्त्व आहे तिथे तुम्ही evidence जोडू शकता.

हे production application वर आमच्या टीमसोबत सेट अप करण्यासाठी, early access साठी अर्ज करा. evidence ने नेमके काय स्थापित करता येते हे समजून घेण्यासाठी, Detection & Limitations वाचा.

स्रोत

• RFC 9421: HTTP Message Signatures: automated clients requests sign करण्यासाठी वापरू शकणारा standard
• 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 आणि प्रकाशित IP address files
• OWASP Automated Threats to Web Applications: credential stuffing आणि scraping यांसारख्या automated threats चे taxonomy
• Node.js test runner: उदाहरणात वापरलेला node:test module