ਆਪਣੇ app ਵਿੱਚ Unknown traffic ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਣਾ ਹੈ

ਕੀ Unknown ਇੱਕ error ਹੈ ਜਾਂ ਇੱਕ ਨਤੀਜਾ?

ਜਦੋਂ ਤੁਸੀਂ interactions ਨੂੰ Human, Human + AI, Agent ਜਾਂ Unknown ਵਜੋਂ classify ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ, ਤਾਂ Unknown bucket ਅਕਸਰ ਲੋਕਾਂ ਦੀ ਉਮੀਦ ਨਾਲੋਂ ਵੱਡੀ ਹੁੰਦੀ ਹੈ। ਇਸਨੂੰ ਇੱਕ ਐਸੀ ਖਾਲੀ ਥਾਂ ਵਜੋਂ ਦੇਖਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਜਿਸਨੂੰ ਲੁਕਾ ਦਿੱਤਾ ਜਾਵੇ, ਜਾਂ ਤਾਂ Unknown ਨੂੰ Human ਵਿੱਚ ਮਿਲਾ ਕੇ ਜਾਂ ਇਸਨੂੰ ਸ਼ੱਕੀ ਮੰਨ ਕੇ। ਦੋਵੇਂ ਚੋਣਾਂ ਸਮੱਸਿਆ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ।

Unknown ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਉਪਲਬਧ evidence ਭਰੋਸੇਯੋਗ ਨਿਰਣੈ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ। ਇੱਕ client ਤੋਂ ਆਈ request ਜੋ ਕੋਈ JavaScript ਨਹੀਂ ਚਲਾਉਂਦਾ, ਕਿਸੇ endpoint ਨੂੰ ਕੀਤਾ call ਜਿੱਥੇ ਤੁਸੀਂ ਕੋਈ signals ਇਕੱਠੇ ਨਹੀਂ ਕਰਦੇ, ਇੱਕ session ਜੋ ਇੱਕ page ਤੋਂ ਬਾਅਦ ਖਤਮ ਹੋ ਗਈ: ਇਹ ਸਭ ਬਿਲਕੁਲ ਵਾਜਬ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਇਹ ਕਹਿਣ ਲਈ ਕਾਫ਼ੀ ਜਾਣਕਾਰੀ ਨਹੀਂ ਦਿੰਦਾ ਕਿ ਕੌਣ ਜਾਂ ਕੀ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ।

Unknown ਨੂੰ ਇਮਾਨਦਾਰੀ ਨਾਲ report ਕਰਨਾ ਹੀ ਹੋਰ classes ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਈ ਰੱਖਦਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ system ਕਦੇ Unknown ਨਹੀਂ ਕਹਿੰਦਾ, ਤਾਂ ਹਰ Human ਨਤੀਜਾ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਇੱਕ ਅਨੁਮਾਨ ਬਣ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਕਿ ਕਿਹੜਾ ਹਿੱਸਾ ਅਨੁਮਾਨ ਸੀ। AI traffic ਨੂੰ classify ਕਰਦੇ ਸਮੇਂ Unknown ਇੱਕ ਵਾਜਬ ਨਤੀਜਾ ਕਿਉਂ ਹੈ, ਇਸ ਬਾਰੇ ਸਾਡੀ post ਇਥੇ ਹੋਰ ਗਹਿਰਾਈ ਨਾਲ ਤਰਕ ਸਮਝਾਉਂਦੀ ਹੈ.

ਇਹ guide ਇਸ ਗੱਲ ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ ਕਿ practical ਤੌਰ 'ਤੇ Unknown ਨੂੰ ਕਿਵੇਂ handle ਕਰਨਾ ਹੈ: explicit per-route fallbacks, ਉਹ rules ਜੋ ਇਸਨੂੰ ਹੋਰ classes ਵਿੱਚ ਲੀਕ ਹੋਣ ਤੋਂ ਰੋਕਦੇ ਹਨ, ਇਸਦੀ ਨਿਗਰਾਨੀ ਕਿਵੇਂ ਕਰਨੀ ਹੈ, ਅਤੇ ਜਿੱਥੇ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ ਉੱਥੇ ਇਸਨੂੰ ਕਿਵੇਂ ਘਟਾਉਣਾ ਹੈ।

