আপনার অ্যাপে Unknown ট্র্যাফিক কীভাবে সামলাবেন

Unknown কি একটি error, নাকি একটি result?

যখন আপনি interaction-গুলোকে Human, Human + AI, Agent বা Unknown হিসেবে শ্রেণিবদ্ধ করা শুরু করেন, তখন Unknown bucket অনেক সময় মানুষের প্রত্যাশার চেয়ে বড় হয়। এটিকে লুকিয়ে ফেলার মতো একটি gap হিসেবে ধরতে ইচ্ছে হতে পারে, হয় Unknown-কে Human-এর সঙ্গে মিশিয়ে, নয়তো এটিকে সন্দেহজনক ধরে। এই দুই সিদ্ধান্তই সমস্যা তৈরি করে।

Unknown-এর মানে হলো উপলব্ধ evidence কোনো নির্ভরযোগ্য সিদ্ধান্তকে সমর্থন করছে না। এমন একটি client থেকে আসা request যা কোনো JavaScript চালায় না, এমন একটি endpoint-এ call যেখানে আপনি কোনো signal সংগ্রহ করেন না, এমন একটি session যা এক page-এর পরেই শেষ হয়ে গেছে: এগুলোর সবই সম্পূর্ণ বৈধ হতে পারে, এবং এগুলোর কোনোটিই আপনাকে who বা what কাজ করছিল তা বলার মতো যথেষ্ট তথ্য দেয় না।

Unknown-কে সৎভাবে report করাই অন্য class-গুলোকে trustworthy রাখে। আপনার system যদি কখনও Unknown না বলে, তাহলে প্রতিটি Human result আংশিকভাবে একটি অনুমান হয়ে যায়, এবং কোন অংশটি অনুমান তা আপনি বুঝতে পারবেন না। AI traffic শ্রেণিবদ্ধ করার সময় Unknown কেন একটি valid result, তা নিয়ে আমাদের লেখা why Unknown is a valid result when classifying AI traffic এই যুক্তি আরও গভীরভাবে ব্যাখ্যা করে।

এই guide-এ বাস্তবে Unknown কীভাবে handle করতে হয় তা কভার করা হয়েছে: স্পষ্ট per-route fallback, এটিকে অন্য class-এ ছড়িয়ে পড়া থেকে রোধ করার নিয়ম, কীভাবে এটি monitor করতে হয়, এবং যেখানে গুরুত্বপূর্ণ সেখানে কীভাবে এটি কমাতে হয়।

ধাপ 1: কখনও ডিফল্টভাবে Human ধরবেন না

সবচেয়ে সাধারণ ভুল হলো এমন একটি 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 entry এবং 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-গুলো কীভাবে wider policy model-এ বসে, তা জানতে designing app-level policies for humans and AI agents দেখুন।

প্যাটার্নটি সহজ। কম ঝুঁকির route-এ Unknown সাধারণ traffic-এর মতো আচরণ করে। বেশি ঝুঁকির route-এ Unknown সেই একই protection পায় যা route-এর already আছে। এই দুই ক্ষেত্রের কোনোটিতেই actor result কোনো unclassified কিন্তু বৈধ 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-কে একইভাবে দেখুন

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

কোন কারণে result Unknown হলো তা record করুন: no evidence, timeout, evaluation error, বা stale evidence। এই কারণগুলো আপনাকে কী ঠিক করতে হবে তা জানায়।

ধাপ 4: Unknown-কে সন্দেহজনক বলে ধরবেন না

Unknown কোনো risk score নয়। অনেক বৈধ client নির্দিষ্ট route-এ সব সময়ই Unknown হবে: command-line tool, server-side integration যেখানে signature নেই, accessibility tool, privacy-focused browser, এবং simple feed reader। এমনকি বড় AI operator-রাও আজকাল তাদের fetcher-গুলোকে মূলত user agent এবং প্রকাশিত IP range দিয়ে চিহ্নিত করে। উদাহরণ হিসেবে, OpenAI's crawler documentation নভেম্বর 2026 পর্যন্ত প্রতিটি bot-এর জন্য একটি user agent string এবং একটি প্রকাশিত IP address file তালিকাভুক্ত করে।

