તુલના

Proof of Actor vs user agent allowlists: નામ એક દાવો છે, પુરાવો નથી

User-Agent string દ્વારા allowlisting કરવું ઝડપથી સેટ થઈ જાય છે અને સમજવામાં સરળ છે. તેને ભ્રમિત કરવું પણ સરળ છે, કારણ કે header તે જ છે જે client મોકલવાનું પસંદ કરે છે. અહીં user agent allowlist વાસ્તવમાં તમને શું કહે છે, network checks ક્યાં મદદ કરે છે, અને Proof of Actor કેવી રીતે declarations ને verified evidence થી અલગ કરે છે તે બતાવવામાં આવ્યું છે.

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

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

ટૂંકો જવાબ

એક user agent allowlist client તેના User-Agent header માં જે નામ મૂકે છે તેના પર વિશ્વાસ કરે છે, અને કોઈપણ client કોઈપણ નામ દાખલ કરી શકે છે. Reverse DNS અને published IP ranges કેટલાક operators માટે વાસ્તવિક evidence ઉમેરે છે, પરંતુ ફક્ત તેમના માટે જ, જે તેને પ્રકાશિત કરે છે. Proof of Actor header ને declaration તરીકે ગણાવે છે, જ્યાં agents તેમના requests sign કરે છે ત્યાં signatures તપાસે છે, અને evidence નબળું હોય ત્યારે Unknown દર્શાવે છે, જેથી તમારી code facts ને નજર સમક્ષ રાખીને નિર્ણય કરે.

User agent allowlist વેબના સૌથી જૂના patterns માંનું એક છે. તમે વિશ્વાસ રાખતા crawler અને client names ની યાદી રાખો છો. જ્યારે request મેળ ખાતા User-Agent header સાથે આવે છે, ત્યારે તમે તેને પસાર થવા દો છો, challenge છોડો છો, અથવા તેને હળવું page આપો છો. તેને સેટ કરવા માટે મિનિટો લાગે છે અને ટીમમાં દરેક તેને સમજે છે.

આ pattern ત્યારે વધુ અર્થપૂર્ણ હતું જ્યારે મુખ્ય automated visitors થોડા search crawlers અને થોડાં monitoring tools હતા. આજે, AI agents, assistants અને automated clients વધતી સંખ્યામાં applications સુધી પહોંચે છે, અને તેમાંના ઘણા પોતાનું નામ જાહેર કરે છે. આ નામોમાંથી કેટલાક સાચા હોય છે. કેટલાક નકલ કરાયેલા હોય છે. header તમને કયું છે તે કહી શકતો નથી.

Proof of Actor એક અલગ approach લે છે. તે User-Agent string ને તે જ રીતે લે છે જેમ તે છે, એટલે કે declaration, અને જ્યાં તે evidence હાજર હોય ત્યાં stronger evidence સાથે તેને report કરે છે. આ page નામ દ્વારા allowlisting ની મર્યાદાઓ, network-level checks ક્યાં મદદરૂપ છે, અને verified signatures તથા explicit Unknown class picture કેવી રીતે બદલે છે તે સમજાવે છે.

ટૂંકો સાર

	User agent allowlist	Proof of Actor
મુખ્ય evidence	User-Agent header માંનું નામ	Signatures, declarations અને signals, દરેકને તેના basis સાથે label કરેલું
શું client તેને fake કરી શકે?	હા, એ જ string મોકલીને	declared basis દાવો થઈ શકે છે; verified basis માટે signing key જરૂરી છે
Output	યાદીમાં અથવા બહાર	Human, Human + AI, Agent અથવા Unknown, સાથે basis
અસ્પષ્ટ traffic	allowlisted નથી એવું માનવામાં આવે છે, અથવા default રૂપે મંજૂરી મળે છે	Unknown, route દીઠ તમે પસંદ કરો તે fallback સાથે
AI-સહાયિત લોકો	અદૃશ્ય; તેઓ સામાન્ય browsers વાપરે છે	જ્યારે declared અથવા observed હોય ત્યારે અલગ વર્ગ, Human + AI
જાળવણી	નામો બદલાય ત્યારે manual list updates	agent operators દ્વારા published keys; તમારી code માં policies
install સમયે default	યાદી જે મંજૂર કરે તે બધું	Observation; તમે policy ઉમેરો ત્યાં સુધી કંઈ બદલાતું નથી
શ્રેષ્ઠ શું માટે	સારી રીતે વર્તતા, જાણીતા clients નું સસ્તુ routing	product અને policy decisions માટે evidence આધારિત actor context

પાનાનો બાકી ભાગ દરેક row સમજાવે છે.

User-Agent દ્વારા allowlisting spoofable કેમ છે

