ମୁଖ୍ୟ ବିଷୟବସ୍ତୁକୁ ଛାଡ଼ନ୍ତୁ
ବ୍ୟାଖ୍ୟା

ଉତ୍ପାଦ ଟିମ୍‌ମାନଙ୍କ ପାଇଁ Web Bot Auth: signed agent requests ଆପଣଙ୍କ roadmap ପାଇଁ କ'ଣ ଅର୍ଥ ରଖେ

AI agents ଏବଂ crawlers ଏବେ User-Agent string ଉପରେ ଭରସା ନକରି, ଯାହାକୁ କେହି ମଧ୍ୟ copy କରିପାରେ, ସେମାନେ କିଏ ବୋଲି ପ୍ରମାଣ କରିବା ପାଇଁ ଏକ ପଥ ଦରକାର କରୁଛନ୍ତି। IETF Web Bot Auth କାର୍ଯ୍ୟ ଏହାକୁ standardize କରିବା ପାଇଁ ପ୍ରମୁଖ ପ୍ରୟାସ। ଏହା product managers ଏବଂ engineering leads ପାଇଁ ସରଳ ବ୍ୟାଖ୍ୟା: ଏହା କିପରି କାମ କରେ, କ'ଣ ପ୍ରମାଣ କରେ, November 2026 ଅବଧିରେ ଏହାର ଅବସ୍ଥା କ'ଣ, ଏବଂ ଏହା ପାଇଁ କିପରି ପ୍ରସ୍ତୁତି ନେବେ।

Early Access ପାଆନ୍ତୁଏହା କିପରି କାମ କରେ ଅନୁସନ୍ଧାନ କରନ୍ତୁ
Toshendra Sharma

ଦ୍ୱାରା Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

ବର୍ଷଗୁଡ଼ିକ ଧରି, ଏକ automated client କେବଳ ଗୋଟିଏ website କୁ ନିଜେ କିଏ ବୋଲି କହିପାରୁଥିଲା User-Agent header ର ଏକ ନାମ ଦ୍ୱାରା, ଏବଂ କିଛି ବଡ଼ operator ମାନଙ୍କ ପାଇଁ, published IP addresses ର ତାଲିକା କିମ୍ବା reverse DNS check ଦ୍ୱାରା। ନାମ copy କରିବା ସହଜ। Network lists କେବଳ ସେହି operator ମାନଙ୍କୁ cover କରେ ଯେଉଁମାନେ ସେମାନଙ୍କୁ maintain କରନ୍ତି। AI agents ଯେପରିକି web ରେ ସତ୍ୟିକାର ଲୋକମାନଙ୍କ ପକ୍ଷରୁ act କରିବା ଆରମ୍ଭ କରୁଛନ୍ତି, ସେ gap ଏକ product problem ହୋଇଯାଇଛି, କେବଳ security problem ନୁହେଁ।

Web Bot Auth ଏହାକୁ ଭରିବା ପାଇଁ ପ୍ରମୁଖ ପ୍ରୟାସ। ଏହା automated clients କୁ ସେମାନଙ୍କର control ଏବଂ publish କରାଯାଇଥିବା key ସହିତ ସେମାନଙ୍କ requests sign କରିବାର ଏକ ପଥ ଦେଉଛି, ଯାହାଦ୍ୱାରା website ଏକ ନାମ ଉପରେ ଭରସା କରିବା ପରିବର୍ତ୍ତେ signature check କରିପାରେ। ଏହି explainer product managers ଏବଂ engineering leads ପାଇଁ, ଯେଉଁମାନେ specification କୁ ଆରମ୍ଭରୁ ଶେଷ ପର୍ଯ୍ୟନ୍ତ ପଢ଼ିବା ବିନା ଏହା କ'ଣ, ଏହା କ'ଣ ପରିବର୍ତ୍ତନ କରେ, ଏବଂ ଏହା କ'ଣ କରେ ନାହିଁ, ସେଥିକୁ ବୁଝିବା ଆବଶ୍ୟକ।

