ਮੁੱਖ ਸਮੱਗਰੀ 'ਤੇ ਜਾਓ
ਮਾਰਗਦਰਸ਼ਕ

ਦਸਤਖਤ ਕੀਤੀਆਂ AI ਏਜੰਟ ਬੇਨਤੀਆਂ ਦੀ ਪੁਸ਼ਟੀ ਕਿਵੇਂ ਕਰਨੀ ਹੈ

RFC 9421 signatures ਦੀ automated clients ਤੋਂ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਇੱਕ ਵਿਆਵਹਾਰਿਕ walkthrough, ਇੱਕ ਵੈਧ signature ਕੀ ਸਾਬਤ ਕਰਦੀ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ logs ਵਿੱਚ ਕੀ capture ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ.

Toshendra Sharma

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

ਉੱਚ ਪੱਧਰ · 11 ਮਿੰਟ ਪੜ੍ਹਨ ਸਮਾਂ

ਦਸਤਖਤ ਕੀਤੀ ਬੇਨਤੀ ਕੀ ਸਾਬਤ ਕਰਦੀ ਹੈ?

ਜ਼ਿਆਦਾਤਰ automated traffic ਆਪਣੇ ਆਪ ਨੂੰ ਇੱਕ user agent string ਨਾਲ ਦਰਸਾਉਂਦਾ ਹੈ। ਉਹ string ਇੱਕ ਦਾਅਵਾ ਹੈ, ਅਤੇ ਉਸਦੀ ਨਕਲ ਕਰਨ ਦੀ ਕੋਈ ਲਾਗਤ ਨਹੀਂ ਹੁੰਦੀ। ਦਸਤਖਤ ਕੀਤੀਆਂ ਬੇਨਤੀਆਂ ਇਹ ਤਸਵੀਰ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ। ਜਦੋਂ ਇੱਕ automated client ਆਪਣੇ HTTP requests ਨੂੰ private key ਨਾਲ sign ਕਰਦਾ ਹੈ ਅਤੇ operator ਨਾਲ ਜੁੜੀ ਇਕ ਥਾਂ ਤੇ matching public key ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡਾ server ਜਾਂਚ ਸਕਦਾ ਹੈ ਕਿ request ਸਚਮੁੱਚ ਉਸ key ਨੂੰ ਰੱਖਣ ਵਾਲੇ ਕਿਸੇ ਵਿਅਕਤੀ ਵੱਲੋਂ ਬਣਾਈ ਗਈ ਸੀ।

ਇਸ ਦੇ ਪਿੱਛੇ ਮਿਆਰ HTTP Message Signatures ਹੈ, ਜੋ RFC 9421 ਵਜੋਂ ਪ੍ਰਕਾਸ਼ਿਤ ਹੈ। IETF Web Bot Auth working group automated clients ਲਈ ਇਸ ਉੱਤੇ conventions ਬਣਾਉਂਦਾ ਹੈ: agent ਆਪਣੀ key directory ਕਿਵੇਂ ਦਰਸਾਵੇ ਅਤੇ request ਦੇ ਕਿਹੜੇ components ਉਸਨੂੰ sign ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ। November 2026 ਤੱਕ, working group's protocol document draft-ietf-webbotauth-httpsig-protocol ਹੈ, ਜੋ Signature-Agent header, JSON Web Key Sets ਉੱਤੇ ਆਧਾਰਿਤ key directory format, ਅਤੇ ਉਸਨੂੰ serve ਕਰਨ ਲਈ ਇੱਕ well-known URI ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਦੋਵੇਂ ਨੂੰ detail ਵਿੱਚ ਸਮਝਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ verification ਵਿੱਚ subtle ਗਲਤੀਆਂ ਆਸਾਨੀ ਨਾਲ ਹੋ ਸਕਦੀਆਂ ਹਨ।

