ਮਾਰਗਦਰਸ਼ਕ

Node.js ਐਪ ਵਿੱਚ actor context ਕਿਵੇਂ ਜੋੜਨਾ ਹੈ

ਇੱਕ ਕਦਮ-ਦਰ-ਕਦਮ guide ਜੋ middleware ਬਣਾਉਣ ਲਈ ਹੈ, ਜੋ ਹਰ request ਦੇ ਪਿੱਛੇ ਕੌਣ ਜਾਂ ਕੀ ਹੈ ਇਹ ਦਰਜ ਕਰਦੀ ਹੈ, ਤਾਂ ਕਿ ਤੁਸੀਂ ਕੋਈ enforcement ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹਕੀਕਤੀ traffic ਦਾ ਅਧਿਐਨ ਕਰ ਸਕੋ.

ਦੁਆਰਾ Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

ਸ਼ੁਰੂਆਤੀ · 9 min read

Rules ਦੀ ਥਾਂ actor context ਨਾਲ ਕਿਉਂ ਸ਼ੁਰੂ ਕਰੀਏ?

ਜਿਆਦਾਤਰ teams ਜਿਨ੍ਹਾਂ ਨੂੰ ਆਪਣੇ traffic ਵਿੱਚ AI agents ਦਿੱਖਦੇ ਹਨ, ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ rule ਵੱਲ ਜਾਂਦੀਆਂ ਹਨ। user agent block ਕਰੋ, challenge ਜੋੜੋ, rate limit ਸਖ਼ਤ ਕਰੋ। ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ traffic ਨੂੰ ਸਮਝਣ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖਿਆ rule ਅਕਸਰ ਗਲਤ ਲੋਕਾਂ ਨੂੰ ਚੋਟ ਪਹੁੰਚਾਉਂਦਾ ਹੈ। legitimate assistants block ਹੋ ਜਾਂਦੇ ਹਨ, real users ਨੂੰ challenge ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਜਿਸ automation ਤੋਂ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਚਿੰਤਿਤ ਸੀ ਉਹ ਆਉਂਦੀ ਰਹਿੰਦੀ ਹੈ ਕਿਉਂਕਿ ਉਸ ਨੇ ਪਹਿਲਾਂ ਕਦੇ ਆਪਣੀ ਪਛਾਣ ਹੀ ਨਹੀਂ ਦੱਸੀ ਸੀ।

Actor context rules ਤੋਂ ਪਹਿਲਾਂ ਆਉਂਦਾ ਕਦਮ ਹੈ। ਹਰ request ਲਈ, ਤੁਸੀਂ ਦਰਜ ਕਰਦੇ ਹੋ ਕਿ ਤੁਹਾਡੀ application ਕੀ observe ਕਰ ਸਕਦੀ ਹੈ ਕਿ ਕੌਣ ਜਾਂ ਕੀ act ਕਰ ਰਿਹਾ ਹੈ: ਇੱਕ interactive person, AI assistant ਦੇ ਨਾਲ ਕੰਮ ਕਰ ਰਿਹਾ person, ਇੱਕ autonomous agent, ਜਾਂ ਕੁਝ ਅਜਿਹਾ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਹਾਲੇ ਵੱਖਰਾ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਤੁਸੀਂ ਉਸ view ਦੇ ਪਿੱਛੇ evidence ਦਰਜ ਕਰਦੇ ਹੋ, ਅਤੇ ਉਸਨੂੰ request ਦੇ outcome ਦੇ ਨਾਲ ਰੱਖਦੇ ਹੋ। ਇੱਕ ਜਾਂ ਦੋ ਹਫ਼ਤਿਆਂ ਬਾਅਦ, ਤੁਹਾਡੇ ਕੋਲ ਕੁਝ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ ਜੋ ਕੋਈ rule template ਨਹੀਂ ਦੇ ਸਕਦਾ: ਤੁਹਾਡੇ ਆਪਣੇ traffic ਦਾ map। ਜੇ ਤੁਸੀਂ ਹਾਲੇ ਵੀ ਇਹ ਤੈਅ ਕਰ ਰਹੇ ਹੋ ਕਿ agents ਤੁਹਾਡੀ site ਤੱਕ ਪਹੁੰਚਦੇ ਵੀ ਹਨ ਜਾਂ ਨਹੀਂ, ਤਾਂ website traffic AI agents ਤੋਂ ਆਉਂਦਾ ਹੈ ਕਿ ਨਹੀਂ ਇਹ ਕਿਵੇਂ ਪਤਾ ਲਗਾਇਆ ਜਾਵੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ।

