AI एजंट ओळख

API साठी AI एजंट ओळख

तुमच्या API ला आधीच कोणत्या key ने request केली हे माहीत असते. Proof of Actor त्या मागे कोणत्या प्रकारचा actor होता, त्या निष्कर्षाला कोणता पुरावा आधार देतो, आणि पुढे काय घडावे हे तुमच्या code ला ठरवू देतो.

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

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

तुमच्या API ला key माहीत असते. actor माहीत नसतो.

प्रत्येक API request सोबत ती कोणासाठी pay केली जात आहे याचा काही ना काही पुरावा येतो: API key, OAuth token, session. तो पुरावा एक प्रश्न चांगला सोडवतो. तो तुम्हाला call साठी कोणते account जबाबदार आहे हे सांगतो. पण सध्या प्रत्यक्षात call काय करत आहे हे तो सांगत नाही.

एकच API key terminal मध्ये test करणारा developer, schedule वर चालणारी backend job, AI assistant सोबत काम करणारी व्यक्ती, आणि task पूर्ण करण्यास सांगितलेला autonomous agent यांनी वापरू शकतो. हे सगळे वेगवेगळे actors आहेत. त्यांची गती वेगळी आहे, failure modes वेगवेगळे आहेत, आणि risk profiles वेगवेगळे आहेत. त्यांना एकसारखे वागवले तर तुम्ही एकतर तुमच्या customers ज्या legitimate automation वर अवलंबून आहेत ती जास्त मर्यादित करता, किंवा unattended agent ने कधीच चालवू नये अशा तुमच्या API च्या भागांचे संरक्षण कमी करता.

API साठी AI agent ओळख ही ती दरी भरून काढते. key वरून सगळे infer करण्याऐवजी, प्रत्येक request मागील actor चे classification आणि त्याला आधार देणारा पुरावा तुम्हाला मिळतो. हेच Proof of Actor देण्यासाठी बनवले आहे, आणि APIs use case API teams ते route by route कसे वापरतात ते दाखवते.

API teams ला आता actor context का हवा आहे

API कडे जाणारी automated traffic नवीन नाही. scripts, integrations आणि crawlers नेहमीच चित्राचा भाग होते. बदलला आहे तो automation चा प्रकार. AI agents documentation वाचू शकतात, calls एकत्र जोडू शकतात, creative retry करू शकतात आणि प्रत्येक step पाहत नसलेल्या लोकांच्या वतीने काम करू शकतात. त्यापैकी बरेच उपयुक्त आणि स्वागतार्ह आहेत. काही नीट built नाहीत. काही hostile आहेत.

actor context नसल्यास, API teams साधारणपणे कठोर 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 वर unknown caller कडून stronger credential मागता येते. AI assistant वापरणारी व्यक्ती normal experience ठेवू शकते. उद्देश agents थांबवणे नाही. प्रत्येक प्रकारच्या caller ला योग्य path देणे हा उद्देश आहे. signed request काय सिद्ध करू शकते आणि काय नाही, हे जाणून घेण्यासाठी what signed AI agent requests prove वाचा.

Proof of Actor मध्ये AI agent identification कसे काम करते

Proof of Actor प्रत्येक request साठी एकच evidence-first flow वापरतो. पूर्ण walkthrough साठी How It Works पहा; API teams साठी संक्षिप्त रूप येथे आहे.

1. तुमच्या integration मधील signals

तुमची integration त्या context मध्ये उपलब्ध असलेले signals Proof of Actor ला देते. API साठी, याचा अर्थ सहसा headers आणि protocol details सारखा request context, client कडून मिळणाऱ्या cryptographic request signatures, आणि client स्वतःबद्दल करते त्या declarations असा होतो. प्रत्येक signal तो कुठून आला त्याने label केलेला असतो.

2. basis सह classification

हे signals तपासले आणि एकत्र करून चार public classes पैकी एका मध्ये ठेवले जातात:

Human: दिसणारे signals human-directed interaction दाखवतात.
Human + AI: AI assistance घोषित केली गेली आहे किंवा निरीक्षण करू शकणाऱ्या integration ने ती ओळखली आहे.
Agent: verifiable identity किंवा काळजीपूर्वक qualified inference ने समर्थित automated किंवा agent-origin traffic.
Unknown: पुरावा विश्वासार्ह निर्धारणाला आधार देत नाही.

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

3. तुमच्या code ला कृती करता येईल असा result

