মুখ্য সামগ্ৰীৰ পৰা এৰাই চাওক
অজানা ট্রাফিক

অজানা স্বয়ংক্রিয় ট্রাফিক দৃশ্যমান কৰক

বেছিভাগ application-এ তেওঁলোকৰ স্বয়ংক্রিয় traffic-ৰ এক বৃহৎ অংশ ঠিক কোন ধৰণৰ সেইটো ক'ব নোৱাৰে। Proof of Actor-এ সেই traffic-ক নিজৰ এক পৃথক class হিচাপে দৃশ্যমান ৰাখে, যাতে আপুনি ইয়াক মাপিব, কমাব আৰু সচেতনভাৱে পৰিচালনা কৰিব পাৰে।

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

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

যি traffic-ৰ নাম কেউ নাজানে

এটা application-ৰ log ভালদৰে চালে আপুনি এনে request পাব যি ব্যাখ্যা কৰিবলৈ মানি নলয়। সিহঁত browser context নথকা client-ৰ পৰা আহে। সিহঁতৰ user-agent string generic, খালী বা জনপ্ৰিয় browser-ৰ পৰা copied। সিহঁতে নিজৰ request sign নকৰে। সিহঁতে কোনে পঠালে সেয়া নকয়। কিছুমান নিৰাপদ script। কিছুমান বাস্তৱ user-ৰ হৈ কাম কৰা agent। কিছুমান এনে tool যাক আপুনি একেবাৰে serve কৰিব নুখুজে।

এইটো অজানা স্বয়ংক্রিয় traffic, আৰু বেছিভাগ team-এ ইয়াক দুটা উপায়ৰ এটাৰে সামলে। হয়তো ইয়াক নীৰৱে human হিচাপে গণনা কৰা হয়, যাৰ ফলত analytics বিকৃত হয় আৰু ঝুঁকিপূর্ণ activity পাৰ হৈ যায়, নহ'লে default-তে hostile বুলি ধৰা হয়, যাৰ ফলত legit user আৰু agent-কে ধৰি বাকী সকলো block হয়। দুয়োটা approach-এ একে ত্ৰুটি ভাগ কৰে: সিহঁতে missing evidence-ৰ ঠাইত assumption দিয়ে।

Proof of Actor বিপৰীত দৃষ্টিভংগী লয়। যদি evidence-এ নিৰ্ভৰযোগ্য determination সমৰ্থন নকৰে, তেনেহ'লে সঠিক উত্তৰ Unknown, আৰু Unknown দৃশ্যমান, মাপযোগ্য আৰু ইচ্ছাকৃতভাৱে পৰিচালিত হোৱা উচিত। AI traffic-ৰ বাবে Unknown এটা বৈধ result কিয় এই blog post-এ সম্পূৰ্ণ যুক্তি দিয়ে।

Unknown কিয় এটা first-class result

Proof of Actor-এ প্ৰতিটো interaction-এ চাৰিটা class-ৰ এটাত ভাগ কৰে: Human, Human + AI, Agent বা Unknown। Unknown কোনো error state বা product-ৰ ফাঁক নহয়। ই এক সচেতন result, যাৰ অৰ্থ স্পষ্ট: উপলব্ধ evidence-এ নিৰ্ভৰযোগ্য determination সমৰ্থন নকৰে।

সেই সৎভাৱৰ practical সুবিধা আছে।

  • আপোনাৰ analytics সঠিক থাকে। Human আৰু Agent count-ত কেৱল সমৰ্থিত evidence থকা interaction-সমূহেই থাকে, সেয়ে সিহঁতে যি কয় সেয়াই বুজায়।
  • আপোনাৰ coverage মাপযোগ্য হয়। প্ৰতিটো route-ত Unknown-ৰ অংশে আপোনাক ঠিক দেখুৱায় ক'ত অধিক evidence লাগে।
  • আপোনাৰ policy অধিক সুৰক্ষিত হয়। অনিশ্চিত case-সমূহ আপোনাৰ নিৰ্বাচিত fallback-লৈ যায়, অনুমান কৰি নীৰৱে trusted বা blocked কৰা নহয়।

Unknown কেতিয়াও Humanলৈ ৰূপান্তৰ কৰা নহয়, আৰু default-তে ইয়াক malicious বুলিও ধৰা নহয়। আপুনি Unknown classification glossary entry-ত, Detection & Limitations-ত, আৰু AI traffic-ৰ বাবে Unknown এটা বৈধ result কিয়-ত অধিক পঢ়িব পাৰে। websites আৰু APIs use case-সমূহে দেখুৱায় দলসমূহে practical ৰূপে Unknown fallback কেনেকৈ স্থাপন কৰে।

