মুখ্য সামগ্ৰীৰ পৰা এৰাই চাওক
নিৰ্দেশিকা

স্বাক্ষরিত AI agent অনুরোধ কেনভাবে যাচাই কৰিব

স্বয়ংক্রিয় client ৰ পৰা RFC 9421 signature যাচাই কৰাৰ এটা ব্যৱহাৰিক walkthrough, বৈধ signature এ কি প্ৰমাণ কৰে, আৰু আপোনাৰ লগত কি ৰেকৰ্ড থাকিব লাগে.

Toshendra Sharma

দ্বাৰা Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

উন্নত · 11 min read

স্বাক্ষৰিত request এ কি প্ৰমাণ কৰে?

বেছি ভাগ স্বয়ংক্রিয় traffic এ নিজকে user agent string ৰে চিনাক্ত কৰে। সেই string এটা দাবী, আৰু সেটি কপি কৰাৰ খৰচ একেবাৰেই নহয়। স্বাক্ষৰিত request এ এই ছবি সলনি কৰে। যেতিয়া এটা স্বয়ংক্রিয় client এ private key ব্যৱহাৰ কৰি নিজৰ HTTP request স্বাক্ষৰ কৰে আৰু operator-সংযুক্ত এটা স্থলত মিলা public key প্ৰকাশ কৰে, তেতিয়া আপোনাৰ server এ যাচাই কৰিব পাৰে যে request টো সঁচাকৈয়ে সেই key ধৰি থকা কোনোবাই উৎপন্ন কৰিছিল।

এই standard টো হৈছে HTTP Message Signatures, যাক RFC 9421 হিচাপে প্ৰকাশ কৰা হৈছে। IETF Web Bot Auth working group এ automated client ৰ বাবে conventions লৈ ইয়াৰ ওপৰত কাম কৰে: এটা agent এ কেনেকৈ নিজৰ key directory ত আঙুলিয়ায় আৰু request ৰ কোন অংশ স্বাক্ষৰ কৰিব লাগে। November 2026 অনুসৰি, working group ৰ protocol document হৈছে draft-ietf-webbotauth-httpsig-protocol, যিয়ে Signature-Agent header, JSON Web Key Sets ভিত্তিক key directory format, আৰু সেইটো serve কৰাৰ বাবে এটা well-known URI সংজ্ঞায়িত কৰে। এই দুয়োটা খুঁটি বুজি ল’বলগীয়া, কিয়নো verification সূক্ষ্মভাৱে ভুল হ’ব পাৰে।

mechanics ৰ আগতে, ফলাফলটো স্পষ্টকৈ কওক। এটা বৈধ signature এ দেখুৱায় যে request টো প্ৰকাশিত identifier ৰ সৈতে সংযুক্ত এটা key, যেনে operator ৰ domain, ৰে স্বাক্ষৰিত হৈছিল, আৰু request ৰ স্বাক্ষৰিত অংশসমূহ সলনি কৰা হোৱা নাছিল। ই এয়া দেখুৱাই নে agent ক কোনে নিৰ্দেশ দিলে, এজন ব্যক্তিয়ে ইয়াক ক্ষমতা হস্তান্তৰ কৰিছিল নে নাই, বা action টো সুৰক্ষিত নে নহয়। identity evidence আৰু authorization পৃথক প্ৰশ্ন, আৰু আপোনাৰ application এ দ্বিতীয়টো প্রশ্নৰ উত্তৰ দিয়ে। স্বাক্ষৰিত AI agent request এ কি প্ৰমাণ কৰে সম্পৰ্কে আমাৰ blog post এ উদাহৰণসহ সেই সীমা ব্যাখ্যা কৰে।

জড়িত header সমূহ