ਕਦਮ 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 ਨਾ ਕਰੇ। ਹੇਠਾਂ ਦਿੱਤਾ ਉਦਾਹਰਣ 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 ਨੂੰ ਇੱਕ defined behavior ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਸਹੀ behavior route 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਇਸਨੂੰ ਹਰ route ਲਈ ਤੈਅ ਕਰੋ, ਲਿਖੋ, ਅਤੇ configuration ਵਿੱਚ ਰੱਖੋ। ਇਹ fallbacks ਇੱਕ ਵੱਡੇ policy model ਵਿੱਚ ਕਿਵੇਂ fit ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ humans ਅਤੇ AI agents ਲਈ app-level policies ਕਿਵੇਂ design ਕਰਨੀ ਹੈ ਵੇਖੋ।

Pattern ਸਧਾਰਨ ਹੈ। ਘੱਟ risk ਵਾਲੇ routes ਲਈ, Unknown ਆਮ traffic ਵਾਂਗ ਵਰਤਦਾ ਹੈ। ਉੱਚ risk ਵਾਲੇ routes ਲਈ, Unknown ਨੂੰ ਉਹੀ protection ਮਿਲਦੀ ਹੈ ਜੋ route ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਹੈ। ਦੋਵੇਂ ਹਾਲਤਾਂ ਵਿੱਚ 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",
};

ਕਦਮ 3: timeout ਅਤੇ error ਨੂੰ ਇੱਕੋ ਤਰੀਕੇ ਨਾਲ handle ਕਰੋ

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 ਕਿਉਂ ਹੈ: ਕੋਈ evidence ਨਹੀਂ, timeout, evaluation error, ਜਾਂ stale evidence। ਇਹ reasons ਤੁਹਾਨੂੰ ਦੱਸਦੇ ਹਨ ਕਿ ਕੀ ਠੀਕ ਕਰਨਾ ਹੈ।

ਕਦਮ 4: Unknown ਨੂੰ ਸ਼ੱਕੀ ਨਾ ਮੰਨੋ

Unknown risk score ਨਹੀਂ ਹੁੰਦਾ। ਕਈ legitimate clients ਕੁਝ routes 'ਤੇ ਹਮੇਸ਼ਾ Unknown ਰਹਿਣਗੇ: command-line tools, server-side integrations ਬਿਨਾਂ signatures ਦੇ, accessibility tools, privacy-focused browsers ਅਤੇ ਸਧਾਰਨ feed readers। ਅੱਜ ਵੱਡੇ AI operators ਵੀ ਅਕਸਰ ਆਪਣੇ fetchers ਨੂੰ user agent ਅਤੇ published IP ranges ਨਾਲ ਪਛਾਣਦੇ ਹਨ। ਉਦਾਹਰਨ ਵਜੋਂ, OpenAI ਦੀ crawler documentation November 2026 ਤੱਕ ਆਪਣੇ bots ਲਈ ਇੱਕ user agent string ਅਤੇ ਇੱਕ published IP address file ਸੂਚੀਬੱਧ ਕਰਦੀ ਹੈ।

ਜੇ ਤੁਸੀਂ ਸ਼ੱਕੀ behavior 'ਤੇ ਕਾਰਵਾਈ ਕਰਨੀ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਐਸੇ behavior 'ਤੇ ਅਧਾਰਿਤ ਕਰੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਵਰਣਨ ਕਰ ਸਕੋ, ਜਿਵੇਂ request rates, failed login patterns ਜਾਂ abuse reports, ਆਪਣੀ ਵੱਖਰੀ evidence ਨਾਲ। ਇਸ logic ਨੂੰ actor class ਤੋਂ ਵੱਖ ਰੱਖੋ ਤਾਂ ਜੋ ਇੱਕ ਦੂਜੇ ਨੂੰ distort ਨਾ ਕਰੇ।

ਕਦਮ 5: ਆਪਣੀ unknown rate ਦੀ ਨਿਗਰਾਨੀ ਕਿਵੇਂ ਕਰਨੀ ਹੈ?

