ପ୍ରମାଣିତ ସ୍ୱୟଂଚାଳନ

ପ୍ରମାଣିତ ସ୍ୱୟଂଚାଳିତ ଅନୁରୋଧଗୁଡ଼ିକୁ ଚିହ୍ନନ୍ତୁ

ଯେତେବେଳେ ଏକ ସ୍ୱୟଂଚାଳିତ କ୍ଲାଏଣ୍ଟ ନିଜ ଅନୁରୋଧଗୁଡ଼ିକୁ ସାଇନ୍ କରେ, ଆପଣଙ୍କ ଆପ୍ଲିକେସନ୍ ସେହି ସିଗ୍ନେଚରକୁ ଯାଞ୍ଚ କରି କଲର୍‌କୁ ଯଥାଯୋଗ୍ୟ ଭାବେ ବ୍ୟବହାର କରିପାରେ। Proof of Actor ସେହି ଯାଞ୍ଚକୁ ସ୍ପଷ୍ଟ, ରୁଟ୍ କରିପାରିବା ଫଳାଫଳରେ ପରିଣତ କରେ।

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

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

ସମସ୍ତ ସ୍ୱୟଂଚାଳିତ ଟ୍ରାଫିକ୍ ଏକରକମ ନୁହେଁ

ସ୍ୱୟଂଚାଳିତ କ୍ଲାଏଣ୍ଟଗୁଡ଼ିକ ପ୍ରତି ମିନିଟ୍‌ରେ ଆପଣଙ୍କ ଆପ୍ଲିକେସନ୍‌କୁ ପହଞ୍ଚନ୍ତି: search crawlers, monitoring tools, partner integrations, ଏକ user ପାଇଁ ପୃଷ୍ଠା ଆଣୁଥିବା AI assistants, ଏବଂ କାର୍ଯ୍ୟ ସମାପ୍ତ କରୁଥିବା autonomous agents। ବର୍ଷଗୁଡ଼ିକ ଧରି, ଅଧିକାଂଶ ଆପ୍ଲିକେସନ୍ ସେମାନଙ୍କୁ ଅଲଗା କରିବାର ଏକମାତ୍ର ଉପାୟ ଥିଲା user-agent header, ଏକ string ଯାହା କୌଣସି କ୍ଲାଏଣ୍ଟ ଯେକୌଣସି ମୂଲ୍ୟରେ ସେଟ୍ କରିପାରେ।

ଏହା application teams ପାଇଁ ଏକ ଦ୍ୱନ୍ଦ୍ୱ ସୃଷ୍ଟି କରେ। ସମସ୍ତ automation କୁ ସନ୍ଦେହର ଚକ୍ଷୁରେ ଦେଖିଲେ, ଆପଣଙ୍କ ଗ୍ରାହକମାନେ ନିର୍ଭର କରୁଥିବା legitimate agents ର ଅନୁଭବ ଖରାପ ହୁଏ। header କୁ ବିଶ୍ୱାସ କଲେ, ଯେକେହି ମଧ୍ୟ ନିଜକୁ ଏକ well-known crawler ବୋଲି କହିପାରିବ।

