તુલના

Proof of Actor vs API બોટ સુરક્ષા: keys કહે છે કોણ pay કરે છે, actor context કહે છે કોણ act કરી રહ્યું છે

API gateway, WAF bot rules, API keys અને rate limits તમારી API ને available અને accountable રાખે છે. તે આ જણાવવા માટે બનાવ્યા નહોતા કે request એપમાં કોઈ વ્યક્તિ પાસેથી આવી, કોઈ assistant સાથે કામ કરતી વ્યક્તિ પાસેથી આવી, કે autonomous agent પાસેથી. APIs માટે bot management Proof of Actor સાથે કેવી રીતે compare થાય છે અને બંને કેવી રીતે સાથે fit થાય છે તે અહીં છે.

પ્રારંભિક ઍક્સેસ મેળવો તે કેવી રીતે કાર્ય કરે છે તે અન્વેષણ કરો

દ્વારા Toshendra Sharmaસ્થાપક અને CEO, AgentCredia · Updated November 13, 2026

APIમાં પહેલાં traffic model સરળ હતો. કોઈ developer register થતો, key લેતો, integration લખતો, અને તે integration schedule મુજબ અથવા જ્યારે user કંઈક ક્લિક કરે ત્યારે તમારા endpoint ને call કરતું. API માટેનું bot management આ model આસપાસ વિકસ્યું: key authenticate કરો, volume cap કરો, સ્પષ્ટ રીતે abusive traffic filter કરો, અને service ને બાકીના સૌ માટે available રાખો.

આ model હજી પણ લાગુ પડે છે, અને તેના માટે બનાવાયેલા tools હજી પણ મહત્વના છે. બદલાયું છે calls પાછળ કોણ બેઠું છે તે. એ જ API key હવે તમારા customerના app નો ઉપયોગ કરતી વ્યક્તિ, કામ કરવા માટે AI assistant ને કહેનાર વ્યક્તિ, અને રાતભર multi-step task ચલાવતા autonomous agent પાસેથી requests લઈ શકે છે. તમારા હાલના controls એક key અને એક request rate જુએ છે. તમારા product, support અને policy નિર્ણયોને ઘણી વાર વધુ જાણવાની જરૂર પડે છે.

Proof of Actor આ gap ભરે છે. તે તમારી API ને કહે છે કે દરેક request પર કોણ અથવા શું act કરી રહ્યું છે અને evidence જણાવે છે, પછી નિર્ણય તમારા code પર છોડે છે. આ page તેને API bot protection ના મુખ્ય layers સાથે compare કરે છે જેથી તમે જોઈ શકો કે કયો ભાગ ક્યાં fit થાય છે.

ટૂંકું સંસ્કરણ

	API bot સુરક્ષા	Proof of Actor
મુખ્ય પ્રશ્ન	આ request allowed છે, authenticated છે અને limitsની અંદર છે?	કોણ અથવા શું act કરી રહ્યું છે, અને evidence શું છે?
સામાન્ય layers	API gateway, WAF bot rules, API keys, rate limits	તમારી API અથવા MCP serverની અંદર actor classification
ઓળખે છે	key ધરાવતું account અથવા integration	દરેક request પાછળનો actor: Human, Human + AI, Agent અથવા Unknown
Output	Allow, reject, throttle; ક્યારેક bot score	એક class અને basis: verified, declared, inferred અથવા unknown
અસ્પષ્ટ traffic	સામાન્ય રીતે key valid હોય તો allow, અથવા rule દ્વારા reject	Unknown, તમારા દ્વારા route પ્રમાણે પસંદ કરેલા fallback સાથે
Response કોણ નક્કી કરે	Gateway અને WAF configuration	તમારી application code
Install પર default	Enforcement	Observation; તમે policy ઉમેરો ત્યાં સુધી કંઈ બદલાતું નથી
શેમાં શ્રેષ્ઠ	Availability, abuse filtering, quotas, accountability	દરેક actor ને યોગ્ય રીતે serve કરવું અને API usage સમજવું

