AI एजेंट पहचान

API के लिए AI एजेंट पहचान

आपका API पहले से जानता है कि किस key ने अनुरोध किया। Proof of Actor आपको बताता है कि उसके पीछे किस प्रकार का actor था, उस परिणाम का कौन सा प्रमाण समर्थन करता है, और आपके code को यह तय करने देता है कि आगे क्या होगा।

Early Access प्राप्त करें यह कैसे काम करता है, देखें

द्वारा Toshendra Sharmaसंस्थापक और CEO, AgentCredia · Updated November 13, 2026

आपका API key जानता है। actor नहीं जानता।

हर API request के साथ इस बात का कुछ प्रमाण आता है कि उसका भुगतान कौन कर रहा है: एक API key, एक OAuth token, एक session. यह प्रमाण एक प्रश्न का अच्छा उत्तर देता है। यह बताता है कि कॉल के लिए कौन सा account जिम्मेदार है। यह नहीं बताता कि इस समय वास्तव में कॉल क्या कर रहा है।

एक ही API key का उपयोग terminal में परीक्षण कर रहे developer, schedule पर चल रहे backend job, AI assistant के माध्यम से काम कर रहे व्यक्ति, और ऐसे autonomous agent द्वारा किया जा सकता है जिसे key दी गई हो और task पूरा करने को कहा गया हो। ये सभी बहुत अलग actors हैं। उनकी गति अलग है, failure modes अलग हैं, और risk profiles अलग हैं। इन्हें एक ही तरह से treat करने का मतलब है कि आप या तो अपने ग्राहकों द्वारा भरोसा की जाने वाली legitimate automation को जरूरत से ज्यादा restrict करेंगे, या अपने API के उन हिस्सों की पर्याप्त सुरक्षा नहीं करेंगे जिन्हें कभी भी unattended agent द्वारा drive नहीं किया जाना चाहिए।

API के लिए AI agent पहचान इस अंतर को बंद करती है। key से सब कुछ infer करने के बजाय, आपको हर request के पीछे वाले actor की classification मिलती है, साथ ही उस classification का समर्थन करने वाला evidence भी। यही वह चीज है जिसे Proof of Actor deliver करने के लिए बनाया गया है, और APIs use case दिखाता है कि API teams इसे route by route कैसे लागू करती हैं।

API teams को अभी actor context की जरूरत क्यों है

API पर automated traffic नया नहीं है। scripts, integrations और crawlers हमेशा से इसका हिस्सा रहे हैं। जो बदला है वह automation का प्रकार है। AI agents documentation पढ़ सकते हैं, calls को chain कर सकते हैं, creatively retry कर सकते हैं, और उन लोगों की ओर से कार्य कर सकते हैं जो हर step नहीं देख रहे होते। उनमें से कई उपयोगी और स्वागत योग्य हैं। कुछ poorly built हैं। कुछ hostile हैं।

Actor context के बिना, API teams अक्सर blunt tools पर लौटती हैं:

प्रति key rate limits, जो अच्छे agents और बुरे agents दोनों को समान रूप से धीमा करती हैं।
User-agent rules, जो client द्वारा header बदलते ही टूट जाती हैं।
व्यापक blocks, जो legitimate automation को आपकी web app को scrape करने के लिए धकेल देते हैं।

Actor context आपको सटीकता के साथ जवाब देने देता है। किसी operator का signed agent जिसे आप पहचानते हैं, उसे read routes पर अधिक limit मिल सकती है। write route hit करने वाले unknown caller से stronger credential मांगा जा सकता है। AI assistant का उपयोग कर रहा human सामान्य अनुभव बनाए रख सकता है। उद्देश्य agents को रोकना नहीं है। उद्देश्य हर प्रकार के caller को सही path देना है। Signed request क्या बता सकता है और क्या नहीं, इसके लिए signed AI agent requests क्या साबित करते हैं पढ़ें।

Proof of Actor में AI agent पहचान कैसे काम करती है

Proof of Actor हर request के लिए वही evidence-first flow अपनाता है। पूरा walkthrough आप How It Works पर पढ़ सकते हैं; यहां API teams के लिए संक्षिप्त संस्करण है।

1. आपके integration से signals

आपका integration उस context में उपलब्ध signals Proof of Actor को भेजता है। API के लिए, इसका अर्थ आम तौर पर request context जैसे headers और protocol details, client द्वारा दिए गए कोई cryptographic request signatures, और client द्वारा अपने बारे में की गई कोई declarations होता है। हर signal को उसके स्रोत के साथ label किया जाता है।

2. आधार के साथ classification

Signals की जांच और संयोजन करके उन्हें चार public classes में से एक में रखा जाता है:

Human: दिखाई देने वाले signals human-directed interaction का संकेत देते हैं।
Human + AI: AI सहायता घोषित की गई थी या ऐसे integration द्वारा detect की गई थी जो उसे observe कर सकता है।
Agent: automated या agent-origin traffic, जो verifiable identity या सावधानी से qualified inference द्वारा समर्थित है।
Unknown: evidence विश्वसनीय determination का समर्थन नहीं करता।

हर result के साथ उसका आधार भी आता है: verified, declared, inferred या unknown. API teams के लिए यही सबसे मूल्यवान हिस्सा है। एक request जिसका HTTP message signature, जैसा कि RFC 9421 में परिभाषित है, published key के विरुद्ध validate होता है, उसे verified के रूप में report किया जाता है। एक client जो खुद को बस agent कहता है, उसे declared के रूप में report किया जाता है। जो pattern automated लगता है, उसे inferred के रूप में report किया जाता है। आपको कभी यह सोचने की जरूरत नहीं होती कि परिणाम cryptography पर आधारित है या heuristic पर। evidence basis उत्तर का हिस्सा है।

3. ऐसा result जिस पर आपका code action ले सके

Result आपके application को class, basis और readable evidence summary के साथ वापस मिलता है। आपका code तय करता है कि उसके साथ क्या करना है। Observation mode में, आप बस इसे record करते हैं। जब आप तैयार हों, आप इसके आधार पर route करते हैं।

आपकी team को क्या मिलता है: Detect, Understand, Route

Proof of Actor एक product है जिसमें तीन capabilities हैं।

Detect

अपने API द्वारा देखे जा सकने वाले actor signals इकट्ठा करें और verified assertions को behavioural inferences से अलग करें। Signed agent requests, declared clients, automation signals और Unknown results सभी अलग रखे जाते हैं, ताकि कुछ भी चुपचाप एक single score में न मिल जाए।

Understand

देखें कि कौन से actors किन routes को call करते हैं, समय के साथ यह कैसे बदलता है, और हर classification के पीछे कौन सा evidence है। Unknown rate visible रहती है, जिससे आपको साफ पता चलता है कि आपकी coverage कहां खत्म होती है और कहां stronger signal मदद करेगा।

Route

हर route और हर risk tier के लिए policies लिखें: allow, adapt, challenge, review या rate-limit। verified agents के लिए read-only endpoints पर एक structured, generous path रखें। high-impact operations पर stronger credentials मांगें। Unknown और timeouts के लिए एक explicit fallback परिभाषित करें, ताकि आपका API जो भी हो, predictably behave करे। आप तय करते हैं कि हर policy कैसे fail होती है, open या closed, इस route पर गलती की लागत के आधार पर।

Identity evidence, credentials और authorization तीन अलग चीजें हैं

Agent-aware API design में सबसे आम गलती तीन अलग questions को एक में मिला देना है। Proof of Actor इन्हें अलग रखता है, और आपका design भी ऐसा ही होना चाहिए।

Identity evidence: कौन सा actor call कर रहा है, और यह क्या साबित करता है? यही AI agent पहचान देती है। एक verified signature request को एक key और उसके published operator identifier से जोड़ता है। IETF Web Bot Auth working group को automated clients के लिए इस तरह की cryptographic authentication standardize करने का charter दिया गया है, और इसका scope end user के बजाय agent को authenticate करने को शामिल करता है।
Credentials: इस call के लिए कौन सा account जिम्मेदार है? यह आपका API key, token या session है, जिसे आप issue और manage करते हैं।
Authorization: क्या यह caller यह specific काम करने की अनुमति रखता है? यह आपका permission model है।

Verified agent automatically authorized agent नहीं होता। Valid signature यह साबित नहीं करता कि किसी person ने agent को authority delegate की थी, और यह requested action को safe भी नहीं बनाता। Proof of Actor आपको पहले प्रश्न के लिए भरोसेमंद context देता है और दूसरे तथा तीसरे को ठीक वहीं छोड़ देता है जहां वे होने चाहिए: आपके application में। agent authorization और Detection & Limitations पर जाएं कि evidence क्या स्थापित कर सकता है और क्या नहीं।

Unknown कोई failure नहीं, एक feature है

Request signing optional है, और unsigned client अपने बारे में जैसा चाहे वैसा वर्णन कर सकता है। जो system हर request को Human या Agent में force करता है, वह कुछ समय confidently wrong होगा, और आपको पता भी नहीं चलेगा कि कब।

जब evidence किसी determination का समर्थन नहीं करता, तब Proof of Actor Unknown report करता है। Unknown को कभी Human में convert नहीं किया जाता, और default रूप से कभी malicious नहीं माना जाता। आपकी policy तय करती है कि हर route के लिए Unknown का क्या अर्थ है: public reads पर अनुमति दें, account changes पर अपने existing checks बनाए रखें, जहां stakes ऊंचे हैं वहां इसे review के लिए queue करें। Unknown को visible रखना ही आपकी अन्य classifications को trustworthy बनाता है। handling unknown traffic पर guide दिखाता है कि इसके लिए design कैसे करें।