ପ୍ରମାଣିତ ସ୍ୱୟଂଚାଳିତ ଅନୁରୋଧଗୁଡ଼ିକ ଏହି ପରିସ୍ଥିତିକୁ ବଦଳାଏ। ଯେତେବେଳେ ଏକ ସ୍ୱୟଂଚାଳିତ କ୍ଲାଏଣ୍ଟ ନିଜ ପ୍ରକାଶିତ କି ସହିତ ତାହାର ଅନୁରୋଧଗୁଡ଼ିକୁ ସାଇନ୍ କରେ, ଆପଣଙ୍କ ଆପ୍ଲିକେସନ୍ ସିଗ୍ନେଚରକୁ ଯାଞ୍ଚ କରି କ୍ରିପ୍ଟୋଗ୍ରାଫିକ ଭାବେ ଜାଣିପାରେ କେଉଁ କ୍ଲାଏଣ୍ଟ ଅନୁରୋଧଟି ସାଇନ୍ କଲା। Proof of Actor ସେହି ଯାଞ୍ଚକୁ ଏକମାତ୍ର, ସୁସଙ୍ଗତ actor result ର ଅଂଶ କରେ, ଯାହା ଉପରେ ଆପଣଙ୍କ କୋଡ୍ ରୁଟ୍ କରିପାରେ। ସେହି ଯାଞ୍ଚ କ'ଣ ସ୍ଥାପନ କରେ ଏବଂ କ'ଣ କରେ ନାହିଁ, ତାହାକୁ ନିକଟରୁ ଦେଖିବା ପାଇଁ what signed AI agent requests prove ପଢ଼ନ୍ତୁ।

request signing କେମିତି କାମ କରେ

ସ୍ୱୟଂଚାଳିତ ଟ୍ରାଫିକ୍ ପାଇଁ ଉଦୟମାନ ପ୍ରବନ୍ଧ HTTP message signatures ବ୍ୟବହାର କରେ, ଯାହା RFC 9421 ରେ ସ୍ଟାଣ୍ଡାର୍ଡାଇଜ୍ ହୋଇଛି, ଏବଂ ଯାହା HTTP message ର ଉପାଦାନଗୁଡ଼ିକ ଉପରେ signature କେମିତି ସୃଷ୍ଟି, encode ଏବଂ verify କରିବାକୁ ହୁଏ ତାହା ନିର୍ଦ୍ଦେଶ କରେ। କ୍ଲାଏଣ୍ଟ ପ୍ରତ୍ୟେକ ଅନୁରୋଧର ଚୟନିତ ଅଂଶଗୁଡ଼ିକୁ private key ସହିତ ସାଇନ୍ କରେ ଏବଂ signature ଏବଂ ତାହାର parameters କୁ headers ମଧ୍ୟରେ ରଖେ। ଏହା ସମ୍ବନ୍ଧିତ public key କୁ ତାହା ନିୟନ୍ତ୍ରଣ କରୁଥିବା ଏକ identifier ସହିତ ଯୋଡ଼ାଯାଇଥିବା ସ୍ଥାନରେ ପ୍ରକାଶ କରେ, ସାଧାରଣତଃ ତାହାର domain।

ଅନୁରୋଧ ଆସିଲେ, receiver ପ୍ରକାଶିତ key କୁ fetch କିମ୍ବା lookup କରେ, signed content ପୁନଃନିର୍ମାଣ କରେ, ଏବଂ signature ଯାଞ୍ଚ କରେ। ଯଦି ଏହା validate ହୁଏ, ତେବେ ଅନୁରୋଧଟି ସେହି key ର holder ଦ୍ୱାରା ସାଇନ୍ ହୋଇଥିଲା। ସ୍ୱୟଂଚାଳିତ ଟ୍ରାଫିକ୍ ସାଇନିଂ ଉପରେ କାର୍ଯ୍ୟ IETF Web Bot Auth working group ରେ ଚାଲୁ ଅଛି, ଯାହାର charter ରେ crawlers ଏବଂ end users ପାଇଁ କାର୍ଯ୍ୟ କରୁଥିବା AI agents ଭଳି ସ୍ୱୟଂଚାଳିତ କ୍ଲାଏଣ୍ଟମାନଙ୍କୁ କ୍ରିପ୍ଟୋଗ୍ରାଫିକ ଭାବେ authenticating କରିବା ଅନ୍ତର୍ଭୁକ୍ତ; Web Bot Auth glossary entry ଏହାକୁ ସାରାଂଶ କରେ। what signed AI agent requests prove ଉପରେ blog post ଏକ ପ୍ରମାଣିତ ଅନୁରୋଧକୁ ଆରମ୍ଭରୁ ଶେଷ ପର୍ଯ୍ୟନ୍ତ ଦେଖାଏ, ଏବଂ APIs use case ଯେଉଁଠାରେ verification ପ୍ରଥମେ ଲାଭଦାୟକ ହୁଏ ତାହା ଦେଖାଏ।

