ব্রাউজার প্রোফাইলে ন্যূনতম-অধিকার অটোমেশন

অ্যাক্সেস-অনুমোদনের সীমা দিয়ে শুরু করুন

NIST-এর সংজ্ঞা অনুযায়ী ন্যূনতম অধিকার মানে হলো ব্যবহারকারী এবং তার হয়ে কাজ করা প্রক্রিয়াকে নির্দিষ্ট কাজের জন্য যতটুকু অ্যাক্সেস দরকার, ততটুকুতেই সীমাবদ্ধ রাখা। তাই ব্রাউজার-প্রোফাইলের কাজে automation-এর মতো একটিমাত্র ভূমিকা খুব বিস্তৃত। এতে কে অনুরোধ করছে তা বোঝা যায়, কিন্তু কোন প্রোফাইল খোলা যাবে, কোন ওয়েবসাইটে যাওয়া যাবে, কী বদলানো যাবে বা অনুমতি কতক্ষণ থাকবে—তা বোঝা যায় না।

একটি কার্যকর অ্যাক্সেস-অনুমোদনের সীমায় আটটি দিক থাকে:

দিক	যে প্রশ্নের উত্তর দিতে হবে	নিরাপদ প্রাথমিক নিয়ম
কর্তা	কোন ব্যক্তি, ওয়ার্কলোড বা এজেন্ট কাজটি শুরু করেছে?	প্রতিটি ব্যক্তি বা ওয়ার্কলোডের জন্য আলাদা, শনাক্তযোগ্য পরিচয়
টেন্যান্ট	কোন সংস্থা বা ক্লায়েন্টের সীমা প্রযোজ্য?	একটি সংস্থা; টেন্যান্ট বদলে অন্য সংস্থায় অ্যাক্সেস নয়
প্রোফাইলসমষ্টি	ঠিক কোন প্রোফাইল ব্যবহার করা যাবে?	নির্দিষ্ট ID অথবা পর্যালোচিত ফোল্ডার/ট্যাগ নির্বাচক
কার্যক্রম	অটোমেশন কী করতে পারবে?	ফাইল-সিস্টেম বা প্রক্রিয়ার মৌলিক কমান্ড নয়, নাম-দেওয়া ডোমেইন-অ্যাকশন
গন্তব্য	কোন সাইট, API বা পরিবেশে যোগাযোগ করা যাবে?	কেবল অনুমোদিত উৎস ও পরিবেশ
সময়	অধিকার কখন শুরু হবে এবং কখন শেষ হবে?	স্বল্পমেয়াদি ক্রেডেনশিয়াল ও নির্দিষ্ট সময়সীমার কাজ
হার	কতটা কাজ করা যাবে?	একসঙ্গে চলা, অনুরোধ ও খরচের সীমা
পার্শ্বপ্রভাব	কী বদলানো, প্রকাশ, মুছে ফেলা বা কেনা যাবে?	আগে শুধু-পড়া; বেশি প্রভাবের কাজে আলাদা সম্মতি

প্রতিটি কমান্ডের জন্য নীতিগত সিদ্ধান্ত যাচাই করুন। প্রোফাইল চালু করা সফল হলেই যেন কুকি রপ্তানি, দল পরিচালনা, বিলিং বদলানো বা ব্রাউজার যে কোনো সাইটে কাজ করার অধিকার নীরবে না মেলে।

তিন ধরনের অধিকার আলাদা রাখুন

ব্রাউজার অটোমেশন প্রায়ই তিন ধরনের আলাদা ক্রেডেনশিয়ালকে একই ওয়ার্কফ্লোতে মিশিয়ে ফেলে:

1. অটোমেশন ক্রেডেনশিয়াল প্রোফাইল ম্যানেজার বা অটোমেশন সেবায় করা কলের অনুমতি দেয়।
2. প্রোফাইলের সেশন-অবস্থা কোনো ব্যক্তি বা পরীক্ষার অ্যাকাউন্টকে ওয়েবসাইটে প্রমাণীকৃত করতে পারে।
3. লক্ষ্য সেবার অর্পিত অধিকার ওই অ্যাকাউন্ট ওয়েবসাইটে কী করতে পারবে তা নির্ধারণ করে।

