तुलना

Proof of Actor विरुद्ध API bot संरक्षण: keys सांगतात कोण पैसे भरतो, actor context सांगतो कोण कृती करत आहे

API gateways, WAF bot rules, API keys आणि rate limits तुमचे API उपलब्ध आणि उत्तरदायी ठेवतात. परंतु एखादी request app मधील व्यक्तीकडून आली आहे का, assistant सोबत काम करणाऱ्या व्यक्तीकडून आली आहे का, किंवा autonomous agent कडून आली आहे का, हे सांगण्यासाठी ते तयार केलेले नाहीत. API साठी bot management ची Proof of Actor शी तुलना कशी होते, आणि दोन्ही एकत्र कसे बसतात, ते येथे दिले आहे.

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

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

थोडक्यात उत्तर

API साठी bot management तुमचे endpoints संरक्षित करते: gateways keys authenticate करतात, WAF bot rules अपायकारक traffic फिल्टर करतात, आणि rate limits volume मर्यादित करतात. Proof of Actor एक वेगळा layer जोडते, जो तुमच्या API ला प्रत्येक caller Human, Human + AI, Agent किंवा Unknown आहे का ते सांगतो, आणि त्यामागील evidence देतो, त्यामुळे तुमचा code प्रत्येकावर योग्य प्रकारे प्रतिसाद देऊ शकतो. बहुतेक teams दोन्ही वापरतात.

API कधी काळी सोप्या traffic model वर चालत होती. एका developer ने नोंदणी केली, एक key घेतली, integration लिहिले, आणि त्या integration ने वेळापत्रकानुसार किंवा user ने काही क्लिक केल्यावर तुमच्या endpoints ला call केले. API साठी bot management त्या model भोवती विकसित झाले: key authenticate करा, volume मर्यादित करा, स्पष्टपणे अपायकारक traffic फिल्टर करा, आणि service इतरांसाठी उपलब्ध ठेवा.

तो model अजूनही लागू आहे, आणि त्यासाठी तयार केलेली tools अजूनही महत्त्वाची आहेत. बदलले आहे ते calls च्या मागे कोण आहे ते. तोच API key आता तुमच्या ग्राहकाच्या app वापरणाऱ्या व्यक्तीकडून, AI assistant ला काम सांगणाऱ्या व्यक्तीकडून, आणि रात्रीभर multi-step task चालवणाऱ्या autonomous agent कडून requests घेऊ शकतो. तुमची विद्यमान controls एक key आणि एक request rate पाहतात. तुमच्या product, support आणि policy निर्णयांना अनेकदा अधिक माहितीची गरज असते.

Proof of Actor ही पोकळी भरते. ती तुमच्या API ला प्रत्येक request वर कोण किंवा काय कृती करत आहे ते सांगते आणि evidence स्पष्ट करते, आणि मग निर्णय तुमच्या code कडे सोपवते. ही page तिला API bot protection च्या प्रमुख layers सोबत तुलना करते, जेणेकरून प्रत्येक कुठे बसते ते तुम्हाला दिसेल.

थोडक्यात

	API bot संरक्षण	Proof of Actor
मुख्य प्रश्न	ही request allowed, authenticated आणि limits च्या आत आहे का?	कोण किंवा काय कृती करत आहे, आणि evidence काय आहे?
ठराविक layers	API gateway, WAF bot rules, API keys, rate limits	तुमच्या API किंवा MCP server मधील actor वर्गीकरण
ओळखते	key चा मालक असलेले account किंवा integration	प्रत्येक request मागील actor: Human, Human + AI, Agent किंवा Unknown
Output	Allow, reject, throttle; कधी bot score	एक class आणि basis: verified, declared, inferred किंवा unknown
अस्पष्ट traffic	key वैध असल्यास सहसा allow केले जाते, किंवा rule ने reject केले जाते	Unknown, ज्यासाठी route नुसार fallback तुम्ही निवडता
प्रतिसाद कोण ठरवते	Gateway आणि WAF configuration	तुमचे application code
installation नंतर default	Enforcement	Observation; तुम्ही policy जोडल्याशिवाय काहीही बदलत नाही
कशात सर्वात चांगले	उपलब्धता, abuse filtering, quotas, accountability	प्रत्येक actor ला योग्य प्रकारे serve करणे आणि API usage समजून घेणे

खालील विभाग प्रत्येक भाग स्पष्ट करतात.

API bot संरक्षण काय चांगले करते

प्रत्येक layer नेमके काय काम करते हे विशिष्टपणे समजून घेणे महत्त्वाचे आहे, कारण Proof of Actor हे कोणतीही गोष्ट बदलण्यासाठी नाही, तर त्या सर्वांच्या शेजारी बसण्यासाठी डिझाइन केलेले आहे.