verifying signed agent requests ଉପରେ guide timestamps, replay windows ଏବଂ key caching ସହିତ mechanics କୁ ଖୁବ୍ ଭଳି ଭାବରେ କୁହେ।

ଏକ ପ୍ରମାଣିତ ସିଗ୍ନେଚର କ'ଣ ପ୍ରମାଣ କରେ, ଏବଂ କ'ଣ ପ୍ରମାଣ କରେ ନାହିଁ

ପ୍ରମାଣିତ ସ୍ୱୟଂଚାଳିତ ଅନୁରୋଧଗୁଡ଼ିକୁ ଭଲଭାବେ ହାତାହାତି କରିବାରେ ଏହି ଭେଦଟି ସବୁଠାରୁ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ।

ଏକ ସଠିକ ସିଗ୍ନେଚର ପ୍ରମାଣ କରେ ଯେ ଅନୁରୋଧଟି ପ୍ରକାଶିତ identifier ସହିତ ସଂଯୁକ୍ତ ଏକ କି ବ୍ୟବହାର କରି ସାଇନ୍ କରାଯାଇଥିଲା। ଯଦି କିଟି ଅପରେଟର୍‌ଙ୍କ domain ର ହୁଏ, ତେବେ ଅନୁରୋଧଟି ସେହି ଅପରେଟର୍‌ଙ୍କ କି ଧାରଣ କରୁଥିବା କ୍ଲାଏଣ୍ଟରୁ ଆସିଥିଲା।

ଏକ ସଠିକ ସିଗ୍ନେଚର ପ୍ରମାଣ କରେ ନାହିଁ:

କିଏ agent କୁ ନିର୍ଦ୍ଦେଶ ଦେଲା, କିମ୍ବା କୌଣସି ମଣିଷ ଏହି କାର୍ଯ୍ୟ ଚାହିଲେ କି ନାହିଁ;
କୌଣସି ମଣିଷ agent କୁ authority ଡେଲିଗେଟ୍ କଲେ କି ନାହିଁ;
ଅପରେଟର୍‌ଙ୍କ ପଛରେ ଥିବା ପ୍ରକୃତ ଆଇନଗତ ପରିଚୟ;
ଅନୁରୋଧିତ କାର୍ଯ୍ୟଟି ଆପଣଙ୍କ ଆପ୍ଲିକେସନ୍‌ରେ ସୁରକ୍ଷିତ କିମ୍ବା ଅନୁମତିପ୍ରାପ୍ତ କି ନୁହେଁ।

ଏଗୁଡ଼ିକ ଅଲଗା ପ୍ରଶ୍ନ। ଆପଣଙ୍କ ଆପ୍ଲିକେସନ୍ ନିଜ credentials, authorization model ଏବଂ policy ସହିତ ସେଗୁଡ଼ିକୁ ଉତ୍ତର ଦିଏ। Proof of Actor ସେଗୁଡ଼ିକୁ ଇଚ୍ଛାକୃତ ଭାବେ ପୃଥକ ରଖେ, ଏବଂ Detection & Limitations ପୃଷ୍ଠାରେ ପ୍ରତ୍ୟେକ ପ୍ରକାରର evidence କ'ଣ ସ୍ଥାପନ କରିପାରେ ତାହା ସ୍ପଷ୍ଟ କରାଯାଇଛି।

Proof of Actor ପ୍ରମାଣିତ ସ୍ୱୟଂଚାଳିତ ଅନୁରୋଧଗୁଡ଼ିକୁ କେମିତି ହାତଲ କରେ

Detect

