এআই এজেন্টরা এখন চ্যাট উইন্ডোর গণ্ডি পেরিয়ে এসেছে। তারা এখন মিটিং বুক করে, গ্রাহকের তথ্য আপডেট করে, অভ্যন্তরীণ ডেটাবেস অনুসন্ধান করে, এবং...

AI এজেন্টরা এখন আর শুধু চ্যাট উইন্ডোর মধ্যে সীমাবদ্ধ নেই। তারা এখন মিটিং বুক করছে, কাস্টমার রেকর্ড আপডেট করছে, ইন্টারনাল ডেটাবেস কুয়েরি করছে এবং আর্থিক লেনদেন সম্পন্ন করছে। উপদেষ্টা থেকে অপারেটরে এই রূপান্তর ঝুঁকির ধরণ পুরোপুরি বদলে দিচ্ছে। যখন সফটওয়্যার কেবল পরামর্শ দেওয়া বন্ধ করে কাজ করা শুরু করে, তখন প্রতিটি API এন্ডপয়েন্ট একটি সম্ভাব্য প্রবেশদ্বারে পরিণত হয়। প্রথাগত নিরাপত্তা মডেলগুলো মানুষের অনুমেয় আচরণের ওপর ভিত্তি করে তৈরি করা হয়েছিল: একজন ব্যক্তি লগ ইন করেন, পরিচিত পথগুলো অনুসরণ করেন এবং লগ আউট করেন। কিন্তু স্বায়ত্তশাসিত এজেন্টরা সেই প্যাটার্ন অনুসরণ করে না। তারা কয়েক সেকেন্ডের মধ্যে শত শত কলের মাধ্যমে লুপ করে, পুনরায় চেষ্টা করে এবং বিভিন্ন দিকে শাখা বিস্তার করে। API লেয়ার, যা মূলত মানুষের নির্দেশিত অনুরোধের জন্য ডিজাইন করা হয়েছিল, এখন ক্রমাগত স্বয়ংক্রিয় চাপের সম্মুখীন হচ্ছে। আপনার প্রতিরক্ষা ব্যবস্থা যদি এখনও গত প্রান্তিকের লেখা স্থির নিয়মের ওপর নির্ভর করে, তবে আপনি ডেটা ফাঁস এবং অননুমোদিত অ্যাক্সেসের জন্য দরজা খোলা রেখে দিচ্ছেন। আপনার এমন রিয়েল-টাইম ডিফেন্স প্রয়োজন যা প্রতিটি কল হওয়ার সাথে সাথে তা মূল্যায়ন করতে পারে।

এজেন্টের প্রিভিলেজ সীমিত করুন

এজেন্ট ডেপ্লয়মেন্টের ক্ষেত্রে সবচেয়ে বিপজ্জনক শর্টকাট হলো একটি শক্তিশালী API কী হস্তান্তর করা। একটি কী দিয়ে প্রতিটি সিস্টেমের সমস্ত অ্যাক্সেস পাওয়া সম্ভব। যদি কোনো আক্রমণকারী একটি বিষাক্ত প্রম্পট (poisoned prompt) বা হাইজ্যাক করা ইন্টিগ্রেশনের মাধ্যমে এজেন্টের নিয়ন্ত্রণ নিতে পারে, তবে তারা পুরো সাম্রাজ্যের চাবিকাঠি পেয়ে যাবে। রিকভারি করা একটি দুঃস্বপ্নে পরিণত হবে কারণ এর প্রভাবের ব্যাপ্তি (blast radius) আপনার ইমেল সার্ভিস থেকে শুরু করে প্রোডাকশন ডেটাবেস পর্যন্ত সবকিছুকে কভার করবে।

এই অভ্যাসটি অবিলম্বে ত্যাগ করুন। ডেলিগেটেড অথরাইজেশনের জন্য OAuth 2.0 দিয়ে শুরু করুন। এজেন্টের উচিত স্বতন্ত্র সুপারইউজার হিসেবে অথেন্টিকেট না করা। পরিবর্তে, এর এমন একটি টোকেন থাকা উচিত যা এজেন্ট এবং যে ব্যবহারকারীকে এটি সেবা দিচ্ছে—উভয়ের প্রতিনিধিত্ব করে। যখন মানুষের সেশন শেষ হবে, এজেন্টের অ্যাক্সেসও তার সাথে শেষ হয়ে যাওয়া উচিত।

Token Exchange এটিকে ব্যবহারিক করে তোলে। এজেন্ট বর্তমানে ঠিক যা প্রয়োজন তার জন্য স্বল্পমেয়াদী টোকেন ইস্যু করুন। একটি শিডিউলিং এজেন্ট ক্যালেন্ডার পড়া এবং ইনভাইট পাঠানোর অনুমতি পেতে পারে, কিন্তু ক্যালেন্ডার ইনফ্রাস্ট্রাকচার মুছে ফেলা বা পেরোল API অ্যাক্সেস করার অনুমতি পাবে না। যদি কোনো আক্রমণকারী টোকেনটি ইন্টারসেপ্ট করে, তবে অপব্যবহারের সুযোগ খুব সীমিত থাকবে।

Context-Bound Scopes আরও একটি স্তর যোগ করে। প্রতিটি টোকেনকে ডিফল্টভাবে 'রিড-অনলি' রাখুন। যদি এজেন্টের ডেটা লেখার প্রয়োজন হয়, যেমন রিফান্ড প্রসেস করা বা কোনো চুক্তি আপডেট করা, তবে মানুষের অনুমোদনের একটি ধাপ (human approval gate) নিশ্চিত করুন। টাকা লেনদেন, অ্যাকাউন্ট পরিবর্তন বা রেকর্ড মুছে ফেলার সিদ্ধান্ত কখনোই একা মডেলকে নিতে দেবেন না। অনুমতিটি সেই মুহূর্তের প্রয়োজনের সাথে সামঞ্জস্যপূর্ণ হওয়া উচিত, সর্বোচ্চ ক্ষমতার সাথে নয়।

