मार्गदर्शक

स्वाक्षरी केलेल्या AI एजंट विनंत्या कशा पडताळायच्या

स्वयंचलित clients कडील RFC 9421 signatures पडताळण्याचा एक व्यावहारिक walkthrough, वैध signature काय सिद्ध करते, आणि तुमच्या logs मध्ये काय capture करावे.

लेखक Toshendra Sharmaसंस्थापक आणि CEO, AgentCredia · Updated November 13, 2026

प्रगत · 11 min read

स्वाक्षरी केलेली request काय सिद्ध करते?

बहुतेक स्वयंचलित traffic स्वतःची ओळख user agent string ने देतो. ती string एक दावा असते, आणि तिची नक्कल करणे काहीच खर्चिक नसते. स्वाक्षरी केलेल्या requests हे चित्र बदलतात. जेव्हा एखादा स्वयंचलित client त्याच्या HTTP requests एका private key ने sign करतो आणि operator शी जोडलेल्या ठिकाणी जुळणारी public key प्रकाशित करतो, तेव्हा तुमचा server तपासू शकतो की request प्रत्यक्षात त्या key धारकानेच तयार केली होती.

यामागील standard म्हणजे HTTP Message Signatures, जे RFC 9421 म्हणून प्रकाशित आहे. IETF Web Bot Auth working group स्वयंचलित 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 परिभाषित करते. दोन्ही सविस्तर समजून घेणे उपयुक्त आहे, कारण verification मध्ये सूक्ष्म चुका सहज होऊ शकतात.

mechanics आधी, result बद्दल अचूक रहा. वैध signature दाखवते की request एका प्रकाशित identifier शी संबंधित key ने signed आहे, उदाहरणार्थ operator चा domain, आणि request चे signed भाग बदललेले नाहीत. ते agent ला कोणी निर्देश दिले, एखाद्या व्यक्तीने त्याला authority दिली का, किंवा ती कृती सुरक्षित आहे का हे दाखवत नाही. identity evidence आणि authorization हे वेगवेगळे प्रश्न आहेत, आणि तुमचे application दुसऱ्याचे उत्तर देते. स्वाक्षरी केलेल्या AI agent requests काय सिद्ध करतात या आमच्या blog post मध्ये उदाहरणांसह ही सीमा समजावून सांगितली आहे.

Step 1: structured fields योग्यरीत्या parse करा

Signature-Input आणि Signature हे HTTP Structured Fields (RFC 9651, जे RFC 8941 ला obsolete करते) आहेत. त्यांना string splitting ने parse करू नका. Quoted strings, parameters आणि inner lists यांचे grammar अचूक असते, आणि निष्काळजी parser मुळे खोटे rejection आणि खरे security gaps दोन्ही निर्माण होतात.

देखभाल केलेला structured-field parser वापरा, किंवा अधिक चांगले म्हणजे parsing आणि verification एकत्र हाताळणारी maintained RFC 9421 library वापरा. specification शून्यातून implement करणे हे शिकण्यासाठी चांगले व्यायाम आहे, पण production साठी कमकुवत निवड आहे. खालील steps अशा library काय करते ते सांगतात, जेणेकरून तुम्ही ती योग्यरीत्या configure करू शकाल आणि तिचा output तपासू शकाल.

Step 2: कोणती signature evaluate करायची ते निवडा

एका request मध्ये एकापेक्षा अधिक signature label असू शकतात. तुमच्या policy शी जुळणारी निवडा, उदाहरणार्थ तो label ज्याचा tag web-bot-auth आहे. खालीलपैकी काही असल्यास verification purposes साठी request reject करा (serving purposes साठी नाही):

आवश्यक parameters असलेली कोणतीही signature नसणे,
algorithm तुमच्या allowlist वर नसणे (उदाहरणार्थ ed25519), किंवा
covered components मध्ये तुमच्या आवश्यक minimum set चा समावेश नसणे.