ਇਹ guide plain middleware ਦੀ ਵਰਤੋਂ ਕਰਕੇ Node.js application ਵਿੱਚ ਉਹ layer ਬਣਾਉਂਦੀ ਹੈ। ਇਹ Express ਨਾਲ ਕੰਮ ਕਰਦੀ ਹੈ, ਅਤੇ ਇਹੀ ਵਿਚਾਰ Fastify, Koa, Hono ਜਾਂ Next.js route handler ਤੱਕ ਵੀ ਲਾਗੂ ਹੁੰਦੇ ਹਨ।

ਤੁਸੀਂ ਕੀ ਬਣਾਉਣੇ ਹੋ

ਅੰਤ ਤੱਕ ਤੁਹਾਡੇ ਕੋਲ ਹੋਵੇਗਾ:

ਇੱਕ middleware ਜੋ ਹਰ request ਤੋਂ actor evidence ਕੱਢਦਾ ਹੈ।
ਇੱਕ ਛੋਟਾ, ਸਪਸ਼ਟ classification ਜਿਸ ਲਈ ਹਰ result ਦਾ basis ਦਰਜ ਹੋਵੇ।
structured observation logs ਜੋ request ਨੂੰ handle ਕਰਨ ਦੇ ਤਰੀਕੇ ਨੂੰ ਕਦੇ ਨਹੀਂ ਬਦਲਦੇ।
ਇੱਕ ਤਰੀਕਾ ਜਿਸ ਨਾਲ result ਨੂੰ request ਨਾਲ attach ਕੀਤਾ ਜਾ ਸਕੇ, ਤਾਂ ਕਿ ਬਾਅਦ ਦੇ handlers ਉਸਨੂੰ ਪੜ੍ਹ ਸਕਣ।

ਇੱਥੇ ਕੁਝ ਵੀ request ਨੂੰ block ਨਹੀਂ ਕਰਦਾ। ਇਹ ਜਾਣ-ਬੂਝ ਕੇ ਹੈ।

Step 1: ਤੁਹਾਡਾ server ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ evidence ਦੇਖ ਸਕਦਾ ਹੈ?

ਇੱਕ server ਉਹਨਾਂ ਨਾਲੋਂ ਘੱਟ ਵੇਖਦਾ ਹੈ ਜਿੰਨਾ ਲੋਕ ਮੰਨਦੇ ਹਨ। Code ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ, ਆਪਣੇ edge 'ਤੇ ਉਪਲਬਧ signals ਦੀ ਸੂਚੀ ਬਣਾਓ:

Request signatures. ਕੁਝ automated clients HTTP Message Signatures ([RFC 9421]) ਦੀ ਵਰਤੋਂ ਕਰਕੇ requests sign ਕਰਦੇ ਹਨ, Signature-Input ਅਤੇ Signature headers ਭੇਜਦੇ ਹਨ, ਅਕਸਰ ਇੱਕ Signature-Agent header ਦੇ ਨਾਲ ਜੋ operator ਦੀ published keys ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ IETF Web Bot Auth protocol draft ਵਿੱਚ ਵਰਣਨ ਹੈ।
Declared identity. Clients ਆਪਣੇ ਆਪ ਨੂੰ User-Agent header ਵਿੱਚ, From header ਵਿੱਚ, ਜਾਂ protocol metadata ਰਾਹੀਂ, ਜਿਵੇਂ MCP client ਦਾ ਨਾਮ। MCP clients 2025-11-25 revision ਦੇ initialize request ਵਿੱਚ ਆਪਣੀ ਚੁਣੀ ਹੋਈ clientInfo name ਦੱਸਦੇ ਹਨ, ਅਤੇ 2026-07-28 revision per-request metadata ਵਜੋਂ client identity ਲਿਜਾਂਦੀ ਹੈ per-request metadata. ਇਹ declarations ਹਨ, ਅਤੇ ਕੋਈ ਵੀ ਇਨ੍ਹਾਂ ਦੀ ਨਕਲ ਕਰ ਸਕਦਾ ਹੈ।
Authentication context. ਕੀ request session cookie, bearer token ਜਾਂ API key ਲਿਜਾਂਦੀ ਹੈ, ਅਤੇ credential ਦੀ ਕਿਸਮ ਕੀ ਹੈ।
Protocol shape. Accept headers, client HTML ਜਾਂ JSON ਮੰਗ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਕੀ ਉਹ page assets load ਕਰਦਾ ਹੈ, ਅਤੇ redirects ਅਤੇ cookies ਨੂੰ ਕਿਵੇਂ handle ਕਰਦਾ ਹੈ।
Application declarations. ਤੁਹਾਡਾ ਆਪਣਾ product ਉਹ ਗੱਲਾਂ ਜਾਣ ਸਕਦਾ ਹੈ ਜੋ network ਨਹੀਂ ਜਾਣਦਾ, ਜਿਵੇਂ user ਦਾ "AI assisted" option ਚੁਣਨਾ, ਜਾਂ request ਦਾ ਤੁਹਾਡੇ built-in assistant feature ਤੋਂ ਆਉਣਾ।

ਹਰ signal ਦੀ ਤਾਕਤ ਵੱਖਰੀ ਹੁੰਦੀ ਹੈ। ਇੱਕ validated signature check ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਇੱਕ user agent string ਇੱਕ claim ਹੈ। ਇੱਕ missing cookie ਸਿਰਫ਼ missing ਹੈ। ਇਨ੍ਹਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖਣਾ ਹੀ ਇਸ exercise ਦਾ ਮੁੱਖ ਉਦੇਸ਼ ਹੈ।

Step 2: Result ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ model ਕਰੋ

Detection logic ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ actor result ਦਾ shape define ਕਰੋ। ਇੱਕ ਛੋਟਾ, typed model ਸਭ ਨੂੰ ਇਸ ਬਾਰੇ ਸੱਚਾ ਰੱਖਦਾ ਹੈ ਕਿ classification ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਇੱਥੇ ਵਰਤੀਆਂ ਗਈਆਂ ਚਾਰ classes Human, AI-assisted ਜਾਂ agent: application traffic ਲਈ ਇੱਕ practical taxonomy ਵਿੱਚ ਸਮਝਾਈਆਂ ਗਈਆਂ ਹਨ।

export type ActorClass = "human" | "human_ai" | "agent" | "unknown";
export type EvidenceBasis = "verified" | "declared" | "inferred" | "unknown";

export interface ActorEvidence {
  signaturePresent: boolean;
  signatureAgent?: string;
  declaredClient?: string;
  credentialType: "session" | "api_key" | "bearer" | "none";
  acceptsHtml: boolean;
  appDeclaredAssist: boolean;
}

export interface ActorResult {
  actor: ActorClass;
  basis: EvidenceBasis;
  reasons: string[];
  evidence: ActorEvidence;
  observedAt: string;
}

ਦੋ fields ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਹਨ। actor class ਹੈ। basis ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸ 'ਤੇ ਕਿਉਂ ਵਿਸ਼ਵਾਸ ਕਰਦੇ ਹੋ। ਇੱਕ validated signature 'ਤੇ ਆਧਾਰਿਤ agent result ਅਤੇ user agent string 'ਤੇ ਆਧਾਰਿਤ agent result ਦੋਵੇਂ "agent" ਹਨ, ਪਰ ਬਾਅਦ ਵਿੱਚ ਉਹਨਾਂ ਨਾਲ ਬਹੁਤ ਵੱਖਰਾ ਵਰਤਾਅ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਇਸ ਲਈ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਕਦੇ ਇਕੱਠਾ ਨਹੀਂ ਕਰਦੇ।

