এন্টারপ্রাইজ AI access controls কীভাবে কাজ করা উচিত?

একটি এন্টারপ্রাইজ AI development workspace-এ প্রতিটি তৈরি হওয়া পরিবর্তনকে নির্দিষ্ট মানব পরিচয়ের অধীনে, নির্ধারিত role দিয়ে এবং নির্দিষ্ট environment-এর বিরুদ্ধে করা কাজ হিসেবে দেখতে হবে। প্ল্যাটফর্মটি যদি source পড়তে, বাহ্যিক service call করতে, infrastructure তৈরি করতে, application deploy করতে, snapshot restore করতে বা code export করতে পারে, তবে তার access model কোনো চতুর editor নয়, একটি production system নিয়ন্ত্রণ করে।

Procurement-এ সবচেয়ে বেশি যে ভুলটি দেখি, তা হলো feature sheet-এ SAML, SCIM ও RBAC লেখা আছে কি না দেখে নেওয়া। উপস্থিতি enforcement সম্পর্কে খুব কমই বলে। কোনো vendor SAML assertion গ্রহণ করেও password login খোলা রাখতে পারে, SCIM suspension প্রক্রিয়া করেও সক্রিয় session রেখে দিতে পারে, আর RBAC-এর বিজ্ঞাপন দিয়েও প্রতিটি builder-কে deploy-এর অনুমতি দিতে পারে। ক্রেতাদের identity provider থেকে শেষ side effect পর্যন্ত পুরো শৃঙ্খল পরীক্ষা করতে হবে।

Authentication, lifecycle management, authorization, approval, credential handling, environment isolation এবং audit evidence ভিন্ন সমস্যা সমাধান করে। অস্পষ্ট security শিরোনামের নিচে সবকিছু এক করলে controls-এর মধ্যের ফাঁক ঢাকা পড়ে। সেই ফাঁকেই সাবেক কর্মীরা session ধরে রাখে, development agents production credentials-এ পৌঁছে যায় এবং অনুমোদিত পরিবর্তন release-এর আগে বদলে যায়।

SAML-এর সমান্তরাল দরজা বন্ধ করা উচিত

SAML SSO-তে enterprise identity provider-ই workspace-এ প্রবেশের স্বাভাবিক ও বাধ্যতামূলক পথ হওয়া উচিত, vendor password form-এর পাশে ঐচ্ছিক button নয়। কোনো corporate domain দাবি করলে সেই domain-এ unmanaged identity তৈরি করে এমন self registration, password recovery এবং invitation বন্ধ হওয়া উচিত।

OASIS SAML 2.0 specifications authentication ও attributes সম্পর্কিত assertions নির্ধারণ করে। কেউ প্রতিষ্ঠান ছাড়লে সেগুলো vendor account নিষ্ক্রিয় করে না এবং প্রমাণীকৃত engineer production-এ deploy করতে পারবে কি না তাও ঠিক করে না। এই সীমানাটি গুরুত্বপূর্ণ, কারণ procurement questionnaire প্রায়ই SAML-কে কেন্দ্রীভূত access control-এর প্রমাণ ধরে নেয়, যেখানে এটি authentication-এর কেবল একটি অংশ প্রমাণ করে।

একটি শক্ত বাস্তবায়ন assertion signature, issuer, audience, recipient, time conditions এবং request correlation যাচাই করে। outage ছাড়াই certificate rollover সমর্থন করে এবং immutable identifier দিয়ে users map করে। Email ভালো primary identifier নয়, কারণ address বদলায়, পুনর্ব্যবহৃত হয় এবং কখনো শুধু formatting-এ ভিন্ন হয়। কোন SAML attribute স্থায়ী account identity হবে এবং attribute বদলালে কী হবে, তা জিজ্ঞেস করুন।

Administrators-কে session duration, inactivity limits এবং sensitive actions-এর জন্য reauthentication কনফিগার করতে দিন। policy যদি multifactor authentication-এর ওপর নির্ভর করে, workspace-কে identity provider-এর authentication context মানতে হবে। identity provider যে কোনো assertion ইস্যু করলেই SAML স্বয়ংক্রিয়ভাবে strong authentication দেয়, এমন দাবি করা উচিত নয়।