Mechanics ਤੋਂ ਪਹਿਲਾਂ, ਨਤੀਜੇ ਬਾਰੇ ਸਪਸ਼ਟ ਰਹੋ। ਇੱਕ ਵੈਧ signature ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ request ਕਿਸੇ ਪ੍ਰਕਾਸ਼ਿਤ identifier, ਜਿਵੇਂ operator ਦੇ domain, ਨਾਲ ਜੁੜੀ key ਨਾਲ sign ਕੀਤੀ ਗਈ ਸੀ, ਅਤੇ ਇਹ ਕਿ request ਦੇ signed ਹਿੱਸੇ ਬਦਲੇ ਨਹੀਂ ਗਏ ਸਨ। ਇਹ ਨਹੀਂ ਦਿਖਾਉਂਦੀ ਕਿ agent ਨੂੰ ਕਿਸਨੇ ਨਿਰਦੇਸ਼ ਦਿੱਤੇ, ਕੀ ਕਿਸੇ ਵਿਅਕਤੀ ਨੇ ਉਸਨੂੰ authority ਦਿੱਤੀ ਸੀ, ਜਾਂ ਕੀ ਕਾਰਵਾਈ ਸੁਰੱਖਿਅਤ ਹੈ। Identity evidence ਅਤੇ authorization ਵੱਖਰੇ ਸਵਾਲ ਹਨ, ਅਤੇ ਤੁਹਾਡੀ application ਦੂਜੇ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ। ਸਾਡੇ blog post what signed AI agent requests prove ਵਿੱਚ examples ਨਾਲ ਇਹ boundary ਵਿਆਖਿਆ ਕੀਤੀ ਗਈ ਹੈ।

ਕਿਹੜੇ headers ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ

ਇੱਕ signed request ਆਮ ਤੌਰ ਤੇ ਤਿੰਨ headers ਰੱਖਦੀ ਹੈ:

  • Signature-Input (RFC 9421, Section 4.1) ਹਰ signature ਦਾ ਵੇਰਵਾ ਦਿੰਦਾ ਹੈ: ਇੱਕ label, covered components ਦੀ list, ਅਤੇ parameters ਜਿਵੇਂ created, expires, keyid, alg, nonce ਅਤੇ tag.
  • Signature (RFC 9421, Section 4.2) ਹਰ label ਲਈ signature bytes ਰੱਖਦਾ ਹੈ, base64 encoded, structured field ਵਜੋਂ।
  • Signature-Agent (Web Bot Auth conventions ਤੋਂ) ਉਸ ਥਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ ਜਿੱਥੇ client ਦੀਆਂ public keys ਪ੍ਰਕਾਸ਼ਿਤ ਹੁੰਦੀਆਂ ਹਨ, ਆਮ ਤੌਰ ਤੇ operator ਦੇ domain ਉੱਤੇ ਇੱਕ HTTPS URL।

ਇੱਕ ਸਰਲ example:

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==:

ਇਹ example ਪੜ੍ਹਨ ਯੋਗਤਾ ਲਈ ਸਰਲ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਮੌਜੂਦਾ working group draft ਵਿੱਚ, Signature-Agent ਖੁਦ signature label ਨਾਲ keyed ਇੱਕ structured field ਹੈ (ਉਦਾਹਰਨ ਵਜੋਂ sig1="https://agent.example"), ਇਸ ਲਈ ਜਾਂਚੋ ਕਿ ਤੁਹਾਡੀ verification library ਕਿਸ format ਦੀ ਉਮੀਦ ਕਰਦੀ ਹੈ।

ਕਦਮ 1: Structured fields ਨੂੰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ parse ਕਰੋ

Signature-Input ਅਤੇ Signature HTTP Structured Fields ਹਨ (RFC 9651, ਜੋ RFC 8941 ਨੂੰ supersede ਕਰਦਾ ਹੈ)। ਇਨ੍ਹਾਂ ਨੂੰ string splitting ਨਾਲ parse ਨਾ ਕਰੋ। Quoted strings, parameters ਅਤੇ inner lists ਸਭ ਦੀ grammar ਬਹੁਤ ਸਟੀਕ ਹੈ, ਅਤੇ ਢਿੱਲਾ parser false rejections ਅਤੇ ਅਸਲੀ security gaps ਦੋਵੇਂ ਪੈਦਾ ਕਰਦਾ ਹੈ।