Step 3: Middleware ਵਿੱਚ evidence extract ਕਰੋ

Extraction step headers ਅਤੇ request state ਪੜ੍ਹਦਾ ਹੈ। ਇਹ ਹਾਲੇ ਕੁਝ decide ਨਹੀਂ ਕਰਦਾ।

import type { Request, Response, NextFunction } from "express";

const KNOWN_AGENT_TOKENS = ["bot", "crawler", "spider", "agent", "gpt", "claude"];

export function extractEvidence(req: Request): ActorEvidence {
  const ua = (req.get("user-agent") || "").toLowerCase();
  const auth = req.get("authorization") || "";
  const hasSession = Boolean(req.cookies?.session);

  let credentialType: ActorEvidence["credentialType"] = "none";
  if (hasSession) credentialType = "session";
  else if (auth.toLowerCase().startsWith("bearer ")) credentialType = "bearer";
  else if (req.get("x-api-key")) credentialType = "api_key";

  const declaredToken = KNOWN_AGENT_TOKENS.find((t) => ua.includes(t));

  return {
    signaturePresent: Boolean(req.get("signature") && req.get("signature-input")),
    signatureAgent: req.get("signature-agent") || undefined,
    declaredClient: declaredToken ? ua.slice(0, 200) : undefined,
    credentialType,
    acceptsHtml: (req.get("accept") || "").includes("text/html"),
    appDeclaredAssist: req.get("x-app-assist") === "1",
  };
}

ਇਸ code ਬਾਰੇ ਕੁਝ ਨੋਟਸ:

signaturePresent ਸਿਰਫ਼ ਇਹ ਦਰਜ ਕਰਦਾ ਹੈ ਕਿ signature headers ਮੌਜੂਦ ਹਨ। Validation ਇੱਕ ਵੱਖਰਾ step ਹੈ, ਜਿਸਨੂੰ signed agent requests verify ਕਰਨ ਵਾਲੀ guide ਵਿੱਚ ਕਵਰ ਕੀਤਾ ਗਿਆ ਹੈ।
User agent token list ਜਾਣ-ਬੂਝ ਕੇ ਸਧਾਰਣ ਹੈ। ਇਹ ਇੱਕ declaration ਪੈਦਾ ਕਰਦਾ ਹੈ, verification ਕਦੇ ਨਹੀਂ।
x-app-assist ਤੁਹਾਡੇ ਆਪਣੇ frontend ਵੱਲੋਂ ਉਸ ਵੇਲੇ ਭੇਜੇ ਗਏ ਕਿਸੇ ਵੀ signal ਲਈ placeholder ਹੈ ਜਦੋਂ ਕੋਈ user ਤੁਹਾਡੇ built-in AI feature ਨਾਲ ਕੰਮ ਕਰ ਰਿਹਾ ਹੋਵੇ। ਇਸਨੂੰ ਆਪਣੇ ਅਸਲ mechanism ਨਾਲ ਬਦਲੋ।

Step 4: ਇੱਕ stated basis ਨਾਲ classify ਕਰੋ

ਹੁਣ evidence ਨੂੰ ਇੱਕ result ਵਿੱਚ ਬਦਲੋ। Rules ਛੋਟੇ ਰੱਖੋ, strongest evidence ਤੋਂ weakest ਤੱਕ ਕ੍ਰਮਬੱਧ, ਅਤੇ ਹਮੇਸ਼ਾਂ Unknown 'ਤੇ fall through ਕਰੋ।

