Phishing প্রতিরক্ষা — চেনা, রিপোর্ট করা আর প্রযুক্তিগত বাধা

১ · Phishing কী, আর কেন এটি এখনও বড় প্রবেশপথ

Phishing মানে বিশ্বস্ত কেউ সেজে মানুষকে দিয়ে এমন কিছু করানো, যা তিনি জেনে করতেন না: password দেওয়া, ফাইল খোলা, টাকা পাঠানো বা কোনো app-কে অনুমতি দেওয়া। এটি social engineering-এর সবচেয়ে পরিচিত রূপ। মনস্তত্ত্বের দিকটি পর্ব ৫২ (Social engineering প্রতিরক্ষা) দেখায়। এই পর্ব দেখাবে চেনা, report করা আর প্রযুক্তিগত বাধা।

কেন এত বছর পরও এটি টিকে আছে? চারটি কারণ:

• খরচ কম: একটি বার্তা হাজার জনকে পাঠাতে প্রায় কিছুই লাগে না। আক্রমণকারীর দরকার একজন, রক্ষকের দরকার সবাই।
• নকশার ঐতিহ্য: Email, SMS আর ফোন শুরুতে প্রেরকের পরিচয় প্রমাণ করত না। পরিচয় যাচাই পরে জোড়া হয়েছে (পর্ব ২৬).
• আমাদের কাজই link খোলা: Invoice, শেয়ার করা ফাইল, ডেলিভারির খবর। সন্দেহ করাই যদি সারাদিনের কাজ হয়, সন্দেহ ক্লান্ত হয়।
• পরের ধাপের চাবি: একটি বৈধ login-এর পরে আক্রমণকারী “চেনা ব্যবহারকারী” হয়ে যান, যা সাধারণ alert-কে ফাঁকি দিতে পারে।

সংখ্যা নিয়ে সতর্ক থাকুন। ২০২৬ সালের Verizon DBIR-এর প্রকাশিত সারসংক্ষেপগুলো বলছে, breach-এর প্রবেশপথে vulnerability exploitation প্রায় ৩১% নিয়ে প্রথম, আর phishing প্রায় ১৬%. এই সংখ্যাগুলো মূল প্রতিবেদন নয়, প্রকাশিত সংবাদ ও সারসংক্ষেপ থেকে নেওয়া, আর শ্রেণিবিভাগ বছরে বছরে বদলায়। তাই phishing “সবসময় এক নম্বর” বলা ঠিক নয়, তবে এটি নিয়মিতই বড় প্রবেশপথ। টাকার দিকে FBI IC3-র ২০২৫ সালের বার্ষিক প্রতিবেদনে business email compromise থেকে অভিযোগ করা ক্ষতি প্রায় ৩০৫ কোটি ডলার, যা শুধু যুক্তরাষ্ট্র-কেন্দ্রিক অভিযোগের ছবি।

২ · Phishing-এর নানা রূপ

লক্ষ্য একই, চ্যানেল আর প্রস্তুতি আলাদা। ধরন চিনলে বুঝবেন কোন প্রতিরক্ষা কোনটিতে কাজ করে।

শেষ ধরনটি আলাদা গুরুত্ব পায়, কারণ এটি হাতে টাইপ করা OTP-কেও কাজে লাগাতে পারে। শুধু password নয়, চুরি হতে পারে পুরো session. Relay-এর ধারণা পর্ব ১৬-এ দেখেছেন। নিচের ছবিটি শুধু মূল পার্থক্য দেখায়: passkey কেন এখানে কাজে লাগে।

৩ · লক্ষণ দেখা, আর “বানান ভুল খোঁজা” কেন আর চলে না

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

কাল্পনিক উদাহরণ — সন্দেহজনক বার্তার বিবরণ
From:    "IT Support" <notice@example-com.example>
বিষয়:    আজই কিছু করার তাড়া
ভেতরে:   account বন্ধের ভয়, আর একটি link-এ যেতে বলা
Link:    https://example.com.example.net/verify

এখানে যা দেখার:

• প্রেরকের domain: দেখানো নাম “IT Support” যে কেউ লিখতে পারে। আসল ঠিকানাটি অফিসের example.com নয়।
• তাড়া আর ভয়: আজই করতে হবে, নইলে বন্ধ। চিন্তা করার সময় কেড়ে নেওয়াই উদ্দেশ্য।
• প্রক্রিয়ার সাথে অমিল: আপনার IT বিভাগ কি সত্যিই এভাবে যাচাই করতে বলে?
• Link-এর আসল গন্তব্য: শুরুতে example.com থাকলেও মালিক অন্য কেউ। পরের অংশে দেখবেন কেন।
• অনুরোধটি: Password, OTP, PIN, টাকা পাঠানো, gift card, ব্যাংক হিসাব বদলানো, remote access. এগুলো চাইলেই থামুন।