ਇੱਕ maintained structured-field parser ਵਰਤੋ, ਜਾਂ ਇਸ ਤੋਂ ਵੀ ਵਧੀਆ, ਇੱਕ maintained RFC 9421 library ਜੋ parsing ਅਤੇ verification ਨੂੰ ਇਕੱਠੇ ਸੰਭਾਲਦੀ ਹੋਵੇ। Specification ਨੂੰ scratch ਤੋਂ implement ਕਰਨਾ ਸਿੱਖਣ ਲਈ ਚੰਗੀ exercise ਹੈ ਅਤੇ production ਲਈ ਖਰਾਬ ਚੋਣ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੇ ਕਦਮ ਦੱਸਦੇ ਹਨ ਕਿ ਅਜਿਹੀ library ਕੀ ਕਰਦੀ ਹੈ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਉਸਨੂੰ ਠੀਕ ਤਰੀਕੇ ਨਾਲ configure ਕਰ ਸਕੋ ਅਤੇ ਉਸਦੇ output ਦੀ ਸਮੀਖਿਆ ਕਰ ਸਕੋ।

ਕਦਮ 2: ਕਿਹੜੀ signature evaluate ਕਰਨੀ ਹੈ, ਇਹ ਚੁਣੋ

ਇੱਕ request ਵਿੱਚ ਇੱਕ ਤੋਂ ਵੱਧ signature label ਹੋ ਸਕਦੇ ਹਨ। ਉਹ label ਚੁਣੋ ਜੋ ਤੁਹਾਡੀ policy ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਵੇ, ਉਦਾਹਰਨ ਵਜੋਂ ਉਹ label ਜਿਸਦਾ tag web-bot-auth ਹੈ। ਜੇ ਇਹ ਹਾਲਾਤ ਹੋਣ, ਤਾਂ verification purposes ਲਈ request ਨੂੰ reject ਕਰੋ, serving purposes ਲਈ ਨਹੀਂ:

  • ਕਿਸੇ ਵੀ signature ਵਿੱਚ ਤੁਹਾਡੇ ਲੋੜੀਂਦੇ parameters ਨਹੀਂ ਹਨ,
  • algorithm ਤੁਹਾਡੀ allowlist ਉੱਤੇ ਨਹੀਂ ਹੈ (ਉਦਾਹਰਨ ਵਜੋਂ ed25519), ਜਾਂ
  • covered components ਵਿੱਚ ਤੁਹਾਡੇ ਲੋੜੀਂਦੇ minimum set ਸ਼ਾਮਲ ਨਹੀਂ ਹਨ।

Automated clients ਲਈ ਇੱਕ ਵਾਜਬ minimum @method, @authority ਅਤੇ @path ਹੈ, ਨਾਲ ਹੀ signature-agent ਜਦੋਂ ਉਹ header ਮੌਜੂਦ ਹੋਵੇ। @authority ਦੇ ਬਿਨਾਂ, ਇੱਕ site ਲਈ captured signature ਦੂਜੇ site ਉੱਤੇ replay ਹੋ ਸਕਦੀ ਹੈ। @path ਦੇ ਬਿਨਾਂ, ਇਹ endpoints ਵਿਚ ਦੁਬਾਰਾ ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ। Web Bot Auth protocol draft agents ਨੂੰ @authority ਜਾਂ @target-uri cover ਕਰਨ ਦੀ ਲੋੜ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਚੇਤਾਵਨੀ ਦਿੰਦਾ ਹੈ ਕਿ ਸਿਰਫ authority ਨੂੰ cover ਕਰਨ ਵਾਲੀ signature ਉਸ host ਉੱਤੇ ਕਿਸੇ ਵੀ method ਜਾਂ path ਨਾਲ ਉਸਦੀ ਮਿਆਦ ਖਤਮ ਹੋਣ ਤੱਕ verify ਹੋ ਜਾਵੇਗੀ।

ਕਦਮ 3: ਸਮੇਂ ਵਾਲੇ parameters ਦੀ ਜਾਂਚ ਕਰੋ

