Coding agent-এ prompt injection: ঝুঁকি ও প্রতিরোধ

কোডিং agent-এর বিরুদ্ধে prompt injection কী

কোডিং agent-এর বিরুদ্ধে prompt injection সহজভাবে বলা যায়: agent যে text পড়ে, সেটিকে agent-এর অনুসরণ করার instruction হিসেবে বিবেচনা করে। agent একটি file, pull request comment, web page বা কোনো tool call-এর ফলাফল খোলে। সবকিছু আপনার নিজের request-এর মতো একই ধরনের text হিসেবে আসে। কোনো attacker এই text-এর যেকোনো অংশ নিয়ন্ত্রণ করতে পারলে, সে আপনার session-এ text লিখছে।

বর্তমান প্রতিটি agent product-এর মধ্যেই এই বৈশিষ্ট্য রয়েছে। model একটি token sequence গ্রহণ করে। আপনার request, system prompt, file content এবং tool result একসঙ্গে যুক্ত হয়, তারপর model পরবর্তী অংশ কী হবে তা পূর্বাভাস দেয়। কোনো token-এর সঙ্গে privilege bit থাকে না। কোন অংশ আপনি অনুমোদন করেছেন এবং কোন অংশ অপরিচিত কারও README file থেকে এসেছে, তা format-এর কোথাও উল্লেখ থাকে না।

এই page-এ threat model ব্যাখ্যা করা হয়েছে: server-এ চলমান agent-এর কাছে attacker-controlled text কোন কোন পথে পৌঁছায়, প্রতিটি পর্যায়ে attacker কী সুবিধা পায়, এবং কোন defence বাস্তবে প্রয়োগ করা যুক্তিযুক্ত। agent-কে কোন উৎস থেকে containment করতে হবে তা না জানলে আমাদের অন্যান্য guide-এর containment পরামর্শ বোঝা যাবে না।

মডেল কেন কনটেন্টকে নির্দেশনা থেকে আলাদা করতে পারে না

Training সহায়তা করে, কিন্তু সমস্যার সমাধান করে না। বর্তমান মডেলগুলোকে retrieved text সন্দেহের সঙ্গে বিবেচনা করার জন্য training দেওয়া হয়, এবং এগুলো অনেক সরল প্রচেষ্টা প্রত্যাখ্যান করে। প্রত্যাখ্যান কোনো নিয়ম নয়, এটি একটি probability। আক্রমণকারী বক্তব্যটি নতুনভাবে লিখতে পারে, বারবার চেষ্টা করতে পারে এবং এমন format-এ text লুকিয়ে রাখতে পারে যার জন্য কেউ প্রস্তুতি নেয়নি। তারা কত ধরনের wording চেষ্টা করতে পারবে, তার কোনো সীমা নেই।

OWASP GenAI project এটিকে LLM01:2025 Prompt Injection হিসেবে নথিভুক্ত করেছে এবং এটিকে দুই ভাগে বিভক্ত করেছে। Direct injection হলো ব্যবহারকারীর নিজের prompt দিয়ে মডেলের আচরণ পরিবর্তন করা। Indirect injection হলো website বা file-এর মতো external content মডেল process করার সময় তার আচরণ পরিবর্তন করা। Server-এর ক্ষেত্রে indirect injection-ই গুরুত্বপূর্ণ, কারণ আপনি যতটা text type করেন, তার চেয়ে একটি agent অনেক বেশি text পড়ে।

প্রথম systematic study হলো Greshake এবং তাঁর সহকর্মীদের আপনি যে ব্যবস্থায় সম্মতি দিয়েছিলেন, এটি তা নয় (2023)। তাঁদের উপসংহারের এই বাক্যটি মনে রাখা উচিত: কোনো application যখন retrieved text এমন একটি মডেলে পাঠায়, যে মডেল tools call করতে পারে, তখন সেই text process করা অনেকটা arbitrary code execution-এর কাছাকাছি।

পড়া কখন breach-এ পরিণত হয়

শত্রুভাবাপন্ন লেখা পড়া নিজে কোনো ক্ষতি নয়। ক্ষতিকর ফলাফল মেশিনের বাইরে যাওয়ার একটি পথ প্রয়োজন।

