তুলনা

Proof of Actor বনাম bot management: ভিন্ন প্ৰশ্ন, এটা stack

Bot management এ আপোনাৰ infrastructure-টো abusive automation-ৰ পৰা ৰক্ষা কৰে। Proof of Actor এ আপোনাৰ application-ক সেই actor context দিয়ে, যাৰ সহায়ত ই মানুহ, AI-assisted user আৰু agent-ৰ বাবে ভিন্নভাবে সেৱা দিব পাৰে। ইয়াত দুয়োটাই কেনেকৈ তুলনা হয় আৰু কেনেকৈ একেলগে খাপ খায় সেয়া দেখুওৱা হৈছে।

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

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

Web-ৰ ইতিহাসৰ বেছিভাগ সময়জুৰি, automated traffic-ৰ security stack-ত এটা কাম আছিল: চিনাক্ত হওক আৰু থামাওক। Bot management সেই কামটোৰ ওপৰতে গঢ় লৈ উঠিছে। ই আপোনাৰ infrastructure-ৰ edge-ত থাকে, request score কৰে, আৰু abusive যেন দেখা সেইবোৰ block বা challenge কৰে। ই এই কামটো ভালকৈ কৰে, আৰু আপুনি ইয়াক ৰাখিব লাগে।

AI agent-এ application-ৰ প্ৰয়োজনীয়তাই সলনি কৰিলে। এতিয়া automated request-ৰ এটা বঢ়ি অহা অংশ বাস্তৱ customer-ৰ হৈ কাম কৰা agent-ৰ পৰা আহে: এটা assistant plan তুলনা কৰিছে, এটা agent support ticket দাখিল কৰিছে, এজন client এ আপোনাৰ MCP server-লৈ কল কৰি এটা কাম শেষ কৰিছে। একে সময়তে, বহু মানুহে AI assistant কাষত লৈ আপোনাৰ product ব্যৱহাৰ কৰে। এইবোৰ attack নহয়। এইবোৰ user, আৰু block page-ৰ সলনি সঠিক experience পোৱাৰ অধিকাৰী।

সেই gapটো Proof of Actor পূৰণ কৰে। এই page-এ দুয়োটা category স্পষ্টকৈ তুলনা কৰিছে যাতে প্ৰতিটিৰ ঠাই ক'ত সেয়া আপুনি দেখা পায়।

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

	Bot management	Proof of Actor
মূল প্ৰশ্ন	এই request থামাব লাগেনে?	কোনে বা কি কাৰ্য কৰিছে, আৰু evidence কি?
ক'ত চলে	Edge-ত, আপোনাৰ application-ৰ আগতে	আপোনাৰ application-ৰ ভিতৰত, API বা MCP server-ত
সাধাৰণ output	Allow, block বা challenge; প্ৰায়ে এটা score	Human, Human + AI, Agent বা Unknown, লগতে এটা basis
AI-assisted মানুহক কিদৰে দেখে	সাধাৰণতে অন্য মানুহৰ পৰা পৃথক নোহোৱা	এটা পৃথক class, Human + AI
অস্পষ্ট traffic-ৰ সৈতে কিদৰে ব্যৱহাৰ কৰে	প্ৰায়ে challenge বা block কৰে	Unknown, route অনুসৰি আপুনি বাছি লোৱা fallback-সহ
response কোনে নিৰ্ধাৰণ কৰে	Edge rule set	আপোনাৰ application code
install কৰাৰ পাছৰ default আচৰণ	Enforcement	Observation; আপুনি policy যোগ নকৰা পৰ্যন্ত একো সলনি নহয়
কোন ক্ষেত্ৰত সৰ্বোত্তম	Credential stuffing, scraping abuse আৰু volumetric attacks থামোৱাত	প্ৰতিটো actor-ৰ বাবে product, analytics আৰু policy সিদ্ধান্তত