created ਅਤੇ expires ਪੜ੍ਹੋ, ਜੋ RFC 9421, Section 2.3 ਵਿੱਚ defined time parameters ਹਨ। ਫਿਰ:

  1. ਉਹ signatures reject ਕਰੋ ਜਿਨ੍ਹਾਂ ਦਾ created ਸਮਾਂ ਛੋਟੀ clock skew allowance ਤੋਂ ਬਾਹਰ ਭਵਿੱਖ ਵਿੱਚ ਹੈ।
  2. ਉਹ signatures reject ਕਰੋ ਜਿਨ੍ਹਾਂ ਦੀ expires ਲੰਘ ਚੁੱਕੀ ਹੈ।
  3. ਜੇ expires ਗਾਇਬ ਹੈ, ਤਾਂ created ਦੇ ਆਧਾਰ ਤੇ ਆਪਣੀ maximum age ਲਾਗੂ ਕਰੋ।

ਛੋਟੀਆਂ validity windows captured request ਦੇ replay ਹੋਣ ਦੀ ਮਿਆਦ ਘਟਾਉਂਦੀਆਂ ਹਨ।

ਕਦਮ 4: key ਲੱਭੋ

Signature-Agent header operator ਦੀ key directory ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਇਸਨੂੰ HTTPS ਰਾਹੀਂ ਲਵੋ, ਅਤੇ ਸਿਰਫ HTTPS ਰਾਹੀਂ। Web Bot Auth protocol draft directory ਨੂੰ ਇੱਕ JSON Web Key Set ਵਜੋਂ ਵਰਣਨ ਕਰਦਾ ਹੈ (keys JWK format ਵਿੱਚ) ਜੋ ਉਸ origin ਦੇ http-message-signatures-directory well-known URI ਤੋਂ serve ਹੁੰਦਾ ਹੈ। ਫਿਰ ਉਸ key ਨੂੰ ਲੱਭੋ ਜਿਸਦਾ identifier keyid parameter ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਵੇ।

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 ਹਰ request ਲਈ network call ਨਾ ਜੋੜੇ।
  • Short timeout set ਕਰੋ ਅਤੇ failed fetch ਨੂੰ "could not verify" ਮੰਨੋ, ਕਦੇ ਵੀ "verified" ਨਹੀਂ।
  • ਕਿਹੜੇ origins ਤੋਂ fetch ਕਰਨਾ ਹੈ, ਉਸਨੂੰ ਸੀਮਤ ਕਰੋ ਜੇ ਤੁਸੀਂ ਕਰ ਸਕੋ, ਜਾਂ ਘੱਟੋ-ਘੱਟ private address ranges block ਕਰੋ ਤਾਂ ਜੋ server-side request forgery ਤੋਂ ਬਚ ਸਕੋ। Protocol draft ਇਸੇ ਕਾਰਨ ਆਪਣੀਆਂ security considerations ਵਿੱਚ server-side request forgery ਦੀ ਗੱਲ ਕਰਦਾ ਹੈ।
  • Identity ਨੂੰ origin ਨਾਲ bind ਕਰੋ, user agent ਵਿੱਚ ਮੌਜੂਦ free-text name ਨਾਲ ਨਹੀਂ। ਜੋ identifier ਤੁਸੀਂ record ਕਰਦੇ ਹੋ ਉਹ directory origin ਹੈ।

ਕਦਮ 5: signature base ਮੁੜ ਬਣਾਓ

Signer ਨੇ raw request sign ਨਹੀਂ ਕੀਤੀ ਸੀ। ਉਸਨੇ ਇੱਕ canonical string sign ਕੀਤੀ ਸੀ ਜਿਸਨੂੰ signature base ਕਹਿੰਦੇ ਹਨ (RFC 9421, Section 2.5), ਜੋ covered components ਦੇ order ਵਿੱਚ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਫਿਰ @signature-params line ਜੋੜੀ ਜਾਂਦੀ ਹੈ। ਤੁਹਾਡਾ verifier ਉਸੇ request ਤੋਂ ਉਹੀ string ਮੁੜ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਉਸਨੂੰ ਮਿਲੀ ਸੀ।

ਉੱਪਰ ਦਿੱਤੇ example ਲਈ 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"