Local emergency access-এর জন্য সীমিত ব্যতিক্রম দরকার। identity provider outage যেন প্রতিটি administrator-কে lock out না করে, সে জন্য সাধারণ SSO path-এর বাইরে এক বা একাধিক break glass identity রাখুন। শক্তিশালী authentication, পৃথক custody, তাৎক্ষণিক alerts ও নথিবদ্ধ test schedule দিয়ে সেগুলো সুরক্ষিত করুন। সাধারণ administrators সুবিধার জন্য এই accounts ব্যবহার করবেন না।

শুধু login button নয়, bypass-গুলো পরীক্ষা করুন। পুরোনো invitation খুলুন, password reset চান, user's email বদলান, user-কে অনুমোদিত identity provider group থেকে সরান এবং ভুল tenant-এ identity provider initiated login চেষ্টা করুন। workspace কীভাবে guest domains, অধিগ্রহণ করা company domains এবং একাধিক identity providers সামলায় তা যাচাই করুন। vendor যদি অস্পষ্ট কথা ছাড়া account linking ব্যাখ্যা করতে না পারে, duplicate identities দেখা দেবে ধরে নিন।

Session termination-এর নিজস্ব acceptance criterion প্রাপ্য। identity provider-এ কাউকে disable করলে পরের login বন্ধ হতে পারে, কিন্তু বিদ্যমান browser session, command line token বা agent job ঘণ্টার পর ঘণ্টা চলতে পারে। administrator কি একটি identity-এর সব sessions revoke করতে পারেন এবং SCIM suspension স্বয়ংক্রিয়ভাবে তা চালায় কি না, জিজ্ঞেস করুন।

SCIM যেন মানুষের স্মৃতির ওপর নির্ভর না করে accounts বন্ধ করে

Identity source কোনো user-কে suspend করলে SCIM-এর কাজ হলো interactive sessions, API credentials, queued work এবং agent executions জুড়ে দ্রুত কার্যকর access সরিয়ে দেওয়া। শুধু account field-কে inactive করলেই offboarding সম্পূর্ণ হয় না।

RFC 7643 মূল User ও Group resource schemas নির্ধারণ করে, আর RFC 7644 এসব resources তৈরি, query, modify ও delete করার protocol operations নির্ধারণ করে। Standards vendors-কে সাধারণ exchange দেয়, কিন্তু deactivation-এর প্রতিটি স্থানীয় ফল ঠিক করে না। পরিবর্তন পাওয়ার পর workspace আসলে কী করে, তা ক্রেতাদের জানতে হবে।

First login-এর আগে provisioning-এর মাধ্যমে সঠিক organization ও baseline group membership-সহ account তৈরি হওয়া উচিত। Group updates পূর্বানুমেয়ভাবে workspace roles যোগ ও সরাবে। Suspension নতুন sessions প্রত্যাখ্যান করবে, বিদ্যমান sessions ও personal tokens revoke করবে, scheduled work বন্ধ বা পুনরায় বরাদ্দ করবে এবং suspended identity দিয়ে pending approvals কার্যকর হওয়া ঠেকাবে। Deletion গ্রাহকের retention policy মেনে হবে, কিন্তু audit attribution মুছে ফেলা যাবে না।

পরিচিত একটি ব্যর্থতার শুরু হয় release group-এ থাকা contractor দিয়ে। identity provider contractor-কে group থেকে সরিয়ে SCIM patch পাঠায়। workspace দৃশ্যমান role update করে, কিন্তু আগের browser session-এ release permission রয়ে যায়। অপসারণের আগে contractor যে deployment queue করেছিল, সেটিও পরে service credential দিয়ে চলে। প্রতিটি screen ঠিক দেখালেও কার্যকর access দুই জায়গায় জীবিত থাকে।

এই ব্যর্থতা directory state ও runtime authority-এর পার্থক্য দেখায়। SCIM directory state update করে। workspace-কে সেই পরিবর্তন sessions, tokens, jobs, approval assignments এবং cached authorization decisions-এ ছড়িয়ে দিতে হবে। Procurement-এর উচিত প্রত্যাশিত revocation interval নির্ধারণ করে তা মাপা, immediate বা automatic-এর মতো শব্দ মেনে না নেওয়া।

