ମାର୍ଗଦର୍ଶିକା

Node.js ଆପ୍‌ରେ actor context କିପରି ଯୋଡ଼ିବେ

ପ୍ରତ୍ୟେକ request ପଛରେ କିଏ କିମ୍ବା କ’ଣ ଅଛି ତାହା record କରୁଥିବା middleware ତିଆରି କରିବା ପାଇଁ ଏକ step-by-step guide, ଯାହାଦ୍ୱାରା ଆପଣ କୌଣସି enforcement କରିବା ପୂର୍ବରୁ real traffic ଅଧ୍ୟୟନ କରିପାରିବେ।

ଦ୍ୱାରା Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

ଆରମ୍ଭିକ · 9 min read

ନିୟମର ବଦଳରେ actor context ରୁ କାହିଁକି ଆରମ୍ଭ କରିବେ?

ଅନେକ team ଯେତେବେଳେ ନିଜ traffic ମଧ୍ୟରେ AI agents ଦେଖିଥାନ୍ତି, ସେମାନେ ପ୍ରଥମେ ଏକ rule ବନାଇବାକୁ ଲାଗନ୍ତି। user agent block କରନ୍ତୁ, ଏକ challenge ଯୋଡ଼ନ୍ତୁ, rate limit କଠୋର କରନ୍ତୁ। ସମସ୍ୟା ହେଉଛି, ଆପଣ traffic ବୁଝିବା ପୂର୍ବରୁ ଲେଖିଥିବା rule ସାଧାରଣତଃ ଭୁଲ ଲୋକଙ୍କୁ ଆଘାତ କରେ। ଯୋଗ୍ୟ assistants block ହୋଇଯାନ୍ତି, ପ୍ରକୃତ users challenge ହୋଇଯାନ୍ତି, ଏବଂ ଯେ automation ପାଇଁ ଆପଣ ସତର୍କ ଥିଲେ ସେଟା ପ୍ରଥମେ ନିଜକୁ ପରିଚୟ ଦେଇନଥିବାରୁ ଚାଲୁ ରହିଯାଏ।

Actor context ହେଉଛି rules ପୂର୍ବରୁ ଥିବା ପଦକ୍ଷେପ। ପ୍ରତ୍ୟେକ request ପାଇଁ, ଆପଣ record କରନ୍ତି ଯେ ଆପଣଙ୍କ application କିଏ କିମ୍ବା କ’ଣ କାର୍ଯ୍ୟ କରୁଛି ତାହା ବିଷୟରେ କ’ଣ observe କରିପାରେ: ଏକ interactive person, AI assistant ସହ କାମ କରୁଥିବା ଏକ person, ଏକ autonomous agent, କିମ୍ବା ଯାହାକୁ ଆପଣ ଏପର୍ଯ୍ୟନ୍ତ ଅଲଗା କରିପାରୁନାହାନ୍ତି। ଆପଣ ସେହି view ପଛର evidence record କରନ୍ତି, ଏବଂ ଏହାକୁ request outcome ପାଖରେ ରଖନ୍ତି। ଏହାକୁ ଏକ କିମ୍ବା ଦୁଇ ସପ୍ତାହ ଚାଲୁ ରଖିଲେ, ଆପଣଙ୍କ ପାଖରେ ଏମିତି କିଛି ଥାଏ ଯାହା କୌଣସି rule template ଦେଇପାରେ ନାହିଁ: ଆପଣଙ୍କର own traffic ର ଏକ map। ଯଦି ଆପଣ ଏପର୍ଯ୍ୟନ୍ତ ଏହା ନେଇ ନିଷ୍ପତ୍ତି ନେଉଛନ୍ତି ଯେ agents ଆପଣଙ୍କ site କୁ ପ୍ରକୃତରେ ପହଞ୍ଚୁଛନ୍ତି କି ନାହିଁ, ତେବେ website traffic AI agents ଠାରୁ ଆସୁଛି କିପରି ଜାଣିବେ ରୁ ଆରମ୍ଭ କରନ୍ତୁ।

ଏହି guide plain middleware ବ୍ୟବହାର କରି Node.js application ମଧ୍ୟରେ ସେ layer ତିଆରି କରେ। ଏହା Express ସହ କାମ କରେ, ଏବଂ ସେଇ ଧାରଣାଗୁଡ଼ିକ Fastify, Koa, Hono କିମ୍ବା Next.js route handler କୁ ମଧ୍ୟ ଲାଗୁହୁଏ।