এই ক্রেডেনশিয়ালগুলো একে অপরের বিকল্প নয়। অটোমেশন টোকেনে প্রোফাইলের কুকি থাকা বা সেগুলো প্রকাশ পাওয়া উচিত নয়। কোনো প্রোফাইল প্রমাণীকৃত আছে—এতে প্রমাণ হয় না যে অনুরোধকারী ওয়েবসাইটের সব উপলভ্য কাজ করার অধিকারও রাখে। ওয়েবসাইটের পাসওয়ার্ড বা OAuth টোকেনকে প্রোফাইল-ম্যানেজারের ক্রেডেনশিয়াল হিসেবে পুনর্ব্যবহার করবেন না।

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

দূরবর্তী ব্রাউজার নিয়ন্ত্রণেও একই সতর্কতা প্রযোজ্য। Chrome 136 থেকে ডিফল্ট ডেটা ডিরেক্টরির ওপর দূরবর্তী-ডিবাগিং সুইচ আর কার্যকর হয় না; বাস্তব প্রোফাইল থেকে ডিবাগিং আলাদা রাখতে কাস্টম ইউজার-ডেটা ডিরেক্টরি ব্যবহার করার পরামর্শ দেওয়া হয়েছে। Google তাদের 17 March 2025-এর নিরাপত্তা বিজ্ঞপ্তিতে পরিবর্তনের একটি কারণ হিসেবে দূরবর্তী ডিবাগিং দিয়ে কুকি উদ্ধারের কথা বলেছে। সহজ পথ হিসেবে কারও প্রতিদিনের ব্রাউজার-প্রোফাইলে অটোমেশন জুড়ে দেবেন না।

অনুমতি দেওয়ার আগে কাজের শ্রেণি নির্ধারণ করুন

নিয়ন্ত্রণ-ব্যবস্থায় একটি অবাধ ব্রাউজার-সংযোগ খুলে না দিয়ে ব্যবসায়িক কাজ এবং তার ঝুঁকি স্পষ্টভাবে প্রকাশ করা উচিত।

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

ঝুঁকি প্রেক্ষাপটের ওপর নির্ভর করে। একবার ব্যবহারযোগ্য স্টেজিং অ্যাকাউন্টে ফর্ম জমা দেওয়া নিয়মিত পরীক্ষা হতে পারে; প্রোডাকশন অ্যাকাউন্টে একই কাজ আইনগত, আর্থিক বা সুনামগত ফল আনতে পারে। সিদ্ধান্তটি পরিবেশ, অ্যাকাউন্ট এবং ঠিক যে পরিবর্তন প্রস্তাব করা হয়েছে তার সঙ্গে বাঁধুন।

সংকীর্ণ ও স্বল্পমেয়াদি ক্রেডেনশিয়াল দিন

প্রতিটি ওয়ার্কলোডের জন্য আলাদা সেবা-পরিচয় ব্যবহার করুন। নিরবচ্ছিন্ন ইন্টিগ্রেশন (CI), স্থানীয় স্ক্রিপ্ট বা এজেন্টকে মানুষের প্রশাসক-সেশন ধার দেবেন না। একটি কার্যকর টোকেনের পরিসর সীমিত থাকবে:

• সংস্থা এবং প্রয়োজন হলে ক্লায়েন্ট বা ওয়ার্কস্পেস;
• প্রোফাইল ID, ফোল্ডার, ট্যাগ বা অন্য স্থিতিশীল রিসোর্স-নির্বাচক;
• অনুমোদিত কার্যক্রম;
• উদ্দেশ্যপ্রাপ্ত সেবা বা অডিয়েন্স;
• জারির সময়, মেয়াদ শেষ হওয়া এবং প্রত্যাহারের অবস্থা;
• প্ল্যাটফর্ম সমর্থন করলে ডিভাইস বা ওয়ার্কলোডের পরিচয়; এবং
• একসঙ্গে চলা কাজ, অনুরোধের হার ও খরচের সর্বোচ্চ সীমা।

