உங்கள் app-இல் Unknown traffic-ஐ எப்படிக் கையாளுவது

Unknown என்பது error-ஆ, அல்லது result-ஆ?

நீங்கள் interactions-ஐ Human, Human + AI, Agent அல்லது Unknown என்று classify செய்யத் தொடங்கும்போது, Unknown bucket பெரும்பாலும் மக்கள் எதிர்பார்ப்பதைவிட பெரியதாக இருக்கும். Unknown-ஐ Human-இல் சேர்த்துவிடுவதன் மூலம் அல்லது அதை சந்தேகத்திற்குரியது என்று கருதி மறைப்பது tempting ஆக இருக்கும். இந்த இரண்டு அணுகுமுறைகளும் பிரச்சினைகளை உருவாக்கும்.

Unknown என்றால் கிடைத்த evidence நம்பகமான முடிவை ஆதரிக்கவில்லை என்பதைக் குறிக்கும். எந்த JavaScript-யும் இயக்காத client-இலிருந்து வரும் ஒரு request, நீங்கள் எந்த signals-யும் சேகரிக்காத endpoint-க்கு வரும் ஒரு call, ஒரே page-க்கு பிறகு முடிந்த session: இவை அனைத்தும் முற்றிலும் legitimate ஆக இருக்கலாம், மேலும் எது acting செய்தது என்பதைக் கூறுவதற்கு இவற்றில் எதுவும் போதுமானதல்ல.

Unknown-ஐ நேர்மையாக report செய்வதே மற்ற classes-ஐ நம்பகமானதாக வைத்திருக்கும். உங்கள் system ஒருபோதும் Unknown என்று சொல்லவில்லை என்றால், ஒவ்வொரு Human result-மும் பகுதியளவில் ஒரு guess ஆகிவிடும், எந்த பகுதி என்று நீங்கள் சொல்ல முடியாது. AI traffic-ஐ classify செய்யும்போது Unknown ஒரு valid result ஏன் என்பதற்கான காரணம் பற்றிய எங்கள் post இதை மேலும் விரிவாக விளக்குகிறது.

இந்த guide நடைமுறையில் Unknown-ஐ எப்படிக் கையாளுவது என்பதை உள்ளடக்குகிறது: explicit per-route fallbacks, அது மற்ற classes-க்குள் கசியாமல் இருக்க வைத்திருக்கும் rules, அதை monitor செய்வது எப்படி, மற்றும் முக்கியமான இடங்களில் அதை எப்படி குறைப்பது.

Step 1: ஒருபோதும் Human-ஐ default ஆகப் பயன்படுத்த வேண்டாம்

அதிகமாக நடக்கும் mistake என்பது எந்த automation signal-யும் கிடைக்காதபோது Human-ஐ return செய்யும் ஒரு classification function ஆகும். அது reasonable போலத் தெரிகிறது, ஆனால் அது தவறு. bot signal இல்லாதது மனித 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" };
}

Result-கள் உருவாக்கப்படும் எல்லா இடங்களிலும் ஒரே rule-ஐப் பயன்படுத்துங்கள்: timeout-கள், error-கள், stale cache entries மற்றும் missing telemetry எல்லாம் Unknown-ஐ உருவாக்க வேண்டும். இந்த பாதைகளில் ஒவ்வொன்றிற்கும் test எழுதுங்கள், அப்போதுதான் நடத்தை அமைதியாக 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-க்கு வரையறுக்கப்பட்ட behavior தேவை, மேலும் சரியான behavior route-ஐப் பொறுத்தது. அதை route-by-route முடிவு செய்து, எழுதி வைத்துக் கொண்டு, configuration-இல் வைத்திருங்கள். இந்த fallbacks பரந்த policy model-இல் எவ்வாறு பொருந்துகின்றன என்பதற்கு, app-level policies for humans and AI agents-ஐ வடிவமைத்தல் என்பதைப் பார்க்கவும்.

