പ്രധാന ഉള്ളടക്കത്തിലേക്ക് കടക്കുക
ഗൈഡ്

ഒപ്പിട്ട AI ഏജന്റ് അഭ്യർത്ഥനകൾ എങ്ങനെ സ്ഥിരീകരിക്കാം

ഓട്ടോമേറ്റഡ് ക്ലയന്റുകളിൽ നിന്ന് വരുന്ന RFC 9421 signatures സ്ഥിരീകരിക്കുന്നതിനുള്ള പ്രായോഗിക വഴികാട്ടി, സാധുവായ signature എന്താണ് തെളിയിക്കുന്നത്, നിങ്ങളുടെ logs എന്തൊക്കെ രേഖപ്പെടുത്തണം എന്നിവ.

Toshendra Sharma

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

അഡ്വാൻസ്ഡ് · 11 മിനിറ്റ് വായന

ഒരു ഒപ്പിട്ട അഭ്യർത്ഥന എന്താണ് തെളിയിക്കുന്നത്?

മിക്ക ഓട്ടോമേറ്റഡ് traffic-വും ഒരു user agent string ഉപയോഗിച്ച് സ്വയം തിരിച്ചറിയുന്നു. ആ string ഒരു അവകാശവാദമാണ്, അതു പകർത്തുന്നതിന് ചിലവൊന്നുമില്ല. ഒപ്പിട്ട അഭ്യർത്ഥനകൾ ഈ സ്ഥിതിഗതികൾ മാറ്റുന്നു. ഒരു ഓട്ടോമേറ്റഡ് client തന്റെ HTTP requests ഒരു private key ഉപയോഗിച്ച് ഒപ്പിടുകയും, operator-ുമായി ബന്ധിപ്പിച്ച ഒരു സ്ഥലത്ത് പൊരുത്തപ്പെടുന്ന public key പ്രസിദ്ധീകരിക്കുകയും ചെയ്യുമ്പോൾ, key കൈവശമുള്ള ഒരാളാണ് യഥാർത്ഥത്തിൽ അഭ്യർത്ഥന സൃഷ്ടിച്ചതെന്ന് നിങ്ങളുടെ server പരിശോധിക്കാം.

ഇതിന്റെ പിന്നിലുള്ള standard ആണ് HTTP Message Signatures, RFC 9421 ആയി പ്രസിദ്ധീകരിച്ചത്. IETF Web Bot Auth working group ഓട്ടോമേറ്റഡ് clients-നുള്ള conventions ഉപയോഗിച്ച് ഇതിനെ വിപുലീകരിക്കുന്നു: ഒരു agent തന്റെ key directory എങ്ങനെ സൂചിപ്പിക്കുന്നു, കൂടാതെ ഏത് request components ആണ് ഒപ്പിടേണ്ടത് എന്നത്. November 2026 വരെ, working group-ന്റെ protocol document ആണ് draft-ietf-webbotauth-httpsig-protocol, അത് Signature-Agent header, JSON Web Key Sets അടിസ്ഥാനമാക്കിയുള്ള ഒരു key directory format, അത് സർവ് ചെയ്യുന്നതിനുള്ള ഒരു well-known URI എന്നിവ നിർവചിക്കുന്നു. രണ്ടും വിശദമായി മനസ്സിലാക്കേണ്ടതാണ്, കാരണം verification വളരെ സൂക്ഷ്മമായി തെറ്റിപ്പോകാൻ സാധ്യതയുണ്ട്.

Mechanics-ലേക്ക് കടക്കുന്നതിന് മുമ്പ്, ഫലത്തെക്കുറിച്ച് വ്യക്തമായി പറയുക. ഒരു സാധുവായ signature കാണിക്കുന്നത്, operator-ന്റെ domain പോലുള്ള published identifier-ുമായി ബന്ധപ്പെട്ട ഒരു key ആണ് അഭ്യർത്ഥന ഒപ്പിട്ടത് എന്നും, അഭ്യർത്ഥനയിലെ ഒപ്പിട്ട ഭാഗങ്ങൾ മാറ്റം വരുത്തിയിട്ടില്ല എന്നും ആണ്. അത് agent-നെ ആരാണ് നിർദ്ദേശിച്ചതെന്ന്, ഒരു വ്യക്തി അതിന് അധികാരം കൈമാറിയതാണോ എന്ന്, അല്ലെങ്കിൽ നടപടി സുരക്ഷിതമാണോ എന്ന് കാണിക്കുന്നില്ല. Identity evidence ഉം authorization ഉം വേറിട്ട ചോദ്യങ്ങളാണ്, നിങ്ങളുടെ application രണ്ടാമത്തേതിന് ഉത്തരം നൽകുന്നു. signed AI agent requests എന്താണ് തെളിയിക്കുന്നത് എന്ന ഞങ്ങളുടെ blog post ഈ അതിരിനെ ഉദാഹരണങ്ങളോടെ വിശദീകരിക്കുന്നു.