हा result class, basis आणि वाचनीय evidence summary सह तुमच्या application कडे परत येतो. काय करायचे ते तुमचा 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 वेगळे ठेवले जातात, त्यामुळे काहीही शांतपणे एका score मध्ये मिसळले जात नाही.

Understand

कोणते actors कोणते routes call करतात, ते वेळेनुसार कसे बदलते, आणि प्रत्येक classification मागे कोणता पुरावा आहे ते पहा. unknown rate दिसत राहते, त्यामुळे तुमची coverage कुठे संपते आणि stronger signal कुठे मदत करेल हे अचूक कळते.

Route

प्रत्येक route आणि प्रत्येक risk tier साठी policy लिहा: allow, adapt, challenge, review किंवा rate-limit. read-only endpoints वर verified agents साठी structured, generous path ठेवा. high-impact operations साठी stronger credentials मागा. Unknown आणि timeout साठी explicit fallback ठरवा, त्यामुळे काहीही घडले तरी तुमचा API predictably वागेल. चुकांची किंमत त्या route वर किती आहे यावर आधारित, प्रत्येक policy fail open की fail closed कशी होईल ते तुम्ही ठरवता.

identity evidence, credentials आणि authorization या तीन वेगळ्या गोष्टी आहेत

agent-aware API design मधील सर्वात सामान्य चूक म्हणजे तीन स्वतंत्र प्रश्न एकात मिसळणे. Proof of Actor त्यांना वेगळे ठेवतो, आणि तुमच्या design नेही तसेच करायला हवे.

Identity evidence: कोणत्या प्रकारचा actor call करत आहे, आणि त्याचा पुरावा काय? हे AI agent identification देते. एक verified signature request ला key आणि तिच्या प्रकाशित operator identifier शी जोडते. IETF Web Bot Auth working group automated clients साठी अशा प्रकारच्या cryptographic authentication ला standardize करण्यासाठी chartered आहे, आणि त्याचा scope end user ऐवजी agent authenticate करण्यापर्यंत आहे.
Credentials: या call साठी कोणते account जबाबदार आहे? हे तुमचे API key, token किंवा session आहे, जे तुम्ही जारी आणि व्यवस्थापित करता.
Authorization: हा caller हे विशिष्ट काम करू शकतो का? हे तुमचे permission model आहे.

verified agent आपोआप authorized agent होत नाही. वैध signature मुळे एखाद्या व्यक्तीने agent ला authority दिली आहे हे सिद्ध होत नाही, आणि requested action safe आहे हेही सिद्ध होत नाही. Proof of Actor पहिल्या प्रश्नासाठी विश्वासार्ह context देतो आणि दुसरा व तिसरा प्रश्न तिथेच ठेवतो जिथे ते असायला हवेत: तुमच्या application मध्ये. agent authorization आणि Detection & Limitations वर पुरावा काय स्थापित करू शकतो आणि काय नाही, याबद्दल अधिक वाचा.

Unknown हे feature आहे, failure नाही

Request signing ऐच्छिक आहे, आणि unsigned client स्वतःचे वर्णन हवे तसे करू शकतो. प्रत्येक request ला Human किंवा Agent मध्ये जबरदस्तीने बसवणारी system कधी ना कधी आत्मविश्वासाने चुकते, आणि तेव्हा तुम्हाला ते कळणारही नाही.

पुरावा निर्धारणाला आधार देत नाही तेव्हा Proof of Actor Unknown report करतो. Unknown कधीच Human मध्ये convert केला जात नाही आणि default म्हणून कधीच malicious मानला जात नाही. तुमच्या policy मध्ये प्रत्येक route साठी Unknown चा अर्थ काय हे ठरते: public reads वर तो allow करा, account changes वर तुमच्या विद्यमान checks कायम ठेवा, stakes जास्त असतील तेव्हा review साठी queue करा. Unknown visible ठेवणे हेच तुमच्या इतर classifications ला विश्वासार्ह बनवते. handling unknown traffic वरील guide ते कसे design करायचे ते दाखवतो.

AI agent identification तुमच्या stack मध्ये कुठे बसते

Proof of Actor तुमच्या existing gateway, authentication आणि rate limiting सोबत बसतो. तो यापैकी कोणालाही replace करत नाही. सामान्य placements मध्ये समाविष्ट आहे:

Server-side middleware, तुमच्या route handlers च्या आधी, त्यामुळे business logic चालण्यापूर्वी प्रत्येक request चे evaluation होते.
At the edge, त्यामुळे requests origin पर्यंत पोहोचण्यापूर्वी signals चे evaluation होते.
A generic HTTP integration, त्यामुळे कोणताही stack request context पाठवू शकतो आणि basis सह result प्राप्त करू शकतो.

Onboarding दरम्यान प्रत्येक founding team सोबत integrations hands-on दिले जातात, त्यामुळे path तुमच्या architecture ला जुळतो, उलट नाही. developer hub आज उपलब्ध integration paths दाखवतो. तुम्ही agents साठी tools चालवत असाल, तर MCP Servers use case tool calls साठी विशिष्ट patterns कव्हर करतो.

Observation mode मध्ये सुरू करा

Proof of Actor install केल्याने तुमचा API कसा respond करतो ते बदलत नाही. परिणाम record केले जातात, त्यामुळे तुमची team ते आधीच माहित असलेल्या outcomes शी compare करू शकते, agents प्रत्यक्षात कुठे जातात ते पाहू शकते, प्रत्येक route वर unknown rate मोजू शकते, आणि चुकीचा वाटणारा कोणताही classification review करू शकते. त्यानंतरच, पुरावा जिथे आधार देतो तिथे route by route policy सक्षम करा.

AI agent identification तुमच्या customers ना surprise न देता किंवा ते अवलंबून असलेली integrations न मोडता कसे roll out करायचे, हे असे केले जाते. rolling out actor-aware policies safely वरील guide क्रमाने step by step समजावतो.

founding developer program मध्ये सहभागी व्हा

Proof of Actor private beta मध्ये एका छोट्या group of founding development teams सोबत आहे. निवडलेल्या teams ना onboarding दरम्यान ठरवलेल्या usage limits अंतर्गत up to 12 months free access, आमच्या engineers कडून direct integration support, आणि आम्ही पुढे काय build करतो यावर खरा influence मिळू शकतो.

तुम्ही API चालवत असाल आणि खरं तर कोण call करत आहे हे जाणून घ्यायचं असेल, तर apply for early access. तुमच्या API बद्दल, तुम्हाला सर्वाधिक महत्त्वाचे वाटणारे routes, आणि actor context मिळाल्यावर तुम्ही वेगळे निर्णय घ्याल अशी decisions आम्हाला सांगा. Proof of Actor कसा बसतो ते आम्ही सांगू.

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 च्या शेजारी नोंदवा आणि तुम्ही policy निवडेपर्यंत काहीही बदलू नका. Node.js integration guide वाचा

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

AI agent ओळख API key authentication पेक्षा वेगळी कशी आहे?

API key तुम्हाला कोणत्या account ने request पाठवली हे सांगते. AI agent ओळख तुम्हाला request मागे कोणता प्रकारचा actor आहे आणि त्या निष्कर्षाला कोणता पुरावा आधार देतो हे सांगते. तुम्हाला दोन्हींची गरज असते, आणि ते वेगवेगळ्या प्रश्नांची उत्तरे देतात.

Proof of Actor माझ्या API ला कॉल करणारा प्रत्येक AI agent ओळखू शकतो का?

Proof of Actor दिसणारी प्रत्येक request Human, Human + AI, Agent किंवा Unknown अशी वर्गीकृत करतो, आणि प्रत्येक निकालाचा basis सांगतो. पुरावा पुरेसा मजबूत नसल्यास, तो निकाल Unknown असतो, अंदाज नाही.

एखादा agent ओळखला म्हणजे त्याला कृती करण्याची परवानगी आहे का?

नाही. ओळख आणि authorization वेगवेगळे आहेत. Proof of Actor तुमच्या application ला caller बद्दल context देतो, आणि तुमचे स्वतःचे authorization rules तो caller काय करू शकतो हे ठरवतात.

Proof of Actor माझ्या API वरच्या requests block करेल का?

तुम्ही तसे ठरवले नाही तर नाही. प्रत्येक integration observation mode मध्ये सुरू होते, आणि enforcement फक्त तुमची team लिहिते आणि सक्षम करते अशा policies मधूनच होते.

मला access कसा मिळेल?

Proof of Actor private beta मध्ये आहे. early access साठी apply करा आणि निवडलेल्या founding developer teams ना agreed usage limits अंतर्गत up to 12 months free access मिळू शकतो.

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

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

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

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