મુખ્ય સામગ્રી પર જાઓ
માર્ગદર્શિકા

સહી કરેલી AI એજન્ટ વિનંતીઓને કેવી રીતે ચકાસવી

Automated clientsમાંથી RFC 9421 signatures ચકાસવાની એક પ્રાયોગિક માર્ગદર્શિકા, માન્ય signature શું સાબિત કરે છે, અને તમારા logsમાં શું નોંધવું જોઈએ.

Toshendra Sharma

દ્વારા Toshendra Sharmaસ્થાપક અને CEO, AgentCredia · Updated November 13, 2026

ઉન્નત · 11 મિનિટ વાંચન

સહી કરેલી વિનંતી શું સાબિત કરે છે?

મોટાભાગનું automated traffic પોતાને user agent string વડે ઓળખાવે છે. એ string એક દાવો છે, અને તેનું નકલ કરવું કંઈ ખર્ચાળ નથી. સહી કરેલી વિનંતીઓ સ્થિતિ બદલે છે. જ્યારે automated client પોતાના HTTP requests ને private key સાથે sign કરે છે અને operator સાથે જોડાયેલી જગ્યાએ મેળ ખાતી public key પ્રકાશિત કરે છે, ત્યારે તમારો server ચકાસી શકે છે કે વિનંતી ખરેખર તે કી ધરાવનાર વ્યક્તિ દ્વારા બનાવવામાં આવી હતી.

આનું આધાર HTTP Message Signatures છે, જે RFC 9421 તરીકે પ્રકાશિત છે. IETF Web Bot Auth working group automated clients માટે પરંપરાઓ સાથે તેના પર આધારિત કામ કરે છે: 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 અને તેને સર્વ કરવા માટે એક well-known URI નિર્ધારિત કરે છે. બંનેને વિગતવાર સમજવું યોગ્ય છે, કારણ કે verification બહુ સૂક્ષ્મ રીતે ખોટી થઈ શકે છે.

મેકેનિક્સ પહેલાં, પરિણામ વિશે ચોક્કસ રહો. માન્ય signature બતાવે છે કે વિનંતી operator ના domain જેવી published identifier સાથે જોડાયેલી key દ્વારા sign થઈ હતી, અને request ના signed ભાગોમાં ફેરફાર થયો ન હતો. તે નથી બતાવતું કે agent ને કોણે સૂચના આપી, કોઈ વ્યક્તિએ તેને authority સોંપી કે નહીં, અથવા ક્રિયા સુરક્ષિત છે કે નહીં. identity evidence અને authorization અલગ પ્રશ્નો છે, અને તમારું application બીજા પ્રશ્નનો જવાબ આપે છે. અમારી blog post what signed AI agent requests prove ઉદાહરણો સાથે આ સીમા સમજાવે છે.

સંકળાયેલા headers

સહી કરેલી વિનંતી સામાન્ય રીતે ત્રણ headers ધરાવે છે:

  • Signature-Input (RFC 9421, Section 4.1) દરેક signature ને વર્ણવે છે: એક label, covered components ની યાદી, અને created, expires, keyid, alg, nonce અને tag જેવા parameters.
  • 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.

એક સરળ ઉદાહરણ:

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 કયો form અપેક્ષે છે તે તપાસો.

પગલું 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 ખોટા rejection અને વાસ્તવિક security gaps બંને બનાવે છે.

જાળવેલ structured-field parser નો ઉપયોગ કરો, અથવા વધુ સારું, જાળવેલ RFC 9421 library નો ઉપયોગ કરો જે parsing અને verification ને સાથે સંભાળે. Specification ને શૂન્યથી implement કરવું શીખવા માટે સારું exercise છે અને production માટે ખરાબ પસંદગી છે. નીચેના પગલાં બતાવે છે કે એવી library શું કરે છે, જેથી તમે તેને યોગ્ય રીતે configure કરી શકો અને તેનો output review કરી શકો.

પગલું 2: કયા signature ને evaluate કરવો તે પસંદ કરો

