तुलना

Proof of Actor बनाम API बॉट सुरक्षा: keys बताती हैं कौन भुगतान करता है, actor context बताता है कौन कार्रवाई कर रहा है

API gateways, WAF bot rules, API keys और rate limits आपकी API को उपलब्ध और उत्तरदायी बनाए रखते हैं। इन्हें यह बताने के लिए नहीं बनाया गया था कि कोई request app में किसी व्यक्ति से आई, किसी assistant के साथ काम कर रहे व्यक्ति से आई, या किसी autonomous agent से। यहां बताया गया है कि APIs के लिए bot management, Proof of Actor से कैसे तुलना करता है, और दोनों एक साथ कैसे फिट होते हैं।

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

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

संक्षिप्त उत्तर

API के लिए bot management आपके endpoints की सुरक्षा करता है: gateways keys authenticate करते हैं, WAF bot rules abusive traffic को filter करते हैं, और rate limits volume को सीमित करते हैं। Proof of Actor एक अलग layer जोड़ता है, जो आपकी API को बताता है कि हर caller Human, Human + AI, Agent या Unknown है, और उसके पीछे का evidence भी देता है, ताकि आपका code हर एक के साथ सही तरीके से काम कर सके। अधिकतर teams दोनों चलाती हैं।

API में पहले traffic model सरल था। एक developer ने registration किया, key ली, integration लिखा, और वह integration schedule के अनुसार या user के कुछ click करने पर आपके endpoints को call करता था। APIs के लिए bot management इसी model के आसपास विकसित हुआ: key authenticate करें, volume सीमित करें, स्पष्ट रूप से abusive traffic filter करें, और बाकी सभी के लिए service उपलब्ध रखें।

वह model आज भी लागू है, और उसके लिए बने tools अब भी महत्वपूर्ण हैं। जो बदला है वह यह है कि calls के पीछे कौन है। वही API key अब आपके customer के app का उपयोग करने वाले व्यक्ति, AI assistant से काम करवाने वाले व्यक्ति, और रात भर multi-step task चलाने वाले autonomous agent की requests ले जा सकती है। आपके मौजूदा controls को एक key और एक request rate दिखता है। लेकिन आपके product, support और policy decisions को अक्सर इससे अधिक जानना होता है।

Proof of Actor यह gap भरता है। यह आपकी API को बताता है कि हर request पर कौन या क्या action कर रहा है, evidence बताता है, और फिर निर्णय आपके code पर छोड़ देता है। यह page इसे API bot protection की मुख्य layers के साथ compare करता है ताकि आप देख सकें कि हर एक कहां उपयुक्त है।

संक्षिप्त संस्करण

	API bot protection	Proof of Actor
मुख्य प्रश्न	क्या यह request allowed, authenticated है और limits के भीतर है?	कौन या क्या action कर रहा है, और evidence क्या है?
सामान्य layers	API gateway, WAF bot rules, API keys, rate limits	आपकी API या MCP server के भीतर actor classification
किसकी पहचान करता है	वह account या integration जो key का मालिक है	हर request के पीछे का actor: Human, Human + AI, Agent या Unknown
Output	Allow, reject, throttle; कभी-कभी bot score	एक class के साथ basis: verified, declared, inferred या unknown
अस्पष्ट traffic	आम तौर पर valid key होने पर allow, या rule से reject	Unknown, आपके चुने हुए fallback के साथ per route
response कौन तय करता है	Gateway और WAF configuration	आपकी application code
install के समय default	Enforcement	Observation; जब तक आप policy नहीं जोड़ते, कुछ नहीं बदलता
सबसे अच्छा	Availability, abuse filtering, quotas, accountability	हर actor के साथ सही सेवा देना और API usage को समझना

नीचे के sections हर भाग को समझाते हैं।

API bot protection क्या अच्छा करता है

यह स्पष्ट होना उपयोगी है कि हर layer क्या काम करती है, क्योंकि Proof of Actor इन्हीं के साथ बैठने के लिए बनाया गया है, किसी को replace करने के लिए नहीं।

API gateways

Gateway आपकी API का front door है। यह connections terminate करता है, API keys या tokens authenticate करता है, requests को सही service तक route करता है, quotas लागू करता है, और अक्सर billing तथा analytics के लिए usage record करता है। यह हर endpoint पर तेजी और consistency के साथ यह जवाब देता है: "क्या यह caller अंदर आने के योग्य है, और किस door से?"

WAF bot rules

Bot rules वाला web application firewall known attack patterns और abusive automation के लिए traffic inspect करता है। यह injection attempts filter कर सकता है, abuse के इतिहास वाले sources से traffic block कर सकता है, और scraping या credential attacks जैसे दिखने वाले requests को challenge या drop कर सकता है। यह उस traffic के खिलाफ आपकी सबसे अच्छी रक्षा है जिसे कभी भी आपकी code तक नहीं पहुंचना चाहिए।