কেন “টাইপো ধরুন” পরামর্শটি দুর্বল হচ্ছে

বহু বছর ধরে সচেতনতা প্রশিক্ষণ শেখাত: খারাপ বাংলা বা ইংরেজি মানেই phishing. এখন LLM মিনিটে নির্ভুল, ব্যক্তিগত ভঙ্গির লেখা দিতে পারে। Heiding, Lermen, Kao, Schneier ও Vishwanath-এর (arXiv, ২০২৪) ১০১ জনের ছোট পরীক্ষায় সাধারণ নমুনা বার্তায় click ছিল প্রায় ১২%, আর মানুষ-বিশেষজ্ঞ ও সম্পূর্ণ AI-লিখিত বার্তা দুটিতেই প্রায় ৫৪%. নমুনা ছোট আর এটি নিয়ন্ত্রিত পরীক্ষা, তাই সংখ্যাটি সব জায়গায় খাটবে না। দিকটি অবশ্য পরিষ্কার: ভাষার মান আর পরিচয়ের প্রমাণ নয়।

তাই লক্ষণের ক্রম বদলান। আগে দেখুন ভাষা নয়, অনুরোধ, তারপর domain, তারপর প্রক্রিয়া। মনে রাখুন, আপসকৃত আসল account থেকেও phishing আসতে পারে। তখন domain-ও ঠিক থাকে, শুধু অনুরোধটি অস্বাভাবিক লাগে। AI-তে বানানো কণ্ঠ বা ভিডিও ফোনেও একই নীতি: পরিচিত গলা প্রমাণ নয়, অন্য পথে যাচাইই প্রমাণ।

৪ · URL পড়তে শেখা — ডান দিক থেকে মালিক খুঁজুন

নিয়মটি হলো: প্রথমে //-এর পর থেকে প্রথম /, ? বা # পর্যন্ত host খুঁজুন। @ থাকলে তার বাঁ দিকটি host নয়। তারপর host-এর ডান প্রান্ত থেকে public suffix (.com, .com.bd) চিনুন। ঠিক তার আগের নামসহ অংশটিই registrable domain. নিচের কাল্পনিক ঠিকানাটি ধরে এগোন। আশা করছিলেন example.com.

https://
example.com.example.net
/verify?id=7

https://
example.com.example.net
/verify?id=7

https://
example.com.example.net
/verify?id=7

https://
example.com.example.net
/verify?id=7

https://
example.com.example.net
/verify?id=7

চেহারায় কাছাকাছি নাম

Typosquatting-এ অক্ষর এক-আধটু বদলে একটি কাছাকাছি নাম নেওয়া হয়: l-এর বদলে 1, m-এর বদলে rn, বা মাঝে হাইফেন। আরও সূক্ষ্ম ধারণা হলো IDN homograph. Domain-এ এখন নানা ভাষার অক্ষর চলে (Internationalized Domain Name). এতে বাংলা নামের domain-ও সম্ভব, যা ভালো কথা। কিন্তু Latin a আর Cyrillic а দেখতে প্রায় এক, যদিও কম্পিউটারের কাছে আলাদা অক্ষর। DNS-এ এমন নাম যায় Punycode রূপে, xn-- দিয়ে শুরু।

ব্রাউজারগুলো নিজ নিজ নিয়মে সন্দেহজনক মিশ্র অক্ষরের নাম Punycode-এ দেখায়। নিয়ম একেক ব্রাউজারে একেক রকম, আর চোখ দিয়ে এটি নিয়মিত ধরা কঠিন। তাই এর সমাধান মানুষের চোখ নয়: password manager আর passkey অক্ষর ধরে মেলায়, চেহারা ধরে নয়।

নিচের কোডটি একই নিয়ম প্রোগ্রামে করে। এটি নিজে ভাঙাচোরা string কাটে না, ভাষার URL parser ব্যবহার করে, আর ছোট একটি কাল্পনিক suffix তালিকা দেখে। কোনো request পাঠানো হয় না।

