మీ యాప్‌లో Unknown ట్రాఫిక్‌ను ఎలా నిర్వహించాలి

Unknown ఒక errorా, లేక ఒక ఫలితమా?

మీరు interactions ను Human, Human + AI, Agent లేదా Unknown గా వర్గీకరించడం ప్రారంభించినప్పుడు, Unknown bucket చాలా సందర్భాల్లో ప్రజలు ఊహించినదానికంటే పెద్దగా ఉంటుంది. దానిని దాచడానికి, Unknown ను Human లో కలిపేయడం ద్వారా లేదా దానిని అనుమానాస్పదంగా పరిగణించడం ద్వారా, ఒక gap గా చూడాలని అనిపించవచ్చు. ఈ రెండూ సమస్యలను కలిగిస్తాయి.

Unknown అంటే అందుబాటులో ఉన్న evidence నమ్మదగిన నిర్ణయాన్ని సమర్థించదని అర్థం. JavaScript ఏదీ నడపని client నుండి వచ్చిన request, మీరు ఏ signals కూడా సేకరించని endpoint కు చేసిన call, ఒకే పేజీ తర్వాత ముగిసిన session: ఇవన్నీ పూర్తిగా legitimate కావచ్చు, మరియు ఎవరు లేదా ఏమి చర్య తీసుకున్నారో చెప్పడానికి వీటిలో ఏదీ సరిపడ evidence ఇవ్వదు.

Unknown ను నిజాయితీగా నివేదించడమే ఇతర classes ను నమ్మదగినవిగా ఉంచేది. మీ system ఎప్పుడూ Unknown అనకపోతే, ప్రతి Human ఫలితం కొంతవరకు ఒక ఊహ మాత్రమే అవుతుంది, ఆ భాగం ఏదో కూడా మీరు చెప్పలేరు. AI traffic ను వర్గీకరిస్తున్నప్పుడు Unknown ఎందుకు చెల్లుబాటు అయ్యే ఫలితం అనే దానిపై మా post why Unknown is a valid result when classifying AI traffic లో ఆ reasoning ను మరింత లోతుగా వివరించాము.

ఈ guide ప్రాక్టీస్‌లో Unknown ను ఎలా నిర్వహించాలో కవర్ చేస్తుంది: explicit per-route fallbacks, అది ఇతర classes లోకి లీక్ కాకుండా ఉంచే rules, దాన్ని ఎలా monitor చేయాలి, మరియు అది ముఖ్యమైన చోట ఎలా తగ్గించాలి.

Step 1: Human గా default చేయవద్దు

అత్యంత సాధారణమైన పొరపాటు ఏమిటంటే, ఏ automation signal కూడా కనబడనప్పుడు Human ను return చేసే 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" };
}

ఫలితాలు ఉత్పత్తి అయ్యే ప్రతి చోట ఇదే నియమాన్ని వర్తించండి: timeoutలు, errorలు, stale cache entries మరియు missing telemetry అన్నీ Unknown ను ఉత్పత్తి చేయాలి. ఈ paths ప్రతి ఒక్కటి కోసం ఒక test రాయండి, తద్వారా ఈ behavior నిశ్శబ్దంగా 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");
});

Step 2: ప్రతి route కు explicit fallback ఇవ్వండి

Unknown కు నిర్వచించిన behavior అవసరం, మరియు సరైన behavior route పై ఆధారపడి ఉంటుంది. దాన్ని ప్రతి route కు వేర్వేరుగా నిర్ణయించండి, రాయండి, మరియు configuration లో ఉంచండి. ఈ fallbacks విస్తృత policy model లో ఎలా సరిపోతాయో తెలుసుకోవడానికి designing app-level policies for humans and AI agents చూడండి.

Pattern సులభం. తక్కువ risk ఉన్న routes కోసం, Unknown సాధారణ traffic లాగా ప్రవర్తిస్తుంది. ఎక్కువ risk ఉన్న routes కోసం, Unknown కు route ఇప్పటికే కలిగి ఉన్న same protection లభిస్తుంది. రెండు సందర్భాల్లోనూ, classification లేని కానీ legitimate అయిన user కు 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",
};

Step 3: Timeoutలు మరియు errors ను ఒకే విధంగా పరిగణించండి

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 ఎందుకు అయిందో నమోదు చేయండి: no evidence, timeout, evaluation error లేదా stale evidence. ఆ కారణాలు మీరు ఏమి సరిచేయాలో చెబుతాయి.