Group reconciliation-ও পরীক্ষা দরকার। user-কে একটি group থেকে সরিয়ে অন্যটিতে রাখুন, suspend ও reactivate করুন, group-এর নাম বদলান এবং production access দেওয়া group delete করুন। Reactivation-এর ফলে user যে group আর ধরে না, সেখান থেকে আসা privileges ফিরে আসা উচিত নয়। Manual role grants আলাদা করে দৃশ্যমান হওয়া দরকার, কারণ সেগুলো group cleanup-এর পরও টিকে থাকতে পারে।

SCIM connector-টিও পরীক্ষা করুন। তার bearer token-এ শুধু provisioning permissions থাকা উচিত, rotation সমর্থন করা উচিত এবং configuration ও ব্যবহারের জন্য audit events তৈরি করা উচিত। Service provider-এর দরকারি error responses দেখানো এবং নিরাপদ retries সহ্য করা উচিত। নীরবে group changes বাদ দেওয়া connector identity team-কে বিনা পারিশ্রমিকের monitoring software-এ পরিণত করে।

RBAC-এ actions-কে resources-এর সঙ্গে মেলাতে হবে

RBAC-এ প্রকাশ পাবে কোন identity কোন resource-এ কোন action, কোন environment-এ করতে পারে। বিস্তৃত viewer, member ও administrator label-এর একটি সেট software build ও release করা workspace-কে নিরাপদে পরিচালনা করতে পারে না।

Job title দিয়ে নয়, actions দিয়ে শুরু করুন। Permission catalog-এ project দেখা, instructions edit, agent চালানো, generated source পড়া, source export, snapshots manage, version restore, domain configure, deployment তৈরি, artifact promote, secret metadata পড়া, credentials বদলানো, audit records পড়া এবং organization policy বদলানো আলাদা হওয়া উচিত। Platform-ভেদে নাম বদলাতে পারে, কিন্তু বিভাজনটি হারানো যাবে না।

শুরুর জন্য কার্যকর একটি matrix এমন হতে পারে:

এই table অন্ধভাবে কপি করবেন না। স্পষ্ট সিদ্ধান্ত দরকার এমন সমন্বয়গুলো খুঁজতে এটি ব্যবহার করুন। কিছু organization approver ও operator এক করে, আর নিয়ন্ত্রিত দলগুলো আলাদা রাখে। বিপজ্জনক default হলো এমন generic administrator, যে পরিবর্তন তৈরি, অনুমোদন, credential যোগ, deploy এবং প্রমাণ মুছে ফেলতে পারে।

Roles-এর scope দরকার। একজন engineer এক workspace-এ build, অন্যটিতে review এবং তৃতীয়টিতে কোনো access-ই না পেতে পারেন। শুধু development access আছে বলে production permission স্বয়ংক্রিয়ভাবে পাওয়া উচিত নয়। Authorization engine-এ organization, workspace, project, environment ও resource scopes-এর documented inheritance সমর্থন করা উচিত। Parent scope-এর allow নিচের deny-কে অগ্রাহ্য করে কি না, নাকি উল্টোটি হয়, ক্রেতাদের তা জানা দরকার।

Vendor stable permissions প্রকাশ করে এবং effective access report করলে custom roles কাজে লাগে। সহজ একটি তদন্তের প্রশ্নের উত্তর দেয় এমন view বা export চান: এই identity কেন এই action করতে পারে? উত্তরে direct assignments, group-derived roles, inherited permissions, temporary grants ও policy conditions চিহ্নিত হওয়া উচিত। এই ব্যাখ্যা ছাড়া প্রথম reorganization-এর পর custom roles review করা কঠিন হয়ে যায়।

Human roles ও workload identities-ও আলাদা করে সামলাতে হবে। Deployment agent creator-এর পূর্ণ interactive role ধার নেবে না এবং service identity user interface-এ login করবে না। প্রতিটি workload-কে নামযুক্ত owner, purpose, environment, permission set, expiry বা review date এবং revocation path দিন।

Environments-এর বাস্তব security boundaries দরকার

Development, test এবং production-কে enforced permissions, credentials, runtime resources, data policy ও release paths দিয়ে আলাদা হতে হবে। Environment selector বা রঙিন label isolation তৈরি করে না।