// Toy URL reader. Reserved example names only; no request is sent.
// Real tools use the full Public Suffix List. This short list is invented.
const suffixes = ['com', 'net', 'org', 'example', 'co.example'];
const expected = 'example.com';

function registrable(host) {
  const labels = host.split('.');
  for (let i = 0; i < labels.length; i++) {       // longest suffix first
    if (suffixes.includes(labels.slice(i).join('.'))) {
      return i === 0 ? '(suffix only)' : labels.slice(i - 1).join('.');
    }
  }
  return '(unknown suffix)';
}

const urls = [
  'https://www.example.com/pay',
  'https://example.com.example.net/pay',
  'https://example.com@example.org/pay',
  'https://example-com.example/pay',
  'https://examp1e.example/pay',
  'https://exаmple.example/pay',   // Cyrillic a inside the name
  'https://pay.shop.co.example/pay',
];

for (const raw of urls) {
  const host = new URL(raw).hostname;     // the parser finds the real host
  const reg = registrable(host);
  const verdict = reg === expected ? 'MATCH' : 'DIFFERENT';
  console.log(verdict.padEnd(10) + reg.padEnd(26) + 'host=' + host);
}

৫ · নিরাপদ অভ্যাস — মনোযোগ কমলেও যা কাজ করে

প্রতিটি link পরীক্ষা করা অসম্ভব, বিশেষ করে ক্লান্ত দুপুরে বা ফোনের ছোট পর্দায়। ভালো অভ্যাস সেটি, যার জন্য আলাদা বিচার লাগে না।

• Link নয়, নিজের পথ: ব্যাংক, মোবাইল ব্যাংকিং, অফিস portal বা কোনো সরকারি সেবার বার্তা এলে link চাপবেন না। নিজের সংরক্ষিত bookmark বা অফিসিয়াল app দিয়ে ঢুকুন। সত্যি কিছু থাকলে সেখানেই দেখবেন।
• অন্য পথে যাচাই: টাকা বা হিসাব বদলের অনুরোধ এলে জানা নম্বরে ফোন করুন, বার্তার দেওয়া নম্বরে নয়। পুরোনো খাতায় লেখা নম্বরই ভরসা।
• OTP আর PIN কাউকে না: ব্যাংক, মোবাইল অপারেটর বা IT সাপোর্ট কখনো এগুলো চাওয়ার কথা নয়। চাইলে সেটিই লক্ষণ।
• Password manager ব্যবহার: এটি যাচাই করা domain ধরে পূরণ করে, চেহারা ধরে নয়।
• Passkey বা security key: যেখানে আছে, চালু করুন (পর্ব ১৬).
• QR code: খাবার দোকান বা বিলবোর্ডে চিপকানো QR-এর ওপরে আলাদা স্টিকার আছে কি না দেখুন। খোলার আগে ফোনে দেখানো domain পড়ুন।

৬ · প্রযুক্তিগত স্তর — প্রতিটি কী থামায়, কী থামায় না

মহল্লার নিরাপত্তায় যেমন গেট, দারোয়ান, রাতের পাহারা আর ঘরের তালা একসাথে থাকে, phishing-এও তেমনি defense in depth লাগে (পর্ব ৩). যুক্তরাজ্যের NCSC-র নির্দেশিকাও স্তরভিত্তিক প্রতিরক্ষার কথা বলে, যেখানে ব্যবহারকারীর চোখ একমাত্র ভরসা নয়। ২০২৩ সালে CISA, NSA, FBI ও MS-ISAC-এর যৌথ নির্দেশিকা phishing-এর দুটি লক্ষ্যে জোর দেয়: credential চুরি আর malware ঢোকানো।

চিঠির header থেকে প্রথম স্তরের ফল দেখা যায়। আপনার mail server Authentication-Results নামের একটি লাইন (RFC 8601) যোগ করে। এখানে দুটি বড় ফাঁদ: প্রেরকও এমন একটি লাইন আগেই লিখে পাঠাতে পারেন, তাই শুধু নিজের server-এর লাইন গণ্য; আর dmarc=pass মানে domain প্রমাণিত, উদ্দেশ্য সৎ নয়। নিচে কাল্পনিক চারটি চিঠি। mx.example.org আমাদের নিজের server.

