AI এজেণ্ট চিনাক্তকৰণ

ৱেবছাইটৰ বাবে AI এজেণ্ট চিনাক্তকৰণ, প্ৰতিটো ফলাফলৰ আঁৰত প্ৰমাণসহ

আপোনাৰ ৱেবছাইটৰ কোন কোন interaction মানুহৰ পৰা, AI-ৰ সৈতে কাম কৰা মানুহৰ পৰা, স্বয়ংচালিত agent-ৰ পৰা, বা এনে উৎসৰ পৰা আহে যাৰ evidence এতিয়াও চিনাক্ত কৰিব পৰা হোৱা নাই, সেয়া দেখক। প্ৰতিটো ফলাফলত ইয়াৰ ভিত্তি দেখুৱা হয়।

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

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

এতিয়া আপোনাৰ ৱেবছাইটত visitor-ৰ একাধিক ধৰণ আছে

Web-ৰ বেছি সময়ৰ ইতিহাসত, এটা ৱেবছাইটে এটা সহজ model ধাৰণা কৰিব পাৰিছিল: এজন ব্যক্তি browser খোলে, ইফালে সিফালে click কৰে, আৰু হয়তো sign in কৰে। Analytics, rate limits, onboarding flows আৰু security checks এই ব্যক্তিজনৰ ওপৰতে ভিত্তি কৰি তৈয়াৰ হৈছিল।

এই model-এ এতিয়া বাস্তৱ traffic বৰ্ণনা নকৰে। আজি এটা একেটা ৱেবছাইটে নিজৰ মতে browsing কৰা মানুহ, কোনো AI assistant-ৰ পৰা নিজৰ হৈ summary বনাবলৈ বা কিবা ভৰাই দিবলৈ কোৱা মানুহ, আন কাৰোবাৰ হৈ pages পঢ়ি endpoint call কৰা autonomous agent, আৰু বহু ধৰণৰ crawler আৰু script-লৈ service দিয়ে। AI provider-সকলে এই visitor-সমূহৰ কেইটামান নিজেই document কৰিছে: OpenAI-এ, উদাহৰণস্বৰূপে, তাৰ search crawler, training crawler আৰু ChatGPT user এ এটা প্ৰশ্ন কৰোঁতে pages visit কৰা fetcher-ৰ বাবে পৃথক user agents প্ৰকাশ কৰে (OpenAI crawler documentation), আৰু Anthropic-এ ClaudeBot, Claude-User আৰু Claude-SearchBot-ৰ বাবেও সেই একে কৰে (Anthropic crawler documentation). এই visitor-সমূহৰ কিছুমান welcome। কিছুমানৰ বাবে বেলেগ experience লাগে। কিছুমান sensitive কিবা কৰিব পাৰোঁ বুলি ধৰাৰ আগতে অধিক কাষৰ পৰা চাব লাগে।

সমস্যাটো হৈছে, এই interaction-সমূহৰ বেছিভাগেই প্ৰথম চালে একে ধৰণৰ লাগে। এটা login-এ কোন account ব্যৱহৃত হৈছে সেয়া ক'ব পাৰে। কিন্তু তাৰ পৰা এইটো নাজানিব যে এজন ব্যক্তি click কৰি আছে নে এটা assistant সেই session-ৰ জৰিয়তে কাম কৰি আছে, নে কোনো automated client-এ আপোনাৰ pricing page আন কাৰোবাৰ বাবে পঢ়ি আছে। ৱেবছাইটৰ বাবে AI এজেণ্ট চিনাক্তকৰণ-ৰ উদ্দেশ্য হৈছে evidence-সহ সেই ফাঁকটো পূৰণ কৰা, যাতে আপোনাৰ দলে traffic-ৰ সকলো ধৰণক একে বুলি গণ্য নকৰি প্ৰতিটো actor-ৰ ধৰণৰ অনুযায়ী উপযুক্ত সঁহাৰি দিব পাৰে। involved signals-ৰ এটা ব্যৱহাৰিক walkthrough-ৰ বাবে কেনেকৈ জানিব যে ৱেবছাইট traffic AI agents-ৰ পৰা আহিছে পঢ়ক, আৰু production site-ত এইটো কেনেকৈ দেখা যায় তাৰ বাবে websites use case চাওক।