ସଂକ୍ଷିପ୍ତ ସାର

  • ଏହା କ'ଣ: ଏକ IETF working group, webbotauth, ଏବଂ automated HTTP clients କୁ authenticate କରିବା ପାଇଁ ସେମାନେ standardize କରୁଥିବା ପଦ୍ଧତି।
  • ଏହା କିପରି କାମ କରେ: client ପ୍ରତ୍ୟେକ request ର କିଛି ଅଂଶକୁ HTTP Message Signatures (RFC 9421) ବ୍ୟବହାର କରି sign କରେ ଏବଂ ନିଜ public keys ର ଏକ directory କୁ point କରେ। Site key fetch କରେ ଏବଂ signature verify କରେ।
  • ଏହା କ'ଣ ପ୍ରମାଣ କରେ: କେଉଁ key request କୁ sign କଲା, ଏବଂ transit ରେ signed parts ବଦଳାଯାଇନଥିଲା।
  • ଏହା କ'ଣ ପ୍ରମାଣ କରେ ନାହିଁ: agent କୁ ସେ ଯାହା ଚାହୁଁଛି ତାହା କରିବାକୁ authorization ଅଛି କି ନୁହେଁ, ସେ ନିର୍ଦ୍ଦିଷ୍ଟ user ପାଇଁ act କରୁଛି କି ନୁହେଁ, କିମ୍ବା ସେ ଭଲ ଭାବରେ ବ୍ୟବହାର କରିବ କି ନୁହେଁ।
  • November 2026 ଅବଧିରେ ଅବସ୍ଥା: RFC 9421 ଏକ published Proposed Standard। Web Bot Auth protocol document ଏକ working group Internet-Draft, ଏପର୍ଯ୍ୟନ୍ତ RFC ନୁହେଁ।
  • କ'ଣ କରିବେ: valid signatures କୁ ଶକ୍ତ evidence ଭାବେ ବ୍ୟବହାର କରିବା ପାଇଁ ପ୍ରସ୍ତୁତି ନିଅନ୍ତୁ, unsigned traffic କୁ ଚାଲୁ ରଖି ସମ୍ଭାଳନ୍ତୁ, ଏବଂ authorization decisions କୁ ନିଜ code ରେ ରଖନ୍ତୁ।

IETF Web Bot Auth କାମ କ'ଣ

IETF Web Bot Auth working group କୁ cryptographically automated clients କୁ websites ସହିତ authenticate କରିବା ପ୍ରଣାଳୀ ଏବଂ websites କୁ ସେମାନଙ୍କ ପଛର operator ମାନଙ୍କ ବିଷୟରେ ଅଧିକ ସୂଚନା ଦେବା ପାଇଁ standardize କରିବା ଉଦ୍ଦେଶ୍ୟରେ charter କରିଥିଲା। Charter ମୁଖ୍ୟତଃ ଲୋକମାନଙ୍କୁ ସେବା ଦେଉଥିବା sites ଉପରେ କେନ୍ଦ୍ରିତ, ଏବଂ ଏହା scope ଭିତରେ clients ର ଏକ ବ୍ୟାପକ set କୁ ନାମ କରେ: crawlers, web archivers, link checkers, AI training crawlers, ଏବଂ end users ପାଇଁ act କରୁଥିବା AI agents।

Charter ଭିତରେ ଦୁଇଟି exclusion product teams ପାଇଁ ଧ୍ୟାନ ଦେବା ଯୋଗ୍ୟ। End-user authentication scope ବାହାରେ, ସେଥିପାଇଁ ଏହା କାହାରୋ ଲଗ୍‌ଇନ କରିବା ପାଇଁ ଏକ ଉପାୟ ନୁହେଁ। Bot reputation ଟ୍ରାକିଂ ମଧ୍ୟ scope ବାହାରେ, ସେଥିପାଇଁ standard ଆପଣଙ୍କୁ କେଉଁ request କୁ sign କଲା କେବଳ ଦେଖାଏ, ସେ operator କେତେ trustworthy ତାହା ନୁହେଁ।

