ಪ್ರಮುಖ ವಿಷಯಕ್ಕೆ ಬಿಟ್ಟುಬಿಡಿ
ಮಾರ್ಗದರ್ಶಿ

ಸೈನ್ ಮಾಡಿದ AI ಏಜೆಂಟ್ ವಿನಂತಿಗಳನ್ನು ಹೇಗೆ ಪರಿಶೀಲಿಸುವುದು

ಸ್ವಯಂಚಾಲಿತ ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಬಂದ RFC 9421 signatures ಅನ್ನು ಪರಿಶೀಲಿಸುವ ಪ್ರಾಯೋಗಿಕ ಹಂತಾವಳಿ, ಮಾನ್ಯ signature ಏನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಮತ್ತು ನಿಮ್ಮ ಲಾಗ್‌ಗಳು ಏನು ಸೆರೆಹಿಡಿಯಬೇಕು ಎಂಬುದು.

Toshendra Sharma

ರಚನೆ Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

ಅತ್ಯಾಧುನಿಕ · 11 min read

ಸಹಿ ಮಾಡಿದ ವಿನಂತಿ ಏನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ?

ಬಹುತೇಕ ಸ್ವಯಂಚಾಲಿತ traffic ತನ್ನನ್ನು user agent string ಮೂಲಕ ಗುರುತಿಸುತ್ತದೆ. ಆ string ಒಂದು ಹೇಳಿಕೆ ಮಾತ್ರ, ಮತ್ತು ಅದನ್ನು ನಕಲಿಸಲು ಯಾವುದೇ ವೆಚ್ಚವಿಲ್ಲ. Signed requests ಈ ಚಿತ್ರವನ್ನು ಬದಲಾಯಿಸುತ್ತವೆ. ಸ್ವಯಂಚಾಲಿತ client ತನ್ನ HTTP requests ಅನ್ನು private key ಬಳಸಿ ಸಹಿ ಮಾಡಿ, ಅದರ matching public key ಅನ್ನು operator ಗೆ ಸಂಬಂಧಿಸಿದ ಸ್ಥಳದಲ್ಲಿ ಪ್ರಕಟಿಸಿದಾಗ, ನಿಮ್ಮ server ಆ ವಿನಂತಿಯನ್ನು ನಿಜವಾಗಿಯೂ ಆ key ಹೊಂದಿರುವ ಯಾರೋ ಒಬ್ಬರು ರಚಿಸಿದ್ದಾರೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಬಹುದು.

ಇದಕ್ಕೆ ಆಧಾರವಾಗಿರುವ standard ಎಂದರೆ HTTP Message Signatures, ಇದನ್ನು RFC 9421 ಆಗಿ ಪ್ರಕಟಿಸಲಾಗಿದೆ. IETF Web Bot Auth working group ಸ್ವಯಂಚಾಲಿತ clients ಗಾಗಿ conventions ಗಳೊಂದಿಗೆ ಇದನ್ನು ವಿಸ್ತರಿಸುತ್ತದೆ: ಒಂದು agent ತನ್ನ key directory ಗೆ ಹೇಗೆ ಸೂಚಿಸುತ್ತದೆ ಮತ್ತು ಅದು ಯಾವ request components ಗಳಿಗೆ ಸಹಿ ಮಾಡಬೇಕು ಎಂಬುದು. 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 ಅನ್ನು ಸಣ್ಣ ತಪ್ಪುಗಳಿಂದ ಸುಲಭವಾಗಿ ತಪ್ಪಾಗಿ ಮಾಡಬಹುದು.