অজানা স্বয়ংক্রিয় traffic ক'ৰ পৰা আহে

উৎসসমূহ বুজিলে ইয়াক কেনেকৈ সামলাব সেইটো ঠিক কৰাত সহায় হয়।

Unsigned automated client

RFC 9421-ত সংজ্ঞায়িত HTTP Message Signatures-ৰ সৈতে request signing ঐচ্ছিক, আৰু IETF Web Bot Auth working group এতিয়াও automated client-এ এই ধৰণে প্ৰমাণীকৰণ কেনেকৈ কৰিব লাগে সেইটো standardize কৰি আছে। Signature নাথাকিলে client-ৰ পৰিচয় সি নিজৰ বিষয়ে যি কয় তাৰ ওপৰতেই নিৰ্ভৰ কৰে।

Copied বা generic user agent

User-agent string স্থাপন কৰা অতি সহজ। এটা client-এ নিজকে well-known browser বা crawler বুলি দাবী কৰিলে সেয়া সঁচাকৈও তেনেকুৱা হ'ব পাৰে, বা অনুকৰণো হ'ব পাৰে। user-agent spoofing entry-এ বুজায় কিয় এই header-এ একাই classification বহন কৰিব নোৱাৰে। সেই কাৰণেই search engine-এ পৃথক verification method নথিভুক্ত কৰে: Google-এ verifying Googlebot-ৰ বাবে reverse আৰু forward DNS lookup-ৰ সৈতে প্ৰকাশিত IP range বৰ্ণনা কৰে, আৰু Bing-এ verifying Bingbot-ৰ বাবে একেটা DNS check বৰ্ণনা কৰে।

Integration নথকা route

যদি কোনো route-ত browser integration নাথাকে আৰু মৌলিক বিষয়ৰ বাহিৰে server-side context নাথাকে, তেনেহ'লে observe কৰাৰ বস্তু সৰলভাৱে কম থাকে। সেই route-সমূহত Unknown থকা মানে coverage-ৰ সংকেত, threat-ৰ নহয়।

Missing বা delayed evidence

Timeout, blocked script বা অসম্পূৰ্ণ request-এ যথেষ্ট evidence নথকা result এৰি যাব পাৰে। Proof of Actor-এ সেইটো পূৰ্ণ কৰাৰ সলনি সৎভাৱে প্ৰতিবেদন কৰে।

Proof of Actor-এ Unknown কেনেকৈ পৰিচালনাযোগ্য কৰে

Proof of Actor-এ নিজৰ কাম তিনিটা capability-ত সংগঠিত কৰে। প্ৰতিটোৱেই অজানা স্বয়ংক্রিয় traffic-ত সহায় কৰে।

Detect: Unknown পৃথক ৰাখক

Signal-সমূহ basis অনুসৰি পৰীক্ষা আৰু label কৰা হয়: verified, declared, inferred বা unknown। সিহঁতে যদি determination সমৰ্থন নকৰে, তেনেহ'লে result-টো Unknown হয়, আৰু কি উপলব্ধ আছিল আৰু কি নাছিল তাৰ এটা summary থাকে। কিছুমানো অন্য class-লৈ অনুমান কৰি নিয়া নহয়।

Understand: Unknown ক'ত বাস কৰে দেখক

Understand view-এ প্ৰতিটো breakdown-ত, route আৰু সময়ৰ সৈতে, Unknown দেখুৱায়। আপুনি কোন route-ত সৰ্বাধিক unknown activity আছে, আপুনি integration যোগ কৰাৰ পিছত ই কেনেকৈ সলনি হয়, আৰু ব্যক্তিগত interaction-ৰ বাবে কোন evidence উপস্থিত আছিল সেয়া দেখিব পাৰে। ইয়াৰ ফলত এক অস্পষ্ট চিন্তা এটা স্পষ্ট মানচিত্ৰলৈ পৰিণত হয়।

Route: প্ৰতিটো route-ৰ বাবে fallback বাছনি কৰক