Charter ତିନି ପ୍ରକାର deliverables ତାଲିକାଭୁକ୍ତ କରେ:

  1. People ପାଇଁ ନିର୍ମିତ websites ସହିତ automated clients କୁ authenticate କରିବା ପ୍ରଣାଳୀ ଉପରେ Standards track documents।
  2. Existing identifier, ଯେପରିକି domain name କିମ୍ବା URL, ବ୍ୟବହାର କରି ଅନୁରୋଧକ bot ବିଷୟରେ ଅଧିକ ସୂଚନା ପହଞ୍ଚାଇବା ଉପରେ Standards track documents।
  3. Key management, lifecycle ଏବଂ deployment ପରି operational topics ଉପରେ Best current practice କିମ୍ବା informational documents।

November 2026 ଅବଧିରେ document ଗୁଡ଼ିକ କେଉଁଠି ଅଛି

November 2026 ଅବଧିରେ, working group ରେ ଗୋଟିଏ adopted working group document ଅଛି: draft-ietf-webbotauth-httpsig-protocol, ଶୀର୍ଷକ "HTTP Message Signatures for automated traffic", revision 01, October 29, 2026 ତାରିଖର। ଏହା ଏକ Internet-Draft, ଅର୍ଥାତ୍ ଏହା ଏକ work in progress ଯାହା ଏବେ ମଧ୍ୟ ପରିବର୍ତ୍ତିତ ହୋଇପାରେ। ଏହା RFC ନୁହେଁ।

Several individual drafts ମଧ୍ୟ group ସହିତ ସମ୍ପୃକ୍ତ ଏବଂ ଆଲୋଚନା ଅଧୀନରେ ଅଛି, ଯେଉଁଥିରେ registry ଏବଂ agent card format, anonymous bot authentication, automated clients ର IP ranges publish କରିବା ପାଇଁ JSON format, ଏବଂ signed agent metadata ପାଇଁ ଏକ header ଉପରେ proposals ଅଛି। Individual drafts ହେଉଛି proposals; ଏମାନଙ୍କ ମଧ୍ୟରୁ କେହି ମଧ୍ୟ ଏହି ତାରିଖ ଅବଧିରେ group ଦ୍ୱାରା adopted ହୋଇନାହିଁ।

Charter 2026 ମଧ୍ୟରେ specifications କୁ approval ପାଇଁ IESG କୁ ପଠାଇବା ପାଇଁ milestones set କରିଥିଲା। November 2026 ଅବଧିରେ, protocol document ଏବେ ମଧ୍ୟ ଏକ working group draft ରହିଛି। ଆପଣ current state କୁ IETF datatracker page for the working group ଏବଂ protocol draft ରେ follow କରିପାରିବେ।

HTTP Message Signatures କିପରି କାମ କରେ

Web Bot Auth RFC 9421, HTTP Message Signatures ଉପରେ ଭିତ୍ତି କରେ, ଯାହା February 2024 ରେ Proposed Standard ଭାବେ published ହୋଇଥିଲା। RFC 9421 ଏକ general mechanism: ଏହା HTTP message ର selected parts କିପରି sign କରିବା ଏବଂ signature କୁ headers ରେ କିପରି carry କରିବା, ତାହା define କରେ। Web Bot Auth automated clients ପାଇଁ ଏହାକୁ profile କରେ।

