আপোনাৰ app ত Unknown traffic কেনেকৈ handle কৰিব

Unknown এটা error নে এটা result?

যেতিয়া আপুনি interactions-ক Human, Human + AI, Agent বা Unknown হিচাপে classify কৰিবলৈ আৰম্ভ কৰে, Unknown bucket-টো প্ৰায়ে মানুহে আশা কৰাতকৈ ডাঙৰ হয়। ইয়াক লুকুৱাবলৈ এটা gap হিচাপে ধৰিবলৈ মন যাব পাৰে, হয়তো Unknown-ক Human-ত fold কৰি বা ইয়াক সন্দেহজনক বুলি ধৰি। দুয়োটা বাছনিয়েই সমস্যা সৃষ্টি কৰে।

Unknown মানে হৈছে উপলব্ধ evidence-এ এটা reliable determination সমৰ্থন নকৰে। কোনো JavaScript run নকৰা client-ৰ পৰা অহা request, আপুনি কোনো signals সংগ্ৰহ নকৰা endpoint-লৈ কৰা call, এটা page-ৰ পাছতেই শেষ হোৱা session: এইবোৰ সকলো সম্পূৰ্ণ legitimate হ'ব পাৰে, আৰু এইবোৰে কোনে বা কি acting কৰিছিল ক'বলৈ যথেষ্ট তথ্য নিদিয়ে।

Unknown-ৰ বিষয়ে সৎভাবে report কৰাটোৱেই আন class-সমূহক trustworthy কৰি ৰাখে। যদি আপোনাৰ system-এ কেতিয়াও Unknown নকয়, তেন্তে প্ৰতিটো Human result আংশিকভাবে এটা অনুমান হয়, আৰু কোন অংশটো অনুমান সেইটো ক'ব নোৱাৰি। AI traffic classify কৰাৰ সময়ত Unknown কিয় valid result সেই বিষয়ে আমাৰ এই post-এ অধিক বিশদভাবে যুক্তি ব্যাখ্যা কৰিছে।

এই guide-এ practical ভাবে Unknown কেনেকৈ handle কৰিব সেয়া covers: explicit per-route fallback, ইয়াক অন্য class-লৈ leak নোহোৱাকৈ ৰাখা rules, ইয়াক কেনেকৈ monitor কৰিব, আৰু য'ত প্ৰাসংগিক তাত কেনেকৈ কমাব।

Step 1: কেতিয়াও Human-লৈ default নকৰিব

সৰ্বাধিক সাধাৰণ ভুল হৈছে এটা classification function যিয়ে automation signal নাপালে সদায় Human return কৰে। দেখিবলৈ যুক্তিসংগত লাগে, কিন্তু ভুল। 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" };
}

ফলাফল উৎপন্ন হোৱা সকলো ঠাইতে একে rule প্ৰয়োগ কৰক: timeout, error, stale cache entry আৰু missing telemetry, এই সকলোবোৰে Unknown produce কৰিব। এই path-সমূহৰ প্ৰতিটোৰ বাবে এটা test লিখক যাতে behavior নিঃশব্দে regress নকৰে। তলৰ উদাহৰণত 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");
});

Step 2: প্ৰতিটো route-লৈ explicit fallback দিয়ক

Unknown-ৰ এটা defined behavior লাগে, আৰু সঠিক behavior route-ৰ ওপৰত নিৰ্ভৰ কৰে। Route অনুসৰি সেয়া সিদ্ধান্ত লওক, লিখি থওক, আৰু configuration-ত ৰাখক। এই fallback-সমূহ কেনেকৈ এটা broader policy model-ত fit হয়, তাৰ বাবে humans আৰু AI agents-ৰ বাবে app-level policy design কৰা চাওক।

Patternটো সহজ। কম risk থকা route-সমূহত, Unknown normal traffic-ৰ দৰে behave কৰে। উচ্চ risk থকা route-সমূহত, Unknown-এ route-এ ইতিমধ্যে থকা একে protection পায়। কোনো ক্ষেত্ৰতেই 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",
};

Step 3: timeout আৰু error-সমূহক একেইভাবে handle কৰক

Actor evaluation request path-ৰ ভিতৰত থাকে, সেয়েহে ইয়াৰ strict 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 হৈছে সেয়া record কৰক: no evidence, timeout, evaluation error বা stale evidence। এই reasons-এ আপোনাক কি fix কৰিব লাগিব সেয়া জানিবলৈ সহায় কৰে।

Step 4: Unknown-ক সন্দেহজনক বুলি গণ্য নকৰিব