এটা স্বাক্ষৰিত request ত সাধাৰণতে তিনিটা header থাকে:

  • Signature-Input (RFC 9421, Section 4.1) এ প্ৰতিটো signature বৰ্ণনা কৰে: এটা label, covered component ৰ তালিকা, আৰু created, expires, keyid, alg, nonce আৰু tag যেনে parameter সমূহ।
  • Signature (RFC 9421, Section 4.2) এ প্ৰতিটো label ৰ বাবে signature byte ৰখে, base64 encoded, এটা structured field হিচাপে।
  • Signature-Agent (Web Bot Auth convention ৰ পৰা) client ৰ public key ক’ত প্ৰকাশিত হৈছে তাৰ ঠিকনা দেখুৱায়, সাধাৰণতে 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 এ কোন format আশা কৰে সেয়া পৰীক্ষা কৰক।

পদক্ষেপ 1: structured field সঠিকভাৱে parse কৰক

Signature-Input আৰু Signature হৈছে HTTP Structured Fields (RFC 9651, যিয়ে RFC 8941 কে অবলুপ্ত কৰিছে)। এইবোৰক string splitting কৰি parse নকৰিব। Quoted string, parameter আৰু inner list সকলোৰে সুনিৰ্দিষ্ট grammar আছে, আৰু অযত্ন parser এ মিছা rejection আৰু বাস্তৱ security gap দুয়োটাই সৃষ্টি কৰে।

একটা maintained structured-field parser ব্যৱহাৰ কৰক, বা তাতকৈ উত্তম, parsing আৰু verification একেলগে সামৰা এটা maintained RFC 9421 library ব্যৱহাৰ কৰক। specification টো scratch ৰ পৰা ৰূপায়ণ কৰা ভাল learning exercise, কিন্তু production ৰ বাবে বেয়া পছন্দ। তলৰ পদক্ষেপসমূহে এনে library এ কি কৰে সেয়া বৰ্ণনা কৰে, যাতে আপুনি ইয়াক সঠিকভাৱে configure কৰি ইয়াৰ output পৰ্যালোচনা কৰিব পাৰে।

পদক্ষেপ 2: কোন signature মূল্যায়ন কৰিব সেয়া বাছক

এটা request ত এটা তকৈ অধিক signature label থাকিব পাৰে। আপোনাৰ policy ৰ সৈতে মিলা label বাছক, উদাহৰণস্বৰূপ যাৰ tag হৈছে web-bot-auth। যদি তলৰ যিকোনো এটা হয়, verification purpose ৰ বাবে request টি reject কৰক (serving purpose ৰ বাবে নহয়):

  • আপোনাৰ প্ৰয়োজনীয় parameter থকা কোনো signature নাই,
  • algorithm আপোনাৰ allowlist ত নাই (উদাহৰণস্বৰূপ ed25519), অথবা
  • covered component সমূহত আপোনাৰ প্ৰয়োজনীয় ন্যূনতম set নাই।

স্বয়ংক্রিয় client ৰ বাবে যুক্তিসংগত ন্যূনতম set হৈছে @method, @authority আৰু @path, লগতে সেই header উপস্থিত থাকিলে signature-agent। @authority নাথাকিলে, এটা site ৰ বাবে ধৰা signature আন এটা site ৰ বিৰুদ্ধে replay কৰিব পাৰি। @path নাথাকিলে, ইয়াক endpoint জুৰি পুনৰ ব্যৱহাৰ কৰিব পাৰি। Web Bot Auth protocol draft এ agent ক @authority বা @target-uri cover কৰিবলৈ বাধ্য কৰে, আৰু সতৰ্ক কৰে যে কেৱল authority cover কৰা signature এ expire নোহোৱা পৰ্যন্ত সেই host ৰ যিকোনো method বা path ৰ বিৰুদ্ধে verify হয়।

পদক্ষেপ 3: time parameter পৰীক্ষা কৰক

RFC 9421, Section 2.3 ত সংজ্ঞায়িত created আৰু expires, time parameter দুখন পঢ়ক। তাৰ পাছত:

  1. যি signature ৰ created সময় সামান্য clock skew allowance অতিক্ৰম কৰি ভৱিষ্যতে আছে সেয়া reject কৰক।
  2. যি signature এ expires অতিক্ৰম কৰিছে সেয়া reject কৰক।
  3. যদি expires নাই, তেন্তে created ৰ ওপৰত ভিত্তি কৰি নিজৰ maximum age বলবৎ কৰক।

