এআই এজেন্টকে ন্যূনতম অধিকার দিন—sandbox একা যথেষ্ট নয়

এআই এজেন্টকে নিরাপদে চালাতে প্রতিটি agent ও environment-এর পৃথক পরিচয় দিন, কাজভিত্তিক ন্যূনতম অনুমতি নির্ধারণ করুন এবং credential কেবল কাজের সময় ইস্যু করুন। সঙ্গে outbound network default-deny রাখুন, প্রতিটি tool call নথিবদ্ধ করুন এবং পরীক্ষিত kill switch দিয়ে agent, credential ও সংযোগ একসঙ্গে থামানোর ব্যবস্থা করুন।
Sandbox দরকার, কারণ এটি agent-এর file, process ও runtime resource সীমিত করে। কিন্তু এর ভেতরের process যদি production API token, বিস্তৃত database role বা অবাধ internet access পায়, prompt injection কিংবা ভুল পরিকল্পনা সেই বৈধ পথ ব্যবহার করেই ক্ষতি করতে পারে। তাই sandbox-কে একমাত্র নিরাপত্তা-সীমানা না ধরে identity, authorization, network policy ও incident response-এর একটি স্তর হিসেবে ব্যবহার করতে হবে।
১. Agent-এর পরিচয় ও কাজের সীমানা নির্ধারণ করুন
মানুষের ব্যক্তিগত account বা shared service account দিয়ে agent চালাবেন না। প্রতিটি agent ও deployment environment-এর জন্য শনাক্তযোগ্য workload identity রাখুন; প্রয়োজন হলে প্রতিটি run-ও আলাদাভাবে শনাক্ত করুন। Log থেকে যেন বোঝা যায় কোন agent, কোন ব্যবহারকারী বা service-এর অনুরোধে এবং কোন policy version মেনে কাজ করেছে।
NIST-এর AI Agent Standards Initiative agent authentication, identity infrastructure ও security evaluation-কে নিরাপদ agent ecosystem-এর মৌলিক গবেষণার ক্ষেত্র হিসেবে রেখেছে। ছোট দলের জন্য এর বাস্তব অর্থ হলো, model-এর নামকে পরিচয় না ধরে execution identity-কে authentication ও authorization-এর কেন্দ্রে রাখা।
Agent-এর কাজকে অনুমোদিত সম্পদ, operation ও সময়সীমায় ভাঙুন। “Repository পরিচালনা” কার্যকর permission নয়; “নির্দিষ্ট repository পড়া, feature branch-এ commit লেখা, production branch-এ merge না করা” enforce করা যায়। সিদ্ধান্ত ও execution-ও আলাদা রাখুন: agent পরিবর্তনের প্রস্তাব তৈরি করতে পারে, কিন্তু production deployment বা অপরিবর্তনীয় কাজ মানুষের অনুমোদন ছাড়া চলবে না।
২. তিন environment-এর জন্য পৃথক permission template বানান

একই role development থেকে production পর্যন্ত কপি করলে পরীক্ষার সুবিধাই পরে অতিরিক্ত privilege-এর পথ তৈরি করে। তিনটি template version control-এ রাখুন এবং infrastructure policy হিসেবে review করুন:
- Development: synthetic বা অসংবেদনশীল data, নির্দিষ্ট workspace-এ read-write এবং test tool ব্যবহারের অনুমতি দিন; production secret, customer data ও production endpoint নিষিদ্ধ রাখুন।
- Staging: production-এর মতো schema হলেও masked data ব্যবহার করুন; access শুধু staging service ও test account-এ সীমিত রাখুন। Destructive action সীমিত করুন এবং privileged workflow-তে approval বাধ্যতামূলক করুন।
- Production: dedicated workload identity, নির্দিষ্ট resource ও operation-এর allowlist এবং read-only default রাখুন। Payment, bulk deletion, access-policy পরিবর্তন বা deployment-এর মতো উচ্চ-প্রভাবের কাজে মানুষের পৃথক অনুমোদন নিন।
ASD, CISA, NSA এবং কানাডা, নিউজিল্যান্ড ও যুক্তরাজ্যের সংশ্লিষ্ট সংস্থার যৌথ agentic AI নিরাপত্তা নির্দেশিকা secure sandbox-এর সঙ্গে least privilege, নির্দিষ্ট resource-operation-timeframe-এ entitlement সীমাবদ্ধ করা, কাজ শেষে মেয়াদ শেষ হওয়া credential, isolation, monitoring ও পরীক্ষিত incident response রাখার সুপারিশ করে। ফলে production template-এ বিস্তৃত wildcard permission গ্রহণযোগ্য নয়, এমনকি agent sandbox-এ চললেও।
Template-এর acceptance test সরাসরি করুন: agent অনুমোদিত resource পড়তে পারবে, কিন্তু একই ধরনের অননুমোদিত resource পড়তে পারবে না; development identity দিয়ে production endpoint-এ authentication ব্যর্থ হবে; production-এ নিষিদ্ধ write policy layer-এই আটকাবে। শুধু prompt-এ “এ কাজ কোরো না” লেখা authorization control নয়।
৩. Credential ও network egress একসঙ্গে সীমিত করুন
স্থায়ী API key environment variable-এ রেখে image বা container পুনর্ব্যবহার করবেন না। Runtime broker বা workload identity ব্যবস্থা থেকে task-scoped credential ইস্যু করুন, যাতে agent শুধু প্রয়োজনীয় service, action ও resource-এ পৌঁছাতে পারে। কাজ শেষ, timeout, cancellation বা kill switch সক্রিয় হলেই credential বাতিল হতে হবে।
চারটি পরীক্ষায় credential control যাচাই করুন: run শুরুর আগে credential অনুপস্থিত; অন্য agent বা environment সেটি ব্যবহার করতে পারে না; কাজ শেষ হলে একই token দিয়ে অনুরোধ ব্যর্থ হয়; privilege বাড়ানোর অনুরোধ কেন্দ্রীয় policy decision ছাড়া অনুমোদিত হয় না। Secret যেন prompt, memory, tool argument বা log-এ plain text হিসেবে না ঢোকে, তার জন্য redaction test রাখুন।
Network policy default-deny রাখুন। কাজের জন্য প্রয়োজনীয় domain, port, protocol ও API operation স্পষ্ট allowlist-এ দিন; সরাসরি internet access-এর বদলে policy-enforcing egress proxy ব্যবহার করা যেতে পারে। Staging-এ পরীক্ষা করুন arbitrary domain, raw IP, অপরিচিত webhook ও নতুন redirect destination আটকানো হয় কি না।
গ্রহণযোগ্য egress test-এ অনুমোদিত API call সফল হবে, কিন্তু allowlist-এর বাইরের destination ব্যর্থ হবে। অনুমোদিত destination-এও অপ্রত্যাশিত data volume বা secret-সদৃশ payload alert তৈরি করবে। Network isolation তাই শুধু “internet বন্ধ” নয়; কোন পরিচয়, কোন উদ্দেশ্যে, কোথায় এবং কী পাঠাতে পারে—তার enforceable নিয়ম।
৪. Audit trail, alert ও kill switch প্রস্তুত রাখুন