Unknown কোনো risk score নহয়। বহু legitimate client কিছুমান route-ত সদায় Unknown হ'ব: command-line tools, server-side integrations without signatures, accessibility tools, privacy-focused browsers আৰু simple feed readers। আজিও ডাঙৰ AI operator-সকলে বেছিভাগে নিজৰ fetchers-ক user agent আৰু published IP ranges-ৰ দ্বাৰাই চিনাক্ত কৰে। উদাহৰণস্বৰূপে, OpenAI's crawler documentation-এ November 2026 অনুসৰি নিজৰ প্ৰতিটো bot-ৰ বাবে এটা user agent string আৰু এটা published IP address file তালিকাভুক্ত কৰে।

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

Step 5: আপোনাৰ unknown rate কেনেকৈ monitor কৰিব?

Unknown rate হৈছে Unknown হিচাপে classify হোৱা interactions-ৰ অংশ। ইয়াক প্ৰতিটো route-ত, প্ৰতিটো integration context-ত আৰু সময়ৰ সৈতে track কৰক। ই আপোনাৰ হাতত থকা আটাইতকৈ উপযোগী 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 load নকৰে, বা যি API-এ কেতিয়াও signed request নেদেখে, সেয়া বেছিভাগ Unknown হৈয়ে থাকিব।
• এটা হঠাৎ বৃদ্ধি প্ৰায়ে বোলে আপোনাৰ stack-ত কিবা সলনি হৈছে, উদাহৰণস্বৰূপে এনে এটা release যিয়ে header বাদ দিলে, signature header strip কৰা CDN rule, বা আপোনাৰ app-ৰ declaration পঠিয়োৱা বন্ধ কৰা frontend change।
• এটা হঠাৎ হ্ৰাসও যাচাই কৰা উচিত। যদি Unknown কমি Human বৃদ্ধি পায়, তেন্তে নিশ্চিত কৰক যে নতুন evidence আহিছে, কেৱল fallback নিঃশব্দে সলনি হোৱা নাই।

Absolute level-ৰ ওপৰত নহয়, sharp change-ৰ ওপৰত alert কৰক। প্ৰতিটো application-ৰ নিজৰ normal থাকে।

Step 6: য'ত প্ৰয়োজন তাত Unknown কেনেকৈ কমাব?

আপোনাক Unknown শূন্যলৈ নামাব নালাগে। সিদ্ধান্ত গুৰুত্বপূৰ্ণ হোৱা route-সমূহত যথেষ্ট evidence থাকিব লাগিব। সৰ্বাধিক প্ৰভাৱৰ ক্ৰম অনুসৰি আগবাঢ়ক:

1. প্ৰথমে উচ্চ-প্ৰভাৱৰ route-সমূহত evidence যোগ কৰক। যদি account change-সমূহ বেছিভাগ Unknown হয়, তেন্তে browser integration বা server-side check তাতেই লাভজনক হয়।
2. Automated client-সমূহক নিজকে চিনাক্ত কৰিবলৈ আমন্ত্ৰণ দিয়ক। আপোনাৰ API-ৰ বাবে documentation প্ৰকাশ কৰক যিয়ে ব্যাখ্যা কৰে যে agents-এ HTTP Message Signatures আৰু IETF Web Bot Auth conventions-ৰ সৈতে request কেনেকৈ sign কৰিব পাৰে, আৰু verified client-সমূহক higher limits বা structured response যেনে উন্নত experience দিয়ক। যিয়ে verify কৰিব পাৰে, সেয়া verify কৰিবলৈ আৰম্ভ কৰিব।
3. আপোনাৰ নিজৰ application knowledge ব্যৱহাৰ কৰক। যদি users আপোনাৰ built-in assistant-ৰ সৈতে interact কৰে, তেন্তে সেইটোক declaration হিচাপে record কৰক। Network-তকৈ আপোনাৰ app-এ প্ৰায়ে অধিক জানে।
4. Plumbing ঠিক কৰক। নিশ্চিত কৰক যে proxies-এ আপুনি নিৰ্ভৰ কৰা headers forward কৰে আৰু evaluation-ৰ completion-ৰ বাবে যথেষ্ট time budget থাকে।

Unknown-ৰ পৰা traffic বাহিৰলৈ নিবলৈ যি signal সহায় কৰে, তাৰ practical দৃষ্টি পোৱাৰ বাবে website traffic AI agents-ৰ পৰা আহে নে নাই কেনেকৈ জানিব পঢ়ক।

Step 7: Dashboards-ত Unknown সৎভাৱে দেখুৱাওক