ଆପଣ କ’ଣ ତିଆରି କରିବେ

ଶେଷରେ ଆପଣଙ୍କ ପାଖରେ ଏହା ଥାଇବ:

ପ୍ରତ୍ୟେକ request ରୁ actor evidence ବାହାର କରୁଥିବା ଏକ middleware।
ପ୍ରତ୍ୟେକ result ପାଇଁ ତାହାର stated basis ସହ ଏକ ଛୋଟ, explicit classification।
ଏମିତି structured observation logs ଯାହା request କିପରି handle ହେଉଛି ତାହା କେବେ ବଦଳାଏ ନାହିଁ।
request ସହ result attach କରିବାର ଏକ ଉପାୟ, ଯାହା ଦ୍ୱାରା ପରେ ଥିବା handlers ଏହାକୁ ପଢ଼ିପାରିବେ।

ଏଠାରେ କିଛିମଧ୍ୟ request block କରୁନାହିଁ। ସେଟା ଇଚ୍ଛାପୂର୍ଣ୍ଣ।

ପଦକ୍ଷେପ 1: ଆପଣଙ୍କ server ପ୍ରକୃତରେ କେଉଁ evidence ଦେଖିପାରେ?

Server ଲୋକମାନେ ଭାବନ୍ତି ସେତେ ଦେଖେ ନାହିଁ। Code ଲେଖିବା ପୂର୍ବରୁ, ଆପଣଙ୍କ edge ରେ ଉପଲବ୍ଧ signals ତାଲିକା କରନ୍ତୁ:

Request signatures. କିଛି automated clients HTTP Message Signatures (RFC 9421) ବ୍ୟବହାର କରି request 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 name. MCP clients 2025-11-25 revision ର initialize request ମଧ୍ୟରେ ଏକ self-chosen clientInfo name ରିପୋର୍ଟ କରନ୍ତି, ଏବଂ 2026-07-28 revision client identity କୁ per-request metadata ଭାବେ ବହନ କରେ। ଏଗୁଡ଼ିକ declarations, ଏବଂ ଯେକେହି ଏଗୁଡ଼ିକୁ copy କରିପାରେ।
Authentication context. Request ରେ session cookie, bearer token କିମ୍ବା API key ଅଛି କି ନାହିଁ, ଏବଂ ସେଟି କେଉଁ ପ୍ରକାରର credential।
Protocol shape. Accept headers, client HTML କି JSON ଚାହୁଁଛି କି, ସେ page assets load କରୁଛି କି, ଏବଂ redirects ଏବଂ cookies ସହ କିପରି ବ୍ୟବହାର କରୁଛି।
Application declarations. ଆପଣଙ୍କର own product network ଯାହା ଦେଖିପାରେ ନାହିଁ ସେମିତି କିଛି ଜାଣିପାରେ, ଯେପରି user ଏକ "AI assisted" option ବାଛିବା, କିମ୍ବା request ଆପଣଙ୍କ built-in assistant feature ରୁ ଆସିବା।

ପ୍ରତ୍ୟେକ signal ର ଶକ୍ତି ଭିନ୍ନ। ଏକ validated signature check କରାଯାଇପାରେ। ଏକ user agent string ହେଉଛି ଏକ claim। ଏକ missing cookie କେବଳ missing ଅଟେ। ଏଗୁଡ଼ିକୁ ଅଲଗା ରଖିବା ହେଉଛି ଏହି exercise ର ପୂରା ଉଦ୍ଦେଶ୍ୟ।

ପଦକ୍ଷେପ 2: ଫଳାଫଳକୁ ସ୍ପଷ୍ଟ ଭାବରେ model କରନ୍ତୁ

Detection logic ଲେଖିବା ପୂର୍ବରୁ actor result ର shape define କରନ୍ତୁ। ଏକ ଛୋଟ, typed model classification ର ଅର୍ଥ କ’ଣ ସେଥିରେ ସମସ୍ତଙ୍କୁ ସତ୍ୟନିଷ୍ଠ ରଖେ। ଏଠାରେ ବ୍ୟବହୃତ ଚାରିଟି class Human, AI-assisted or agent: a practical taxonomy for application traffic ରେ ବ୍ୟାଖ୍ୟା କରାଯାଇଛି।

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;
}