ছোট validity window এ captured request replay কৰাৰ সময় সীমিত কৰে।

পদক্ষেপ 4: key বিচাৰি উলিয়াওক

Signature-Agent header এ operator ৰ key directory ক দেখুৱায়। সেইটো HTTPS ৰে আনক, আৰু কেৱল HTTPS ৰে। Web Bot Auth protocol draft এ এই directory ক JSON Web Key Set হিচাপে বৰ্ণনা কৰে (JWK format ত থকা key), যি সেই origin ৰ http-message-signatures-directory well-known URI ৰ পৰা serve কৰা হয়। তাৰ পাছত 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 ৰ ব্যৱহাৰিক নিয়ম:

  • key cache কৰক bounded lifetime সহ, যাতে verification এ প্ৰতিটো request ত network call যোগ নকৰে।
  • timeout চুটি ৰাখক আৰু failed fetch ক "could not verify" হিচাপে গণ্য কৰক, কেতিয়াও "verified" হিচাপে নহয়।
  • আপুনি যদি পাৰে তেন্তে কোন origin ৰ পৰা আনিব সেয়া সীমিত কৰক, বা অন্তত private address range block কৰক যাতে server-side request forgery ৰোধ হয়। Protocol draft এ ঠিক এই কাৰণতেই security consideration ত server-side request forgery উল্লেখ কৰিছে।
  • identity ক origin ৰ সৈতে bind কৰক, user agent ৰ মুক্ত-লিখিত নামৰ সৈতে নহয়। আপুনি record কৰা identifier হৈছে directory origin।

পদক্ষেপ 5: signature base পুনৰ্গঠন কৰক

Signer এ raw request স্বাক্ষৰ কৰা নাছিল। তেওঁ signature base নামেৰে এটা canonical string স্বাক্ষৰ কৰিছিল (RFC 9421, Section 2.5), যিটো covered component সমূহৰ ক্রম অনুসৰি, আৰু তাৰ পাছত @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 সেই host হব লাগিব যিটোক client এ লক্ষ্য কৰিছিল। যদি load balancer এ Host rewrite কৰে, তেন্তে ই আগবঢ়োৱা original value ব্যৱহাৰ কৰক।
  • @path এ query string বাদ দিয়ে। যদি client এ @query cover কৰিছিল, তেন্তে সেয়া পোৱা অনুসাৰে সঠিকভাৱে পুনৰ্গঠন কৰক।
  • header value সমূহ specified মতে canonicalize কৰা হয়: trimmed, আৰু একাধিক value একেলগে combine কৰা। ভাল 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"));
}

যদি পৰীক্ষা বিফল হয়, request টো verified নহয়। তাতো হয়তো serve কৰা যাব পাৰে। কেৱল "verified" basis নাপায়।

পদক্ষেপ 7: replay ৰোধ কৰক

এটা বৈধ signature ধৰা আৰু expires হোৱালৈকে পুনৰ পঠিয়াব পাৰি। RFC 9421, Section 7.2.2 এ signature replay সামৰে, আৰু Web Bot Auth protocol draft এ নিজস্ব nonce নিয়ম যোগ নকৰি সেইখিনিৰ ওপৰত নিৰ্ভৰ কৰে। দুটা নিয়ন্ত্ৰণে সেই window ৰ বেছি ভাগ বন্ধ কৰে:

  1. চুটি expiry, পদক্ষেপ 3 ত বলবৎ কৰা।
  2. nonce tracking. যেতিয়া nonce উপস্থিত থাকে, সেয়া এর key identifier সহ signature expired হওঁ নোপৰ্যন্ত এটা 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;
}

multi-instance deployment ত, remaining validity ৰ সমান time to live সহ Redis দৰে এটা shared store ত nonce ৰাখক।