ಯಾಂತ್ರಿಕ ಹಂತಗಳಿಗೆ ಮೊದಲು, ಫಲಿತಾಂಶದ ಬಗ್ಗೆ ನಿಖರವಾಗಿರಿ. ಮಾನ್ಯ signature ತೋರಿಸುವುದು ಎಂದರೆ, ವಿನಂತಿಯನ್ನು operator ನ domain ನಂತಹ ಪ್ರಕಟಿಸಿದ identifier ಗೆ ಸಂಬಂಧಿಸಿದ key ಬಳಸಿ ಸಹಿ ಮಾಡಲಾಗಿದೆ, ಮತ್ತು request ನ ಸಹಿ ಮಾಡಲಾದ ಭಾಗಗಳನ್ನು ಬದಲಾಯಿಸಲಾಗಿಲ್ಲ ಎಂಬುದು. ಇದು agent ಗೆ ಯಾರು ಸೂಚನೆ ನೀಡಿದರು, ವ್ಯಕ್ತಿಯೊಬ್ಬರು ಅದಕ್ಕೆ ಅಧಿಕಾರ ಹಂಚಿಕೊಟ್ಟರೇ, ಅಥವಾ ಕ್ರಮವು ಸುರಕ್ಷಿತವೇ ಎಂಬುದನ್ನು ತೋರಿಸುವುದಿಲ್ಲ. Identity evidence ಮತ್ತು authorization ಬೇರೆ ಪ್ರಶ್ನೆಗಳು, ಮತ್ತು ನಿಮ್ಮ application ಎರಡನೆಯದಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ. ಸೈನ್ ಮಾಡಿದ AI agent requests ಏನು ಸಾಬೀತುಪಡಿಸುತ್ತವೆ ಎಂಬ ನಮ್ಮ blog post ಉದಾಹರಣೆಗಳೊಂದಿಗೆ ಆ ಗಡಿ ರೇಖೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಬಳಸುವ ಹೆಡರ್‌ಗಳು

ಸೈನ್ ಮಾಡಿದ ವಿನಂತಿ ಸಾಮಾನ್ಯವಾಗಿ ಮೂರು 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 ಎನ್‌ಕೋಡ್ ಮಾಡಿರುವ ರೂಪದಲ್ಲಿ ಹೊಂದಿರುತ್ತದೆ.
  • 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 ಮೂಲಕ key ಮಾಡಲಾದ structured field ಆಗಿದೆ (ಉದಾಹರಣೆಗೆ sig1="https://agent.example"), ಆದ್ದರಿಂದ ನಿಮ್ಮ verification library ಯಾವ ರೂಪವನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ.

ಹಂತ 1: structured fields ಅನ್ನು ಸರಿಯಾಗಿ ಪಾರ್ಸ್ ಮಾಡಿ

Signature-Input ಮತ್ತು Signature ಗಳು HTTP Structured Fields (RFC 9651, ಇದು RFC 8941 ಅನ್ನು obsolete ಮಾಡುತ್ತದೆ). ಇವನ್ನು string splitting ಮೂಲಕ ಪಾರ್ಸ್ ಮಾಡಬೇಡಿ. Quoted strings, parameters ಮತ್ತು inner lists ಎಲ್ಲಕ್ಕೂ ನಿಖರ grammar ಇದೆ, ಮತ್ತು ಅಸಾವಧಾನ parser false rejections ಗಳನ್ನೂ ನಿಜವಾದ security gaps ಗಳನ್ನೂ ಉಂಟುಮಾಡುತ್ತದೆ.

ಒಂದು maintained structured-field parser ಬಳಸಿ, ಅಥವಾ ಅದಕ್ಕಿಂತ ಉತ್ತಮವಾಗಿ, parsing ಮತ್ತು verification ಎರಡನ್ನೂ ಒಟ್ಟಿಗೆ ನಿರ್ವಹಿಸುವ maintained RFC 9421 library ಬಳಸಿ. Specification ಅನ್ನು ಶೂನ್ಯದಿಂದ ಅನುಷ್ಠಾನಗೊಳಿಸುವುದು ಕಲಿಕೆಯ ಉತ್ತಮ ಅಭ್ಯಾಸ, ಆದರೆ production ಗೆ ಕೆಟ್ಟ ಆಯ್ಕೆ. ಕೆಳಗಿನ ಹಂತಗಳು ಅಂತಹ library ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ನೀವು ಅದನ್ನು ಸರಿಯಾಗಿ configure ಮಾಡಿ ಅದರ output ಅನ್ನು ಪರಿಶೀಲಿಸಬಹುದು.

ಹಂತ 2: ಯಾವ signature ಅನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಬೇಕು ಎಂಬುದನ್ನು ಆರಿಸಿ

