AIR পেল ৫ কোটি ডলার—AI agent-এর plugin এখন supply-chain ঝুঁকি
AI security startup AIR ১ সেপ্টেম্বর ২০২৬-এ stealth থেকে বেরিয়ে AI agent-এর context সুরক্ষার platform প্রকাশ্যে এনেছে। AIR-এর আনুষ্ঠানিক ঘোষণায় পণ্যটিকে এমন একটি firewall হিসেবে বর্ণনা করা হয়েছে, যা endpoint, cloud ও SaaS পরিবেশে অবিশ্বস্ত input agent-এর context-এ পৌঁছানোর আগে ছেঁকে দেবে।
একই দিনে AIR-এর মোট ৫ কোটি ডলারের অর্থায়ন ও আনুষ্ঠানিক আত্মপ্রকাশের খবর প্রকাশিত হয়। SiliconANGLE-এর প্রতিবেদনে দুটি round-এর মোট অঙ্ক, বিনিয়োগকারীদের পরিচয় এবং agent discovery, component re-check ও runtime blocking—এই পণ্যকাঠামো নিশ্চিত করা হয়েছে। এটি প্রচলিত network firewall-এর বিকল্প নয়; কোনো enterprise agent কোন skill, plugin, add-on বা MCP server-এর ওপর ভরসা করবে, AIR সেই নতুন trust boundary-তে কাজ করতে চায়।
দুই seed round-এর অর্থায়ন কীভাবে হয়েছে
অর্থায়নটি এক দফায় আসেনি। TechCrunch-এর বিস্তারিত তথ্য অনুযায়ী, কয়েক সপ্তাহের ব্যবধানে প্রথম seed round-এ ১ কোটি ডলার এবং দ্বিতীয়টিতে ৪ কোটি ডলার তোলা হয়; প্রথমটির নেতৃত্ব দেয় Sequoia, দ্বিতীয়টির Greenoaks। Swish, Netz এবং প্রযুক্তি ও নিরাপত্তা খাতের কয়েকজন angel investor-ও অংশ নিয়েছেন।
AIR-এর সহপ্রতিষ্ঠাতা ও প্রধান নির্বাহী Yair Saban এবং সহপ্রতিষ্ঠাতা ও প্রযুক্তিপ্রধান Niv Hoffman। প্রতিষ্ঠানটি নতুন মূলধন গবেষক নিয়োগ এবং যুক্তরাষ্ট্র ও ইউরোপে বাণিজ্যিক কার্যক্রম বাড়াতে ব্যবহার করার পরিকল্পনা করেছে। বড় অঙ্কের দুটি seed round দেখায় যে বিনিয়োগকারীরা agent-এর সঙ্গে যুক্ত তৃতীয় পক্ষের capability যাচাইকে আলাদা নিরাপত্তা অবকাঠামো হিসেবে দেখছেন; তবে অর্থায়ন নিজে পণ্যের কার্যকারিতার প্রমাণ নয়।
AIR-এর তিন স্তর: discovery, enforcement ও allowlist
প্রথম স্তর discovery। AIR endpoint, cloud account ও SaaS ব্যবস্থায় সক্রিয় agent খুঁজে তাদের ব্যবহৃত skills, plugins, MCP servers ও অন্যান্য add-on-এর inventory তৈরির কথা বলছে। অনুমোদিত agent-এর ওপর policy বসালেও অজানা বা কোনো বিভাগের নিজস্ব উদ্যোগে চালু করা agent নিয়ন্ত্রণের বাইরে থাকতে পারে; তাই discovery পরবর্তী নিয়ন্ত্রণগুলোর ভিত্তি।
দ্বিতীয় স্তর enforcement। কোনো agent skill load করলে, internet থেকে content আনলে বা বাইরের tool ব্যবহার করলে AIR সেই action ও input পরীক্ষা করে নিরাপত্তা criteria না-পেরোনো উপাদান ঠেকাতে চায়। “Firewall” উপমাটি এখানেই প্রযোজ্য: platformটি network packet নয়, agent কী দেখছে এবং কোন capability নিজের context-এ গ্রহণ করছে, সেই পথ নিয়ন্ত্রণের দাবি করছে।
তৃতীয় স্তর একটি রক্ষণাবেক্ষণ করা allowlist ও যাচাইকৃত add-on marketplace। আগে অনুমোদন পাওয়া component পরে বদলে গেলে, তার dependency পাল্টালে বা publisher account compromised হলে AIR পুনরায় পরীক্ষা করার কথা বলছে। কোনো component malicious, vulnerable বা অননুমোদিত হিসেবে চিহ্নিত হলে কোন agent ও workflow তার ওপর নির্ভর করছে, তা শনাক্ত করে ব্যবহার প্রত্যাহার করাও প্রস্তাবিত ব্যবস্থার অংশ।
Plugin ও MCP কেন supply-chain boundary
একটি agent-এর মূল model ও system instruction প্রতিষ্ঠানের নিয়ন্ত্রণে থাকলেও কাজ সম্পন্ন করতে তাকে বাইরের capability ব্যবহার করতে হতে পারে। Skill বিশেষ কাজের instruction বা code দিতে পারে, plugin ও add-on বাইরের service বা function যুক্ত করে, আর Model Context Protocol বা MCP server agent-কে tool ও data source-এর সঙ্গে সংযুক্ত করে। এগুলো স্বয়ংক্রিয়ভাবে ক্ষতিকর নয়; ঝুঁকি তৈরি হয় যখন publisher, instruction source, permission, dependency ও ভবিষ্যৎ update—সব কিছুকে একসঙ্গে বিশ্বাস করতে হয়।
এই trust boundary-তে অন্তত তিনটি পৃথক আক্রমণপথ থাকে। Agent runtime-এ বিষাক্ত instruction সিদ্ধান্ত বদলাতে পারে; third-party tool বৈধ credential ব্যবহার করেই সংবেদনশীল data পড়তে বা action নিতে পারে; আবার package বা remote dependency update আগে অনুমোদিত component-এর আচরণ পাল্টে দিতে পারে। ফলে installation-এর সময় একবার scan করলেই আস্থা স্থায়ী হয় না।
MCP-এর ক্ষেত্রেও server, publisher, প্রকাশিত tool এবং প্রতিটি tool-এর permission আলাদা করে বিবেচ্য। একটি server অনুমোদিত হলেই তার সব tool, পরবর্তী version বা ফেরত দেওয়া content সমানভাবে নিরাপদ—এমন সিদ্ধান্ত নেওয়া যায় না। AIR-এর প্রস্তাবিত অবস্থান এই সংযোগগুলো deployment-এর আগে যাচাই করা এবং ব্যবহারের সময় পরিবর্তন হলে আবার পরীক্ষা করা।
২৭ শতাংশ বাদ দেওয়ার দাবি কতটা শক্ত
AIR বলছে, online-এ পাওয়া add-on ও skill-এর প্রায় ২৭ শতাংশ তার platform filter করে বাদ দেয়। এটি প্রকাশ্য agent ecosystem-এর একটি অংশ AIR-এর নিজস্ব security criteria পূরণ করেনি—এমন vendor-reported সংকেত; পুরো ecosystem-এর স্বাধীনভাবে প্রতিষ্ঠিত vulnerability rate নয়।
দাবিটির সঙ্গে সম্পূর্ণ sample list, sampling period, পরীক্ষার পুনরুৎপাদনযোগ্য methodology বা স্বাধীন audit প্রকাশ করা হয়নি। “বাদ দেওয়া” বলতে malware শনাক্ত হওয়া, অতিরিক্ত permission, সন্দেহজনক external instruction, পরিবর্তিত dependency কিংবা AIR-এর approval policy না-পেরোনো—কোন কারণ কতবার ঘটেছে, তার পূর্ণ বিভাজনও পাওয়া যায় না। তাই অন্য কোনো গবেষণার শতাংশের সঙ্গে সরাসরি তুলনা করার আগে dataset, সংজ্ঞা ও পরীক্ষার শর্ত মিলতে হবে।
প্রযুক্তি ক্রেতার জন্য অমীমাংসিত বিষয় হলো block করার criteria, false positive সামলানোর পদ্ধতি এবং জরুরি exception-এর auditability। Allowlist কত ঘন ঘন refresh হয়, remote dependency বদলালে কত দ্রুত পুনর্মূল্যায়ন হয় এবং enforcement এড়িয়ে যাওয়ার চেষ্টা কীভাবে ধরা পড়ে—এসব তথ্য ছাড়া ২৭ শতাংশকে launch metric হিসেবেই পড়তে হবে।
কী প্রমাণিত, কী এখনো বাকি
এখন নিশ্চিত তথ্য হলো, AIR দুই seed round-এ মোট ৫ কোটি ডলার তুলেছে এবং agent discovery, inline enforcement ও যাচাইকৃত capability তালিকাকে একটি platform-এ আনছে। কোম্পানিটি যে সমস্যাকে লক্ষ্য করছে, তা model-এর বাইরের স্তরে: skill, plugin, MCP server, website কিংবা internal content agent-এর context-এ অবিশ্বস্ত instruction বা বদলে যাওয়া software পৌঁছে দিতে পারে।
তবে AIR-এর detection ও prevention ক্ষমতা নিয়ে স্বাধীন benchmark, false-positive হার, inspection latency এবং বিভিন্ন agent platform-এ coverage-এর পূর্ণ তথ্য প্রকাশিত হয়নি। পরবর্তী গুরুত্বপূর্ণ প্রমাণ হবে স্বচ্ছ evaluation methodology, পরিবর্তিত package শনাক্ত করতে প্রয়োজনীয় সময়, enforcement bypass পরীক্ষা এবং customer deployment-এর যাচাইযোগ্য ফল। সেগুলো না আসা পর্যন্ত “firewall” প্রতিষ্ঠিত category standard নয়, AIR-এর পণ্য-অবস্থান।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।