প্রথম boundary হলো authorization। Development resources বদলাতে পারা builder একই inherited project role দিয়ে production access পাবে না। দ্বিতীয়টি credentials। Development agents-কে development database ও cloud permissions দিন, এমন organization credential নয় যা প্রতিটি environment-এ পৌঁছাতে পারে। তৃতীয়টি data: পৃথক process অনুমোদন ও সুরক্ষা না দিলে previews ও tests-এ production records কপি করা যাবে না।

Generated applications বাহ্যিক call বা infrastructure তৈরি করতে পারলে runtime separation গুরুত্বপূর্ণ। Environments কি পৃথক execution identities, network rules, storage locations ও deployment targets ব্যবহার করে, জিজ্ঞেস করুন। Shared worker একাধিক environment সামলালে platform কীভাবে একটি job-কে অন্য job-এর material পড়া থেকে আটকায় তা নির্ধারণ করুন। Logical separation-এর দাবি architecture slide নয়, control demonstration চায়।

Promotion-এ বিস্তৃত production permissions দিয়ে mutable source পুনর্নির্মাণ না করে reviewed artifact সরানো উচিত। Source revision, generated files, dependency lock state, test result, policy version ও artifact digest রেকর্ড করুন। Production যদি সর্বশেষ project state থেকে rebuild করে, approval-এর পরের পরিবর্তন review ছাড়া release-এ ঢুকে যেতে পারে।

Snapshots ও rollback-এও একই boundary দরকার। আগের application version restore করলে vulnerable code, পুরোনো configuration বা database-এর সঙ্গে আর না মেলা schema expectation-ও ফিরে আসতে পারে। Production rollback-কে authorization, evidence ও audit trail-সহ production action হিসেবে বিবেচনা করুন। সান্ত্বনাদায়ক rollback শব্দটি যেন release policy এড়িয়ে না যায়।

Data residency ও environment separation সম্পর্কিত হলেও আলাদা বিষয়। নির্বাচিত দেশে workloads চালানো storage বা transfer requirements মেটাতে পারে, কিন্তু development ও production পৃথক identities বা data ব্যবহার করে প্রমাণ করে না। একটি location claim যেন দুটি প্রশ্নের উত্তর না হয়ে যায়, সে জন্য procurement teams-এর উভয় requirement নথিবদ্ধ করা উচিত।

Vendor একটি organization-এর মধ্যে এই boundaries enforce করতে না পারলে separate tenants প্রয়োজন হতে পারে। এতে administration বাড়ে এবং promotion জটিল হতে পারে, কিন্তু project label-এ production authority আছে ভান করার চেয়ে এটি নিরাপদ।

Consequential edges-এ approval gates থাকা উচিত

Approval gates এমন actions সুরক্ষিত করবে যেগুলো বাস্তব ফল তৈরি করে এবং প্রতিটি approval একটি immutable proposal-এর সঙ্গে বাঁধা থাকবে। প্রতিটি agent message-এর জন্য approval চাইলে ক্লান্তি আসে, আবার অস্পষ্ট conversation অনুমোদন করলে reviewers খুব কম তথ্য পান।

ভালো candidate হলো production deployment, credential যোগ বা তার scope বাড়ানো, network exposure বদলানো, public domain configure করা, sensitive source বা data export, production snapshot restore, authorization policy পরিবর্তন এবং audit export বন্ধ করা। Development edits-এ protected data বা external systems না থাকলে সাধারণত একই gate দরকার হয় না।

Reviewer-এর সামনে নির্দিষ্ট packet থাকা দরকার: requested action, target environment, source ও artifact digest, file বা infrastructure diff, tests, policy findings, requested credential scopes, requester identity, agent identity এবং expiry time। Reviewer অনুমোদন দিলে কী হবে, interface-এ তা স্পষ্ট থাকা উচিত। Action boundary ছাড়া allow লেখা button approval control নয়।

Policy-টি এমন রূপে প্রকাশ করা যায়, যা buyer দেখতে ও পরীক্ষা করতে পারেন:

policy_version: 18
rules:
  - action: deploy
    environment: production
    require:
      approvals: 1
      approver_role: release_approver
      requester_cannot_approve: true
      artifact_digest_must_match: true
      expires_minutes: 30
  - action: credential_scope_change
    require:
      approvals: 1
      approver_role: credential_custodian
      scope_diff_required: true