ഉൾപ്പെട്ടിരിക്കുന്ന headers

ഒരു ഒപ്പിട്ട അഭ്യർത്ഥന സാധാരണയായി മൂന്ന് headers വഹിക്കുന്നു:

  • Signature-Input (RFC 9421, Section 4.1) ഓരോ signature-ഉം വിവരിക്കുന്നു: ഒരു label, ഉൾപ്പെടുത്തിയിരിക്കുന്ന components-ന്റെ പട്ടിക, കൂടാതെ created, expires, keyid, alg, nonce, tag പോലുള്ള parameters.
  • Signature (RFC 9421, Section 4.2) ഓരോ label-ത്തിനും signature bytes structured field ആയി base64 encoded രൂപത്തിൽ വഹിക്കുന്നു.
  • Signature-Agent (Web Bot Auth conventions-ൽ നിന്ന്) client-ന്റെ public keys എവിടെ പ്രസിദ്ധീകരിച്ചിരിക്കുന്നു എന്ന് സൂചിപ്പിക്കുന്നു, സാധാരണ operator-ന്റെ domain-ലുള്ള ഒരു HTTPS URL.

ഒരു ലളിതമായ ഉദാഹരണം:

HTTP
GET /api/catalog?page=2 HTTP/1.1
Host: shop.example
Signature-Agent: "https://agent.example"
Signature-Input: sig1=("@method" "@authority" "@path" "signature-agent");created=1762934400;expires=1762934700;keyid="kq1";alg="ed25519";tag="web-bot-auth";nonce="d9f1c2"
Signature: sig1=:Base64SignatureBytes==:

വായനാസൗകര്യത്തിനായി ഉദാഹരണം ലളിതമാക്കിയതാണ്. നിലവിലുള്ള working group draft-ൽ, Signature-Agent സ്വയം signature label-ൽ keyed ചെയ്ത ഒരു structured field ആണ് (ഉദാഹരണത്തിന് sig1="https://agent.example"), അതിനാൽ നിങ്ങളുടെ verification library ഏത് രൂപമാണ് പ്രതീക്ഷിക്കുന്നതെന്ന് പരിശോധിക്കുക.

ഘട്ടം 1: structured fields ശരിയായി parse ചെയ്യുക

Signature-Inputവും Signatureവും HTTP Structured Fields ആണ് (RFC 9651, ഇത് RFC 8941-നെ obsoletes ചെയ്യുന്നു). ഇവയെ string splitting ഉപയോഗിച്ച് parse ചെയ്യരുത്. Quoted strings, parameters, inner lists എന്നിവയ്ക്കെല്ലാം കൃത്യമായ grammar ഉണ്ട്, അശ്രദ്ധമായ parser തെറ്റായ നിരാകരണങ്ങളും യഥാർത്ഥ സുരക്ഷാ വിടവുകളും സൃഷ്ടിക്കും.

പരിപാലിക്കപ്പെടുന്ന structured-field parser ഉപയോഗിക്കുക, അല്ലെങ്കിൽ അതിലും നല്ലത്, parsing, verification എന്നിവ ഒരുമിച്ച് കൈകാര്യം ചെയ്യുന്ന ഒരു പരിപാലിക്കപ്പെടുന്ന RFC 9421 library ഉപയോഗിക്കുക. Specification തുടക്കം മുതൽ implement ചെയ്യുന്നത് പഠനത്തിന് നല്ലതാണ്, പക്ഷേ production-ന് മോശം തിരഞ്ഞെടുപ്പാണ്. താഴെ പറയുന്ന ഘട്ടങ്ങൾ അത്തരം ഒരു library എന്താണ് ചെയ്യുന്നതെന്ന് വിശദീകരിക്കുന്നു, അതുവഴി നിങ്ങൾക്ക് അത് ശരിയായി configure ചെയ്യാനും അതിന്റെ output പരിശോധിക്കാനും കഴിയും.

