നിങ്ങളുടെ app-ലുള്ള Unknown traffic എങ്ങനെ കൈകാര്യം ചെയ്യാം

Unknown ഒരു error ആണോ, അല്ലെങ്കിൽ ഒരു result ആണോ?

നിങ്ങൾ interactions-നെ Human, Human + AI, Agent അല്ലെങ്കിൽ Unknown ആയി വർഗ്ഗീകരിക്കാൻ തുടങ്ങുമ്പോൾ, Unknown bucket പലപ്പോഴും ആളുകൾ പ്രതീക്ഷിക്കുന്നതിലുപരി വലുതായിരിക്കും. അത് മറയ്ക്കാൻ, Unknown-നെ Human-ലേക്ക് ചേർക്കുകയോ അല്ലെങ്കിൽ അതിനെ സംശയാസ്പദമായി കാണുകയോ ചെയ്യുന്നത് ആകർഷകമായി തോന്നും. രണ്ടും പ്രശ്നങ്ങൾ സൃഷ്ടിക്കും.

ലഭ്യമായ evidence, വിശ്വസനീയമായ ഒരു നിർണ്ണയം പിന്തുണയ്ക്കുന്നില്ല എന്നതാണ് Unknown എന്നതിന്റെ അർത്ഥം. JavaScript ഒന്നും പ്രവർത്തിക്കാത്ത client-ിൽ നിന്നുള്ള ഒരു request, നിങ്ങൾക്ക് signal ഒന്നും ലഭിക്കാത്ത endpoint-ിലേക്കുള്ള ഒരു call, ഒരു page കഴിഞ്ഞ് തന്നെ അവസാനിച്ച session: ഇവയൊക്കെ പൂർണ്ണമായും നിയമാനുസൃതമായിരിക്കാം, പക്ഷേ acting ചെയ്തിരുന്നത് ആരോ എന്തോ എന്ന് പറയാൻ ഇവ ഒന്നും മതിയായ വിവരം നൽകുന്നില്ല.

Unknown-നെ സത്യസന്ധമായി report ചെയ്യുന്നതാണ് മറ്റ് classes-നെ വിശ്വസനീയമാക്കുന്നത്. നിങ്ങളുടെ system ഒരിക്കലും Unknown പറയുന്നില്ലെങ്കിൽ, എല്ലാ Human results-ഉം ഭാഗികമായി ഒരു guess ആയിരിക്കും, ഏത് ഭാഗമാണ് അതെന്ന് നിങ്ങൾക്ക് തിരിച്ചറിയാനാവില്ല. AI traffic classify ചെയ്യുമ്പോൾ Unknown ഒരു valid result ആകുന്നത് എന്തുകൊണ്ടാണ് എന്ന ഞങ്ങളുടെ post, അതിന്റെ കാരണം കൂടുതൽ വിശദമായി പറയുന്നു.

ഈ guide പ്രായോഗികമായി Unknown എങ്ങനെ കൈകാര്യം ചെയ്യാമെന്ന് വിവരിക്കുന്നു: explicit per-route fallbacks, അത് മറ്റ് classes-ലേക്ക് ചോർന്നുപോകാതിരിക്കാൻ ഉള്ള rules, അത് എങ്ങനെ monitor ചെയ്യാം, അതുപോലെ ഏറ്റവും പ്രധാനപ്പെട്ടിടത്ത് അത് എങ്ങനെ കുറയ്ക്കാം.

ഘട്ടം 1: ഒരിക്കലും Human-ലേക്ക് default ചെയ്യരുത്

ഏറ്റവും സാധാരണമായ പിശക്, automation signal ഒന്നും കണ്ടെത്താനാവാത്തപ്പോൾ Human തിരികെ നൽകുന്ന ഒരു classification function ആണ്. അത് യുക്തിസഹമായി തോന്നും, പക്ഷേ അത് തെറ്റാണ്. 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 സൃഷ്ടിക്കണം. ഇവയിൽ ഓരോ പാതയ്ക്കുമായി test എഴുതുക, അങ്ങനെ behavior നിശബ്ദമായി വഴുതിപ്പോകാതിരിക്കും. താഴെയുള്ള ഉദാഹരണം 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-ൽ സൂക്ഷിക്കുക. ഈ fallback-കൾ വിശാലമായ policy model-ലേക്ക് എങ്ങനെ ചേരുന്നു എന്നതിന് human, AI agent കളുടെ app-level policies രൂപകൽപ്പന ചെയ്യുന്നത് കാണുക.

