सत्यापित स्वयंचलन

सत्यापित स्वयंचलित विनंत्या ओळखा

जेव्हा स्वयंचलित क्लायंट आपल्या विनंत्यांवर स्वाक्षरी करतो, तेव्हा तुमचे application ती स्वाक्षरी तपासू शकते आणि कॉल करणाऱ्याला त्यानुसार हाताळू शकते. Proof of Actor ती तपासणी स्पष्ट, मार्गित करता येणाऱ्या परिणामात रूपांतरित करते.

लवकर प्रवेश मिळवा ते कसे कार्य करते ते अन्वेषित करा

लेखक Toshendra Sharmaसंस्थापक आणि CEO, AgentCredia · Updated November 13, 2026

सर्व स्वयंचलित traffic सारखा नसतो

स्वयंचलित client दर मिनिटाला तुमच्या application पर्यंत पोहोचतात: search crawlers, monitoring tools, partner integrations, user साठी pages आणणारे AI assistants, आणि tasks पूर्ण करणारे autonomous agents. अनेक वर्षे, बहुतेक applications त्यांच्यात फरक ओळखण्याचा एकच मार्ग वापरत होत्या - user-agent header, असा string जो कोणताही client काहीही value देऊन सेट करू शकतो.

यामुळे application teams अडचणीत येतात. सर्व automation वर संशय ठेवा, आणि तुमचे customers ज्या legitimate agents वर अवलंबून आहेत त्यांचा अनुभव खराब होतो. Header वर विश्वास ठेवा, आणि कोणीही स्वतःला ओळखीचा crawler म्हणू शकतो.

सत्यापित स्वयंचलित विनंत्या हा समतोल बदलतात. जेव्हा एखादा स्वयंचलित client त्याने प्रकाशित केलेल्या किल्ल्याने आपल्या विनंत्यांवर स्वाक्षरी करतो, तेव्हा तुमचे application ती स्वाक्षरी तपासू शकते आणि cryptographically, कोणत्या client ने विनंतीवर स्वाक्षरी केली ते जाणू शकते. Proof of Actor ही तपासणी तुमच्या code साठी एका एकसंध actor result चा भाग बनवते, ज्यावर route करता येते. ती तपासणी काय सिद्ध करते आणि काय नाही याचा जवळून अभ्यास हवा असल्यास signed AI agent requests prove काय सिद्ध करतात ते वाचा.

request signing कसे काम करते

स्वयंचलित traffic साठी उदयोन्मुख पद्धत HTTP message signatures वापरते, जी RFC 9421 मध्ये प्रमाणित आहे आणि HTTP message च्या components वर signature कशी तयार करायची, encode करायची आणि verify करायची हे ठरवते. client प्रत्येक विनंतीचे निवडक भाग private key ने sign करतो आणि headers मध्ये signature तसेच त्याचे parameters समाविष्ट करतो. तो ज्या identifier वर नियंत्रण ठेवतो त्याच्याशी जोडलेल्या ठिकाणी संबंधित public key प्रकाशित करतो, बहुतेक वेळा आपला domain.

विनंती आली की receiver प्रकाशित key शोधतो किंवा lookup करतो, signed content पुन्हा तयार करतो आणि signature तपासतो. जर ती validate झाली, तर ती विनंती त्या key धारकाने sign केलेली असते. स्वयंचलित traffic signing वरचे काम IETF Web Bot Auth working group मध्ये पुढे चालू आहे, ज्याच्या charter मध्ये crawlers आणि end users साठी काम करणारे AI agents यांसारख्या स्वयंचलित client चे cryptographic authentication समाविष्ट आहे; Web Bot Auth glossary entry त्याचा सारांश देते. signed AI agent requests prove काय सिद्ध करतात ते वाचा हा blog post verified request टप्प्याटप्प्याने स्पष्ट करतो, आणि APIs use case verification कुठे सर्वाधिक फायदा देते ते दाखवतो.

verifying signed agent requests हे guide timestamps, replay windows आणि key caching यांसह mechanics सविस्तरपणे समजावते.

सत्यापित स्वाक्षरी काय सिद्ध करते, आणि काय नाही

सत्यापित स्वयंचलित विनंत्या योग्यरीत्या हाताळताना हा फरक सर्वात महत्त्वाचा आहे.

वैध स्वाक्षरी सिद्ध करते की ही विनंती published identifier शी संबंधित किल्ल्याने sign करण्यात आली होती. जर तो key operator च्या domain चा असेल, तर विनंती त्या operator चा key धरून असलेल्या client कडून आली होती.

वैध स्वाक्षरी हे सिद्ध करत नाही:

agent ला कोणी सूचना दिली, किंवा एखाद्या व्यक्तीने ही क्रिया मागितली का;
एखाद्या व्यक्तीने agent कडे अधिकार सोपवला का;
operator मागची प्रत्यक्ष जगातील कायदेशीर ओळख;
मागितलेली क्रिया तुमच्या application मध्ये सुरक्षित आहे किंवा परवानगीची आहे का.

हे स्वतंत्र प्रश्न आहेत. तुमचे application त्यांची उत्तरे स्वतःच्या credentials, authorization model आणि policy ने देते. Proof of Actor त्यांना मुद्दाम वेगळे ठेवते, आणि Detection & Limitations पान प्रत्येक evidence प्रकार नेमके काय स्थापित करू शकतो ते स्पष्ट करते.

सत्यापित स्वयंचलित विनंत्यांना Proof of Actor कसे हाताळते

Detect

तुमचे integration request context, त्यात कोणतेही signature headers समाविष्ट करून, Proof of Actor कडे पाठवते. Signatures प्रकाशित keys विरुद्ध तपासल्या जातात. ज्या requests validate होतात त्या verified आधारासह नोंदवल्या जातात. ज्या clients फक्त स्वतःला नाव देतात त्यांची नोंद declared म्हणून होते. वर्तनात्मक patterns inferred म्हणून नोंदवले जातात. पुरेसे काही नसल्यास, निकाल Unknown असतो. जोपर्यंत cryptographic तपासणी pass होत नाही, तोपर्यंत काहीही verified म्हणून promote केले जात नाही.

Understand

कोणते verified operators तुमचे application कॉल करतात, कोणते routes वापरतात, किती वेळा वापरतात, आणि ते declared व unknown automation शी कसे तुलना होतात ते पाहा. प्रत्येक निकालावरील evidence summary तुम्हाला कोणता key आणि कोणता identifier सहभागी होता ते सांगते, त्यामुळे तुमची team कोणतीही विनंती पटकन तपासू शकते.

Route

तुमच्या policies मध्ये आधार वापरा. सामान्य patterns मध्ये हे समाविष्ट आहे:

verified agents ना read-only routes वर structured response द्या, जसे API किंवा page ची Markdown आवृत्ती.
ज्या verified operators ना तुम्ही ओळखता त्यांच्यासाठी rate limits वाढवा, पण घोषित clients साठी standard limits ठेवा.
signature काहीही सांगत असला तरी प्रत्येक 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 तसेच 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 नाही. याचा अर्थ वैध स्वाक्षरी नसतानाही स्वतःला ओळखीचा crawler म्हणणारा client declared किंवा inferred आधारासह नोंदवला जातो, आणि तुमची policy त्याच्याशी identity सिद्ध केलेल्या client पेक्षा वेगळे वागू शकते.

म्हणूनच सत्यापित स्वयंचलित विनंत्या मौल्यवान ठरतात: ज्या clients ती कमावतात त्यांच्यापर्यंत trust वाढवण्याचा विश्वासार्ह मार्ग त्या देतात, पण फक्त त्यांचा header कॉपी करणाऱ्या सर्वांपर्यंत नाही.

identity evidence, credentials आणि authorization

स्वयंचलित clients ना सेवा देणाऱ्या कोणत्याही application मध्ये तीन स्तर एकत्र काम करतात:

Identity evidence: ही विनंती कोणत्या client ने sign केली? याचे उत्तर सत्यापित स्वाक्षरी देते.
Credentials: कोणते account जबाबदार आहे? तुमचा API key, token किंवा session याचे उत्तर देतो.
Authorization: हा caller हे करू शकतो का? तुमचे permission model याचे उत्तर देते.

Proof of Actor पहिला स्तर मजबूत करते आणि तो दिसण्याजोगा बनवते. ती identity किंवा delegation credentials जारी करत नाही, आणि तुमचे authorization बदलत नाही. स्तर वेगळे ठेवणेच तुम्हाला कमी जोखमीच्या routes वर verified agents साठी उदार आणि उच्च परिणाम असलेल्या routes वर सावध राहू देते.

हे कुठे बसते

Proof of Actor तुमच्या gateway, authentication आणि rate limiting सोबत काम करते. Integrations server-side middleware म्हणून, edge वर, तुमच्या MCP server मध्ये, किंवा generic HTTP integration द्वारे चालतात, आणि founding team सोबत प्रत्यक्ष मदतीने दिल्या जातात. तुमचा traffic मुख्यतः APIs आणि tools चा असेल, तर APIs आणि MCP Servers use cases सर्वाधिक महत्त्वाचे patterns दाखवतात.

observation mode मध्ये सुरुवात करा