ଦୁଇଟି field ସବୁଠାରୁ ମୁଖ୍ୟ। actor ହେଉଛି class। basis କାହିଁକି ଆପଣ ଏହାକୁ ବିଶ୍ୱାସ କରୁଛନ୍ତି ସେଥି କହେ। validated signature ଆଧାରିତ agent result ଏବଂ user agent string ଆଧାରିତ agent result ଦୁହେଁ "agent" ହେଲେ ମଧ୍ୟ, ପରେ ଅତ୍ୟନ୍ତ ଭିନ୍ନ ବ୍ୟବହାର ଦରକାର, ତେଣୁ ସେମାନଙ୍କୁ କେବେ ମିଶାଇବେ ନାହିଁ।

ପଦକ୍ଷେପ 3: Middleware ରେ evidence ବାହାର କରନ୍ତୁ

Extraction step headers ଏବଂ request state ପଢ଼େ। ସେଟା ଏପର୍ଯ୍ୟନ୍ତ କିଛି ନିଷ୍ପତ୍ତି ନେଉନାହିଁ।

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 କେବଳ ଏହା record କରେ ଯେ signature headers ଅଛି। Validation ଏକ ଅଲଗା ପଦକ୍ଷେପ, ଯାହା signed agent requests verify କରିବା ଉପରେ guide ରେ ଆବୃତ।
user agent token list ଜଣାଶୁଣାଭାବରେ ସରଳ। ଏହା ଏକ declaration ଦିଏ, କେବେ verification ନୁହେଁ।
x-app-assist ଆପଣଙ୍କ own frontend ଯେତେବେଳେ user ଆପଣଙ୍କ built-in AI feature ମାଧ୍ୟମରେ କାମ କରେ, ସେତେବେଳେ ଯାହା ପଠାଏ ତାହା ପାଇଁ placeholder ଭାବେ ଦେଖାଯାଇଛି। ଏହାକୁ ଆପଣଙ୍କ real mechanism ସହ ବଦଳାନ୍ତୁ।

ପଦକ୍ଷେପ 4: stated basis ସହ classification କରନ୍ତୁ

ଏବେ evidence କୁ result ରେ ପରିବର୍ତ୍ତନ କରନ୍ତୁ। Rule ଗୁଡ଼ିକୁ ଛୋଟ ରଖନ୍ତୁ, strongest evidence ରୁ weakest ଦିଗକୁ ordered କରନ୍ତୁ, ଏବଂ ସଦା 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 କରିଦିଏ ନାହିଁ। ଏହା କେବେ interactive signal ନଥିବା request କୁ Human ନିଯୁକ୍ତ କରେ ନାହିଁ। ଯେତେବେଳେ ଏହା ନିଷ୍କର୍ଷ କରିପାରେ ନାହିଁ, ସେତେବେଳେ Unknown କହେ। Unknown ହେଉଛି ଏକ ବୈଧ, ଉପଯୋଗୀ ଉତ୍ତର, ଏବଂ ଏହା ଆପଣଙ୍କ visibility କେଉଁଠାରେ ଶେଷ ହୁଏ ସେଥି ସ୍ପଷ୍ଟ କରେ। ଆମେ ସମ୍ପୂର୍ଣ୍ଣ case AI traffic ପାଇଁ Unknown କାହିଁକି ଏକ ବୈଧ result ରେ ବ୍ୟାଖ୍ୟା କରୁଛୁ।

ପଦକ୍ଷେପ 5: Observation mode ରେ ଏହାକୁ wire କରନ୍ତୁ

Middleware କୁ early ରେ 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();
});

ଏହାକୁ safe କରୁଥିବା ତିନୋଟି detail:

try block detection ର failure କେବେ response କୁ ପ୍ରଭାବିତ କରେ ନାହିଁ ବୋଲି ନିଶ୍ଚିତ କରେ। Observation fail open ହେବା ଉଚିତ।
Logging finish ଉପରେ ହୁଏ, ତେଣୁ ଆପଣ real status code capture କରନ୍ତି ଏବଂ ପରେ classification କୁ outcome ସହ ତୁଳନା କରିପାରନ୍ତି।
Real validation implement କରିବା ପର୍ଯ୍ୟନ୍ତ verifySignature କୁ false ଭାବେ stub କରାଯାଇଛି। ଏହା signed requests କୁ declared କିମ୍ବା unknown bucket ମଧ୍ୟରେ ରଖେ, ଅତିରଞ୍ଜିତ କରେ ନାହିଁ।