ଆପଣଙ୍କ integration ରେ request context, ସିଗ୍ନେଚର headers ସହିତ, Proof of Actor କୁ ପଠାଯାଏ। Signatures ପ୍ରକାଶିତ keys ସହିତ ଯାଞ୍ଚ କରାଯାଏ। validate ହୋଇଥିବା ଅନୁରୋଧଗୁଡ଼ିକୁ verified basis ସହିତ ରେକର୍ଡ କରାଯାଏ। ଯେ କ୍ଲାଏଣ୍ଟଗୁଡ଼ିକ କେବଳ ନିଜକୁ ନାମିତ କରନ୍ତି ସେଗୁଡ଼ିକୁ declared ଭାବେ ରେକର୍ଡ କରାଯାଏ। ବ୍ୟବହାରଗତ pattern ଗୁଡ଼ିକୁ inferred ଭାବେ ରେକର୍ଡ କରାଯାଏ। ଯେତେବେଳେ ପର୍ଯ୍ୟାପ୍ତ ପ୍ରମାଣ ନଥାଏ, ଫଳାଫଳ Unknown ହୁଏ। କୌଣସି କଥାକୁ verified କରାଯାଏ ନାହିଁ ଯଦି କ୍ରିପ୍ଟୋଗ୍ରାଫିକ ଯାଞ୍ଚ ପାସ୍ ହୋଇନଥାଏ।

Understand

କେଉଁ verified operators ଆପଣଙ୍କ ଆପ୍ଲିକେସନ୍‌କୁ କଲ୍ କରନ୍ତି, କେଉଁ routes ସେମାନେ ବ୍ୟବହାର କରନ୍ତି, କେତେଥର, ଏବଂ declared ଏବଂ unknown automation ସହିତ ତାହା କିପରି ତୁଳନା ହୁଏ ଦେଖନ୍ତୁ। ପ୍ରତ୍ୟେକ ଫଳାଫଳର evidence summary ଆପଣଙ୍କ ଟିମ୍‌କୁ କୁହେ କେଉଁ key ଏବଂ identifier ଜଡିତ ଥିଲା, ଯାହା ଦ୍ୱାରା ଟିମ୍ କୌଣସି ଅନୁରୋଧକୁ ଶୀଘ୍ର ତଦନ୍ତ କରିପାରେ।

Route

ଆପଣଙ୍କ policy ମଧ୍ୟରେ basis ବ୍ୟବହାର କରନ୍ତୁ। ସାଧାରଣ pattern ଗୁଡ଼ିକରେ ଅନ୍ତର୍ଭୁକ୍ତ:

read-only route ଗୁଡ଼ିକରେ, ଯଥା API କିମ୍ବା ଏକ ପୃଷ୍ଠାର Markdown version, verified agents କୁ ଏକ structured response ଦିଅନ୍ତୁ।
ଆପଣ ଚିହ୍ନିଥିବା verified operators ପାଇଁ rate limits ବଢ଼ାନ୍ତୁ, declared clients ପାଇଁ standard limits ରଖିଥାଇ।
signature କ'ଣ କହୁଛି ତାହା ସତ୍ତ୍ୱେ, ପ୍ରତ୍ୟେକ write route ରେ ଆପଣଙ୍କ existing authorization ରଖନ୍ତୁ।
ପ୍ରତ୍ୟେକ route ପାଇଁ unsigned ଏବଂ Unknown callers ପାଇଁ ଏକ explicit fallback ନିର୍ଦ୍ଦିଷ୍ଟ କରନ୍ତୁ।

ଆପଣଙ୍କ policies ନିଷ୍ପତ୍ତି କରେ; Proof of Actor evidence ପ୍ରଦାନ କରେ।

user-agent header ପର୍ଯ୍ୟାପ୍ତ କାହିଁକି ନୁହେଁ