এটা single bot score কিয় যথেষ্ট নহয়

বহু tools-এ এই প্ৰশ্নৰ উত্তৰ এটা সংখ্যা দি দিয়ে: bot score, risk score, বা এটা percentage যি দাবী কৰে যে visitor কিমান human ধৰণৰ সেয়া বৰ্ণনা কৰে। ইয়াৰ আকর্ষণ স্পষ্ট। এটা সংখ্যা rule-ত বসাবলৈ সহজ।

সমস্যাটো হৈছে, এটা single number-এ reasoning লুকুৱাই ৰাখে। যেতিয়া এটা score-এ কয় যে এটা session সম্ভৱত automated, আপোনাৰ দলৰ বাবে সেই সিদ্ধান্ত verified signature-ৰ ওপৰত ভিক্তি কৰিছে নে, সকলোৰে কপি কৰিব পৰা user-agent string-ৰ ওপৰত, নে দ্রুতগতিত টাইপ কৰা এজন human-ৰ pattern-ৰ ওপৰত সেয়া দেখা কঠিন হয়। যেতিয়া সেই score-এ block বা challenge drive কৰে, আপুনি ইয়াৰ প্ৰতিটো ভুলকে গ্ৰাহক, সহকৰ্মী বা auditor-ৰ আগত ব্যাখ্যা কৰিব পৰা কোনো উপায় নোহোৱাকৈ গ্ৰহণ কৰে।

Proof of Actor-এ এটা বেলেগ approach লয়। প্ৰতিটো ফলাফল চাৰিটা স্পষ্ট class-ৰ এটা, যি Human, AI-assisted বা agent: app traffic-ৰ বাবে এটা taxonomy-ত ব্যাখ্যা কৰা হৈছে, আৰু প্ৰতিটো ফলাফলে ইয়াৰ ভিত্তি কি সেয়াও ক'ব। আপুনি conclusion আৰু evidence একেলগে দেখে, যাৰ ফলত আপুনি শক্তিশালী ফলাফলক বিশ্বাস কৰিব পাৰে, দুর্বল ফলাফলক প্ৰশ্ন কৰিব পাৰে, আৰু evidence-ৰ গুণাগুণৰ সৈতে মিল থকা policy তৈয়াৰ কৰিব পাৰে।

আপোনাৰ ৱেবছাইটত AI agents চিনাক্ত কৰাৰ চাৰিটা ধাপ

আপোনাৰ হাতত থকা tools-ৰ সহায়তেও আপুনি আপোনাৰ ৱেবছাইটত AI agents চিনাক্তকৰণ আৰম্ভ কৰিব পাৰে। এই চাৰিটা ধাপ vendor-neutral আৰু আপুনি Proof of Actor ব্যৱহাৰ কৰক বা নকৰক, দুয়ো ক্ষেত্ৰতে কাম কৰে; কেনেকৈ জানিব যে ৱেবছাইট traffic AI agents-ৰ পৰা আহিছে শীৰ্ষক blog post-এ এইবোৰ প্ৰতিটোৰ বিষয়ে অধিক গভীৰভাৱে ব্যাখ্যা কৰিছে।