পদক্ষেপ 8: ফলাফল basis সহ record কৰক

Verification এ evidence উৎপন্ন কৰে, verdict নহয়। সেইটো এনে format ত record কৰক যিটো আপোনাৰ analytics আৰু policy এ ব্যৱহাৰ কৰিব পাৰে:

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 নোপোৱা, expired, replayed, বা signature mismatch। এই কাৰণবোৰ মূল্যবান। কোনো operator ৰ পৰা "key not found" ৰ হঠাৎ বৃদ্ধি প্ৰায়েই বুজায় যে তেওঁলোকে key rotate কৰিছে, আপোনাক আক্রমণ কৰিছে বুলি নহয়।

signature verification ৰ পৰা কি লগ কৰিব লাগে?

operator origin, key identifier, covered component, time parameter, outcome আৰু failure reason লগ কৰক। সম্পূর্ণ signature byte বা সম্পূর্ণ request body লগ নকৰিব। pattern অধ্যয়নৰ বাবে যথেষ্ট সময়লৈ লগ ৰাখক, কিন্তু আপোনাৰ privacy প্ৰতিশ্ৰুতি মানি চলিব পৰাকৈ সিমিত সময়লৈ ৰাখক।

verified signature এ আপোনাৰ policy কেনেকৈ সলনি কৰিব?

এবাৰ request verify কৰিব পৰা হ’লে, আপুনি সিহঁতক অৰ্থপূৰ্ণভাৱে বেলেগ ধৰণে ব্যৱহাৰ কৰিব পাৰে। মানুহ আৰু AI agent ৰ বাবে app policy ডিজাইন কৰা সম্পৰ্কে আমাৰ post এ বহল policy model সামৰে:

  • unverified automation ৰ তুলনাত অধিক rate limit সহ verified operator ক read-only route ত অনুমতি দিয়ক।
  • পূৰ্ণ HTML page ৰ সলনি JSON বা Markdown দৰে structured response দিয়ক।
  • উচ্চ-প্ৰভাৱ action সমূহ আপোনাৰ সাধাৰণ authorization ৰ পাছতে ৰাখক। Verified signature এ কেৱল কোন client call কৰিছে সেয়া কয়, account সলনি কৰিবলৈ পাৰে বুলি নহয়।

Observation mode ত আৰম্ভ কৰক। কোনো policy এইটোত নিৰ্ভৰ কৰাৰ আগতে আপোনাৰ স্বয়ংক্রিয় traffic ৰ কিমান অংশ স্বাক্ষৰিত, কোন operator দেখা যায়, আৰু verification কিমানবাৰ বিফল হয় সেয়া জুখক।

Proof of Actor ক’ত খাপ খায়

Signature verification কেইবাটাও evidence উৎসৰ এটা। Proof of Actor এ ইয়াক আন signal সমূহৰ সৈতে একেলগ কৰে আৰু প্ৰতিটো result ত basis দৃশ্যমান ৰাখে, যাতে verified agent ক কেতিয়াও কেৱল নিজকে ঘোষণা কৰা agent ৰ সৈতে গুলীয়াই নথাকে। আপোনাৰ application এ তাৰ পাছত কি হ’ব সেয়া ঠিক কৰে।

আমাৰ engineer সমূহৰ সৈতে production app ত এইটো গঢ়িবলৈ, early access ৰ বাবে আবেদন কৰক। evidence এ কি দেখুৱাব পাৰে আৰু কি দেখুৱাব নোৱাৰে তাৰ সম্পূৰ্ণ চিত্ৰৰ বাবে, Detection & Limitations পঢ়ক।

উৎসসমূহ

আমাৰ সৈতে ইয়াক নিৰ্মাণ কৰক।

Proof of Actor founding developer program-ত যোগদান কৰক।

Early Access লওকডেভেলপাৰ হাব

আগতে কথা পাতিবলৈ পচন্দ কৰেনে? Founding team-ৰ সৈতে কথা পাতক