তুলনা

Proof of Actor বনাম user agent allowlist: একটি নাম একটি দাবি, প্রমাণ নয়

User-Agent string দিয়ে allowlisting করা দ্রুত সেট আপ করা যায় এবং সহজে বোঝা যায়। এটিকে ফাঁকি দেওয়াও সহজ, কারণ header হলো client যা পাঠাতে চায় সেটাই। এখানে দেখানো হয়েছে user agent allowlist আসলে কী বলে, network check কোথায় সাহায্য করে, এবং Proof of Actor কীভাবে declaration-কে verified evidence থেকে আলাদা করে।

প্রাথমিক access পান কীভাবে কাজ করে তা অন্বেষণ করুন

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

সংক্ষিপ্ত উত্তর

একটি user agent allowlist client-এর User-Agent header-এ দেওয়া যে কোনো নামকে বিশ্বাস করে, এবং যে কোনো client যে কোনো নাম টাইপ করতে পারে। Reverse DNS এবং প্রকাশিত IP range কিছু operator-এর জন্য বাস্তব evidence যোগ করে, কিন্তু শুধু তাদের ক্ষেত্রেই যারা সেগুলো প্রকাশ করে। Proof of Actor header-কে একটি declaration হিসেবে ধরে, যেখানে agent তাদের request sign করে সেখানে signature check করে, এবং evidence পাতলা হলে Unknown রিপোর্ট করে, যাতে আপনার code facts সামনে রেখে সিদ্ধান্ত নিতে পারে।

User agent allowlist web-এর সবচেয়ে পুরনো patternগুলোর একটি। আপনি এমন crawler এবং client নামের একটি তালিকা রাখেন যাদের আপনি বিশ্বাস করেন। যখন কোনো request matching User-Agent header নিয়ে আসে, আপনি সেটিকে allow করেন, challenge এড়িয়ে যান, বা একটি হালকা page serve করেন। সেট আপ করতে মিনিট লাগে এবং team-এর সবাই এটি বুঝতে পারে।

এই pattern আরও অর্থবহ ছিল যখন প্রধান automated visitor ছিল কয়েকটি search crawler এবং কিছু monitoring tool। আজ AI agent, assistant এবং automated client বাড়তে থাকা সংখ্যায় application-এ পৌঁছাচ্ছে, এবং তাদের অনেকেই একটি নাম ঘোষণা করে। সেই নামগুলোর কিছু বাস্তব। কিছু কপি করা। header আপনাকে বলতে পারে না কোনটি কোনটি।

Proof of Actor ভিন্ন পদ্ধতি নেয়। এটি একটি User-Agent string-কে তার আসল রূপে, অর্থাৎ একটি declaration হিসেবে ধরে, এবং stronger evidence থাকলে সেটির সঙ্গে সেটিকে রিপোর্ট করে। এই page-এ দেখানো হয়েছে নাম দিয়ে allowlisting-এর সীমা, network-level check কোথায় সাহায্য করে, এবং verified signature ও একটি স্পষ্ট Unknown class কীভাবে চিত্রটি বদলায়।

সংক্ষিপ্ত সংস্করণ

	User agent allowlist	Proof of Actor
প্রধান evidence	User-Agent header-এ একটি নাম	Signature, declaration এবং signal, প্রতিটি তাদের basis সহ চিহ্নিত
client কি এটি নকল করতে পারে?	হ্যাঁ, একই string পাঠিয়ে	একটি declared basis দাবি করা যেতে পারে; একটি verified basis-এর জন্য signing key দরকার
output	তালিকায় আছে বা নেই	Human, Human + AI, Agent বা Unknown, সঙ্গে একটি basis
অস্পষ্ট traffic	allowlist-এ নেই হিসেবে ধরা হয়, বা defaultভাবে allow করা হয়	Unknown, route প্রতি আপনার বেছে নেওয়া fallback সহ
AI-assisted মানুষ	অদৃশ্য; তারা সাধারণ browser ব্যবহার করে	একটি পৃথক class, Human + AI, যখন declared বা observed হয়
রক্ষণাবেক্ষণ	নাম বদলালে list হাতে আপডেট করতে হয়	agent operator-রা key প্রকাশ করে; policy আপনার code-এ থাকে
install-এর সময় default	তালিকা যা allow করে তাই	Observation; আপনি policy যোগ না করা পর্যন্ত কিছুই বদলায় না
সবচেয়ে ভালো	ভালোভাবে আচরণ করা, পরিচিত client-এর সস্তা routing	product এবং policy সিদ্ধান্তের জন্য evidence-based actor context