API gateways

Gateway हे तुमच्या API चे front door आहे. ते connections terminate करते, API keys किंवा tokens authenticate करते, requests योग्य service कडे route करते, quotas enforce करते आणि अनेकदा billing आणि analytics साठी usage नोंदवते. "हा caller आत येऊ शकतो का, आणि कोणत्या दरवाजातून?" या प्रश्नाचे उत्तर ते जलद आणि सुसंगतपणे प्रत्येक endpoint वर देते.

WAF bot rules

Bot rules असलेला web application firewall ज्ञात attack patterns आणि अपायकारक automation साठी traffic तपासतो. तो injection attempts फिल्टर करू शकतो, abuse चा इतिहास असलेल्या sources मधील traffic block करू शकतो, आणि scraping किंवा credential attacks सारखे दिसणाऱ्या requests ना challenge किंवा drop करू शकतो. तुमच्या code पर्यंत पोहोचू नये अशा traffic विरुद्ध ही तुमची सर्वोत्तम defence आहे.

API keys आणि tokens

Keys आणि tokens तुम्हाला accountability देतात. प्रत्येक request एका account शी जोडलेली असते, त्यामुळे कोणाच्या integration ने call केला हे तुम्हाला माहीत असते, access revoke करता येतो, आणि usage चे attribution करता येते. Scoped tokens यापुढे जातात आणि caller काय करू शकतो ते मर्यादित करतात.

Rate limits

Rate limits उपलब्धता संरक्षित करतात. ते एक integration सर्वांसाठी राखीव क्षमता वापरण्यापासून थांबवतात, आणि brute-force आणि enumeration attempts मंद करतात. Per-key आणि per-route limits हे standard, प्रभावी controls आहेत.

एकत्रितपणे या layers संरक्षण आणि accountability च्या प्रश्नांची खूप चांगली उत्तरे देतात. त्यांना ठेवा.

त्यांनी ज्याचे उत्तर देण्यासाठी बांधलेले नाहीत तो प्रश्न

यापैकी कोणतीही layer authenticated request च्या मागे कशा प्रकारचा actor आहे हे सांगण्यासाठी डिझाइन केलेली नाही. Valid key म्हणजे कोणत्या account कडे integration आहे ते सांगते. पण ते असे सांगत नाही:

ही specific call तुमच्या ग्राहकाच्या app मध्ये बटण दाबणाऱ्या व्यक्तीकडून आली का,
व्यक्तीने AI assistant ला ती कृती करायला सांगितली का,
autonomous agent ने मोठ्या task चा एक भाग म्हणून call केली का,
किंवा हे कोणालाही ठामपणे माहीत नाही का.

हा फरक प्रत्येक महिन्यात अधिक महत्त्वाचा होत आहे. CRM integration, scheduling tool किंवा developer platform serve करणाऱ्या API ला increasingly agent traffic हेच keys वापरून मिळते जे human-driven apps serve करतात. जर तुम्हाला agents साठी संरचित response द्यायचा असेल, agents-ने चालवलेल्या high-impact writes साठी confirmation मागायचे असेल, AI-assisted submissions लेबल करायच्या असतील, किंवा फक्त तुमच्या API usage पैकी किती भाग agent-driven आहे ते मोजायचे असेल, तर actor context आवश्यक आहे.

Proof of Actor API मध्ये काय जोडते

Proof of Actor प्रत्येक interaction साठी चार class पैकी एक परिणाम देते:

Human: दिसणारे signals human-directed interaction सूचित करतात.
Human + AI: व्यक्तीने AI सहाय्यासह interaction निर्देशित केली होती, जी supported integration मधून declared किंवा observed होती.
Agent: automated किंवा agent-origin interaction.
Unknown: evidence विश्वसनीय निर्धारणाला पाठबळ देत नाही.

प्रत्येक result त्याचा evidence basis देखील सांगतो:

Verified: उदाहरणार्थ, published key विरुद्ध तपासलेली HTTP Message Signature (RFC 9421).
Declared: client किंवा तुमच्या स्वतःच्या application ने ते जाहीर केले.
Inferred: behavioral किंवा contextual signals, स्पष्टपणे inference म्हणून लेबल केलेले.
Unknown: विश्वसनीय basis नाही.

API साठी verified basis विशेष उपयुक्त आहे. आपले requests स्वाक्षरी करणाऱ्या agents ना त्यांच्या published keys विरुद्ध तपासले जाऊ शकते, आणि हा दृष्टिकोन IETF च्या Web Bot Auth work मागे आहे. पार्श्वभूमीसाठी Web Bot Auth for product teams ही explainer वाचा, आणि implementation बाजूसाठी verifying signed agent requests हा guide पहा.