ಒಂದು request ನಲ್ಲಿ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು signature label ಇರಬಹುದು. ನಿಮ್ಮ policy ಗೆ ಹೊಂದಿಕೆಯಾಗುವದನ್ನು ಆರಿಸಿ, ಉದಾಹರಣೆಗೆ tag web-bot-auth ಆಗಿರುವ label. verification purposes ಗಾಗಿ request ಅನ್ನು reject ಮಾಡಿ (serving purposes ಗಾಗಿ ಅಲ್ಲ), եթե:

  • ನಿಮಗೆ ಅಗತ್ಯವಿರುವ parameters ಇರುವ signature ಯಾವುದೂ ಇಲ್ಲದಿದ್ದರೆ,
  • algorithm ನಿಮ್ಮ allowlist ನಲ್ಲಿ ಇಲ್ಲದಿದ್ದರೆ (ಉದಾಹರಣೆಗೆ ed25519), ಅಥವಾ
  • covered components ಗಳಲ್ಲಿ ನಿಮಗೆ ಅಗತ್ಯವಿರುವ ಕನಿಷ್ಠ ಸಮೂಹ ಸೇರಿಲ್ಲದಿದ್ದರೆ.

ಸ್ವಯಂಚಾಲಿತ clients ಗಾಗಿ ಸಮಂಜಸವಾದ ಕನಿಷ್ಠವು @method, @authority ಮತ್ತು @path, ಹಾಗು ಆ header ಇದ್ದರೆ signature-agent ಕೂಡ. @authority ಇಲ್ಲದಿದ್ದರೆ, ಒಂದು site ಗಾಗಿ ಸೆರೆಹಿಡಿದ signature ಅನ್ನು ಮತ್ತೊಂದು site ವಿರುದ್ಧ replay ಮಾಡಬಹುದು. @path ಇಲ್ಲದಿದ್ದರೆ, ಅದನ್ನು endpoints ಗಳಾದ್ಯಂತ ಮರುಬಳಕೆ ಮಾಡಬಹುದು. Web Bot Auth protocol draft agents ಗಳಿಗೆ @authority ಅಥವಾ @target-uri ಅನ್ನು cover ಮಾಡಲು ಅಗತ್ಯವಿದೆ, ಮತ್ತು authority ಅನ್ನು ಮಾತ್ರ cover ಮಾಡುವ signature ಅದು expire ಆಗುವವರೆಗೆ ಆ host ನ ಯಾವುದೇ method ಅಥವಾ path ವಿರುದ್ಧ ಪರಿಶೀಲಿತವಾಗುತ್ತದೆ ಎಂದು ಎಚ್ಚರಿಸುತ್ತದೆ.

ಹಂತ 3: ಸಮಯ parameters ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ

RFC 9421, Section 2.3 ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಸಮಯ parameters ಆಗಿರುವ created ಮತ್ತು expires ಅನ್ನು ಓದಿ. ನಂತರ:

  1. created ಸಮಯವು ಅಲ್ಪ clock skew allowance ಕ್ಕಿಂತಲೂ ಮುಂದಿನ ಭವಿಷ್ಯದಲ್ಲಿದ್ದರೆ, ಅಂತಹ signatures ಅನ್ನು reject ಮಾಡಿ.
  2. expires ಅನ್ನು ಮೀರಿದ signatures ಅನ್ನು reject ಮಾಡಿ.
  3. expires ಇಲ್ಲದಿದ್ದರೆ, created ಆಧರಿಸಿ ನಿಮ್ಮದೇ maximum age ಅನ್ನು enforce ಮಾಡಿ.

ಸಣ್ಣ validity windows captured request ಅನ್ನು ಎಷ್ಟು ಕಾಲ replay ಮಾಡಬಹುದೋ ಅದನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತವೆ.

ಹಂತ 4: ಕೀಲಿಯನ್ನು ಪತ್ತೆಮಾಡಿ

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 ಗೆ ಪ್ರಾಯೋಗಿಕ ನಿಯಮಗಳು:

  • verification ಪ್ರತಿಯೊಂದು request ಗೆ network call ಸೇರಿಸದಂತೆ, bounded lifetime ಹೊಂದಿರುವ cache ನಲ್ಲಿ keys ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ.
  • ಸಣ್ಣ timeout ಅನ್ನು ಹೊಂದಿಸಿ ಮತ್ತು ವಿಫಲವಾದ 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 ನಲ್ಲಿರುವ ಮುಕ್ತ ಪಠ್ಯದ ಹೆಸರಿಗೆ ಅಲ್ಲ. ನೀವು ದಾಖಲಿಸುವ identifier ಎಂದರೆ directory origin.

ಹಂತ 5: signature base ಅನ್ನು ಮರುನಿರ್ಮಿಸಿ