Simon Willison 2025 সালের June-এ এই সমন্বয়কে the lethal trifecta নামে অভিহিত করেন। কোনো agent-এর কাছে private data থাকে, সে untrusted content-এর সংস্পর্শে থাকে এবং বাইরে data পাঠাতে পারে—তাহলে তাকে প্রভাবিত করে প্রথমটি তৃতীয়টির মাধ্যমে বাইরে পাঠানো সম্ভব।

আপনার VPS-এ থাকা coding agent-এর ক্ষেত্রে প্রথম দিন থেকেই এই তিনটি শর্ত থাকে। private data হলো আপনার source code, আপনার .env file, আপনার SSH keys এবং shell history। untrusted content হলো agent যে প্রতিটি repository, page এবং tool result পড়ে। বাইরে যাওয়ার পথ হলো git push, curl, npm publish, কোনো pull request body, অথবা terminal-এ প্রদর্শিত এমন কোনো link-এ ক্লিক করা।

আপনি দ্বিতীয় শর্তটি সরাতে পারবেন না, কারণ untrusted text পড়াই agent-কে দেওয়া কাজ। তাই বাস্তবসম্মত প্রতিটি প্রতিরক্ষা বাকি দুটি শর্তের ওপর কাজ করে।

সার্ভারে coding agent-এর কাছে অবিশ্বস্ত text পৌঁছানোর স্থান

agent যে repository-তে কাজ করছে

checkout-এর প্রতিটি file-ই input। Source comment, README.md, changelog, test fixture, vendored code এবং agent-এর instruction file-গুলোও এর অন্তর্ভুক্ত: CLAUDE.md, AGENTS.md এবং এগুলোর সমতুল্য file। কোনো codebase বোঝার জন্য agent-কে বললে agent এগুলো পড়ে, কারণ এটিই আপনার অনুরোধের অংশ।

এখানে attacker repository clone করে agent-কে সেটির ওপর চালানো প্রত্যেক ব্যক্তির কাছে পৌঁছানোর সুযোগ পায়। Instruction file সবচেয়ে সরাসরি পথ, কারণ এগুলো পড়ার জন্যই instruction হিসেবে থাকে। কোনো pull request-এ CLAUDE.md-এ চারটি কার্যকর line এবং agent-কে redirect করা একটি line যোগ করা থাকলে human reviewer তা দ্রুত দেখে এড়িয়ে যেতে পারেন।

Issue, pull request এবং code review comment

আপনার tracker-এ কোনো অপরিচিত ব্যক্তি যা লিখতে পারে, triage করতে agent-কে বলার সঙ্গে সঙ্গে তা agent-এর কাছে পৌঁছে যায়। May 2025-এ Invariant Labs ঠিক এই ধরনের একটি GitHub MCP finding প্রকাশ করে। একজন developer-এর agent একটি public repository এবং private repository-গুলোতে access পেয়েছিল। একজন attacker public repository-তে একটি issue খোলে। Developer agent-কে open issue দেখতে বললে agent private repository-এর content পড়ে public side-এর একটি pull request-এ লিখে দেয়।

ওই report-এ MCP server-এর code defect-এর বদলে architectural problem বর্ণনা করা হয়েছে। Agent-এর কাছে একটি বিস্তৃত access token ছিল, এটি public inbox থেকে পড়তে পারত এবং লেখার permission-ও ছিল। প্রচলিত অর্থে কিছু misconfigured ছিল না। তাই সমাধান patch নয়, access scope নির্ধারণ।

agent যে web page fetch করে

Documentation, forum answer, vendor page, search result—যেকোনোটির text আপনার জন্য নয়, agent-এর জন্য লেখা থাকতে পারে। HTML-কে text-এ রূপান্তর করলে attacker অতিরিক্ত জায়গা পায়, কারণ browser যে content কখনো দেখায় না, সেটিও model-এর কাছে পৌঁছে যায়।

agent যখন সবচেয়ে কম পর্যবেক্ষণে থাকে, attacker তখন নিয়ন্ত্রণ পায়। agent কোনো তথ্য খোঁজার সময় যে page fetch করেছে, তার সম্পূর্ণ text কেউ পড়ে না।

MCP tool output