User-Agent header client દ્વારા set થાય છે. Browser તેને set કરે છે, script તેને set કરે છે, અને agent framework પણ તેને set કરે છે. HTTP માં કંઈપણ ચકાસતું નથી કે value સાચી છે. જો તમારી allowlist string પર વિશ્વાસ કરે છે, તો જે કોઈ તે string copy કરે તેને એ જ treatment મળે છે.

આને user agent spoofing કહેવામાં આવે છે, અને તે એક સરળ કારણસર સામાન્ય છે: તેની કિંમત કંઈ નથી. Challenge ટાળવા માંગતો scraper માત્ર તમે વિશ્વાસ કરતા crawler નું નામ ઉધાર લઈ લે છે. ખોટી વર્તણૂક કરતો client પોતાને લોકપ્રિય assistant તરીકે રજૂ કરી શકે છે. ક્યારેક legitimate tool પણ generic browser string મોકલે છે, કારણ કે library નો default એ કર્યું હતું.

પરિણામે, user agent allowlist ના બે failure modes થાય છે:

ખોટો વિશ્વાસ: અવિશ્વસનીય client વિશ્વાસપાત્ર નામ દાવો કરે છે અને પસાર થઈ જાય છે.
ખોટો સંદેહ: legitimacy ધરાવતો client અણધાર્યો અથવા generic string મોકલે છે અને નિષ્ફળ જાય છે.

આમાંથી કોઈપણ failure header થી જ દેખાતું નથી. એ જ મૂળ મર્યાદા છે, અને list maintenance ની કોઈ પણ માત્રા તેને દૂર કરતી નથી.

આ બધાનો અર્થ એ નથી કે તમને User-Agent strings ને અવગણવી જોઈએ. સારી રીતે વર્તતા crawlers અને agents પોતાને ઈમાનદારીથી રજૂ કરે છે, અને નામ routing, analytics અને debugging માટે ઉપયોગી સંકેત છે. તે તમને client પોતે શું કહે છે તે જણાવે છે.

આ માહિતી માટે યોગ્ય સ્થાન declaration તરીકે છે, અન્ય evidence સાથે મૂલ્યાંકન કરીને, access ખોલી આપતી કી તરીકે નહીં. Proof of Actor તેને એ જ રીતે record કરે છે.

Reverse DNS અને IP lists: આંશિક ઉપાયો

ઘણી ટીમો network checks સાથે allowlist ને મજબૂત કરે છે. તે મદદ કરે છે, અને તેને ચોક્કસ રીતે સમજવું યોગ્ય છે.

Reverse DNS verification

કેટલાક crawler operators એક verification process document કરે છે: request ના IP address માટે hostname શોધો, તે operator ના domain નો છે કે નહીં તે તપાસો, પછી તે hostname lookup કરીને ખાતરી કરો કે તે same IP પર resolve થાય છે. જ્યારે આ round trip સફળ થાય છે, ત્યારે તમારા હાથમાં વાસ્તવિક evidence હોય છે કે request operator ની infrastructure માંથી આવી હતી.

મર્યાદાઓ વ્યવહારિક છે. તે ફક્ત એવા operators માટે કામ કરે છે જે તેને document કરે છે અને support કરે છે. તેમાં DNS lookups ઉમેરાય છે જેને તમને cache કરવું પડે છે. અને તે તમને network વિશે કહે છે, ન કે તે network પર કયું product અથવા agent request કરી રહ્યું હતું તે વિશે.

Published IP ranges

અન્ય operators તેમના automated clients ઉપયોગ કરે છે તે IP ranges પ્રકાશિત કરે છે. request ને તે ranges સામે match કરવું ઝડપી છે અને reverse DNS જેવી જ evidence આપે છે. IP ranges publish કરવા માટે standard format અંગે ongoing IETF discussion છે, પરંતુ November 2026 સુધી કોઈ settled standard નથી, અને coverage દરેક operator publish કરવાનું પસંદ કરે છે કે નહીં તેના પર આધારિત છે.

જેમ જેમ વધુ agents shared cloud infrastructure પર, proxies પાછળ, અથવા user ના પોતાના device પરથી ચાલે છે તેમ IP evidence પણ નબળું પડે છે. એક cloud address ઘણા unrelated clients ને host કરી શકે છે, અને કોઈ person ના browser માંથી કાર્યરત agent તે person ના network જેવો જ દેખાય છે.

Network checks એકસાથે શું ઉમેરે છે

Reverse DNS અને IP lists કેટલીક declarations ને well-known operators ના subset માટે કંઈક વધુ મજબૂત બનાવે છે. તે agents અને tools ની લાંબી tail ને આવરી લેતા નથી, અને AI સાથે કામ કરતા લોકો માટે તો બિલકુલ મદદરૂપ નથી. તે આંશિક ઉપાયો છે: ઉપયોગી, પણ પોતાની જાતે પૂરતા નથી.