ഘട്ടം 2: ഏത് signature ആണ് വിലയിരുത്തേണ്ടത് എന്ന് തിരഞ്ഞെടുക്കുക

ഒരു അഭ്യർത്ഥന ഒന്നിലധികം signature labels വഹിക്കാം. നിങ്ങളുടെ policy-ക്ക് പൊരുത്തപ്പെടുന്നതിനെ തിരഞ്ഞെടുക്കുക, ഉദാഹരണത്തിന് tag web-bot-auth ആയിരിക്കുന്ന label. താഴെപ്പറയുന്ന സാഹചര്യങ്ങളിൽ verification purposes-ക്ക് വേണ്ടി അഭ്യർത്ഥന നിരസിക്കുക (serving purposes-ക്കല്ല):

  • നിങ്ങൾക്ക് ആവശ്യമായ parameters ഉള്ള signature ഇല്ലെങ്കിൽ,
  • algorithm നിങ്ങളുടെ allowlist-ൽ ഇല്ലെങ്കിൽ (ഉദാഹരണത്തിന് ed25519), അല്ലെങ്കിൽ
  • ഉൾപ്പെടുത്തിയിരിക്കുന്ന components നിങ്ങൾക്ക് ആവശ്യമായ കുറഞ്ഞ set ഉൾക്കൊള്ളുന്നില്ലെങ്കിൽ.

ഓട്ടോമേറ്റഡ് clients-നുള്ള യുക്തിസഹമായ കുറഞ്ഞ set ആണ് @method, @authority, @path, കൂടാതെ ആ header ഉണ്ടായിരിക്കുമ്പോൾ signature-agent കൂടി. @authority ഇല്ലാതെ, ഒരു site-നായി പിടിച്ച signature മറ്റൊരു site-നെതിരെ replay ചെയ്യാം. @path ഇല്ലാതെ, അത് endpoints-ക്കപ്പുറം വീണ്ടും ഉപയോഗിക്കാം. Web Bot Auth protocol draft agents-നെ @authority അല്ലെങ്കിൽ @target-uri ഉൾക്കൊള്ളാൻ ആവശ്യപ്പെടുന്നു, കൂടാതെ authority മാത്രം ഉൾക്കൊള്ളുന്ന signature അത് expire ആകുന്നതുവരെ ആ host-ിലെ ഏത് method-ിനും path-ിനും എതിരെയും verify ചെയ്യാമെന്ന് മുന്നറിയിപ്പ് നൽകുന്നു.

ഘട്ടം 3: time parameters പരിശോധിക്കുക

RFC 9421, Section 2.3-ൽ നിർവചിച്ചിരിക്കുന്ന createdനും expiresനും വായിക്കുക. തുടർന്ന്:

  1. created സമയം ചെറിയ clock skew allowance-നെക്കാൾ ഭാവിയിലായ signature-കൾ നിരസിക്കുക.
  2. expires കഴിഞ്ഞ signature-കൾ നിരസിക്കുക.
  3. expires ഇല്ലെങ്കിൽ, created അടിസ്ഥാനമാക്കി നിങ്ങളുടെ സ്വന്തം maximum age പ്രയോഗിക്കുക.

ചെറുതായ validity windows പിടിച്ചെടുത്ത അഭ്യർത്ഥന എത്രനേരം replay ചെയ്യാനാകുമെന്നത് കുറയ്ക്കുന്നു.

ഘട്ടം 4: key കണ്ടെത്തുക

Signature-Agent header operator-ന്റെ key directory-യിലേക്ക് സൂചിപ്പിക്കുന്നു. അത് HTTPS വഴി മാത്രം fetch ചെയ്യുക. Web Bot Auth protocol draft ഡയറക്ടറിയെ ഒരു JSON Web Key Set ആയി വിവരിക്കുന്നു (JWK format-ിലുള്ള keys) അവ http-message-signatures-directory well-known URI-ൽ ആ origin-ിൽ നിന്ന് സർവ് ചെയ്യപ്പെടുന്നു. തുടർന്ന് keyid parameter-ുമായി പൊരുത്തപ്പെടുന്ന identifier ഉള്ള key കണ്ടെത്തുക.