এই fragment দুটি সাধারণ ব্যর্থতা ঠেকায়। Requester নিজের production deployment অনুমোদন করতে পারেন না, আর artifact change হলে digest আর না মেলায় approval অবৈধ হয়ে যায়। স্বল্প expiry পুরোনো সিদ্ধান্ত ব্যবহার করাও ঠেকায়, যখন আশপাশের operational context বদলে গেছে।

Approval state action-এর সঙ্গে থাকবে, chat thread বা user session-এর সঙ্গে নয়। Source edit, target বদল, permission বাড়ানো, credential বদলানো বা generation পুনরায় চালানোর ফলে approved proposal বদলালে নতুন সিদ্ধান্ত দরকার। ব্যর্থ deployment retry কেবল artifact ও operation অভিন্ন থাকলে এবং policy স্পষ্ট অনুমতি দিলেই approval পুনর্ব্যবহার করতে পারে।

Queued ও automated actions-এ একই enforcement দরকার। Approved window-তে agent যেন production change schedule করে window বন্ধ হওয়ার পরে অন্য version চালাতে না পারে। Execution service-কে execution time-এ authorization, approval validity, artifact identity ও credential scope আবার পরীক্ষা করতে হবে।

Planning mode reviewers-কে উদ্দেশ্যকৃত কাজ বুঝতে সাহায্য করতে পারে, কিন্তু plan authorization boundary নয়। Tool call বদলালে, integration অপ্রত্যাশিত data ফেরালে বা model তার পদ্ধতি বদলালে platform সঠিক plan তৈরি করেও অতিরিক্ত কাজ করতে পারে। যে operation effect ঘটায়, তার জায়গাতেই approval enforce করুন।

সত্যিকারের incident-এর জন্য emergency paths থাকতে হবে। Reason, সীমিত duration, সীমাবদ্ধ action set, তাৎক্ষণিক alert এবং ব্যবহারের পর review চাইুন। Emergency override নীরবে স্থায়ী administrator access দিলে ব্যতিক্রমটিই control-কে প্রতিস্থাপন করেছে।

মানুষ ভুলে যাওয়ার আগেই credentials-এর মেয়াদ শেষ হওয়া উচিত

Destination সমর্থন করলে workspace-এ সীমিত environment ও action scopes-সহ temporary workload credentials ব্যবহার করা উচিত। Chat, project settings বা build variables-এ রাখা স্থায়ী organization tokens অধিকাংশ কাজের চেয়ে agent-কে অনেক বেশি ক্ষমতা দেয়।

তিনটি ধারণা আলাদা রাখুন। Human session প্রমাণ করে কে workspace ব্যবহার করছে। Workload identity agent, build বা deployment process-কে শনাক্ত করে। Secret material ওই workload-কে বাহ্যিক system-এ পৌঁছানোর অনুমতি দেয়। তিনটির জন্য মানুষের বিস্তৃত token পুনর্ব্যবহার করলে attribution নষ্ট হয় এবং revocation বিঘ্নজনক হয়ে ওঠে।

Federation বা credential broker পছন্দ করুন, যা verified workload identity-র বদলে temporary token দেয়। Broker audience, role, environment ও duration সীমিত করতে পারে। Agent process কেবল অনুমোদিত tool চালানোর সময় token পাবে, model-এর context-এ secret value দেখা বা পুনরুৎপাদন করা উচিত নয়।

Secret storage একাই scope-এর সমাধান নয়। নিখুঁতভাবে encrypted cloud credential-ও প্রতিটি account জুড়ে deletion-এর অনুমতি দিতে পারে। শুধু vault নয়, destination permissions পর্যালোচনা করুন। প্রতিটি credential-এর owner, purpose, allowed environment, authorized workloads, creation source, rotation method এবং last use record থাকা উচিত।

Prompts, chat history, generated source, logs, snapshots, support bundles এবং exports সবই disclosure path হতে পারে। Persistence-এর আগে platform-এর detected secrets redact করা উচিত, তবে formats ভিন্ন হওয়ায় এবং encoded values এড়িয়ে যেতে পারায় detection একটি backup control। শক্তিশালী নকশায় secret material কখনো model input বা সাধারণ output channels-এ রাখা হয় না।