API keys और tokens

Keys और tokens आपको accountability देते हैं। हर request एक account से map होती है, इसलिए आपको पता रहता है कि किस integration ने call की, आप access revoke कर सकते हैं, और usage attribute कर सकते हैं। Scoped tokens इससे आगे जाकर यह सीमित करते हैं कि caller क्या कर सकता है।

Rate limits

Rate limits availability की रक्षा करते हैं। ये एक integration को उस capacity का उपयोग करने से रोकते हैं जो सभी के लिए है, और brute-force तथा enumeration attempts को धीमा करते हैं। Per-key और per-route limits एक standard, प्रभावी control हैं।

साथ मिलकर ये layers protection और accountability के प्रश्न बहुत अच्छी तरह हल करती हैं। इन्हें बनाए रखें।

वह प्रश्न जिसका उत्तर देने के लिए इन्हें नहीं बनाया गया था

इनमें से कोई भी layer यह बताने के लिए नहीं बनाई गई है कि authenticated request के पीछे किस प्रकार का actor है। Valid key बताती है कि integration किस account की है। यह नहीं बताती:

क्या यह specific call आपके customer के app में button दबाने वाले व्यक्ति से आई थी,
क्या किसी व्यक्ति ने AI assistant से यह action करवाया था,
क्या किसी autonomous agent ने इसे किसी लंबे task के एक step के रूप में call किया था,
या क्या इसे कोई विश्वसनीय रूप से नहीं बता सकता।

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

Proof of Actor API में क्या जोड़ता है

हर interaction के लिए Proof of Actor चार classes में से एक लौटाता है:

Human: देखे जा सकने वाले signals बताते हैं कि interaction human-directed था।
Human + AI: एक व्यक्ति ने AI assistance के साथ interaction निर्देशित किया, जो किसी supported integration के माध्यम से declared या observed थी।
Agent: automated या agent-origin interaction।
Unknown: evidence reliable determination का समर्थन नहीं करता।

हर result अपनी evidence basis भी बताता है:

Verified: उदाहरण के लिए, published key के against checked एक HTTP Message Signature (RFC 9421)।
Declared: client या आपकी own application ने इसे बताया।
Inferred: behavioral या contextual signals, जिन्हें साफ तौर पर inference के रूप में label किया गया है।
Unknown: कोई reliable basis नहीं।

APIs के लिए verified basis विशेष रूप से उपयोगी है। जो agents अपनी requests sign करते हैं, उन्हें उनके published keys के against check किया जा सकता है, और यही IETF Web Bot Auth work के पीछे का approach है। Background के लिए Web Bot Auth for product teams का explainer देखें, और implementation side के लिए verifying signed agent requests guide देखें।

यहां एक सीमा महत्वपूर्ण है। Valid signature यह साबित करती है कि किस key ने request sign की। यह यह साबित नहीं करती कि agent को action करने की authorization है। Authorization वहीं रहती है जहां होनी चाहिए, यानी आपकी API के own access control में। agent authorization entry इस अंतर को समझाती है।

Scores और keys बनाम actor evidence

कुछ bot protection products हर request पर score लगाते हैं। Block decision के लिए score efficient होता है। लेकिन API product decisions के लिए यह कम उपयोगी है, क्योंकि यह नहीं बताता कि कोई legitimate request human-driven थी या agent-driven, और यह verified facts को inference से अलग भी नहीं करता।

API keys का उल्टा limitation है। वे ownership के बारे में precise हैं और actor के बारे में मौन। एक customer की key एक ही घंटे में चारों classes ले जा सकती है।

Proof of Actor दोनों distinctions को visible रखता है। आपकी API को key से account दिखता है, Proof of Actor से actor class दिखती है, और उसे support करने वाली basis भी। हर layer वही प्रश्न हल करती है जिसके लिए वह अच्छी है।

हर एक कहां चलता है

Gateways और WAFs आपके network के edge पर या आपकी services के सामने चलते हैं। वह position protection और quotas के लिए सही है।

Proof of Actor वहीं चलता है जहां आपकी API logic रहती है। Founding teams Node.js middleware, Next.js, आपके द्वारा नियंत्रित edge layer, generic HTTP API, या MCP server integration के माध्यम से integrate कर सकते हैं। पूरी सूची के लिए integrations देखें। क्योंकि यह आपकी application के अंदर चलता है, यह वह use कर सकता है जो आपकी API जानती है: route, workflow, client ने खुद को घोषित किया या नहीं, और signature verified हुआ या नहीं।

Routing decisions आपके code में ही रहती हैं