ಸಹಿ ಮಾಡಿದವರು raw request ಅನ್ನು ಸಹಿ ಮಾಡಿಲ್ಲ. ಅವರು signature base ಎಂದು ಕರೆಯುವ canonical string ಅನ್ನು ಸಹಿ ಮಾಡಿದ್ದಾರೆ (RFC 9421, Section 2.5), ಇದು ಕ್ರಮದಲ್ಲಿ covered components ಗಳಿಂದ ನಿರ್ಮಿಸಲ್ಪಟ್ಟು, ನಂತರ @signature-params line ಇರುತ್ತದೆ. ನಿಮ್ಮ verifier ಅದೇ string ಅನ್ನು ತಾನು ಸ್ವೀಕರಿಸಿದ request ನಿಂದ ಮರುನಿರ್ಮಿಸುತ್ತದೆ.

ಮೇಲಿನ ಉದಾಹರಣೆಗೆ 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 ಅನ್ನು ಮರುಬರೆಯುವುದಾದರೆ, ಅದು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಮೂಲ ಮೌಲ್ಯವನ್ನು ಬಳಸಿ.
  • @path query string ಅನ್ನು ಹೊರತುಪಡಿಸುತ್ತದೆ. client @query ಅನ್ನು cover ಮಾಡಿದಿದ್ದರೆ, ಅದನ್ನು ಸ್ವೀಕರಿಸಿದಂತೆ ನಿಖರವಾಗಿ ಮರುನಿರ್ಮಿಸಿ.
  • Header values ಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದಂತೆ canonicalize ಮಾಡಲಾಗುತ್ತದೆ: trimmed ಆಗಿರುತ್ತವೆ, ಮತ್ತು multiple values ಗಳನ್ನು ಸೇರಿಸಲಾಗುತ್ತದೆ. ಒಳ್ಳೆಯ library ಇದನ್ನು ನಿಮ್ಮ ಪರವಾಗಿ ಮಾಡುತ್ತದೆ.

ಹಂತ 6: signature ಅನ್ನು ಪರಿಶೀಲಿಸಿ

Base ಮತ್ತು public key ಇರುವುದರಿಂದ, RFC 9421, Section 3.2 ನಲ್ಲಿ ನೀಡಿದ ಹಂತಗಳನ್ನು ಅನುಸರಿಸಿ verification ಒಂದೇ ಕರೆ ಆಗುತ್ತದೆ. 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"));
}

ಪರಿಶೀಲನೆ ವಿಫಲವಾದರೆ, ವಿನಂತಿ verified ಅಲ್ಲ. ಅದನ್ನು ಇನ್ನೂ serve ಮಾಡಬಹುದು. ಅದು ಕೇವಲ "verified" basis ಅನ್ನು ಪಡೆಯುವುದಿಲ್ಲ.

ಹಂತ 7: replay ಅನ್ನು ತಡೆಯಿರಿ

ಮಾನ್ಯ signature ಅನ್ನು ಹಿಡಿದು ಅದರ ಅವಧಿ ಮುಗಿಯುವವರೆಗೆ ಮರುಕಳುಹಿಸಬಹುದು. 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 ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ, ಮತ್ತು ಎರಡನೇ ಬಳಕೆಯನ್ನು 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;
}

ಬಹು-instance deployment ನಲ್ಲಿ, ಉಳಿದ validity ಗೆ ಸಮನಾದ time to live ಹೊಂದಿರುವ Redis ನಂತಹ shared store ನಲ್ಲಿ nonces ಗಳನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ.

ಹಂತ 8: ಫಲಿತಾಂಶವನ್ನು ಅದರ basis ಜೊತೆಗೆ ದಾಖಲಿಸಿ

Verification evidence ಅನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ, ತೀರ್ಪನ್ನು ಅಲ್ಲ. ನಿಮ್ಮ 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 ವಿಫಲವಾದರೆ ಅಥವಾ ಚಾಲನೆಯಾಗದಿದ್ದರೆ, ಕಾರಣದೊಂದಿಗೆ ಅದನ್ನೂ ದಾಖಲಿಸಿ: 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 ಗಳಿಗೆ ಗೌರವ ನೀಡುವಷ್ಟು ಚಿಕ್ಕದಾಗಿ ಮತ್ತು patterns ಗಳನ್ನು ಅಧ್ಯಯನ ಮಾಡಲು ಸಾಕಷ್ಟು ದೀರ್ಘವಾಗಿ logs ಗಳನ್ನು ಉಳಿಸಿ.

Verified signature ನಿಮ್ಮ policy ಯನ್ನು ಹೇಗೆ ಬದಲಾಯಿಸಬೇಕು?