TS
type Jwk = { kid: string; kty: string; crv?: string; x?: string };

const keyCache = new Map<string, { keys: Jwk[]; fetchedAt: number }>();
const KEY_TTL_MS = 60 * 60 * 1000;

export async function getKey(directoryUrl: string, keyId: string): Promise<Jwk | null> {
  const url = new URL(directoryUrl);
  if (url.protocol !== "https:") return null;

  const cached = keyCache.get(url.origin);
  const fresh = cached && Date.now() - cached.fetchedAt < KEY_TTL_MS;
  const keys = fresh ? cached.keys : await fetchKeys(url.origin);
  return keys.find((k) => k.kid === keyId) ?? null;
}

async function fetchKeys(origin: string): Promise<Jwk[]> {
  const res = await fetch(`${origin}/.well-known/http-message-signatures-directory`, {
    headers: { accept: "application/http-message-signatures-directory+json, application/json" },
    signal: AbortSignal.timeout(2000),
  });
  if (!res.ok) return [];
  const body = (await res.json()) as { keys?: Jwk[] };
  const keys = Array.isArray(body.keys) ? body.keys : [];
  keyCache.set(origin, { keys, fetchedAt: Date.now() });
  return keys;
}

Key discovery-ക്കുള്ള പ്രായോഗിക നിയമങ്ങൾ:

  • Keys cache ചെയ്യുക bounded lifetime ഉപയോഗിച്ച്, ഓരോ അഭ്യർത്ഥനയ്ക്കും verification ഒരു network call ചേർക്കാതിരിക്കാൻ.
  • ചുരുങ്ങിയ timeout സജ്ജമാക്കുക, failure-ആയ fetch-നെ "could not verify" എന്നായി കണക്കാക്കുക, ഒരിക്കലും "verified" എന്നല്ല.
  • എവിടെ നിന്ന് fetch ചെയ്യണം എന്ന് നിയന്ത്രിക്കുക കഴിയുമെങ്കിൽ, അല്ലെങ്കിൽ കുറഞ്ഞത് private address ranges തടയുക, server-side request forgery ഒഴിവാക്കാൻ. Protocol draft ഇതേ കാരണത്താൽ തന്നെ security considerations-ൽ server-side request forgery പട്ടികപ്പെടുത്തുന്നു.
  • Identity origin-ുമായി ബന്ധിപ്പിക്കുക, user agent-ിലെ free-text name-ുമായി അല്ല. നിങ്ങൾ record ചെയ്യുന്ന identifier ആണ് directory origin.

ഘട്ടം 5: signature base പുനർനിർമ്മിക്കുക

Signer raw request ഒപ്പിട്ടതല്ല. അത് signature base എന്ന് വിളിക്കുന്ന ഒരു canonical string ആണ് ഒപ്പിട്ടത് (RFC 9421, Section 2.5), covered components ക്രമത്തിൽ, തുടർന്ന് @signature-params വരിയും ഉൾപ്പെടുത്തി നിർമ്മിച്ചത്. നിങ്ങളുടെ verifier താൻ സ്വീകരിച്ച request-ിൽ നിന്ന് അതേ string പുനർനിർമ്മിക്കുന്നു.

മുകളിൽ കാണിച്ച ഉദാഹരണത്തിനായി base ഇതുപോലെ കാണപ്പെടും:

TEXT
"@method": GET
"@authority": shop.example
"@path": /api/catalog
"signature-agent": "https://agent.example"
"@signature-params": ("@method" "@authority" "@path" "signature-agent");created=1762934400;expires=1762934700;keyid="kq1";alg="ed25519";tag="web-bot-auth";nonce="d9f1c2"

Proxy-കൾക്കു പിന്നിൽ verification തകർക്കുന്ന വിശദാംശങ്ങൾ ശ്രദ്ധിക്കുക:

  • @authority client ലക്ഷ്യമിട്ട host ആയിരിക്കണം. ഒരു load balancer Host പുനരേഖപ്പെടുത്തുന്നുവെങ്കിൽ, അത് forward ചെയ്യുന്ന original value ഉപയോഗിക്കുക.
  • @path query string ഒഴിവാക്കുന്നു. Client @query ഉൾപ്പെടുത്തിയിരുന്നെങ്കിൽ, അത് ലഭിച്ചിരിക്കുന്നതുപോലെ തന്നെ പുനർനിർമ്മിക്കുക.
  • Header values നിർദ്ദേശിച്ചിരിക്കുന്ന പ്രകാരം canonicalize ചെയ്യപ്പെടുന്നു: trimmed, multiple values ഒറ്റയാക്കുന്നു. നല്ല library ഇത് നിങ്ങൾക്കായി ചെയ്യുന്നു.