RFC 9700 অ্যাক্সেস-টোকেনের অধিকার প্রয়োজনীয় ন্যূনতমে সীমিত করার পরামর্শ দেয়; এর মধ্যে উদ্দেশ্যপ্রাপ্ত রিসোর্স সার্ভার, রিসোর্স এবং কাজও আছে। ফাঁস হওয়া টোকেনকে নির্দিষ্ট অডিয়েন্সে সীমিত রাখলে তার ক্ষতি কেন কমে, নির্দেশনাটিতে সেটিও ব্যাখ্যা করা হয়েছে। বর্তমান Model Context Protocol (MCP) অনুমোদন-বিষয়ক স্পেসিফিকেশন একইভাবে অডিয়েন্স যাচাই চায় এবং ক্লায়েন্টকে নির্ধারিত কাজের জন্য যতটুকু পরিসর দরকার, ততটুকুই চাইতে বলে।

ধাপে ধাপে অ্যাক্সেস দিন। কাজের শুরুতে অনুসন্ধান ও প্রিভিউ দেখার অধিকার রাখুন। পরের কোনো ধাপে বেশি ক্ষমতার দরকার হলে শুধু সেই ধাপের জন্য নতুন, স্বল্পমেয়াদি অনুমতি নিন। ওয়ার্কফ্লোর একটি শাখায় পরে কখনও দরকার হতে পারে—এই আশঙ্কায় স্থায়ী সর্বমুখী টোকেন দেবেন না।

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

সম্মতি নির্দিষ্ট ও যাচাইযোগ্য করুন

একটি সম্মতির উত্তর হওয়া উচিত: ‘কিসে সম্মতি দেওয়া হচ্ছে?’ ‘এই এজেন্টকে অনুমতি দিন’ ধরনের সাধারণ নিশ্চিতকরণ পর্যালোচক যতটা বুঝেছেন, তার চেয়ে বেশি ক্ষমতা দিতে পারে।

উচ্চ-প্রভাবের কমান্ডের প্রিভিউতে রাখুন:

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

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

কারও সম্মতি পেলেই সিস্টেমে প্রয়োজনীয় অ্যাক্সেস অধিকার তৈরি হয় না। সংগঠনের হাতে নেই এমন অধিকার কোনো পর্যালোচক দিতে পারেন না, আর একটি প্রম্পট নিষিদ্ধ ওয়ার্কফ্লোকে গ্রহণযোগ্য করে না।

নিরাপদ ব্যর্থতার জন্য কার্যসম্পাদন নকশা করুন

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

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

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

গোপন তথ্য না লিখে সিদ্ধান্ত নথিবদ্ধ করুন

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

প্রতিটি অটোমেশন-সিদ্ধান্তের জন্য লিখুন:

• মানুষ, সেবা এবং অর্পিত কর্তার পরিচয়;
• সংস্থা ও গোপন অংশ বাদ দেওয়া প্রোফাইল-রেফারেন্স;
• কমান্ডের নাম, অনুরোধের ID এবং প্রযোজ্য হলে একই অনুরোধ পুনরাবৃত্তি নিয়ন্ত্রণের idempotency key;
• নীতির সংস্করণ, সিদ্ধান্ত এবং কারণ-কোড;
• অনুমোদিত কাজের জন্য সম্মতির রেফারেন্স ও সম্মতিদাতার পরিচয়;
• গোপন অংশ বাদ দেওয়া গন্তব্য এবং রিসোর্সের সংখ্যা;
• শুরুর সময়, শেষ হওয়ার সময় এবং ফলাফল;
• ব্রাউজার, ক্লায়েন্ট ও অটোমেশন-অ্যাডাপ্টারের সংস্করণ; এবং
• পুনরুদ্ধার, বাতিল বা মানুষের পর্যালোচনার অবস্থা।