User-agent strings ହେଉଛି declarations। କୌଣସି କ୍ଲାଏଣ୍ଟ ଯେକୌଣସି value ପଠାଇପାରେ, ଏବଂ user-agent spoofing କୌଣସି ଦକ୍ଷତା ଚାହିଁନାହିଁ। ସେହିକାରଣରୁ crawler operators ନିଜ ଯାଞ୍ଚଗୁଡ଼ିକ ପ୍ରକାଶ କରନ୍ତି: Google verifying Googlebot ପାଇଁ reverse ଏବଂ forward DNS lookups ଏବଂ published IP ranges ଡକ୍ୟୁମେଣ୍ଟ କରେ, Bing verifying Bingbot ପାଇଁ ଏକ DNS check ଡକ୍ୟୁମେଣ୍ଟ କରେ, ଏବଂ OpenAI ତାହାର crawlers and user agents ପ୍ରତ୍ୟେକ ପାଇଁ IP range files ପ୍ରକାଶ କରେ। Proof of Actor ଏକ user-agent claim କୁ declared evidence ଭାବେ ହାତଲ କରେ, verification ଭାବେ କେବେ ନୁହେଁ। ଏହାର ଅର୍ଥ, ପ୍ରମାଣିତ ସିଗ୍ନେଚର ବିନା ନିଜକୁ well-known crawler ବୋଲି କହୁଥିବା କ୍ଲାଏଣ୍ଟ declared କିମ୍ବା inferred basis ସହିତ ରିପୋର୍ଟ ହୁଏ, ଏବଂ ଆପଣଙ୍କ policy ସେହିକୁ ପ୍ରମାଣିତ ପରିଚୟ ଥିବା କ୍ଲାଏଣ୍ଟରୁ ଭିନ୍ନ ଭାବେ ହାତଲ କରିପାରେ।

ଏହାଇ ପ୍ରମାଣିତ ସ୍ୱୟଂଚାଳିତ ଅନୁରୋଧଗୁଡ଼ିକୁ ମୂଲ୍ୟବାନ କରେ: ସେମାନେ ଆପଣଙ୍କୁ trust କୁ ସେହି କ୍ଲାଏଣ୍ଟମାନଙ୍କ ପର୍ଯ୍ୟନ୍ତ ବିସ୍ତାର କରିବାର ଏକ ନିର୍ଭରଯୋଗ୍ୟ ଉପାୟ ଦିଅନ୍ତି, ଯେଉଁମାନେ ତାହା ଅର୍ଜନ କରିଛନ୍ତି, ତାଙ୍କର header କପି କରୁଥିବା ସମସ୍ତଙ୍କ ପର୍ଯ୍ୟନ୍ତ ନୁହେଁ।

identity evidence, credentials ଏବଂ authorization

ସ୍ୱୟଂଚାଳିତ କ୍ଲାଏଣ୍ଟମାନଙ୍କୁ ସେବା ଦେଉଥିବା କୌଣସି ଆପ୍ଲିକେସନ୍‌ରେ ତିନୋଟି layer ଏକାସାଙ୍ଗରେ କାମ କରେ:

identity evidence: କେଉଁ କ୍ଲାଏଣ୍ଟ ଏହି ଅନୁରୋଧକୁ ସାଇନ୍ କଲା? ପ୍ରମାଣିତ ସିଗ୍ନେଚର ଏହାର ଉତ୍ତର ଦେଉଛି।
credentials: କେଉଁ account ଦାୟୀ? ଆପଣଙ୍କ API key, token କିମ୍ବା session ଉତ୍ତର ଦେଉଛି।
authorization: ଏହି caller ଏହା କରିପାରିବ କି? ଆପଣଙ୍କ permission model ଉତ୍ତର ଦେଉଛି।

Proof of Actor ପ୍ରଥମ layer କୁ ଶକ୍ତିଶାଳୀ କରେ ଏବଂ ଏହାକୁ ଦୃଶ୍ୟମାନ କରେ। ଏହା identity କିମ୍ବା delegation credentials ଜାରି କରେ ନାହିଁ, ଏବଂ ଆପଣଙ୍କ authorization କୁ ପ୍ରତିସ୍ଥାପନ କରେ ନାହିଁ। layer ଗୁଡ଼ିକୁ ପୃଥକ ରଖିବା ଦ୍ୱାରା ଆପଣ low-risk route ଗୁଡ଼ିକରେ verified agents ପ୍ରତି ଉଦାର ଏବଂ high-impact ones ରେ ସାବଧାନ ହୋଇପାରନ୍ତି।

