ચકાસાયેલ સ્વચાલિકતા

ચકાસાયેલ સ્વચાલિત વિનંતીઓને ઓળખો

જ્યારે કોઈ સ્વચાલિત ક્લાયંટ તેની વિનંતીઓ પર હસ્તાક્ષર કરે છે, ત્યારે તમારું એપ્લિકેશન તે હસ્તાક્ષરને ચકાસી શકે છે અને કોલરને તે મુજબ સંભાળી શકે છે. Proof of Actor એ ચકાસણીને સ્પષ્ટ, માર્ગિત કરી શકાય તેવા પરિણામમાં રૂપાંતરિત કરે છે.

પ્રારંભિક ઍક્સેસ મેળવો તે કેવી રીતે કાર્ય કરે છે તે અન્વેષણ કરો

દ્વારા Toshendra Sharmaસ્થાપક અને CEO, AgentCredia · Updated November 13, 2026

બધી સ્વચાલિત traffic એક જેવી નથી

સ્વચાલિત clients દર મિનિટે તમારી application સુધી પહોંચે છે: search crawlers, monitoring tools, partner integrations, user માટે પેજ લાવતાં AI assistants, અને tasks પૂરાં કરતા autonomous agents. વર્ષો સુધી, મોટાભાગની applications તેમને અલગ પાડવાનો એકમાત્ર રસ્તો user-agent header હતો, જે કોઈપણ client કંઈપણ મૂલ્યથી સેટ કરી શકે એવો string છે.

આ application teamsને મુશ્કેલીમાં મૂકે છે. બધી automation પર શંકા રાખો અને તમે તમારા customers આધાર રાખે છે એવા legitimate agentsનો અનુભવ ખરાબ કરો. header પર વિશ્વાસ કરો અને તમે કોઈપણને જાણીતા crawler હોવાનો દાવો કરવાની તક આપો.

ચકાસાયેલ સ્વચાલિત વિનંતીઓ આ સમીકરણ બદલે છે. જ્યારે કોઈ સ્વચાલિત client પોતાની વિનંતીઓ પર તે પ્રકાશિત કરેલી keyથી હસ્તાક્ષર કરે છે, ત્યારે તમારું application હસ્તાક્ષર ચકાસી શકે છે અને ક્રિપ્ટોગ્રાફિક રીતે જાણી શકે છે કે કયા clientએ વિનંતી પર હસ્તાક્ષર કર્યું. Proof of Actor તે ચકાસણીને એક જ, સુસંગત actor પરિણામનો ભાગ બનાવે છે, જેના આધારે તમારો code route કરી શકે. તે ચકાસણી શું સ્થાપિત કરે છે અને શું નથી કરતી, તેની નજીકથી સમજ માટે signed AI agent requests શું સાબિત કરે છે વાંચો.

request signing કેવી રીતે કામ કરે છે

સ્વચાલિત traffic માટે ઉદભવતી પદ્ધતિ HTTP message signatures નો ઉપયોગ કરે છે, જે RFC 9421 માં standardize કરવામાં આવ્યું છે અને જે HTTP messageના ઘટકો પર હસ્તાક્ષર કેવી રીતે બનાવવું, encode કરવું અને verify કરવું તે વ્યાખ્યાયિત કરે છે. client દરેક વિનંતીના પસંદ કરેલા ભાગો પર private keyથી હસ્તાક્ષર કરે છે અને headersમાં હસ્તાક્ષર અને તેના parameters સામેલ કરે છે. તે સંબંધિત public keyને તે નિયંત્રિત identifier સાથે જોડાયેલી જગ્યાએ પ્રકાશિત કરે છે, સામાન્ય રીતે તેનું domain.

જ્યારે વિનંતી આવે છે, ત્યારે receiver પ્રકાશિત key fetch કરે છે અથવા lookup કરે છે, હસ્તાક્ષર કરાયેલ content પુનઃરચના કરે છે, અને હસ્તાક્ષર ચકાસે છે. જો તે validate થાય, તો વિનંતી તે keyના ધારક દ્વારા હસ્તાક્ષરિત હતી. સ્વચાલિત traffic પર હસ્તાક્ષર સંબંધિત કામ IETF Web Bot Auth working group માં આગળ વધે છે, જેના charterમાં crawlers અને end users માટે કાર્ય કરતા AI agents જેવા સ્વચાલિત clientsની ક્રિપ્ટોગ્રાફિક authentication આવરી લેવાઈ છે; Web Bot Auth glossary entry તેનું સારાંશ આપે છે. signed AI agent requests શું સાબિત કરે છે પરનો blog post verified requestને અંતથી અંત સુધી સમજાવે છે, અને APIs use case બતાવે છે કે verification ક્યાં સૌથી પહેલા લાભ આપે છે.