export async function classify(
  evidence: ActorEvidence,
  verifySignature: () => Promise<boolean>,
): Promise<ActorResult> {
  const reasons: string[] = [];
  const observedAt = new Date().toISOString();

  if (evidence.signaturePresent && (await verifySignature())) {
    reasons.push("request signature validated");
    return { actor: "agent", basis: "verified", reasons, evidence, observedAt };
  }

  if (evidence.appDeclaredAssist) {
    reasons.push("application reported its built-in assistant");
    return { actor: "human_ai", basis: "declared", reasons, evidence, observedAt };
  }

  if (evidence.declaredClient) {
    reasons.push("client declared itself as automated");
    return { actor: "agent", basis: "declared", reasons, evidence, observedAt };
  }

  if (evidence.credentialType === "session" && evidence.acceptsHtml) {
    reasons.push("interactive browser session");
    return { actor: "human", basis: "inferred", reasons, evidence, observedAt };
  }

  reasons.push("insufficient evidence");
  return { actor: "unknown", basis: "unknown", reasons, evidence, observedAt };
}

ਧਿਆਨ ਦਿਓ ਕਿ ਇਹ ਕੀ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਕਦੇ declaration ਨੂੰ verification ਵਿੱਚ upgrade ਨਹੀਂ ਕਰਦਾ। ਇਹ ਕਦੇ ਉਸ request ਨੂੰ Human ਨਹੀਂ ਦਿੰਦਾ ਜਿਸ ਵਿੱਚ ਕੋਈ interactive signal ਨਹੀਂ ਹੈ। ਜਦੋਂ ਇਹ ਨਹੀਂ ਦੱਸ ਸਕਦਾ, ਇਹ Unknown ਕਹਿੰਦਾ ਹੈ। Unknown ਇੱਕ ਵੈਧ, ਲਾਭਦਾਇਕ ਉੱਤਰ ਹੈ, ਅਤੇ ਇਹ ਤੁਹਾਨੂੰ ਬਿਲਕੁਲ ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਹਾਡੀ visibility ਕਿੱਥੇ ਖਤਮ ਹੁੰਦੀ ਹੈ। ਅਸੀਂ ਪੂਰਾ ਮਾਮਲਾ AI traffic ਲਈ Unknown ਇੱਕ ਵੈਧ result ਕਿਉਂ ਹੈ ਵਿੱਚ ਸਮਝਾਉਂਦੇ ਹਾਂ।

Step 5: ਇਸਨੂੰ observation mode ਵਿੱਚ wire ਕਰੋ

Middleware ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ mount ਕਰੋ, result ਨੂੰ request ਨਾਲ attach ਕਰੋ, ਅਤੇ ਇਸਨੂੰ log ਕਰੋ। ਇਸ ਦੇ ਆਧਾਰ 'ਤੇ branch ਨਾ ਕਰੋ।

import express from "express";
import cookieParser from "cookie-parser";

const app = express();
app.use(cookieParser());

app.use(async (req, res, next) => {
  try {
    const evidence = extractEvidence(req);
    const result = await classify(evidence, async () => false);
    res.locals.actor = result;

    res.on("finish", () => {
      logActor({
        route: req.route?.path ?? req.path,
        method: req.method,
        status: res.statusCode,
        actor: result.actor,
        basis: result.basis,
        reasons: result.reasons,
      });
    });
  } catch {
    res.locals.actor = undefined;
  }
  next();
});

ਤਿੰਨ ਵੇਰਵੇ ਇਸਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੇ ਹਨ:

try block ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ detection ਵਿੱਚ ਕੋਈ failure ਕਦੇ response ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਾ ਕਰੇ। Observation ਨੂੰ fail open ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
Logging finish 'ਤੇ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਤੁਸੀਂ ਅਸਲ status code capture ਕਰਦੇ ਹੋ ਅਤੇ ਬਾਅਦ ਵਿੱਚ classifications ਨੂੰ outcomes ਨਾਲ compare ਕਰ ਸਕਦੇ ਹੋ।
verifySignature ਨੂੰ false ਵਜੋਂ stub ਕੀਤਾ ਗਿਆ ਹੈ ਜਦ ਤੱਕ ਤੁਸੀਂ real validation implement ਨਹੀਂ ਕਰਦੇ। ਇਸ ਨਾਲ signed requests declared ਜਾਂ unknown buckets ਵਿੱਚ ਰਹਿੰਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਉਹਨਾਂ ਨੂੰ ਹੱਦ ਤੋਂ ਵੱਧ ਦੱਸਿਆ ਜਾਂਦਾ ਹੈ।