কুকির মান, পাসওয়ার্ড, অ্যাক্সেস বা পুনর্নবীকরণ টোকেন, অনুমোদন-হেডার, প্রক্সি-ক্রেডেনশিয়াল, এনক্রিপশন-কী, সম্পূর্ণ পৃষ্ঠার কনটেন্ট, ফর্মের মান বা কাঁচা প্রোফাইল-আর্কাইভ নথিবদ্ধ করবেন না। URL কম রাখুন, কারণ পথ ও query string-এ ব্যক্তিগত তথ্য বা গোপন তথ্য থাকতে পারে। অডিটে প্রবেশাধিকার সুরক্ষিত করুন, সংরক্ষণকাল নির্ধারণ করুন এবং লগ ধীর, পূর্ণ বা অপ্রাপ্য হলে কী হবে—তা পরীক্ষা করুন।

একটি নির্দিষ্ট নীতির উদাহরণ

নিচের ছদ্মকোডটি নকশার উদাহরণ, Isoline-এর কনফিগারেশন নয়। এটি CI ওয়ার্কলোডকে স্টেজিং প্রোফাইলে আঞ্চলিক স্মোক পরীক্ষা চালাতে এবং অন্য কিছু না করতে অনুমতি দেয়:

principal: "workload:regional-smoke-tests"
tenant: "org:example-studio"
profiles:
  selector: "tag == qa-staging"
operations:
  allow:
    - "profile.read"
    - "profile.launch"
    - "test.run-approved-suite"
    - "profile.stop"
  deny:
    - "profile.export-session-state"
    - "profile.delete"
    - "team.manage"
destinations:
  allow:
    - "https://staging.example.test"
conditions:
  expiresAt: "2026-08-26T18:00:00Z"
  maxConcurrentProfiles: 2
  maxRuns: 20
  requireCleanStop: true
approvals:
  "staging-data.reset": "single-use-human-approval"
onUnknownSideEffect: "stop-and-review"

এই নীতিতে সাধারণ ব্রাউজিং, প্রোডাকশন অ্যাক্সেস, গোপন তথ্য রপ্তানি, দল পরিচালনা বা ইচ্ছেমতো নতুন পরিসর যোগ করার উন্মুক্ত ক্ষমতা নেই। ধোঁয়া-পরীক্ষায় নতুন উৎস বা কার্যক্রম দরকার হলে রানটাইমে অনুমান না করে নীতি-পর্যালোচনার মাধ্যমে পরিবর্তন আনুন।

পর্যালোচনা-তালিকা

ব্রাউজার-প্রোফাইল অটোমেশন-ওয়ার্কফ্লো চালু করার আগে নিশ্চিত করুন:

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

সীমাবদ্ধতা

ন্যূনতম অধিকার ভুল ও ক্রেডেনশিয়াল ফাঁসের প্রভাব কমায়; এটি কোনো অননুমোদিত ওয়ার্কফ্লোকে গ্রহণযোগ্য করে না এবং তৃতীয় পক্ষের সেবা কোনো কাজ করতে দেবে—এমন নিশ্চয়তাও দেয় না। Playwright-এর browser-context সংক্রান্ত ডকুমেন্টেশনে বর্ণিত ব্রাউজার-প্রেক্ষাপট আলাদা রাখা পরীক্ষার বিচ্ছিন্নতা উন্নত করতে পারে, কিন্তু একটি মেশিনকে একাধিক স্বাধীনভাবে বিশ্বস্ত ডিভাইসে পরিণত করে না। আক্রান্ত এন্ডপয়েন্ট, ক্ষতিকর এক্সটেনশন, অতিরিক্ত অধিকার পাওয়া লক্ষ্য-অ্যাকাউন্ট বা অনিরাপদ পরবর্তী সেবা এখনও নির্ধারিত আস্থার সীমা ভেঙে দিতে পারে।

ওয়ার্কফ্লো বদলালে অ্যাক্সেস-অধিকার পর্যালোচনা করুন। অব্যবহৃত পরিসর সরান, নিষ্ক্রিয় ক্রেডেনশিয়ালের মেয়াদ শেষ করুন, প্রত্যাখ্যানের পথ আবার পরীক্ষা করুন এবং কাঁচা সেশন-উপকরণ চাওয়াকে নিয়মিত অটোমেশন-সুবিধা না ধরে আলাদা উচ্চ-ঝুঁকির নিরাপত্তা-পর্যালোচনা হিসেবে বিবেচনা করুন।