स्वयंचलित clients साठी वाजवी minimum म्हणजे @method, @authority आणि @path, तसेच तो header उपस्थित असल्यास signature-agent. @authority शिवाय, एका site साठी capture केलेली signature दुसऱ्या site विरुद्ध replay केली जाऊ शकते. @path शिवाय, ती endpoints मध्ये पुन्हा वापरली जाऊ शकते. Web Bot Auth protocol draft agents ना @authority किंवा @target-uri cover करणे आवश्यक ठरवतो, आणि इशारा देतो की फक्त authority cover करणारी signature expiry होईपर्यंत त्या host वरील कोणत्याही method किंवा path विरुद्ध verify होते.

Step 3: वेळेचे parameters तपासा

RFC 9421, Section 2.3 मध्ये defined केलेले created आणि expires हे time parameters वाचा. मग:

ज्यांचा created time छोट्या clock skew allowance पेक्षा पुढे future मध्ये आहे अशा signatures reject करा.
ज्यांची expires संपली आहे अशा signatures reject करा.
जर expires missing असेल, तर created वर आधारित तुमचा स्वतःचा maximum age लागू करा.

लहान validity windows मुळे पकडलेली request किती काळ replay होऊ शकते हे मर्यादित होते.

Step 4: key शोधा

Signature-Agent header operator च्या key directory कडे निर्देश करतो. ते HTTPS वरून मिळवा, आणि फक्त HTTPS वरूनच. Web Bot Auth protocol draft directory चे वर्णन JSON Web Key Set म्हणून करतो (JWK(https://www.rfc-editor.org/rfc/rfc7517) format मधील keys) जे त्या origin वरील http-message-signatures-directory well-known URI वरून serve केले जाते. मग keyid parameter शी जुळणारी identifier असलेली key शोधा.

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 ठेवा आणि अपयशी fetch ला "could not verify" असे माना, कधीही "verified" नाही.
शक्य असल्यास ज्या origins वरून fetch करता त्यावर मर्यादा ठेवा, किंवा किमान private address ranges block करा जेणेकरून server-side request forgery टाळता येईल. protocol draft ने या security विचारांमध्ये server-side request forgery चा उल्लेख याच कारणासाठी केला आहे.
identity ला origin शी बांधा, user agent मधील मुक्त-शब्द नावाशी नाही. तुम्ही नोंदवणारा identifier म्हणजे directory origin आहे.

Step 5: signature base पुन्हा तयार करा

Signer ने raw request sign केलेली नाही. त्याने signature base नावाची canonical string sign केली आहे (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"

Proxies मागे verification मोडणाऱ्या तपशीलांकडे लक्ष द्या:

@authority हा client ने लक्ष्य केलेला host असला पाहिजे. जर load balancer Host पुन्हा लिहित असेल, तर तो पुढे पाठवत असलेले मूळ value वापरा.
@path query string वगळते. जर client ने @query cover केले असेल, तर ते जसे प्राप्त झाले तसेच पुन्हा तयार करा.
Header values चे canonicalization specification प्रमाणे केले जाते: trimmed, आणि multiple values एकत्र केलेले. चांगली library हे तुमच्यासाठी करते.

Step 6: signature verify करा

Base आणि public key सह, verification ही एकच call असते, RFC 9421, Section 3.2 मधील steps नुसार. Node.js मध्ये Ed25519 साठी, अंतर्भूत crypto module वापरून:

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

तपासणी अयशस्वी झाल्यास, request verified नाही. ती तरीही serve केली जाऊ शकते. तिला फक्त "verified" basis मिळत नाही.

Step 7: replay रोखा

वैध signature capture करून ती expiry होईपर्यंत पुन्हा पाठवली जाऊ शकते. RFC 9421, Section 7.2.2 replay हाताळते, आणि Web Bot Auth protocol draft स्वतःचे nonce नियम जोडण्याऐवजी त्याच्यावर अवलंबून राहतो. खालील दोन controls त्या window चा बहुतांश भाग बंद करतात:

Short expiry, Step 3 मध्ये enforce केलेले.
Nonce tracking. जेव्हा nonce उपस्थित असते, तेव्हा signature expire होईपर्यंत ते त्याच्या key identifier सह store करा, आणि दुसऱ्या वापराला नकार द्या.

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 मध्ये, उरलेल्या validity इतका time to live असलेला Redis सारखा shared store वापरून nonces ठेवा.

Step 8: basis सह result record करा

Verification evidence निर्माण करते, verdict नाही. ते अशा स्वरूपात record करा जे तुमचे analytics आणि policies वापरू शकतील:

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 केल्या आहेत याचे लक्षण असते, तो तुमच्यावर हल्ला करतो आहे याचे नाही.

Signature verification मधून काय log करावे?

Operator origin, key identifier, covered components, time parameters, outcome आणि failure reason log करा. Full signature bytes किंवा संपूर्ण request bodies log करू नका. तुमच्या privacy commitments चा आदर राखण्यासाठी logs पुरेसे दीर्घ, पण त्यांचा अभ्यास करण्यासाठी पुरेसे लहान ठेवा.

Verified signature ने तुमची policy कशी बदलावी?

एकदा requests verify करता आल्या की, तुम्ही त्यांना अर्थपूर्ण रीतीने वेगळे हाताळू शकता. मानव आणि AI agents साठी app policies डिझाइन करणे या आमच्या post मध्ये व्यापक policy model दिला आहे:

Unverified automation पेक्षा जास्त rate limit सह verified operators ना read-only routes वर allow करा.
पूर्ण HTML pages ऐवजी त्यांना JSON किंवा Markdown सारखी structured responses द्या.
High-impact actions तुमच्या सामान्य authorization मागेच ठेवा. Verified signature तुम्हाला कोणता client call करत आहे ते सांगते, पण तो खाते बदलू शकतो असे सांगत नाही.

Observation mode मध्ये सुरुवात करा. तुमच्या किती automated traffic ला signature आहे, कोणते operators दिसतात, आणि verification किती वेळा अयशस्वी होते ते मोजा, त्यावर कोणतीही policy अवलंबून ठेवण्याआधी.

Proof of Actor कुठे बसते

Signature verification हा अनेक evidence sources पैकी एक आहे. Proof of Actor ते इतर signals सोबत एकत्र करते आणि प्रत्येक result वर basis visible ठेवते, त्यामुळे verified agent आणि फक्त स्वतःला घोषित करणारा agent यांचा गोंधळ होत नाही. पुढे काय घडेल ते तुमचे application ठरवते.

हे production app मध्ये आमच्या engineers सोबत तयार करण्यासाठी, early access साठी अर्ज करा. Evidence काय दाखवू शकते आणि काय दाखवू शकत नाही याचे संपूर्ण चित्र पाहण्यासाठी, Detection & Limitations वाचा.

Sources

RFC 9421: HTTP Message Signatures: signature parameters, signature base आणि replay considerations यांसह signing आणि verification standard
RFC 9651: Structured Field Values for HTTP: Signature-Input आणि Signature यांनी वापरले जाणारे grammar
IETF Web Bot Auth working group: automated client authentication work चे charter आणि status
draft-ietf-webbotauth-httpsig-protocol: Signature-Agent, JWKS key directory आणि त्याचा well-known URI define करणारा Internet-Draft (November 2026 पर्यंत work in progress)
RFC 7517: JSON Web Key (JWK): published key directories मध्ये वापरले जाणारे key format
RFC 8615: Well-Known URIs: key directory सारखे well-known paths कसे register केले जातात
RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA): उदाहरणात वापरलेला Ed25519 algorithm
Node.js crypto documentation: Step 6 मध्ये वापरलेले createPublicKey आणि verify

ते आमच्यासोबत तयार करा.

Proof of Actor founding developer program मध्ये सामील व्हा.

लवकर प्रवेश मिळवा विकसक केंद्र

आधी बोलणे पसंत आहे? founders शी बोला