आपकी stack में AI agent पहचान कहां फिट होती है

Proof of Actor आपके existing gateway, authentication और rate limiting के साथ बैठता है। यह इनमें से किसी को replace नहीं करता। सामान्य placements में शामिल हैं:

Server-side middleware आपके route handlers के सामने, ताकि आपका business logic चलने से पहले हर request evaluate हो जाए।
At the edge, ताकि requests आपके origin तक पहुंचने से पहले signals evaluate हो जाएं।
एक generic HTTP integration, ताकि कोई भी stack request context भेज सके और उसका basis के साथ result प्राप्त कर सके।

Integrations onboarding के दौरान हर founding team के साथ hands-on deliver की जाती हैं, इसलिए path आपकी architecture से मेल खाता है, उल्टा नहीं। developer hub आज उपलब्ध integration paths दिखाता है। यदि आप agents के लिए tools चलाते हैं, तो MCP Servers use case tool calls के विशिष्ट patterns को कवर करता है।

Observation mode में शुरू करें

Proof of Actor install करने से आपका API जवाब देने का तरीका नहीं बदलता। Results record किए जाते हैं ताकि आपकी team उन्हें उन outcomes से compare कर सके जिन्हें आप पहले से जानते हैं, देख सके कि agents वास्तव में कहां जाते हैं, हर route पर unknown rate माप सके, और किसी भी classification की समीक्षा कर सके जो गलत लगती है। इसके बाद ही आप route by route कोई policy enable करते हैं, जहां evidence उसका समर्थन करता है।

इसी तरह आप AI agent पहचान को इस तरह roll out करते हैं कि आपके customers को surprise न हो और उनके भरोसे की integrations न टूटें। rolling out actor-aware policies safely पर guide step by step sequence बताती है।

Founding developer program से जुड़ें

Proof of Actor private beta में कुछ founding development teams के छोटे समूह के साथ है। चुनी गई teams onboarding के दौरान agreed usage limits के भीतर up to 12 months free access प्राप्त कर सकती हैं, साथ ही हमारे engineers से direct integration support और हम आगे क्या बनाते हैं उस पर वास्तविक प्रभाव भी।

यदि आप कोई API चलाते हैं और जानना चाहते हैं कि उसे वास्तव में कौन call कर रहा है, तो early access के लिए apply करें. हमें अपने API, उन routes के बारे में बताएं जिनकी आपको सबसे अधिक परवाह है, और उन decisions के बारे में बताएं जो आप actor context के साथ अलग तरीके से लेते। हम आपको बताएंगे कि Proof of Actor कैसे fit बैठता है।

Sources

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.

डेवलपर्स के लिए

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 के पास record करें और जब तक आप कोई policy न चुनें, कुछ न बदलें। Node.js integration guide पढ़ें

अक्सर पूछे जाने वाले प्रश्न

AI agent पहचान API key authentication से कैसे अलग है?

एक API key आपको बताती है कि किस account ने अनुरोध भेजा। AI agent पहचान आपको बताती है कि उस अनुरोध के पीछे किस प्रकार का actor है और उस निष्कर्ष का कौन सा प्रमाण समर्थन करता है। आपको दोनों की जरूरत है, और वे अलग प्रश्नों के उत्तर देते हैं।

क्या Proof of Actor मेरे API को कॉल करने वाले हर AI agent की पहचान कर सकता है?

Proof of Actor अपने द्वारा देखे गए हर अनुरोध को Human, Human + AI, Agent या Unknown के रूप में वर्गीकृत करता है, और हर परिणाम के लिए उसका आधार बताता है। जब प्रमाण पर्याप्त मजबूत नहीं होता, तो परिणाम अनुमान के बजाय Unknown होता है।

क्या किसी agent की पहचान का मतलब है कि उसे कार्य करने की अनुमति है?

नहीं। पहचान और authorization अलग हैं। Proof of Actor आपके application को कॉलर के बारे में संदर्भ देता है, और आपके अपने authorization rules तय करते हैं कि वह कॉलर क्या कर सकता है।

क्या Proof of Actor मेरे API पर अनुरोधों को block करेगा?

नहीं, जब तक आप ऐसा नहीं तय करते। हर integration observation mode में शुरू होता है, और enforcement केवल उन policies के माध्यम से होती है जिन्हें आपकी टीम लिखती और सक्षम करती है।

मुझे access कैसे मिलेगा?

Proof of Actor private beta में है। early access के लिए apply करें और चुनी गई founding developer teams को agreed usage limits के भीतर up to 12 months free मिल सकते हैं।

जानें कि आपका app कौन उपयोग कर रहा है।

founding developers के छोटे समूह के लिए private beta।

Early Access प्राप्त करें मूल्य निर्धारण देखें

क्या पहले बात करना पसंद करेंगे? founders से बात करें