ଏହା କେଉଁଠି ମିଳେ

Proof of Actor ଆପଣଙ୍କ gateway, authentication ଏବଂ rate limiting ସହିତ ପାର୍ଶ୍ୱରେ ରହେ। Integrations server-side middleware ଭାବରେ, edge ରେ, ଆପଣଙ୍କ MCP server ରେ କିମ୍ବା ଏକ generic HTTP integration ମାଧ୍ୟମରେ ଚାଲେ, ପ୍ରତ୍ୟେକ founding team ସହିତ hands-on ଭାବେ ପ୍ରଦାନ କରାଯାଏ। ଯଦି ଆପଣଙ୍କ traffic ପ୍ରଧାନତଃ APIs ଏବଂ tools ଅଟେ, ତେବେ APIs ଏବଂ MCP Servers use case ଗୁଡ଼ିକ ସବୁଠାରୁ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ pattern ଦେଖାଏ।

observation mode ରେ ଆରମ୍ଭ କରନ୍ତୁ

ପ୍ରତ୍ୟେକ integration observation mode ରେ ଆରମ୍ଭ ହୁଏ। ଫଳାଫଳଗୁଡ଼ିକ ଆପଣଙ୍କ ଆପ୍ଲିକେସନ୍ କେମିତି ପ୍ରତିକ୍ରିୟା କରେ ତାହା ବଦଳାନାହିଁ କରି ରେକର୍ଡ ହୁଏ, ଯାହା ଦ୍ୱାରା ଆପଣଙ୍କ ସ୍ୱୟଂଚାଳିତ ଟ୍ରାଫିକ୍‌ର କେତେଟି verified, କେଉଁ operators ସାଇନ୍ କରୁଛନ୍ତି, ଏବଂ unknown rate କେଉଁଠି ସବୁଠାରୁ ଉଚ୍ଚ ତାହା ଦେଖିପାରିବେ। evidence ସେଗୁଡ଼ିକୁ ସମର୍ଥନ କଲେ ପରେ route by route ଭାବରେ policies ଆସେ। How It Works ସମ୍ପୂର୍ଣ୍ଣ flow ଦେଖାଏ।

verification କୁ ନିର୍ଭରଯୋଗ୍ୟ କରୁଥିବା practical details

Signature checking ଚାରିପାଖର ବିବରଣୀ ଯେତେଭଳି ସଠିକ, ତେତେଭଳି ଭଲ। କିଛି practice production ରେ ପ୍ରମାଣିତ ସ୍ୱୟଂଚାଳିତ ଅନୁରୋଧଗୁଡ଼ିକୁ ଭରସାଯୋଗ୍ୟ କରେ।

freshness ଯାଞ୍ଚ କରନ୍ତୁ

RFC 9421 created ଏବଂ expires signature parameters ବ୍ୟାଖ୍ୟା କରେ, ଏବଂ signed requests ସାଧାରଣତଃ ସେଗୁଡ଼ିକ ଧାରଣ କରେ। ଛୋଟ window ବାହାରରେ ଥିବା signature ଗୁଡ଼ିକୁ ଅସ୍ୱୀକାର କରନ୍ତୁ, ଯାହା ଦ୍ୱାରା ଧରାପଡ଼ିଥିବା request ପରେ ପୁନଃବ୍ୟବହାର ହୋଇପାରିବ ନାହିଁ।

keys କୁ ଉଚିତ ଭାବରେ cache କରନ୍ତୁ