// Toy Authentication-Results reader (format from RFC 8601). Invented data.
// Only the line stamped by OUR OWN receiving server is trusted.
const ourServer = 'mx.example.org', ourPartners = ['example.com'];
const mails = {
  A: ['mx.example.org; spf=pass smtp.mailfrom=example.com; ' +
      'dkim=pass header.d=example.com; dmarc=pass header.from=example.com'],
  B: ['mx.example.org; spf=pass smtp.mailfrom=example.net; ' +
      'dkim=none; dmarc=fail header.from=example.com'],
  C: ['mx.example.org; spf=pass smtp.mailfrom=example-com.example; ' +
      'dkim=pass header.d=example-com.example; ' +
      'dmarc=pass header.from=example-com.example'],
  D: ['relay.example.net; dmarc=pass header.from=example.com',
      'mx.example.org; spf=fail smtp.mailfrom=example.net; ' +
      'dkim=none; dmarc=fail header.from=example.com'],
};

function read(lines) {
  const line = lines.find(l => l.split(';')[0].trim() === ourServer);
  if (!line) return 'no trusted line: treat as unauthenticated';
  const dmarc = /dmarc=(\w+)/.exec(line)[1];
  const from = /header\.from=([\w.-]+)/.exec(line)[1];
  const skipped = lines.length - 1;
  let note = dmarc !== 'pass' ? 'SUSPECT: From is not proven'
    : ourPartners.includes(from) ? 'OK: domain proven and known'
    : 'CAUTION: proven, but unknown domain';
  if (skipped) note += ' (ignored ' + skipped + ' other line)';
  return 'from=' + from + ' dmarc=' + dmarc + ' -> ' + note;
}

for (const id in mails) console.log(id + ': ' + read(mails[id]));

৭ · Report বোতাম থেকে mailbox purge

Filter যেটি পার হলো, তার প্রথম খবর সাধারণত একজন মানুষই দেন। তাই সবচেয়ে সহজ জায়গায় একটি report বোতাম রাখুন: mail app-এর ওপরেই, এক চাপে, যেখানে চিঠিটি পুরো header-সহ SOC-এ পৌঁছায়। ফোন বা SMS-এর জন্য একটি সহজ নম্বর বা chat চ্যানেল রাখুন। একজন report করলে তাঁকে দ্রুত জানান “ধন্যবাদ, দেখা হচ্ছে”। Lain ও সহকর্মীদের গবেষণায় (২০২২) ইতিবাচক সাড়া পরে আরও report বাড়িয়েছিল। ওই গবেষণায় report-এর গড় সঠিকতা ছিল প্রায় ৬৮%, তাই ভুল report-ও আসবে, আর সেজন্যই triage লাগে। ভুল report-এর জন্য কাউকে বকবেন না।

কেন দ্রুত report এত দামি: একটি হিসাব

নিচে একটি কাল্পনিক প্রতিষ্ঠানে ১৮০ জনের mailbox-এ পৌঁছানো একটি বার্তার পথ দেখুন। সময় বার্তা পৌঁছানোর পর থেকে গোনা।

এই পথের সবচেয়ে কঠিন ধাপটি purge, কারণ ভুল search-এ বৈধ চিঠিও মুছে যায়। নিচের সিমুলেটরে একটি কাল্পনিক in-memory mailbox আছে। একজন আসল ব্যবসায়িক সহযোগীও একই বিষয় দিয়ে চিঠি পাঠিয়েছেন।

// Toy mailbox purge. In-memory objects only; no mail server is touched.
const mail = [
  { box: 'rina',  from: 'notice@example.net',  subj: 'Invoice 44', url: 'example.net/v', clicked: true },
  { box: 'tuhin', from: 'notice@example.net',  subj: 'Invoice 44', url: 'example.net/v', clicked: false },
  { box: 'mitu',  from: 'notice@example.net',  subj: 'Invoice 44', url: 'example.net/v', clicked: true },
  { box: 'sohel', from: 'notice@example.net',  subj: 'Invoice 44', url: 'example.net/v', clicked: false },
  { box: 'rina',  from: 'billing@example.org', subj: 'Invoice 44', url: 'example.org/i', clicked: false },
  { box: 'mitu',  from: 'hr@example.com',      subj: 'Leave form', url: 'example.com/l', clicked: true },
];
const quarantine = [], log = [];
const broad = m => m.subj === 'Invoice 44';
const scoped = m => m.from === 'notice@example.net' && m.url === 'example.net/v';

function dryRun(rule) { return mail.filter(rule).length; }
function purge(rule, who) {
  for (const m of mail.filter(rule)) {
    mail.splice(mail.indexOf(m), 1);
    quarantine.push(m);                     // kept as evidence, can be restored
  }
  log.push(who + ' moved ' + quarantine.length + ' to quarantine');
}