নিজকে ঘোষণা কৰা agents-সমূহ তালিকাভুক্ত কৰক। আপোনাৰ server বা CDN logs-ত AI provider-এ প্ৰকাশ কৰা user agents বিচাৰক। OpenAI-এ OAI-SearchBot, GPTBot আৰু ChatGPT-User document কৰে, আৰু কয় যে ChatGPT-User-এ pages তেতিয়াহে visit কৰে যেতিয়া user-এ ChatGPT-ত এটা প্ৰশ্ন কৰে, স্বয়ংক্ৰিয়ভাৱে crawl কৰা নহয়। Anthropic-এ ClaudeBot, Claude-User আৰু Claude-SearchBot document কৰে। ইয়াৰ ফলত route-অনুসাৰে agent traffic-ৰ প্ৰথম, declared ছবি পোৱা যায়।
String-ৰ ওপৰত বিশ্বাস নকৰি দাবীসমূহ verify কৰক। এটা user agent self-reported আৰু সহজে copy কৰিব পৰা। ইয়াক operator-ৰ নিজস্ব verification method-ৰ সৈতে মিলাওক: Google-এ Googlebot-ৰ বাবে reverse DNS lookup-ৰ পিছত forward DNS lookup, লগতে প্ৰকাশিত IP range files বৰ্ণনা কৰিছে (Google: verifying Googlebot); Bing-এ Bingbot-ৰ বাবে একে reverse আৰু forward DNS check বৰ্ণনা কৰিছে (Bing: verifying Bingbot); OpenAI-এ তাৰ প্ৰতিটো user agent-ৰ বাবে IP range files প্ৰকাশ কৰে। য'ত এটা client-এ HTTP Message Signatures, যি RFC 9421-ত সংজ্ঞায়িত, ব্যৱহাৰ কৰি requests sign কৰে, তাত operator-এ প্ৰকাশ কৰা key-ৰ সৈতে signature মিলাওক।
প্ৰতিটো ফলাফলৰ সৈতে ইয়াৰ evidence label কৰক, আৰু Unknown ৰাখক। প্ৰতিটো conclusion verified, declared বা inferred নে সেয়া নথিভুক্ত কৰক। কোনো verified বা declared agent-ৰ সৈতে মিলা নথকা আৰু স্পষ্ট human pattern নেদেখুৱা traffic-ক Unknown হিচাপে label কৰিব লাগে, human বা bot-লৈ বলপূৰ্বক ঠেলি নিদিয়াকৈ। এইটোৱেই এটা উপযোগী report আৰু এটা অনুমানৰ মাজৰ পাৰ্থক্য সৃষ্টি কৰে।
কাৰ্য্য কৰাৰ আগতে route-অনুসাৰে observe কৰক। কেইসপ্তাহমানৰ বাবে ফলাফলসমূহ route আৰু workflow অনুসৰি ভাগ কৰক: public content, signup, account settings, APIs। তাৰ পাছতহে যি route-ত actor context সৰ্বাধিক গুৰুত্বপূৰ্ণ, তাৰ বাবে এটা সংকীর্ণ policy লিখক, Unknown-ৰ বাবে স্পষ্ট fallback-সহ।

Proof of Actor-এ আপোনাৰ application-ৰ ভিতৰত এই ধাপসমূহ স্বয়ংক্ৰিয় কৰে: ই আপোনাৰ integration-এ দেখা কৰিব পৰা signals সংগ্ৰহ কৰে, basis-সহ এটা class দিয়ে, route-অনুসাৰে Unknown track কৰে, আৰু policy আপোনাৰ code-ৰ ওপৰত এৰি দিয়ে।

Proof of Actor-এ ৱেবছাইটত AI agents কেনেকৈ চিনাক্ত কৰে

Proof of Actor এটা সহজ path-ৰ ওপৰত নিৰ্মিত: আপোনাৰ integration-এ observe কৰিব পৰা signals, এটা explicit basis-সহ classification, আৰু আপোনাৰ হাততেই থকা সিদ্ধান্ত। সম্পূৰ্ণ flow আপুনি How It Works page-ত পঢ়িব পাৰে। ইয়াত সংক্ষিপ্ত সংস্কৰণ দিয়া হৈছে।

আপোনাৰ integration-ৰ পৰা signals

প্ৰতিটো integration-এ নিজৰ context যিমানখিনি অনুমতি দিয়ে সিমানখিনি দেখে। এটা server-side integration-এ request context, protocol details আৰু, client-এ সমৰ্থন কৰিলে, এটা request signature দেখে। এটা browser integration-এ ইয়াক চলা pages-ৰ interaction signals দেখে। এটা application-এ নিজৰ declarations-ও record কৰিব পাৰে, যেনে কোনো user-এ content-এ AI assistance-সহ draft কৰা বুলি চিহ্নিত কৰা, বা কোনো agent client-এ নিজকে নামকৰণ কৰা।