ਉਹ ਵੇਰਵੇ ਧਿਆਨ ਨਾਲ ਦੇਖੋ ਜੋ proxies ਦੇ ਪਿੱਛੇ verification ਨੂੰ ਤੋੜ ਦਿੰਦੇ ਹਨ:

  • @authority ਉਹ host ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸਨੂੰ client ਨੇ target ਕੀਤਾ ਸੀ। ਜੇ load balancer Host ਨੂੰ rewrite ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹ original value ਵਰਤੋ ਜੋ ਉਹ forward ਕਰਦਾ ਹੈ।
  • @path query string ਨੂੰ exclude ਕਰਦਾ ਹੈ। ਜੇ client ਨੇ @query cover ਕੀਤਾ ਸੀ, ਤਾਂ ਉਸਨੂੰ ਬਿਲਕੁਲ ਉਸੇ ਤਰ੍ਹਾਂ ਮੁੜ ਬਣਾਓ ਜਿਵੇਂ ਉਹ ਮਿਲਿਆ ਸੀ।
  • Header values ਨੂੰ specified ਤਰੀਕੇ ਨਾਲ canonicalize ਕੀਤਾ ਜਾਂਦਾ ਹੈ: trimmed, ਅਤੇ multiple values combined। ਇੱਕ ਚੰਗੀ library ਇਹ ਤੁਹਾਡੇ ਲਈ ਕਰਦੀ ਹੈ।

ਕਦਮ 6: signature verify ਕਰੋ

Base ਅਤੇ public key ਨਾਲ, verification ਇੱਕੋ call ਵਿੱਚ ਹੋ ਜਾਂਦੀ ਹੈ, RFC 9421, Section 3.2 ਦੇ steps ਅਨੁਸਾਰ। 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"));
}

ਜੇ ਜਾਂਚ fail ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ request verified ਨਹੀਂ ਹੈ। ਫਿਰ ਵੀ ਇਸਨੂੰ serve ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਸਨੂੰ ਸਿਰਫ "verified" basis ਨਹੀਂ ਮਿਲਦਾ।

ਕਦਮ 7: replay ਨੂੰ ਰੋਕੋ

ਇੱਕ ਵੈਧ signature ਨੂੰ ਉਸਦੀ ਮਿਆਦ ਖਤਮ ਹੋਣ ਤੱਕ capture ਕਰਕੇ ਦੁਬਾਰਾ ਭੇਜਿਆ ਜਾ ਸਕਦਾ ਹੈ। RFC 9421, Section 7.2.2 signature replay ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ, ਅਤੇ Web Bot Auth protocol draft ਆਪਣੇ nonce rules ਜੋੜਨ ਦੀ ਬਜਾਏ ਉਸੇ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਦੋ controls ਇਸ window ਦਾ ਜ਼ਿਆਦਾਤਰ ਹਿੱਸਾ ਬੰਦ ਕਰ ਦਿੰਦੀਆਂ ਹਨ:

  1. ਛੋਟੀ ਮਿਆਦ, ਜੋ Step 3 ਵਿੱਚ enforce ਕੀਤੀ ਜਾਂਦੀ ਹੈ।
  2. Nonce tracking. ਜਦੋਂ nonce ਮੌਜੂਦ ਹੋਵੇ, signature ਦੀ ਮਿਆਦ ਖਤਮ ਹੋਣ ਤੱਕ ਉਸਨੂੰ ਉਸਦੇ key identifier ਨਾਲ store ਕਰੋ, ਅਤੇ ਦੂਜੀ ਵਰਤੋਂ ਨੂੰ reject ਕਰੋ।
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;
}

ਇੱਕ multi-instance deployment ਵਿੱਚ, nonces ਨੂੰ Redis ਵਰਗੇ shared store ਵਿੱਚ ਰੱਖੋ, ਜਿਸਦੀ time to live ਬਾਕੀ ਰਹਿ ਗਈ validity ਦੇ ਬਰਾਬਰ ਹੋਵੇ।

ਕਦਮ 8: ਨਤੀਜੇ ਨੂੰ ਉਸਦੇ basis ਨਾਲ record ਕਰੋ