Unknown rate ਉਹ ਹਿੱਸਾ ਹੈ ਜਿੰਨ੍ਹਾਂ interactions ਨੂੰ Unknown ਵਜੋਂ classify ਕੀਤਾ ਗਿਆ ਹੈ। ਇਸਨੂੰ ਹਰ 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 ਦੀ ਘਾਟ ਹੈ। ਇੱਕ page ਜੋ ਕਦੇ ਵੀ ਤੁਹਾਡੀ browser integration ਨਹੀਂ ਲੋਡ ਕਰਦੀ, ਜਾਂ ਇੱਕ API ਜੋ ਕਦੇ ਵੀ signed requests ਨਹੀਂ ਵੇਖਦੀ, ਉਹ ਜ਼ਿਆਦਾਤਰ Unknown ਹੀ ਰਹੇਗੀ।
• ਅਚਾਨਕ ਵਾਧਾ ਅਕਸਰ ਇਸ ਗੱਲ ਦਾ ਸੰਕੇਤ ਹੁੰਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ stack ਵਿੱਚ ਕੁਝ ਬਦਲਿਆ ਹੈ, ਉਦਾਹਰਨ ਵਜੋਂ ਇੱਕ release ਜਿਸ ਨੇ header ਹਟਾ ਦਿੱਤਾ, ਇੱਕ CDN rule ਜੋ signature headers strip ਕਰਦੀ ਹੈ, ਜਾਂ ਇੱਕ frontend change ਜਿਸ ਨੇ ਤੁਹਾਡੀ app ਦੀਆਂ declarations ਭੇਜਣੀਆਂ ਬੰਦ ਕਰ ਦਿੱਤੀਆਂ।
• ਅਚਾਨਕ ਕਮੀ ਵੀ ਦੇਖਣ ਯੋਗ ਹੈ। ਜੇ Unknown ਘਟਦਾ ਹੈ ਜਦੋਂ ਕਿ Human ਵਧਦਾ ਹੈ, ਤਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਨਵਾਂ evidence ਆਇਆ ਹੈ, ਨਾ ਕਿ fallback ਚੁੱਪਚਾਪ ਬਦਲ ਗਿਆ ਹੈ।

ਤੇਜ਼ ਬਦਲਾਵਾਂ 'ਤੇ alert ਕਰੋ, absolute levels 'ਤੇ ਨਹੀਂ। ਹਰ application ਦਾ ਆਪਣਾ normal ਹੁੰਦਾ ਹੈ।

ਕਦਮ 6: ਜਿੱਥੇ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ ਉੱਥੇ Unknown ਨੂੰ ਕਿਵੇਂ ਘਟਾਉਣਾ ਹੈ?

ਤੁਹਾਨੂੰ Unknown ਨੂੰ zero ਤੱਕ ਲਿਜਾਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਤੁਹਾਨੂੰ ਉਹਨਾਂ routes 'ਤੇ ਕਾਫ਼ੀ evidence ਦੀ ਲੋੜ ਹੈ ਜਿੱਥੇ decisions ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ। ਪ੍ਰਭਾਵ ਦੇ ਕ੍ਰਮ ਵਿੱਚ ਇਨ੍ਹਾਂ 'ਤੇ ਕੰਮ ਕਰੋ:

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 ਨੂੰ ਇੱਕ ਬਿਹਤਰ experience ਦਿਓ, ਜਿਵੇਂ ਉੱਚ limits ਜਾਂ structured responses। ਜੋ clients verify ਕਰ ਸਕਦੇ ਹਨ ਉਹ ਇਹ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦੇਣਗੇ।
3. ਆਪਣੀ application knowledge ਵਰਤੋ। ਜੇ users ਤੁਹਾਡੇ built-in assistant ਨਾਲ interact ਕਰਦੇ ਹਨ, ਤਾਂ ਇਸਨੂੰ ਇੱਕ declaration ਵਜੋਂ ਦਰਜ ਕਰੋ। ਤੁਹਾਡੀ app ਅਕਸਰ network ਨਾਲੋਂ ਵੱਧ ਜਾਣਦੀ ਹੈ।
4. Plumbing ਠੀਕ ਕਰੋ। ਯਕੀਨੀ ਬਣਾਓ ਕਿ proxies ਉਹ headers ਅੱਗੇ ਭੇਜਦੇ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਤੁਸੀਂ ਨਿਰਭਰ ਕਰਦੇ ਹੋ ਅਤੇ ਕਿ evaluation ਪੂਰੀ ਹੋਣ ਲਈ ਕਾਫ਼ੀ time budget ਰੱਖਦੀ ਹੈ।

Unknown ਤੋਂ traffic ਨੂੰ ਬਾਹਰ ਲਿਜਾਣ ਵਾਲੇ signals ਦਾ practical ਦੇਖਣ ਲਈ, ਕਿਵੇਂ ਪਤਾ ਕਰਨਾ ਹੈ ਕਿ website traffic AI agents ਤੋਂ ਆ ਰਹੀ ਹੈ ਪੜ੍ਹੋ।