Step 6: ਸਿਰਫ਼ debugging ਨਹੀਂ, analysis ਲਈ log ਕਰੋ

ਅਜਿਹੇ logs ਲਿਖੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ aggregate ਕਰ ਸਕੋ। ਹਰ request ਲਈ ਇੱਕ structured line ਕਾਫ਼ੀ ਹੈ।

function logActor(entry: Record<string, unknown>) {
  process.stdout.write(JSON.stringify({ type: "actor_observation", ...entry }) + "\n");
}

ਇਨ੍ਹਾਂ logs ਤੋਂ personal data ਦੂਰ ਰੱਖੋ। ਤੁਹਾਨੂੰ route, class, basis, reasons ਅਤੇ outcome ਦੀ ਲੋੜ ਹੈ। ਆਪਣੇ traffic mix ਨੂੰ ਸਮਝਣ ਲਈ ਤੁਹਾਨੂੰ ਪੂਰੇ IP addresses, raw cookies ਜਾਂ request bodies ਦੀ ਲੋੜ ਨਹੀਂ। ਜੇ ਤੁਸੀਂ correlation ਲਈ ਕੋਈ identifier ਰੱਖਦੇ ਹੋ, ਤਾਂ ਉਸਨੂੰ rotating salt ਨਾਲ hash ਕਰੋ ਅਤੇ ਛੋਟੀ retention period ਸੈੱਟ ਕਰੋ।

Step 7: ਕਾਰਵਾਈ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ data ਪੜ੍ਹੋ

ਆਮ ਹਫਤਾਵਾਰੀ patterns ਵੇਖਣ ਲਈ observation mode ਵਿੱਚ ਕਾਫ਼ੀ ਸਮੇਂ ਤੱਕ ਚਲਾਓ। ਫਿਰ ਕੁਝ ਪ੍ਰਸ਼ਨਾਂ ਦੇ ਜਵਾਬ ਦਿਓ:

ਕਿਹੜੇ routes agents ਨੂੰ ਆਕਰਸ਼ਿਤ ਕਰਦੇ ਹਨ? Documentation, catalog ਅਤੇ search endpoints ਆਮ ਤੌਰ 'ਤੇ ਕਰਦੇ ਹਨ। Account ਅਤੇ checkout flows ਆਮ ਤੌਰ 'ਤੇ ਨਹੀਂ ਕਰਨੇ ਚਾਹੀਦੇ।
Agent results ਦਾ ਕਿੰਨਾ ਹਿੱਸਾ verified ਹੈ ਅਤੇ ਕਿੰਨਾ declared? ਇਹ ਅਨੁਪਾਤ ਦੱਸਦਾ ਹੈ ਕਿ ਜਦੋਂ ਤੁਸੀਂ policies ਲਿਖਦੇ ਹੋ ਤਾਂ ਤੁਸੀਂ identity 'ਤੇ ਕਿੰਨਾ safely rely ਕਰ ਸਕਦੇ ਹੋ।
Unknown ਕਿੱਥੇ ਸਭ ਤੋਂ ਵੱਧ concentrated ਹੈ? ਕਿਸੇ route 'ਤੇ ਉੱਚ Unknown rate ਅਕਸਰ ਇਸ ਗੱਲ ਦਾ ਸੰਕੇਤ ਹੁੰਦਾ ਹੈ ਕਿ ਉੱਥੇ ਕੋਈ signal ਗੁੰਮ ਹੈ, ਉਦਾਹਰਣ ਵਜੋਂ ਇੱਕ ਅਜਿਹਾ page ਜੋ ਤੁਹਾਡਾ frontend code ਕਦੇ ਚਲਾਉਂਦਾ ਹੀ ਨਹੀਂ।
ਕੀ outcomes class ਦੇ ਅਨੁਸਾਰ ਵੱਖਰੇ ਹਨ? Error rates, conversion steps ਜਾਂ abuse reports ਨੂੰ classes ਵਿੱਚ compare ਕਰੋ। ਇੱਥੋਂ ਹੀ ਅਸਲ policy ideas ਆਉਂਦੀਆਂ ਹਨ।