નીચેના sections દરેક ભાગ સમજાવે છે.

API bot સુરક્ષા શું સારું કરે છે

દરેક layerનું કામ શું છે તે સ્પષ્ટ હોવું જરૂરી છે, કારણ કે Proof of Actor એમના બાજુમાં રહેવા માટે બનાવાયું છે, કોઈને replace કરવા માટે નહીં.

API gateways

Gateway તમારી API માટેનું front door છે. તે connections terminate કરે છે, API keys અથવા tokens authenticate કરે છે, requests ને યોગ્ય service તરફ route કરે છે, quotas enforce કરે છે અને ઘણી વાર billing અને analytics માટે usage record કરે છે. તે દરેક endpoint પર ઝડપથી અને સતત પૂછે છે, "આ caller ને અંદર આવવા દેવું જોઈએ, અને કયા door દ્વારા?"

WAF bot rules

Bot rules ધરાવતું web application firewall જાણીતા attack patterns અને abusive automation માટે traffic inspect કરે છે. તે injection પ્રયાસો filter કરી શકે છે, abuse history ધરાવતા sourcesમાંથી traffic block કરી શકે છે, અને scraping અથવા credential attacks જેવા દેખાતા requests ને challenge અથવા drop કરી શકે છે. જે traffic તમારા code સુધી ક્યારેય પહોંચવું જ ન જોઈએ તેના સામે તે તમારી શ્રેષ્ઠ defense છે.

API keys અને tokens

Keys અને tokens તમને accountability આપે છે. દરેક request એક account સાથે map થાય છે, તેથી તમે જાણો છો કે કોની integration એ call કરી, તમે access revoke કરી શકો છો, અને usage attribute કરી શકો છો. Scoped tokens આથી આગળ જાય છે અને caller શું કરી શકે તે restrict કરે છે.

Rate limits

Rate limits availability protect કરે છે. તે એક integration ને દરેક માટે રાખેલી capacity consume કરવા દેતાં નથી, અને brute-force તથા enumeration પ્રયાસોને slow કરે છે. Per-key અને per-route limits એક standard, અસરકારક control છે.

આ layers સાથે protection અને accountabilityના પ્રશ્નોના ખૂબ સારાં જવાબ મળે છે. તેને રાખો.

તેઓ જે પ્રશ્નનો જવાબ આપવા માટે બનાવાયા નહોતા

આ layersમાંની કોઈપણ authenticated request પાછળ કયા પ્રકારનો actor છે તે જણાવવા માટે designed નથી. Valid key કહે છે કે કયું account integrationનું owner છે. તે આ નથી કહેતું:

કે આ ચોક્કસ call તમારા customerના appમાં button દબાવતી વ્યક્તિ પાસેથી આવી,
કે કોઈ વ્યક્તિએ AI assistant ને action કરવા કહ્યું,
કે autonomous agent એ લાંબા taskના એક step તરીકે call કરી,
અથવા કે કોઈ નક્કી કરી શકતું નથી.

આ ફરક દરેક મહિને વધુ મહત્વનો બને છે. CRM integration, scheduling tool અથવા developer platform serving કરતી API increasingly human-driven apps જેવી જ keys મારફતે agent traffic મેળવે છે. જો તમે agents ને structured response આપવા માંગતા હો, agents દ્વારા ચાલતા high-impact writes માટે confirmation માંગતા હો, AI-assisted submissions label કરવા માંગતા હો, અથવા તમારી API usage માંથી કેટલું agent-driven છે તે માત્ર માપવા માંગતા હો, તો તમને actor context જોઈએ.

Proof of Actor APIમાં શું ઉમેરે છે

Proof of Actor દરેક interaction માટે ચાર classes માંથી એક આપે છે:

Human: observable signals human-directed interaction બતાવે છે.
Human + AI: વ્યક્તિએ AI assistance સાથે interaction ચલાવ્યો, જે supported integration મારફતે declared અથવા observed થયું હતું.
Agent: automated અથવા agent-origin interaction.
Unknown: evidence વિશ્વસનીય determinationને support કરતું નથી.