Requests ಗಳನ್ನು ಒಮ್ಮೆ verified ಮಾಡಬಹುದಾದರೆ, ನೀವು ಅವುಗಳನ್ನು ಅರ್ಥಪೂರ್ಣ ರೀತಿಯಲ್ಲಿ ವಿಭಿನ್ನವಾಗಿ ನಿರ್ವಹಿಸಬಹುದು. ಮಾನವರು ಮತ್ತು AI agents ಗಾಗಿ app policies ವಿನ್ಯಾಸಗೊಳಿಸುವುದು ಎಂಬ ನಮ್ಮ post ವಿಸ್ತೃತ policy model ಅನ್ನು ಒಳಗೊಂಡಿದೆ:

  • verified operators ಗಳಿಗೆ read-only routes ಗಳಲ್ಲಿ, unverified automation ಗಿಂತ ಹೆಚ್ಚಿನ rate limit ನೊಂದಿಗೆ ಅನುಮತಿ ನೀಡಿ.
  • ಅವರಿಗೆ full HTML pages ಬದಲು JSON ಅಥವಾ Markdown ನಂತಹ structured responses ನೀಡಿರಿ.
  • ಹೆಚ್ಚಿನ ಪ್ರಭಾವದ actions ಗಳನ್ನು ನಿಮ್ಮ ಸಾಮಾನ್ಯ authorization ಹಿಂದೆಯೇ ಇಡಿ. Verified signature ನಿಮಗೆ ಯಾವ client ಕರೆ ಮಾಡುತ್ತಿದೆ ಎಂಬುದನ್ನು ಹೇಳುತ್ತದೆ, ಆದರೆ ಅದು account ಅನ್ನು ಬದಲಾಯಿಸಬಹುದು ಎಂದು ಹೇಳುವುದಿಲ್ಲ.

Observation mode ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಿ. ಯಾವುದೇ policy ಅದನ್ನು ಆಧರಿಸುವ ಮೊದಲು, ನಿಮ್ಮ automated traffic ನ ಎಷ್ಟು ಭಾಗ signed ಇದೆ, ಯಾವ operators ಕಾಣಿಸುತ್ತಾರೆ, ಮತ್ತು verification ಎಷ್ಟು ಬಾರಿ ವಿಫಲವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಅಳೆಯಿರಿ.

Proof of Actor ಎಲ್ಲಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ

Signature verification ಅನೇಕ signals ಗಳಲ್ಲಿ ಒಂದೇ evidence ಮೂಲವಾಗಿದೆ. Proof of Actor ಅದನ್ನು ಇತರ signals ಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸಿ, ಪ್ರತಿಯೊಂದು result ನಲ್ಲೂ basis ಅನ್ನು ಗೋಚರವಾಗಿರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ verified agent ಎಂದಿಗೂ ತನ್ನನ್ನು ಮಾತ್ರ declared ಮಾಡಿಕೊಂಡ agent ಜೊತೆ ಗೊಂದಲಗೊಳ್ಳುವುದಿಲ್ಲ. ಮುಂದೇನು ಆಗಬೇಕು ಎಂಬುದನ್ನು ನಿಮ್ಮ application ನಿರ್ಧರಿಸುತ್ತದೆ.

ನಮ್ಮ engineers ಜೊತೆ production app ನಲ್ಲಿ ಇದನ್ನು ನಿರ್ಮಿಸಲು, early access ಗೆ ಅರ್ಜಿ ಸಲ್ಲಿಸಿ. Evidence ಏನು ತೋರಿಸಬಹುದು ಮತ್ತು ಏನು ತೋರಿಸಲಾರದು ಎಂಬ ಸಂಪೂರ್ಣ ಚಿತ್ರಕ್ಕಾಗಿ, Detection & Limitations ಅನ್ನು ಓದಿ.

ಮೂಲಗಳು

ನಮ್ಮೊಂದಿಗೆ ಅದನ್ನು ನಿರ್ಮಿಸಿ.

Proof of Actor founding developer program ಗೆ ಸೇರಿ.

ಮುಂಗಡ ಪ್ರವೇಶ ಪಡೆಯಿರಿಡೆವಲಪರ್ ಕೇಂದ್ರ

ಮೊದಲು ಮಾತನಾಡಲು ಇಷ್ಟವಿದೆಯೆ? ಸ್ಥಾಪಕರೊಂದಿಗೆ ಮಾತನಾಡಿ