ସରଳ ଭାଷାରେ, signed agent request ଏଭଳି କାମ କରେ:

  1. Operator ଏକ key pair create କରେ। Private key କୁ secret ରଖେ ଏବଂ public key publish କରେ।
  2. Client କ'ଣ sign କରିବେ ତାହା ବାଛେ। ଏହା request ର components, ଯେପରିକି target host କିମ୍ବା URI ଏବଂ creation time, ବାଛେ। Current draft authority କିମ୍ବା target URI କୁ cover କରିବାକୁ ଆବଶ୍ୟକ କରେ, ସେଥିପାଇଁ ଗୋଟିଏ site ପାଇଁ signature କୁ ସରଳଭାବେ ଅନ୍ୟ site ରେ replay କରିହେବ ନାହିଁ।
  3. Client sign କରେ ଏବଂ send କରେ। Request ରେ Signature-Input header ଥାଏ, ଯାହା signed କ'ଣ ଏବଂ କେଉଁ key ସହିତ, ତାହା describe କରେ, ଏବଂ Signature header ରେ signature value ଥାଏ। Draft ରେ web-bot-auth tag ବ୍ୟବହାର ହୁଏ ଏବଂ ପ୍ରତ୍ୟେକ signature ରେ creation ଏବଂ expiry times ଆଶା କରାଯାଏ।
  4. Site verify କରେ। ଏହା public key ଖୋଜେ, ସେ ପାଇଥିବା request ରୁ signed components ପୁଣି ତିଆରି କରେ, ଏବଂ signature check କରେ। Check ପାସ୍ ହେଲେ, request ସେହି key ର holder ଦ୍ୱାରା sign ହୋଇଥିଲା ଏବଂ covered parts ବଦଳାଯାଇନଥିଲା।

Draft ଏକ site କୁ signature ଚାହିଁବାକୁ ମଧ୍ୟ ଅନୁମତି ଦେଉଛି। ଏକ origin Accept-Signature header ପଠାଇପାରେ, ସାଧାରଣତଃ refusal ସହିତ, signed requests ଚାହୁଁଛି ବୋଲି signal କରିବା ପାଇଁ।

Key directory ବିଚାର

Site ଠିକ public key ଖୋଜିପାରିଲେ ମାତ୍ର ଏକ signature ଉପଯୋଗୀ। Web Bot Auth ଏହାର ଉତ୍ତର key directory ଦ୍ୱାରା ଦେଉଛି।

Current working group draft ରେ, client ଏକ HTTPS URL ସହିତ Signature-Agent header ଯୋଡ଼େ। ସେ URL operator ର public keys ର directory କୁ JSON Web Key Set ଭାବରେ serve କରେ। Site directory fetch କରେ, signature ରେ key identifier ସହିତ ମେଳ ଖାଉଥିବା key ବାଛେ, ଏବଂ verify କରେ। Draft ଏକ well-known path, /.well-known/http-message-signatures-directory, ମଧ୍ୟ define କରେ, ଯେଠାରେ operator ନିଜ directory serve କରିପାରେ।

Product teams ପାଇଁ ଉପଯୋଗୀ ବିଚାର ହେଉଛି URL identity ହୋଇଯାଏ। Agent operator କେଉଁଠି ନିଜ keys publish କରେ, ତାହା ଦ୍ୱାରା ଚିହ୍ନଟ ହୁଏ, ଯାହା signature କୁ operator ଯେଉଁ domain control କରେ ସେଥି ସହିତ ଯୋଡ଼େ। Key rotation ପୁରୁଣା key ସହିତ ଏକ ନୂଆ key publish କରି, ପରେ ପୁରୁଣାଟି remove କରି କାମ କରେ।

Verifying sites ମାନେ directories କୁ ସାବଧାନୀପୂର୍ବକ handle କରିବା ଆବଶ୍ୟକ: normal HTTP rules ଅନୁଯାୟୀ cache କରନ୍ତୁ, size limits ଏବଂ timeouts set କରନ୍ତୁ, ଏବଂ private network addresses ରୁ fetch କରିବାକୁ ଏଡ଼ାନ୍ତୁ। ଏହା standard engineering concern, ଏବଂ ଏହିକାରଣରୁ ଅନେକ team ସେମାନଙ୍କ ପାଇଁ verification କରୁଥିବା ଏକ component ପସନ୍ଦ କରନ୍ତି।

Valid signature କ'ଣ ପ୍ରମାଣ କରେ, ଏବଂ କ'ଣ ପ୍ରମାଣ କରେ ନାହିଁ

ଏହା product policy ଲେଖୁଥିବା କାହା ପାଇଁ ମଧ୍ୟ ସର୍ବାଧିକ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ section।