বাকি page-এ প্রতিটি row ব্যাখ্যা করা হয়েছে।

কেন User-Agent দিয়ে allowlisting spoof করা যায়

User-Agent header client দ্বারা set করা হয়। একটি browser এটি set করে, একটি script এটি set করে, এবং একটি agent framework এটি set করে। HTTP-এর মধ্যে এমন কিছু নেই যা যাচাই করে যে valueটি সত্য কি না। আপনার allowlist যদি একটি string বিশ্বাস করে, তাহলে যে কেউ সেই string কপি করলে একই treatment পায়।

এটিকে user agent spoofing বলা হয়, এবং এটি একটি সহজ কারণে সাধারণ: এর খরচ কিছুই নয়। যে scraper একটি challenge এড়াতে চায় তাকে শুধু আপনার বিশ্বাসী একটি crawler-এর নাম ধার নিতে হয়। একটি misbehaving client নিজেকে একটি জনপ্রিয় assistant বলে দাবি করতে পারে। একটি legitimate tool-ও generic browser string পাঠাতে পারে কারণ একটি library default সেটাই করেছে।

ফলে user agent allowlist-এর দুটি failure mode থাকে:

False trust: একটি অবিশ্বস্ত client একটি বিশ্বাসযোগ্য নাম দাবি করে এবং পাস করে।
False doubt: একটি legitimate client অপ্রত্যাশিত বা generic string পাঠায় এবং ব্যর্থ হয়।

শুধু header দেখে এই দুই failure-ই দেখা যায় না। এটাই মূল সীমাবদ্ধতা, এবং list maintenance যতই করা হোক এটি দূর হয় না।

এর মানে এই নয় যে আপনাকে User-Agent string উপেক্ষা করতে হবে। ভালোভাবে আচরণ করা crawler এবং agent নিজেদের সৎভাবে পরিচয় দেয়, এবং নামটি routing, analytics এবং debugging-এর জন্য একটি দরকারি সংকেত। এটি বলে একটি client নিজেকে কী বলে।

এই তথ্যের সঠিক জায়গা হলো একটি declaration হিসেবে, অন্য evidence-এর সঙ্গে ওজন করে দেখা, একা access খুলে দেওয়ার চাবি হিসেবে নয়। Proof of Actor এটিকে ঠিক সেইভাবেই record করে।

Reverse DNS এবং IP list: আংশিক ব্যবস্থা

অনেক team allowlist-কে network check দিয়ে শক্তিশালী করে। এগুলো সাহায্য করে, এবং সুনির্দিষ্টভাবে বোঝা মূল্যবান।

Reverse DNS verification

কিছু crawler operator একটি verification process ডকুমেন্ট করে: request-এর IP address-এর জন্য hostname lookup করুন, দেখুন এটি operator-এর domain-এর অন্তর্ভুক্ত কি না, তারপর সেই hostname lookup করে নিশ্চিত করুন এটি একই IP-তে ফিরে resolve হয়। যখন এই round trip সফল হয়, তখন আপনার কাছে বাস্তব evidence থাকে যে requestটি operator-এর infrastructure থেকে এসেছে।

সীমাবদ্ধতাগুলো ব্যবহারিক। এটি শুধু সেই operator-এর জন্য কাজ করে যারা এটি ডকুমেন্ট ও support করে। এটি DNS lookup যোগ করে যা আপনাকে cache করতে হয়। এবং এটি network সম্পর্কে বলে, সেই network-এ কোন product বা agent requestটি করেছে সে সম্পর্কে নয়।

প্রকাশিত IP range

অন্যান্য operator প্রকাশ করে কোন IP range তাদের automated client ব্যবহার করে। request-কে সেই range-এর সঙ্গে match করা দ্রুত এবং reverse DNS-এর মতো evidence দেয়। publication-এর জন্য একটি standard format নিয়ে IETF-এ চলমান আলোচনা আছে, কিন্তু November 2026 পর্যন্ত কোনো চূড়ান্ত standard স্থির হয়নি, এবং coverage নির্ভর করে প্রতিটি operator প্রকাশ করার সিদ্ধান্ত নেয় কি না তার ওপর।

