তুলনা

Proof of Actor বনাম user agent allowlist: এটা নাম এটা claim, proof নহয়

User-Agent string ভিত্তিক allowlisting চেটআপ কৰিবলৈ দ্ৰুত আৰু বুজিবলৈ সহজ। কিন্তু ই সহজে ভুলাই দিব পাৰি, কাৰণ header-টো client-এ যি পঠিয়াবলৈ বাছি লয় সেয়াই হয়। ইয়াত user agent allowlist-এ সঁচাকৈ আপোনাক কি কয়, network checks ক’ত সহায় কৰে, আৰু Proof of Actor-এ declaration আৰু verified evidence কেনেকৈ পৃথক কৰে সেয়া দিয়া হৈছে।

Early Access লওক ই কেনেকৈ কাম কৰে অন্বেষণ কৰক

দ্বাৰা Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

চুটি উত্তৰ

user agent allowlist-এ client-এ নিজৰ User-Agent header-ত যি নাম ৰাখে তাকে বিশ্বাস কৰে, আৰু যিকোনো client-এ যিকোনো নাম টাইপ কৰিব পাৰে। Reverse DNS আৰু published IP ranges-এ কিছুমান operator-ৰ বাবে বাস্তৱ evidence যোগ কৰে, কিন্তু কেৱল যিসকলে সেইবোৰ publish কৰে তেওঁলোকৰ ক্ষেত্ৰতহে। Proof of Actor-এ header-টোক এটা declaration হিচাপে ধৰে, agent-এ নিজৰ request sign কৰা ঠাইত signature check কৰে, আৰু evidence কম হলে Unknown report কৰে, যাতে আপোনাৰ code-এ facts দেখা অৱস্থাত সিদ্ধান্ত ল’ব পাৰে।

User agent allowlist হৈছে web-ৰ আটাইতকৈ পুৰণি pattern-সমূহৰ এটা। আপুনি বিশ্বাস কৰা crawler আৰু client নামৰ এখন তালিকা ৰাখে। যেতিয়া matching User-Agent header-সহ request আহে, আপুনি তাক যাবলৈ দিয়ে, challenge এৰাই যায়, বা হালকা page serve কৰে। ইয়াক set up কৰিবলৈ মিনিট লাগে আৰু team-ৰ সকলোয়ে এইটো বুজি পায়।

এই pattern-টো তেতিয়া অধিক যুক্তিসংগত আছিল, যেতিয়া মূল automated visitor আছিল কিছু search crawler আৰু কেইটামান monitoring tool। আজি AI agent, assistant আৰু automated client বাঢ়ি অহা সংখ্যাত application-লৈ আহে, আৰু তেওঁলোকৰ বহুতেই এটা নাম ঘোষণা কৰে। সেই নামবোৰৰ কিছুমান বাস্তৱ। কিছুমান কপি কৰা। Header-এ কোনটো কোনটো ক’ব নোৱাৰে।

Proof of Actor-এ এটা ভিন্ন approach লয়। ই User-Agent string-টোক যি আছে সেই হিচাপে, এটা declaration হিচাপে ধৰে, আৰু যেতিয়া stronger evidence থাকে সেই evidence-ৰ সৈতে একেলগে report কৰে। এই page-এ name-ভিত্তিক allowlisting-ৰ সীমা, network-level check ক’ত সহায় কৰে, আৰু verified signature আৰু explicit Unknown class-এ ছবিটো কেনেকৈ সলনি কৰে সেয়া ব্যাখ্যা কৰে।

The short version

	User agent allowlist	Proof of Actor
Main evidence	User-Agent header-ত এটা নাম	Signature, declaration আৰু signal, প্ৰতিটোকে নিজৰ basis-সহ label কৰা
Client-এ fake কৰিব পাৰেনে?	হয়, একে string পঠিয়াই	declared basis দাবী কৰিব পাৰি; verified basis-ৰ বাবে signing key লাগে
Output	তালিকাত আছে বা নাই	Human, Human + AI, Agent অথবা Unknown, আৰু এটা basis
অস্পষ্ট traffic	Not allowlisted হিচাপে ধৰা, বা default-এ allow কৰা	Unknown, যাৰ fallback আপুনি route-ভেদে বাছি লয়
AI-assisted people	অদৃশ্য; তেওঁলোকে ordinary browser ব্যৱহাৰ কৰে	declared বা observed হ’লে, পৃথক class, Human + AI
Maintenance	নাম সলনি হ’লে manual list update	agent operator-এ published কৰা key; আপোনাৰ code-ত policy
Install কৰাৰ সময়ৰ default	তালিকাই যি allow কৰে	Observation; আপুনি policy যোগ নকৰা লৈকে একোৱেই সলনি নহয়
Best at	সু-আচৰণকাৰী, known client-সমূহৰ cheap routing	product আৰু policy সিদ্ধান্তৰ বাবে evidence-based actor context

