முக்கிய உள்ளடக்கத்திற்கு தவிர்க்கவும்
வழிகாட்டி

கையொப்பமிடப்பட்ட AI agent கோரிக்கைகளை எவ்வாறு சரிபார்ப்பது

தானியங்கி clients-இருந்து வரும் RFC 9421 signatures-ஐ சரிபார்ப்பதற்கான நடைமுறை வழிகாட்டி, சரியான signature என்ன நிரூபிக்கிறது, மேலும் உங்கள் logs எதைப் பதிவு செய்ய வேண்டும் என்பதையும் விளக்குகிறது.

Toshendra Sharma

ஆசிரியர் Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

மேம்பட்டது · 11 நிமிட வாசிப்பு

கையொப்பமிடப்பட்ட request என்ன நிரூபிக்கிறது?

பெரும்பாலான தானியங்கி traffic தன்னை ஒரு user agent string மூலம் அடையாளப்படுத்துகிறது. அந்த string ஒரு கோரிக்கை மட்டுமே, அதனை நகலெடுக்க செலவு எதுவும் இல்லை. கையொப்பமிடப்பட்ட requests அந்த நிலையை மாற்றுகின்றன. ஒரு தானியங்கி client தனது HTTP requests-ஐ ஒரு private key-யுடன் sign செய்து, operator-க்கு இணைக்கப்பட்ட இடத்தில் பொருந்தும் public key-ஐ வெளியிடும் போது, அந்த key-ஐ வைத்திருக்கும் ஒருவர் உண்மையிலேயே request-ஐ உருவாக்கினார் என்பதை உங்கள் server சரிபார்க்க முடியும்.

இதற்குப் பின்னணியில் இருக்கும் standard என்பது HTTP Message Signatures, இது RFC 9421 ஆக வெளியிடப்பட்டுள்ளது. IETF Web Bot Auth working group தானியங்கி clients-க்கான மரபுகளை அதன் மேல் கட்டுகிறது: ஒரு agent தனது key directory-க்கு எவ்வாறு சுட்டிக்காட்ட வேண்டும், மற்றும் request components எவற்றை sign செய்ய வேண்டும் என்பவை. 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-க்கு முன், முடிவைத் தெளிவாகப் பாருங்கள். ஒரு valid signature, request ஒரு published identifier-க்கு தொடர்புடைய key-யால் sign செய்யப்பட்டது என்பதை காட்டுகிறது, உதாரணமாக operator-ன் domain, மேலும் request-ன் sign செய்யப்பட்ட பகுதிகள் மாற்றப்படவில்லை என்பதையும் காட்டுகிறது. அது agent-க்கு உத்தரவு கொடுத்தவர் யார், ஒரு person அதற்கு authority-யை ஒப்படைத்தாரா, அல்லது action பாதுகாப்பானதா என்பதைக் காட்டாது. identity evidence மற்றும் authorization என்பது தனித்தனி கேள்விகள், இரண்டாவது கேள்விக்கு பதில் உங்கள் application தருகிறது. signed AI agent requests என்ன நிரூபிக்கின்றன என்ற எங்கள் blog post இந்த எல்லையை எடுத்துக்காட்டுகளுடன் விளக்குகிறது.

பயன்படுத்தப்படும் headers

ஒரு கையொப்பமிடப்பட்ட request பொதுவாக மூன்று 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-ஐ structured field ஆக, base64 encode செய்யப்பட்ட நிலையில், கொண்டுள்ளது.
  • Signature-Agent (Web Bot Auth மரபுகளிலிருந்து) 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 itself 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-ஐ மாற்றியுள்ளது). அவற்றை string splitting மூலம் parse செய்ய வேண்டாம். Quoted strings, parameters மற்றும் inner lists அனைத்தும் துல்லியமான grammar-ஐ கொண்டுள்ளன, மேலும் அலட்சியமான parser false rejections மற்றும் உண்மையான security gaps இரண்டையும் உருவாக்கும்.

பராமரிக்கப்படும் structured-field parser-ஐ, அல்லது parsing மற்றும் verification இரண்டையும் ஒருங்கே கையாளும் பராமரிக்கப்படும் RFC 9421 library-ஐப் பயன்படுத்தவும். Specification-ஐ முற்றிலும் புதிதாக உருவாக்குவது கற்றலுக்கான நல்ல பயிற்சி, ஆனால் production-க்கு மோசமான தேர்வு. கீழேயுள்ள படிகள் அத்தகைய library என்ன செய்கிறது என்பதை விளக்குகின்றன, அதனால் அதை சரியாக configure செய்து அதன் output-ஐ மதிப்பாய்வு செய்யலாம்.