console.log('dry run, subject only :', dryRun(broad), 'match (1 is a real invoice!)');
console.log('dry run, from + url   :', dryRun(scoped), 'match');
const followUp = mail.filter(scoped).filter(m => m.clicked).map(m => m.box);
purge(scoped, 'analyst-1');
console.log('left in mailboxes     :', mail.map(m => m.box + ':' + m.subj).join(', '));
console.log('quarantined           :', quarantine.length);
console.log('follow up with        :', followUp.join(', '));
console.log('audit log             :', log[0]);

৮ · Phishing simulation — নৈতিকতা, গবেষণা আর ঠিক metric

Phishing simulation মানে প্রতিষ্ঠান অনুমোদিতভাবে নিজের কর্মীদের কাছে নকল phishing পাঠিয়ে দেখে, মানুষ ও প্রক্রিয়া কেমন সাড়া দিচ্ছে। এটি অগ্নি-মহড়ার মতো হতে পারে: লক্ষ্য মানুষকে লজ্জা দেওয়া নয়, দরজা আর সিঁড়ি পরীক্ষা করা। কিন্তু গবেষণা বলে, এর ফল অনেকের ধারণার চেয়ে অনেক সীমিত।

একই সাথে পুরোনো কিছু গবেষণা (যেমন Kumaraguru ও সহকর্মীদের ২০০৯ সালের কাজ) প্রশিক্ষণের ইতিবাচক ফল পেয়েছিল। ফল প্রতিষ্ঠান, পদ্ধতি আর মাপার ধরনভেদে বদলায়। তাই সৎ অবস্থান হলো: training-কে বাদ দেওয়া নয়, তবে একে প্রধান নিয়ন্ত্রণও না ভাবা। Ho ও সহকর্মীদের সুপারিশও প্রযুক্তিগত প্রতিরক্ষায় জোর দেওয়া। গবেষণার দ্বিতীয় বড় শিক্ষা: Ho-র গবেষণায় একই প্রতিষ্ঠানে বার্তাভেদে click হার ১.৮২% থেকে ৩০.৮% পর্যন্ত গেছে। অর্থাৎ বার্তা বদলালেই হার বদলায়, মানুষ নয়।

নৈতিক নিয়ম

• লিখিত অনুমোদন: পরিচালনা, HR আর আইন বিভাগের সম্মতি, স্পষ্ট পরিধি, আর কর্মীদের আগে জানানো যে এমন কর্মসূচি আছে।
• আসল password নেবেন না: Simulation-এর কোনো ফর্মে কেউ কিছু টাইপ করলে তা সংরক্ষণ নয়। “জমা দেওয়া হয়েছে” এটুকুই গণনা।
• নিষ্ঠুর লোভ নয়: বোনাস, ছাঁটাই, স্বাস্থ্য বা শোকের গল্প ব্যবহার করবেন না। এতে আস্থা ভাঙে।
• শাস্তি নয়: শাস্তির ভয়ে মানুষ click লুকাবেন, আর ঠিক সেটিই SOC-এর সবচেয়ে বড় ক্ষতি। প্রয়োজন হলে সহায়তা আর প্রক্রিয়া বদল। পর্ব ৫৪ (নিরাপত্তা সংস্কৃতি) এটি বিস্তারে দেখায়।
• তথ্য গোপন রাখা: ব্যক্তির নাম ধরে তালিকা বানিয়ে ম্যানেজারদের পাঠানো নয়, দলভিত্তিক সারাংশ দেওয়া।

কী মাপবেন

শুধু কত জন পড়লেন দেখলে আপনি মানুষকে দোষী বানাচ্ছেন। দেখুন কত দ্রুত প্রতিষ্ঠান জানল। Report rate আর প্রথম report-এর সময় সরাসরি SOC-এর সাড়ার সক্ষমতা মাপে। নিচে দুটি কাল্পনিক দফার হিসাব। আসল simulation-এ বার্তার কঠিনতা মিলিয়ে তবেই তুলনা চলে।

