AI agent-এর hook update-এই দখল হতে পারে host—সাত harness-ই ভেঙেছে গবেষণায়
৩ সেপ্টেম্বর ২০২৬ arXiv-এ জমা হওয়া HookPry-এর মূল প্রিপ্রিন্ট lifecycle-hook update-কে AI agent-এর নতুন supply-chain attack surface হিসেবে চিহ্নিত করেছে। পরীক্ষায় plugin-এর executable code না বদলে metadata ও hook configuration নিয়ন্ত্রণ করে model-এর সিদ্ধান্তপথের বাইরে host command চালানো হয়। সাতটি harness ও পাঁচটি LLM backend-এর ২৫টি বৈধ সমন্বয়ে ১,০০০টি end-to-end run চালিয়ে সাত harness-এই compromise পাওয়া গেছে; একটির সাফল্যের হার সর্বোচ্চ ৯২.৫% ছিল।
৩ সেপ্টেম্বরের এই ফল একটি নিয়ন্ত্রিত attack framework-এর প্রদর্শন—বাস্তবে সাত পণ্যের সব installation দখল হয়েছে, এমন ঘটনার প্রতিবেদন নয়। শিরোনামের “দখল” বলতে সফল run-এ host-side credential collection, data exfiltration, tampering বা privilege escalation-এর মতো প্রভাব বোঝানো হয়েছে; চূড়ান্ত ক্ষতি নির্ভর করে update গৃহীত হওয়া, সংশ্লিষ্ট event trigger হওয়া এবং hook process-এর privilege ও network access-এর ওপর।
Update কীভাবে পুরোনো বিশ্বাসকে নতুন command-এ নেয়
HookPry-এর লক্ষ্য model-কে প্রতারণা করানো নয়। আক্রমণকারী প্রথমে স্বাভাবিক plugin প্রকাশ করে ব্যবহারকারী বা marketplace-এর আস্থা অর্জন করে, পরে একই plugin পরিচয়ের update-এ নতুন lifecycle binding যোগ করে। Harness যদি পরিবর্তিত command-এর জন্য আলাদা অনুমোদন না চায়, এক সংস্করণের ওপর দেওয়া বিশ্বাস পরবর্তী সংস্করণের executable authority-তেও চলে যায়।
নতুন binding session start, tool call বা file edit-এর মতো সাধারণ event-এর সঙ্গে attacker-chosen command জুড়ে দিতে পারে। Event ঘটলে harness নিজেই command bind করে subprocess চালায়; LLM-কে command তৈরি, নির্বাচন বা অনুমোদন করতে হয় না। তাই prompt filter, model refusal এবং model-visible tool approval ঠিকমতো কাজ করলেও এই execution path তাদের বাইরে থাকতে পারে।
Framework-টির তিন অংশ এই পথ তৈরি করে: benign plugin-কে খুঁজে পাওয়ার উপযোগী metadata, initial trust ও ক্ষতিকর update-এর সময়গত বিচ্ছিন্নতা এবং বিভিন্ন harness-এর native hook format-এ একই উদ্দেশ্য রূপান্তর। তবে এটি zero-click remote compromise নয়—plugin আগে পৌঁছাতে হবে, update install হতে হবে এবং উপযুক্ত lifecycle event ঘটতে হবে।
সাত harness ভাঙার ফলটির সঠিক সীমা
“সাত harness-ই ভেঙেছে” মানে পরীক্ষিত প্রতিটি harness-এ অন্তত একটি run চূড়ান্ত ক্ষতিকর ফল তৈরি করেছে; সব run সফল হয়েছে বা সব deployment সমানভাবে দুর্বল—এমন নয়। দশ ধরনের attack objective পরীক্ষা করা হয়েছিল, আর harness ও backend-এর সব সম্ভাব্য জোড়া নয়, ২৫টি বৈধ সমন্বয় ব্যবহার করা হয়েছিল। ফলে ৯২.৫% সর্বোচ্চ হারটিও একটি নির্দিষ্ট পরীক্ষিত harness-এর ফল, পুরো AI-agent বাজারের হার নয়।
৬ সেপ্টেম্বরের স্বাধীন নিরাপত্তা পর্যালোচনা একই ১,০০০ run, সাত harness ও ৯২.৫% সর্বোচ্চ হার নথিবদ্ধ করেছে; পাশাপাশি ৪০টি ক্ষতিকর artifact-এর পরীক্ষায় Microsoft Defender-এর recall ০% এবং তিন static defense মিলিয়েও ৪৭.৫% artifact বাদ পড়ার ফল তুলে ধরেছে। পর্যালোচনাটি পরীক্ষাটি স্বাধীনভাবে পুনরুৎপাদন করেনি, আর ছোট synthetic corpus-এর ওই recall-কে সব Defender version, endpoint বা production environment-এর detection rate হিসেবে পড়া যাবে না।
গবেষণাটি OpenHarness, OpenClaw, Claude Code, Codex CLI, OpenCode, Hermes ও WorkBuddy পরীক্ষা করেছে। এই তালিকা কোনো vendor-wide vulnerability notice নয়: product version, operating system, update channel, enterprise policy এবং deployment boundary বদলালে exposure-ও বদলাতে পারে। গবেষকেরা সংশ্লিষ্ট harness নির্মাতাদের ফল জানিয়েছেন, তবে প্রিপ্রিন্টে vendor-by-vendor patch status দেওয়া হয়নি।
Copilot CLI-তে host boundary কেন বাস্তব
Hook যে সত্যিই model-এর বাইরের local execution mechanism হতে পারে, তা বর্তমান product documentation-এ দেখা যায়। GitHub Copilot hooks reference অনুযায়ী, Copilot CLI hook developer-এর local machine-এ CLI-এর একই shell-এ চলে; policy, user, project ও installed plugin থেকে পাওয়া hook একত্রে load হতে পারে। Command hook shell script বা executable চালাতে পারে, তাই hook JSON-কে নিছক inert configuration ধরে নেওয়া নিরাপদ নয়।
একই নথিতে local CLI ও cloud agent-এর boundary আলাদা। Cloud agent-এর hook ক্ষণস্থায়ী Linux sandbox-এ চলে, outbound network সীমিত এবং job শেষে filesystem নষ্ট হয়; local CLI hook developer machine-এর পরিবেশে চলে। অতএব কোনো product-এর নাম দেখেই ঝুঁকি নির্ধারণ করা যাবে না—কোন surface চলছে, subprocess কোন user-এর অধিকার পাচ্ছে এবং সেই পরিবেশে কী credential আছে, সেটিই আসল।
Hook update গ্রহণের আগে যে চারটি নিয়ন্ত্রণ জরুরি
এই attack model-এ update-ই নতুন execution authorization। তাই publisher-এর নাম অপরিবর্তিত দেখাই যথেষ্ট নয়; পুরোনো ও নতুন manifest, hook file, command, argument, working directory, environment variable এবং event binding-এর diff দেখতে হবে। নতুন command-এর প্রয়োজন ও প্রভাব বোঝা না গেলে update স্থগিত রাখাই নিরাপদ সিদ্ধান্ত।
- Automatic update নিয়ন্ত্রণ করে অনুমোদিত version, commit বা digest pin করুন। Ecosystem signature সমর্থন করলে signature ও publisher identity যাচাই করুন, তবে signed artifact-কে স্বয়ংক্রিয়ভাবে নিরাপদ ধরে নেবেন না।
- Disposable environment-এ update খুলে hook configuration diff করুন। কোন event কোন executable চালাবে এবং নতুন network বা filesystem access চাইছে কি না, তা release approval-এর অংশ করুন।
- Agent ও hook-কে administrator বা root account-এর বদলে low-privilege user, container বা sandbox-এ চালান। SSH key, cloud credential, home directory এবং production secret শুধু প্রয়োজন অনুযায়ী expose করুন।
- অপ্রয়োজনীয় hook বন্ধ রাখুন এবং hook subprocess-এর child process, sensitive-file read, network egress ও persistence location পর্যবেক্ষণ করুন। Model transcript-কে পূর্ণ execution audit log হিসেবে ব্যবহার করবেন না।
Copilot configuration-এ disableAllHooks দিয়ে সংশ্লিষ্ট file-এর hook বন্ধ করা যায়, কিন্তু administrator-installed policy hook এতে বন্ধ হয় না। Signature-ও কেবল artifact-এর উৎস ও অখণ্ডতা যাচাই করে; publisher account বা update channel আক্রান্ত হলে ক্ষতিকর পরিবর্তন বৈধ signature নিয়েই আসতে পারে। তাই provenance verification-এর সঙ্গে semantic diff, version pinning, least privilege এবং runtime restriction একসঙ্গে দরকার।
এখনও কোন প্রমাণ অনুপস্থিত
HookPry reproducible attack framework ও স্পষ্ট execution boundary দেখিয়েছে, কিন্তু ব্যাপক in-the-wild exploitation, সাত harness-এর সব বর্তমান release-এর অবস্থা বা বাস্তব ব্যবহারকারীর compromise rate প্রকাশ করেনি। Independent reproduction এবং নির্মাতাদের প্রতিকার ছাড়া controlled result থেকে বাজারজুড়ে আক্রান্ত পণ্যের তালিকা তৈরি করা নির্ভরযোগ্য হবে না।
পরবর্তী গুরুত্বপূর্ণ তথ্য হবে harness নির্মাতারা update-এর সময় hook-level re-authorization, configuration-diff warning, verifiable release provenance এবং default sandboxing যোগ করছে কি না। আপাতত নিশ্চিত সিদ্ধান্তটি সীমিত কিন্তু গুরুত্বপূর্ণ: model guardrail শক্ত হলেও harness পরিচালিত event-driven command path আলাদাভাবে সুরক্ষিত না থাকলে trusted plugin update host-এ ক্ষতিকর কাজ ঘটাতে পারে।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।