Valid signature ପ୍ରମାଣ କରେ:

  • Request ଏକ specific private key ର holder ଦ୍ୱାରା sign ହୋଇଥିଲା।
  • ସେ key operator control କରୁଥିବା ଏକ directory URL ରେ publish ହୋଇଛି।
  • Request ର signed parts transit ରେ ବଦଳାଯାଇନଥିଲା, ଏବଂ signature ନିଜ validity window ଭିତରେ ଥିଲା।

Valid signature ପ୍ରମାଣ କରେ ନାହିଁ:

  • Agent ଯେ କାର୍ଯ୍ୟ କରିବାକୁ ଚାହୁଁଛି, ସେଥି ପାଇଁ authorized ଅଛି କି ନୁହେଁ। Identifiable ହେବା permission ନୁହେଁ। agent authorization ଦେଖନ୍ତୁ।
  • Agent ନିର୍ଦ୍ଦିଷ୍ଟ person ପାଇଁ act କରୁଛି କି, କିମ୍ବା ସେ person ଯେ authority ଦେଇଛି ସେଥିରେ act କରୁଛି କି ନୁହେଁ। delegated authority ଦେଖନ୍ତୁ।
  • Operator trustworthy କି ନୁହେଁ କିମ୍ବା agent ଭଲ ଭାବରେ ବ୍ୟବହାର କରିବ କି ନୁହେଁ। Reputation working group ର scope ବାହାରେ ସ୍ପଷ୍ଟଭାବେ ରହିଛି।
  • Signed ନୁହେଁ ଏମିତି requests ବିଷୟରେ କିଛି। Unsigned traffic ନିଜ ସ୍ୱତନ୍ତ୍ର handling ଆବଶ୍ୟକ କରେ।

Valid signature କୁ request କିଏ ପଠାଇଲା ତାହାର ଶକ୍ତ evidence ଭାବେ ନିଅନ୍ତୁ, ପରେ ଆପଣଙ୍କ ନିଜ access control କୁ ନିର୍ଣ୍ଣୟ କରିବାକୁ ଦିଅନ୍ତୁ ସେ sender କ'ଣ କରିପାରିବ।

Product teams ଏଥିପାଇଁ କ'ଣ କରିବା ଉଚିତ

Plan କରିବା ପାଇଁ ଆପଣଙ୍କୁ RFC ଅପେକ୍ଷା କରିବାକୁ ପଡ଼େ ନାହିଁ। Signed agent traffic ଏମିତି କିଛି ଯାହା ପାଇଁ ଆପଣ ଏବେଠାରୁ ପ୍ରସ୍ତୁତି ନେଇପାରିବେ, ଏହି ବୁଝାମଣି ସହିତ ଯେ draft ର କିଛି ବିବରଣୀ ବଦଳିପାରେ।

1. Decision ନେବା ପୂର୍ବରୁ measure କରନ୍ତୁ

ଆପଣଙ୍କ traffic ର କେତେ ଅଂଶ automated, କେଉଁ routes agent ବ୍ୟବହାର କରୁଛନ୍ତି, ଏବଂ ସେଥିର କେତେ signed, ତାହା ଜାଣନ୍ତୁ। observation mode ରୁ ଆରମ୍ଭ କରନ୍ତୁ, ଯାହାଦ୍ୱାରା measurement ଆପଣଙ୍କ users ପାଇଁ କିଛି ପରିବର୍ତ୍ତନ କରେ ନାହିଁ।

2. Evidence ଓ policy କୁ ଅଲଗା କରନ୍ତୁ

Evidence କ'ଣ କହୁଛି, verified, declared, inferred କିମ୍ବା unknown, ତାହାକୁ ଆପଣ କ'ଣ କରିବେ ସେଥିରୁ ଅଲଗା ଭାବରେ record କରନ୍ତୁ। ଏହା policies କୁ ପଢ଼ିବାଯୋଗ୍ୟ ରଖେ ଏବଂ re-instrument କରିବା ବିନା ସେଗୁଡ଼ିକୁ କଠୋର କିମ୍ବା ଢିଲା କରିବାକୁ ଦେଉଛି। evidence basis entry ଚାରିଟି level ବିଷୟରେ ବ୍ୟାଖ୍ୟା କରେ।