Step 4: Unknown ను అనుమానాస్పదంగా పరిగణించవద్దు

Unknown ఒక risk score కాదు. అనేక legitimate clients కొన్ని routes లో ఎప్పటికీ Unknown గా ఉంటాయి: command-line tools, signatures లేని server-side integrations, accessibility tools, privacy-focused browsers మరియు simple feed readers. పెద్ద AI operators కూడా ఈ రోజుల్లో ఎక్కువగా తమ fetchers ను user agent మరియు published IP ranges ద్వారా గుర్తిస్తున్నారు. ఉదాహరణకు, OpenAI's crawler documentation November 2026 నాటికి తన bots ప్రతిదానికి ఒక user agent string మరియు published IP address file ను జాబితా చేస్తుంది.

మీరు అనుమానాస్పద ప్రవర్తనపై చర్య తీసుకోవాలనుకుంటే, request rates, failed login patterns లేదా abuse reports వంటి మీరు వివరించగల behavior ఆధారంగా చేయండి, దానికి తన స్వంత evidence ఉండాలి. ఆ logic ను actor class నుండి వేరు గా ఉంచండి, తద్వారా రెండూ ఒకదానిని మరొకటి వక్రీకరించవు.

Step 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 ఎప్పుడూ లోడ్ కాని page, లేదా signed requests ఎప్పుడూ కనిపించని API, ఎక్కువగా Unknown గానే ఉంటుంది.
• ఒక sudden rise తరచుగా మీ stack లో ఏదో మారినట్టు సూచిస్తుంది, ఉదాహరణకు ఒక release వల్ల header పోయింది, signature headers ను strip చేసే CDN rule, లేదా మీ app's declarations పంపడం ఆపేసిన frontend change.
• ఒక sudden fall కూడా పరిశీలించదగినదే. Unknown తగ్గి Human పెరిగితే, fallback నిశ్శబ్దంగా మారిందా లేక కొత్త evidence వచ్చిందా అనేది ధృవీకరించండి.

Absolute levels పై కాదు, పదునైన మార్పులపై alert పెట్టండి. ప్రతి application కు దాని స్వంత normal ఉంటుంది.

Step 6: ముఖ్యమైన చోట Unknown ను ఎలా తగ్గించాలి?

Unknown ను zero కి తీసుకెళ్లాల్సిన అవసరం లేదు. నిర్ణయాలు ముఖ్యమైన routes పై తగినంత evidence ఉండాలి. ప్రభావ క్రమంలో వీటిని పరిష్కరించండి:

1. High-impact routes పై ముందుగా evidence చేర్చండి. Account changes ఎక్కువగా Unknown గా ఉంటే, browser integration లేదా server-side check ఇక్కడే ప్రయోజనం ఇస్తుంది.
2. Automated clients తమను తాము గుర్తించుకునేలా ప్రోత్సహించండి. మీ API కోసం documentation ను ప్రచురించి, agents ఎలా HTTP Message Signatures మరియు IETF Web Bot Auth conventions తో requests ను sign చేయగలరో వివరించండి, మరియు verified clients కు ఎక్కువ limits లేదా structured responses వంటి మెరుగైన experience ఇవ్వండి. Verify చేయగల clients అలా చేయడం ప్రారంభిస్తాయి.
3. మీ స్వంత application knowledge ను ఉపయోగించండి. Users మీ built-in assistant తో interact చేస్తే, దాన్ని ఒక declaration గా నమోదు చేయండి. Network కంటే మీ app కు చాలాసార్లు ఎక్కువ సమాచారం ఉంటుంది.
4. Plumbing ను సరి చేయండి. మీరు ఆధారపడే headers ను proxies forward చేస్తున్నాయో, evaluation పూర్తి కావడానికి తగిన time budget ఉందో నిర్ధారించండి.

Traffic Unknown నుంచి బయటకు వెళ్లే signals పై practical దృష్టి కోసం how to tell if website traffic comes from AI agents చదవండి.

Step 7: Dashboards లో Unknown ను నిజాయితీగా చూపండి