ପ୍ରତ୍ୟେକ request ରେ ଅପରେଟର୍‌ଙ୍କ ପ୍ରକାଶିତ key fetch କରିବା latency ବଢ଼ାଇଦିଏ। ସେଗୁଡ଼ିକୁ ଯଥୋଚିତ ସମୟ ପାଇଁ cache କରନ୍ତୁ ଏବଂ signature ଅଜଣା key identifier ସହିତ fail ହେଲେ refresh କରନ୍ତୁ, ଯାହା ଦ୍ୱାରା key rotation ଭୁଲ failure ସୃଷ୍ଟି କରିବ ନାହିଁ।

request ର ସଠିକ ଅଂଶଗୁଡ଼ିକୁ ସାଇନ୍ କରନ୍ତୁ

କେବଳ timestamp କୁ ଢାକିଥିବା signature ବହୁତ କମ୍ ପ୍ରମାଣ କରେ। ନିଶ୍ଚିତ କରନ୍ତୁ ଯେ signed components ମଧ୍ୟରେ method, path ଏବଂ host ଅନ୍ତର୍ଭୁକ୍ତ, ଯାହାଦ୍ୱାରା signature ଆପଣଙ୍କ ଆପ୍ଲିକେସନ୍ ଯେଉଁ request ପ୍ରକୃତରେ ପାଇଛି ତାହା ସହିତ ବନ୍ଧିତ ହୁଏ।

evidence ରେକର୍ଡ କରନ୍ତୁ

ପ୍ରତ୍ୟେକ verified request ସହିତ key identifier, published identifier ଏବଂ result ରଖନ୍ତୁ। କିଛି ଅସାଧାରଣ ଘଟିଲେ, ଆପଣଙ୍କ team ଠିକ୍ କେଉଁ client କଣ ସାଇନ୍ କଲା ଏବଂ କେବେ କଲା ଦେଖିପାରିବ।

Proof of Actor Detect step ର ଅଂଶ ଭାବରେ ଏହି ଯାଞ୍ଚଗୁଡ଼ିକୁ ହାତଲ କରେ ଏବଂ ତାହାର outcome କୁ basis ଭାବରେ ରିପୋର୍ଟ କରେ, ଯାହାକୁ ଆପଣଙ୍କ policies ପଢ଼ିପାରେ, ତେଣୁ ଆପଣଙ୍କ application code ସରଳ ରହେ।

founding developer program ରେ ଯୋଗ ଦିଅନ୍ତୁ

Proof of Actor private beta ରେ ଅଛି। ଚୟନିତ founding development teams agreed usage limits ମଧ୍ୟରେ up to 12 months free access ପାଇପାରନ୍ତି, ଆମ engineers ଠାରୁ ସିଧା integration support ସହିତ।

ଯଦି ସ୍ୱୟଂଚାଳିତ କ୍ଲାଏଣ୍ଟଗୁଡ଼ିକ ଆପଣଙ୍କ ଆପ୍ଲିକେସନ୍‌କୁ ପହଞ୍ଚେ ଏବଂ ଆପଣ verified ones କୁ ଭିନ୍ନ ଭାବେ ହାତଲ କରିବାକୁ ଚାହାଁନ୍ତି, apply for early access। ଆପଣଙ୍କ ଆପ୍ଲିକେସନ୍ ଏବଂ ଦେଖୁଥିବା automated callers ବିଷୟରେ ଆମକୁ କୁହନ୍ତୁ, ଏବଂ Proof of Actor କେମିତି ମିଳେ ଆମେ ଦେଖାଇଦେବୁ।

ସ୍ରୋତଗୁଡ଼ିକ

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.
Verifying Googlebot and other Google crawlers, Google Search Central.
How to verify that Bingbot is Bingbot, Bing Webmaster Blog.
Overview of OpenAI crawlers, OpenAI.

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

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 ପଢନ୍ତୁ

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

ପ୍ରମାଣିତ ସ୍ୱୟଂଚାଳିତ ଅନୁରୋଧ କ'ଣ?