3. Verified agents ପାଇଁ ଭଲ path ଦିଅନ୍ତୁ

ଯେଠାରେ ଯୁକ୍ତିସଙ୍ଗତ, people ପାଇଁ ନିର୍ମିତ pages ପରିବର୍ତ୍ତେ verified agents କୁ structured content କିମ୍ବା agent-friendly flow serve କରନ୍ତୁ। serving AI agents structured content guide patterns କୁ ଆବରଣ କରେ।

4. Authorization କୁ ନିଜ code ରେ ରଖନ୍ତୁ

Signature ବ୍ୟବହାର କରି କିଏ ପଚାରୁଛି ଜାଣନ୍ତୁ। ସେମାନେ କ'ଣ କରିପାରିବ, ସେଥି ପାଇଁ ଆପଣଙ୍କ existing permissions, scopes ଏବଂ confirmations ବ୍ୟବହାର କରନ୍ତୁ। High-impact actions ତଥାପି human confirmation ଆବଶ୍ୟକ କରିପାରେ, request କିଏ sign କଲା ତାହା ସହିତ ସମ୍ପର୍କ ନ ରଖି। protecting sensitive actions without blocking agents ଦେଖନ୍ତୁ।

5. Unsigned ଏବଂ Unknown traffic ପାଇଁ ପ୍ରସ୍ତୁତ ହୁଅନ୍ତୁ

Signing ପାଇଁ support agents ଏବଂ tools ମଧ୍ୟରେ ଭିନ୍ନ ହୁଏ, ସେଥିପାଇଁ କିଛି ସମୟ ପାଇଁ signed ଏବଂ unsigned requests ର ମିଶ୍ରଣ ଆଶା କରନ୍ତୁ। Declared, inferred ଏବଂ Unknown traffic ପାଇଁ route ଅନୁଯାୟୀ କ'ଣ ହେବ, ସେଥି ଧାର୍ଯ୍ୟ କରନ୍ତୁ, site-wide rule ର ବଦଳରେ। handling Unknown traffic guide ଏହାକୁ ଧାପେ ଧାପେ ଦେଖାଏ।

Proof of Actor Web Bot Auth କୁ କିପରି ବ୍ୟବହାର କରେ

Proof of Actor ଆପଣଙ୍କ application କୁ ପ୍ରତ୍ୟେକ interaction ରେ Human, Human + AI, Agent କିମ୍ବା Unknown କିଏ କିମ୍ବା କ'ଣ act କରୁଛି, ତାହା କୁହେ, ଏବଂ evidence basis ଦେଖାଏ। Web Bot Auth signatures ଏହାର ସବୁଠୁ ଶକ୍ତ evidence ମୂଳଗୁଡ଼ିକ ମଧ୍ୟରୁ ଗୋଟିଏ।

Agent HTTP Message Signatures ସହିତ ନିଜ request sign କଲେ, Proof of Actor operator ର published key ବିରୁଦ୍ଧରେ signature check କରେ। Check pass ହେଲେ, result ଏକ verified basis ସହିତ ଆସେ, ଏବଂ ଆପଣଙ୍କ team review କରିପାରୁଥିବା evidence ସହିତ। Client କେବଳ header ରେ ନିଜକୁ ନାମ କରିଲେ, result declared ହୁଏ। Conclusion ଯଦି behavioral କିମ୍ବା contextual signals ଉପରେ ଭିତ୍ତି କରେ, ଏହାକୁ inferred ଭାବେ label କରାଯାଏ। Evidence ପର୍ଯ୍ୟାପ୍ତ ନୁହେଁ ହେଲେ, result Unknown ହୁଏ।

ଆପଣଙ୍କ application ସେ context ସହିତ କ'ଣ କରିବ, ତାହା ନିଜେ ନିର୍ଣ୍ଣୟ କରେ। Policies route ଅନୁଯାୟୀ, actor class ଅନୁଯାୟୀ ଏବଂ basis ଅନୁଯାୟୀ ଲେଖାଯାଏ, outcome ଯେପରିକି allow, adapt, challenge, review ଏବଂ rate-limit ସହିତ। ଡିଫଲ୍ଟ ଭାବେ କିଛି enforce ହୁଏ ନାହିଁ: ଆପଣ real traffic ବିରୁଦ୍ଧରେ ଏକ policy preview କରନ୍ତି ଏବଂ ନିଜ code ରେ, route ଅନୁଯାୟୀ route, enforce କରନ୍ତି।