ପଦକ୍ଷେପ 6: କେବଳ debugging ପାଇଁ ନୁହେଁ, analysis ପାଇଁ log କରନ୍ତୁ

Aggregate କରିପାରିବା logs ଲେଖନ୍ତୁ। ପ୍ରତ୍ୟେକ 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 ବୁଝିବା ପାଇଁ full IP address, raw cookies କି request bodies ଦରକାର ନୁହେଁ। Correlation ପାଇଁ କୌଣସି identifier ରଖିଥିଲେ, ଏହାକୁ rotating salt ସହ hash କରନ୍ତୁ ଏବଂ ଛୋଟ retention period ସେଟ୍ କରନ୍ତୁ।

ପଦକ୍ଷେପ 7: କାର୍ଯ୍ୟ ନେବା ପୂର୍ବରୁ data ପଢ଼ନ୍ତୁ

ସାଧାରଣ ସାପ୍ତାହିକ pattern ଦେଖିବା ପର୍ଯ୍ୟନ୍ତ observation mode ରେ ଚାଲାନ୍ତୁ। ତାପରେ କିଛି ପ୍ରଶ୍ନର ଉତ୍ତର ଦିଅନ୍ତୁ:

କେଉଁ route ଗୁଡ଼ିକ agents କୁ ଆକର୍ଷିତ କରେ? Documentation, catalog ଏବଂ search endpoint ସାଧାରଣତଃ କରେ। Account ଏବଂ checkout flow ସାଧାରଣତଃ କରିବା ଉଚିତ ନୁହେଁ।
verified ବନାମ declared agent result ର share କେତେ? ସେ ratio ଆପଣଙ୍କୁ କହେ policy ଲେଖିବା ସମୟରେ identity ଉପରେ କେତେଟା ସୁରକ୍ଷିତ ଭାବେ ଭରସା କରିପାରିବେ।
Unknown କେଉଁଠି concentrated? ଏକ route ରେ ଉଚ୍ଚ Unknown rate ସାଧାରଣତଃ ଅର୍ଥ ହେଉଛି ସେଠାରେ ଆପଣ ଗୋଟିଏ signal ହାରାଇଛନ୍ତି, ଉଦାହରଣ ସ୍ୱରୂପ ଏକ page ଯାହା କେବେ ଆପଣଙ୍କ frontend code ଚଲାଏ ନାହିଁ।
class ଅନୁସାରେ outcome ଭିନ୍ନ କି? class ମଧ୍ୟରେ error rate, conversion step କି abuse report ତୁଳନା କରନ୍ତୁ। ସତ୍ୟ policy idea ଏଠାରୁ ଆସେ।

ଉତ୍ତରଗୁଡ଼ିକ ପ୍ରାୟସଃ ଆପଣଙ୍କୁ ଆଶ୍ଚର୍ୟ କରାଇବ। Team ମାନେ ସାଧାରଣତଃ ଦେଖନ୍ତି ଯେ ତାଙ୍କର "bot problem" ର ଏକ ବଡ଼ ଅଂଶ ପ୍ରକୃତରେ ଯୋଗ୍ୟ automation, ଯାହା ସଂରଚିତ endpoint ଥାଇଥାନ୍ତା ତେବେ ସେଥିକୁ ସନ୍ତୁଷ୍ଟିର ସହିତ ବ୍ୟବହାର କରିଥାନ୍ତା।

ପଦକ୍ଷେପ 8: ଫଳାଫଳକୁ ଆପଣଙ୍କ app ର ଅନ୍ୟ ଅଂଶକୁ expose କରନ୍ତୁ

Data ପ୍ରବାହିତ ହେଲେ, non-enforcing uses ପାଇଁ handlers କୁ res.locals.actor ପଢ଼ିବାକୁ ଦିଅନ୍ତୁ: analytics tags, response format ବାଛିବା, କିମ୍ବା ଏକ support ticket AI-assisted session ରୁ ଆସିଥିଲା ବୋଲି record କରିବା। ଏହି uses ଅନୁଭବକୁ ଉନ୍ନତ କରେ, କାହାରି access ବନ୍ଦ ହେବାର ଝୁମୁକି ନେଇନାହିଁ।

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 });
});

