ഗൈഡ്

ഒരു Node.js app-ലേക്ക് actor context എങ്ങനെ ചേർക്കാം

ഓരോ request-ന്റെയും പിന്നിൽ ആരോ എന്തോ ഉണ്ടെന്ന് രേഖപ്പെടുത്തുന്ന middleware നിർമ്മിക്കാൻ ഘട്ടംഘട്ടമായി ഉള്ള ഒരു മാർഗ്ഗനിർദ്ദേശം, അതുവഴി നിങ്ങൾക്ക് ഏതെങ്കിലും enforcement ആരംഭിക്കുന്നതിന് മുമ്പ് യഥാർത്ഥ traffic പഠിക്കാം.

രചിച്ചത് Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

ആരംഭക · 9 മിനിറ്റ് വായന

Rules-ക്ക് പകരം actor context കൊണ്ട് തുടങ്ങേണ്ടത് എന്തുകൊണ്ട്?

തങ്ങളുടെ traffic-ൽ AI agents ഉണ്ടെന്ന് ശ്രദ്ധിക്കുന്ന പല ടീമുകളും ആദ്യം ഒരു rule-ലേക്കാണ് കൈ നീട്ടുന്നത്. ഒരു user agent block ചെയ്യുക, ഒരു challenge ചേർക്കുക, ഒരു rate limit കെട്ടിപ്പടുക്കുക. പ്രശ്നം ഇതാണ്: traffic നിങ്ങൾ മനസ്സിലാക്കുന്നതിന് മുമ്പ് എഴുതിയ ഒരു rule തെറ്റായ ആളുകളെ ബാധിക്കാനുള്ള സാധ്യത കൂടുതലാണ്. നിയമപരമായ assistants block ചെയ്യപ്പെടുന്നു, യഥാർത്ഥ users challenge ചെയ്യപ്പെടുന്നു, നിങ്ങൾ യഥാർത്ഥത്തിൽ ആശങ്കപ്പെട്ട automation അതിനെ തുടർച്ചയായി കൊണ്ടിരിക്കുന്നു, കാരണം അത് ആദ്യം തന്നെ സ്വയം തിരിച്ചറിയാതെ പോയിരിക്കുന്നു.

Actor context ആണ് rules-ക്കുമുമ്പിലുള്ള ഘട്ടം. ഓരോ request-ക്കും, പ്രവർത്തിക്കുന്നത് ആരോ എന്തോ എന്നതിനെക്കുറിച്ച് നിങ്ങളുടെ application നിരീക്ഷിക്കാൻ കഴിയുന്നതെന്താണോ അത് നിങ്ങൾ രേഖപ്പെടുത്തുന്നു: ഒരു interactive person, ഒരു AI assistant-നൊപ്പം പ്രവർത്തിക്കുന്ന person, ഒരു autonomous agent, അല്ലെങ്കിൽ ഇപ്പോഴും വ്യക്തമായി വേർതിരിക്കാൻ കഴിയാത്ത ഒന്നോ. ആ കാഴ്‌ചയുടെ പിന്നിലെ 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-ലേക്കും കൊണ്ടുപോകാം.

നിങ്ങൾ നിർമ്മിക്കുക എന്താണ്

അവസാനത്തിൽ നിങ്ങൾക്കുണ്ടാകുന്നത്:

ഓരോ request-ലും നിന്ന് actor evidence പുറത്തെടുക്കുന്ന ഒരു middleware.
ഓരോ result-ിനും പ്രസ്താവിച്ച basis ഉള്ള ചെറിയ, വ്യക്തമായ ഒരു classification.
request എങ്ങനെ കൈകാര്യം ചെയ്യപ്പെടുന്നു എന്നത് ഒരിക്കലും മാറ്റാത്ത structured observation logs.
പിന്നീട് handlers-ക്ക് വായിക്കാനാവുന്ന തരത്തിൽ result request-ലേക്ക് attach ചെയ്യാനുള്ള ഒരു മാർഗം.

ഇവിടെയൊന്നും ഒരു request block ചെയ്യുന്നില്ല. അത് ഉദ്ദേശിച്ചുള്ളതാണ്.

ഘട്ടം 1: നിങ്ങളുടെ server യഥാർത്ഥത്തിൽ കാണാൻ കഴിയുന്ന evidence എന്താണ്?

People കരുതുന്നതിനെക്കാൾ കുറച്ച് മാത്രമാണ് ഒരു server കാണുന്നത്. code എഴുതുന്നതിന് മുമ്പ്, നിങ്ങളുടെ edge-ൽ ലഭ്യമായ signals പട്ടികയാക്കുക:

Request signatures. ചില automated clients HTTP Message Signatures (RFC 9421) ഉപയോഗിച്ച് requests sign ചെയ്യുന്നു, പലപ്പോഴും operator-ന്റെ പ്രസിദ്ധീകരിച്ച keys-ലേക്ക് സൂചിപ്പിക്കുന്ന ഒരു Signature-Agent header-നൊപ്പം Signature-Input һәм Signature headers അയയ്ക്കുന്നു, IETF Web Bot Auth protocol draft-ൽ വിവരിച്ചതുപോലെ.
Declared identity. Clients User-Agent header-ലോ From header-ലോ, അല്ലെങ്കിൽ MCP client name പോലുള്ള protocol metadata വഴിയോ തങ്ങളെത്തന്നെ പേരിടാം. MCP clients 2025-11-25 revision-ന്റെ initialize request-ൽ സ്വയം തിരഞ്ഞെടുത്ത ഒരു 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. നിങ്ങളുടെ സ്വന്തം product network-ിന് അറിയാൻ കഴിയാത്ത കാര്യങ്ങൾ അറിയാമായിരിക്കും, ഉദാഹരണത്തിന് ഒരു user "AI assisted" option തിരഞ്ഞെടുക്കുന്നത്, അല്ലെങ്കിൽ നിങ്ങളുടെ built-in assistant feature-ൽ നിന്ന് request വരുന്നത്.

ഓരോ signal-ക്കും വ്യത്യസ്ത ശക്തിയുണ്ട്. ഒരു validated signature പരിശോധിക്കാനാകും. ഒരു user agent string ഒരു അവകാശവാദമാണ്. ഒരു missing cookie വെറുമൊരു അഭാവം മാത്രമാണ്. ഇവയെ വേർതിരിച്ച് സൂക്ഷിക്കുന്നതാണ് ഈ exercise-ന്റെ മുഴുവൻ ഉദ്ദേശം.

ഘട്ടം 2: ഫലം വ്യക്തമായി model ചെയ്യുക

Detection logic എഴുതുന്നതിന് മുമ്പ് actor result-ന്റെ shape നിർവചിക്കുക. ചെറിയ, typed model classification എന്താണ് അർത്ഥമാക്കുന്നത് എന്നതിൽ എല്ലാവരെയും സത്യസന്ധരാക്കുന്നു. ഇവിടെ ഉപയോഗിക്കുന്ന നാല് classes 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;
}

രണ്ട് fields ആണ് ഏറ്റവും പ്രധാനപ്പെട്ടത്. actor class ആണ്. basis നിങ്ങൾ അത് എന്തുകൊണ്ട് വിശ്വസിക്കുന്നു എന്ന് പറയുന്നു. ഒരു validated signature-ൽ അടിസ്ഥാനപ്പെടുത്തിയ agent result-ും ഒരു user agent string-ൽ അടിസ്ഥാനപ്പെടുത്തിയ agent result-ും രണ്ടും "agent" ആണെങ്കിലും, പിന്നീട് അവയ്ക്ക് വളരെ വ്യത്യസ്തമായ treatment ആവശ്യമാണ്, അതിനാൽ അവയെ ഒരിക്കലും ഒന്നാക്കി ചുരുക്കരുത്.

ഘട്ടം 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 signature headers നിലവിലുണ്ടെന്ന് മാത്രം രേഖപ്പെടുത്തുന്നു. Validation ഒരു വേറിട്ട ഘട്ടമാണ്, signed agent requests verify ചെയ്യുന്നതിനെക്കുറിച്ചുള്ള guide-ിൽ അത് ഉൾപ്പെടുത്തിയിരിക്കുന്നു.
User agent token list ഉദ്ദേശപൂർവ്വം ലളിതമാണ്. അത് ഒരു declaration മാത്രം സൃഷ്ടിക്കുന്നു, verification അല്ല.
x-app-assist ഒരു user നിങ്ങളുടെ built-in AI feature വഴി പ്രവർത്തിക്കുമ്പോൾ നിങ്ങളുടെ സ്വന്തം frontend അയയ്ക്കുന്ന ഒന്നിനായി placeholder ആണ്. അത് നിങ്ങളുടെ യഥാർത്ഥ mechanism-ൽ മാറ്റിസ്ഥാപിക്കുക.

ഘട്ടം 4: പ്രസ്താവിച്ച basis-ോടെ classify ചെയ്യുക

ഇപ്പോൾ evidence-നെ ഒരു result ആക്കുക. Rules ചെറുതായി വയ്ക്കുക, ഏറ്റവും ശക്തമായ evidence-ിൽ നിന്ന് ഏറ്റവും ദുർബലമായതിലേക്കുള്ള ക്രമത്തിൽ, എന്നും 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 ഒരു സാധുവായ, ഉപകാരപ്രദമായ answer ആണ്, നിങ്ങൾക്കുള്ള visibility എവിടെയാണ് അവസാനിക്കുന്നത് എന്ന് അത് കൃത്യമായി പറയുന്നു. AI traffic-നായി Unknown എന്തുകൊണ്ട് ഒരു valid 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();
});