Founding teams Node.js middleware, Next.js, ଏକ edge integration, approved pages ରେ browser collector, generic HTTP API, କିମ୍ବା MCP server integration ମାଧ୍ୟମରେ evidence collect କରିପାରନ୍ତି। integrations ଏବଂ verifying signed agent requests guide practical steps ପାଇଁ ଦେଖନ୍ତୁ।

Proof of Actor standard ଯେ ସୀମା ରଖେ, ସେହି ସୀମାକୁ follow କରେ: verified signature ଆପଣଙ୍କୁ କୁହେ କେଉଁ key request କୁ sign କଲା, କିନ୍ତୁ agent authorized କି ନୁହେଁ, ତାହା ନୁହେଁ। Authorization ଆପଣଙ୍କ ସହିତ ରହେ। evidence and limits ପୃଷ୍ଠା ପ୍ରତ୍ୟେକ result କ'ଣ support କରିପାରେ ଏବଂ କ'ଣ କରିପାରେ ନାହିଁ, ସେଥିକୁ ସଠିକ୍ ଭାବେ ଦେଖାଏ।

ଆରମ୍ଭ କରନ୍ତୁ

Proof of Actor private beta ରେ ଅଛି। Selected founding developer teams agreed usage limits ଭିତରେ, no automatic billing ସହିତ, up to 12 months ର free access ପାଇପାରନ୍ତି। early access ପାଇଁ apply କରନ୍ତୁ ଏବଂ signed agents କେଉଁ routes ବ୍ୟବହାର କରିବେ ବୋଲି ଆପଣ ଆଶା କରୁଛନ୍ତି ଏବଂ ସେମାନଙ୍କ ସହିତ ଆପଣ କ'ଣ କରିବାକୁ ଚାହୁଁଛନ୍ତି, ସେଥି କୁହନ୍ତୁ।

ବିକାଶକର୍ତ୍ତାମାନଙ୍କ ପାଇଁ

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record
{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}
class
Human, Human + AI, Agent କିମ୍ବା Unknown।
basis
ପ୍ରମାଣ କେତେ ଶକ୍ତିଶାଳୀ: verified, declared, inferred କିମ୍ବା unknown।
evidence
result ପଛରେ ଥିବା signal, ଯାହାଦ୍ୱାରା ଆପଣଙ୍କ team କାହିଁକି ତାହା ଦେଖିପାରିବ।

observation mode ରେ ଆରମ୍ଭ କରନ୍ତୁ: ଆପଣଙ୍କ log ପାଖରେ result record କରନ୍ତୁ ଏବଂ ଆପଣ policy ବାଛିବା ପର୍ଯ୍ୟନ୍ତ କିଛି ମଧ୍ୟ ପରିବର୍ତ୍ତନ କରନ୍ତୁ ନାହିଁ। Node.js integration guide ପଢନ୍ତୁ

ସାଧାରଣ ପ୍ରଶ୍ନଗୁଡ଼ିକ

Web Bot Auth କ'ଣ?

Web Bot Auth ହେଉଛି IETF working group ର ନାମ, webbotauth, ଏବଂ ସେମାନେ standardize କରୁଥିବା ପଦ୍ଧତି: automated clients HTTP requests କୁ HTTP Message Signatures (RFC 9421) ସହିତ sign କରନ୍ତି ଏବଂ ସେମାନଙ୍କର public keys publish କରନ୍ତି, ଯାହାଦ୍ୱାରା websites କେଉଁ operator request ପଠାଇଲା ତାହା verify କରିପାରିବ।

Web Bot Auth କି ଏକ ସମାପ୍ତ standard?