ਕਦਮ 7: Dashboards ਵਿੱਚ Unknown ਨੂੰ ਇਮਾਨਦਾਰੀ ਨਾਲ ਦਿਖਾਓ

Unknown ਨੂੰ ਹੋਰ classes ਦੇ ਬਰਾਬਰ visual weight ਨਾਲ ਆਪਣੀ ਹੀ series ਵਜੋਂ ਦਿਖਾਓ। ਇਸਨੂੰ "other" bucket ਵਿੱਚ ਨਾ ਲੁਕਾਓ, ਅਤੇ ਨਾ ਹੀ ਇਸਨੂੰ alert ਵਰਗਾ ਰੰਗ ਦਿਓ। ਜਦੋਂ stakeholders ਇੱਕ ਵੱਡਾ Unknown share ਵੇਖਦੇ ਹਨ, ਤਾਂ ਸਹੀ ਪ੍ਰਤੀਕਿਰਿਆ ਹੁੰਦੀ ਹੈ "ਸਾਨੂੰ ਹੋਰ evidence ਕਿੱਥੇ ਚਾਹੀਦਾ ਹੈ", ਨਾ ਕਿ "bots ਕਿੱਥੇ ਹਨ"।

ਕਦਮ 8: Unknown ਦੀ ਸਮੀਖਿਆ outcomes ਨਾਲ ਕਰੋ, ਅਟਕਲਾਂ ਨਾਲ ਨਹੀਂ

ਹਰ ਕੁਝ ਹਫ਼ਤਿਆਂ ਵਿੱਚ, ਆਪਣੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ routes ਤੋਂ Unknown interactions ਦਾ ਇੱਕ sample ਲਓ ਅਤੇ ਵੇਖੋ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਹੋਇਆ। ਕੀ session ਨੇ ਖਰੀਦ ਪੂਰੀ ਕੀਤੀ, ਇੱਕ project ਬਣਾਇਆ, ਤਿੰਨ articles ਪੜ੍ਹੀਆਂ, ਜਾਂ login 'ਤੇ ਵਾਰ-ਵਾਰ ਅਸਫਲ ਰਹੀ? Outcomes ਤੁਹਾਨੂੰ ਦੱਸਦੇ ਹਨ ਕਿ bucket ਵਿੱਚ ਕਿਹੋ ਜਿਹਾ traffic ਹੈ ਬਿਨਾਂ ਇਸ 'ਤੇ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਲੇਬਲ ਲਗਾਏ।

ਜੋ ਕੁਝ ਤੁਸੀਂ ਲੱਭਦੇ ਹੋ, ਉਸਨੂੰ ਤਿੰਨ practical categories ਵਿੱਚ ਵੰਡੋ:

1. Legitimate ਅਤੇ low risk। Feed readers, link previews, monitoring tools ਅਤੇ privacy settings ਵਾਲੇ ਲੋਕ। Route fallback ਨੂੰ ਜਿਵੇਂ ਹੈ ਤਿਵੇਂ ਰੱਖੋ।
2. Legitimate automation ਜੋ ਆਪਣੇ ਆਪ ਨੂੰ ਪਛਾਣ ਸਕਦੀ ਹੈ। Integrations ਅਤੇ agents ਜੋ structured path ਵਰਤਣਾ ਜਾਂ requests sign ਕਰਨਾ ਖੁਸ਼ੀ ਨਾਲ ਕਰਣਗੇ ਜੇ ਤੁਸੀਂ ਵਿਕਲਪ ਦਿਓ। Guidance ਪ੍ਰਕਾਸ਼ਤ ਕਰੋ ਅਤੇ ਜਿੱਥੇ ਹੋ ਸਕੇ ਸੰਪਰਕ ਕਰੋ।
3. Behavior ਜਿਸਨੂੰ ਆਪਣਾ control ਚਾਹੀਦਾ ਹੈ। Credential stuffing ਜਾਂ scraping patterns, ਦੋਵੇਂ OWASP Automated Threats to Web Applications project ਵਿੱਚ ਦਰਜ ਹਨ। ਇਨ੍ਹਾਂ ਨੂੰ behavior-based controls ਨਾਲ address ਕਰੋ ਜਿਨ੍ਹਾਂ ਦੀ ਆਪਣੀ evidence ਹੋਵੇ, ਜਿਵੇਂ login failure rates, ਅਤੇ ਇਨ੍ਹਾਂ ਨੂੰ actor class ਤੋਂ ਵੱਖ ਰੱਖੋ।

