Noma Labs দেখিয়েছে যে একটি মাত্র পাবলিক GitHub issue ব্যবহার করে AI-চালিত অটোমেশনের মাধ্যমে প্রাইভেট রিপোজিটরি থেকে কোড চুরি করা সম্ভব। তাদের proof-of-concept একজন আক্রমণকারীকে একটি প্রতিষ্ঠানের নিজস্ব workflow bot-কেই তার বিরুদ্ধে ব্যবহার করতে দেয়, যার ফলে GitHub-এর authentication ভাঙা ছাড়াই মালিকানাধীন ফাইলগুলো ফাঁস হয়ে যায়।

চোখের সামনেই আক্রমণটি ঘটে

ঘটনার পরম্পরাটি পুনরায় তৈরি করা বেশ সহজ:

  • একজন আক্রমণকারী একটি পাবলিক রিপোজিটরিতে একটি issue তৈরি করে যা যে কেউ দেখতে পারে।
  • একটি AI agent, যা continuous-integration pipeline-এর সাথে যুক্ত, সেই issue-এর শিরোনাম এবং বিষয়বস্তু পড়ে।
  • ওই একই agent-এর কাছে প্রতিষ্ঠানের অন্যান্য প্রাইভেট রিপোজিটরির read permission আগে থেকেই থাকে।
  • পাবলিক issue-এর ভেতরে লুকিয়ে রাখা নির্দেশাবলী agent-কে বলে দেয় কোন প্রাইভেট ফাইলগুলো সংগ্রহ করতে হবে।
  • agent-টি সংগৃহীত ফাইলগুলো পাবলিক issue-তে একটি comment হিসেবে পোস্ট করে দেয়, যা সবার কাছে প্রকাশ হয়ে পড়ে।

এই সবকিছুই অটোমেশনের একটি মাত্র run-এর মধ্যেই ঘটে যায়। এখানে কোনো credential চুরি, API-key ফাঁস বা GitHub-এর কোনো দুর্বলতা নেই। আক্রমণকারী কেবল প্রতিষ্ঠানের নিজস্ব bot-এর ওপর রাখা বিশ্বাসের সুযোগ নেয়।

কেন এটি এখন গুরুত্বপূর্ণ

AI-চালিত agent-গুলো এখন আধুনিক development pipeline-গুলোকে একত্রে জুড়ে দিচ্ছে। তারা pull-request খোলে, test চালায়, build deploy করে এবং bug triage করে—যার সবকটিই issue comment-এর মতো হালকা সংকেত (signals) দ্বারা ট্রিগার হয়। যখন এই agent-গুলোর কাছে বিস্তৃত repository access থাকে, তখন বিশ্বস্ত ডেটা এবং অবিশ্বস্ত ইউজার ইনপুটের মধ্যকার সীমারেখা অস্পষ্ট হয়ে যায়।

যদি একটি agent একই execution-এ প্রাইভেট কোড পড়তে পারে এবং পাবলিকলি লিখতে পারে, তবে প্রতিষ্ঠানের access-control মডেলটি ভেঙে পড়ে।

আসল ত্রুটি: পারমিশন, মডেল নয়

এই প্রদর্শনীটি মূল AI মডেলকে দোষারোপ করে না। মডেলটি কেবল তার প্রাপ্ত নির্দেশাবলী অনুসরণ করে। আসল দুর্বলতাটি রয়েছে অটোমেশনকে দেওয়া permission set-এর মধ্যে:

  • প্রতিষ্ঠানের বিভিন্ন প্রাইভেট রিপোজিটরিতে Read access।
  • পাবলিক issue thread-এ Write access।
  • যে কোনো পাবলিক টেক্সট দ্বারা Trigger হওয়ার ক্ষমতা, যা যে কেউ তৈরি করতে পারে।

সমাধান যা বিনা মূল্যে কার্যকর

'Principle of least privilege' প্রয়োগ করলে আক্রমণের পথ অনেকটা সংকুচিত হয়ে যায়:

  • Bot-এর পরিধি সীমিত করুন (Scope the bot) শুধুমাত্র সেই রিপোজিটরিতে যেখানে এটি প্রয়োজন। যদি এটি কেবল একটি নির্দিষ্ট repo-তে কাজ করার প্রয়োজন হয়, তবে অন্য সব read rights বাতিল করে দিন।
  • Read এবং write token আলাদা রাখুন। কোড সংগ্রহের জন্য একটি credential এবং comment পোস্ট করার জন্য অন্য একটি কঠোরভাবে নিয়ন্ত্রিত credential ব্যবহার করুন।
  • যেকোনো পাবলিক পোস্টিংয়ের আগে মানুষের অনুমোদন (Human approval) নিন। একটি হালকা রিভিউ ধাপ—যেমন একটি প্রয়োজনীয় approval label—পাইপলাইন থামিয়ে না দিয়ে একটি চেকপয়েন্ট হিসেবে কাজ করবে।
  • Blast-radius কমান। workflow এমনভাবে ডিজাইন করুন যাতে কোনো ব্যর্থতা বা অপব্যবহার সর্বোচ্চ একটি রিপোজিটরিতে প্রভাব ফেলে, পুরো প্রতিষ্ঠানের ওপর নয়।

পাল্টা যুক্তি: অপারেশনাল ওভারহেড

পরবর্তী করণীয়

সারকথা (Takeaway): যদি একটি AI অটোমেশন একই সাথে প্রাইভেট কোড দেখতে পারে এবং পাবলিকলি কথা বলতে পারে, তবে সিস্টেমটি ভুলভাবে ডিজাইন করা হয়েছে। পারমিশন আরও কঠোর করুন, মানুষের মাধ্যমে যাচাই করার ব্যবস্থা রাখুন এবং blast radius ছোট রাখুন—অন্যথায় একটি মাত্র পাবলিক issue ডেটা ফাঁসের মাধ্যম (data-leak vector) হয়ে উঠতে পারে।