শুধু chat transcript সংরক্ষণ করলে incident পুনর্গঠন করা যাবে না। Audit event-এ agent identity, initiating user বা service, session, policy version, requested tool, resource, authorization result, approval identifier, execution result ও timestamp রাখুন। Secret ও ব্যক্তিগত তথ্য redact করুন, আর agent-কে নিজের security log পরিবর্তন বা মুছতে দেবেন না।
OWASP-এর AI Agent Security Cheat Sheet agent decision, tool call ও ফলাফল log করা, structured audit metadata রাখা, অস্বাভাবিক আচরণ শনাক্ত করা, high-impact action-এ approval নেওয়া এবং agent operation interrupt করার পরামর্শ দেয়। সেই অনুযায়ী repeated denial, approval bypass, privilege পরিবর্তন, অস্বাভাবিক হারে tool call এবং নতুন outbound destination-এর জন্য alert বসান।
Kill switch শুধু process terminate করলে অসম্পূর্ণ থাকে। একটি action-এ নতুন task গ্রহণ বন্ধ, চলমান tool call বাতিল, active credential revoke, outbound egress block এবং pending approval freeze হওয়া দরকার। Control plane agent-এর runtime ও model থেকে স্বাধীন রাখুন, যাতে আপস হওয়া agent switch উপেক্ষা করতে না পারে।
Staging drill-এ একটি অননুমোদিত write বা data-exfiltration প্রচেষ্টা চালান। দলকে দেখাতে হবে যে alert পৌঁছেছে, switch কাজ করেছে, credential আর ব্যবহারযোগ্য নয় এবং অপরিবর্তনীয় log থেকে ঘটনার ক্রম পুনর্গঠন করা যায়। পুনরুদ্ধারের আগে affected identity ও token বদলানো, policy সংশোধন এবং নিরাপদ checkpoint থেকে পুনরায় চালুর দায়িত্বও নির্দিষ্ট করুন।
৫. Production release-এর আগে security gate বসান
Agent-এর model quality ভালো হলেই production release অনুমোদন করবেন না। নিচের প্রতিটি ফলাফলের প্রমাণ CI/CD artifact বা security review-তে সংরক্ষণ করুন:
- Development, staging ও production identity পরস্পরের resource ব্যবহার করতে পারে না।
- অনুমোদিত কাজ সফল হলেও wildcard tool, production secret ও অননুমোদিত write ব্যর্থ হয়।
- Credential task শেষ হওয়ার পর অকার্যকর এবং log বা agent memory-তে প্রকাশিত নয়।
- Allowlist-এর বাইরের network destination ও সন্দেহজনক outbound payload আটকানো হয়।
- প্রতিটি sensitive action-এর identity, authorization, approval ও ফলাফল audit trail-এ খুঁজে পাওয়া যায়।
- Kill switch agent execution, credential ও egress অনুমোদিত operational procedure অনুযায়ী থামায়।
- Incident drill-এ detection, containment, evidence preservation ও controlled recovery সম্পন্ন হয়।
কোনো gate ব্যর্থ হলে production access বাড়াবেন না; agent-কে কম autonomy বা read-only mode-এ রাখুন। Sandbox গুরুত্বপূর্ণ থাকলেও ক্ষতির পরিসর বাস্তবে সীমিত করে পরিচয়ভিত্তিক অনুমতি, স্বল্পমেয়াদি access, network boundary, audit এবং দ্রুত প্রত্যাহারযোগ্য control-এর সম্মিলিত ব্যবস্থা।
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।