Amazon Quick agent production-এ নেবেন? Prompt নয়, dataset-এই access কাটুন
Amazon Quick-এর proof of concept production-এ নেওয়ার নিরাপদ ভিত্তি হলো prompt-কে access-control boundary না ধরা। কোনো audience-এর যে field দেখার অধিকার নেই, তাদের agent-এর সঙ্গে যুক্ত dataset থেকে সেটি বাদ দিন; তারপর RLS দিয়ে row সীমিত করুন, audience অনুযায়ী agent ও Space আলাদা করুন এবং outbound Flow-এ মানুষের অনুমোদন বসান।
Dashboard-এ field লুকানো বা dashboard permission কমানো যথেষ্ট নয়। AWS-এর companion sample দেখায়, agent-সংযুক্ত dataset-এ salary-এর মতো field থাকলে dashboard-স্তরের বিধিনিষেধ সত্ত্বেও agent সেটি প্রকাশ করতে পারে। তাই production acceptance test শুরু হবে data boundary থেকে, prompt-এর ভাষা থেকে নয়।
প্রথমে audience অনুযায়ী dataset কাটুন
একটি পূর্ণ source dataset থেকে authorization-aligned dataset বা view তৈরি করুন। HR leadership-এর dataset-এ অনুমোদিত ব্যক্তিগত তথ্য থাকতে পারে; department manager-এর dataset থেকে salary, personal identifier ও অপ্রয়োজনীয় sensitive column সরিয়ে দিন; সাধারণ কর্মীদের জন্য রাখুন aggregated dataset। Analysis বা dashboard-এ column hide করা physical removal-এর বিকল্প নয়।
Manager dataset-এ RLS rules dataset যুক্ত করে user বা group identity-কে Department-এর মতো অনুমোদিত মানের সঙ্গে map করুন। Identity provider যে exact username পাঠায়, নিয়মে সেটিই দিতে হবে; format না মিললে শূন্য row আসতে পারে। ব্যক্তির বদলে group-কে permission দিলে কর্মী যোগ, বদলি বা প্রস্থানের access একটি নিয়ন্ত্রিত জায়গায় সামলানো যায়।
Go/no-go পরীক্ষা: একই প্রশ্ন দুটি test account দিয়ে চালান—একটি অনুমোদিত manager, অন্যটি ভিন্ন department-এর persona। প্রথম account কেবল নিজের department-এর row পাবে; দ্বিতীয়টি সেই row পাবে না। বাদ দেওয়া column, নির্দিষ্ট কর্মীর তথ্য এবং aggregate ভেঙে individual record চেয়ে adversarial query-ও চালান। নিষিদ্ধ field schema বা উত্তরে দেখা গেলে release থামান।
Prompt আচরণ নিয়ন্ত্রণ করবে, access নয়
Prompt agent-কে কীভাবে উত্তর দিতে হবে তা বোঝায়, কিন্তু dataset-এ থাকা তথ্যকে অদৃশ্য করে না। প্রতিটি audience-এর জন্য purpose-built agent বানিয়ে সেটিকে সেই audience-এর একটি scoped dataset-এর সঙ্গে যুক্ত করুন। Agent topic-এ শুধু প্রয়োজনীয় field রাখুন এবং individual record বা বাদ দেওয়া metric চাইলে প্রত্যাখ্যানের নির্দেশ দিন—এটি structural control-এর ওপর অতিরিক্ত প্রতিরক্ষা।
AWS-এর production security pattern sensitive column dataset স্তরে সরানো, প্রতিটি agent-কে একটি audience-scoped dataset-এ সীমিত রাখা, document classification এবং outbound action-এর আগে human approval একসঙ্গে প্রয়োগ করে। ফলে agent instruction বদলালেও মূল access boundary dataset ও RLS-এ অক্ষত থাকে।
Space ও document ingestion-এর সীমানা আলাদা করুন
Space-এর role অনুযায়ী ক্ষমতা আলাদা: Owner view, query ও upload করতে পারে; Viewer কেবল view ও query করতে পারে। তাই upload শুধু content owner-দের দিন এবং consumer group-কে প্রয়োজনীয় Viewer access-এ সীমিত রাখুন। Agent, dataset ও Space-এর group membership একই audience model অনুসরণ করছে কি না আলাদাভাবে যাচাই করুন।
প্রতিটি document upload-এর আগে প্রতিষ্ঠানের অনুমোদিত শ্রেণিবিন্যাস—যেমন public, internal, confidential বা restricted—প্রয়োগ করুন। Shared knowledge base-এর audience-এর জন্য অনুপযুক্ত performance review, ব্যক্তিগত feedback বা অন্য PII সেখানে তুলবেন না; প্রয়োজন হলে সীমিত audience-এর জন্য আলাদা Space তৈরি করুন। Denied account দিয়ে sensitive phrase retrieval test চালান। উত্তর, citation বা summary-তে restricted content ফিরলে document সরিয়ে পুনরায় index না করা পর্যন্ত rollout বন্ধ রাখুন।
Outbound action-এর আগে approval, secret-এর জন্য আলাদা store
Email, messaging service, ticketing system বা অন্য বাহ্যিক গন্তব্যে তথ্য পাঠানো Flow-এ send বা invoke ধাপের আগে human approval রাখুন। Approver-এর কাছে recipient, প্রকাশযোগ্য payload এবং action-এর উদ্দেশ্য দেখান। অনুমোদন না পাওয়া, rejection বা timeout—প্রতিটি অবস্থায় outbound action বন্ধ থাকে কি না test করুন।
Connector credential বা API secret Flow definition, prompt, uploaded document কিংবা dataset-এ রাখবেন না; AWS Secrets Manager-এর মতো আলাদা secret store ব্যবহার করে Flow-কে প্রয়োজনীয় secret-এর ন্যূনতম read permission দিন। Negative test হিসেবে approval ছাড়া outbound action চালানো এবং prompt দিয়ে secret-এর value বা location চাওয়া—দুটিই ব্যর্থ হতে হবে। Credential output বা execution log-এ এলে Flow disable, credential rotate এবং exposure review সম্পন্ন না হওয়া পর্যন্ত rollback বজায় রাখুন।
CloudTrail-এ যে প্রমাণ দরকার, সেটিই খুঁজুন
Amazon Quick-এর CloudTrail নির্দেশিকা অনুযায়ী supported API ও documented non-API activity event হিসেবে ধরা হয়; continuous delivery-এর জন্য trail দরকার। Flow, FlowSession ও ActionConnector-এর data event default-এ বন্ধ, তাই supported resource type যাচাই করে advanced event selector দিয়ে সেগুলো চালু করুন। Availability account ও Region অনুযায়ী বদলাতে পারে।
Acceptance test-এ agent update, group membership change, dataset permission change, একটি approved Flow run এবং একটি rejected run তৈরি করুন। Actor identity, event time, Region, event name ও target resource দিয়ে সংশ্লিষ্ট record খুঁজুন; approved run-এর outbound invocation থাকার এবং rejected run-এ invocation না থাকার প্রমাণ মিলিয়ে দেখুন। তবে CloudTrail-এর InvokeAction event recipient, message body বা approval decision ধরে না—এসব প্রমাণের জন্য Flow run record ও প্রযোজ্য CloudWatch log আলাদাভাবে সংরক্ষণ করুন। Expected event না এলে, actor অস্পষ্ট থাকলে বা retention owner নির্ধারিত না হলে sign-off দেবেন না।
তিন পর্যায়ের rollout checklist
Pilot: ছোট audience হলেও production-এর একই boundary ব্যবহার করুন। একটি audience-specific dataset, RLS, দুটি বিপরীত test identity এবং adversarial query set ছাড়া pilot পাস নয়। Sensitive column ফিরে এলে agent unpublish করুন, sharing বন্ধ করুন এবং শেষ অনুমোদিত dataset version-এ ফিরুন।
Departmental rollout: প্রতিটি department-এর group owner, dataset owner ও Space content owner নির্ধারণ করুন। নতুন department যোগ করার আগে cross-department row test, excluded-column test, document retrieval test এবং approval-bypass test পুনরায় চালান। Agent-এর scope, dataset বা Space membership বদলালে আগের acceptance result আর বৈধ নয়।
Enterprise scale: dataset, agent, Space ও Flow inventory-তে owner, reviewer, audience, last review ও expiry রাখুন। এই পর্যায়ে agent registry-র owner ও expiry operational control হিসেবে কাজে লাগে। নির্ধারিত review cadence, audit alert, credential rotation এবং break-glass rollback owner ছাড়া নতুন asset চালু করবেন না।
Production-এর চূড়ান্ত সিদ্ধান্ত prompt নিষেধ মানছে কি না দিয়ে নয়, নিষিদ্ধ data agent-এর নাগালের বাইরে আছে কি না দিয়ে নিন। দুই পরিচয়ের negative test, document boundary, approval gate ও audit evidence—চারটির যেকোনো একটি ব্যর্থ হলে rollout স্থগিত রেখে boundary ঠিক করুন।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।