Source export-এর জন্য সচেতন নিয়ম দরকার। Export packages-এ secret values বাদ থাকবে এবং unresolved secret references চিহ্নিত থাকবে, যাতে গ্রহণকারী team কী configure করবে জানে। কার্যকর environment file-সহ export portability-কে credential distribution-এ বদলে দেয়।

কোনো বাস্তব privilege নেই এমন canary credential দিয়ে containment পরীক্ষা করুন। প্রতিটি supported input path-এ তার সহজে চেনা value দিন, agent চালান, snapshot তৈরি করুন, logs দেখুন ও project export করুন। এরপর প্রতিটি তৈরি হওয়া artifact ও audit stream-এ খুঁজুন। এই পরীক্ষা দেখায় vendor-এর secret boundary শুধু সরাসরি secret entry-তে নয়, সাধারণ product features-এও টিকে আছে কি না।

সম্পূর্ণ workspace rebuild ছাড়া rotation ও revocation কাজ করতে হবে। কোনো destination temporary credentials দিতে না পারলে system কীভাবে চলে, stored secrets কীভাবে rotate করে এবং jobs execution time-এ current version নেয় কি না, জিজ্ঞেস করুন। গতকালের credential ধরে রাখা job credential record updated দেখালেও চলতে পারে।

Outbound integrations-এর নিজস্ব consent model দরকার। Source repository, database, ticket system বা cloud account যোগ করার সময় requested scopes দেখাতে হবে এবং connection-কে workspace ও environment-এর সঙ্গে বাঁধতে হবে। Organization-wide connections ব্যতিক্রম হওয়া উচিত, কারণ একটি project-এ agent-এর ভুল যেন প্রতিটি repository বা account প্রকাশ না করে।

Export করা audit logs-এ intent ও effect পুনর্গঠন করা উচিত

Audit logs দিয়ে তদন্তকারী যেন vendor-এর user interface-এর ওপর নির্ভর না করে মানব request-কে authorization, agent execution, credential use এবং ফলের পরিবর্তনের সঙ্গে যুক্ত করতে পারেন। Exportability বলতে শুধু administrators-এর manual download নয়, customer-controlled storage বা monitoring-এ যাওয়ার documented, continuous path বোঝায়।

NIST SP 800-53, AU-12-এ audit event generation-কে AU-9-এর audit information protection থেকে আলাদা করেছে। এখানে এই বিভাজনটি উপকারী। কোনো deployment record করাই যথেষ্ট নয়, যদি workspace administrator একমাত্র copy বদলে বা মুছে ফেলতে পারেন। সীমিত write access ও customer-controlled retention-সহ events workspace-এর বাইরে পাঠান।

প্রতিটি event-এ stable identifier, timestamp, tenant, human actor, workload বা agent identity, action, target resource, environment, authorization decision, role বা policy basis, approval reference, credential reference, result এবং correlation identifier থাকা দরকার। Change events-এ diff, নিরাপদ before ও after values অথবা stored artifacts-এর সঙ্গে event-কে বাঁধা hashes অন্তর্ভুক্ত করুন।

একটি deployment event এমন হতে পারে:

{
  "event_id": "evt_01J...",
  "occurred_at": "2026-07-27T14:03:22Z",
  "actor": {"type": "user", "id": "usr_1842"},
  "workload": {"type": "release_agent", "id": "agt_77"},
  "action": "deployment.create",
  "target": {"environment": "production", "application": "app_91"},
  "authorization": {
    "decision": "allow",
    "policy_version": 18,
    "approval_id": "apr_552"
  },
  "artifact_digest": "sha256:8b1c...",
  "credential_ref": "cred_cloud_prod_4",
  "request_id": "req_9031",
  "result": "success"
}

Event-এ secret values নয়, references প্রকাশ পায়। এতে human ও executing workload দুটিরই নাম থাকে, ফলে শুধু agent deployed বলার মতো অনুপকারী record এড়ানো যায়। Request identifier-কে সম্পর্কিত model runs, tool calls, policy decisions এবং destination responses যুক্ত করা উচিত।