படி 2: எந்த signature-ஐ மதிப்பிட வேண்டும் என்பதைத் தேர்ந்தெடுக்கவும்

ஒரு request பல signature labels-ஐ கொண்டிருக்கலாம். உங்கள் policy-க்கு பொருந்துவதைத் தேர்ந்தெடுக்கவும், உதாரணமாக tag என்பது web-bot-auth ஆக இருக்கும் label. இவற்றில் ஏதேனும் ஒன்று இருந்தால் verification நோக்கில் request-ஐ reject செய்யவும், serving நோக்கில் அல்ல:

  • உங்களுக்குத் தேவையான parameters எதுவும் signature-ல் இல்லையெனில்,
  • algorithm உங்கள் allowlist-இல் இல்லையெனில் (உதாரணமாக ed25519), அல்லது
  • covered components நீங்கள் தேவைப்படுத்தும் குறைந்தபட்ச தொகுப்பை உள்ளடக்கவில்லை என்றால்.

தானியங்கி clients-க்கான நியாயமான குறைந்தபட்சம் @method, @authority மற்றும் @path, மேலும் அந்த header இருந்தால் signature-agent. @authority இல்லையெனில், ஒரு site-க்கு பிடிக்கப்பட்ட signature மற்றொரு site-க்கு மீண்டும் பயன்படுத்தப்படலாம். @path இல்லையெனில், அது endpoints across பயன்படுத்தப்படலாம். Web Bot Auth protocol draft agents-க்கு @authority அல்லது @target-uri-ஐ cover செய்ய வேண்டும் என்று கோருகிறது, மேலும் authority-ஐ மட்டும் cover செய்த signature expiry வரை அந்த host-இல் எந்த method அல்லது path மீதும் verify ஆகும் என்று எச்சரிக்கிறது.

படி 3: நேர parameters-ஐச் சரிபார்க்கவும்

RFC 9421, Section 2.3-இல் வரையறுக்கப்பட்ட created மற்றும் expires எனும் time parameters-ஐப் படிக்கவும். பின்னர்:

  1. created நேரம் சிறிய clock skew அனுமதியை விட எதிர்காலத்தில் இருந்தால் அந்த signatures-ஐ reject செய்யவும்.
  2. expires கடந்த signatures-ஐ reject செய்யவும்.
  3. expires இல்லையெனில், created அடிப்படையில் உங்கள் சொந்த maximum age-ஐ enforce செய்யவும்.

சுருக்கமான validity windows பிடிக்கப்பட்ட request எவ்வளவு நேரம் replay செய்ய முடியும் என்பதை கட்டுப்படுத்துகின்றன.

படி 4: key-ஐ கண்டறியவும்

Signature-Agent header operator-ன் key directory-யை சுட்டிக்காட்டுகிறது. அதை HTTPS வழியாக மட்டுமே பெறவும். Web Bot Auth protocol draft அந்த directory-ஐ JSON Web Key Set ஆக விவரிக்கிறது, அதாவது JWK format-இல் உள்ள keys, http-message-signatures-directory well-known URI-இல் அந்த origin-இல் 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-க்கான நடைமுறை விதிகள்:

  • Keys-ஐ cache செய்யவும் - bounded lifetime உடன், verification ஒவ்வொரு request-க்கும் network call சேர்க்காதபடி.
  • Short timeout அமைக்கவும் மற்றும் failed fetch-ஐ "verified" என்று அல்ல, எப்போதும் "could not verify" என்று கருதவும்.
  • நீங்கள் fetch செய்யும் origins-ஐ கட்டுப்படுத்தவும் முடிந்தால், அல்லது குறைந்தபட்சம் private address ranges-ஐ தடுக்கவும், server-side request forgery-ஐத் தவிர்க்க. Protocol draft அதன் security considerations-இல் இதே காரணத்தால் server-side request forgery-ஐ பட்டியலிடுகிறது.
  • Identity-யை origin-க்கு bind செய்யவும், user agent-இல் உள்ள free-text பெயருக்கு அல்ல. நீங்கள் பதிவு செய்யும் identifier என்பது directory origin ஆகும்.

படி 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-ஐ rewrite செய்தால், அது forward செய்யும் original value-ஐப் பயன்படுத்தவும்.
  • @path query string-ஐ விலக்குகிறது. Client @query-ஐ cover செய்திருந்தால், அதை பெற்றவாறே துல்லியமாக மறுகட்டமைக்கவும்.
  • Header values குறிப்பிட்ட விதப்படி canonicalize செய்யப்படுகின்றன: trim செய்யப்பட்டு, பல values ஒன்றாக சேர்க்கப்படுகின்றன. ஒரு நல்ல library இதை உங்களுக்காகச் செய்கிறது.