এই page-ৰ বাকী অংশে প্ৰতিটো row ব্যাখ্যা কৰিছে।

দুটা ভিন্ন প্ৰশ্ন

Bot management এ এটা protection প্ৰশ্নৰ উত্তৰ দিয়ে। ইয়াৰ লক্ষ্য হৈছে abusive automation-ক আপোনাৰ infrastructure, আপোনাৰ account আৰু আপোনাৰ inventory-ৰ পৰা দূৰত ৰখা। ই সংগ্ৰহ কৰা প্ৰতিটো signal সেই লক্ষ্যৰ বাবে কাম কৰে, আৰু ইয়াৰ output এটা সিদ্ধান্ত: request-টো পাৰ হ'ব, block হ'ব, বা ইয়াৰ আগত এটা challenge থিয় কৰোৱা হ'ব।

Proof of Actor এ এটা understanding প্ৰশ্নৰ উত্তৰ দিয়ে। ইয়াৰ লক্ষ্য হৈছে আপোনাৰ application-ক কোৱা যে প্ৰতিটো interaction কোনে বা কি চলাই আছে, যাতে আপুনি ইয়াক কেনেকৈ serve কৰিব সেইটো সিদ্ধান্ত ল'ব পাৰে। ইয়াৰ output request-ৰ ওপৰত verdict নহয়। ই evidence-সহ এটা classification:

Human: observable signal-এ human-directed interaction সূচায়।
Human + AI: এজন ব্যক্তিয়ে declared বা observed AI assistance-সহ interaction চলাইছে।
Agent: automated বা agent-origin interaction, verifiable identity বা qualified inference-এ সমৰ্থিত।
Unknown: evidence-এ reliable determination সমৰ্থন নকৰে।

প্ৰতিটো result-এ নিজৰ evidence basisও কয়: verified, declared, inferred বা unknown। এইটোৱেই product সিদ্ধান্তৰ বাবে প্ৰয়োজনীয় তথ্য, আৰু protection score সেই তথ্য বহন কৰিবলৈ ডিজাইন কৰা হোৱা নাই।

প্ৰতিটো ক'ত চলে

Bot management সাধাৰণতে network edge বা reverse proxy-ত, বাকী সকলো বস্তুৰ আগত চলে। protection-ৰ বাবে সেই স্থান একেবাৰে উপযুক্ত। ই traffic আগতেই দেখে, attack-সমূহে আপোনাৰ কিবা খৰচ কৰাৰ আগতে সিহঁত শোষণ কৰে, আৰু আপোনাৰ origin server-সমূহক পৰিষ্কাৰ ৰাখে।

Proof of Actor চলে য'ত আপোনাৰ application logic থাকে: server middleware, Next.js, আপুনি নিয়ন্ত্ৰণ কৰা edge layer, এটা approved browser integration, এটা generic HTTP API, বা আপোনাৰ MCP server। সেই স্থানটোৱে ইয়াক আপোনাৰ application-এ যি জানে তাৰ প্ৰৱেশ দিয়ে: কোন route কল হৈছে, ই কোন workflow-ৰ অংশ, আপোনাৰ নিজৰ assistant-এ কোনো action কৰিছে নে নাই, আৰু কোনো client-এ নিজকে declared কৰিছে নে নাই। সম্পূৰ্ণ তালিকাৰ বাবে integration paths চাওক।

দুয়োটাই ভিন্ন ঠাইত চলে বাবে, সিহঁতে একেটা কামৰ বাবে প্ৰতিযোগিতা নকৰে। এটা request আপোনাৰ bot management পাৰ হৈ, আপোনাৰ application-লৈ আহি, তাৰ পাছত response গঢ়ি তোলা actor context পাব পাৰে।

Score বনাম evidence

বহু protection product-এ নিজৰ judgement এটা score হিচাপে প্ৰকাশ কৰে। Block সিদ্ধান্তৰ বাবে score কাৰ্যকৰী: এটা threshold বাছক, তাৰ ওপৰত action লওক। কিন্তু প্ৰশ্নটো যদি হয় "এই actor-এ কেনে experience পাব?" তেন্তে ই বহুত কম উপযোগী।