ਇਹ ਸਮੀਖਿਆ ਤੁਹਾਡੇ fallbacks ਨੂੰ ਤੁਹਾਡੇ ਅਸਲੀ traffic ਵਿੱਚ ਜ਼ਮੀਨ ਨਾਲ ਜੋੜੀ ਰੱਖਦੀ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਅਗਲਾ evidence ਕਿੱਥੇ ਜੋੜਣਾ ਹੈ, ਇਸਦੀ ਇੱਕ ਸਪਸ਼ਟ ਸੂਚੀ ਦਿੰਦੀ ਹੈ।

ਆਮ ਸਵਾਲ

ਕੀ Unknown ਨੂੰ rate limits ਵਿੱਚ ਗਿਣਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ? ਆਪਣੀਆਂ standard limits ਵਰਤੋ। Class ਦੇ ਆਧਾਰ 'ਤੇ rate limiting verified agents ਲਈ ਠੀਕ ਹੈ, ਜੋ ਉੱਚ limits ਹਾਸਲ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ Unknown ਨੂੰ normal limit ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਸਜ਼ਾਮੁਲਕ ਨਹੀਂ।

ਕੀ ਅਸੀਂ Unknown users ਨੂੰ challenge ਕਰ ਸਕਦੇ ਹਾਂ? ਸਿਰਫ਼ ਉੱਥੇ ਜਿੱਥੇ route ਪਹਿਲਾਂ ਹੀ ਉਸ ਸਥਿਤੀ ਵਿੱਚ ਸਭ ਨੂੰ challenge ਕਰਦੀ ਹੈ। ਸਿਰਫ਼ ਇਸ ਕਰਕੇ ਕਿ ਨਤੀਜਾ Unknown ਹੈ, challenge ਜੋੜਨਾ legitimate users ਨੂੰ ਸਜ਼ਾ ਦਿੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੇ clients ਘੱਟ signals ਭੇਜਦੇ ਹਨ।

ਕੀ standards mature ਹੋਣ ਨਾਲ Unknown ਘਟੇਗਾ? ਜਿਵੇਂ ਜ਼ਿਆਦਾ automated clients requests sign ਕਰਦੇ ਹਨ, ਹੋਰ agent traffic Unknown ਜਾਂ declared ਤੋਂ verified ਵੱਲ ਜਾਏਗਾ। ਤੁਹਾਡੀ monitoring ਇਹ ਬਦਲਾਅ route ਦਰ route ਦਿਖਾਏਗੀ।

Proof of Actor ਕਿੱਥੇ fit ਹੁੰਦਾ ਹੈ

Proof of Actor Unknown ਨੂੰ ਇੱਕ first-class result ਵਜੋਂ report ਕਰਦਾ ਹੈ, reason ਦੇ ਨਾਲ, ਅਤੇ ਕਦੇ ਵੀ ਇਸਨੂੰ Human ਵਿੱਚ convert ਨਹੀਂ ਕਰਦਾ। ਤੁਹਾਡੀ application ਹਰ route ਲਈ fallback ਚੁਣਦੀ ਹੈ, ਅਤੇ analytics ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ coverage ਕਿੱਥੇ ਖਤਮ ਹੁੰਦੀ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਜਿੱਥੇ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ ਉੱਥੇ evidence ਜੋੜ ਸਕੋ।

ਸਾਡੀ ਟੀਮ ਨਾਲ production application 'ਤੇ ਇਹ ਸੈਟ ਕਰਨ ਲਈ, early access ਲਈ apply ਕਰੋ. ਬਿਲਕੁਲ ਕੀ evidence establish ਕਰ ਸਕਦਾ ਹੈ, ਇਹ ਸਮਝਣ ਲਈ Detection & Limitations ਪੜ੍ਹੋ।

ਸਰੋਤ

• RFC 9421: HTTP Message Signatures: ਉਹ standard ਜਿਸਦੀ ਵਰਤੋਂ automated clients requests 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 threats ਦੀ taxonomy
• Node.js test runner: ਉਦਾਹਰਣ ਵਿੱਚ ਵਰਤਿਆ ਗਿਆ node:test module