ప్రధాన కంటెంట్‌కు దాటవేయండి
GUIDE

సంతకం చేసిన AI agent అభ్యర్థనలను ఎలా ధృవీకరించాలి

ఆటోమేటెడ్ క్లయింట్ల నుండి వచ్చిన RFC 9421 signaturesను ధృవీకరించే ప్రాయోగిక walkthrough, చెల్లుబాటు అయ్యే signature ఏమి నిరూపిస్తుందో, మరియు మీ logsలో ఏమి capture చేయాలో వివరిస్తుంది.

Toshendra Sharma

రచన Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

అధునాతన · 11 నిమిషాల చదువు

సంతకం చేసిన అభ్యర్థన ఏమి నిరూపిస్తుంది?

చాలా ఆటోమేటెడ్ traffic ఒక user agent stringతో తనను తాను గుర్తిస్తుంది. ఆ string ఒక claim మాత్రమే, దాన్ని copy చేయడం ఖర్చు లేకుండా సాధ్యం. Signed 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 automated clients కోసం conventionsతో దీనిపై నిర్మిస్తుంది: ఒక agent తన key directoryను ఎలా సూచించాలి మరియు ఏ request componentsను sign చేయాలి. నవంబర్ 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 ఒక ప్రచురిత identifier, ఉదాహరణకు operator domain,తో అనుసంధానమైన key ద్వారా sign చేయబడిందని, మరియు requestలోని signed భాగాలు మార్పు చెందలేదని చూపిస్తుంది. అది agentకి ఎవరు సూచనలు ఇచ్చారో, ఒక వ్యక్తి దానికి అధికారం అప్పగించాడో, లేదా చర్య సురక్షితమో చూపించదు. Identity evidence మరియు authorization వేర్వేరు ప్రశ్నలు, మరియు మీ application రెండవదానికి సమాధానం ఇస్తుంది. మా blog post what signed AI agent requests prove ఉదాహరణలతో ఆ సరిహద్దును వివరంగా చూపిస్తుంది.

ఇందులో ఉన్న 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 encoded రూపంలో తీసుకెళుతుంది.
  • 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==:

ఈ example చదవడానికి సులభంగా ఉండేలా సరళీకరించబడింది. ప్రస్తుత working group draftలో, Signature-Agent itself signature label ద్వారా key చేయబడిన structured fieldగా ఉంటుంది, ఉదాహరణకు sig1="https://agent.example", కాబట్టి మీ verification library ఏ రూపాన్ని ఆశిస్తుందో తనిఖీ చేయండి.

దశ 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 వల్ల false rejections కూడా, నిజమైన security gaps కూడా వస్తాయి.

Maintained structured-field parserను, లేదా మరింత మంచిగా, parsing మరియు verificationను కలిపి నిర్వహించే maintained RFC 9421 libraryను వాడండి. Specificationను మొదటి నుండి implement చేయడం మంచి learning exercise, కానీ productionలో చెడు ఎంపిక. క్రింద ఉన్న దశలు అలాంటి library ఏమి చేస్తుందో వివరిస్తాయి, కాబట్టి దాన్ని సరిగా configure చేసి, దాని outputను review చేయవచ్చు.

దశ 2: ఏ signatureను evaluate చేయాలో ఎంచుకోండి

ఒక requestలో ఒకటి కంటే ఎక్కువ signature labels ఉండవచ్చు. మీ policyకి సరిపోయేదాన్ని ఎంచుకోండి, ఉదాహరణకు tag web-bot-authగా ఉన్న label. Verification purposes కోసం requestను reject చేయండి (serving purposes కోసం కాదు) ఎప్పుడు అంటే:

  • మీకు అవసరమైన parameters ఉన్న signature లేకపోతే,
  • algorithm మీ allowlistలో లేకపోతే, ఉదాహరణకు ed25519, లేదా
  • covered componentsలో మీకు కావలసిన minimum set లేకపోతే.

Automated clients కోసం sensible minimumగా @method, @authority మరియు @path, అలాగే ఆ header ఉన్నప్పుడు signature-agent కూడా సరిపోతాయి. @authority లేకపోతే, ఒక site కోసం captured చేసిన signatureను ఇంకొక siteపై replay చేయవచ్చు. @path లేకపోతే, దాన్ని endpoints across మళ్లీ ఉపయోగించవచ్చు. Web Bot Auth protocol draft agents @authority లేదా @target-uriను cover చేయాలని కోరుతుంది, మరియు authorityను మాత్రమే cover చేసిన signature, అది expire అయ్యే వరకు, ఆ hostపై ఏ method లేదా pathకైనా verify అవుతుందని హెచ్చరిస్తుంది.

దశ 3: time parametersను తనిఖీ చేయండి

RFC 9421, Section 2.3లో నిర్వచించిన time parameters అయిన created మరియు expiresను చదవండి. ఆపై:

  1. చిన్న clock skew allowanceను మించిన భవిష్యత్తు సమయంతో ఉన్న created కలిగిన signaturesను reject చేయండి.
  2. expires దాటిపోయిన signaturesను reject చేయండి.
  3. expires లేకపోతే, created ఆధారంగా మీ స్వంత maximum ageను అమలు చేయండి.

చిన్న validity windows captured చేసిన requestను ఎంతకాలం replay చేయవచ్చో పరిమితం చేస్తాయి.

దశ 4: keyను కనుగొనండి