Other classes కు సమానమైన visual weight తో Unknown ను తన స్వంత series గా చూపించండి. దాన్ని "other" bucket లో దాచవద్దు, alert లాగా రంగు వేయవద్దు. Stakeholders పెద్ద Unknown share ను చూసినప్పుడు, సరైన స్పందన "ఎక్కడ మరింత evidence అవసరం" అనేది, "ఎక్కడ bots ఉన్నాయి" అనేది కాదు.

Step 8: Assumptions కాకుండా outcomes తో Unknown ను review చేయండి

ప్రతి కొన్ని వారాలకు, మీ అత్యంత ముఖ్యమైన routes నుండి Unknown interactions లో ఒక sample తీసుకుని, వాస్తవంగా ఏమి జరిగిందో చూడండి. Session ఒక purchase పూర్తి చేసిందా, ఒక project సృష్టించిందా, మూడు articles చదివిందా, లేదా login లో repeatedly fail అయ్యిందా? Outcomeలు bucket లో ఏ kind of traffic ఉందో premature label పెట్టకుండా తెలియజేస్తాయి.

మీరు కనుగొన్న దాన్ని మూడు practical categories గా గుంపు చేయండి:

1. Legitimate మరియు low risk. Feed readers, link previews, monitoring tools మరియు privacy settings ఉన్న people. Route fallback ను అలాగే ఉంచండి.
2. Legitimate automation that could identify itself. మీరు ఒక structured path ఇచ్చినా లేదా requests ను sign చేయమని చెప్పినా సంతోషంగా ఉపయోగించే integrations మరియు agents. Guidance ను ప్రచురించండి, వీలైతే సంప్రదించండి.
3. తనదైన control అవసరమైన behavior. Credential stuffing లేదా scraping patterns, ఇవి రెండూ OWASP Automated Threats to Web Applications project లో cataloged చేయబడ్డాయి. వీటిని login failure rates వంటి తమ స్వంత evidence ఉన్న behavior-based controls తో పరిష్కరించండి, మరియు వాటిని actor class నుండి వేరుగా ఉంచండి.

ఈ review మీ fallbacks ను మీ నిజమైన traffic పై ఆధారపడి ఉంచుతుంది, అలాగే తదుపరి evidence ఎక్కడ చేర్చాలో ఒక స్పష్టమైన జాబితా ఇస్తుంది.

Common questions

Unknown rate limits లో లెక్కలోకి రావాలా? మీ standard limits ను ఉపయోగించండి. Verified agents కోసం class ఆధారంగా rate limiting సరే, వాళ్లు ఎక్కువ limits సంపాదించవచ్చు, కానీ Unknown కు సాధారణ limit ఉండాలి, శిక్షాత్మక limit కాదు.

మనం Unknown users ను challenge చేయగలమా? route ఆ పరిస్థితిలో అందరినీ ఇప్పటికే challenge చేస్తున్న చోట మాత్రమే. ఫలితం Unknown కాబట్టే challenge చేర్చడం, తక్కువ signals పంపే legitimate users ను శిక్షిస్తుంది.

Standards మెరుగుపడేకొద్దీ Unknown తగ్గుతుందా? ఎక్కువ automated clients requests ను sign చేయడంతో, ఎక్కువ agent traffic Unknown లేదా declared నుంచి verified కు మారుతుంది. మీ monitoring ఆ మార్పును route వారీగా చూపుతుంది.

Proof of Actor ఎక్కడ సరిపోతుంది

Proof of Actor కారణంతో పాటు Unknown ను first-class result గా నివేదిస్తుంది, మరియు దాన్ని ఎప్పుడూ Human గా మార్చదు. మీ application ప్రతి route కోసం fallback ను ఎంచుకుంటుంది, analytics coverage ఎక్కడ ముగుస్తుందో చూపిస్తాయి, తద్వారా మీరు అవసరమైన చోట evidence చేర్చగలరు.

మా team తో production application లో దీన్ని set up చేయడానికి, apply for early access. evidence నిజంగా ఏమి నిర్ధారించగలదో ఖచ్చితంగా తెలుసుకోవడానికి, Detection & Limitations చదవండి.

Sources

• 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's bots కోసం user agent strings మరియు published IP address files
• OWASP Automated Threats to Web Applications: credential stuffing మరియు scraping వంటి automated threats యొక్క taxonomy
• Node.js test runner: example లో ఉపయోగించిన node:test module