Pattern ലളിതമാണ്. കുറഞ്ഞ risk ഉള്ള routes-ൽ, Unknown സാധാരണ traffic പോലെ പ്രവർത്തിക്കും. ഉയർന്ന risk ഉള്ള 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" });

ഒരു result എന്തുകൊണ്ട് Unknown ആണെന്ന് രേഖപ്പെടുത്തുക: evidence ഇല്ല, timeout, evaluation error, stale evidence. ഈ reasons നിങ്ങൾക്ക് എന്താണ് പരിഹരിക്കേണ്ടതെന്ന് പറയുന്നു.

ഘട്ടം 4: Unknown-നെ സംശയാസ്പദമെന്ന് കരുതരുത്

Unknown ഒരു risk score അല്ല. പല നിയമാനുസൃത client-ുകളും ചില routes-ിൽ എന്നും Unknown ആയിരിക്കും: command-line tools, signatures ഇല്ലാത്ത server-side integrations, accessibility tools, privacy-focused browsers, ലളിതമായ feed readers. വലിയ AI operators പോലും ഇന്നും അവരുടെ fetchers-നെ user agent, പ്രസിദ്ധീകരിച്ച IP ranges എന്നിവയിലൂടെ ആണ് കൂടുതലും തിരിച്ചറിയുന്നത്. ഉദാഹരണത്തിന്, OpenAI-യുടെ crawler documentation November 2026 വരെ, അതിന്റെ ഓരോ bot-ത്തിനും ഒരു user agent string, പ്രസിദ്ധീകരിച്ച IP address file എന്നിവ list ചെയ്യുന്നു.

നിങ്ങൾക്ക് സംശയാസ്പദമായ behavior-ൽ നടപടി എടുക്കണമെങ്കിൽ, request rates, failed login patterns, abuse reports പോലുള്ള നിങ്ങൾ വിവരണം ചെയ്യാൻ കഴിയുന്ന behavior-നെ അടിസ്ഥാനമാക്കുക, അതിനായി സ്വന്തം 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 കുറവാണെന്ന് സൂചിപ്പിക്കുന്നു. നിങ്ങളുടെ browser integration ഒരിക്കലും load ചെയ്യാത്ത ഒരു page, അല്ലെങ്കിൽ signed requests ഒരിക്കലും കാണാത്ത ഒരു API, കൂടുതലും Unknown ആയി തുടരും.
• പെട്ടെന്നുള്ള ഉയർച്ച പലപ്പോഴും നിങ്ങളുടെ stack-ൽ എന്തോ മാറ്റം സംഭവിച്ചതാണ് സൂചിപ്പിക്കുന്നത്, ഉദാഹരണത്തിന് ഒരു header ഒഴിവാക്കിയ release, signature headers strip ചെയ്യുന്ന CDN rule, അല്ലെങ്കിൽ നിങ്ങളുടെ app-ന്റെ declarations അയക്കുന്നത് നിർത്തിയ frontend change.
• പെട്ടെന്നുള്ള കുറവ്യും പരിശോധിക്കേണ്ടതാണ്. Unknown കുറയുകയും Human ഉയരുകയും ചെയ്താൽ, പുതിയ evidence എത്തിയതാണോ എന്ന് സ്ഥിരീകരിക്കുക, fallback നിശബ്ദമായി മാറിയതല്ലെന്ന് ഉറപ്പാക്കുക.

Absolute levels-ൽ അല്ല, sharp changes-ൽ alert ചെയ്യുക. ഓരോ application-ക്കും അതിന്റേതായ normal നിലയുണ്ട്.

ഘട്ടം 6: ഏറ്റവും പ്രസക്തമായിടത്ത് Unknown എങ്ങനെ കുറയ്ക്കാം?

Unknown-നെ ശൂന്യത്തിലേക്ക് കൊണ്ടുവരേണ്ടതില്ല. തീരുമാനങ്ങൾ പ്രധാനപ്പെട്ട routes-ിൽ മതിയായ evidence ഉണ്ടായിരിക്കുകയാണ് വേണ്ടത്. impact അനുസരിച്ച് ക്രമത്തിൽ പ്രവർത്തിക്കുക:

1. ഉയർന്ന impact ഉള്ള routes-ിൽ ആദ്യം evidence ചേർക്കുക. account changes കൂടുതലും Unknown ആണെങ്കിൽ, browser integration അല്ലെങ്കിൽ server-side check ഏറ്റവും കൂടുതൽ value നൽകുന്നത് അവിടെയാണ്.
2. Automated clients-നെ സ്വയം identify ചെയ്യാൻ ക്ഷണിക്കുക. നിങ്ങളുടെ API-യ്ക്ക് documentation പ്രസിദ്ധീകരിക്കുക, അതിൽ agents എങ്ങനെ HTTP Message Signatures ഉം IETF Web Bot Auth conventions ഉം ഉപയോഗിച്ച് requests sign ചെയ്യാം എന്ന് വിശദീകരിക്കുക, കൂടാതെ verified clients-ന് മികച്ച experience നൽകുക, ഉദാഹരണത്തിന് ഉയർന്ന limits അല്ലെങ്കിൽ structured responses. verify ചെയ്യാൻ കഴിയുന്ന clients അങ്ങനെ ചെയ്യാൻ തുടങ്ങും.
3. നിങ്ങളുടെ സ്വന്തം application knowledge ഉപയോഗിക്കുക. ഉപയോക്താക്കൾ നിങ്ങളുടെ built-in assistant-ുമായി ഇടപെടുമ്പോൾ, അതിനെ ഒരു declaration ആയി രേഖപ്പെടുത്തുക. പലപ്പോഴും network-നെക്കാൾ കൂടുതൽ app-ിന് അറിയാം.
4. Plumbing ശരിയാക്കുക. നിങ്ങൾ ആശ്രയിക്കുന്ന headers proxies forward ചെയ്യുന്നുണ്ടോ, evaluation പൂർത്തിയാകാൻ മതിയായ time budget ഉണ്ടോ എന്നിവ ഉറപ്പാക്കുക.

ട്രാഫിക് Unknown-ിൽ നിന്ന് പുറത്തേക്ക് മാറ്റുന്ന signals-നെ പ്രായോഗികമായി കാണാൻ, website traffic AI agents-ിൽ നിന്നാണോ എന്ന് എങ്ങനെ തിരിച്ചറിയാം വായിക്കുക.

ഘട്ടം 7: dashboards-ൽ Unknown സത്യസന്ധമായി കാണിക്കുക

Unknown-നെ മറ്റ് classes-ിനോടൊപ്പം തുല്യ visual weight ഉള്ള സ്വന്തം series ആയി കാണിക്കുക. അതിനെ "other" bucket-ലേക്ക് ഒളിപ്പിക്കരുത്, alert പോലെ നിറമിടുകയും ചെയ്യരുത്. Stakeholders വലിയ Unknown share കാണുമ്പോൾ, ശരിയായ പ്രതികരണം "നമുക്ക് എവിടെയാണ് കൂടുതൽ evidence വേണ്ടത്" എന്നായിരിക്കണം, "ബോട്ടുകൾ എവിടെയാണ്" എന്നല്ല.

ഘട്ടം 8: assumptions അല്ല, outcomes ഉപയോഗിച്ച് Unknown review ചെയ്യുക

ഏതാനും ആഴ്ചകൾ കൂടുമ്പോൾ, നിങ്ങളുടെ ഏറ്റവും പ്രധാനപ്പെട്ട routes-ിൽ നിന്നുള്ള Unknown interactions-ന്റെ ഒരു sample എടുത്ത്, യഥാർത്ഥത്തിൽ എന്താണ് സംഭവിച്ചതെന്ന് നോക്കുക. session ഒരു purchase പൂർത്തിയാക്കിയോ, ഒരു project സൃഷ്ടിച്ചോ, മൂന്ന് articles വായിച്ചോ, അല്ലെങ്കിൽ login-ൽ ആവർത്തിച്ച് പരാജയപ്പെട്ടോ? Outcomes, അതിൽ നേരത്തെ ഒരു label അടിച്ചേൽപ്പിക്കാതെ, ആ bucket-ൽ ഏത് തരത്തിലുള്ള traffic ഇരിക്കുന്നു എന്ന് പറയുന്നു.

കണ്ടെത്തുന്നതിനെ മൂന്ന് പ്രായോഗിക വിഭാഗങ്ങളായി കൂട്ടിച്ചേർക്കുക:

1. നിയമാനുസൃതവും കുറഞ്ഞ risk ഉള്ളതും. Feed readers, link previews, monitoring tools, സ്വകാര്യതാ ക്രമീകരണങ്ങളുള്ള ആളുകൾ. Route fallback അതുപോലെ തന്നെ സൂക്ഷിക്കുക.
2. സ്വയം identify ചെയ്യാവുന്ന നിയമാനുസൃത automation. നിങ്ങൾ structured path അല്ലെങ്കിൽ requests sign ചെയ്യാനുള്ള മാർഗം നൽകുന്നുവെങ്കിൽ സന്തോഷത്തോടെ അത് ഉപയോഗിക്കുന്ന integrations, agents. Guidance പ്രസിദ്ധീകരിക്കുക, കഴിയുന്നിടത്ത് ബന്ധപ്പെടുക.
3. സ്വന്തമായ control ആവശ്യമുള്ള behavior. Credential stuffing അല്ലെങ്കിൽ scraping patterns, ഇരുവരും OWASP Automated Threats to Web Applications project-ൽ catalog ചെയ്തവ. login failure rates പോലുള്ള സ്വന്തം evidence ഉള്ള behavior-based controls ഉപയോഗിച്ച് ഇവ കൈകാര്യം ചെയ്യുക, actor class-ിൽ നിന്ന് വേർതിരിച്ച് സൂക്ഷിക്കുക.

ഈ review, നിങ്ങളുടെ fallbacks-നെ യഥാർത്ഥ traffic-ിൽ ആധാരപ്പെടുത്തുകയും, അടുത്തതായി എവിടെയാണ് evidence ചേർക്കേണ്ടത് എന്നതിനുള്ള വ്യക്തമായ പട്ടിക നൽകുകയും ചെയ്യുന്നു.

സാധാരണ ചോദ്യങ്ങൾ

Rate limits-ലേക്ക് Unknown കണക്കാക്കണോ? നിങ്ങളുടെ standard limits ഉപയോഗിക്കുക. verified agents-നെ class അനുസരിച്ച് rate limit ചെയ്യുന്നത് ശരിയാണ്, അവർക്ക് ഉയർന്ന limits നേടാനും കഴിയും, പക്ഷേ Unknown-ന് സാധാരണ limit തന്നെയായിരിക്കണം, ശിക്ഷാപരമായ limit അല്ല.

Unknown users-നെ challenge ചെയ്യാമോ? ആ സാഹചര്യത്തിൽ route ഇതിനകം എല്ലാവരെയും challenge ചെയ്യുന്നിടങ്ങളിൽ മാത്രം. ഒരു result Unknown ആണെന്ന കാരണം മാത്രം challenge ചേർക്കുന്നത് കുറച്ച് signals അയക്കുന്ന clients ഉള്ള നിയമാനുസൃത ഉപയോക്താക്കളെ ശിക്ഷിക്കും.

Standards വളരുന്നതിനനുസരിച്ച് Unknown കുറയുമോ? കൂടുതൽ automated clients requests sign ചെയ്യുന്നതിനനുസരിച്ച്, കൂടുതൽ agent traffic Unknown അല്ലെങ്കിൽ declared-ിൽ നിന്ന് verified-ലേക്ക് മാറും. നിങ്ങളുടെ monitoring route-തോറും ആ മാറ്റം കാണിക്കും.

Proof of Actor എവിടെയാണ് ചേരുന്നത്

Proof of Actor Unknown-നെ ആദ്യം പരിഗണിക്കേണ്ട result ആയി, അതിന്റെ reason സഹിതം report ചെയ്യുന്നു, ഒരിക്കലും അതിനെ Human-ലേക്ക് മാറ്റുന്നില്ല. നിങ്ങളുടെ application ഓരോ route-ക്കും fallback തിരഞ്ഞെടുക്കുന്നു, analytics coverage എവിടെ അവസാനിക്കുന്നു എന്ന് കാണിക്കുന്നു, അങ്ങനെ ഏറ്റവും പ്രധാനപ്പെട്ടിടത്ത് evidence ചേർക്കാൻ കഴിയും.

ഒരു production application-ൽ ഇത് നമ്മുടെ team-നൊപ്പം സജ്ജീകരിക്കാൻ, early access-ന് അപേക്ഷിക്കുക. തെളിവിന് യഥാർത്ഥത്തിൽ എന്താണ് സ്ഥാപിക്കാനാകുന്നത് എന്ന് മനസ്സിലാക്കാൻ, 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 (November 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