Pattern எளிமையானது. Low-risk routes-க்கு Unknown சாதாரண traffic போல நடக்கும். High-risk routes-க்கு Unknown அந்த route ஏற்கனவே கொண்டிருக்கும் protection-ஐப் பெறும். எந்த நிலையிலும் வகைப்படுத்தப்படாத, ஆனால் legitimate பயனருக்கு 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-களையும் 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 ஆனது என்பதை பதிவு செய்யுங்கள்: 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 மற்றும் எளிய feed readers. இன்று பெரிய AI operators கூட பெரும்பாலும் தங்கள் fetchers-ஐ user agent மற்றும் published IP ranges மூலம் identify செய்கிறார்கள். உதாரணமாக, OpenAI's crawler documentation அதன் bots ஒவ்வொன்றுக்கும் ஒரு user agent string மற்றும் published IP address file-ஐ November 2026 நிலவரப்படி பட்டியலிடுகிறது.

நீங்கள் சந்தேகத்திற்குரிய நடத்தைக்கு நடவடிக்கை எடுக்க விரும்பினால், request rates, failed login patterns அல்லது abuse reports போன்ற, நீங்கள் விவரிக்கக்கூடிய நடத்தையை அடிப்படையாகக் கொள்ளுங்கள், அதற்கான சொந்த evidence-உடன். அந்த logic-ஐ actor class-இலிருந்து தனியாக வைத்திருங்கள், அப்போது இரண்டிலும் எதுவும் மற்றொன்றை சிதைக்காது.

Step 5: உங்கள் unknown rate-ஐ எப்படி monitor செய்வது?

Unknown rate என்பது Unknown என்று வகைப்படுத்தப்பட்ட interactions-ன் பங்காகும். அதை route-by-route, integration context-by-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-ஐ நீங்கள் இழந்துள்ளீர்கள் என்பதைக் குறிக்கும். உங்கள் browser integration ஒருபோதும் load ஆகாத ஒரு page, அல்லது signed requests-ஐ ஒருபோதும் காணாத ஒரு API, பெரும்பாலும் Unknown ஆகவே இருக்கும்.
• திடீர் உயர்வு பெரும்பாலும் உங்கள் stack-இல் ஏதோ ஒன்று மாறியுள்ளது என்பதைக் காட்டுகிறது, உதாரணமாக ஒரு header-ஐ தவற விட்ட release, signature headers-ஐ அகற்றும் CDN rule, அல்லது உங்கள் app's declarations-ஐ அனுப்புவதை நிறுத்திய frontend change.
• திடீர் குறைவு கூட சரிபார்க்க வேண்டியது. Unknown குறைந்து Human உயர்ந்தால், புதிய evidence வந்ததா அல்லது fallback அமைதியாக மாறிவிட்டதா என்பதை உறுதிப்படுத்துங்கள்.

Absolute level-களில் அல்ல, கடுமையான மாற்றங்களில் alert செய்யுங்கள். ஒவ்வொரு application-க்கும் அதன் சொந்த இயல்பு உண்டு.

Step 6: முக்கியமான இடங்களில் Unknown-ஐ எப்படி குறைப்பது?

நீங்கள் Unknown-ஐ zero-க்கு கொண்டு வர வேண்டியதில்லை. முடிவுகள் முக்கியமான routes-இல் போதுமான evidence தேவை. தாக்கம் அதிகமான வரிசையில் அவற்றைச் செய்யுங்கள்:

1. உயர் தாக்கம் உள்ள 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-ஐப் பயன்படுத்துங்கள். பயனர்கள் உங்கள் built-in assistant-உடன் தொடர்பு கொள்கிறார்கள் என்றால், அதை ஒரு declaration-ஆக பதிவு செய்யுங்கள். Network-ஐ விட உங்கள் app பெரும்பாலும் அதிகம் அறிந்திருக்கும்.
4. Plumbing-ஐ சரிசெய்யுங்கள். நீங்கள் நம்பும் headers-ஐ proxies forward செய்கிறார்களா, evaluation முடிவடைய போதுமான time budget இருக்கிறதா என்பதை உறுதிப்படுத்துங்கள்.

Traffic-ஐ Unknown-இலிருந்து வெளியே நகர்த்தும் signals-ஐ நடைமுறையில் பார்க்க, website traffic AI agents-இலிருந்து வருகிறது என்பதை எப்படி அறியலாம் என்பதைப் படியுங்கள்.

Step 7: Dashboards-இல் Unknown-ஐ நேர்மையாகக் காட்டுங்கள்