ଏହା ହେଉଛି ଏକ ସ୍ୱୟଂଚାଳିତ କ୍ଲାଏଣ୍ଟର ଅନୁରୋଧ, ଯାହାର କ୍ରିପ୍ଟୋଗ୍ରାଫିକ ସିଗ୍ନେଚର ଏକ ଜଣାଶୁଣା ପରିଚୟକାରୀ, ଯଥା ଅପରେଟର୍‌ଙ୍କ ଡୋମେନ୍, ପାଇଁ ପ୍ରକାଶିତ କି ସହିତ ସତ୍ୟାପିତ ହୁଏ। ଏହା କେଉଁ କ୍ଲାଏଣ୍ଟ ଅନୁରୋଧଟି ସାଇନ୍ କଲା ତାହା ଦେଖାଏ।

ପ୍ରମାଣିତ ସିଗ୍ନେଚର ଅର୍ଥ ଏଜେଣ୍ଟ ଅଧିକୃତ କି?

ନା। ସିଗ୍ନେଚର ଏକ ଅନୁରୋଧକୁ ଏକ କି ଏବଂ ତାହାର ପ୍ରକାଶିତ ପରିଚୟକାରୀ ସହିତ ସମ୍ପର୍କିତ କରେ। ସେହି କ୍ଲାଏଣ୍ଟ କୌଣସି କାର୍ଯ୍ୟ କରିପାରିବ କି ନାହିଁ, ତାହା ଆପଣଙ୍କ ଆପ୍ଲିକେସନ୍‌ର ଏକ ପୃଥକ ଅଧିକାରୀକରଣ ନିଷ୍ପତ୍ତି।

ଯେ ସ୍ୱୟଂଚାଳିତ କ୍ଲାଏଣ୍ଟଗୁଡ଼ିକ ନିଜ ଅନୁରୋଧ ସାଇନ୍ କରନ୍ତି ନାହିଁ, ସେମାନଙ୍କ ବିଷୟରେ କ'ଣ?

Proof of Actor ତଥାପି ସେମାନଙ୍କୁ ବର୍ଗୀକୃତ କରେ, ଉପଲବ୍ଧ ଥିବା ସ୍ଥାନରେ declared ଏବଂ inferred ପ୍ରମାଣ ବ୍ୟବହାର କରି, ଏବଂ ପ୍ରମାଣ ପ୍ରବଳ ନହେଲେ Unknown ଦେଖାଏ। ପ୍ରତ୍ୟେକ ଫଳାଫଳ ତାହାର ଆଧାର ଉଲ୍ଲେଖ କରେ।

ଏକ user-agent string କ'ଣ କ୍ଲାଏଣ୍ଟକୁ ପ୍ରମାଣ କରିପାରେ?

ନା। User-agent strings ସହଜରେ ଅନୁକରଣ କରାଯାଇପାରେ, ତେଣୁ ସେଗୁଡ଼ିକ ଏକ declaration ହିସାବରେ ଗଣାଯାନ୍ତି, verification ନୁହେଁ। କ୍ରିପ୍ଟୋଗ୍ରାଫିକ ସିଗ୍ନେଚରଗୁଡ଼ିକ ହେଉଛି ଯାହା ଏକ ଅନୁରୋଧକୁ ସତ୍ୟାପିତ କରିପାରିବା ଯୋଗ୍ୟ କରେ।

ମୁଁ କେମିତି ଆରମ୍ଭ କରିବି?

ପ୍ରାରମ୍ଭିକ ଆକ୍ସେସ୍ ପାଇଁ ଆବେଦନ କରନ୍ତୁ। Founding teams ଅବଜର୍ଭେସନ୍ ମୋଡ୍‌ରେ ଆରମ୍ଭ କରନ୍ତି ଏବଂ ଚୟନିତ teams ଏକମତ usage limits ମଧ୍ୟରେ up to 12 months free ପାଇପାରନ୍ତି।

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

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

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

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