Ephemeral Windows এই চক্রটিকে সম্পূর্ণভাবে বন্ধ করে দেয়। টোকেনের মেয়াদ দিন হিসেবে নয়, বরং মিনিটে পরিমাপ করুন। একটি সংক্ষিপ্ত কম্প্রোমাইজের সময় যদি কোনো টোকেন চুরিও হয়, আক্রমণকারী যখন এটি পুনরায় ব্যবহার করার চেষ্টা করবে, ততক্ষণে সেটি অকেজো হয়ে যাবে। এটিকে একটি ক্রমাগত পরিবর্তনশীল লক হিসেবে ভাবুন।

একটি সেলস অটোমেশন এজেন্টের কথা চিন্তা করুন যা আপনার CRM থেকে লিড ডেটা পড়ে এবং আপনার মেইল API-এর মাধ্যমে ফলো-আপ ইমেল পাঠায়। একটি চিরস্থায়ী অ্যাডমিন কী-এর পরিবর্তে, এজেন্ট আপনার আইডেন্টিটি প্রোভাইডার থেকে ১৫ মিনিটের একটি টোকেন পাবে। টোকেনটি CRM রিড এবং মেইল পাঠানোর অনুমতি দেবে, কিন্তু কন্টাক্ট ডিলিট করা এবং বিলিং অ্যাক্সেস ব্লক করবে। যদি এজেন্ট পুরো ডেটাবেস এক্সপোর্ট করার মতো কোনো সন্দেহজনক নির্দেশ পায়, তবে এই স্কোপটি সেই চেষ্টাটিকে আটকে দেবে।

ইনডাইরেক্ট প্রম্পট ইনজেকশন বন্ধ করুন

প্রম্পট ইনজেকশন এখন আর চ্যাটবটের জন্য কোনো মজার খেলা নয়। এজেন্টিক যুগে, এটি ইমেলের মাধ্যমে আসা রিমোট কোড এক্সিকিউশনের মতো কাজ করে।

এখানে একটি বাস্তব উদাহরণ দেওয়া হলো। একটি এজেন্ট মিটিং শিডিউল করার জন্য ব্যবহারকারীর ইনবক্স মনিটর করে। একটি মেসেজের ভেতরে, হয়তো অদৃশ্য টেক্সট বা অ্যাটাচমেন্টের মেটাডেটার মধ্যে, এমন একটি কমান্ড লুকিয়ে থাকতে পারে যা সমস্ত ইনভয়েস একটি বাহ্যিক ঠিকানায় ফরোয়ার্ড করতে এবং আসল ইনভয়েসগুলো মুছে ফেলতে নির্দেশ দেয়। এজেন্ট ইমেলটি পড়ে, বিষাক্ত টেক্সটটিকে একটি বৈধ সিস্টেম নির্দেশ হিসেবে ভুল করে এবং API কল করা শুরু করে। যেহেতু এজেন্টটি নিজেই অনুমোদিত, তাই এই ক্ষতিকারক অনুরোধগুলো স্বাভাবিক চ্যানেলের মাধ্যমেই প্রবাহিত হয়। এর ফলে অননুমোদিত ডেটা এক্সফিল্ট্রেশন ঘটে যা দেখতে সাধারণ আচরণের মতোই মনে হয়।

আপনার প্রথম প্রতিরক্ষা হলো কঠোর ইনপুট ভ্যালিডেশন। AI যা কিছু জেনারেট করে, তার প্রতিটি প্যারামিটারকে প্রমাণিত না হওয়া পর্যন্ত অনির্ভরযোগ্য হিসেবে গণ্য করুন। আপনার API গেটওয়েতে JSON-schema ভ্যালিডেশন চালান। যদি এজেন্ট কোনো কাস্টমার রেকর্ড অনুরোধ করে, তবে গেটওয়ে যাচাই করবে যে পেলোডটিতে শুধুমাত্র একটি প্রত্যাশিত আইডেন্টিফায়ার আছে কি না, কোনো ওয়াইল্ডকার্ড বা অস্বাভাবিক বড় ব্যাচ রিকোয়েস্ট নয়। আপনার ব্যাকএন্ডে পৌঁছানোর আগেই যেকোনো ত্রুটিপূর্ণ, অতিরিক্ত বড় বা কৃত্রিমভাবে অদ্ভুত অনুরোধ প্রত্যাখ্যান করুন।

Second, deploy data exfiltration filters on the response path. API responses should pass through inspection before they reach the AI. Scan for patterns that match secrets, authentication tokens, or bulk personal information. If a CRM query returns ten thousand records instead of one, block it. If the payload contains an internal API key, redact it. The agent does not need raw secrets to do its job, and outbound channels must not become smuggling routes for stolen data.

Third, enforce domain whitelisting. The agent needs to communicate with your calendar service, your payment processor, and your internal inventory system. It does not need to talk to arbitrary file-sharing sites, pasteboard services, or foreign cloud storage endpoints. Restrict outbound DNS resolution and HTTP requests to an explicit allow-list. Even if an attacker tricks the agent into trying to ship data elsewhere, the network layer simply refuses the connection.

Build Zero-Trust Architectures

Zero-trust is not a product you install. It is a design philosophy built on one assumption: the agent is already compromised. Act accordingly.

That means splitting identity cleanly. The human user and the agent are not the same entity, even when the agent acts on the user’s behalf. Maintain separate service identities for the agent itself, distinct from the human’s SSO session. Your audit logs should capture both identities side by side. When something goes wrong, you