ನಿಮ್ಮ app ನಲ್ಲಿ Unknown traffic ಅನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುವುದು

Unknown ಒಂದು error ಆಗಿದೆಯೇ ಅಥವಾ ಒಂದು result ಆಗಿದೆಯೇ?

ನೀವು interactions ಗಳನ್ನು Human, Human + AI, Agent ಅಥವಾ Unknown ಎಂದು classify ಮಾಡಲು ಆರಂಭಿಸಿದಾಗ, Unknown bucket ಸಾಮಾನ್ಯವಾಗಿ ಜನರು ನಿರೀಕ್ಷಿಸುವುದಕ್ಕಿಂತ ದೊಡ್ಡದಾಗಿರುತ್ತದೆ. ಅದನ್ನು ಒಂದು gap ಎಂದು ನೋಡಿ ಮರೆಮಾಚಲು, ಅಂದರೆ Unknown ಅನ್ನು Human ಒಳಗೆ ಸೇರಿಸಿ ಅಥವಾ ಅದನ್ನು suspicious ಎಂದು ಪರಿಗಣಿಸಿ, ಪ್ರಲೋಭನ ಉಂಟಾಗುತ್ತದೆ. ಎರಡೂ ಆಯ್ಕೆಗಳು ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ.

Unknown ಎಂದರೆ ಲಭ್ಯವಿರುವ evidence ವಿಶ್ವಾಸಾರ್ಹ ನಿರ್ಧಾರವನ್ನು support ಮಾಡುವುದಿಲ್ಲ. ಯಾವುದೇ JavaScript ಅನ್ನು run ಮಾಡದ client ನಿಂದ ಬಂದ request, ನೀವು ಯಾವುದೇ signals ಸಂಗ್ರಹಿಸದ endpoint ಗೆ ಮಾಡಿದ call, ಅಥವಾ ಒಂದು ಪುಟದ ನಂತರವೇ ಮುಗಿದ session: ಇವೆಲ್ಲವೂ ಸಂಪೂರ್ಣ legitimate ಆಗಿರಬಹುದು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ acting ಮಾಡುತ್ತಿದ್ದವರು ಯಾರು ಅಥವಾ ಏನು ಎಂಬುದನ್ನು ಹೇಳಲು ಸಾಕಷ್ಟು ಮಾಹಿತಿ ನೀಡುವುದಿಲ್ಲ.

Unknown ಅನ್ನು ಪ್ರಾಮಾಣಿಕವಾಗಿ report ಮಾಡುವುದೇ ಇತರ classes ಗಳನ್ನು trustworthy ಆಗಿ ಇಡುತ್ತದೆ. ನಿಮ್ಮ system ಎಂದಿಗೂ Unknown ಎಂದು ಹೇಳದಿದ್ದರೆ, ಪ್ರತಿ Human result ಕೂಡ ಭಾಗಶಃ ಒಂದು ಊಹೆಯೇ ಆಗಿರುತ್ತದೆ, ಮತ್ತು ಯಾವ ಭಾಗ ಎಂಬುದು ನಿಮಗೆ ತಿಳಿಯದು. AI traffic ಅನ್ನು classify ಮಾಡುವಾಗ Unknown ಒಂದು valid result ಏಕೆ ಎಂಬುದರ ಬಗ್ಗೆ ನಮ್ಮ post (/blog/why-unknown-is-a-valid-result-for-ai-traffic) ನಲ್ಲಿ reasoning ಅನ್ನು ಇನ್ನಷ್ಟು ವಿವರವಾಗಿ ನೀಡಲಾಗಿದೆ.