படி 6: signature-ஐ verify செய்யவும்

Base மற்றும் public key உடன், RFC 9421, Section 3.2-இல் உள்ள படிகளைப் பின்பற்றி verification ஒரு single 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"));
}

Check fail ஆனால், request verified அல்ல. அது இன்னும் serve செய்யப்படலாம். அது simply "verified" basis-ஐப் பெறாது.

படி 7: replay-ஐத் தடுக்கவும்

ஒரு valid signature capture செய்யப்பட்டு expiry வரை மீண்டும் அனுப்பப்படலாம். RFC 9421, Section 7.2.2 signature replay-ஐக் கையாளுகிறது, மேலும் Web Bot Auth protocol draft அதற்குத் தன் சொந்த nonce விதிகளைச் சேர்க்காமல் அதைத் தொடர்கிறது. அந்த window-இன் பெரும்பகுதியை மூடும் இரண்டு controls:

  1. Short expiry, படி 3-இல் enforce செய்யப்பட்டது.
  2. Nonce tracking. ஒரு nonce இருந்தால், signature expire ஆகும் வரை அதை அதன் key identifier உடன் 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-இல், remaining validity-க்கு சமமான time to live உடன் Redis போன்ற shared store-இல் nonces-ஐ வைத்திருக்கவும்.

படி 8: முடிவை அதன் basis-உடன் பதிவு செய்யவும்

Verification evidence-ஐ உருவாக்குகிறது, verdict-ஐ அல்ல. உங்கள் 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 ஆனால் அல்லது இயங்க முடியாவிட்டால், அதையும் காரணத்துடன் பதிவு செய்யவும்: 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-ஐ மதிக்கும் அளவுக்கு logs-ஐ குறுகிய காலம் மட்டும் அல்லாமல், நடைமுறைகளை ஆய்வு செய்யும் அளவுக்கு நீண்ட காலமும் வைத்திருங்கள்.

ஒரு verified signature உங்கள் policy-யை எவ்வாறு மாற்ற வேண்டும்?

Requests verify செய்யக்கூடியதாக ஆன பிறகு, அவற்றை அர்த்தமுள்ள வகையில் வேறுபட்ட முறையில் கையாளலாம். மனிதர்களும் AI agents-மும் பற்றிய app policies-ஐ வடிவமைப்பது குறித்த எங்கள் post பரந்த policy model-ஐ உள்ளடக்குகிறது:

  • Verified operators-ஐ read-only routes-க்கு, unverified automation-ஐ விட உயர்ந்த rate limit உடன் அனுமதிக்கவும்.
  • முழு HTML pages-க்கு பதிலாக JSON அல்லது Markdown போன்ற structured responses-ஐ வழங்கவும்.
  • உயர் தாக்கம் உள்ள actions-ஐ உங்கள் சாதாரண authorization-க்கு பின்னால் வைத்திருங்கள். ஒரு verified signature உங்களுக்கு எந்த client call செய்கிறது என்பதைச் சொல்கிறது, அது ஒரு account-ஐ மாற்றலாம் என்று அல்ல.

Observation mode-இல் தொடங்கவும். எந்த policy-க்கும் சார்பாக இருக்குமுன், உங்கள் automated traffic-இல் எவ்வளவு பகுதி sign செய்யப்பட்டுள்ளது, எந்த operators தோன்றுகின்றனர், மற்றும் verification எவ்வளவு அடிக்கடி தோல்வியடைகிறது என்பதை அளவிடவும்.

Proof of Actor எங்கு பொருந்துகிறது

Signature verification என்பது பல evidence sources-இல் ஒன்றே. Proof of Actor அதை மற்ற signals-உடன் இணைத்து, ஒவ்வொரு result-இலும் basis-ஐ தெளிவாகக் காட்டுகிறது, இதனால் ஒரு verified agent-ஐ, தன்னை மட்டும் declared செய்த ஒன்றாக தவறாகக் கருத முடியாது. அடுத்து என்ன நடக்க வேண்டும் என்பதை உங்கள் application தீர்மானிக்கிறது.

எங்கள் engineers-உடன் production app-இல் இதை உருவாக்க, early access-க்கு விண்ணப்பிக்கவும். evidence என்ன காட்ட முடியும், என்ன காட்ட முடியாது என்பதற்கான முழு பார்வைக்காக, Detection & Limitations-ஐப் படிக்கவும்.

மூலங்கள்

அதை எங்களுடன் உருவாக்குங்கள்.

Proof of Actor founding developer program-இல் சேருங்கள்.

முன்கூட்டிய அணுகலைப் பெறுகடெவலப்பர் மையம்

முதலில் பேச விரும்புகிறீர்களா? founders-உடன் பேசுங்கள்