verifying signed agent requests માર્ગદર્શિકા timestamps, replay windows અને key caching સહિતની mechanicsને વિગતે આવરી લે છે.

ચકાસાયેલ હસ્તાક્ષર શું સાબિત કરે છે, અને શું નથી સાબિત કરતું

ચકાસાયેલ સ્વચાલિત વિનંતીઓને સારી રીતે સંભાળવાનો સૌથી મહત્વનો ભાગ આ ભેદ છે.

માન્ય હસ્તાક્ષર સાબિત કરે છે કે વિનંતી પ્રકાશિત identifier સાથે જોડાયેલી keyથી હસ્તાક્ષરિત હતી. જો key કોઈ operatorના domainની હોય, તો વિનંતી તે operatorની key ધરાવતા client પાસેથી આવી હતી.

માન્ય હસ્તાક્ષર સાબિત કરતું નથી:

એજન્ટને કોણે સૂચના આપી, અથવા કોઈ વ્યક્તિએ આ ક્રિયા માગી હતી કે નહીં;
કોઈ વ્યક્તિએ એજન્ટને અધિકાર સોંપ્યો હતો કે નહીં;
operator પાછળની વાસ્તવિક કાનૂની ઓળખ;
વિનંતી કરેલી ક્રિયા તમારી applicationમાં સલામત છે કે મંજૂર છે કે નહીં.

આ અલગ પ્રશ્નો છે. તમારી application પોતાના credentials, authorization model અને policy દ્વારા તેમને જવાબ આપે છે. Proof of Actor તેમને જાણીજોઈને અલગ રાખે છે, અને Detection & Limitations પૃષ્ઠ સ્પષ્ટ કરે છે કે દરેક પ્રકારનું evidence શું સ્થાપિત કરી શકે છે.

ચકાસાયેલ સ્વચાલિત વિનંતીઓને Proof of Actor કેવી રીતે સંભાળે છે

Detect

તમારી integration વિનંતીનો context, જેમાં કોઈપણ signature headers શામેલ હોય, Proof of Actorને મોકલે છે. signatures પ્રકાશિત keys સામે ચકાસવામાં આવે છે. જે વિનંતીઓ માન્ય થાય છે તે ચકાસાયેલ આધાર સાથે નોંધાય છે. જે clients માત્ર પોતાને નામ આપે છે તે ઘોષિત તરીકે નોંધાય છે. વર્તણૂકી patterns અનુમાનિત તરીકે નોંધાય છે. જો આગળ વધવા માટે પૂરતું ન હોય, તો પરિણામ Unknown હોય છે. જો cryptographic check પસાર ન થયો હોય તો કંઈપણ verified તરીકે promote થતું નથી.

Understand

કયા ચકાસાયેલ operators તમારી applicationને call કરે છે, તેઓ કયા routes વાપરે છે, કેટલી વાર વાપરે છે, અને તે declared અને unknown automationની તુલનામાં કેવું છે તે જુઓ. દરેક પરિણામ પરનો evidence summary તમને બતાવે છે કે કઈ key અને identifier સામેલ હતાં, જેથી તમારી ટીમ કોઈપણ વિનંતીની ઝડપથી તપાસ કરી શકે.

Route

તમારી policiesમાં આ આધારનો ઉપયોગ કરો. સામાન્ય patternsમાં સમાવિષ્ટ છે:

verified agentsને read-only routes પર રચિત response આપો, જેમ કે API અથવા પૃષ્ઠનું Markdown version.
તમે ઓળખો છો એવા verified operators માટે rate limits વધારો, જ્યારે declared clients માટે standard limits જાળવો.
હસ્તાક્ષર શું કહે છે તે છતાં, દરેક write route પર તમારી હાલની authorization જ રાખો.
દરેક route પર unsigned અને Unknown callers માટે સ્પષ્ટ fallback વ્યાખ્યાયિત કરો.

તમારી policies નિર્ણય લે છે; Proof of Actor evidence પૂરૂં પાડે છે.

user-agent header પૂરતો કેમ નથી