Challenges, rate limits କି step-up checks ପରି enforcement ପରେ ଆସେ, false positives measure କରିବା ପରେ। actor-aware policies roll out କରିବା ଉପରେ guide ସେହି process କୁ ଆବୃତ କରେ।

କେଉଁ ଭୁଲଗୁଡ଼ିକୁ ଏଡ଼ାଇବା ଉଚିତ?

User agent କୁ identity ଭାବରେ ନେବା। ଏହା ପରିବର୍ତ୍ତନ କରିବା ସବୁଠାରୁ ସହଜ header। ଏହାକୁ declaration ଭାବେ record କରନ୍ତୁ। AI operators ମଧ୍ୟ ଏହିକଥା କହନ୍ତି: Anthropic ର ତାଙ୍କର hosted browser agent ପାଇଁ guidance ଟିପ୍ପଣୀ କରେ ଯେ ଯେକେହି ସେଇ User-Agent header ପଠାଇପାରେ ଏବଂ traffic କୁ genuine ଭାବେ ନେବା ପୂର୍ବରୁ ତାଙ୍କର published IP addresses check କରିବାକୁ ସୁପାରିଶ କରେ।
Default ଭାବେ Human କରିଦେବା। ଯଦି ଆପଣଙ୍କ code bot signals ମିଳୁନାହିଁ ବୋଲି ସବୁବେଳେ Human କହିଦିଏ, ତେବେ ଆପଣଙ୍କ Human numbers inflated ହେବ ଏବଂ policies ଭୁଲ traffic ଉପରେ trust କରିବ।
Class ଏବଂ basis ମିଶାଇଦେବା। ସଦା ଦୁହେଁ store କରନ୍ତୁ। କେବଳ "Agent" ଦେଖାଉଥିବା dashboard ଏକ verified operator ଏବଂ ଏକ copied string ମଧ୍ୟର ତଫାତ ଲୁଚାଇଦିଏ।
Observation ସମୟରେ block କରିବା। Temporary block ମଧ୍ୟ ଆପଣଙ୍କ measurements କୁ invalid କରେ, କାରଣ blocked clients ନିଜ ବ୍ୟବହାର ବଦଳାନ୍ତି।

Proof of Actor କେଉଁଠି fit ହୁଏ

ଉପରେ ଥିବା middleware ଏକ ଭଲ starting point, ଏବଂ ସେ core model କୁ ଦେଖାଏ: ପ୍ରଥମେ evidence, ପ୍ରତ୍ୟେକ result ପାଇଁ ସ୍ପଷ୍ଟ basis, Unknown visible ରହିଥାଏ, ଏବଂ decisions ଆପଣଙ୍କ application ପାଖରେ ରହିଯାଏ। Proof of Actor ସେଇ model ଉପରେ build କରେ, server, edge, browser ଏବଂ MCP context across deeper signal coverage ସହ, ଏବଂ analytics ଯାହା ଆପଣଙ୍କୁ confidence ସହ Detect, Understand ଏବଂ Route କରିବାକୁ ଦିଏ।

ଯଦି ଆପଣ production app ଉପରେ ଏହାକୁ ଆଗକୁ ନେବାରେ ସାହାଯ୍ୟ ଚାହୁଁଛନ୍ତି, early access ପାଇଁ apply କରନ୍ତୁ। Full decision flow ଦେଖିବାକୁ, How Proof of Actor works ପଢ଼ନ୍ତୁ।

ସ୍ରୋତଗୁଡ଼ିକ

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 copy ହୋଇପାରେ ବୋଲି ସତର୍କବାଣୀ

ଆମ ସହିତ ଏହା ତିଆରି କରନ୍ତୁ।

Proof of Actor founding developer program ରେ ଯୋଗଦିଅନ୍ତୁ।

Early Access ପାଆନ୍ତୁ ଡେଭେଲପର୍ କେନ୍ଦ୍ର

ପ୍ରଥମେ କଥାହେବାକୁ ପସନ୍ଦ କରନ୍ତି? founderମାନଙ୍କ ସହ କଥାବାର୍ତ୍ତା କରନ୍ତୁ