MCP (model context protocol) হলো external tool-এর সঙ্গে agent সংযোগের প্রচলিত পদ্ধতি। Result text হিসেবে ফিরে এসে সরাসরি context window-তে যায়। এখানে একটি নয়, দুটি attack surface আছে। Tool যে data ফেরত দেয়, সেটি সুস্পষ্ট surface। Tool-এর নিজের name ও description দ্বিতীয় surface; model কখন tool call করবে তা নির্ধারণের জন্য এগুলো পড়ে। আপনি নিয়ন্ত্রণ করেন না এমন server প্রতিটি call-এর মধ্যে যেকোনো একটি পরিবর্তন করতে পারে।

কোনো attacker একটি tool-এর output-এ text ঢোকাতে পারলে agent-এর অন্য সব tool-এও পৌঁছাতে পারে। এভাবেই কম গুরুত্বপূর্ণ কোনো স্থানে থাকা injection শেষ পর্যন্ত বেশি গুরুত্বপূর্ণ কাজ পরিচালনা করতে পারে।

CI log, build output এবং dependency metadata

npm install আপনার লেখা নয় এমন package থেকে text print করে। কোনো test failure library থেকে আসা assertion message print করে। একটি continuous integration (CI) job log-এ third-party output-এর হাজার হাজার line থাকতে পারে। কোনো build ব্যর্থ হলে তা ঠিক করতে agent-কে বললে agent এসবের সব পড়ে।

এখানে attacker build machine-এ পৌঁছানোর সুযোগ পায়। এই machine-এ সাধারণত deploy credential এবং registry token থাকে, অথচ laptop-এর তুলনায় এটিতে কম নজর দেওয়া হয়।

আক্রমণকারী বাস্তবে কী পায়

চারটি ফলাফলের জন্য পরিকল্পনা করা জরুরি।

পরিচয়-সংক্রান্ত তথ্য চুরি। Agent process যে তথ্য পড়তে পারে, তার সবই ঝুঁকির মধ্যে পড়ে: environment variable, ~/.aws/credentials, ~/.ssh, একটি gh token, অথবা একটি Docker config file। এগুলো বাইরে পাঠাতে curl প্রয়োজন হয় না। কোনো branch-এ commit করা, pull request-এর বিবরণ লেখা, কোনো registry-তে package publish করা, অথবা আক্রমণকারীর নিয়ন্ত্রণাধীন কোনো নামের জন্য DNS lookup করা—এসবের যেকোনোটি data-কে server-এর বাইরে পাঠাতে পারে।

আপনার অনুমোদিত code change। Agent-এর কাজই হলো code লেখা। তাই তাকে দিয়ে সামান্য ভুলযুক্ত কোনো line লেখানোই সবচেয়ে সহজে ঘটানো ফলাফল। এর মধ্যে থাকতে পারে একটি অতিরিক্ত dependency, অথবা এমন একটি logging call যা token-কে এমন কোনো log-এ নিয়ে যায়, যেটি আপনি অন্য কোথাও পাঠান।

স্থায়ী উপস্থিতি। একবার লেখা কোনো file model ছাড়াই পরবর্তী সময়ে কাজ করতে পারে: .git/hooks-এ একটি hook, package.json-এ একটি postinstall script, shell startup file-এ যোগ করা একটি line, অথবা CLAUDE.md-এ একটি অতিরিক্ত line। পরবর্তী command এটি চালাবে।

আপনার network-এর ভেতরে সংক্রমণ ছড়ানো। Agent আপনি যেখানে চালান, সেখানেই চলে। সেই server যদি loopback-এ থাকা কোনো database, কোনো internal admin service, আপনার cloud provider-এর metadata service, অথবা private network-এর অন্য কোনো host-এ পৌঁছাতে পারে, তাহলে agent নিয়ন্ত্রণকারী যেকোনো কিছুই সেসব স্থানে পৌঁছাতে পারে।

Auto-approve mode শেষ যাচাইটিও সরিয়ে দেয়

ডিফল্ট mode-এ Claude Code কোনো command চালানো বা file সম্পাদনা করার আগে অনুমতি চায়। উপরের প্রতিটি exposure এবং বাস্তব action-এর মাঝখানে এই prompt-ই human check হিসেবে কাজ করে। যে mode prompt সরিয়ে দেয়, সেটি এই check-ও সরিয়ে দেয়।