User-agent strings declarations છે. કોઈપણ client કોઈપણ value મોકલી શકે છે, અને user-agent spoofing માટે કોઈ ખાસ કુશળતા જરૂરી નથી. એટલા માટે crawler operators પોતાના checks પ્રકાશિત કરે છે: Google verifying Googlebot માટે reverse અને forward DNS lookups તથા પ્રકાશિત IP ranges દસ્તાવેજિત કરે છે, Bing verifying Bingbot માટે DNS check દસ્તાવેજિત કરે છે, અને OpenAI તેના crawlers and user agents માટે IP range files પ્રકાશિત કરે છે. Proof of Actor user-agent claimને declared evidence તરીકે જ લે છે, કદી verification તરીકે નહીં. તેનો અર્થ એ છે કે valid signature વગર પોતાને જાણીતા crawler તરીકે રજૂ કરતો client declared અથવા inferred આધાર સાથે રિપોર્ટ થાય છે, અને તમારી policy તેને એવી clientથી અલગ રીતે સંભાળી શકે છે જેણે પોતાની ઓળખ સાબિત કરી હોય.

ચકાસાયેલ સ્વચાલિત વિનંતીઓ મૂલ્યવાન બનાવે છે તે આ જ છે: તે તમને વિશ્વાસ ત્યાં વિસ્તરાવવા માટે વિશ્વસનીય રીત આપે છે જ્યાં clients તે કમાય, દરેક એવા client સુધી નહીં જે તેમનું header નકલ કરે.

ઓળખ પુરાવા, credentials અને authorization

કોઈપણ applicationમાં જે સ્વચાલિત clientsને સેવા આપે છે, ત્રણ સ્તરો સાથે કામ કરે છે:

ઓળખ પુરાવો: આ વિનંતી પર કોણે હસ્તાક્ષર કર્યું? આને ચકાસાયેલ હસ્તાક્ષર જવાબ આપે છે.
Credentials: કયા account માટે જવાબદારી છે? તમારું API key, token અથવા session જવાબ આપે છે.
Authorization: શું આ caller આ કરી શકે? તમારું permission model જવાબ આપે છે.

Proof of Actor પ્રથમ સ્તરને મજબૂત કરે છે અને તેને દૃશ્યમાન બનાવે છે. તે ઓળખ અથવા delegation credentials જારી કરતું નથી, અને તમારી authorizationને બદલે પણ નથી. સ્તરોને અલગ રાખવાથી તમે low-risk routes પર 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 cases સૌથી મહત્વના patterns બતાવે છે.

observation modeમાં શરૂઆત કરો

દરેક integration observation modeથી શરૂ થાય છે. પરિણામો તમારી application કેવી રીતે respond કરે છે તે બદલ્યા વિના નોંધાય છે, જેથી તમે જોઈ શકો કે તમારા સ્વચાલિત trafficનો કેટલો ભાગ verified છે, કયા operators sign કરી રહ્યા છે, અને ક્યાં unknown rate સૌથી ઊંચો છે. Policies પછી આવે છે, route પ્રમાણે route, જ્યારે evidence તેમને સમર્થન આપે છે. How It Works સંપૂર્ણ flow સમજાવે છે.

verificationને વિશ્વસનીય બનાવતી વ્યાવહારિક વિગતો

Signature checking માત્ર તેની આસપાસની વિગતો જેટલું જ સારું છે. થોડા practices ચકાસાયેલ સ્વચાલિત વિનંતીઓને productionમાં વિશ્વસનીય બનાવે છે.

freshness તપાસો

RFC 9421 created અને expires signature parameters વ્યાખ્યાયિત કરે છે, અને signed requests સામાન્ય રીતે તેમને ધરાવે છે. ટૂંકા windowની બહારના signatures નકારી દો, જેથી પકડાયેલી વિનંતી પછીથી replay ન થઈ શકે.

keysને સમજદારીથી cache કરો

દરેક વિનંતી પર operatorની પ્રકાશિત keys fetch કરવાથી latency વધે છે. તેમને યોગ્ય સમયગાળા માટે cache કરો અને જ્યારે કોઈ signature અજાણ્યા key identifier સાથે નિષ્ફળ જાય ત્યારે refresh કરો, જેથી key rotation ખોટી નિષ્ફળતાઓનું કારણ ન બને.

વિનંતીના યોગ્ય ભાગો પર હસ્તાક્ષર કરો

માત્ર timestampને આવરી લેતું signature બહુ ઓછું સાબિત કરે છે. ખાતરી કરો કે signed componentsમાં method, path અને host શામેલ છે, જેથી signature તે વિનંતી સાથે બંધાય જે ખરેખર તમારી applicationને મળી.