IP evidence আরও দুর্বল হয়ে যায় যখন বেশি agent shared cloud infrastructure-এ, proxy-এর আড়ালে, বা ব্যবহারকারীর নিজের device থেকে চলে। একটি cloud address অনেক unrelated client host করতে পারে, এবং একজন মানুষের browser থেকে কাজ করা agent সেই মানুষের network-এর মতোই দেখায়।

network check মোটামুটি কী যোগ করে

Reverse DNS এবং IP list কিছু declaration-কে well-known operator-এর একটি subset-এর জন্য আরও শক্তিশালী কিছুতে রূপান্তর করে। এগুলো agent এবং tool-এর দীর্ঘ tail-কে কভার করে না, এবং AI-এর সঙ্গে কাজ করা মানুষের জন্য একেবারেই সাহায্য করে না। এগুলো আংশিক ব্যবস্থা: ব্যবহার করার মতো, কিন্তু একা যথেষ্ট নয়।

Signature বনাম declaration

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

IETF Web Bot Auth working group automated client কীভাবে এই signature ব্যবহার করে এবং কীভাবে তাদের key প্রকাশ করে তা standardize করছে। product team-এর জন্য Web Bot Auth নিয়ে আমাদের explainer বর্তমান 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 কখনো দাবি আর check-কে গুলিয়ে না ফেলে। পূর্ণ সংজ্ঞার জন্য evidence basis entry দেখুন।

একটি limit verified evidence-এর ক্ষেত্রেও প্রযোজ্য। একটি valid signature প্রমাণ করে কোন key request sign করেছে। এটি প্রমাণ করে না যে agent যা করতে চাইছে তা করার অনুমতি তার আছে। এটি একটি agent authorization প্রশ্ন, এবং এটি আপনার application-এই থাকে।

অনুমান না করে Unknown handling

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

Proof of Actor Unknown-কে একটি first-class result হিসেবে দেখে। Evidence যখন নির্ভরযোগ্য determination support করে না, তখন এটি অনুমান না করে সেটাই বলে। তারপর আপনার policy প্রতিটি route-এ Unknown-এর মান কী হবে তা নির্ধারণ করে:

Public documentation বা marketing page-এ, allow করুন।
Search বা listing endpoint-এ, আপনার স্বাভাবিক rate limit সহ allow করুন।
Account পরিবর্তনে, আপনার বিদ্যমান check বজায় রাখুন।
উচ্চ-প্রভাবের action-এ, এটিকে review-এ পাঠান বা আরও শক্তিশালী signal চাইুন।

Unknown traffic handling guide এবং unknown classification entry patternগুলো দেখায়। সময়ের সঙ্গে আপনার Unknown rate tracking করাও বলে traffic-এর কতটা এখনো দুর্বল evidence-এর ওপর নির্ভর করছে।

AI-assisted মানুষ সম্পর্কে কী?

একটি user agent allowlist এমন একজন মানুষের কথা বলে না যিনি একটি সাধারণ browser-এর মধ্যে AI assistant ব্যবহার করেন। তাদের User-Agent একটি স্বাভাবিক browser string। তবু অনেক product এমন interaction চিনতে চায়, উদাহরণস্বরূপ AI-drafted submission label করতে বা AI-assisted user onboarding-এ কীভাবে এগোয় তা বুঝতে।

Proof of Actor এই interaction-গুলোকে Human + AI হিসেবে রিপোর্ট করে, যখন assistance-টি একটি supported integration-এর মাধ্যমে declared বা observed হয়। এটি শুধু লেখার style দেখে অনুমান করে না। AI-assisted interaction-এ আরও পড়ুন।

allowlist থেকে evidence-based policy-তে যাওয়া

প্রথম দিনেই আপনাকে allowlist সরাতে হবে না। একটি নিরাপদ পথ এমন দেখায়:

Observation mode-এ install করুন। Proof of Actor কিছুই বদলায় না। আপনার allowlist কাজ করতে থাকে।
Compare করুন। প্রতিটি route-এর জন্য দেখুন কোন allowlisted request verified evidence বহন করছে, কোনটি শুধু declaration বহন করছে, এবং কোনটি Unknown হয়ে যাচ্ছে।
Policy preview করুন। এমন একটি policy draft করুন যা verified agent, declared agent এবং Unknown-কে ভিন্নভাবে treats করে, এবং real traffic-এ তার প্রভাব preview করুন।
Route অনুযায়ী enforce করুন। এমন route দিয়ে শুরু করুন যেখানে spoof করা নাম সবচেয়ে বেশি গুরুত্বপূর্ণ।
Allowlist-কে hint হিসেবেই রাখুন। নামগুলো routing এবং analytics-এর জন্য এখনও দরকারি থাকে, এখন তাদের basis দৃশ্যমান।

Actor-aware policy safely rollout guide প্রতিটি ধাপ কভার করে, এবং verified automated requests ব্যাখ্যা করে signed client কীভাবে fit করে।

কখন allowlist যথেষ্ট

কম ঝুঁকির routing-এর জন্য, যেমন public content-এ পরিচিত crawler-কে হালকা page serve করা, user agent allowlist প্রায়ই ঠিক থাকে। spoof করা নামের খরচ কম।

যখন সিদ্ধান্তের ফল আছে, যেমন challenge এড়িয়ে যাওয়া, richer data প্রকাশ করা, বা write অনুমতি দেওয়া, তখন এমন evidence চাই যা আপনি check করতে পারেন। এটাই Proof of Actor-এর স্থান, আপনার ইতিমধ্যে চালানো network check এবং edge control-এর সঙ্গে কাজ করে।

শুরু করুন

Proof of Actor private beta-তে আছে। নির্বাচিত founding developer team-রা agreed usage limit-এর মধ্যে up to 12 months free access পেতে পারে, automatic billing ছাড়া। early access-এর জন্য apply করুন এবং আমাদের জানান আজ আপনি কোন 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: evidence কতটা শক্তিশালী: verified, declared, inferred বা unknown।
evidence: result-এর পেছনের signals, যাতে আপনার team কারণটি দেখতে পারে।

observation mode-এ শুরু করুন: results আপনার logs-এর পাশে record করুন এবং আপনি কোনো policy বেছে না নেওয়া পর্যন্ত কিছুই পরিবর্তন করবেন না। Node.js integration guide পড়ুন

প্রায়শই জিজ্ঞাসিত প্রশ্ন

একটি user agent allowlist কি অকেজো?

না। এটি ভালোভাবে আচরণ করা client-এর কাছ থেকে একটি দরকারি declaration এবং পরিচিত crawler route করার একটি সস্তা উপায়। সমস্যা হলো এটিকে proof হিসেবে ধরা। যে কোনো client যে কোনো User-Agent string পাঠাতে পারে, তাই allowlist একা কখনোই sensitive action খুলে দেওয়া উচিত নয়।

Reverse DNS verification কি User-Agent spoofing ঠিক করে?

যেসব operator এটি ডকুমেন্ট করে, তাদের ক্ষেত্রে এটি সাহায্য করে। একটি 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 দিয়ে result-এ অবদান রাখে, কখনোই verified basis হিসেবে নয়। একটি verified basis-এর জন্য এমন evidence দরকার যেমন প্রকাশিত key-এর বিরুদ্ধে checked একটি HTTP Message Signature।

একটি verified signature কী প্রমাণ করে?

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

যে client নিজেকে একটি পরিচিত agent বলে দাবি করে কিন্তু verify করা যায় না, তার কী হয়?

Proof of Actor evidence যা সমর্থন করে সেটাই রিপোর্ট করে, প্রায়ই একটি declared বা inferred result, অথবা Unknown। আপনার policy ওই route-এর জন্য fallback কী হবে তা বেছে নেয়, দাবি করা নামকে বিশ্বাস না করে।

Proof of Actor যোগ করলে কি আমার বর্তমান allowlist behavior বদলে যাবে?

না। এটি observation mode-এ শুরু হয়। কিছু বদলানোর আগে আপনি বাস্তব traffic-এ এর result আপনার allowlist সিদ্ধান্তের সঙ্গে তুলনা করতে পারেন।

কে আপনার app ব্যবহার করছে, তা জানুন।

Founding developer-এর একটি ছোট group-এর জন্য private beta।

প্রাথমিক access পান মূল্য দেখুন

আগে কথা বলতে চান? Founders-এর সঙ্গে কথা বলুন