এটা score-এ আপোনাক কোৱা নাযায় যে low-risk request এটা মানুহৰ পৰা আহিছে নে, assistant-সহ কাম কৰা মানুহৰ পৰা নে, বা ভাল আচৰণ কৰা agent-ৰ পৰা। ই কোৱা নাযায় যে conclusion-ৰ কোন অংশ verified আছিল আৰু কোন অংশ inferred। আৰু ই "আমাক নাজানে" সংখ্যাৰ ভিতৰত ঢুকুৱাই নোতোলা পৰ্যন্ত প্ৰকাশ কৰিব নোৱাৰে।

Proof of Actor সেই ভেদবোৰ সংৰক্ষণ কৰে। এটা verified agent result মানে এটা request signature প্রকাশিত key-ৰ সৈতে পৰীক্ষা কৰা হৈছিল, উদাহৰণস্বৰূপে HTTP Message Signatures-ৰ জৰিয়তে। এটা declared result মানে client বা আপোনাৰ নিজৰ application-এ সেইটো ঘোষণা কৰিছিল। এটা inferred result inference হিচাপে label কৰা হয়। আৰু Unknown এটা first-class উত্তৰ, লুকাই থকা default নহয়। আপোনাৰ দলে প্ৰতিটো result পঢ়ি ইয়াৰ ভিত্তি একেবাৰে স্পষ্টকৈ দেখিব পাৰে।

AI-assisted মানুহ bot নহয়

অধিকাংশ application-ত সৰ্বাধিক বাঢ়ি অহা group হৈছে AI-ৰ সৈতে কাম কৰা মানুহ। তেওঁলোকে assistant-ৰে message draft কৰে, সহায়ত form পূৰণ কৰে, আৰু নিজৰ কাষত AI tool লৈ আপোনাৰ product-ৰ মাজেৰে আগবাঢ়ে। Protection tooling তেওঁলোকক অন্য মানুহৰ পৰা পৃথক কৰিবলৈ নিৰ্মিত হোৱা নাছিল, আৰু তাৰ প্ৰয়োজনো নাই।

কিন্তু আপোনাৰ product-এ প্ৰায়ে কৰে। আপুনি হয়তো AI-drafted support ticket label কৰিব বিচাৰে যাতে সঠিক দলটোৱে সিহঁত handle কৰে, AI-assisted user-এ onboarding-ত কেনেকৈ আগবাঢ়ে measure কৰিব বিচাৰে, বা সিহঁতৰ বাবে এটা smoother path দিব বিচাৰে। Proof of Actor-এ সেই group-টোক নিজৰ class, Human + AI, দিয়ে, আৰু কেৱল তেতিয়াই report কৰে যেতিয়া assistance declared হয় বা supported integration-এৰে observable হয়। অধিক জানিবলৈ AI-assisted interaction glossary entry চাওক।

Unknown এটা উত্তৰ, threat নহয়

প্ৰতিটো classifier-এ এনে traffic পায় যাক ই ব্যাখ্যা কৰিব নোৱাৰে। Protection system-সমূহ cautious হ'বলৈ ডিজাইন কৰা, সেয়েহে অস্পষ্ট traffic-এ প্ৰায়ে challenge পায়। Edge-ত এইটো এটা যুক্তিসংগত বাছনি।

আপোনাৰ application-ৰ ভিতৰত, এটা একক cautious default প্ৰায়ে ভুল বাছনি হয়। এটা public documentation page-লৈ unknown request আৰু account password সলনি কৰাৰ unknown request-এ একেবাৰে ভিন্ন handling যোগ্য। Proof of Actor-এ Unknown-ক নিজৰ result হিচাপে দিছে আৰু আপোনাক route অনুসৰি fallback সেট কৰিবলৈ দিয়ে: public page-ত allow কৰক, account change-ত আপোনাৰ বিদ্যমান check ৰাখক, high-impact action-ত review-লৈ route কৰক। Unknown traffic handling-ৰ guide-এ pattern-সমূহৰ মাজেৰে লৈ যায়।