evidence નોંધો

દરેક verified વિનંતી સાથે key identifier, પ્રકાશિત identifier અને પરિણામ રાખો. કંઈક અસામાન્ય બન્યું ત્યારે, તમારી ટીમ ચોક્કસ જોઈ શકે કે કયા clientે શું અને ક્યારે sign કર્યું.

Proof of Actor આ checksને Detect પગથિયાના ભાગ રૂપે સંભાળે છે અને પરિણામને એવા આધાર તરીકે રિપોર્ટ કરે છે જેને તમારી policies વાંચી શકે, જેથી તમારા application code સાદું રહે.

founding developer programમાં જોડાઓ

Proof of Actor private betaમાં છે. પસંદ કરેલી founding development teamsને સંમત usage limitsની અંદર 12 months of free access અને અમારા engineers તરફથી direct integration support મળી શકે છે.

જો સ્વચાલિત clients તમારી application સુધી પહોંચે છે અને તમે verified onesને અલગ રીતે સંભાળવા માંગો છો, તો early access માટે અરજી કરો. તમારી application અને તમે જોતા સ્વચાલિત callers વિશે અમને જણાવો, અને અમે બતાવશું કે Proof of Actor ક્યાં બંધબેસે છે.

Sources

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: પરિણામ પાછળના signals, જેથી તમારી team કારણ જોઈ શકે.

observation mode માં શરૂ કરો: પરિણામોને તમારા logsની બાજુમાં નોંધો અને તમે policy પસંદ કરો ત્યાં સુધી કંઈ બદલશો નહીં. Node.js integration guide વાંચો

વારંવાર પૂછાતા પ્રશ્નો

ચકાસાયેલ સ્વચાલિત વિનંતી શું છે?

આ એવી વિનંતી છે જે સ્વચાલિત ક્લાયંટ તરફથી આવે છે અને જેનું ક્રિપ્ટોગ્રાફિક હસ્તાક્ષર જાણીતા ઓળખચિહ્ન, જેમ કે સંચાલકના ડોમેન, માટે પ્રકાશિત કી સામે માન્ય થાય છે. તે બતાવે છે કે કઈ ક્લાયંટે વિનંતી પર હસ્તાક્ષર કર્યું.

શું ચકાસાયેલ હસ્તાક્ષરનો અર્થ એ છે કે એજન્ટ અધિકૃત છે?

ના. હસ્તાક્ષર વિનંતીને કી અને તેના પ્રકાશિત ઓળખચિહ્ન સાથે જોડે છે. તે ક્લાયંટ કોઈ ક્રિયા કરી શકે છે કે નહીં, તે તમારી એપ્લિકેશન દ્વારા લેવાયેલ અલગ અધિકૃતતા નિર્ણય છે.

જે સ્વચાલિત ક્લાયંટ તેમની વિનંતીઓ પર હસ્તાક્ષર કરતા નથી, તેમનું શું?

Proof of Actor હજી પણ તેમને વર્ગીકૃત કરે છે, જ્યાં ઉપલબ્ધ હોય ત્યાં declared અને inferred પુરાવાનો ઉપયોગ કરીને, અને પુરાવો પૂરતો મજબૂત ન હોય ત્યારે Unknown દર્શાવે છે. દરેક પરિણામ તેનો આધાર જણાવે છે.

શું user-agent string ક્લાયંટને ચકાસી શકે છે?

ના. user-agent string નકલ કરવા સરળ છે, તેથી તે verification નહીં, declaration ગણાય છે. ક્રિપ્ટોગ્રાફિક હસ્તાક્ષર જ વિનંતીને ચકાસી શકાય એવી બનાવે છે.

હું શરૂઆત કેવી રીતે કરું?

વહેલી ઍક્સેસ માટે અરજી કરો. Founding ટીમો observation modeમાં શરૂ કરે છે અને પસંદ કરેલી ટીમોને સંમત ઉપયોગ મર્યાદાઓ હેઠળ 12 months free મળી શકે છે.

તમારા app નો ઉપયોગ કોણ કરે છે તે જાણો.

Founding developers ના નાના સમૂહ માટે private beta.

પ્રારંભિક ઍક્સેસ મેળવો કિંમત જુઓ

પહેલાં વાત કરવી પસંદ કરો છો? સ્થાપકો સાથે વાત કરો