ಈ guide ನಲ್ಲಿ practical ಆಗಿ Unknown ಅನ್ನು ಹೇಗೆ handle ಮಾಡಬೇಕು ಎಂಬುದು ಇದೆ: explicit per-route fallback ಗಳು, ಅದನ್ನು ಇತರ classes ಗಳಿಗೆ leak ಆಗದಂತೆ ತಡೆಯುವ rules, ಅದನ್ನು ಹೇಗೆ monitor ಮಾಡಬೇಕು, ಮತ್ತು ಅಗತ್ಯವಿರುವ ಕಡೆ ಅದನ್ನು ಹೇಗೆ reduce ಮಾಡಬೇಕು ಎಂಬುದು.

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 entries ಮತ್ತು missing telemetry ಎಲ್ಲವೂ Unknown ಅನ್ನು ಉತ್ಪಾದಿಸಬೇಕು. ಈ ಪ್ರತಿಯೊಂದು path ಗೆ 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 ನಲ್ಲಿ ಉಳಿಸಿ. ಈ fallback ಗಳು ವಿಶಾಲ policy model ಗೆ ಹೇಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತವೆ ಎಂಬುದಕ್ಕೆ, humans ಮತ್ತು AI agents ಗಾಗಿ app-level policies ವಿನ್ಯಾಸಗೊಳಿಸುವುದು ನೋಡಿ.

Pattern ಸರಳವಾಗಿದೆ. ಕಡಿಮೆ risk ಇರುವ routes ಗಾಗಿ, Unknown ಸಾಮಾನ್ಯ traffic ನಂತೆ ನಡೆದುಕೊಳ್ಳುತ್ತದೆ. ಹೆಚ್ಚು risk ಇರುವ routes ಗಾಗಿ, Unknown route ಈಗಾಗಲೇ ಹೊಂದಿರುವ ಅದೇ protection ಅನ್ನು ಪಡೆಯುತ್ತದೆ. ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ, actor result ಗುರುತಿಸಲಾಗದ ಆದರೆ legitimate ಬಳಕೆದಾರನಿಗೆ ಪರಿಸ್ಥಿತಿಯನ್ನು ಇನ್ನಷ್ಟು ಕೆಡಿಸುವುದಿಲ್ಲ.

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 ಅನ್ನು 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 ಏಕೆ ಎಂಬುದನ್ನು ದಾಖಲಿಸಿ: no evidence, timeout, evaluation error ಅಥವಾ stale evidence. ಆ ಕಾರಣಗಳು ನೀವು ಏನು fix ಮಾಡಬೇಕು ಎಂಬುದನ್ನು ಹೇಳುತ್ತವೆ.

Step 4: Unknown ಅನ್ನು suspicious ಎಂದು ಪರಿಗಣಿಸಬೇಡಿ

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 ಮತ್ತು ಪ್ರಕಟಿತ IP ranges ಮೂಲಕ ಗುರುತಿಸುತ್ತಾರೆ. ಉದಾಹರಣೆಗೆ, OpenAI's crawler documentation ನಲ್ಲಿ November 2026 ರ ವೇಳೆಗೆ ಅದರ ಪ್ರತಿಯೊಂದು bot ಗಾಗಿ user agent string ಮತ್ತು ಪ್ರಕಟಿತ IP address file ಪಟ್ಟಿ ಮಾಡಲಾಗಿದೆ.

