মূল বিষয়বস্তুতে যান
DETECTION এবং LIMITATIONS

Proof of Actor কী নির্ধারণ করতে পারে, আর কী পারে না।

classification, সেগুলোর পেছনের evidence, কোন context-এ সেগুলো প্রযোজ্য, এবং আমরা যে সীমাবদ্ধতাগুলো বিবেচনায় নিয়ে design করি - তার একটি সরল বর্ণনা।

সিগন্যাল · প্রতি উৎসের সর্বশেষ অনুরোধ
  • অনুরোধের স্বাক্ষরvalid · sample-crawler.exampleverified
  • client ঘোষণা"research-assistant/2.1"declared
  • ব্রাউজার ইন্টারঅ্যাকশনpointer + keyboard eventsinferred
  • কোনো supported signal নেইroute not instrumentedunknown

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

Proof of Actor আপনাকে কী বলতে পারে এবং কী guarantee করতে পারে না
Proof of Actor আপনাকে কী বলতে পারে (যেখানে supported)এটি কী guarantee করতে পারে না
কোনো supported agent request signature বৈধ কি নাAgent সৎ, নিরাপদ, বা কোনো action করার অনুমতি পেয়েছে
কোনো session নির্দিষ্ট interactive বা automation সংকেত দেখায় কি নাএকজন human আপনার observable integration-এর বাইরে কোনো AI ব্যবহার করেননি
AI ব্যবহার declared ছিল কি না বা supported workflow-এ তা দেখা গেছে কি নাAI assistance, copied content, বা অন্য device-এর universal detection
সেই evidence পর্যাপ্ত ছিল নাকোনো unknown interaction malicious

উপলব্ধতা আপনার ইন্টিগ্রেশন এবং সক্রিয় চেকগুলোর ওপর নির্ভর করে। প্রয়োগ-সংক্রান্ত সিদ্ধান্তের নিয়ন্ত্রণ অ্যাপ্লিকেশনের মালিকের কাছেই থাকে।

Classification

চারটি public class। প্রতিটির একটি নির্ধারিত অর্থ এবং একটি স্পষ্ট সীমা আছে।

  • মানুষ

    সমর্থিত পর্যবেক্ষণযোগ্য সিগন্যালগুলো মানব-নির্দেশিত ইন্টারঅ্যাকশন নির্দেশ করে।

    এর অর্থ এই নয়: কোনো AI ব্যবহার করা হয়নি, অথবা ব্যক্তির বাস্তব-জগতের identity verified।

  • মানুষ + AI

    AI assistance declared করা হয়েছিল, অথবা এমন একটি supported integration দ্বারা detected হয়েছিল যা সত্যিই সেটি পর্যবেক্ষণ করতে পারে।

    এর অর্থ এই নয়: সব hidden AI use শনাক্ত করা যায়, অন্য tab বা অন্য device-সহ।

  • এজেন্ট

    স্বয়ংক্রিয় বা agent-উৎপন্ন interaction, যা যাচাইযোগ্য পরিচয় বা সতর্কভাবে নির্ধারিত অনুমানের দ্বারা সমর্থিত।

    এর অর্থ এই নয়: Agent authorized, safe, বা একজন ব্যক্তির বৈধ delegation নিয়ে কাজ করছে।

  • অজানা

    উপলব্ধ evidence একটি নির্ভরযোগ্য সিদ্ধান্ত সমর্থন করে না।

    এর অর্থ এই নয়: Interactionটি সন্দেহজনক বা malicious।

Verified, declared, inferred, unknown

প্রতিটি result-এর সঙ্গে একটি basis থাকে। কোনো class কখনও inference-কে cryptographic verification হিসেবে উপস্থাপন করে না, যা security-sensitive application-এর ক্ষেত্রে সবচেয়ে গুরুত্বপূর্ণ।

verified
যাচাইকৃত. একটি cryptographic বা অন্যভাবে যাচাইযোগ্য assertion যাচাই করা হয়েছে, যেমন published key-এর বিপরীতে একটি request signature। এটি সেই যাচাইটিই প্রমাণ করে, এর বেশি কিছু নয়।
declared
ঘোষিত. Actor বা আপনার application এটি বলেছে, যেমন AI-assistance disclosure বা নিজেকে agent হিসেবে পরিচয় দেওয়া কোনো client। Declaration মিথ্যা হতে পারে।
inferred
অনুমিত. আচরণগত বা প্রাসঙ্গিক signals থেকে গৃহীত একটি সিদ্ধান্ত। Inferences ভুল হতে পারে এবং সবসময় inferences হিসেবেই চিহ্নিত থাকে।
unknown
অজানা. সিদ্ধান্তের জন্য যথেষ্ট evidence নেই। অনুমান করার বদলে ফলাফল Unknown হিসেবে report করা হয়।

যেখানে confidence figure-এর জন্য পেছনে পরীক্ষিত, calibrated model দরকার, সেখানে আমরা তার বদলে qualitative evidence strength ব্যবহার করি। 99.7% human-এর মতো কোনো figure আপনি আমাদের কাছ থেকে দেখবেন না, যদি না তা পরিমাপ করা এবং ব্যাখ্যা করা হয়ে থাকে।