ভিন্ন route-এ ভিন্ন fallbackৰ যোগ্য। বহু application-ৰ বাবে এটা উপযুক্ত আৰম্ভণিৰ বিন্দু:

  • Public page আৰু documentation: আপোনাৰ standard rate limit-ৰ সৈতে Unknown allow কৰক।
  • Signup আৰু onboarding: আপোনাৰ বিদ্যমান check ৰাখক, আৰু আপোনাৰ নিজৰ condition-এ দাবী কৰিলে তেতিয়াহে review যোগ কৰক।
  • Account change আৰু অন্য sensitive action: আপোনাৰ বিদ্যমান authentication আৰু step-up control-ৰ ওপৰত নিৰ্ভৰ কৰক, actor guess-ৰ ওপৰত নহয়।
  • উচ্চ-প্ৰভাৱযুক্ত API operation: আপোনাৰ API-এ ইতিমধ্যে সমৰ্থন কৰা অধিক শক্তিশালী credential বা control দাবী কৰক।

handling unknown traffic-ৰ guide-এ এই fallback ডিজাইন কেনেকৈ কৰিব সেইটো দেখুৱায়, প্ৰতিটো risk tier-ৰ বাবে fail-open আৰু fail-closed বাছনি সহ।

সময়ৰ সৈতে Unknown কমোৱা

লক্ষ্য হৈছে Unknown-ক ৰাতিৰ ভিতৰতে নাইকিয়া কৰা নহয়। সঠিক কাৰণত ইয়াক প্ৰতিমাহে সৰু কৰা।

  • য'ত গুৰুত্বপূৰ্ণ তাত integration যোগ কৰক। key page-ত browser integration আৰু key route-ত server-side integration-এ উপলব্ধ evidence বৃদ্ধি কৰে।
  • Signed request সমৰ্থন কৰক। agent operator-এ HTTP message signatures গ্ৰহণ কৰাৰ লগে লগে, যি traffic Unknown আছিল সেয়া verified Agent traffic হয়।
  • আপোনাৰ নিজৰ app-ত declaration ৰেকৰ্ড কৰক। আপোনাৰ application-এ যেতিয়া জানে যে AI assistance জড়িত, তেতিয়া সেয়া কওক। সেই evidence নিখুঁত আৰু সস্তা।
  • Agent-লৈ এটা front door দিয়ক। agent-ৰ বাবে structured path প্ৰকাশ কৰিলে সিহঁতে মিহলি হৈ থকাৰ সলনি নিজৰ পৰিচয় দিবলৈ উৎসাহ পায়।

কাৰণ Proof of Actor-এ Unknown-ক route অনুসৰি track কৰে, আপুনি এই প্ৰতিটো পৰিৱৰ্তন সংখ্যা-ত দেখিব পাৰে।

ই কেনেকৈ কাম কৰে

প্ৰতিটো interaction একে evidence-first পথ অনুসৰণ কৰে, How It Works-ত সম্পূৰ্ণভাৱে বৰ্ণনা কৰা মতে: আপোনাৰ application-এ এটা request বা event গ্ৰহণ কৰে, integration-এ সেই context-ত উপলব্ধ signal সংগ্ৰহ কৰে, signal-সমূহ normalize কৰি explicit basis-সহ classify কৰা হয়, result analytics-ৰ বাবে record কৰা হয়, আৰু আপোনাৰ application-এ নিজৰ policy প্ৰয়োগ কৰে বা কেৱল observe কৰে।

Timeout আৰু missing telemetry স্পষ্টভাৱে সামলোৱা হয়। আপোনাৰ integration-এ সেই route-ৰ বাবে আপুনি বাছনি কৰা fallback ব্যৱহাৰ কৰে, আৰু evidence নথকাৰ বাবে result কেতিয়াও Humanলৈ উন্নীত কৰা নহয়।

কেইমাহৰ পিছত ভাল দেখাৰ ৰূপ

অজানা স্বয়ংক্রিয় traffic ভালদৰে সামলোৱা team-সমূহ সাধাৰণতে একে সুস্থ অৱস্থাত উপনীত হয়। Unknown প্ৰতিটো গুৰুত্বপূৰ্ণ route-ত এক জনা পৰিমাণ, human আৰু agent activity-ৰ সৈতে একে dashboard-ত track কৰা হয়। প্ৰতিটো route-ৰ এটা লিখিত fallback থাকে যি product, platform আৰু security team-এ একেলগে মানি লৈছে। অধিক operator-এ নিজৰ request sign কৰাৰ সৈতে verified agent traffic বৃদ্ধি পায়, আৰু সেই agent-সমূহ structured path-ৰ জৰিয়তে serve কৰা হয়, page scrape কৰি নহয়। Sensitive action-সমূহ application-এ ইতিমধ্যে বিশ্বাস কৰা authentication আৰু step-up control-এ সুৰক্ষিত কৰে, actor context-টো gatekeeper নহৈ এক অতিৰিক্ত input হিচাপে থাকে।