Proof of Actor-এ বাস্তৱতে উপস্থিত evidence-ৰ সৈতে কাম কৰে। আপোনাৰ ৱেবছাইটে observe কৰিব নোৱৰা কিবা দেখা পোৱা বুলি ভাণ নকৰে।

বিশেষ অৰ্থ থকা চাৰিটা class

প্ৰতিটো interaction এই চাৰিটা class-ৰ এটাত পৰে:

Human: observable signals-এ human-directed interaction সূচায়।
Human + AI: AI assistance declared হৈছে, বা যি supported integration-এ ইয়াক দেখা পাৰে তাত observable হৈছে।
Agent: স্বয়ংচালিত বা agent-origin interaction, যাৰ বাবে verifiable identity বা সাৱধানভাৱে qualified inference আছে।
Unknown: উপলব্ধ evidence-এ reliable determination সমৰ্থন নকৰে।

প্ৰতিটো class-ৰ এটা স্পষ্ট definition আৰু এটা স্পষ্ট সীমা আছে। Human result এটা verified identity নহয়। Agent result এটা agent authorized বুলি কোৱা কথা নহয়। Unknown result এটা অভিযোগ নহয়। সম্পূৰ্ণ taxonomy আপুনি Detection & Limitations page-ত পঢ়িব পাৰে।

প্ৰতিটো ফলাফলত এটা basis

Class-ৰ সৈতে একেলগে, প্ৰতিটো ফলাফলে ইয়াৰ basis কঢ়িয়ায়: verified, declared, inferred বা unknown। প্ৰকাশিত key-ৰ পৰা valid signature কঢ়িয়াই অনা request সেই check-ৰ বাবে verified হয়। নিজকে agent বুলি কোৱা client-এ সেইটো declared কৰে। automation-ৰ সৈতে মিল থকা আচৰণৰ pattern এটা inference। এই পাৰ্থক্যই আপোনাৰ policy-সমূহ precise হ'বলৈ দিয়ে। read-only route-ত এটা verified signed agent আৰু account settings page-ত এটা self-declared client-ৰ সৈতে একে ধৰণে ব্যৱহাৰ কৰা উচিত নহয়, আৰু Proof of Actor-ৰ সৈতে সেইটো বাধ্যতামূলক নহয়। evidence basis glossary entry-এ প্ৰতিটো বিষয়ে অধিক বিস্তারিত ব্যাখ্যা কৰে।

আপোনাৰ দলৰ বাবে কি পোৱা যায়: Detect, Understand, Route

Proof of Actor এটা product, যাৰ তিনিটা capability একেলগে কাম কৰে।

Detect

আপোনাৰ integration-ৰ বাবে উপলব্ধ actor signals সংগ্ৰহ কৰক আৰু verified assertions-ক behavioral inferences-ৰ পৰা পৃথক কৰক। Unknown traffic এটা guess-ত মিহলি হোৱাৰ পৰিৱৰ্তে নিজৰ পৃথক category হিচাপেই দৃশ্যমান থাকে। কোন interaction-ৰ বিষয়ে confidence-সহ কথা ক'ব পাৰি আৰু কোনবোৰৰ বাবে অধিক evidence লাগিব সেয়া আপুনি সদায় জানে।

Understand

আপোনাৰ AI agent traffic context-সহ দেখক। route আৰু time অনুসৰি interaction types অন্বেষণ কৰক, human, AI-assisted, agent আৰু unknown activity-ত trend অনুসৰণ কৰক, আৰু যিকোনো classification খুলি চাওক যাতে কি জনা আছে, কি জনা নাই, আৰু result-টো কিহৰ ওপৰত ভিক্তি কৰিছে সেয়া দেখা যায়। এইখিনিত product, platform আৰু security দলসমূহে ৱেবছাইটটো কোনে ব্যৱহাৰ কৰিছে তাৰ এটা ভাগ-বতৰা কৰিব পৰা, ব্যাখ্যাযোগ্য ছবি পায়।