ഘട്ടം 6: signature സ്ഥിരീകരിക്കുക

Base ഉം public key ഉം ഉപയോഗിച്ച്, RFC 9421, Section 3.2-ൽ ഉള്ള ഘട്ടങ്ങൾ പിന്തുടർന്ന് verification ഒറ്റ call ആണ്. Node.js-ൽ Ed25519-നായി, built-in crypto module ഉപയോഗിച്ച്:

TS
import { createPublicKey, verify } from "node:crypto";

export function verifyEd25519(jwk: Jwk, base: string, signatureB64: string): boolean {
  const key = createPublicKey({ key: jwk as any, format: "jwk" });
  return verify(null, Buffer.from(base, "utf8"), key, Buffer.from(signatureB64, "base64"));
}

പരിശോധന പരാജയപ്പെട്ടാൽ, അഭ്യർത്ഥന verified അല്ല. അതിനെ ഇപ്പോഴും serve ചെയ്യാം. അതിന് simply "verified" basis ലഭിക്കില്ല.

ഘട്ടം 7: replay തടയുക

ഒരു സാധുവായ signature പിടിച്ചെടുത്ത് അത് expire ആകുന്നതുവരെ വീണ്ടും അയയ്ക്കാൻ കഴിയും. RFC 9421, Section 7.2.2 signature replay-നെ ഉൾക്കൊള്ളുന്നു, കൂടാതെ Web Bot Auth protocol draft സ്വന്തം nonce rules ചേർക്കാതെ അതിനെയാണ് ആശ്രയിക്കുന്നത്. ആ window-ന്റെ ഭൂരിഭാഗവും അടയ്ക്കുന്ന രണ്ട് controls ഇതാണ്:

  1. ചുരുങ്ങിയ expiry, ഘട്ടം 3-ൽ enforce ചെയ്യുന്നത്.
  2. Nonce tracking. ഒരു nonce ഉണ്ടായിരിക്കുമ്പോൾ, അത് അതിന്റെ key identifier-ോടെ signature expire ആകുന്നതുവരെ ഒരു shared store-ൽ സൂക്ഷിക്കുക, തുടർന്ന് രണ്ടാമത്തെ ഉപയോഗം നിരസിക്കുക.
TS
const seen = new Map<string, number>();

export function acceptNonce(keyId: string, nonce: string, expiresAt: number): boolean {
  const id = `${keyId}:${nonce}`;
  const now = Date.now() / 1000;
  for (const [k, exp] of seen) if (exp < now) seen.delete(k);
  if (seen.has(id)) return false;
  seen.set(id, expiresAt);
  return true;
}

ഒന്നിലധികം instance-ുകളുള്ള deployment-ൽ, ശേഷിക്കുന്ന validity-യ്ക്ക് തുല്യമായ time to live ഉള്ള Redis പോലുള്ള shared store-ൽ nonces സൂക്ഷിക്കുക.

ഘട്ടം 8: ഫലം അതിന്റെ basis-ോടെ രേഖപ്പെടുത്തുക

Verification തെളിവ് സൃഷ്ടിക്കുന്നു, വിധിയല്ല. നിങ്ങളുടെ analytics, policies എന്നിവക്ക് ഉപയോഗിക്കാവുന്ന രൂപത്തിൽ അത് രേഖപ്പെടുത്തുക:

TS
const result = {
  actor: "agent",
  basis: "verified",
  operator: "https://agent.example",
  keyId: "kq1",
  coveredComponents: ["@method", "@authority", "@path", "signature-agent"],
  verifiedAt: new Date().toISOString(),
};