সবচেয়ে গুৰুত্বপূর্ণ কথা, কেউ অনুমান নকৰে। যেতিয়া কোনোবাই সোধে যোৱা সপ্তাহৰ traffic-ৰ কিমান অংশ automated আছিল, উত্তৰটো basis-সহ আহে: এতিয়ালৈকে ইমান verified, ইমান declared, ইমান inferred, আৰু ইমান এতিয়াও Unknown। এইটো এটা সংখ্যা যাৰ ওপৰত দল-এ পৰিকল্পনা কৰিব পাৰে। ই নেতৃত্বৰ সৈতে হোৱা কথোপকথনো সলনি কৰে, কাৰণ প্ৰশ্নটো bot সমস্যা আছে নে নাই সেয়াৰ পৰা সলনি হৈ কোন route-এ অধিক evidence আৰু কোন fallback-এ refinement লাগে তাত যায়।

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

Proof of Actor default-তে একো block নকৰে। Observation mode-ত আপোনাৰ application আগৰ দৰেই respond কৰাৰ সময়তে result record কৰা হয়। আপোনাৰ team-এ প্ৰতিটো route-এ কিমান অজানা স্বয়ংক্রিয় traffic পায় সেয়া দেখে, আপুনি ইতিমধ্যে জনা outcome-ৰ সৈতে তুলনা কৰে, আৰু বাস্তৱ pattern-ৰ ওপৰত ভিত্তি কৰি fallback design কৰে। Policy-সমূহ এটা এটাকৈ route-ত enable কৰা হয়, কেৱল তেতিয়াহে যেতিয়া আপোনাৰ team নিশ্চিত হয় সিহঁত উপযুক্ত।

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

Proof of Actor private beta-ত আছে। নিৰ্বাচিত founding developer team-এ agreed usage limit-ৰ ভিতৰত, product feedback-ৰ বিনিময়ত, আমাৰ engineer-ৰ পৰা direct integration support-সহ up to 12 months free access পাব পাৰে।

যদি অজানা স্বয়ংক্রিয় traffic-এ আপোনাৰ analytics বা security decision অস্পষ্ট কৰি তুলিছে, early access-ৰ বাবে apply কৰক। আপোনাৰ application আৰু যি route-ত Unknown আটাইতকৈ গুৰুত্বপূৰ্ণ সেইবোৰৰ বিষয়ে আমাক কওক।

Proof of Actor অন্বেষণ কৰক, how it works পঢ়ক, বা evidence কি স্থাপন কৰিব পাৰে সেয়া দেখক।

উৎস

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

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

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

অজানা স্বয়ংক্রিয় traffic কি?

ই এনে activity য'ত উপলব্ধ evidence-এ নিৰ্ভৰযোগ্যভাৱে দেখুৱাই নাথাকে যে এজন human, AI-সহ এজন human, নে এজন autonomous agent কাৰ্য কৰিছে, প্ৰায়ে browser context নথকা unsigned client আৰু generic বা copied user-agent string-সহ।

অজানা traffic কেৱল block নকিয়?

Unknown মানে malicious নহয়। ইয়াৰ ভিতৰত legitimate client, privacy-focused browser আৰু নিজকে পৰিচয় নিদিয়া tool অন্তৰ্ভুক্ত থাকে। ইয়াক সোজাকৈ block কৰিলে বাস্তৱ ক্ষতি হয়। প্ৰতিটো route-ত deliberate fallback বহুত ভাল কাম কৰে।

Proof of Actor-এ কেতিয়াবা Unknown-ক Humanলৈ ৰূপান্তৰ কৰে নেকি?

কেতিয়াও নহয়। evidence নাথাকিলেও বা check timeout হ'লেও Unknown ফলাফল Unknown-তেই থাকে। আপোনাৰ policy-এ প্ৰতিটো route-ৰ বাবে fallback বাছনি কৰে।

অজানা traffic সময়ৰ সৈতে কমাব পাৰি নেকি?

হয়। অধিক route-ত integration যোগ কৰা, signed request সমৰ্থন কৰা আৰু আপোনাৰ app-ত declaration ৰেকৰ্ড কৰাই traffic-ক Unknown-ৰ পৰা স্পষ্ট basis থকা class-লৈ লৈ যায়।

অজানা traffic মই ক'ত দেখিব পাৰি?

Understand view-ত Unknown-ৰ প্ৰতিটো breakdown-ত, route আৰু সময়ৰ সৈতে, আৰু প্ৰতিটো interaction-ৰ বাবে উপলব্ধ evidence-সহ নিজৰ class থাকে।

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

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

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

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