Audit ও observability আলাদা। Operational traces engineers-কে latency, model calls ও failures debug করতে সাহায্য করে। Audit records বলে কে কী করার অনুমতি পেয়েছিল এবং কী বদলেছে। Vendors কখনো সমৃদ্ধ traces দিলেও role changes, secret administration, support access, export actions বা failed authorization attempts বাদ দেয়।

Prompt content সংরক্ষণে সংযম দরকার। Full prompts-এ source code, personal data বা secrets থাকতে পারে, তাই প্রতিটি conversation security log-এ রাখলে আরেকটি sensitive repository তৈরি হয়। Stable hashes, redacted summaries, আলাদাভাবে governed content-এর references এবং উৎপন্ন concrete operations রেকর্ড করুন। Customer-কে retention ও redaction-এর নিয়ন্ত্রণ দিন, কিন্তু acting model-কে কখনোই কোন security events অদৃশ্য হবে তা ঠিক করতে দেবেন না।

Ordering, clock consistency, delivery delay, retries, duplicate handling, schema changes এবং outage-এর সময়কার আচরণ পরীক্ষা করুন। Export-এ versioning নথিবদ্ধ থাকা এবং recovery-এর জন্য cursor বা event identifier থাকা উচিত। Customer receiver unavailable হলে vendor-কে ঘোষিত সীমা অনুযায়ী events buffer করতে হবে এবং delivery পিছিয়ে পড়লে জানাতে হবে।

Support access একই stream-এ থাকা উচিত। Vendor personnel কখন tenant access করে, কোন authorization তা অনুমতি দেয়, তারা কী দেখেছে বা বদলেছে এবং access কখন শেষ হয়েছে তা রেকর্ড করুন। Customers export করতে পারে না এমন অভ্যন্তরীণ vendor log কোনো enterprise investigation-এর উত্তর দেয় না।

Procurement tests-এর লক্ষ্য হওয়া উচিত control plane

Procurement-এর উচিত isolated evaluation tenant-এ live tests চাওয়া এবং দেখা enforcement-কে acceptance evidence হিসেবে ধরা। Presentation architecture বোঝাতে পারে, কিন্তু suspended user-এর cached deployment token হারিয়েছে কি না প্রমাণ করতে পারে না।

একটি identity provider, SCIM client, কয়েকটি test identity, দুটি environment, harmless external credential এবং audit receiver প্রস্তুত করুন। Session-এর আগে vendor-কে প্রত্যাশিত outcomes দিন, যাতে exercise-টি presenter-এর তাৎক্ষণিক উদ্ভাবন নয়, product মাপে।

1. প্রতিটি identity bypass চেষ্টা করুন: local password, invitation, password recovery, duplicate email, ভুল identity provider এবং suspension-এর পরের পুরোনো session।
2. Browser sessions, personal tokens, pending approvals, scheduled jobs ও agent runs সক্রিয় থাকা অবস্থায় group membership বদলান এবং privileged user suspend করুন।
3. Inherited roles, custom roles, service identities, source export, snapshot restore এবং development থেকে production-এ যাওয়া দিয়ে privilege escalation চেষ্টা করুন।
4. একটি artifact অনুমোদন করুন, তার source বা target বদলান, তারপর পুরোনো approval ও আরও বিস্তৃত credential দিয়ে deployment চেষ্টা করুন।
5. সব events export করে কে change request, approve, execute ও পেয়েছে তা পুনর্গঠন করুন, denied attempts ও vendor support access-সহ।

প্রতিটি ফলের raw evidence রাখুন: sensitive values বাদ দেওয়া SAML response details, SCIM requests ও responses, effective permission exports, approval identifiers, artifact digests, credential metadata, audit events এবং timestamps। Screenshots finding ব্যাখ্যায় সাহায্য করে, কিন্তু vendor control বদলালে machine-readable output তুলনা করা সহজ।

চারটি result state ব্যবহার করুন: pass, fail, partial এবং promised। Partial মানে control কেবল কিছু access paths, resources বা plans-এ কাজ করে। Promised মানে vendor ভবিষ্যতের আচরণ বর্ণনা করেছে। Account team roadmap date দিলেও কোনো অবস্থাকে pass-এ বদলাবেন না।