বাকী page-টোৱে প্ৰতিটো row ব্যাখ্যা কৰে।

Why allowlisting by User-Agent is spoofable

User-Agent header client-এ set কৰে। Browser-এ set কৰে, script-এ set কৰে, আৰু agent framework-এ set কৰে। HTTP-ত কোনো জিনিসে এই value-টো সত্য বুলি check নকৰে। যদি আপোনাৰ allowlist-এ এটা string বিশ্বাস কৰে, তেন্তে যি-ই সেই string copy কৰে সি একে treatment পায়।

ইয়াক user agent spoofing বোলা হয়, আৰু ই এটা সহজ কাৰণত সাধাৰণ: ইয়াৰ খৰচ একো নহয়। Challenge এৰাই যাব খোজা scraper-এ কেৱল আপুনি বিশ্বাস কৰা crawler-ৰ নামটো ধাৰ কৰিব লাগে। Unruly client-এ নিজকে জনপ্ৰিয় assistant বুলি দাবী কৰিব পাৰে। Legitimate tool-এও generic browser string পঠিয়াব পাৰে, কাৰণ library default-এ তেনেকৈ কৰিলে।

ফলত user agent allowlist-ৰ দুটা failure mode থাকে:

False trust: অবিশ্বাস্য client-এ বিশ্বাসযোগ্য নাম দাবী কৰে আৰু পাৰ হৈ যায়।
False doubt: বিশ্বাসযোগ্য client-এ অপ্ৰত্যাশিত বা generic string পঠিয়ায় আৰু fail কৰে।

Header-টো একাই এই দুয়োটাৰ কোনো এটা দেখুৱাব নোৱাৰে। এইটোৱেই মূল limitation, আৰু list maintenance-এ ইয়াক আঁতৰাই নেপাকে।

What the header is still good for

ইয়াৰ অৰ্থ এইটো নহয় যে আপুনি User-Agent string-সমূহ উপেক্ষা কৰিব লাগে। সু-আচৰণকাৰী crawler আৰু agent-এ honest ভাবে নিজৰ পৰিচয় দিয়ে, আৰু নামটো routing, analytics আৰু debugging-ৰ বাবে উপযোগী hint। ই আপোনাক কয় client-এ নিজকে কি বুলি কয়।

এই তথ্যৰ সঠিক স্থান হৈছে এটা declaration হিচাপে, আন evidence-ৰ সৈতে তুলনা কৰি, নিজৰ শক্তিত access unlock কৰা key হিচাপে নহয়। Proof of Actor-এ ঠিক সেইভাৱে record কৰে।

Reverse DNS and IP lists: partial measures

বহু team-এ network check-সহ allowlist শক্তিশালী কৰে। সিহঁতে সহায় কৰে, আৰু সেয়া সঠিককৈ বুজি ল’বলগীয়া।

Reverse DNS verification

কিছুমান crawler operator-এ verification process document কৰে: request-ৰ IP address-ৰ hostname lookup কৰক, সেয়া operator-ৰ domain-ৰ অন্তৰ্গত নে চাওক, তাৰপিছত সেই hostname lookup কৰি নিশ্চিত কৰক যে ই একে IP-লৈ resolve হয়। এই round trip সফল হ’লে, আপোনাৰ হাতত এই evidence থাকে যে request-টো operator-ৰ infrastructure-ৰ পৰা আহিছে।

ইয়াৰ সীমা ব্যৱহাৰিক। ই কেৱল সেই operator-সমূহৰ ক্ষেত্ৰত কাম কৰে যিসকলে এইটো document আৰু support কৰে। ইয়াৰ বাবে DNS lookup লাগে যি আপুনি cache কৰিব লাগিব। আৰু ই network-ৰ বিষয়ে কয়, সেই network-ত কোন product বা agent-এ request কৰিলে সেই বিষয়ে নহয়।