એક request માં એકથી વધુ signature labels હોઈ શકે છે. તમારી policy સાથે મેળ ખાતું label પસંદ કરો, ઉદાહરણ તરીકે તે 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 છે, અને તે header હાજર હોય ત્યારે signature-agent પણ. @authority વિના, એક site માટે captured signature બીજી સામે replay થઈ શકે છે. @path વિના, તેને endpoints across ફરીથી વાપરી શકાય છે. Web Bot Auth protocol draft agents ને @authority અથવા @target-uri cover કરવાનું કહે છે, અને ચેતવણી આપે છે કે authority ને જ cover કરતી signature તે host પર કોઈપણ method અથવા path સામે તેના expiry સુધી verify થશે.

પગલું 3: time parameters તપાસો

RFC 9421, Section 2.3 માં નિર્ધારિત time parameters created અને expires વાંચો. પછી:

  1. જે signatures નું created time નાની clock skew allowance કરતાં આગળ ભવિષ્યમાં છે તેને reject કરો.
  2. જે signaturesનું expires પસાર થઈ ગયું છે તેને reject કરો.
  3. જો expires ગાયબ હોય, તો createdના આધારે તમારી પોતાની maximum age લાગુ કરો.

નાની validity windows captured request ને replay કરી શકાય તેવી અવધિ મર્યાદિત કરે છે.

પગલું 4: કી શોધો

Signature-Agent header operator ની key directory તરફ સંકેત કરે છે. તેને HTTPS પર મેળવો, અને માત્ર HTTPS પર. Web Bot Auth protocol draft directory ને JSON Web Key Set તરીકે વર્ણવે છે (કી JWK format માં) જે તે origin પરના http-message-signatures-directory well-known URI પરથી સર્વ થાય છે. પછી તે 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;
}

કી શોધવા માટેના વ્યવહારુ નિયમો:

  • Keys cache કરો નિર્ધારિત lifetime સાથે, જેથી verification દરેક request પર network call ન ઉમેરે.
  • Short timeout મૂકો અને failed fetch ને હંમેશા "could not verify" તરીકે ગણાવો, ક્યારેય "verified" તરીકે નહીં.
  • જો શક્ય હોય તો કયા origins પરથી fetch કરવું તે મર્યાદિત કરો, અથવા ઓછામાં ઓછું private address ranges block કરો જેથી server-side request forgery ટાળી શકાય. protocol draft આ જ કારણસર તેની security considerations માં server-side request forgery નો ઉલ્લેખ કરે છે.
  • ઓળખને origin સાથે બાંધો, user agent ના મુક્ત લખાણ નામ સાથે નહીં. તમે જે identifier નોંધો છો તે directory origin છે.

પગલું 5: signature base ફરી બનાવો

Signer એ raw request પર sign કર્યું નહોતું. તેણે canonical string પર sign કર્યું હતું જેને signature base કહે છે (RFC 9421, Section 2.5), જે covered components ને ક્રમમાં ગોઠવીને, પછી @signature-params line સાથે બને છે. તમારો 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 કરે તે મૂળ value નો ઉપયોગ કરો.
  • @path query string ને બહાર રાખે છે. જો client એ @query cover કર્યું હોય, તો તેને મળ્યું તેમ જ ફરી બનાવો.
  • Header values ને નિર્ધારિત રીતે canonicalize કરવામાં આવે છે: trim કરીને, અને multiple values ને combine કરીને. સારું library આ તમારા માટે કરે છે.

પગલું 6: signature ચકાસો

Base અને public key સાથે, verification એક single call છે, RFC 9421, Section 3.2 ના પગલાં મુજબ. 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"));
}

જો check નિષ્ફળ જાય, તો request verified નથી. તેમ છતાં તેને serve કરી શકાય છે. માત્ર તેને "verified" basis મળતું નથી.

પગલું 7: replay અટકાવો