Signatures સામે declarations

Evidence નો વધુ મજબૂત રૂપ cryptographic signature છે. HTTP Message Signatures સાથે, જે RFC 9421 માં વ્યાખ્યાયિત છે, client દરેક request ના પસંદ કરેલા ભાગો private key વડે sign કરે છે. Verifier operator ની published public key fetch કરે છે અને signature તપાસે છે. જો તે verify થાય, તો request key ના holder દ્વારા sign કરવામાં આવી હતી, અને માર્ગમાં signed parts બદલાયા નથી.

IETF Web Bot Auth working group automated clients signatures કેવી રીતે ઉપયોગ કરે છે અને તેઓ પોતાની keys કેવી રીતે publish કરે છે તે standardize કરી રહ્યું છે. અમારા Web Bot Auth for product teams explainer માં વર્તમાન સ્થિતિ આવરી લેવામાં આવી છે.

Proof of Actor માન્ય signature ને Verified evidence તરીકે વાપરે છે. User-Agent string, client hint અથવા request body માં self-description ને Declared ગણવામાં આવે છે. Behavioral અને contextual signals Inferred ગણાય છે, અને એ રીતે label થાય છે. દરેક result જણાવે છે કે તે કયા basis પર આધારિત છે, જેથી તમારી ટીમ ક્યારેય દાવાને તપાસ સાથે ગૂંચવતી નથી. સંપૂર્ણ વ્યાખ્યાઓ માટે evidence basis entry જુઓ.

એક મર્યાદા verified evidence પર પણ લાગુ પડે છે. માન્ય signature સાબિત કરે છે કે કઈ key એ request sign કરી. તે સાબિત કરતું નથી કે agent તે જે માંગે છે તે કરવા માટે authorized છે. તે agent authorization નો પ્રશ્ન છે, અને તે તમારી application માં જ રહે છે.

અંદાજ લગાવવાના બદલે Unknown સંભાળવું

Allowlist દરેક request ને બે જ buckets માં મૂકે છે: યાદીમાં છે અથવા નથી. વ્યવહારમાં તેનો અર્થ એ થાય છે કે અસ્પષ્ટ traffic ને તમારા default મુજબ વર્તાવવામાં આવે છે, અને default સામાન્ય રીતે આખા site માટે એકવાર જ નક્કી કરવામાં આવે છે.

Proof of Actor Unknown ને પ્રથમ વર્ગનું result માને છે. જ્યારે evidence વિશ્વસનીય નિર્ધારણને support ન કરે, ત્યારે તે અંદાજ લગાવવાને બદલે એમ જ કહે છે. પછી તમારી policies દરેક route પર Unknown નો અર્થ શું થાય છે તે નક્કી કરે છે:

જાહેર documentation અથવા marketing pages પર, તેને allow કરો.
Search અથવા listing endpoints પર, તમારા સામાન્ય rate limits સાથે તેને allow કરો.
Account changes પર, તમારી હાલની checks જાળવો.
ઊંચા પ્રભાવના actions પર, તેને review માટે મોકલો અથવા વધુ મજબૂત signal માંગો.

handling Unknown traffic માટેનું guide અને unknown classification entry આ patterns સમજી આપે છે. સમય સાથે તમારો Unknown rate track કરવાથી પણ ખબર પડે છે કે તમારા traffic નો કેટલો ભાગ હજુ નબળા evidence પર આધારિત છે.

AI-સહાયિત લોકો વિશે શું?

સામાન્ય browser અંદર AI assistant વાપરતા person વિશે user agent allowlist કંઈ કહેતી નથી. તેમનો User-Agent સામાન્ય browser string હોય છે. છતાં ઘણા products આ interaction ને ઓળખવા માંગે છે, ઉદાહરણ તરીકે AI-drafted submissions label કરવા અથવા AI-assisted users onboarding માં કેવી રીતે આગળ વધે છે તે સમજવા માટે.

Proof of Actor આ interactions ને Human + AI તરીકે report કરે છે જ્યારે assistance declared હોય અથવા supported integration દ્વારા observed હોય. તે માત્ર writing style પરથી અંદાજ લગાવતું નથી. વધુ માટે AI-assisted interaction જુઓ.

Allowlist થી evidence-based policies તરફ આગળ વધવું

તમારે પ્રથમ દિવસે જ allowlist દૂર કરવાની જરૂર નથી. સુરક્ષિત માર્ગ આવો દેખાય છે:

Observation mode માં install કરો. Proof of Actor કંઈ બદલતું નથી. તમારી allowlist કામ કરતી રહે છે.
તુલના કરો. દરેક route માટે જુઓ કે કયા allowlisted requests પાસે verified evidence છે, કયા પાસે માત્ર declaration છે, અને કયા Unknown બને છે.
Policies preview કરો. એવી policy draft કરો જે verified agents, declared agents અને Unknown ને અલગ રીતે સંભાળે, અને વાસ્તવિક traffic પર તેનો અસર preview કરો.
Route by route enforce કરો. એવા routes થી શરૂઆત કરો જ્યાં spoofed નામ સૌથી વધુ મહત્વ ધરાવે છે.
Allowlist ને hint તરીકે રાખો. નામો routing અને analytics માટે ઉપયોગી રહે છે, હવે તેમનો basis દેખાય છે.

rolling out actor-aware policies safely માટેનો guide દરેક પગલું આવરી લે છે, અને verified automated requests સમજાવે છે કે signed clients કેવી રીતે fit થાય છે.

Allowlist ક્યારે પૂરતી છે

ઓછા જોખમના routing માટે, જેમ કે public content પર જાણીતા crawler ને હળવું page આપવા માટે, user agent allowlist ઘણીવાર પૂરતી હોય છે. spoofed નામની કિંમત ઓછી હોય છે.

જ્યારે નિર્ણયના પરિણામો હોય, જેમ કે challenge છોડવો, વધુ સમૃદ્ધ data ખુલ્લું કરવું, અથવા write કરવાની મંજૂરી આપવી, ત્યારે તમને તપાસી શકાય એવું evidence જોઈએ. ત્યાં Proof of Actor સંબંધિત છે, જે તમે પહેલેથી ચલાવતા network checks અને edge controls સાથે કામ કરે છે.

શરૂઆત કરો

Proof of Actor private beta માં છે. પસંદ કરેલી founding developer teams ને સંમત usage limits હેઠળ, automatic billing વગર, 12 months સુધીની free access મળી શકે છે. Apply for early access અને અમને જણાવો કે આજે તમે કયા clients ને allowlist કરો છો અને કયા routes ને વધુ સારા evidence સાથે protect કરવા માંગો છો.

વિકાસકર્તાઓ માટે

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 વાંચો

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

શું user agent allowlist બિનઉપયોગી છે?

ના. તે સારી રીતે વર્તતા clients તરફથી મળતું ઉપયોગી declaration છે અને જાણીતા crawlers ને route કરવા માટે સસ્તો રસ્તો છે. સમસ્યા તેને proof તરીકે માનવાની છે. કોઈપણ client કોઈપણ User-Agent string મોકલી શકે છે, તેથી allowlist માત્રથી sensitive actions ક્યારેય unlock ન થવા જોઈએ.

શું reverse DNS verification User-Agent spoofing ને ઠીક કરે છે?

જે operators તેને document કરે છે તેમના માટે તે મદદરૂપ થાય છે. Reverse lookup પછી matching forward lookup કરવાથી IP address ને operator ના domain સાથે જોડાણ મળે છે. તે ફક્ત એવા operators માટે કામ કરે છે જે તેને support કરે છે, અને shared cloud અથવા residential addresses પરથી આવતાં traffic વિશે તે કંઈ કહેતો નથી.

Proof of Actor User-Agent header ને કેવી રીતે સંભાળે છે?

Declaration તરીકે. તે પરિણામમાં declared basis સાથે યોગદાન આપે છે, ક્યારેય verified basis તરીકે નહીં. Verified basis માટે HTTP Message Signature જેવી evidence જરૂરી છે, જે published key સામે તપાસવામાં આવે છે.

Verified signature શું સાબિત કરે છે?

તે સાબિત કરે છે કે કઈ key એ request sign કરી અને signed parts બદલાયા નથી. તે સાબિત કરતું નથી કે agent ને આ action કરવા માટે authority છે. Authorization તમારી application માં જ રહે છે.

જ્યારે clients પોતાને known agent તરીકે દાવો કરે છે પરંતુ verify થઈ શકતા નથી ત્યારે શું થાય છે?

Proof of Actor evidence જે support કરે છે તે દર્શાવે છે, ઘણીવાર declared અથવા inferred result, અથવા Unknown. તમારી policy તે route માટે fallback શું હશે તે નક્કી કરે છે, દાવા કરાયેલા નામ પર વિશ્વાસ કરીને નહીં.

શું Proof of Actor ઉમેરવાથી મારી હાલની allowlist વર્તણૂક બદલાશે?

ના. તે observation mode માં શરૂ થાય છે. કંઈપણ બદલ્યા પહેલાં તમે વાસ્તવિક traffic પર તેના પરિણામોની તમારી allowlist decisions સાથે તુલના કરી શકો છો.

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

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

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

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