Published IP ranges

আন operator-এ তেওঁলোকৰ automated client-সমূহে ব্যৱহাৰ কৰা IP ranges publish কৰে। request-টোক সেই range-সমূহৰ সৈতে match কৰাটো দ্ৰুত, আৰু reverse DNS-ৰ দৰে similar evidence দিয়ে। IETF-ত এই ranges publish কৰাৰ বাবে এটা standard format-ৰ ওপৰত ongoing discussion চলিছে, কিন্তু November 2026 পৰ্যন্ত কোনো settled standard নাই, আৰু coverage প্ৰতিটো operator-এ publish কৰিবলৈ বাছি লোৱাৰ ওপৰত নিৰ্ভৰ কৰে।

IP evidence-ও দুর্বল হয় যেতিয়া অধিক agent shared cloud infrastructure-ত, proxy-ৰ পিছফালে, বা user-ৰ নিজৰ device-ৰ পৰা চলে। এটা cloud address-এ বহুত unrelated client host কৰিব পাৰে, আৰু এটা person-ৰ browser-ৰ পৰা act কৰা agent-এ সেই person-ৰ network-ৰ দৰে দেখা যায়।

What network checks add up to

Reverse DNS আৰু IP list-এ কিছুমান declaration-ক well-known operator-ৰ এটা subset-ৰ বাবে অধিক শক্তিশালী কিবা এটালৈ ৰূপান্তৰ কৰে। ই agent আৰু tool-সমূহৰ long tail cover নকৰে, আৰু AI-ৰ সৈতে কাম কৰা মানুহৰ ক্ষেত্ৰত একেবাৰে সহায় নকৰে। এইবোৰ partial measure: ব্যৱহাৰযোগ্য, কিন্তু একাই যথেষ্ট নহয়।

Signatures versus declarations

Evidence-ৰ অধিক শক্তিশালী ৰূপ হৈছে cryptographic signature। HTTP Message Signatures-ৰ সৈতে, যি RFC 9421-ত define কৰা হৈছে, client-এ প্ৰতিটো request-ৰ নিৰ্বাচিত অংশ private key-ৰে sign কৰে। Verifier-এ operator-ৰ published public key আনিছে আৰু signature check কৰে। যদি ই verify হয়, request-টো সেই key-ৰ holder-এ sign কৰিছিল, আৰু signed অংশবোৰ পথত সলনি কৰা হোৱা নাছিল।

IETF Web Bot Auth working group-এ automated client-এ কেনেকৈ এই signature ব্যৱহাৰ কৰে আৰু key কেনেকৈ publish কৰে সেয়া standardize কৰি আছে। আমাৰ Web Bot Auth for product teams explainer-এ current status সামৰি দিছে।

Proof of Actor-এ valid signature-ক Verified evidence হিচাপে ব্যৱহাৰ কৰে। User-Agent string, client hint বা request body-ত self-description-এ Declared হিচাপে গণ্য হয়। Behavioral আৰু contextual signal-এ Inferred হিচাপে গণ্য হয়, আৰু সেইভাৱেই label কৰা হয়। প্ৰতিটো result-এ সেয়া কোন basis-ৰ ওপৰত নিৰ্ভৰ কৰে সেয়া কয়, যাতে আপোনাৰ team-এ claim আৰু check-ৰ মাজত কেতিয়াও গলত নাখাই। পূৰ্ণ definition-ৰ বাবে evidence basis entry চাওক।

এটা সীমা verified evidence-ৰ ক্ষেত্ৰতো প্ৰযোজ্য। valid signature-এ কোন key-এ request sign কৰিলে সেয়া প্ৰমাণ কৰে। ই এইটো প্ৰমাণ নকৰে যে agent-এ যি কৰিবলৈ কৈছে সেইটো কৰিবলৈ অনুমতি আছে। সেয়া এটা agent authorization question, আৰু সেয়া আপোনাৰ application-তেই থাকে।

Handling Unknown instead of guessing

একটা allowlist-এ প্ৰতিটো request-ক দুটা bucket-ৰ এটাত জোৰ কৰে: তালিকাত আছে বা নাই। বাস্তৱত ইয়াৰ অৰ্থ হ’ল অস্পষ্ট traffic-এ আপোনাৰ default যি সেয়াই পায়, আৰু default সাধাৰণতে সম্পূৰ্ণ site-ৰ বাবে এদিনেই বাছি লোৱা হয়।