response কোনে নিৰ্ধাৰণ কৰে

Bot management-ৰ সৈতে, edge-ৰ rule set-এ সিদ্ধান্ত লয়। ই কাৰ্যকৰী আৰু আপোনাৰ property-সমূহৰ মাজত সিদ্ধান্ত একে ধৰণৰ ৰাখে।

Proof of Actor-ৰ সৈতে, আপোনাৰ application-এ সিদ্ধান্ত লয়। Product-এ actor context যোগান ধৰে; আপোনাৰ code-এ policy প্ৰয়োগ কৰে। আপুনি verified agent-লৈ people-ৰ বাবে নিৰ্মিত page-ৰ সলনি এটা structured API দি পারে, human session-ৰ বাবে standard experience ৰাখে, AI-assisted submission label কৰে, আৰু আপোনাৰ নিজৰ condition-এ দাবী কৰিলে sensitive action-ত অধিক শক্তিশালী credential বিচাৰে। Policy-সমূহ route, actor class আৰু basis-অনুসাৰে লিখা হয়, আৰু সিহঁত আপোনাৰ বাকি business logic-ৰ কাষতে থাকে।

প্ৰথমে observation

Bot management সাধাৰণতে enforce কৰিবলৈ install কৰা হয়, কাৰণ ইয়াৰ সমগ্ৰ মূল্য abuse থামোৱাত।

Proof of Actor observation mode-ত আৰম্ভ হয়। ইয়াক install কৰিলে আপোনাৰ application কেনেকৈ আচৰণ কৰে তাত একো সলনি নহয়। আপুনি route অনুসৰি আপোনাৰ বাস্তৱ actor mix দেখে, evidence review কৰে, real traffic-ৰ বিপৰীতে policy-ৰ প্ৰভাৱ preview কৰে, আৰু সাজু হ'লে, একো route এটা সময়ত enforce কৰে। Actor-aware policy safely rollout-ৰ guide-এ এই প্ৰক্ৰিয়া সামৰি লৈছে।

দুয়োটাই কেনেকৈ একেলগে কাম কৰে

সবাতোকৈ শক্তিশালী setup-এ দুয়োটাই ব্যৱহাৰ কৰে, প্ৰত্যেকেই নিজৰ layer-ত:

Edge-ত, bot management এ credential stuffing, scraping abuse আৰু volumetric attacks থামায়।
আপোনাৰ application-ত, Proof of Actor-এ পাৰ হৈ অহা traffic Human, Human + AI, Agent বা Unknown হিচাপে basis-সহ classify কৰে।
আপোনাৰ code-ত, policy-সমূহে সেই context ব্যৱহাৰ কৰি experience বাছি লয়: verified agent-ৰ বাবে structured API, এজন মানুহৰ বাবে normal flow, AI-assisted submission-ৰ বাবে এটা label, Unknown-ৰ বাবে এটা explicit fallback।
আপোনাৰ analytics-ত, আপোনাৰ দলে দেখে কোন route আৰু workflow-টো প্ৰতিটো actor class-এ ব্যৱহাৰ কৰিছে, যাতে product আৰু security একে ছবিৰ ওপৰত কাম কৰে।

Edge decision-টো actor result-ৰ কাষত record কৰিলে ছবিখন সম্পূৰ্ণ হয়: protection-এ কি কৰিলে, আৰু বাস্তৱতে কোনে কাৰ্য কৰিছিল।

কেতিয়া কোনটো বাছিব

আপোনাৰ মূল সমস্যা যদি abuse হয়, তেন্তে bot management বাছক: account takeover attempt, inventory hoarding, aggressive scraping বা traffic flood।