ನೀವು suspicious behavior ಮೇಲೆ ಕ್ರಮ ಕೈಗೊಳ್ಳಲು ಬಯಸಿದರೆ, request rates, failed login patterns ಅಥವಾ abuse reports ಮುಂತಾದ ನೀವು ವಿವರಿಸಬಹುದಾದ behavior ಗಳನ್ನು ಆಧಾರವಾಗಿಸಿ, ಮತ್ತು ಅದಕ್ಕೆ ತನ್ನದೇ ಆದ evidence ಇರಲಿ. ಆ logic ಅನ್ನು actor class ನಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿಡಿ, ಹೀಗಾಗಿ ಯಾವುದೂ ಮತ್ತೊಂದನ್ನು distort ಮಾಡದಿರಲಿ.

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 ಎಂದಿಗೂ load ಆಗದ page, ಅಥವಾ signed requests ಅನ್ನು ಎಂದಿಗೂ ನೋಡದ API, ಹೆಚ್ಚಾಗಿ Unknown ಆಗಿಯೇ ಇರುತ್ತದೆ.
• ಅಚಾನಕ್ ಏರಿಕೆ ಆಗಾಗ್ಗೆ ನಿಮ್ಮ stack ನಲ್ಲಿ ಏನೋ ಬದಲಾದಿತೆಂದು ಅರ್ಥ, ಉದಾಹರಣೆಗೆ header ಅನ್ನು ಕೈಬಿಟ್ಟ release, signature headers ಅನ್ನು strip ಮಾಡುವ CDN rule, ಅಥವಾ ನಿಮ್ಮ app's declarations ಅನ್ನು ಕಳುಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದ frontend change.
• ಅಚಾನಕ್ ಇಳಿಕೆ ಕೂಡ ಪರಿಶೀಲನೆಗೆ ಅರ್ಹ. Unknown ಇಳಿದು Human ಏರಿದರೆ, ಹೊಸ evidence ಬಂದಿದೆಯೇ ಹೊರತು fallback ಶಾಂತವಾಗಿ ಬದಲಾಗಿದೆಯೇ ಎಂದು ದೃಢಪಡಿಸಿ.

ತೀವ್ರ ಬದಲಾವಣೆಗಳ ಮೇಲೆ alert ಮಾಡಿ, absolute ಮಟ್ಟಗಳ ಮೇಲೆ ಅಲ್ಲ. ಪ್ರತಿಯೊಂದು application ಕ್ಕೂ ತನ್ನದೇ ಆದ normal ಇರುತ್ತದೆ.

Step 6: ಅಗತ್ಯವಿರುವ ಕಡೆ Unknown ಅನ್ನು ಹೇಗೆ ಕಡಿಮೆ ಮಾಡಬೇಕು?

ನೀವು Unknown ಅನ್ನು ಶೂನ್ಯಕ್ಕೆ ತಲುಪಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ನಿರ್ಧಾರಗಳು ಮುಖ್ಯವಾಗಿರುವ routes ಗಳಲ್ಲಿ ಸಾಕಷ್ಟು evidence ಬೇಕು. ಪ್ರಭಾವದ ಕ್ರಮದಲ್ಲಿ ಅವುಗಳ ಮೂಲಕ ಕೆಲಸ ಮಾಡಿ:

1. ಮೊದಲು ಹೆಚ್ಚಿನ ಪ್ರಭಾವದ routes ಗಳಿಗೆ evidence ಸೇರಿಸಿ. Account changes ಹೆಚ್ಚಾಗಿ Unknown ಆಗಿದ್ದರೆ, ಅಲ್ಲಿ browser integration ಅಥವಾ server-side check ಹೆಚ್ಚು ಪ್ರಯೋಜನ ನೀಡುತ್ತದೆ.
2. ಸ್ವಯಂಚಾಲಿತ clients ಗಳು ತಮಗೇ ಗುರುತಿಸಿಕೊಳ್ಳುವಂತೆ ಆಹ್ವಾನಿಸಿ. ನಿಮ್ಮ API ಗೆ documentation ಪ್ರಕಟಿಸಿ, agents ಗಳು HTTP Message Signatures ಮತ್ತು IETF Web Bot Auth conventions ಬಳಸಿ requests ಗಳಿಗೆ ಹೇಗೆ sign ಮಾಡಬಹುದು ಎಂದು ವಿವರಿಸಿ, ಮತ್ತು verified clients ಗಳಿಗೆ ಹೆಚ್ಚು ಉತ್ತಮ ಅನುಭವವನ್ನು ನೀಡಿ, ಉದಾಹರಣೆಗೆ higher limits ಅಥವಾ structured responses. verify ಮಾಡಬಹುದಾದ clients ಹಾಗೆ ಮಾಡಲು ಆರಂಭಿಸುತ್ತವೆ.
3. ನಿಮ್ಮದೇ application knowledge ಅನ್ನು ಬಳಸಿ. ಬಳಕೆದಾರರು ನಿಮ್ಮ built-in assistant ಜೊತೆ ಸಂವಹನ ಮಾಡಿದರೆ, ಅದನ್ನು declaration ಆಗಿ ದಾಖಲಿಸಿ. ನಿಮ್ಮ app ಬಹುಸಾರಿ network ಗಿಂತ ಹೆಚ್ಚು ತಿಳಿದುಕೊಂಡಿರುತ್ತದೆ.
4. Plumbing ಅನ್ನು fix ಮಾಡಿ. ನೀವು ಅವಲಂಬಿಸಿರುವ headers ಗಳನ್ನು proxies forward ಮಾಡುತ್ತಿವೆಯೇ ಮತ್ತು evaluation ಪೂರ್ಣಗೊಳ್ಳಲು ಸಾಕಷ್ಟು time budget ಇದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.