प्रत्येक integration observation mode मध्ये सुरू होते. तुमचे application कसे प्रतिसाद देते ते न बदलता निकाल नोंदवले जातात, त्यामुळे तुमच्या automated traffic पैकी किती verified आहे, कोणते operators sign करत आहेत, आणि unknown rate कुठे सर्वाधिक आहे हे तुम्ही पाहू शकता. Evidence त्यांना पाठिंबा देत असेल तेव्हाच, route नुसार policies नंतर लागू होतात. How It Works संपूर्ण flow समजावते.

verification विश्वासार्ह बनवणारे व्यवहार्य तपशील

Signature checking ची गुणवत्ता आजूबाजूच्या तपशीलांइतकीच असते. काही पद्धती production मध्ये सत्यापित स्वयंचलित विनंत्या विश्वासार्ह ठेवतात.

freshness तपासा

RFC 9421 created आणि expires signature parameters ठरवतो, आणि signed requests बहुतेकदा ते घेऊन येतात. अल्प window बाहेरील signatures नाकाराव्यात, जेणेकरून पकडलेली विनंती नंतर replay करता येणार नाही.

keys शहाणपणाने cache करा

प्रत्येक विनंतीवर operator चे published keys fetch केल्याने latency वाढते. त्यांना वाजवी कालावधीसाठी cache करा आणि unknown key identifier मुळे signature fail झाल्यास refresh करा, जेणेकरून key rotation मुळे खोट्या failures निर्माण होणार नाहीत.

विनंतीचे योग्य भाग sign करा

फक्त timestamp कव्हर करणारी signature फारसे काही सिद्ध करत नाही. Signed components मध्ये method, path आणि host आहेत याची खात्री करा, जेणेकरून signature तुमच्या application ला प्रत्यक्षात मिळालेल्या विनंतीशी जोडली जाईल.

evidence नोंदवा

प्रत्येक verified विनंतीसोबत key identifier, published identifier आणि result ठेवून द्या. काही असामान्य घडल्यास, तुमच्या team ला नेमके कोणत्या client ने काय आणि कधी sign केले ते दिसू शकते.

Proof of Actor या तपासण्या Detect टप्प्याचा भाग म्हणून हाताळते आणि policy वाचू शकेल असा आधार म्हणून परिणाम नोंदवते, त्यामुळे तुमचा 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 सह.

जर स्वयंचलित clients तुमच्या application पर्यंत पोहोचत असतील आणि तुम्हाला verified clients वेगळ्या पद्धतीने हाताळायचे असतील, तर 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: result मागचे signals, जेणेकरून तुमची team कारण पाहू शकेल.

observation mode मध्ये सुरुवात करा: results तुमच्या logs च्या शेजारी नोंदवा आणि तुम्ही policy निवडेपर्यंत काहीही बदलू नका. Node.js integration guide वाचा

वारंवार विचारले जाणारे प्रश्न

सत्यापित स्वयंचलित विनंती म्हणजे काय?

ही अशा स्वयंचलित क्लायंटकडून आलेली विनंती आहे, ज्याची क्रिप्टोग्राफिक स्वाक्षरी ओळखीच्या identifier साठी प्रकाशित केलेल्या किल्ल्याशी जुळून पडताळली जाते, जसे operator चे domain. यात कोणत्या client ने विनंतीवर स्वाक्षरी केली ते दिसते.

सत्यापित स्वाक्षरीचा अर्थ agent अधिकृत आहे असा होतो का?

नाही. स्वाक्षरी विनंतीला एका किल्ल्याशी आणि त्याच्या प्रकाशित identifier शी जोडते. त्या client ला एखादी क्रिया करण्याची परवानगी आहे की नाही, हा तुमच्या application ने घेतलेला वेगळा authorization निर्णय असतो.

जे स्वयंचलित client आपल्या विनंत्यांवर स्वाक्षरी करत नाहीत त्यांचे काय?

Proof of Actor तरीही त्यांचे वर्गीकरण करते, उपलब्ध असलेल्या declared आणि inferred evidence वापरून, आणि evidence पुरेसा मजबूत नसल्यास Unknown नोंदवते. प्रत्येक निकाल त्याचा आधार सांगतो.

user-agent string client ची पडताळणी करू शकते का?

नाही. User-agent strings सहज नक्कल करता येतात, त्यामुळे त्या declaration मानल्या जातात, verification नाही. क्रिप्टोग्राफिक स्वाक्षऱ्या हीच विनंती पडताळण्याजोगी बनवतात.

मी सुरुवात कशी करू?

early access साठी अर्ज करा. Founding teams observation mode मध्ये सुरुवात करतात आणि निवडलेल्या teams ना agreed usage limits अंतर्गत up to 12 months free मिळू शकतात.

तुमचे app कोण वापरत आहे ते जाणून घ्या.

founding developers च्या छोट्या गटासाठी private beta.

लवकर प्रवेश मिळवा किमती पहा

आधी बोलणे पसंत आहे? founders शी बोला