Verification പരാജയപ്പെടുകയോ പ്രവർത്തിക്കാനാകാതിരിക്കുകയോ ചെയ്താൽ, കാരണം സഹിതം അത് കൂടി രേഖപ്പെടുത്തുക: missing headers, unsupported algorithm, key not found, expired, replayed, അല്ലെങ്കിൽ signature mismatch. ഈ കാരണങ്ങൾ വിലപ്പെട്ടവയാണ്. ഒരു operator-ിൽ നിന്ന് "key not found" പെട്ടെന്ന് വർധിക്കുന്നത് പലപ്പോഴും അവർ keys rotate ചെയ്തതാണെന്നു സൂചിപ്പിക്കുന്നു, അവർ നിങ്ങളെ ആക്രമിക്കുന്നുവെന്നല്ല.

signature verification-ൽ നിന്ന് നിങ്ങൾ എന്താണ് log ചെയ്യേണ്ടത്?

Operator origin, key identifier, covered components, time parameters, outcome, failure reason എന്നിവ log ചെയ്യുക. മുഴുവൻ signature bytes അല്ലെങ്കിൽ പൂർണ്ണ request bodies log ചെയ്യരുത്. നിങ്ങളുടെ privacy commitments മാനിച്ചുകൊണ്ട്, pattern-ുകൾ പഠിക്കാൻ മതിയാകുന്നത്രയും logs സൂക്ഷിക്കുക, അതിലധികം അല്ല.

ഒരു verified signature നിങ്ങളുടെ policy എങ്ങനെ മാറ്റണം?

അഭ്യർത്ഥനകൾ verify ചെയ്യാൻ കഴിയുമ്പോൾ, അവയെ അർത്ഥവത്തായ രീതിയിൽ വ്യത്യസ്തമായി കൈകാര്യം ചെയ്യാം. മനുഷ്യർക്കും AI agents-നും വേണ്ടി app policies രൂപകൽപ്പന ചെയ്യുന്നതിനെക്കുറിച്ചുള്ള ഞങ്ങളുടെ പോസ്റ്റ് designing app policies for humans and AI agents വിപുലമായ policy model ഉൾക്കൊള്ളുന്നു:

  • Verified operators-നെ read-only routes-ൽ unverified automation-നെക്കാൾ ഉയർന്ന rate limit-ോടെ അനുവദിക്കുക.
  • പൂർണ്ണ HTML pages-ന് പകരം JSON അല്ലെങ്കിൽ Markdown പോലുള്ള structured responses നൽകുക.
  • ഉയർന്ന പ്രഭാവമുള്ള actions നിങ്ങളുടെ സാധാരണ authorization-ന്റെ പിന്നിൽ തന്നെ വയ്ക്കുക. ഒരു verified signature ഏത് client ആണ് വിളിക്കുന്നത് എന്ന് പറയുന്നു, അക്കൗണ്ട് മാറ്റാൻ അതിന് കഴിയുമോ എന്ന് അല്ല.

Observation mode-ൽ ആരംഭിക്കുക. ഏതത്ര automated traffic signed ആണ്, ഏത് operators പ്രത്യക്ഷപ്പെടുന്നു, verification എത്രത്തവണ പരാജയപ്പെടുന്നു എന്നിവ, അതിനെ ആശ്രയിച്ചുള്ള ഏതെങ്കിലും policy ആരംഭിക്കുന്നതിന് മുമ്പ് അളക്കുക.

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

Signature verification, തെളിവിന്റെ പല sources-ിൽ ഒന്ന് മാത്രമാണ്. Proof of Actor അത് മറ്റു signals-ുമായി ചേർക്കുകയും, ഓരോ result-ലും basis ദൃശ്യമാക്കി നിലനിർത്തുകയും ചെയ്യുന്നു, അതുവഴി verified agent ഒരിക്കലും സ്വയം declared ചെയ്ത one-ുമായി കുഴക്കപ്പെടുന്നില്ല. നിങ്ങളുടെ application പിന്നീട് എന്ത് സംഭവിക്കണം എന്ന് തീരുമാനിക്കുന്നു.

ഞങ്ങളുടെ engineers-ുമായി ചേർന്ന് ഇത് ഒരു production app-ിൽ നിർമ്മിക്കാൻ, early access-ിനായി അപേക്ഷിക്കുക. തെളിവ് എന്താണ് കാണിക്കാനും കാണിക്കാനാകാത്തതും എന്നതിന്റെ പൂർണ്ണ ചിത്രം ലഭിക്കാൻ, Detection & Limitations വായിക്കുക.

Sources

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

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

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

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