Unknown ನಿಂದ traffic ಅನ್ನು ಹೊರತೆಗೆಸುವ signals ಗಳನ್ನು ಪ್ರಾಯೋಗಿಕವಾಗಿ ನೋಡಲು, website traffic AI agents ಗಳಿಂದ ಬರುತ್ತಿದೆಯೇ ಎಂದು ಹೇಗೆ ಗುರುತಿಸುವುದು ಓದಿ.

Step 7: Dashboards ನಲ್ಲಿ Unknown ಅನ್ನು ಪ್ರಾಮಾಣಿಕವಾಗಿ ತೋರಿಸಿ

Unknown ಅನ್ನು ಇತರ classes ಗಳಷ್ಟೇ visual weight ಇರುವ ತನ್ನದೇ ಆದ series ಆಗಿ ಪ್ರದರ್ಶಿಸಿ. ಅದನ್ನು "other" bucket ನಲ್ಲಿ ಮರೆಮಾಡಬೇಡಿ, ಮತ್ತು alert ನಂತೆ color ಮಾಡಬೇಡಿ. Stakeholders ದೊಡ್ಡ Unknown share ಅನ್ನು ನೋಡಿದಾಗ, ಸರಿಯಾದ ಪ್ರತಿಕ್ರಿಯೆ "ನಮಗೆ ಇನ್ನಷ್ಟು evidence ಎಲ್ಲ ಬೇಕು" ಆಗಿರಬೇಕು, "bots ಎಲ್ಲಿವೆ" ಅಲ್ಲ.

Step 8: ಊಹೆಗಳಲ್ಲ, outcomes ಗಳೊಂದಿಗೆ Unknown ಅನ್ನು review ಮಾಡಿ

ಪ್ರತಿ ಕೆಲವು ವಾರಗಳಿಗೊಮ್ಮೆ, ನಿಮ್ಮ ಅತ್ಯಂತ ಮುಖ್ಯ routes ಗಳಿಂದ Unknown interactions ಗಳ ಒಂದು sample ತೆಗೆದುಕೊಂಡು, ವಾಸ್ತವವಾಗಿ ಏನಾಯಿತು ಎಂದು ನೋಡಿ. Session purchase ಪೂರ್ಣಗೊಳಿಸಿತೇ, project ಸೃಷ್ಟಿಸಿತೇ, ಮೂರು articles ಓದಿತೇ, ಅಥವಾ login ನಲ್ಲಿ ಮರುಮರು ವಿಫಲವಾದಿತೇ? Outcomes ಗಳು ಆ bucket ನಲ್ಲಿ ಯಾವ ತರಹದ traffic ಇದೆ ಎಂಬುದನ್ನು ಹೇಳುತ್ತವೆ, ಅದಕ್ಕೆ ಮುಂಚಿತ label ಅನ್ನು ಒತ್ತಾಯಿಸದೇ.

ನೀವು ಕಂಡುಕೊಂಡಿರುವುದನ್ನು ಮೂರು ಪ್ರಾಯೋಗಿಕ ವರ್ಗಗಳಾಗಿ ಗುಂಪುಮಾಡಿ:

1. Legitimate ಮತ್ತು ಕಡಿಮೆ risk. Feed readers, link previews, monitoring tools ಮತ್ತು privacy settings ಹೊಂದಿರುವ ಜನರು. Route fallback ಅನ್ನು ಇದ್ದಂತೆ ಉಳಿಸಿ.
2. ತಮ್ಮನ್ನು ತಾವೇ ಗುರುತಿಸಿಕೊಳ್ಳಬಹುದಾದ legitimate automation. ನೀವು structured path ಅಥವಾ sign requests ನೀಡಿದರೆ ಸಂತೋಷದಿಂದ ಬಳಸುವ 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 ನಿಮ್ಮ fallback ಗಳನ್ನು ನಿಮ್ಮ ನೈಜ traffic ನಲ್ಲಿ ನೆಲೆಗೆ ಇಡುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ evidence ಅನ್ನು ಎಲ್ಲಿಗೆ ಸೇರಿಸಬೇಕು ಎಂಬುದರ ಸ್ಪಷ್ಟ ಪಟ್ಟಿಯನ್ನು ನಿಮಗೆ ನೀಡುತ್ತದೆ.

ಸಾಮಾನ್ಯ ಪ್ರಶ್ನೆಗಳು

Unknown rate limits ಗೆ count ಆಗಬೇಕೇ? ನಿಮ್ಮ standard limits ಅನ್ನು ಬಳಸಿ. Verified agents ಗಳಿಗೆ class ಆಧಾರಿತ rate limiting ಸೂಕ್ತವಾಗಿದೆ, ಏಕೆಂದರೆ ಅವರು ಹೆಚ್ಚಿನ limits ಗಳನ್ನು ಗಳಿಸಬಹುದು, ಆದರೆ Unknown ಗೆ ಸಾಮಾನ್ಯ limit ಇರಬೇಕು, ದಂಡಾತ್ಮಕವಾದದ್ದು ಅಲ್ಲ.

Unknown users ಗಳಿಗೆ challenge ಮಾಡಬಹುದೇ? ಆ route ಈಗಾಗಲೇ ಆ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಎಲ್ಲರಿಗೂ challenge ಮಾಡುವಲ್ಲಿ ಮಾತ್ರ. ಒಂದು result Unknown ಆದ್ದರಿಂದ ಮಾತ್ರ challenge ಸೇರಿಸುವುದು ಕಡಿಮೆ signals ಕಳುಹಿಸುವ legitimate users ಗಳಿಗೆ ಅನ್ಯಾಯವಾಗುತ್ತದೆ.

Standards mature ಆದಂತೆ Unknown shrink ಆಗುತ್ತದೆಯೇ? ಹೆಚ್ಚು 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 ಗೆ convert ಮಾಡುವುದಿಲ್ಲ. ನಿಮ್ಮ application ಪ್ರತಿ route ಗೆ fallback ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು analytics coverage ಎಲ್ಲಿ ಮುಗಿಯುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತವೆ, ಹೀಗಾಗಿ ನೀವು ಅಗತ್ಯವಿರುವ ಕಡೆ evidence ಸೇರಿಸಬಹುದು.

ನಮ್ಮ ತಂಡದೊಂದಿಗೆ production application ನಲ್ಲಿ ಇದನ್ನು set up ಮಾಡಲು, early access ಗೆ apply ಮಾಡಿ. evidence ನಿಖರವಾಗಿ ಏನು establish ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ತಿಳಿದುಕೊಳ್ಳಲು, 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 ಮತ್ತು ಪ್ರಕಟಿತ IP address files
• OWASP Automated Threats to Web Applications: credential stuffing ಮತ್ತು scraping ಮುಂತಾದ automated threats ಗಳ taxonomy
• Node.js test runner: ಉದಾಹರಣೆಯಲ್ಲಿ ಬಳಸಿದ node:test module