Proof of Actor-এ Unknown-ক প্ৰথম শ্ৰেণীৰ result হিচাপে ধৰে। Evidence-এ যেতিয়া reliable determination সমৰ্থন নকৰে, তেতিয়া ই অনুমান কৰাৰ সলনি সেইটো কয়। তাৰপিছত আপোনাৰ policy-এ route-ভেদে Unknown-ৰ অৰ্থ কি সেয়া সিদ্ধান্ত লয়:

Public documentation বা marketing page-ত, allow কৰক।
Search বা listing endpoint-ত, আপোনাৰ normal rate limits-সহ allow কৰক।
Account change-ত, আপোনাৰ existing check বজাই ৰাখক।
High-impact action-ত, review-লৈ পঠিয়াওক বা অধিক শক্তিশালী signal বিচাৰক।

handling Unknown traffic guide আৰু unknown classification entry-ত এই pattern-সমূহৰ walkthrough আছে। সময়ৰ সৈতে আপোনাৰ Unknown rate track কৰিলে আপোনাৰ traffic-ৰ কিমান অংশ এতিয়াও দুর্বল evidence-ৰ ওপৰত আছে সেয়াও জনা যায়।

What about AI-assisted people?

User agent allowlist-এ ordinary browser-ৰ ভিতৰত AI assistant ব্যৱহাৰ কৰা মানুহৰ বিষয়ে একো নকয়। তেওঁলোকৰ User-Agent এটা normal browser string। তেনেহ’লে বহু product-এ সেই interaction চিনাক্ত কৰিব খোজে, উদাহৰণস্বৰূপে AI-drafted submission label কৰিবলৈ বা AI-assisted user-এ onboarding-ৰ মাজেৰে কেনেকৈ আগবাঢ়ে সেয়া বুজিবলৈ।

Proof of Actor-এ supported integration-ৰ জৰিয়তে assistance declared বা observed হলে এই interaction-সমূহক Human + AI হিচাপে report কৰে। ই কেৱল writing style-ৰ ওপৰত নিৰ্ভৰ কৰি অনুমান নকৰে। অধিক জানিবলৈ AI-assisted interaction চাওক।

Moving from an allowlist to evidence-based policies

Day one-তে আপোনাৰ allowlist আঁতৰাবলৈ আপোনাৰ প্ৰয়োজন নাই। এটা safe path এনেকুৱা দেখায়:

Observation mode-ত install কৰক। Proof of Actor-এ একো সলনি নকৰে। আপোনাৰ allowlist কাম কৰি থাকিব।
Compare কৰক। প্ৰতিটো route-ৰ বাবে চাওক কোন allowlisted request-এ verified evidence বহন কৰে, কোনে কেৱল declaration বহন কৰে, আৰু কোন Unknown-এ শেষ হয়।
Policy preview কৰক। Verified agent, declared agent আৰু Unknown-ৰ বাবে পৃথক treatment থকা policy draft কৰক, আৰু real traffic-ত তাৰ effect preview কৰক।
Route by route enforce কৰক। যি route-ত spoofed name-ৰ প্ৰভাৱ আটাইতকৈ বেছি, তাত আৰম্ভ কৰক।
Allowlist-টো hint হিচাপে ৰাখক। Name-সমূহ routing আৰু analytics-ৰ বাবে উপযোগী হৈ থাকক, এতিয়া তেওঁলোকৰ basis দেখা যাব।

rolling out actor-aware policies safely guide-এ প্ৰতিটো step সামৰি দিছে, আৰু verified automated requests-এ signed client-সমূহ কেনেকৈ fit কৰে সেয়া ব্যাখ্যা কৰে।

When an allowlist is enough

কম-stakes routing-ৰ বাবে, যেনে public content-ত known crawler-লৈ হালকা page serve কৰা, user agent allowlist প্ৰায়ে যথেষ্ট হয়। Spoof কৰা নামৰ খৰচ কম।

যেতিয়া সিদ্ধান্তৰ প্ৰভাৱ থাকে, যেনে challenge skip কৰা, richer data উন্মুক্ত কৰা, বা write allow কৰা, তেতিয়া আপোনাৰ checked evidence লাগে। সেইখিনিত Proof of Actor-ৰ স্থান, আপুনি ইতিমধ্যে চলাই থকা network checks আৰু edge controls-ৰ সৈতে একেলগে।