Route

বিশেষ interaction-সমূহ allow, adapt, challenge, review বা limit কৰিবলৈ আপোনাৰ নিজৰ policy ব্যৱহাৰ কৰক। আপোনাৰ documentation পঢ়ি থকা verified agent-লৈ এটা structured response দিয়ক। human-directed session-সমূহৰ বাবে standard experience ৰাখক। আপোনাৰ নিজৰ condition-সমূহে দাবী কৰিলে sensitive account change-ত অধিক শক্তিশালী check বিচাৰক। Unknown result আৰু timeout-ৰ বাবে route অনুসৰি এটা স্পষ্ট fallback বাছক। Enforcement সদায় আপোনাৰ application-ত হয়, আপোনাৰ দলেই নিশ্চিত কৰা policy-ৰ অধীনত।

আপোনাৰ ৱেবছাইটৰ সৈতে খাপ খোৱা, তাৰ সলনি নহয়

Proof of Actor আপুনি ইতিমধ্যে চলাই থকা tools-ৰ সৈতে একেলগে থাকে। ই আপোনাৰ authentication, আপোনাৰ authorization model বা আপোনাৰ বিদ্যমান abuse controls সলনি নকৰে। ই সেইবোৰৰ সৈতে actor context যোগ কৰে।

এটা সাধাৰণ website integration সেই route-সমূহৰ পৰা আৰম্ভ হয় য'ত actor context সৰ্বাধিক গুৰুত্বপূৰ্ণ: agents বেছিকৈ পঢ়া public content, signup আৰু onboarding flows, account settings আৰু অন্য sensitive action, আৰু site-টো চালিত কৰা কোনো API। Founding দলসমূহে আমাৰ engineer-সমূহৰ সৈতে কাম কৰি সেই route-সমূহ বাছি লয়, scope-ত থকা signals-ত সন্মতি দিয়ে, আৰু কোনো code ship কৰাৰ আগতে data কেনেকৈ handle কৰা হ'ব সেয়া নিশ্চিত কৰে।

কাৰণ decision layer আপোনাৰ code-ত থাকে, experience-ৰ ওপৰত নিয়ন্ত্ৰণ আপোনাৰ হাততেই থাকে। আপুনি নিয়ম সলনি কৰাৰ আগতে কেইসপ্তাহমান এটা internal dashboard-ত ফলাফল দেখুৱাব পাৰে, তাৰ পাছত এটা route-ৰ বাবে এটা সংকীর্ণ policy চালু কৰিব পাৰে, আৰু ফলাফল আপোনাৰ বিশ্বাস অৰ্জন কৰাৰ পাছত বিস্তাৰ কৰিব পাৰে। unknown traffic handle কৰা guide-এ সেই প্ৰথম নিয়মসমূহ কেনেকৈ ডিজাইন কৰিব সেয়া দেখুৱায়।

Observation mode-ত আৰম্ভ কৰক

AI agent detection-ৰ পৰা value পোৱাৰ সৰ্বাধিক দ্ৰুত উপায় হৈছে block নকৰি observe কৰি আৰম্ভ কৰা। observation mode-ত Proof of Actor-এ ফলাফল record কৰে, আৰু আপোনাৰ ৱেবছাইটে ঠিক আগৰ দৰে সঁহাৰি দিয়ে। তাৰ পাছত আপোনাৰ দল application, known integrations, internal tools, আৰু আপুনি ইতিমধ্যে চিনাক্ত কৰা crawler-সমূহৰ দৰে outcomes-ৰ সৈতে classification তুলনা কৰিব পাৰে।

ই enforcement-ৰ আগতে আপোনাক তিনিটা বস্তু দিয়ে:

এটা baseline. route অনুসৰি আপোনাৰ traffic-ৰ কিমান অংশ human-directed, AI-assisted, agent-driven বা unknown।
evidence-ত confidence. আপোনাৰ ৱেবছাইটত কোন signals শক্তিশালী আৰু ক'ত coverage বৃদ্ধি কৰিব লাগিব।
উত্তম policy. অনুমানৰ সলনি বাস্তৱ pattern-ৰ ওপৰত নিৰ্মিত নিয়ম, য'ত false positives কাৰোবাৰ ওপৰত প্ৰভাৱ পৰাৰ আগতে পৰ্যালোচনা কৰা হয়।

যেতিয়া এটা policy প্ৰস্তুত হয়, আপুনি সেই workflow-ৰ বাবে ইয়াক enable কৰে, আৰু যিকোনো সময়তে adjust কৰাৰ ক্ষমতা ৰাখে।

অস্পষ্ট scores-ৰ তুলনাত evidence-backed detection কিয় জয়ী হয়

ৱেবছাইটসমূহে ইতিমধ্যে agents, assistants আৰু AI-ৰ সৈতে কাম কৰা মানুহক একেলগে serve কৰে। এইটো ভালদৰে handle কৰা দলসমূহ আটাইতকৈ আক্রমণাত্মক filter থকা দল নহ'ব। তেওঁলোক সেইসকল হ'ব যিসকলে নিজৰ সিদ্ধান্ত ব্যাখ্যা কৰিব পাৰে।

Evidence-backed result-এ আপোনাক সেই ব্যাখ্যা দিয়ে। যেতিয়া এটা support agent-এ সোধে যে এজন user-এ কিয় এটা অতিৰিক্ত verification step দেখিলে, আপুনি evidence আৰু প্ৰযোজ্য policy-লৈ আঙুলিয়াব পাৰে। যেতিয়া এজন agent operator-এ সোধে যে তাৰ signed request-সমূহক কিয় structured response দিয়া হৈছিল, আপুনি verified basis দেখুৱাব পাৰে। যেতিয়া evidence পাতল হয়, ফলাফল Unknown কয়, আৰু আপোনাৰ fallback-এ ইয়াক আপুনি সচেতনভাৱে বাছি লোৱা উপায়েৰে handle কৰে।

এই approach-এ web-ৰ সৈতে scale-ও কৰে। অধিক agent operator-এ নিজৰ requests sign কৰাৰ লগে লগে আৰু IETF Web Bot Auth working group-ৰ দৰে standards work-এ, যিয়ে automated client-ৰ বাবে cryptographic authentication standardize কৰিবলৈ charter পায়, HTTP message signatures-ৰ ওপৰত ভিত্তি কৰি গঢ়ি উঠাৰ লগে লগে, আপোনাৰ traffic-ৰ অধিক অংশ inferred বা unknown-ৰ পৰা verified-লৈ যায়, আৰু আপোনাৰ policy-সমূহ পুনৰ লিখিব নপৰাকৈ অধিক precise হৈ পৰে।

Founding developer program-ত যোগদান কৰক

Proof of Actor private beta-ত আছে, application দলৰ এটা সৰু গোটৰ সৈতে। নিৰ্বাচিত founding developer-সকলে agreed usage limits-ৰ ভিতৰত 12 months পৰ্যন্ত free access পাব পাৰে, ব্যৱহাৰিক product feedback-ৰ বিনিময়ত। আপুনি আমাৰ engineer-সমূহৰ পৰা direct integration support, feature উপলব্ধ হ'লে early access, আৰু আমি পৰৱৰ্তী কি গঢ়োঁ তাৰ ওপৰত বাস্তৱ প্ৰভাৱ পাব।