আপোনাৰ মূল প্ৰশ্ন যদি আপোনাৰ user-সকলৰ বিষয়ে হয়, তেন্তে Proof of Actor বাছক: আপোনাৰ product-ৰ কিমান অংশ agent ইতিমধ্যে ব্যৱহাৰ কৰে, কোন agent-এ আপোনাৰ API বা MCP server কল কৰে, AI-assisted মানুহে ক'ত অসুবিধা পায়, আৰু কোন route-ত actor-aware policy লাগে।

উৎপাদন-চালিত application, API বা MCP server চলোৱা অধিকাংশ দলক দুয়োটা প্ৰশ্নৰ উত্তৰ লাগে, সেইকাৰণে দুয়োটাই একেটা stack-ত থাকে।

আৰম্ভ কৰক

Proof of Actor private beta-ত আছে। বাছনি কৰা founding developer দলসমূহে সন্মত usage limit-ৰ ভিতৰত 12 months-লৈকে free access পাব পাৰে, যিটো system নিৰ্মাণ কৰা দলে সরাসরি support কৰে। early access-ৰ বাবে আবেদন কৰক আৰু আপোনাৰ application আৰু আপুনি বুজিব বিচৰা interaction-ৰ বিষয়ে আমাক কওক।

ডেভেলপারসকলৰ বাবে

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 পঢ়ক

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

Proof of Actor-এ bot management-ৰ ঠাই লয় নে?

নহয়। Bot management এ credential stuffing, scraping abuse আৰু volumetric attacks-ৰ দৰে abusive automation-ক আপোনাৰ application-লৈ পোৱাৰ আগতেই থামায়। Proof of Actor আপোনাৰ application-ৰ ভিতৰত কাম কৰে আৰু product আৰু policy সিদ্ধান্তৰ বাবে actor context দিয়ে। দুয়োটাই ৰাখক।

Product সিদ্ধান্ত ল'বলৈ bot score ব্যৱহাৰ নকৰা কিয়?

Bot score ৰ উদ্দেশ্য হৈছে কোনো request থামাব লাগে নে নাই সেইটো নিৰ্ণয় কৰা। সাধাৰণতে ই কোৱা নাযায় যে এজন ব্যক্তি AI-ৰ সৈতে কাম কৰিছিল নে নাই, কোন agent কল কৰিছে, বা score-টো কোন evidence-ৰ ওপৰত ভিত্তি কৰি আছে। Proof of Actor এ এটা class আৰু এটা explicit basis দিয়ে, যিটো product সিদ্ধান্তৰ বাবে লাগে।

দুয়োটাই signal ভাগ-বাটোৱাৰা কৰিব পাৰেনে?

হয়। আপোনাৰ application-এ edge controls-ৰ outcome আৰু Proof of Actor result একেলগে record কৰিব পাৰে, যাতে আপোনাৰ দলে একেটা request-ৰ বাবে protection decision আৰু actor context দুয়োটাই দেখে।

Proof of Actor traffic block কৰে নে?

নহয়। ই observation mode-ত আৰম্ভ হয় আৰু আপুনি policy লিখা পৰ্যন্ত একো সলনি নকৰে। Enforcement সদায় আপোনাৰ নিজৰ application code-তেই থাকে।

মই প্ৰথমে কোনটো যোগ কৰা উচিত?

যদি active abuse-ৰ সন্মুখীন হৈ আছেনে, bot management-ৰ পৰা আৰম্ভ কৰক। যদি আপুনি ইতিমধ্যে আপোনাৰ product ব্যৱহাৰ কৰি থকা মানুহ, AI-assisted user আৰু agent-বোৰক বুজিব আৰু সেৱা দিব বিচাৰে, তেন্তে Proof of Actor যোগ কৰক। অধিকাংশ production দলে শেষত দুয়োটাই থাকে।

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

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

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

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