ডকুমেন্টেশনে bypassPermissions সম্পর্কে সরাসরি বলা হয়েছে: এটি শুধু container বা VM-এর মতো isolated environment-এ ব্যবহার করুন, যেখানে Claude Code ক্ষতি করতে পারে না। Auto mode তুলনামূলকভাবে নিরাপদ। এটি background safety check-এর মাধ্যমে tool call স্বয়ংক্রিয়ভাবে অনুমোদন করে এবং action আপনার request-এর সঙ্গে সামঞ্জস্যপূর্ণ কি না যাচাই করে। এই check অনেক ঝুঁকি শনাক্ত করতে পারে। তবে এগুলো এখনও model output সম্পর্কে model-এর judgement। তাই এগুলোকে boundary নয়, filter হিসেবে বিবেচনা করুন।

একজন administrator দুটিই সরিয়ে দিতে পারেন। একটি settings file-এ permissions.disableBypassPermissionsMode বা permissions.disableAutoMode-কে "disable" হিসেবে সেট করুন। এরপর file-টি managed settings-এ রাখুন, যাতে checkout করা project সেটি override করতে না পারে। আমাদের Claude Code auto mode ও permission rules নির্দেশিকায় প্রতিটি rule কোথায় কার্যকর হয় তা ব্যাখ্যা করা হয়েছে।

সুরক্ষাগুলো কী সুবিধা দেয় তার ভিত্তিতে ক্রমবিন্যাস

এগুলোর কোনোটিই সম্পূর্ণ সমাধান নয়। প্রতিটি ব্যবস্থা হয় agent-এর কাছে থাকা জিনিসের পরিমাণ কমায়, নয়তো সেগুলো ব্যবহার করে agent কী করতে পারে তা সীমিত করে।

1. এমন একটি machine যা ধ্বংস করে আবার তৈরি করা যায়, যাতে compromise হলে incident সামলানোর বদলে এক ঘণ্টা খরচ হয়।
2. আপনার নিজস্ব credential থেকে আলাদা credential, যা একটি repository-তে সীমাবদ্ধ এবং অল্প সময়ের জন্য কার্যকর।
3. agent-এর command-গুলো যে environment পায়, সেখানে কোনো দীর্ঘমেয়াদি secret না রাখা।
4. network egress এবং file access-এর ওপর operating system enforcement, যা agent শুরু করা প্রতিটি process-এর ক্ষেত্রে প্রযোজ্য।
5. write এবং network call-এর জন্য approval prompt চালু রাখা।
6. যেসব নির্দিষ্ট action-এর নাম আপনি দিতে পারেন, সেগুলোর জন্য deterministic backstop হিসেবে hook ব্যবহার করা।
7. merge করার আগে diff পড়া।

ক্রমটি গুরুত্বপূর্ণ। 1 থেকে 4 নম্বর ব্যবস্থা model সম্পূর্ণভাবে আক্রমণকারীর নিয়ন্ত্রণে থাকলেও কার্যকর থাকে। 5 থেকে 7 নম্বর ব্যবস্থা কোনো মানুষের মনোযোগ দেওয়ার ওপর নির্ভর করে। দীর্ঘ agent run চললে ঠিক এই মনোযোগই সাধারণত আর থাকে না।

এমন machine-এ agent চালান যা বাদ দিয়ে ফেলা যায়

একটি checkout এবং একটি scoped token থাকা VPS, আপনার key থাকা laptop-এর তুলনায় অনেক ছোট লক্ষ্য। agent-কে নিজের unprivileged user হিসেবে চালান। আপনার login account হিসেবে বা root হিসেবে চালাবেন না। coding agent-এর জন্য disposable VM এবং VPS-এ least-privilege user সম্পর্কিত আমাদের guide-গুলোতে setup ব্যাখ্যা করা হয়েছে। VPS-এ নিরাপদে Claude Code চালানো-তে দৈনন্দিন ব্যবহারের কাঠামো দেখানো হয়েছে।

environment থেকে secret সরিয়ে নিন

একটি environment variable প্রতিটি child process পড়তে পারে। অর্থাৎ agent যে প্রতিটি command চালায়, সেগুলোও এটি পড়তে পারে। Claude Code-এর sandbox প্রতিটি sandboxed command চালানোর আগে নির্দিষ্ট variable unset করতে পারে। Linux-এ sandbox ব্যবহারের আগে দুটি package দরকার:

sudo apt-get install bubblewrap socat

এরপর ~/.claude/settings.json-এ:

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    },
    "credentials": {
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

deny entry প্রতিটি sandboxed command চালানোর আগে ওই variable unset করে। allowedDomains-এ আপনি যে host-গুলোর তালিকা দেন, sandboxed command সেগুলোতেই সীমাবদ্ধ থাকে। credentials block-এর জন্য Claude Code v2.1.187 বা পরবর্তী সংস্করণ প্রয়োজন; এটি August 2026-এ যাচাই করা হয়েছে। কোন layer সক্রিয় এবং কোন dependency অনুপস্থিত তা দেখতে কোনো session-এ /sandbox চালান। ওই machine-এ আদৌ কোন secret থাকতে হবে তা নির্ধারণ করাই কাজটির বড় অংশ। AI agent-এর নাগালের বাইরে secret রাখা এই বিষয়টি বিস্তারিতভাবে ব্যাখ্যা করে।

operating system স্তরে network egress সীমিত করুন

Firewall rule model কী সিদ্ধান্ত নিয়েছে তা বিবেচনা করে না। agent-কে একটি নির্দিষ্ট agent user হিসেবে চালান। এরপর ওই user যে traffic পাঠায় তা drop করুন:

table inet agentcage {
  chain output {
    type filter hook output priority filter; policy accept;
    meta skuid "agent" ct state established,related accept
    meta skuid "agent" oif lo accept
    meta skuid "agent" counter drop
  }
}

এতে agent user-এর জন্য শুধু loopback থাকে। তাই তার traffic একই machine-এ চালানো একটি proxy-এর মধ্য দিয়ে যেতে হয়, এবং hostname allowlist proxy-তে থাকে। https_proxy ওই proxy-কে নির্দেশ করলে client একটি CONNECT request পাঠায় এবং proxy name lookup করে। ফলে agent-এর নিজস্ব outbound DNS (domain name system) প্রয়োজন হয় না। sudo nft list ruleset দিয়ে কাজ যাচাই করুন। agent নতুন কোনো গন্তব্যে পৌঁছানোর চেষ্টা করলে drop rule-এর counter বাড়ছে কি না দেখুন।

Firewall পরিবর্তন প্রয়োগ করার সময় দ্বিতীয় একটি SSH session খোলা রাখুন। আপনার container runtime এই rule-গুলোর সঙ্গে কীভাবে কাজ করে তাও পরীক্ষা করুন। Docker নিজস্ব chain তৈরি করে, এবং published Docker port কীভাবে ufw bypass করে-তে এর ফলে তৈরি হওয়া অপ্রত্যাশিত আচরণ ব্যাখ্যা করা হয়েছে।

Hook: যে check-কে model যুক্তি দেখিয়ে পাশ কাটাতে পারে না

Permission rule এবং hook Claude Code প্রয়োগ করে, model নয়। Documentation-এ বিষয়টি স্পষ্টভাবে বলা আছে: আপনার prompt-এর instruction বা CLAUDE.md Claude কী করার চেষ্টা করবে তা নির্ধারণ করে। এগুলো Claude Code কী অনুমোদন করবে তা পরিবর্তন করে না। এই পার্থক্যই পুরো ব্যবস্থার মূল্য। CLAUDE.md-এ লেখা "never run curl" একটি পরামর্শ, যার বিরুদ্ধে injected paragraph যুক্তি দেখাতে পারে। Hook এমন একটি process যা exit code ফেরত দেয়।

PreToolUse hook .claude/settings.json-এ register করুন:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/no-egress.sh"
          }
        ]
      }
    ]
  }
}

Hook standard input-এ tool call-টি JSON হিসেবে পায়। Exit code 2 call-টি block করে এবং standard error থেকে কারণটি Claude-কে দেখায়। Exit code 0 হলে call-টি স্বাভাবিক permission flow-এর মাধ্যমে চলতে থাকে।

#!/usr/bin/env bash
# PreToolUse: stdin holds the tool call, exit 2 blocks it.
cmd=$(jq -r '.tool_input.command // ""')
if printf '%s' "$cmd" | grep -qE '(^|[;&|]|\s)(curl|wget|nc|ncat)(\s|$)'; then
  echo "Blocked: this repository does not allow outbound network commands." >&2
  exit 2