ഈ setup സുരക്ഷിതമാക്കുന്ന മൂന്ന് വിശദാംശങ്ങൾ:

try block detection-ലെ ഒരു failure ഒരിക്കലും response-നെ ബാധിക്കില്ലെന്ന് ഉറപ്പാക്കുന്നു. Observation fail open ആകണം.
Logging finish-ൽ നടക്കുന്നു, അതിനാൽ നിങ്ങൾ യഥാർത്ഥ status code capture ചെയ്യുകയും പിന്നീട് classifications-നെ outcomes-നുമായി താരതമ്യം ചെയ്യുകയും ചെയ്യാം.
യഥാർത്ഥ validation നടപ്പിലാക്കുന്നതുവരെ verifySignature false-ലേക്ക് stub ചെയ്തിരിക്കുന്നു. ഇതുവഴി signed requests-നെ declared അല്ലെങ്കിൽ unknown buckets-ിൽ തന്നെ വയ്ക്കുന്നു, അവയെ അതിരുകടന്ന് അവതരിപ്പിക്കാതെ.

ഘട്ടം 6: debug-ക്കായി മാത്രം അല്ല, 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 മനസ്സിലാക്കാൻ മുഴുവൻ IP addresses, raw cookies അല്ലെങ്കിൽ request bodies ആവശ്യമില്ല. Correlation-ക്കായി ഏതെങ്കിലും identifier സൂക്ഷിക്കുന്നുവെങ്കിൽ, അത് rotating salt-ോടുകൂടി hash ചെയ്യുക, short retention period നിശ്ചയിക്കുക.

ഘട്ടം 7: പ്രവർത്തിക്കുന്നതിന് മുമ്പ് data വായിക്കുക

സാധാരണ ആഴ്ച്ചപ്പതിപ്പിലെ patterns കാണുന്നതിന് observation mode മതി നീളത്തിൽ പ്രവർത്തിപ്പിക്കുക. പിന്നീട് ചില ചോദ്യങ്ങൾക്ക് ഉത്തരം പറയുക:

ഏത് routes-ലാണ് agents കൂടുതലായി വരുന്നത്? Documentation, catalog, search endpoints സാധാരണയായി വരും. Account, checkout flows സാധാരണയായി വരരുത്.
Agent results-ൽ എത്ര ശതമാനം verified versus declared ആണ്? നിങ്ങൾ policies എഴുതുമ്പോൾ identity-യെ എത്രമാത്രം സുരക്ഷിതമായി ആശ്രയിക്കാനാകുമെന്ന് ആ ratio പറയുന്നു.
Unknown എവിടെയാണ് കൂടുതൽ കേന്ദ്രീകരിക്കുന്നത്? ഒരു route-ൽ ഉയർന്ന Unknown rate ഉണ്ടെങ്കിൽ, അവിടെ നിങ്ങൾക്ക് ഒരു signal നഷ്ടപ്പെട്ടിരിക്കാം, ഉദാഹരണത്തിന് നിങ്ങളുടെ frontend code ഒരിക്കലും പ്രവർത്തിക്കാത്ത ഒരു page.
Outcome-ുകൾ class അനുസരിച്ച് വ്യത്യാസപ്പെടുന്നുണ്ടോ? Error rates, conversion steps അല്ലെങ്കിൽ abuse reports classes-ക്കിടയിൽ താരതമ്യം ചെയ്യുക. യഥാർത്ഥ policy ആശയങ്ങൾ ഇവിടെ നിന്നാണ് വരുന്നത്.

ഉത്തരങ്ങൾ പലപ്പോഴും നിങ്ങളെ അത്ഭുതപ്പെടുത്തും. വലിയൊരു പങ്ക് "bot problem" യഥാർത്ഥത്തിൽ structured endpoint ലഭിച്ചാൽ സന്തോഷത്തോടെ ഉപയോഗിക്കുമായിരുന്ന നിയമപരമായ automation ആണെന്ന് ടീമുകൾ പതിവായി കണ്ടെത്തുന്നു.

ഘട്ടം 8: നിങ്ങളുടെ app-ന്റെ മറ്റു ഭാഗങ്ങളിലേക്ക് result expose ചെയ്യുക

Data ഒഴുകിത്തുടങ്ങിയാൽ, non-enforcing ഉപയോഗങ്ങൾക്കായി handlers-നെ res.locals.actor വായിക്കാൻ അനുവദിക്കുക: analytics tags, response format തിരഞ്ഞെടുക്കൽ, അല്ലെങ്കിൽ ഒരു support ticket AI-assisted session-ിൽ നിന്നുവന്നതെന്ന് രേഖപ്പെടുത്തൽ. ആരെയും 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 });
});

