সংজ্ঞা
একটি actor result-এর evidence basis তার পেছনের evidence-এর ধরন বর্ণনা করে। Proof of Actor চারটি মান ব্যবহার করে:
- verified: একটি cryptographic বা অন্যভাবে যাচাইযোগ্য assertion সফল হয়েছে।
- declared: actor বা application তা জানিয়েছে।
- inferred: behavioral বা contextual signal থেকে সিদ্ধান্ত টানা হয়েছে।
- unknown: নির্ধারণের জন্য যথেষ্ট evidence ছিল না।
প্রতিটি 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-এর ভিত্তিতে অনুমান করা একটি result-এর জন্যও "Agent" দেখানো হয়, তা দলকে দুটির জন্য একই policy প্রয়োগ করতে উৎসাহিত করে। বিশেষ করে security-sensitive application-এর ক্ষেত্রে, একটি inference কখনও cryptographic verification-এর মতো দেখানো উচিত নয়।
class-কে basis থেকে আলাদা করলে policy evidence-এর শক্তির সঙ্গে মেলে:
- একটি read-only route যেকোনো Agent result-কে allow করতে পারে।
- বেশি প্রভাবশালী একটি 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
কেউ তা বলেছে। একটি client যা নিজেকে agent হিসেবে পরিচয় দেয়, একটি MCP client name, বা আপনার নিজের application-এর ভেতরে একটি AI-assistance disclosure - এগুলো declaration। এগুলো উপকারী, প্রায়ই সৎ, এবং কখনও কখনও ভুলও হতে পারে। User-agent spoofing হলো ভুল declaration-এর ক্লাসিক উদাহরণ। User-Agent header নকশাগতভাবেই self-reported।
Inferred
system signal থেকে যুক্তি করেছে: browser session-এর interaction pattern, request timing, browser context-এর অনুপস্থিতি, protocol detail। Inference ভুল হতে পারে, তাই এগুলো সবসময় inference হিসেবে চিহ্নিত থাকে এবং তাই মানুষের সম্পর্কে গুরুত্বপূর্ণ সিদ্ধান্ত কখনও একা এদের ওপর নির্ভর করা উচিত নয়।
Unknown
evidence কোনো নির্ধারণকে সমর্থন করেনি। এটি Unknown classification-এর সঙ্গে মিলে যায় এবং আপনার policy-তে একটি স্পষ্ট fallback-এর সঙ্গে মানচিত্রিত হওয়া উচিত। আমাদের AI traffic classify করার সময় Unknown কেন একটি বৈধ result-বিষয়ক পোস্টে কেন তা ব্যাখ্যা করা হয়েছে।
basis বনাম confidence score
অনেক system evidence-কে একটি একক number-এ গুটিয়ে ফেলে। একটি score লুকিয়ে রাখে এটি cryptographic check থেকে এসেছে নাকি heuristic থেকে, আর একটি অনক্যালিব্রেটেড percentage এমন নিখুঁততার ইঙ্গিত দেয় যা বাস্তবে নেই। নামকরা basis-এর একটি ছোট set বোঝা সহজ, audit করা সহজ, এবং অপব্যবহার করা কঠিন।
সাধারণ ভুল ধারণা
"Declared মানে অবিশ্বস্ত।" Declaration অনেক সময়ই সঠিক হয় এবং কিছু প্রশ্নের জন্য, যেমন AI-assistance disclosure, সেটাই একমাত্র available evidence। তবে সেগুলোকে verification হিসেবে ধরা উচিত নয়।
"Verified মানে নিরাপদ।" Verification signer-এর identity সম্পর্কে, intent বা permission সম্পর্কে নয়।
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