Get started

Proof of Actor private beta-ত আছে। নিৰ্বাচিত founding developer team-সমূহে agreed usage limits-ৰ ভিতৰত 12 months পৰ্যন্ত free access পাব পাৰে, automatic billing নোহোৱাকৈ। Apply for early access কৰক আৰু আজিৰে পৰা আপুনি কোন client allowlist কৰে আৰু কোন route-সমূহক ভাল 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: ফলাফলৰ পিছৰ signal, যাতে আপোনাৰ দলক কাৰণ দেখা যায়।

observation mode-ত আৰম্ভ কৰক: আপোনাৰ log-ৰ কাষে ফলাফল record কৰক আৰু আপুনি policy বাছি নলৈকে একো সলনি নকৰিব। Node.js integration guide পঢ়ক

সঘনাই সোধা প্ৰশ্নসমূহ

User agent allowlist একেবাৰে অপ্ৰয়োজনীয় নেকি?

নহয়। সু-আচৰণকাৰী client-ৰ পৰা অহা এটা উপযোগী declaration আৰু known crawler-সমূহক route কৰাৰ এটা সস্তা উপায়। সমস্যা হৈছে ইয়াক proof হিচাপে গণ্য কৰা। যিকোনো client-এ যিকোনো User-Agent string পঠিয়াব পাৰে, সেয়েহে allowlist-এ একাই সংবেদনশীল action unlock কৰিব নালাগে।

Reverse DNS verification-এ User-Agent spoofing ঠিক কৰি দিয়া নাই নেকি?

যিসকল operator-এ এইটো document কৰে, তেওঁলোকৰ ক্ষেত্ৰত ই সহায় কৰে। Request-ৰ IP address-ৰ reverse lookup কৰি তাৰপিছত matching forward lookup কৰিলে এটা IP address operator-ৰ domain-ৰ সৈতে সংযুক্ত হয়। ই কেৱল সেই operator-সমূহৰ বাবেহে কাম কৰে যিসকলে এইটো support কৰে, আৰু shared cloud বা residential address-ৰ traffic সম্বন্ধে ই একো নকয়।

Proof of Actor-এ User-Agent header-টোক কেনেকৈ ধৰে?

একটা declaration হিচাপে। ই declared basis-ৰ সৈতে ফলাফলত যোগ দিয়ে, কেতিয়াও verified basis হিচাপে নহয়। Verified basis-ৰ বাবে প্ৰমাণ লাগে, যেনে published key-ৰ বিপৰীতে check কৰা HTTP Message Signature।

Verified signature-এ কি proof কৰে?

ইয়ে প্ৰমাণ কৰে কোন key-এ request sign কৰিলে আৰু signed অংশবোৰ সলনি কৰা হোৱা নাছিল। ই এইটো proof নকৰে যে agent-এ action কৰিবলৈ অনুমোদিত আছিল। Authorization আপোনাৰ application-তেই থাকে।

যিসকল client-এ নিজকে known agent বুলি দাবী কৰে কিন্তু verify কৰিব নোৱাৰি, তেওঁলোকৰ কি হয়?

Proof of Actor-এ evidence-এ যিমান সমৰ্থন কৰে সেয়াই report কৰে, প্ৰায়ে declared বা inferred result, অথবা Unknown। Claim কৰা নামৰ ওপৰত বিশ্বাস কৰাৰ সলনি আপোনাৰ policy-এ সেই route-ৰ fallback বাছি লয়।

Proof of Actor যোগ কৰিলে মোৰ বৰ্তমানৰ allowlist আচৰণ সলনি হ’ব নেকি?

নহয়। ই observation mode-ত আৰম্ভ হয়। কিবা সলনি কৰাৰ আগতে আপুনি real traffic-ত ইয়াৰ result-সমূহ আপোনাৰ allowlist সিদ্ধান্তৰ সৈতে তুলনা কৰিব পাৰে।

আপোনাৰ app ক কোনে ব্যৱহাৰ কৰিছে জানক।

এটা সৰু founding developer দলৰ বাবে private beta।

Early Access লওক মূল্য তালিকা চাওক

আগতে কথা পাতিবলৈ পচন্দ কৰেনে? Founding team-ৰ সৈতে কথা পাতক