Challenges, rate limits അല്ലെങ്കിൽ step-up checks പോലുള്ള enforcement പിന്നീട് വരുന്നു, false positives നിങ്ങൾ അളന്നതിന് ശേഷം. Actor-aware policies roll out ചെയ്യുന്നതിനെക്കുറിച്ചുള്ള guide ആ പ്രക്രിയ ഉൾക്കൊള്ളുന്നു.

എന്തെല്ലാം പിഴവുകൾ ഒഴിവാക്കണം?

User agent-നെ identity ആയി കണക്കാക്കൽ. മാറ്റാൻ ഏറ്റവും എളുപ്പമുള്ള header അതാണ്. അത് ഒരു declaration ആയി രേഖപ്പെടുത്തുക. AI operators പോലും അങ്ങനെ പറയുന്നു: Anthropic-ന്റെ തങ്ങളുടെ hosted browser agent-ിനുള്ള guidance അനുസരിച്ച്, ആരും അതേ User-Agent header അയയ്ക്കാൻ കഴിയും, traffic യഥാർത്ഥമായി കണക്കാക്കുന്നതിന് മുമ്പ് അതിന്റെ പ്രസിദ്ധീകരിച്ച IP addresses പരിശോധിക്കണം എന്ന് അത് ശുപാർശ ചെയ്യുന്നു.
ഡീഫോൾട്ടായി Human നൽകൽ. Bot signals കണ്ടെത്താനാകാത്തപ്പോഴൊക്കെ നിങ്ങളുടെ code Human എന്ന് പറഞ്ഞാൽ, നിങ്ങളുടെ Human numbers ഉയർത്തിപ്പിടിക്കപ്പെടും, നിങ്ങളുടെ policies തെറ്റായ traffic-നെ വിശ്വസിക്കും.
Class-ഉം basis-ഉം കലർത്തി വയ്ക്കൽ. എല്ലായ്പ്പോഴും രണ്ടും സൂക്ഷിക്കുക. "Agent" മാത്രം കാണിക്കുന്ന dashboard verified operator-നും copied string-നും ഇടയിലെ വ്യത്യാസം മറയ്ക്കുന്നു.
Observation സമയത്ത് block ചെയ്യൽ. താൽക്കാലിക block പോലും നിങ്ങളുടെ measurements അസാധുവാക്കുന്നു, കാരണം blocked clients അവരുടെ behavior മാറ്റുന്നു.

Proof of Actor എവിടെയാണ് fit ചെയ്യുന്നത്

മുകളിലെ middleware ഒരു നല്ല തുടക്കമാണ്, കൂടാതെ core model അത് കാണിക്കുന്നു: ആദ്യം evidence, ഓരോ result-ിനും വ്യക്തമായ basis, Unknown visible ആയി നിലനിർത്തൽ, തീരുമാനങ്ങൾ നിങ്ങളുടെ application-ന് വിടൽ. Proof of Actor അതേ model-ൽ നിന്ന് കൂടുതൽ signal coverage-ോടെ server, edge, browser, MCP contexts എന്നിവയിലുടനീളം വികസിപ്പിക്കുന്നു, കൂടാതെ ആത്മവിശ്വാസത്തോടെ Detect, Understand, Route ചെയ്യാൻ സഹായിക്കുന്ന analytics ഉം നൽകുന്നു.

Production app-ൽ ഇത് കൂടുതൽ മുന്നോട്ട് കൊണ്ടുപോകുന്നതിന് സഹായം വേണമെങ്കിൽ, early access-ിനായി അപേക്ഷിക്കുക. മുഴുവൻ decision flow കാണാൻ, How Proof of Actor works വായിക്കുക.

സ്രോതസ്സുകൾ

RFC 9421: HTTP Message Signatures: signed requests-ിന് പിന്നിലെ standard
draft-ietf-webbotauth-httpsig-protocol: Signature-Agent header നിർവചിക്കുന്ന IETF Web Bot Auth draft (2026 November നിലയിൽ work in progress)
RFC 9110: HTTP Semantics, User-Agent and From: സ്വയം റിപ്പോർട്ട് ചെയ്യുന്ന 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: Anthropic-hosted browsers themselves എങ്ങനെ identify ചെയ്യുന്നു: user agent token, പ്രസിദ്ധീകരിച്ച IP addresses, header copy ചെയ്യാനാകുമെന്ന് മുന്നറിയിപ്പ്

ഞങ്ങളോടൊപ്പം അത് നിർമ്മിക്കുക.

Proof of Actor founding developer program-ിൽ ചേരുക.

Early Access നേടുക ഡെവലപ്പർ ഹബ്

ആദ്യം സംസാരിക്കണമോ? സ്ഥാപകരുമായി സംസാരിക്കുക