fi
exit 0

এখন সীমাবদ্ধতাটি পরিষ্কারভাবে বলা দরকার। এটি একটি shell string-এর ওপর denylist, আর shell string-এর denylist সহজেই পাশ কাটানো যায়। python3 -c শব্দ curl ব্যবহার না করেও socket খুলতে পারে। make deploy target একই call-কে আরও এক স্তর নিচে আড়াল করতে পারে। যেসব ভুলের নাম আপনি নির্দিষ্টভাবে বলতে পারেন, সেগুলোর জন্য hook লিখুন। কিন্তু আপনি যে boundary-এর ওপর সত্যিই নির্ভর করেন, সেটি kernel বা network স্তরে প্রয়োগ করুন।

Permission deny rule-এর matching limit-ও জানা দরকার। Read এবং Edit deny rule Claude-এর নিজস্ব file tool এবং Bash-এ স্বীকৃত file command-গুলোর ক্ষেত্রে প্রযোজ্য, যেমন cat, head, tail এবং sed। কিন্তু কোনো Python বা Node script নিজে file খুললে এই rule তা আটকায় না। Rule প্রথমে deny, তারপর ask, তারপর allow ক্রমে evaluate হয়। তাই deny rule-এর মধ্যে allowlist exception রাখা যায় না।

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(./secrets/**)",
      "Bash(git push *)"
    ]
  }
}

কী বাইরে যাচ্ছে দেখুন এবং diff পড়ুন

একটি agent run diff এবং network call-এর একটি সেট তৈরি করে। কোনো কিছু merge বা deploy করার আগে দুটিই পরীক্ষা করা উচিত। self-hosted security review pass diff-এর ওপর মানুষের দ্রুত চোখ বুলানোর চেয়ে ভিন্ন ধরনের পরিবর্তন শনাক্ত করতে পারে। coding agent machine-এর বাইরে কী পাঠায় তা জানা স্বাভাবিক traffic কেমন হওয়া উচিত তা বোঝায়, ফলে অস্বাভাবিক request সহজে চোখে পড়ে।

যা এখনো সমাধান হয়নি

বর্তমানে content ও instruction-এর মধ্যে নির্ভরযোগ্য পৃথকীকরণ নেই। প্রকাশিত প্রতিটি প্রতিরক্ষা ব্যবস্থা হয় একটি failure rate-সহ filter, নয়তো ক্ষতির পরিমাণ সীমিত করার ব্যবস্থা। Stack-এর কোনো স্তরই text-এর কোনো অংশকে এমন data হিসেবে চিহ্নিত করে না, যা কখনোই instruction হিসেবে মানা যাবে না।

Filter সহায়তা করে, আবার ব্যর্থও হয়। অধিকাংশ injection attempt শনাক্ত করতে পারে এমন একটি classifier-কেও প্রতিবার সঠিক হতে হয়, আর attacker-কে একবার সঠিক হলেই চলে। এই অসমতার কারণে কোনো প্রতিরক্ষা ব্যবস্থার প্রকাশিত success rate পরবর্তী প্রচেষ্টার জন্য একটি starting point, নিশ্চয়তা নয়।

সবচেয়ে সম্ভাবনাময় কাজ model level-এর বদলে design level-এ হচ্ছে। Defeating Prompt Injections by Design পেপারে Debenedetti ও তাঁর সহকর্মীরা (2025) প্রথমে trusted request থেকে control flow ও data flow বের করেন, যাতে untrusted data program-এর আচরণ পরিবর্তন করতে না পারে। এরপর tool call-এর সময় capability check প্রয়োগ করা হয়। AgentDojo benchmark-এ এর জন্য কী খরচ হয়, তা পেপারটির নিজস্ব figure-গুলোতে দেখানো হয়েছে।

[
  {
    "label": "Undefended agent",
    "tasks_solved_pct": 84
  },
  {
    "label": "CaMeL",
    "tasks_solved_pct": 77
  }
]

কোনো প্রতিরক্ষা ছাড়া agent 84 percent task সমাধান করেছে। CaMeL security guarantee-সহ 77 percent task সমাধান করেছে। এগুলো একটি benchmark-এ পেপারে প্রকাশিত figure; আপনার workload-এর পরিমাপ নয়। বাস্তব guarantee-এর জন্য বর্তমানে যে খরচ দিতে হয়, তাদের ব্যবধানটি মোটামুটি তারই পরিমাণ।

আপনার প্রতিদিনের ব্যবহারের tools-এ এই ধরনের design চালু না হওয়া পর্যন্ত ধরে নিন, কোনো এক সময় agent compromised হবে। সেই ঘটনাকে যেন routine ও সীমিত রাখা যায়, সে অনুযায়ী প্রস্তুতি নিন। Disposable machine, scoped credentials, controlled egress এবং diff পড়ার অভ্যাসের পক্ষে পুরো যুক্তিটিই এখানে।

FAQ

ফাইলের নির্দেশনা উপেক্ষা করতে এজেন্টকে বললে কি prompt injection বন্ধ করা যায়?

না। আক্রমণের লেখার সঙ্গে একই context window-তে থাকা ওই বাক্যটিও পাঠ্যের অংশ, তাই আক্রমণকারীর লেখার সঙ্গে সমানভাবে প্রতিযোগিতা করে। Claude Code-এর documentation বিষয়টি স্পষ্টভাবে আলাদা করেছে: আপনার prompt বা CLAUDE.md-এর নির্দেশনা এজেন্ট কী করার চেষ্টা করবে তা নির্ধারণ করে, কিন্তু এগুলো tool কী করতে পারবে তা পরিবর্তন করে না। একটি instruction file-কে অভিপ্রায়ের বিবৃতি হিসেবে বিবেচনা করুন। আর যেসব বিষয়ে আপনি নির্ভর করেন, সেগুলো permission rules, একটি PreToolUse hook অথবা firewall rule-এ রাখুন।

এজেন্ট যদি শুধু আমার নিজের repository-তে কাজ করে, তবুও কি prompt injection বাস্তব ঝুঁকি?

হ্যাঁ। কারণ আপনার repository-তে এমন অনেক text থাকে যা আপনি লেখেননি। Dependency README file, lockfile URL, test fixture, vendored code এবং npm install-এর output সাধারণ কাজের সময়ই যুক্ত হয়। Issue tracker বা documentation site থেকে আনা যেকোনো বিষয়ও একইভাবে আসে। এজেন্ট যত বেশি text পড়ে, ঝুঁকি তত বাড়ে। কার্যকর এজেন্ট সাধারণত অনেক text পড়ে।

এজেন্টকে container-এ চালালে কি সমস্যার সমাধান হয়?

এতে ক্ষতির পরিমাণ সীমিত হয়, তবে credentials-ও সরিয়ে নিলে তবেই। SSH agent forwarded থাকা, environment-এ cloud credentials থাকা এবং unrestricted network access থাকা একটি container আক্রমণকারীকে host-এর প্রায় সবকিছুই দিয়ে দেয়। Container-এর প্রকৃত সুবিধা হলো এমন একটি filesystem পাওয়া যা আপনি মুছে ফেলতে পারেন এবং egress rules প্রয়োগের জন্য একটি পরিষ্কার পরিবেশ পাওয়া। এর সঙ্গে একটি repository-তে সীমাবদ্ধ token ব্যবহার করুন।

ঝুঁকি সবচেয়ে বেশি কমাতে কোন একক পরিবর্তন করা উচিত?

এজেন্টের command যে environment থেকে পায়, সেখান থেকে long-lived credentials সরিয়ে ফেলুন। এরপর ওই machine-এর জন্য default-deny egress policy প্রয়োগ করুন। একসঙ্গে এগুলো lethal trifecta-র তৃতীয় শর্তটি ভেঙে দেয়: text এখনও এজেন্টকে hijack করতে পারে, কিন্তু এজেন্ট যে data-তে পৌঁছায় তা ব্যবহারের মতো কোনো স্থানে পাঠাতে পারে না। Approval prompt এবং diff review-ও সহায়ক। তবে এগুলোর জন্য দীর্ঘ run চলাকালে একজন মানুষকে সতর্ক থাকতে হয়। তাই ওই দুই পরিবর্তনের নিচে এগুলোর অগ্রাধিকার।