દરેક result તેનું evidence basis પણ બતાવે છે:

Verified: ઉદાહરણ તરીકે, published key સામે ચકાસેલ HTTP Message Signature (RFC 9421).
Declared: client અથવા તમારું own application એ તેને stated કર્યું.
Inferred: behavioral અથવા contextual signals, inference તરીકે સ્પષ્ટપણે labeled.
Unknown: કોઈ વિશ્વસનીય basis નથી.

APIs માટે verified basis ખાસ ઉપયોગી છે. જે agents પોતાની requests sign કરે છે તેમને તેમના published keys સામે check કરી શકાય છે, અને આ જ approach પાછળ IETF Web Bot Auth કામ છે. background માટે Web Bot Auth for product teams explainer વાંચો, અને implementation બાજુ માટે verifying signed agent requests guide જુઓ.

અહીં એક મર્યાદા મહત્વની છે. Valid signature એ સાબિત કરે છે કે request કી દ્વારા sign થઈ હતી. તે agent ને action કરવા અધિકૃત છે તે સાબિત કરતું નથી. Authorization જ્યાં હોવું જોઈએ ત્યાં જ રહે છે, તમારી APIની own access controlમાં. agent authorization entry ફરક સમજાવે છે.

Scores અને keys સામે actor evidence

કેટલાક bot protection products દરેક request સાથે score જોડે છે. Block decision માટે score અસરકારક છે. API product decisions માટે તે ઓછું ઉપયોગી છે, કારણ કે તે જણાવતું નથી કે legitimate request human-driven હતી કે agent-driven, અને તે verified facts ને inference થી અલગ પણ કરતું નથી.

API keys તેનો વિપરીત મર્યાદા ધરાવે છે. તે 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ની સામે ચાલે છે. Protection અને quotas માટે આ position યોગ્ય છે.

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 verified થઈ છે કે નહીં.

Routing decisions તમારા codeમાં જ રહે છે

Proof of Actor default દ્વારા કંઈ block કરતું નથી. તે observation mode માં શરૂ થાય છે, એટલે તેને install કરવાથી તમારી API કેવી રીતે respond કરે છે તેમાં કંઈ બદલાતું નથી. તમે 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 ને person દ્વારા ચકાસવા માટે queueમાં મૂકો.
Rate-limit: ચોક્કસ route પર ચોક્કસ class અને basis માટે વધુ કડક limit લાગુ કરો.

તમે policy ને enforce કરતા પહેલાં real traffic સામે preview કરી શકો છો, પછી route by route enforce કરો. rolling out actor-aware policies safely guide process cover કરે છે, અને protecting sensitive actions without blocking agents સામાન્ય patterns બતાવે છે.

Unknown API callersનું handling

દરેક APIને એવી traffic મળે છે જેને confidence સાથે classify કરી શકાય નહીં. Traditional controls સાથે, valid key સામાન્ય રીતે request ને આગળ જવા દે છે, અને invalid key તેને રોકે છે. વચ્ચે કંઈ નથી.

Proof of Actor તમને explicit Unknown result આપે છે અને route પ્રમાણે fallback પસંદ કરવા દે છે. Read-only catalog endpoints ખુલ્લા રહી શકે છે. Account changes પર તમારા હાલના stricter checks રહી શકે છે. Bulk exports reviewમાં જઈ શકે છે. વિગતો માટે handling Unknown traffic અને unknown automated traffic જુઓ.

તેઓ કેવી રીતે combine થાય છે

સૌથી મજબૂત API setup દરેક layerને તેના પોતાના કામ માટે ઉપયોગ કરે છે:

Edge પર, WAF abusive અને malformed traffic filter કરે છે.
Gateway પર, keys authenticate થાય છે, quotas enforce થાય છે અને 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માં, તમારી ટીમ gatewayમાંથી આવતા account data સાથે દરેક actor class કયા endpoint અને workflow ઉપયોગ કરે છે તે જુએ છે.