ਅਕਸਰ ਜਵਾਬ ਹੈਰਾਨ ਕਰ ਦੇਣਗੇ। Teams ਅਕਸਰ ਪਾਉਂਦੀਆਂ ਹਨ ਕਿ ਉਹਨਾਂ ਦੀ "bot problem" ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਅਸਲ ਵਿੱਚ legitimate automation ਹੁੰਦਾ ਹੈ, ਜੋ structured endpoint ਮਿਲਣ 'ਤੇ ਖੁਸ਼ੀ ਨਾਲ ਵਰਤੇਗੀ ਜੇ ਉਹ ਮੌਜੂਦ ਹੋਵੇ।

Step 8: Result ਨੂੰ ਆਪਣੀ app ਦੇ ਬਾਕੀ ਹਿੱਸੇ ਲਈ expose ਕਰੋ

ਜਦ data ਵਹਿਣ ਲੱਗ ਪਏ, ਤਾਂ handlers ਨੂੰ non-enforcing uses ਲਈ res.locals.actor ਪੜ੍ਹਨ ਦਿਓ: analytics tags, response format ਚੁਣਨਾ, ਜਾਂ ਇਹ ਦਰਜ ਕਰਨਾ ਕਿ ਕੋਈ support ticket AI-assisted session ਤੋਂ ਆਇਆ ਸੀ। ਇਹ uses experience ਨੂੰ ਸੁਧਾਰਦੇ ਹਨ ਬਿਨਾਂ ਕਿਸੇ ਨੂੰ lock out ਕਰਨ ਦੇ ਖਤਰੇ ਦੇ।

app.get("/docs/:page", (req, res) => {
  const actor = res.locals.actor as ActorResult | undefined;
  if (actor?.actor === "agent" && req.accepts("text/markdown")) {
    return res.type("text/markdown").send(renderMarkdown(req.params.page));
  }
  return res.render("doc", { page: req.params.page });
});

Enforcement, ਜਿਵੇਂ challenges, rate limits ਜਾਂ step-up checks, ਬਾਅਦ ਵਿੱਚ ਆਉਂਦੇ ਹਨ, false positives ਮਾਪਣ ਤੋਂ ਬਾਅਦ। actor-aware policies roll out ਕਰਨ ਵਾਲੀ guide ਉਸ process ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ।

ਕਿਹੜੀਆਂ ਗਲਤੀਆਂ ਤੋਂ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ?

User agent ਨੂੰ identity ਮੰਨਣਾ। ਇਹ ਬਦਲਣ ਲਈ ਸਭ ਤੋਂ ਆਸਾਨ header ਹੈ। ਇਸਨੂੰ ਇੱਕ declaration ਵਜੋਂ ਦਰਜ ਕਰੋ। ਇੱਥੋਂ ਤੱਕ ਕਿ AI operators ਵੀ ਇਹੀ ਕਹਿੰਦੇ ਹਨ: Anthropic ਦੀ ਆਪਣੇ hosted browser agent ਲਈ guidance ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਕੋਈ ਵੀ ਉਹੀ User-Agent header ਭੇਜ ਸਕਦਾ ਹੈ ਅਤੇ traffic ਨੂੰ genuine ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸ ਦੇ published IP addresses ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦੀ ਹੈ।
ਮੂਲ ਤੌਰ 'ਤੇ Human ਮੰਨ ਲੈਣਾ। ਜੇ ਤੁਹਾਡਾ code ਬੋਟ signals ਨਾ ਮਿਲਣ 'ਤੇ ਹਰ ਵਾਰੀ Human ਕਹਿੰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ Human numbers ਵਧੇ ਹੋਏ ਹੋਣਗੇ ਅਤੇ ਤੁਹਾਡੀਆਂ policies ਗਲਤ traffic 'ਤੇ ਭਰੋਸਾ ਕਰਨਗੀਆਂ।
Class ਅਤੇ basis ਨੂੰ ਮਿਲਾ ਦੇਣਾ। ਹਮੇਸ਼ਾਂ ਦੋਵੇਂ ਸੰਭਾਲੋ। ਇੱਕ dashboard ਜੋ ਸਿਰਫ਼ "Agent" ਦਿਖਾਉਂਦਾ ਹੈ, verified operator ਅਤੇ copied string ਵਿਚਕਾਰ ਫ਼ਰਕ ਛੁਪਾ ਦਿੰਦਾ ਹੈ।
Observation ਦੌਰਾਨ block ਕਰਨਾ। ਇੱਥੋਂ ਤੱਕ ਕਿ ਇੱਕ temporary block ਵੀ ਤੁਹਾਡੇ measurements ਨੂੰ ਅਵੈਧ ਕਰ ਦਿੰਦਾ ਹੈ, ਕਿਉਂਕਿ blocked clients ਆਪਣਾ behavior ਬਦਲ ਦਿੰਦੇ ਹਨ।

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