Unknown-ஐ மற்ற classes-க்கு இருக்கும் அதே visual weight-உடன் தனி series-ஆகக் காட்டுங்கள். அதை "other" bucket-இல் மறைக்காதீர்கள், alert போல வண்ணமிடாதீர்கள். Stakeholders பெரிய Unknown share-ஐப் பார்க்கும்போது, சரியான எதிர்வினை "எங்கு அதிக evidence தேவை" என்பதுதான், "bots எங்கு உள்ளன" என்பதல்ல.

Step 8: ஊகங்களால் அல்ல, outcomes-ஆல் Unknown-ஐ review செய்யுங்கள்

ஒவ்வொரு சில வாரங்களுக்கும், உங்கள் மிக முக்கியமான routes-இலிருந்து Unknown interactions-ன் ஒரு sample-ஐ எடுத்து, உண்மையில் என்ன நடந்தது என்பதைப் பாருங்கள். session ஒரு purchase-ஐ முடித்ததா, ஒரு project-ஐ உருவாக்கியதா, மூன்று articles-ஐ வாசித்ததா, அல்லது login-இல் மீண்டும் மீண்டும் தோல்வியடைந்ததா? Outcomes, அதற்கு முன் அவசரமாக ஒரு label ஒட்ட வேண்டாமல், அந்த bucket-இல் எந்த வகையான traffic இருக்கிறது என்பதைச் சொல்கின்றன.

நீங்கள் கண்டதை மூன்று நடைமுறை categories-ஆகக் குழுவாக்குங்கள்:

1. Legitimate மற்றும் low risk. Feed readers, link previews, monitoring tools மற்றும் privacy settings கொண்டவர்கள். Route fallback-ஐ அப்படியே வைத்திருங்கள்.
2. தங்களை அடையாளப்படுத்தக்கூடிய legitimate automation. நீங்கள் structured path ஒன்றை வழங்கினால் அல்லது requests-ஐ sign செய்ய முடிந்தால் அதைப் பயன்படுத்த விரும்பும் integrations மற்றும் agents. Guidance-ஐ வெளியிட்டு, எங்கு முடியுமோ அங்கே தொடர்பு கொள்ளுங்கள்.
3. தனது சொந்த control தேவைப்படும் நடத்தை. 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 சேர்க்க வேண்டும் என்பதற்கான தெளிவான பட்டியலை உங்களுக்குத் தருகிறது.

Common questions

Unknown rate limits-க்கு கணக்கில் எடுத்துக் கொள்ள வேண்டுமா? உங்கள் standard limits-ஐப் பயன்படுத்துங்கள். Verified agents-க்கு class அடிப்படையில் rate limiting செய்வது சரி, அவர்கள் அதிக limits-ஐப் பெற முடியும், ஆனால் Unknown-க்கு normal limit இருக்க வேண்டும், தண்டனை அளிப்பதுபோல் அல்ல.

Unknown users-ஐ challenge செய்ய முடியுமா? அந்த நிலைமையில் route ஏற்கனவே அனைவரையும் challenge செய்யும் இடங்களில் மட்டும். result Unknown என்பதற்காக மட்டும் challenge ஒன்றைச் சேர்ப்பது, குறைவான signals அனுப்பும் clients-ஐப் பயன்படுத்தும் legitimate users-ஐ தண்டிக்கும்.

Standards மேம்படும் போது Unknown குறையுமா? மேலும் automated clients requests-ஐ sign செய்யத் தொடங்கும் போது, மேலும் agent traffic Unknown அல்லது declared-இலிருந்து verified-க்கு நகரும். உங்கள் monitoring அந்த மாற்றத்தை route-by-route காட்டும்.

Proof of Actor எங்கு பொருந்துகிறது

Proof of Actor Unknown-ஐ first-class result-ஆக, காரணத்துடன், report செய்கிறது, மேலும் அதை ஒருபோதும் Human-ஆக மாற்றாது. உங்கள் application ஒவ்வொரு route-க்கும் fallback-ஐத் தேர்வு செய்கிறது, மேலும் analytics coverage எங்கு முடிகிறது என்பதை காட்டுகிறது, அதனால் முக்கியமான இடங்களில் evidence-ஐச் சேர்க்க முடியும்.

எங்கள் team-உடன் production application-இல் இதை அமைக்க, 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: உதாரணத்தில் பயன்படுத்தப்பட்ட node:test module