આ stackમાં કંઈ duplicated નથી. Gateway account જાણે છે, WAF threat patterns જાણે છે, અને Proof of Actor actor જાણે છે.

ક્યારે ક્યા પર ધ્યાન આપવું

જ્યારે તમારી મુખ્ય સમસ્યાઓ abuse, availability અથવા unmetered usage હોય ત્યારે પહેલા API bot સુરક્ષા પર ધ્યાન આપો: auth endpoints સામે credential attacks, aggressive scraping, અથવા એક integration દ્વારા બીજાઓને capacityથી વંચિત કરવું.

જ્યારે તમારા મુખ્ય પ્રશ્નો તમારા 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 વધુ વિગત આપે છે.

ઉત્પાદનમાં API ચલાવતા મોટાભાગની teams ને બંને પ્રશ્નોના જવાબોની જરૂર પડે છે.

શરૂ કરો

Proof of Actor private betaમાં છે. પસંદ કરેલી founding developer teams ને agreed usage limitsની અંદર, no automatic billing સાથે, up to 12 monthsનું free access મળી શકે છે. Apply for 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: પરિણામ પાછળના signals, જેથી તમારી team કારણ જોઈ શકે.

observation mode માં શરૂ કરો: પરિણામોને તમારા logsની બાજુમાં નોંધો અને તમે policy પસંદ કરો ત્યાં સુધી કંઈ બદલશો નહીં. Node.js integration guide વાંચો

વારંવાર પૂછાતા પ્રશ્નો

શું Proof of Actor મારું API gateway અથવા WAF replace કરે છે?

ના. તમારું gateway હજી પણ keys ને authenticate કરે છે અને quotas enforce કરે છે, અને તમારું WAF હજી પણ abusive traffic ને filter કરે છે. Proof of Actor તમારી APIની અંદર ચાલે છે અને પસાર થતી requests માં actor context ઉમેરે છે. તમારા હાલના controls જાળવો.

જો દરેક caller પાસે API key હોય, તો મને actor contextની જરૂર શા માટે?

API key integration નો માલિક account ઓળખે છે. તે એ નથી જણાવતું કે કોઈ ચોક્કસ request તમારા customerના app માં button ક્લિક કરતી વ્યક્તિ દ્વારા driven હતી, AI assistant વાપરતી વ્યક્તિ દ્વારા, કે task ચલાવતા autonomous agent દ્વારા. Proof of Actor તેનો basis સાથે આ report કરે છે.

શું Proof of Actor મારા API ને કયો agent call કરે છે તે verify કરી શકે છે?

જ્યારે client તેની requests ને HTTP Message Signatures (RFC 9421) સાથે sign કરે છે અને તેની key publish કરે છે, ત્યારે Proof of Actor signature check કરે છે અને verified basis report કરે છે. Valid signature એ સાબિત કરે છે કે request કી દ્વારા sign થઈ હતી. તે agent ને action કરવા અધિકૃત છે તે સાબિત કરતું નથી, એટલે authorization તમારા codeમાં જ રહે છે.

શું Proof of Actor મારી API traffic ને rate-limit અથવા block કરવાનું શરૂ કરશે?

ના. તે 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 server માટે તેમની પોતાની integration છે. વિગતો માટે integrations page જુઓ.

જે callers ને તમે classify કરી શકતા નથી તેમનું શું થાય છે?

તેમને Unknown તરીકે report કરવામાં આવે છે, જે પ્રથમ-શ્રેણીનું result છે. તમે દરેક route માટે fallback પસંદ કરો છો, ઉદાહરણ તરીકે read-only endpoints પર allow કરો અને write endpoints પર તમારી stricter checks ચાલુ રાખો.

તમારા app નો ઉપયોગ કોણ કરે છે તે જાણો.

Founding developers ના નાના સમૂહ માટે private beta.

પ્રારંભિક ઍક્સેસ મેળવો કિંમત જુઓ

પહેલાં વાત કરવી પસંદ કરો છો? સ્થાપકો સાથે વાત કરો