Unknown-কে অন্য class-সমূহৰ সমান visual weight দি এটা পৃথক series হিচাপে দেখুৱাওক। ইয়াক "other" bucket-ত লুকুৱাই নাৰাখিব, আৰু alert-ৰ দৰে color নকৰিব। Stakeholder-সকলে যেতিয়া ডাঙৰ Unknown share দেখে, সঠিক প্ৰতিক্ৰিয়া হৈছে "আমি ক'ত অধিক evidence লাগে", "bots ক'ত" নহয়।

Step 8: Assumption-ৰ ওপৰত নহয়, outcome-ৰ সৈতে Unknown review কৰক

প্ৰতি কেইসপ্তাহত এবাৰ, আপোনাৰ আটাইতকৈ গুৰুত্বপূৰ্ণ route-সমূহৰ Unknown interactions-ৰ এটা sample লওক আৰু প্ৰকৃততে কি ঘটিল সেয়া চাওক। Session-এ purchase complete কৰিছিল নেকি, project create কৰিছিল নেকি, তিনিখন article পঢ়িছিল নেকি, বা login-ত বাৰে বাৰে fail হৈছিল নেকি? Outcome-এ আপোনাক bucket-ত কিহৰ traffic আছে সেয়া কয়, আগতে label আৰোপ নকৰাকৈ।

আপুনি যি পায়, তাক তিনিটা practical category-ত ভাগ কৰক:

1. Legitimate আৰু low risk. Feed reader, link preview, monitoring tool আৰু privacy setting থকা মানুহ। Route fallback যি আছে, সেয়াই ৰাখক।
2. Legitimate automation যি নিজকে চিনাক্ত কৰিব পাৰে। এনে integration আৰু agent যিয়ে আপুনি এটা structured path বা sign request দিলে সানন্দে ব্যৱহাৰ কৰিব। Guidance প্ৰকাশ কৰক আৰু সম্ভৱ হলে যোগাযোগ কৰক।
3. নিজস্ব control লাগিব পৰা behavior. Credential stuffing বা scraping pattern, যিবোৰ OWASP Automated Threats to Web Applications project-ত catalogued কৰা আছে। Login failure rate যেনে নিজৰ evidence থকা behavior-based control-ৰে এইবোৰ handle কৰক, আৰু actor class-ৰ পৰা পৃথক ৰাখক।

এই review-এ আপোনাৰ fallback-সমূহক বাস্তৱ traffic-ত grounded কৰি ৰাখে আৰু evidence ক'ত আগলৈ যোগ কৰিব লাগিব তাৰ এটা স্পষ্ট তালিকা দিয়ে।

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

Unknown-ক rate limit-ৰ ভিতৰত গণ্য কৰিব লাগে নেকি? আপোনাৰ standard limits ব্যৱহাৰ কৰক। Verified agent-ৰ বাবে class অনুসৰি rate limiting ঠিক আছে, কিয়নো তেওঁলোকে higher limit earn কৰিব পাৰে, কিন্তু Unknown-এ punitive সীমা নহয়, normal limit পোৱা উচিত।

আমি Unknown users-ক challenge কৰিব পাৰোঁনে? কেৱল সেই route-ত, য'ত সেই পৰিস্থিতিত আগতেই সকলোকে challenge কৰা হয়। কেৱল result Unknown হোৱা বাবে challenge যোগ কৰিলে fewer signal পঠিওৱা legitimate user-সকলক শাস্তি দিয়া হয়।

Standards mature হ'লে Unknown কমিব নেকি? অধিক automated client-এ request sign কৰাৰ লগে লগে, অধিক agent traffic Unknown বা declared-ৰ পৰা verified-লৈ যাব। আপোনাৰ monitoring-এ route অনুসৰি সেই shift দেখুৱাব।

Proof of Actor ক'ত fit কৰে

Proof of Actor-এ Unknown-ক reason-সহ প্ৰথম শ্ৰেণীৰ result হিচাপে report কৰে, আৰু ইয়াক কেতিয়াও Human-লৈ convert নকৰে। আপোনাৰ application-এ প্ৰতিটো route-ৰ বাবে fallback বাছি লয়, আৰু analytics-এ coverage ক'ত শেষ হয় সেয়া দেখুৱায় যাতে আপুনি য'ত প্ৰয়োজন তাত evidence যোগ কৰিব পাৰে।

আমাৰ দলৰ সৈতে production application-ত এইটো set up কৰিবলৈ, early access-ৰ বাবে আবেদন কৰক. Evidence-এ ঠিক কি establish কৰিব পাৰে সেয়া বুজিবলৈ, 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-ৰ bots-ৰ user agent strings আৰু published IP address files
• OWASP Automated Threats to Web Applications: credential stuffing আৰু scraping যেনে automated threat-ৰ taxonomy
• Node.js test runner: উদাহৰণত ব্যৱহৃত node:test module