येथे एक मर्यादा महत्त्वाची आहे. वैध signature कोणत्या key ने request वर स्वाक्षरी केली ते सिद्ध करते. पण agent ला ती कृती करण्याची परवानगी आहे हे ते सिद्ध करत नाही. Authorization तुमच्या API च्या स्वतःच्या access control मध्येच राहते. agent authorization ही entry हा फरक स्पष्ट करते.

Scores आणि keys विरुद्ध actor evidence

काही bot protection products प्रत्येक request ला score देतात. Block निर्णयासाठी score कार्यक्षम असतो. पण API product निर्णयांसाठी तो कमी उपयुक्त असतो, कारण तो वैध request human-driven होती की agent-driven, हे सांगत नाही, आणि verified facts आणि inference यांना वेगळे करत नाही.

API keys मध्ये उलट मर्यादा आहे. त्या ownership बाबतीत अचूक असतात आणि actor बाबतीत मौन असतात. एका ग्राहकाची key एका तासात चारही classes घेऊन येऊ शकते.

Proof of Actor दोन्ही फरक दृश्यमान ठेवते. तुमच्या API ला key मधून account दिसतो, Proof of Actor मधून actor class दिसतो, आणि त्याला पाठबळ देणारा basis दिसतो. प्रत्येक layer ती ज्या प्रश्नाचे उत्तर चांगल्या प्रकारे देते तोच प्रश्न सोडवते.

प्रत्येक कुठे चालते

Gateways आणि WAFs तुमच्या network च्या edge वर किंवा सेवांच्या समोर चालतात. संरक्षण आणि quotas साठी ती जागा योग्य आहे.

Proof of Actor तुमची API logic जिथे आहे तिथे चालते. Founding teams Node.js middleware, Next.js, तुम्ही नियंत्रित करता त्या edge layer, generic HTTP API, किंवा MCP server integration द्वारे integrate करू शकतात. संपूर्ण यादीसाठी integrations पहा. ते तुमच्या application मध्येच चालत असल्यामुळे ते तुमच्या API ला माहीत असलेली गोष्ट वापरू शकते: route, workflow, client ने स्वतःबद्दल काय declared केले, आणि signature verify झाला का.

Routing decisions तुमच्या code मध्येच राहतात

Proof of Actor default ने काहीही block करत नाही. ते observation mode मध्ये सुरू होते, त्यामुळे ते install केल्याने तुमची API कशी respond करते यात काहीही बदल होत नाही. तुम्हाला endpoint नुसार तुमचा actor mix दिसतो, individual results साठी evidence review करता येते, आणि तुमचा Unknown rate पाहता येतो.

तुम्ही ready झाल्यावर, route नुसार, actor class नुसार, आणि basis नुसार application-defined policies लिहिता. ठराविक outcomes असे असतात:

Allow: request नेहमीप्रमाणे serve करा.
Adapt: verified agent साठी structured किंवा reduced response परत करा.
Challenge: अतिरिक्त confirmation step आवश्यक करा, उदाहरणार्थ high-impact write वर human approval.
Review: action एखाद्या व्यक्तीने तपासण्यासाठी queue मध्ये ठेवा.
Rate-limit: एखाद्या specific route वर specific class आणि basis साठी अधिक कडक limit लावा.

Policy enforce करण्यापूर्वी तुम्ही ती वास्तविक traffic विरुद्ध preview करू शकता, आणि मग route नुसार enforce करू शकता. rolling out actor-aware policies safely हा guide प्रक्रिया स्पष्ट करतो, आणि protecting sensitive actions without blocking agents सामान्य patterns दाखवतो.

Unknown API callers हाताळणे

प्रत्येक API ला असे traffic मिळते ज्याचे confidence सह वर्गीकरण करता येत नाही. पारंपरिक controls मध्ये, valid key असल्यास request सहसा पुढे जाते, आणि invalid असल्यास जात नाही. मधले काहीच नसते.

Proof of Actor तुम्हाला explicit Unknown result देते आणि route नुसार fallback निवडू देते. Read-only catalog endpoints खुले ठेवू शकता. Account changes साठी तुमचे विद्यमान अधिक कडक checks कायम ठेवू शकता. Bulk exports review कडे पाठवू शकता. तपशीलांसाठी handling Unknown traffic आणि unknown automated traffic पहा.

ते कसे एकत्र काम करतात

सर्वात मजबूत API setup प्रत्येक layer ला त्याचे स्वतःचे काम देते:

Edge वर, WAF अपायकारक आणि चुकीच्या स्वरूपाचा traffic फिल्टर करते.
Gateway वर, keys authenticate केल्या जातात, quotas enforce होतात आणि usage नोंदवले जाते.
API च्या आत, Proof of Actor पुढे आलेली प्रत्येक request वर्गीकृत करते आणि तिचा basis सांगते.
तुमच्या handlers मध्ये, policies class आणि basis वापरून response निवडतात: human-driven call साठी सामान्य handling, verified agent साठी structured response, agent-driven high-impact write साठी confirmation step, Unknown साठी fallback.
Analytics मध्ये, तुमची team कोणते endpoints आणि workflows प्रत्येक actor class वापरते ते gateway मधील account data सोबत पाहते.

या stack मध्ये काहीही duplicated नाही. Gateway account ओळखते, WAF threat patterns ओळखते, आणि Proof of Actor actor ओळखते.

कधी कशावर लक्ष केंद्रित करावे

तुमच्या मुख्य समस्या abuse, उपलब्धता किंवा unmetered usage असतील तेव्हा आधी API bot संरक्षण वर लक्ष केंद्रित करा: auth endpoints वर credential attacks, आक्रमक scraping, किंवा एक integration इतरांना क्षमता न मिळू देणे.

तुमचे मुख्य प्रश्न तुमच्या callers बद्दल असतील तेव्हा Proof of Actor वर लक्ष केंद्रित करा: तुमच्या API traffic पैकी किती भाग agent-driven आहे, कोणते agents कोणते endpoints call करतात, human-driven आणि agent-driven usage कुठे वेगळी आहे, आणि कोणत्या routes ना actor-aware policy हवी आहे. APIs use case आणि AI agent identification for APIs अधिक सविस्तर माहिती देतात.

production API चालवणाऱ्या बहुतेक teams ना दोन्ही गोष्टींची उत्तरे हवी असतात.

सुरुवात करा

Proof of Actor private beta मध्ये आहे. निवडलेल्या founding developer teams ना मान्य usage limits अंतर्गत 12 months पर्यंत free access मिळू शकतो, automatic billing शिवाय. early access साठी अर्ज करा आणि तुम्हाला कोणते API आणि कोणते callers समजून घ्यायचे आहेत ते आम्हाला सांगा.

विकसकांसाठी

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 वाचा

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

Proof of Actor माझा API gateway किंवा WAF बदलते का?

नाही. तुमचा gateway अजूनही keys authenticate करतो आणि quotas enforce करतो, आणि तुमचा WAF अजूनही अपायकारक traffic फिल्टर करतो. Proof of Actor तुमच्या API च्या आत चालते आणि जे requests पुढे जातात त्यांना actor context जोडते. तुमची विद्यमान controls तशीच ठेवा.

जर प्रत्येक caller कडे API key असेल, तर actor context का आवश्यक आहे?

API key integration चा मालक कोणता account आहे ते ओळखतो. पण दिलेली request ग्राहकाच्या app मध्ये क्लिक करणाऱ्या व्यक्तीकडून आली का, AI assistant वापरणाऱ्या व्यक्तीकडून आली का, किंवा task चालवणाऱ्या autonomous agent कडून आली का, हे ते सांगत नाही. Proof of Actor हे त्याच्या basis सह अहवालित करते.

Proof of Actor माझ्या API ला कोणता agent call करत आहे ते verify करू शकते का?

जेव्हा client त्याच्या requests वर HTTP Message Signatures (RFC 9421) ने स्वाक्षरी करतो आणि त्याची key publish करतो, तेव्हा Proof of Actor signature तपासते आणि verified basis अहवालित करते. वैध signature कुठली key request वर स्वाक्षरी करते हे सिद्ध करते. पण agent ला कृती करण्याची परवानगी आहे हे ते सिद्ध करत नाही, त्यामुळे authorization तुमच्या code मध्येच राहते.

Proof of Actor माझ्या API traffic चे rate-limiting किंवा blocking सुरू करेल का?

नाही. ते observation mode मध्ये सुरू होते आणि default ने काहीही block करत नाही. rate-limit हा policy मध्ये निवडता येणारा एक outcome आहे, route, actor class आणि basis नुसार, आणि enforcement तुमच्या स्वतःच्या code मध्ये असते.

API मध्ये Proof of Actor कसे जोडू?

Founding teams Node.js middleware, Next.js, edge integration किंवा generic HTTP API वापरू शकतात. MCP servers साठी स्वतंत्र integration आहे. तपशीलांसाठी integrations page पहा.

जे callers वर्गीकृत करता येत नाहीत त्यांचे काय होते?

त्यांना Unknown म्हणून अहवालित केले जाते, हा first-class result आहे. प्रत्येक route साठी fallback तुम्ही निवडता, उदाहरणार्थ read-only endpoints वर allow करा आणि write endpoints वर तुमचे अधिक कडक checks ठेवा.

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

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

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

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