ଏପର୍ଯ୍ୟନ୍ତ ନୁହେଁ। November 2026 ଅବଧିରେ, ପ୍ରଧାନ protocol document, draft-ietf-webbotauth-httpsig-protocol, revision 01 ରେ ଥିବା ଏକ working group Internet-Draft। RFC 9421, ଯାହା ଉପରେ ଏହା ଭିତ୍ତି କରେ, ଏକ published Proposed Standard।

Valid Web Bot Auth signature କି agent କୁ କାର୍ଯ୍ୟ କରିବାକୁ ଅନୁମତି ମିଳିଛି ବୋଲି ଅର୍ଥ କରେ?

ନା। ଏହା ପ୍ରମାଣ କରେ କେଉଁ key request କୁ sign କଲା ଏବଂ signed parts ବଦଳାଯାଇନଥିଲା। ସେ agent ତଥ୍ୟ ପଢ଼ିପାରିବ କି, form submit କରିପାରିବ କି, କିମ୍ବା ନିର୍ଦ୍ଦିଷ୍ଟ user ପାଇଁ act କରିପାରିବ କି, ସେଥିରେ authorization decision ଆପଣଙ୍କ application ଏପର୍ଯ୍ୟନ୍ତ ନିଜେ କରେ।

Product teams କି Web Bot Auth ନିଜେ implement କରିବାକୁ ପଡ଼େ?

Sites signatures verify କରନ୍ତି; ସେମାନେ କିଛି sign କରିବାକୁ ପଡ଼େ ନାହିଁ, ଯେପର୍ଯ୍ୟନ୍ତ ସେମାନେ ମଧ୍ୟ automated clients ଚଳାଉନ୍ତି ନାହାନ୍ତି। Verification ରେ key directories fetch କରିବା, ସେଗୁଡିକୁ ସୁରକ୍ଷିତ ଭାବରେ cache କରିବା ଏବଂ signatures check କରିବା ଲାଗେ, ଯାହା Proof of Actor ପରି ଏକ tool ଆପଣଙ୍କ ପାଇଁ କରିପାରେ।

ଯେ agent ମାନେ ସେମାନଙ୍କ requests sign କରୁନାହାନ୍ତି, ସେମାନଙ୍କ ସହିତ ଆମେ କ'ଣ କରିବା ଉଚିତ?

ଉପଲବ୍ଧ evidence ଅନୁଯାୟୀ ସେମାନଙ୍କୁ ହାତଲ କରନ୍ତୁ: declared, inferred, କିମ୍ବା Unknown। କିଛି ସମୟ ପର୍ଯ୍ୟନ୍ତ signed ଏବଂ unsigned traffic ର ମିଶ୍ରଣ ଆଶା କରନ୍ତୁ, ଏବଂ ଗୋଟିଏ site-wide rule ବଦଳରେ ପ୍ରତ୍ୟେକ route ପାଇଁ fallback ଧାର୍ଯ୍ୟ କରନ୍ତୁ।

Proof of Actor Web Bot Auth କୁ କିପରି ବ୍ୟବହାର କରେ?

ଏହା published key ବିରୁଦ୍ଧରେ HTTP Message Signatures check କରେ ଏବଂ, check ସଫଳ ହେଲେ, result କୁ verified basis ସହିତ ଦେଖାଏ। ପରେ ଆପଣଙ୍କ policies verified agents କୁ declared କିମ୍ବା Unknown traffic ଠାରୁ ଭିନ୍ନ ଭାବେ ହାତଲ କରିପାରିବ।

ଆପଣଙ୍କ app କୁ କିଏ ବ୍ୟବହାର କରୁଛି, ତାହା ଜାଣନ୍ତୁ।

Founding developer ଙ୍କ ଛୋଟ ଦଳ ପାଇଁ private beta।

Early Access ପାଆନ୍ତୁମୂଲ୍ୟ ଦେଖନ୍ତୁ

ପ୍ରଥମେ କଥାହେବାକୁ ପସନ୍ଦ କରନ୍ତି? founderମାନଙ୍କ ସହ କଥାବାର୍ତ୍ତା କରନ୍ତୁ