শব্দবোৰৰ অৰ্থ কি
request path ত থকা প্ৰতিটো check এ উত্তৰ দিব নোৱাৰিব পাৰে: dependency time out হ’ব পাৰে, signal নোহোৱা হ’ব পাৰে, key fetch কৰিব নোৱাৰিব পাৰে. Fail open মানে request তেনে ধৰণে আগবাঢ়ে যেন check টো তাতেই নাছিল. Fail closed মানে request এ অধিক কঠোৰ পথ লয়: তাক নাকচ কৰা হয়, challenge কৰা হয় বা ইতিমধ্যে থকা অধিক শক্তিশালী control লৈ পঠিওৱা হয়.
সাধাৰণভাৱে কোনোটোৱেই সঠিক নহয়. সঠিক বাছনি নিৰ্ভৰ কৰে route টো কি কৰে আৰু ভুল সিদ্ধান্তৰ খৰচ কিমান তাৰ ওপৰত.
actor checks ৰ ক্ষেত্ৰত ইয়াৰ গুৰুত্ব কিয়
actor checks এ request ত context যোগ কৰে: interaction টো human যেন লাগে নেকি, AI-assisted নেকি, agent-driven নেকি বা unknown নেকি. সেই context উপলব্ধ নাথাকিলে, application টোৱে তথাপিও প্ৰতিক্ৰিয়া দিব লাগে. দুটা failure pattern সাধাৰণ:
- আকস্মিক fail closed. timeout বা signal নোহোৱাটো সন্দেহজনক বুলি গণ্য কৰা হয়, আৰু outage ৰ সময়ত প্ৰকৃত user সকলে block হয়.
- সংবেদনশীল action ৰ ক্ষেত্ৰত আকস্মিক fail open. missing result নীৰৱে human বুলি ধৰা হয়, আৰু উচ্চ-প্ৰভাৱৰ action এ উদ্দেশ্যতকৈ কম scrutiny লৈ আগবাঢ়ে.
দুয়োটাই সিদ্ধান্তটো অপ্রকাশিত কৰি ৰখাৰ ফল. সমাধান হৈছে route অনুসৰি সেইটো স্পষ্টভাৱে ঠিক কৰা. মানৱ আৰু AI agent ৰ বাবে app-level policy ডিজাইন কৰা বিষয়ে আমাৰ লেখা দেখুৱায় যে failure behavior কেনেকৈ per-route policy ৰ অংশ হয়.
কেনেকৈ বাছনি কৰিব
এটা ব্যৱহাৰিক পদ্ধতি হৈছে route সমূহক risk tier ত ভাগ কৰা:
- কম প্ৰভাৱ (public page, documentation, read-only catalog route): fail open. actor result নোহোৱাটোৱে একোৱেই সলনি কৰিব নালাগে.
- মধ্যম প্ৰভাৱ (signup, form submission, খৰচ থকা search): সাধাৰণতে লগিংসহ fail open, বা standard rate limit দৰে এটা কোমল adaptation প্ৰয়োগ কৰা.
- উচ্চ প্ৰভাৱ (account পৰিবর্তন, data export, irreversible action): re-authentication বা confirmation দৰে আপোনাৰ existing stronger control লৈ fail closed. উদ্দেশ্য block কৰা নহয়, বৰঞ্চ আপুনি যি check ব্যৱহাৰ কৰিলেহেঁতেন সেইটোৰ ওচৰলৈ fall back কৰা.
তাৰ পাছত related case সমূহৰ বাবে একে আচৰণ সংজ্ঞায়িত কৰক:
- Timeout: check এ সময়মতে উত্তৰ নিদিলে.
- Missing telemetry: integration চলা নাছিল বা signal অনুপস্থিত আছিল.
- Unknown: check চলিছিল, কিন্তু evidence এ কোনো সিদ্ধান্ত সমৰ্থন কৰা নাছিল.
- Stale evidence: ফলাফল আগৰ সময়ৰ আৰু অধিক সংবেদনশীল action ৰ বাবে পুনৰ ব্যৱহাৰ কৰা উচিত নহয়.
সাধাৰণ ভুল ধাৰণা
- "Fail closed অধিক সুৰক্ষিত." ইয়াৰ খৰচ legitimate user ৰ ওপৰত যায়. কম-প্ৰভাৱৰ route ৰ ক্ষেত্ৰত incident সময়ত fail closed কৰাত prevented risk তকৈ বেছি ক্ষতি হ’ব পাৰে.
- "Unknown মানেই failure." Unknown এটা বৈধ ফলাফল. ইয়াৰ বাবে নিজস্ব স্পষ্ট handling লাগে, আৰু সেয়া আপোনাৰ timeout handling ৰ সৈতে মিলিবও পাৰে বা নাপাওঁও পাৰে.
- "Missing result মানে human." evidence ৰ অভাৱৰ পৰা actor class কেতিয়াও infer নকৰিব.
Proof of Actor এইটো কেনেকৈ সামৰে
Proof of Actor এ timeout বা Unknown result ৰ বাবে কেতিয়াও Human নিযুক্ত নকৰে, আৰু ইয়াক install কৰাত একো block নহয়: team সকলে observation mode ত আৰম্ভ কৰে. প্ৰতিটো route আৰু risk tier ৰ বাবে fail-open বা fail-closed আচৰণ application owner ৰ বাছনি, আৰু সেয়া Route ৰ জৰিয়তে আপোনাৰ নিজৰ code ত প্ৰয়োগ কৰা হয়. ইয়াৰ ফলত enforcement পূৰ্বানুমেয় থাকে আৰু কোনো policy live হোৱাৰ আগতে আপুনি outcome পৰীক্ষা কৰিব পাৰে.
routing সিদ্ধান্তবোৰ কেনেকৈ fit হয় পঢ়ক, বা early access ৰ বাবে আবেদন কৰক.