সংজ্ঞা
এটা actor result-ৰ evidence basis-এ তাৰ পিছৰ evidence-ৰ ধৰণ বৰ্ণনা কৰে। Proof of Actor-এ চাৰিটা মান ব্যৱহাৰ কৰে:
- verified: এটা cryptographic বা অন্য ধৰণে পৰীক্ষাযোগ্য assertion সফল হৈছিল।
- declared: actor বা application-এ সেয়া উল্লেখ কৰিছিল।
- inferred: behavioral বা contextual সংকেতৰ পৰা সিদ্ধান্ত উলিওৱা হৈছিল।
- unknown: নির্ধাৰণৰ বাবে পর্যাপ্ত প্রমাণ নাছিল।
প্ৰতিটো result-এ এটা class (Human, Human + AI, Agent বা Unknown, application traffic-ৰ বাবে আমাৰ taxonomy-ত বৰ্ণিত) আৰু এটা basis দুয়োটা বহন কৰে। "Agent, verified" আৰু "Agent, inferred" দুটা পৃথক result আৰু সেই অনুসাৰে পৃথকভাৱে ব্যৱহাৰ কৰিব লাগে।
এই basis কিয় গুৰুত্বপূর্ণ
Basis নাথাকিলে classification-এ ই কিমান দায়িত্ব বহন কৰিব পাৰে সেয়া আড়াল হৈ যায়। এটা dashboard-এ যদি signed request-ৰ বাবে "Agent" আৰু request timing-ৰ ওপৰত ভিত্তি কৰি কৰা অনুমানৰ বাবে "Agent" দেখুৱায়, তেনেহ'লে দলসমূহ দুয়োটাৰ বাবে একে policy প্রয়োগ কৰিবলৈ উৎসাহিত হয়। বিশেষকৈ security-sensitive application-সমূহত inference-এ কেতিয়াও cryptographic verification যেন দেখা দিব নালাগে।
Class আৰু basis পৃথক কৰিলে policy-সমূহে প্রমাণৰ শক্তিৰ সৈতে মিল খায়:
- এটা read-only route-এ যিকোনো Agent result অনুমতি দিব পাৰে।
- অধিক প্ৰভাৱশালী route-এ কেৱল verified agent-সমূহক known operator হিচাপে গণ্য কৰিব পাৰে আৰু বাকী সকলোৰে পৰা অধিক শক্তিশালী credential দাবী কৰিব পাৰে।
চাৰিটা মানৰ বিশদ ব্যাখ্যা
Verified
কিবা এটা পৰীক্ষা কৰা হৈছিল আৰু সফল হৈছিল। আটাইতকৈ স্পষ্ট উদাহৰণ হৈছে এটা HTTP message signature (RFC 9421) যি agent-ৰ operator-এ প্রকাশ কৰা key-ৰ বিপৰীতে validate হয়। Verified evidence-এ নির্দিষ্ট check-টোহে প্রমাণ কৰে, তাৰ বাহিৰে একো নহয়: এটা valid signature-এ দেখুৱায় কোন key-এ request-টো sign কৰিলে, action-টো authorized আছিল নে নহয় সেয়া নহয়।
Declared
কোনোবাই তেনেকৈ ক'লে। নিজকে agent বুলি নাম দিয়া client, MCP client name, বা আপোনাৰ নিজৰ application-ৰ ভিতৰৰ AI-assistance disclosure-সমূহ declaration। এইবোৰ উপযোগী, প্ৰায়ে সত্য, আৰু কেতিয়াবা ভুলও হ'ব পাৰে। User-agent spoofing হৈছে ভুল declaration-ৰ ধ্ৰুপদী উদাহৰণ। User-Agent header-টো নকশাৰ পৰাই self-reported।
Inferred
System-এ সংকেতৰ পৰা যুক্তি কৰিছিল: browser session-ৰ interaction pattern, request timing, browser context-ৰ অভাৱ, protocol details। Inference ভুল হ'ব পাৰে, সেইবাবেই ইয়াক সদায় inference হিচাপে label কৰা হয় আৰু মানুহ সম্পর্কীয় consequential সিদ্ধান্ত কেতিয়াও কেৱল ইয়াৰ ওপৰত নির্ভৰ কৰিব নালাগে।
Unknown
প্রমাণে নির্ধাৰণ সমর্থন নকৰিলে। এইটো Unknown classification-ৰ সৈতে মিলে আৰু আপোনাৰ policy-ত এটা স্পষ্ট fallback-লৈ map হ'ব লাগে। আমাৰ AI traffic classify কৰোঁতে Unknown এটা বৈধ result কিয় বিষয়ে লিখা post-এ সেয়া ব্যাখ্যা কৰে।
Basis বনাম confidence score
বহু system-এ evidence-টো এটা মাত্র সংখ্যাত সংকোচিত কৰে। এটা score-এ ইয়াৰ উৎস cryptographic check নে heuristic আছিল সেয়া লুকুৱায়, আৰু এটা uncalibrated percentage-এ অস্তিত্ব নথকা precision-ৰ আভাস দিয়ে। নামকৰণ কৰা basis-ৰ এটা সৰু set-এ যুক্তি কৰা সহজ, audit কৰা সহজ, আৰু অপব্যৱহাৰ কৰাটো কঠিন।
সাধাৰণ ভুল বুজাবুজি
"Declared মানে অবিশ্বাস্য।" Declaration-সমূহ প্ৰায়ে সঠিক হয় আৰু কিছুমান প্রশ্নৰ বাবে একমাত্ৰ উপলব্ধ evidence, যেনে AI-assistance disclosure। সিহঁত কেৱল verification হিচাপে গণ্য কৰা উচিত নহয়।
"Verified মানে নিৰাপদ।" Verification-ৰ বিষয় হৈছে signer-ৰ পরিচয়, উদ্দেশ্য বা অনুমতি নহয়।
Proof of Actor-ত evidence basis
প্ৰতিটো Proof of Actor result-এ তাৰ basis আৰু evidence-ৰ এটা human-readable summary দেখুৱায়। Policy-সমূহ আপোনাৰ application-ত চলে আৰু class আৰু basis একেলগে ব্যৱহাৰ কৰিব পাৰে। Detection & Limitations চাওক বা early access-ৰ বাবে আবেদন কৰক।
উৎসসমূহ
- RFC 9421: HTTP Message Signatures: verified evidence-ৰ আটাইতকৈ স্পষ্ট উৎস
- RFC 9110: HTTP Semantics, User-Agent: এটা self-reported, declared identifier