যদি আপোনাৰ ৱেবছাইটে মানুহ, AI-assisted user আৰু agent-সকলক service দিয়ে, আৰু পৰৱৰ্তী কি হ'ব সেয়া সিদ্ধান্ত লোৱাৰ আগতে কোনে ইয়াক ব্যৱহাৰ কৰিছে সেয়া জানিব বিচাৰে, early access-ৰ বাবে আবেদন কৰক। আপোনাৰ ৱেবছাইট আৰু যি interaction-টো আপুনি আটাইতকৈ বেছি বুজিব বিচাৰে তাৰ বিষয়ে আমাক কওক, আৰু current beta-ৰ বাবে ই fit হয় নে নহয় আমি পৰ্যালোচনা কৰিম।

প্ৰথমে details চাব বিচাৰেনে? Proof of Actor অন্বেষণ কৰক, ই কেনেকৈ কাম কৰে পঢ়ক, বা সঠিকভাৱে evidence-এ কি স্থাপন কৰিব পাৰে আৰু কি কৰিব নোৱাৰে সেয়া পৰ্যালোচনা কৰক।

Sources

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.
OpenAI crawlers-ৰ overview, OpenAI.
Anthropic-এ web-ৰ পৰা data crawl কৰে নে, আৰু site owner-সকলে crawler কিদৰে block কৰিব পাৰে?, Anthropic.
Googlebot আৰু অন্য Google crawlers verify কৰাৰ পদ্ধতি, Google Search Central.
Bingbot যে Bingbot হয় সেয়া verify কৰাৰ পদ্ধতি, Bing Webmaster Blog.

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

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-ৰ সৈতে ৱেবছাইটৰ বাবে AI এজেণ্ট চিনাক্তকৰণ কেনেকৈ কাম কৰে?

Proof of Actor-এ আপোনাৰ integration-ৰ জৰিয়তে উপলব্ধ signals সংগ্ৰহ কৰে, যেনে request signatures, client declarations আৰু interaction signals, আৰু তাৰ basis সহ এটা classification দিয়ে: verified, declared, inferred বা unknown।

ই ইনষ্টল কৰিলে কোনো visitor বাধাপ্ৰাপ্ত হ’ব নেকি?

নহয়। Proof of Actor observation mode-ত আৰম্ভ হয়। আপোনাৰ দল ফলাফলসমূহ পৰ্যালোচনা কৰি থাকোঁতে আপোনাৰ ৱেবছাইট ঠিক আগৰ দৰে চলি থাকে, আৰু পাছত কোন policy প্ৰয়োগ হ’ব সেয়া আপুনি সিদ্ধান্ত কৰে।

কোনোবাই আন এটা tab-ত AI ব্যৱহাৰ কৰিলে সেয়া ই ক’ব পাৰিব নেকি?

কোনো ৱেবছাইটে আন এটা tab বা আন এটা device-ত হোৱা activity দেখা নাপায়। Proof of Actor-এ AI assistance তেতিয়াহে report কৰে যেতিয়া সেয়া declared হয় বা supported integration-ৰ জৰিয়তে observable হয়, আৰু বাকী সকলো design অনুসৰি honest হৈ থাকে।

Evidence স্পষ্ট নোহোৱালে কি হয়?

ফলাফল Unknown হয়। Unknown এটা first-class result, default-ত কেতিয়াও human বুলি গণ্য কৰা নহয় আৰু default-ত কেতিয়াও malicious বুলিও গণ্য কৰা নহয়। আপোনাৰ policy-এ ঠিক কৰে প্ৰতিটো route-এ ইয়াক কেনেকৈ handle কৰিব।

Proof of Actor কাক লক্ষ্য কৰি তৈয়াৰ কৰা হৈছে?

সেই দলসমূহৰ বাবে, যিসকলে SaaS applications, websites, APIs আৰু MCP servers চলায় আৰু experience বা access policy বাছনি কৰাৰ আগতে কোন বা কি acting কৰি আছে সেয়া বুজিব বিচাৰে।

মই access কেনেকৈ পাব?

Proof of Actor private beta-ত আছে। Early access-ৰ বাবে আবেদন কৰক। নিৰ্বাচিত founding developer দলসমূহে agreed usage limits-ৰ ভিতৰত 12 months পৰ্যন্ত free access পাব পাৰে।

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

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

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

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