আপনি যদি সন্দেহজনক আচরণের ওপর action নিতে চান, তাহলে তা এমন আচরণের ওপর ভিত্তি করুন যা আপনি বর্ণনা করতে পারেন, যেমন request rate, failed login pattern, বা abuse report, এবং তার জন্য আলাদা evidence রাখুন। এই logic-কে actor class থেকে আলাদা রাখুন, যাতে কোনোটিই অন্যটিকে বিকৃত না করে।

ধাপ 5: আপনার unknown rate কীভাবে monitor করবেন?

Unknown rate হলো Unknown হিসেবে শ্রেণিবদ্ধ interaction-এর অংশ। এটি route অনুযায়ী, integration context অনুযায়ী, এবং সময়ের সঙ্গে ট্র্যাক করুন। এটি আপনার সবচেয়ে উপযোগী health metric-গুলোর একটি।

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 request দেখে না, সেটি বেশিরভাগ সময় Unknown-ই থাকবে।
• হঠাৎ বৃদ্ধি প্রায়ই বোঝায় আপনার stack-এ কিছু বদলেছে, যেমন এমন একটি release যা একটি header বাদ দিয়েছে, এমন একটি CDN rule যা signature header সরিয়ে দেয়, বা এমন একটি frontend পরিবর্তন যা আপনার app-এর declarations পাঠানো বন্ধ করেছে।
• হঠাৎ পতন-ও পরীক্ষা করার মতো। Unknown কমে গিয়ে যদি Human বাড়ে, তাহলে নিশ্চিত করুন যে নতুন evidence এসেছে, নাকি fallback নীরবে বদলে গেছে।

তীব্র পরিবর্তনের ওপর alert দিন, absolute level-এর ওপর নয়। প্রতিটি application-এরই নিজস্ব normal থাকে।

ধাপ 6: যেখানে গুরুত্বপূর্ণ সেখানে Unknown কীভাবে কমাবেন?

আপনাকে Unknown-কে শূন্যে নামাতে হবে না। যেখানে সিদ্ধান্ত গুরুত্বপূর্ণ, সেই route-গুলোতে যথেষ্ট evidence দরকার। প্রভাবের ক্রমানুসারে এগোান:

1. উচ্চ-প্রভাবের route-এ আগে evidence যোগ করুন। যদি account পরিবর্তনের বেশিরভাগই Unknown হয়, তাহলে সেখানেই browser integration বা server-side check কার্যকর হবে।
2. স্বয়ংক্রিয় client-গুলোকে নিজেদের পরিচয় দিতে উৎসাহিত করুন। আপনার API-এর জন্য এমন documentation প্রকাশ করুন যা ব্যাখ্যা করে কীভাবে agent-রা HTTP Message Signatures এবং IETF Web Bot Auth conventions ব্যবহার করে request sign করতে পারে, এবং verified client-দের আরও ভালো experience দিন, যেমন বেশি limit বা structured response। যারা verify করতে পারে, তারা তা করা শুরু করবে।
3. আপনার নিজের application knowledge ব্যবহার করুন। ব্যবহারকারীরা যদি আপনার built-in assistant-এর সঙ্গে interact করে, সেটিকে declaration হিসেবে record করুন। network-এর চেয়ে আপনার app প্রায়ই বেশি জানে।
4. প্লাম্বিং ঠিক করুন। নিশ্চিত করুন proxy-গুলো আপনি যে header-এর ওপর নির্ভর করেন সেগুলো forward করে এবং evaluation সম্পন্ন হওয়ার জন্য যথেষ্ট time budget পায়।

Unknown থেকে traffic সরাতে কোন signal কাজ করে, তার একটি বাস্তব দৃষ্টিভঙ্গির জন্য how to tell if website traffic comes from AI agents পড়ুন।

ধাপ 7: dashboard-এ Unknown-কে সৎভাবে দেখান

Unknown-কে অন্য class-গুলোর মতোই একই visual weight সহ একটি পৃথক series হিসেবে দেখান। এটিকে "other" bucket-এ লুকাবেন না, এবং alert-এর মতো রঙ দেবেন না। stakeholder-রা যখন Unknown-এর অংশ বড় দেখবে, সঠিক প্রতিক্রিয়া হলো "আমাদের আরও evidence কোথায় দরকার", "কোথায় bot আছে" নয়।

ধাপ 8: অনুমান নয়, outcome দিয়ে Unknown review করুন