માન્ય signature ને તેની expiry સુધી capture કરીને ફરી મોકલી શકાય છે. RFC 9421, Section 7.2.2 signature replay આવરી લે છે, અને Web Bot Auth protocol draft તેના બદલે પોતાના nonce નિયમો ઉમેરવાને બદલે તેના પર આધાર રાખે છે. બે નિયંત્રણો તે window નો મોટાભાગ બંધ કરે છે:

  1. Short expiry, પગલું 3 માં enforced.
  2. Nonce tracking. જ્યારે nonce હાજર હોય, ત્યારે તેને તેની key identifier સાથે signature expire થાય ત્યાં સુધી shared 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;
}

ઘણા instances ધરાવતી deployment માં, nonces ને Redis જેવા shared store માં remaining validity જેટલી time to live સાથે રાખો.

પગલું 8: basis સાથે પરિણામ નોંધો

Verification evidence ઉત્પન્ન કરે છે, ચુકાદો નહીં. તેને એવી form માં 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 નિષ્ફળ જાય અથવા ચાલી ન શકે, ત્યારે કારણ સાથે તે પણ record કરો: missing headers, unsupported algorithm, key not found, expired, replayed, અથવા signature mismatch. આ કારણો મૂલ્યવાન છે. એક operator તરફથી "key not found" માં અચાનક વધારો ઘણીવાર બતાવે છે કે તેમણે keys rotate કરી છે, નહીં કે તેઓ તમને attack કરી રહ્યા છે.

Signature verification માંથી તમારે શું log કરવું જોઈએ?

Operator origin, key identifier, covered components, time parameters, outcome અને failure reason log કરો. સંપૂર્ણ signature bytes અથવા આખા request bodies log ન કરો. Logs ને એટલા લાંબા રાખો કે તમે patterns અધ્યયન કરી શકો, અને એટલા ટૂંકા કે તમારા privacy commitments નો માન રાખી શકાય.

Verified signature તમારી policy ને કેવી રીતે બદલે?

જ્યારે requests verify કરી શકાય, ત્યારે તમે તેમને અર્થપૂર્ણ રીતે અલગ રીતે treat કરી શકો છો. designing app policies for humans and AI agents પરનો અમારો post વિશાળ policy model આવરી લે છે:

  • Verified operators ને read-only routes પર unverified automation કરતાં વધુ rate limit સાથે allow કરો.
  • તેમને structured responses, જેમ કે JSON અથવા Markdown, સંપૂર્ણ HTML pages ને બદલે આપો.
  • ઉચ્ચ અસર ધરાવતી actions ને તમારી સામાન્ય authorization પાછળ રાખો. Verified signature તમને જણાવે છે કે કયો client calling છે, નહીં કે તે કોઈ account બદલી શકે છે.

Observation mode થી શરૂઆત કરો. તમારી automated traffic માંથી કેટલું signed છે, કયા operators દેખાય છે, અને verification કેટલી વાર નિષ્ફળ જાય છે તે માપો, તે પર કોઈ policy આધારિત થાય તે પહેલાં.

Proof of Actor ક્યાં ફિટ થાય છે

Signature verification evidence ના અનેક sources માંથી એક છે. Proof of Actor તેને અન્ય signals સાથે જોડે છે અને દરેક result પર basis visible રાખે છે, જેથી verified agent ક્યારેય માત્ર પોતાને declared કરનાર સાથે ગડમથલ ન થાય. આગળ શું થાય તે તમારું application નક્કી કરે છે.

આને અમારા engineers સાથે production app માં બનાવવું હોય, તો early access માટે અરજી કરો. Evidence શું બતાવી શકે છે અને શું નહીં, તેની સંપૂર્ણ છબી માટે Detection & Limitations વાંચો.

Sources

અમારી સાથે તેને બનાવો.

Proof of Actor founding developer program માં જોડાઓ.

પ્રારંભિક ઍક્સેસ મેળવોડેવલપર હબ

પહેલાં વાત કરવી પસંદ કરો છો? સ્થાપકો સાથે વાત કરો