// Toy phishing-simulation funnel. All numbers are invented.
const runs = [
  { name: 'Run 1', delivered: 400, opened: 260, clicked: 48, submitted: 22,
    reported: 36,  reportMin: [41, 12, 95, 30, 66, 18, 120] },
  { name: 'Run 2', delivered: 400, opened: 255, clicked: 52, submitted: 14,
    reported: 120, reportMin: [3, 9, 5, 21, 14, 7, 33, 11, 6] },
];
const pct = (a, b) => (100 * a / b).toFixed(1) + '%';
function median(xs) {
  const s = [...xs].sort((a, b) => a - b), m = Math.floor(s.length / 2);
  return s.length % 2 ? s[m] : (s[m - 1] + s[m]) / 2;
}
for (const r of runs) {
  console.log(r.name);
  console.log('  click rate      ' + pct(r.clicked, r.delivered));
  console.log('  submit rate     ' + pct(r.submitted, r.delivered));
  console.log('  report rate     ' + pct(r.reported, r.delivered));
  console.log('  reports/click   ' + (r.reported / r.clicked).toFixed(2));
  console.log('  first report    ' + Math.min(...r.reportMin) + ' min');
  console.log('  median report   ' + median(r.reportMin) + ' min');
}

৯ · Click করে ফেললে, বা password দিয়ে ফেললে

প্রথম কথা: আপনি একা নন, আর চুপ থাকাই সবচেয়ে বড় ভুল। প্রথম কয়েক মিনিটের জানানো পরের কয়েক সপ্তাহের কাজ বাঁচাতে পারে।

শুধু click করলে, কিছু দেননি: Page বন্ধ করুন, report করুন। ফাইল নামলে খুলবেন না। অফিসে থাকলে SOC বা IT-কে জানান, কারণ ব্রাউজার বা ডিভাইসের ঝুঁকি মাপা তাঁদের কাজ (পর্ব ৩৩).

ফাইল খুলে ফেললে: কম্পিউটার বন্ধ করবেন না। Network থেকে বিচ্ছিন্ন করুন আর সঙ্গে সঙ্গে জানান। অফিসে কী করবেন, তা playbook মেনে চলুন; মেমোরির প্রমাণ বন্ধ করলে হারাতে পারে।

Password দিয়ে ফেললে: নিচের ক্রমটি দেখুন।

১০ · AI-এর যুগে phishing প্রতিরক্ষা

AI দুই দিকেই কাজ করে। আক্রমণের ভাষা আর পরিমাণ সহজ হয়েছে, তবে triage, সারাংশ আর URL ব্যাখ্যায় AI রক্ষকেরও ভালো সহকারী। Security কাজে AI সাধারণত যেসব ভুল করে:

• না-থাকা CVE, RFC বা গবেষণা বানিয়ে দেওয়া, আর পুরোনো নিয়মকে বর্তমান বলা, যেমন শুধু RFC 7489 ধরে DMARC ব্যাখ্যা।
• সমস্যা “মেটাতে” নিয়ন্ত্রণ দুর্বল করা: filter শিথিল করা, verify=False, chmod 777, ব্রড CORS, MFA সরিয়ে দেওয়া।
• পুরোনো crypto পরামর্শ (MD5, ECB, salt ছাড়া hash), আর injection বা authorization ফাঁকওয়ালা কোড।
• Triage-এ অতিরিক্ত আত্মবিশ্বাস: “এটি নিরাপদ” বলে দেওয়া, অথচ chat থেকে সে link খোলেনি বা log দেখেনি।
• Prompt-এ দেওয়া আসল চিঠি, ঠিকানা, token বা header-এর তথ্য বাইরে চলে যাওয়ার ঝুঁকি।
• চিঠির ভেতরের লেখা নির্দেশ মেনে নেওয়া: সন্দেহজনক চিঠি নিজেই prompt injection বহন করতে পারে (পর্ব ৫১).

AI-এর উত্তর হাতে পেলে — যাচাইয়ের চেকলিস্ট

• Prompt-এ কোনো আসল password, token, ব্যক্তিগত তথ্য বা পুরো চিঠি দিইনি
• উল্লেখ করা RFC, CVE বা গবেষণা মূল উৎসে নিজে খুঁজে পেয়েছি
• URL-এর মালিক নিজে বা parser দিয়ে মিলিয়েছি, AI-এর কথায় নয়
• সন্দেহজনক link কোনো AI বা নিজের যন্ত্রে সরাসরি খুলিনি; অনুমোদিত sandbox-এ দেখেছি
• Purge বা block-এর আগে dry run দেখেছি, আর সিদ্ধান্ত একজন মানুষ নিয়েছেন
• AI-এর বলা “নিরাপদ” কথাটি log আর gateway-র তথ্য দিয়ে মিলিয়ে দেখেছি