Signature-Agent header operator యొక్క key directoryకి సూచిస్తుంది. దాన్ని HTTPS మీద మాత్రమే fetch చేయండి. Web Bot Auth protocol draft ఆ directoryని JSON Web Key Setగా వివరిస్తుంది (keys JWK formatలో), ఇది ఆ 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 కోసం ప్రాయోగిక నియమాలు:

  • Keysను cache చేయండి bounded lifetimeతో, verification ప్రతి requestకు network callను చేర్చకుండా ఉండేందుకు.
  • చిన్న timeoutను సెట్ చేయండి మరియు failed fetchను "could not verify"గా పరిగణించండి, ఎప్పుడూ "verified"గా కాదు.
  • సాధ్యమైతే మీరు fetch చేసే originsను పరిమితం చేయండి, లేదా కనీసం 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 అంటే 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 అదే stringను అందుకున్న request నుండి తిరిగి నిర్మిస్తుంది.

పై 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 client లక్ష్యంగా పెట్టిన host అయి ఉండాలి. ఒక load balancer Hostను rewrite చేస్తే, అది forward చేసే original valueను ఉపయోగించండి.
  • @path query stringను exclude చేస్తుంది. client @queryను cover చేసి ఉంటే, అది అందుకున్న విధంగానే exactగా తిరిగి నిర్మించండి.
  • Header valuesను పేర్కొన్న విధంగా canonicalize చేస్తారు: trim చేసి, multiple valuesను combine చేస్తారు. మంచి library ఇది మీకోసం చేస్తుంది.

దశ 6: signatureను verify చేయండి

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

Check fail అయితే, request verified కాదు. అది ఇంకా serve చేయబడవచ్చు. దానికి కేవలం "verified" basis లభించదు.

దశ 7: replayను నివారించండి

Valid signatureను అది expire అయ్యే వరకు capture చేసి మళ్లీ పంపవచ్చు. RFC 9421, Section 7.2.2 signature replayను కవర్ చేస్తుంది, మరియు Web Bot Auth protocol draft దానికి తన స్వంత nonce నియమాలను జోడించకుండా దానికే ఆధారం ఇస్తుంది. ఆ windowలో ఎక్కువ భాగాన్ని మూసే రెండు controls ఇవి:

  1. Short expiry, Step 3లో అమలు చేయాలి.
  2. Nonce tracking. ఒక nonce ఉన్నప్పుడు, signature expire అయ్యే వరకు దాన్ని దాని 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లో, మిగిలిన validityకి సమానమైన time to liveతో Redis వంటి shared storeలో noncesను ఉంచండి.

దశ 8: ఫలితాన్ని దాని basisతో record చేయండి

Verification evidenceను ఉత్పత్తి చేస్తుంది, verdictను కాదు. మీ analytics మరియు policies ఉపయోగించగల రూపంలో దాన్ని record చేయండి:

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 అయితే లేదా run చేయలేకపోతే, reasonతో కలిసి దానిని కూడా record చేయండి: missing headers, unsupported algorithm, key not found, expired, replayed, లేదా signature mismatch. ఈ reasons విలువైనవి. ఒక 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ను గౌరవించేంత చిన్నగా, patternలను అధ్యయనం చేయడానికి సరిపడా పెద్దగా logsను ఉంచండి.

Verified signature మీ policyని ఎలా మార్చాలి?

Requests verify చేయగలిగిన తర్వాత, మీరు వాటిని అర్థవంతమైన విధంగా భిన్నంగా పరిగణించవచ్చు. designing app policies for humans and AI agentsపై మా post, broader policy modelను కవర్ చేస్తుంది:

  • Unverified automationతో పోలిస్తే higher rate limitతో verified operatorsను read-only routesకి అనుమతించండి.
  • Full HTML pagesకు బదులుగా JSON లేదా Markdown వంటి structured responsesను వారికి అందించండి.
  • High-impact actionsను మీ సాధారణ authorization వెనుకే ఉంచండి. Verified signature ఏ client call చేస్తోందో చెబుతుంది, కానీ అది accountను మార్చవచ్చని చెప్పదు.

Observation modeలో ప్రారంభించండి. ఏ policy దీనిపై ఆధారపడే ముందు, మీ automated trafficలో ఎంత భాగం signedగా ఉంది, ఏ operators కనిపిస్తున్నారు, మరియు verification ఎంతసార్లు fail అవుతోంది అన్నది కొలవండి.

Proof of Actor ఎక్కడ సరిపోతుంది

Signature verification అనేది అనేక evidence sourcesలో ఒకటి. Proof of Actor దాన్ని ఇతర signalsతో కలిపి, ప్రతి resultపై basisను కనిపించేలా ఉంచుతుంది, కాబట్టి verified agentను కేవలం itselfను ప్రకటించినదానితో ఎప్పుడూ గందరగోళం చేయరు. తరువాత ఏమి జరగాలో మీ application నిర్ణయిస్తుంది.

మా engineersతో production appలో దీనిని నిర్మించడానికి, early access కోసం apply చేయండి. Evidence ఏమి చూపగలదో, ఏమి చూపలేదో పూర్తి దృశ్యం కోసం Detection & Limitationsను చదవండి.

Sources

మాతో కలిసి నిర్మించండి.

Proof of Actor founding developer program లో చేరండి.

తొందరగా యాక్సెస్ పొందండిdeveloper hub

ముందుగా మాట్లాడాలనుకుంటున్నారా? foundersతో మాట్లాడండి