ਉਪਰਲਾ middleware ਇੱਕ ਮਜ਼ਬੂਤ ਸ਼ੁਰੂਆਤ ਹੈ, ਅਤੇ ਇਹ core model ਦਿਖਾਉਂਦਾ ਹੈ: ਪਹਿਲਾਂ evidence, ਹਰ result ਲਈ ਇੱਕ explicit basis, Unknown ਨੂੰ visible ਰੱਖਣਾ, ਅਤੇ decisions ਨੂੰ ਤੁਹਾਡੀ application 'ਤੇ ਛੱਡ ਦੇਣਾ। Proof of Actor ਇਸੇ model 'ਤੇ server, edge, browser ਅਤੇ MCP contexts ਵਿੱਚ ਹੋਰ ਡੂੰਘੀ signal coverage ਅਤੇ analytics ਨਾਲ ਬਣਦਾ ਹੈ, ਜੋ ਤੁਹਾਨੂੰ Detect, Understand ਅਤੇ Route confidence ਨਾਲ ਕਰਨ ਦਿੰਦੇ ਹਨ।

ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ production app 'ਤੇ ਹੋਰ ਅੱਗੇ ਲੈ ਜਾਣ ਲਈ ਮਦਦ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ early access ਲਈ apply ਕਰੋ. ਪੂਰਾ decision flow ਦੇਖਣ ਲਈ, How Proof of Actor works ਪੜ੍ਹੋ।

Sources

RFC 9421: HTTP Message Signatures: signed requests ਦੇ ਪਿੱਛੇ ਦਾ standard
draft-ietf-webbotauth-httpsig-protocol: IETF Web Bot Auth draft ਜੋ Signature-Agent header define ਕਰਦਾ ਹੈ (November 2026 ਤੱਕ work in progress)
RFC 9110: HTTP Semantics, User-Agent and From: self-reported client identification headers
MCP specification 2025-11-25: Lifecycle: initialize request ਅਤੇ clientInfo
MCP specification 2026-07-28: Versioning and Compatibility: per-request version, identity ਅਤੇ capability metadata
Anthropic: how Anthropic-hosted browsers identify themselves: user agent token, published IP addresses ਅਤੇ ਇਹ ਚੇਤਾਵਨੀ ਕਿ header ਦੀ ਨਕਲ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ

ਇਸ ਨੂੰ ਸਾਡੇ ਨਾਲ ਬਣਾਓ।

Proof of Actor founding developer program ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਵੋ।

ਅਗਾਊਂ ਪਹੁੰਚ ਲਵੋ ਡਿਵੈਲਪਰ ਕੇਂਦਰ

ਪਹਿਲਾਂ ਗੱਲ ਕਰਨੀ ਪਸੰਦ ਕਰੋਗੇ? founders ਨਾਲ ਗੱਲ ਕਰੋ