Verification evidence ਪੈਦਾ ਕਰਦੀ ਹੈ, verdict ਨਹੀਂ। ਇਸਨੂੰ ਉਸ ਰੂਪ ਵਿੱਚ record ਕਰੋ ਜੋ ਤੁਹਾਡੀ 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 fail ਹੋ ਜਾਵੇ ਜਾਂ ਚੱਲ ਹੀ ਨਾ ਸਕੇ, ਤਾਂ ਉਹ ਵੀ record ਕਰੋ, ਕਾਰਨ ਸਮੇਤ: 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 ਕਰੋ। Full signature bytes ਜਾਂ ਪੂਰੇ request bodies log ਨਾ ਕਰੋ। Logs ਨੂੰ ਇੰਨਾ ਲੰਮਾ ਰੱਖੋ ਕਿ patterns ਦੀ study ਹੋ ਸਕੇ, ਅਤੇ ਇੰਨਾ ਛੋਟਾ ਕਿ ਤੁਹਾਡੀਆਂ privacy commitments ਦਾ ਆਦਰ ਰਹੇ।

ਇੱਕ verified signature ਤੁਹਾਡੀ policy ਨੂੰ ਕਿਵੇਂ ਬਦਲਨੀ ਚਾਹੀਦੀ ਹੈ?

ਜਦੋਂ requests verify ਹੋ ਸਕਦੀਆਂ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਮਾਇਨੇਦਾਰ ਢੰਗ ਨਾਲ ਵੱਖਰਾ treat ਕਰ ਸਕਦੇ ਹੋ। ਸਾਡਾ post designing app policies for humans and AI agents ਵੱਡੇ policy model ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ:

  • Verified operators ਨੂੰ read-only routes ਉੱਤੇ unverified automation ਨਾਲੋਂ ਵੱਧ rate limit ਦੇ ਨਾਲ allow ਕਰੋ।
  • ਉਨ੍ਹਾਂ ਨੂੰ structured responses ਦਿਓ, ਜਿਵੇਂ JSON ਜਾਂ Markdown, ਨਾ ਕਿ ਪੂਰੇ HTML pages।
  • High-impact actions ਨੂੰ ਆਪਣੀ normal authorization ਦੇ ਪਿੱਛੇ ਰੱਖੋ। ਇੱਕ verified signature ਤੁਹਾਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਕਿਹੜਾ client call ਕਰ ਰਿਹਾ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ ਉਹ account ਬਦਲ ਸਕਦਾ ਹੈ।

Observation mode ਵਿੱਚ ਸ਼ੁਰੂ ਕਰੋ। ਕਿਸੇ ਵੀ policy ਦੇ ਇਸ ਉੱਤੇ ਨਿਰਭਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਮਾਪੋ ਕਿ ਤੁਹਾਡੇ automated traffic ਦਾ ਕਿੰਨਾ ਹਿੱਸਾ signed ਹੈ, ਕਿਹੜੇ operators ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ, ਅਤੇ verification ਕਿੰਨੀ ਵਾਰੀ fail ਹੁੰਦੀ ਹੈ।

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

Signature verification ਕਈ sources of evidence ਵਿੱਚੋਂ ਸਿਰਫ ਇੱਕ ਹੈ। Proof of Actor ਇਸਨੂੰ ਹੋਰ signals ਨਾਲ ਜੋੜਦਾ ਹੈ ਅਤੇ ਹਰ result ਉੱਤੇ basis visible ਰੱਖਦਾ ਹੈ, ਤਾਂ ਜੋ ਇੱਕ verified agent ਕਦੇ ਵੀ ਉਸ ਨਾਲ ਗਲਤਫਹਮੀ ਵਿੱਚ ਨਾ ਪਵੇ ਜੋ ਸਿਰਫ ਆਪਣੇ ਆਪ ਨੂੰ declared ਕਰਦਾ ਹੈ। ਤੁਹਾਡੀ application ਫੈਸਲਾ ਕਰਦੀ ਹੈ ਕਿ ਅਗਲਾ ਕਦਮ ਕੀ ਹੋਵੇਗਾ।

ਇਸਨੂੰ ਸਾਡੇ engineers ਦੇ ਨਾਲ production app ਵਿੱਚ ਬਣਾਉਣ ਲਈ, early access ਲਈ apply ਕਰੋ. Evidence ਕੀ ਦਿਖਾ ਸਕਦੀ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ, ਇਸਦੀ ਪੂਰੀ ਤਸਵੀਰ ਲਈ Detection & Limitations ਪੜ੍ਹੋ।

Sources

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

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

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

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