Configuration বদলানোর পর vendor-কে failed test আবার করতে বলুন। এতে অনুপস্থিত product control ও খারাপ default-এর পার্থক্য বোঝা যায় এবং administrators setting-টি খুঁজে পান কি না দেখা যায়। নথিবিহীন support work-এর আড়ালে থাকা security feature বাস্তব rollout-এ আবার ব্যর্থ হবে।

Test plan ও pricing boundaries একসঙ্গে পরীক্ষা করুন। SSO এক tier-এ, SCIM অন্যটিতে এবং audit export-এর আলাদা retention বা delivery limits থাকতে পারে। Procurement-এর দরকার policy-প্রয়োজনীয় সমন্বয়, আলাদা আলাদা পাওয়া যায় এমন features-এর সংগ্রহ নয়। প্রতিটি acceptance criterion-এর পাশে plan eligibility ও usage limits লিখুন।

Administrative recovery-ও পরিদর্শন করুন। শেষ organization administrator-কে সরান, SAML configuration ভাঙুন, ভুলভাবে SCIM token rotate করুন এবং audit receiver বন্ধ করুন। অদৃশ্য vendor bypass তৈরি না করে workspace-এর নিয়ন্ত্রিত recovery দেওয়া উচিত। Recovery actions-এ system-এর সবচেয়ে শক্ত audit evidence তৈরি হওয়া উচিত।

Koder.ai মূল্যায়নের সময় এর chat-based creation flow, source export, deployment ও hosting, custom domains, snapshots, rollback এবং planning mode-এর ওপর এই tests চাইুন। এগুলো আছে বলেই access control আছে ধরে নেবেন না।

Contract ও rollout-এ control বজায় রাখতে হবে

পরিপাটি evaluation tenant তুলে নেওয়ার পরও contract ও operating process-এ পরীক্ষিত controls বজায় থাকতে হবে। প্রয়োজনীয় features, প্রযোজ্য plans, retention periods, delivery limits, data locations, support access rules, export formats, incompatible schema changes-এর notice এবং প্রয়োজনীয় control কাজ না করলে প্রতিকার নথিবদ্ধ করুন।

Security documentation-এ প্রতিটি action-এর দায়িত্ব কার তা চিহ্নিত থাকা উচিত। Customer সাধারণত identity provider groups, role assignments, approval policy, credential scopes, log destinations ও retention কনফিগার করে। Vendor-এর দায়িত্ব enforcement, platform administrator controls, event generation, service isolation ও support access records। অস্পষ্ট দায়িত্ব incidents-এর সময় অনুমেয় ফাঁক তৈরি করে।

Authorization semantics বদলায় এমন পরিবর্তনে notice ও review চাইুন। নতুন agent tool, deployment target, integration type বা administrator permission কোনো customer assignment না বদলিয়েও existing roles বিস্তৃত করতে পারে। Vendor-এর নতুন permissions নথিবদ্ধ করা এবং নীরবে সেগুলো broad custom roles-এ না রাখা উচিত।

Nonproduction identities, policies, credential exchange, approvals ও audit delivery ব্যর্থতার মধ্যেও ঠিকভাবে চলার পরই production rollout করুন। পরীক্ষিত policy version freeze করুন, permission matrix ধরে রাখুন এবং access reviews ও emergency accounts-এর owners নির্ধারণ করুন। সবার জন্য এক calendar মেনে না নিয়ে organization-এর risk ও staff turnover অনুযায়ী review intervals ঠিক করুন।

Access reviews-এ effective permissions, inactive accounts, groups এড়িয়ে যাওয়া direct grants, unused workload identities, stale credentials, emergency access, failed audit delivery এবং support activity দেখা উচিত। কোনো grant-এর এখনো owner ও purpose আছে, এমন evidence reviewers-এর দরকার। Resource scope ছাড়া role names-এর spreadsheet সেই প্রশ্নের উত্তর দেয় না।

একটি acceptance condition অচল রাখুন: identity source কোনো privileged user-কে suspend করলে production-এ যাওয়ার প্রতিটি ব্যবহারযোগ্য পথ সম্মত interval-এর মধ্যে বন্ধ হবে এবং exported events তা প্রমাণ করবে। Workspace এই পরীক্ষায় উত্তীর্ণ না হলে control sheet-এর বাকি অংশ শুধু সাজসজ্জা।