প্রতি কয়েক সপ্তাহে, আপনার সবচেয়ে গুরুত্বপূর্ণ route-গুলোর Unknown interaction থেকে একটি sample নিয়ে দেখুন বাস্তবে কী হয়েছে। session কি purchase সম্পন্ন করেছে, project তৈরি করেছে, তিনটি article পড়েছে, নাকি login-এ বারবার ব্যর্থ হয়েছে? Outcome আপনাকে bucket-এ কী ধরনের traffic আছে তা বলে, এবং তার ওপর অকাল label চাপিয়ে দিতে বাধ্য করে না।

আপনি যা পান, তা তিনটি বাস্তব category-তে ভাগ করুন:

1. বৈধ এবং কম ঝুঁকির। Feed reader, link preview, monitoring tool, এবং privacy setting ব্যবহারকারী মানুষ। Route fallback আগের মতোই রাখুন।
2. বৈধ automation যা নিজেকে identify করতে পারে। এমন integration এবং agent যা আপনি structured path দেন বা request sign করার সুযোগ দিলে খুশি হয়ে তা করবে। Guidance প্রকাশ করুন এবং যেখানে সম্ভব যোগাযোগ করুন।
3. যে আচরণের জন্য নিজস্ব control দরকার। Credential stuffing বা scraping pattern, যা দুটিই OWASP Automated Threats to Web Applications project-এ তালিকাভুক্ত। এগুলোকে এমন behavior-based control দিয়ে সামলান যার নিজস্ব evidence আছে, যেমন login failure rate, এবং actor class থেকে আলাদা রাখুন।

এই review আপনার fallback-কে বাস্তব traffic-এর সঙ্গে সামঞ্জস্যপূর্ণ রাখে এবং পরের evidence কোথায় যোগ করবেন তার একটি স্পষ্ট তালিকা দেয়।

সাধারণ প্রশ্ন

Unknown কি rate limit-এর মধ্যে গণনা করা উচিত? আপনার standard limit-ই ব্যবহার করুন। verified agent-দের জন্য class অনুযায়ী rate limiting ঠিক আছে, কারণ তারা বেশি limit অর্জন করতে পারে, কিন্তু Unknown-এর ক্ষেত্রে স্বাভাবিক limit থাকা উচিত, শাস্তিমূলক নয়।

Unknown user-দের challenge করা যাবে? কেবল তখনই, যখন ওই পরিস্থিতিতে route ইতিমধ্যে সবাইকে challenge করে। শুধুমাত্র result Unknown বলেই challenge যোগ করলে কম signal পাঠানো বৈধ user-রা ক্ষতিগ্রস্ত হয়।

Standards পরিণত হলে কি Unknown কমবে? আরও বেশি automated client যখন request sign করবে, তখন আরও বেশি agent traffic Unknown বা declared থেকে verified-এ সরে যাবে। আপনার monitoring route অনুযায়ী সেই পরিবর্তন দেখাবে।

Proof of Actor কোথায় কাজে লাগে

Proof of Actor Unknown-কে একটি first-class result হিসেবে report করে, কারণসহ, এবং কখনও এটিকে Human-এ রূপান্তর করে না। আপনার application প্রতিটি route-এর জন্য fallback বেছে নেয়, আর analytics দেখায় coverage কোথায় শেষ হচ্ছে, যাতে আপনি যেখানে গুরুত্বপূর্ণ সেখানে evidence যোগ করতে পারেন।

আমাদের টিমের সঙ্গে production application-এ এটি সেট আপ করতে apply for early access করুন। evidence ঠিক কী স্থাপন করতে পারে তা বুঝতে Detection & Limitations পড়ুন।

Sources

• RFC 9421: HTTP Message Signatures: যে standard automated client-রা request sign করতে ব্যবহার করতে পারে
• draft-ietf-webbotauth-httpsig-protocol: signed automated traffic-এর জন্য IETF Web Bot Auth draft (November 2026 অনুযায়ী work in progress)
• OpenAI: Overview of OpenAI Crawlers: OpenAI-এর bot-গুলোর জন্য user agent string এবং প্রকাশিত IP address file
• OWASP Automated Threats to Web Applications: credential stuffing এবং scraping-এর মতো automated threat-এর taxonomy
• Node.js test runner: উদাহরণে ব্যবহৃত node:test module