সমর্থিত context এবং তাদের সীমা

  • ব্রাউজার

    একটি browser collector এটি যে পৃষ্ঠাগুলিতে চলে সেখানে interactive sessions দেখতে পায়। এটি JavaScript না চালানো clients, অন্য tab, application বা device-এ থাকা activity, বা অন্য কোথাও থেকে একজন ব্যক্তি কপি করে আনা text দেখতে পারে না।

  • সার্ভার এবং API

    একটি server-side integration request context দেখে এবং, যেখানে client তা সমর্থন করে, request signatures দেখে। এটি একজন ব্যক্তির screen দেখতে পারে না, এবং বেশিরভাগ unsigned client নিজেদের যেভাবে ইচ্ছা সেভাবেই বর্ণনা করতে পারে।

  • MCP

    একটি MCP server ক্লায়েন্টের declared details এবং এটি যে tool call করে তা দেখে। declared client name একটি declaration, verification নয়।

বোঝার মতো দুটি সীমা

অন্য tab বা device থেকে তৈরি AI-generated text

কোনো ব্যক্তি অন্য tab-এ, বা তাদের phone-এ, একটি chatbot-কে প্রশ্ন করে এবং উত্তরটি আপনার form-এ paste করলে, সাধারণ web traffic সাধারণত সে সম্পর্কে কিছুই দেখায় না। sessionটি human-directed দেখায় কারণ একজন মানুষ সেটিকে নির্দেশ করেছে।

শুধুমাত্র তখনই Proof of Actor Human + AI রিপোর্ট করে যখন assistance declared হয়েছে, বা এমন supported integration দ্বারা observed হয়েছে যা সত্যিই তা দেখতে পারে, যেমন আপনার app-এর নিজস্ব assistant feature।

signed bot request কী প্রমাণ করে

একটি HTTP message signature যা published key-এর বিরুদ্ধে validate হয়, তা দেখায় যে request-টি এমন একটি key দিয়ে signed হয়েছে যা সেই identifier-এর সঙ্গে যুক্ত, যেমন operator-এর domain।

এটি অনুরোধের পেছনে থাকা ব্যক্তির বাস্তব জগতের পরিচয়, কোনও ব্যক্তি কি এতে কর্তৃত্ব অর্পণ করেছিলেন, বা কাজটি নিরাপদ বা অনুমোদিত কি না, তা প্রতিষ্ঠা করে না। এই ক্ষেত্রের মান, IETF Web Bot Auth কাজসহ, এখনও Internet-Drafts।

Defaultভাবে blocking নয়

Proof of Actor ডিফল্টভাবে কিছুই block, reject বা challenge করে না। আমরা শুধু inferred actor result-এর ভিত্তিতে block বা reject করার পরামর্শ দিই না, এবং বিশেষ করে মানুষের সম্পর্কে গুরুত্বপূর্ণ সিদ্ধান্তের ক্ষেত্রে (কর্মসংস্থান, credit, financial services, education বা essential services-এ প্রবেশাধিকার) কেবল তার উপর ভিত্তি করে সিদ্ধান্ত না নেওয়ার পরামর্শ দিই।

Enforcement আপনার application-এ ঘটে, আপনার team যে policy বেছে নেয় এবং নিশ্চিত করে তার অধীনে, Unknown এবং timeout-এর জন্য explicit fallback সহ।

Unknown এবং abstention

প্রমাণ যদি নির্ভরযোগ্য নির্ধারণকে সমর্থন না করে, তাহলে ফলাফল হয় Unknown। Unknown কখনও Human-এ রূপান্তরিত হয় না, এবং এর মানে সন্দেহজনক নয়। এটিকে দৃশ্যমান রাখা আপনাকে বলে দেয় আপনার coverage কোথায় শেষ হয়, যা কিছু enforce করার আগে আপনার প্রয়োজনীয় তথ্য।

Privacy এবং governance principle

  • উদ্দেশ্য সীমাবদ্ধতা

    Evidence application owner-কে interaction বর্ণনা করে। এটি cross-site profile তৈরি করতে ব্যবহার করা হয় না।

  • ন্যূনতম সংগ্রহ

    প্রতিটি integration তার context-এর প্রয়োজন অনুযায়ী data সংগ্রহ করে। Sensitive telemetry-এর জন্য explicit opt-in প্রয়োজন।

  • টেন্যান্ট আইসোলেশন

    একজন customer-এর evidence কখনও অন্য customer-এর কাছে দৃশ্যমান নয়।

  • কনফিগারযোগ্য retention

    অনবোর্ডিং-এর সময় প্রতিটি founding team-এর সঙ্গে ধরে রাখার মেয়াদে সম্মতি হয়।

  • গ্রাহক-নিয়ন্ত্রিত access

    আপনি ঠিক করেন আপনার দলের কারা প্রমাণ এবং ফলাফল দেখতে পারবে।

  • কোনো identity check নয়

    কোনো biometric collection বা identity verification Proof of Actor-এর অংশ নয়।

প্রতিটি team-এর সঙ্গে agreed

অনবোর্ডিং-এর সময় ধরে রাখার সময়সীমা, data fields এবং processor নিয়ে সম্মতি হয় এবং প্রতিটি founding team-এর জন্য তা নথিভুক্ত করা হয়।

Performance এবং methodology

coverage, unknown rate, false positive এবং calibration প্রতিটি supported context-এ founding team-এর সঙ্গে পরিমাপ করা হয়, সেই outcome-এর বিরুদ্ধে যেগুলো তারা আগে থেকেই জানে। প্রতিটি context পরিপক্ব হলে methodology এবং result এখানে প্রকাশ করা হয়।

privacy বা security সম্পর্কে প্রশ্ন আছে? [email protected]