Proof of Actor by default कुछ भी block नहीं करता। यह observation mode में शुरू होता है, इसलिए इसे install करने से आपकी API के response देने का तरीका नहीं बदलता। आपको endpoint के अनुसार actor mix दिखता है, individual results के लिए evidence review करने को मिलता है, और अपनी Unknown rate पर नज़र रखी जा सकती है।

जब आप तैयार हों, तो आप 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 पर tighter limit लागू करें।

आप policy को enforce करने से पहले real traffic के against preview कर सकते हैं, फिर route by route enforce कर सकते हैं। rolling out actor-aware policies safely guide इस process को कवर करता है, और protecting sensitive actions without blocking agents common patterns दिखाता है।

Unknown API callers को संभालना

हर API को ऐसा traffic मिलता है जिसे confidence के साथ classify नहीं किया जा सकता। Traditional controls में, valid key का मतलब आम तौर पर request का pass होना है, और invalid key का मतलब उसका pass न होना। बीच में कुछ नहीं होता।

Proof of Actor आपको एक स्पष्ट Unknown result देता है और हर route के लिए fallback चुनने देता है। Read-only catalog endpoints खुले रह सकते हैं। Account changes आपकी मौजूदा stricter checks बनाए रख सकते हैं। Bulk exports review में जा सकते हैं। विवरण के लिए handling Unknown traffic और unknown automated traffic देखें।

ये साथ कैसे काम करते हैं

सबसे मजबूत API setup हर layer को उसके अपने काम के लिए उपयोग करता है:

Edge पर, WAF abusive और malformed traffic filter करता है।
Gateway पर, keys authenticate होती हैं, quotas लागू होते हैं और usage record होता है।
API के अंदर, Proof of Actor हर उस request को classify करता है जो आगे निकलती है और उसकी basis बताता है।
आपके handlers में, policies class और basis का उपयोग करके response चुनती हैं: human-driven call के लिए normal handling, verified agent के लिए structured response, agent-driven high-impact write के लिए confirmation step, Unknown के लिए fallback।
Analytics में, आपकी team देखती है कि कौन-से endpoints और workflows हर actor class उपयोग करती है, साथ ही gateway से मिला account data भी।

इस stack में कुछ भी duplicate नहीं है। Gateway account को जानता है, WAF threat patterns को जानता है, और Proof of Actor actor को जानता है।

किस पर कब ध्यान दें

जब आपकी मुख्य समस्याएं abuse, availability या unmetered usage हों, तब पहले API bot protection पर ध्यान दें: auth endpoints पर credential attacks, aggressive 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 को agreed usage limits के भीतर up to 12 months का free access मिल सकता है, बिना automatic billing के। early access के लिए apply करें और हमें उस 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 के पास record करें और जब तक आप कोई policy न चुनें, कुछ न बदलें। Node.js integration guide पढ़ें

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

क्या Proof of Actor मेरे API gateway या WAF को replace करता है?

नहीं। आपका gateway अभी भी keys authenticate करता है और quotas लागू करता है, और आपका WAF अभी भी abusive traffic को filter करता है। Proof of Actor आपकी API के अंदर चलता है और जो requests आगे निकलती हैं, उनमें actor context जोड़ता है। अपने मौजूदा controls बनाए रखें।

अगर हर caller के पास API key है, तो मुझे actor context की जरूरत क्यों है?

API key उस account की पहचान करती है जो integration का मालिक है। यह नहीं बताती कि कोई particular request आपके customer के app में button click करने वाले व्यक्ति से आई थी, AI assistant का उपयोग करने वाले व्यक्ति से आई थी, या कोई autonomous agent किसी task को चला रहा था। Proof of Actor यह उसकी basis के साथ रिपोर्ट करता है।

क्या Proof of Actor यह verify कर सकता है कि मेरी API को कौन-सा agent call कर रहा है?

जब कोई client अपनी requests को HTTP Message Signatures (RFC 9421) से sign करता है और अपनी key publish करता है, तो Proof of Actor signature को check करता है और verified basis report करता है। Valid signature यह साबित करता है कि किस key ने request sign की। यह यह साबित नहीं करता कि agent को action करने की authorization है, इसलिए authorization आपकी code में ही रहती है।

क्या Proof of Actor मेरी API traffic को rate-limit या block करना शुरू कर देगा?

नहीं। यह observation mode में शुरू होता है और by default कुछ भी block नहीं करता। rate-limit एक outcome है जिसे आप policy में चुन सकते हैं, 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 को आप classify नहीं कर सकते, उनका क्या होता है?

उन्हें Unknown के रूप में report किया जाता है, जो एक first-class result है। आप हर route के लिए fallback चुनते हैं, उदाहरण के लिए read-only endpoints पर allow करें और write endpoints पर अपने stricter checks बनाए रखें।

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

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

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

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