کوڈنگ agent کے خلاف prompt injection کیا ہے؟

کوڈنگ agent کے خلاف prompt injection کیا ہے

کوڈنگ agent کے خلاف prompt injection کو سادہ الفاظ میں یوں بیان کیا جا سکتا ہے: agent جو متن پڑھتا ہے، اسے ایسی ہدایت سمجھ لیتا ہے جس پر اسے عمل کرنا ہے۔ agent کوئی file، pull request comment، web page یا tool call کا نتیجہ کھولتا ہے۔ یہ تمام مواد آپ کی اپنی درخواست جیسے ہی متن کی صورت میں agent تک پہنچتا ہے۔ اگر حملہ آور اس متن میں سے کسی حصے کو کنٹرول کرتا ہو تو وہ آپ کے session میں لکھ رہا ہوتا ہے۔

ہر موجودہ agent product میں یہ خاصیت موجود ہے۔ model کو tokens کی ایک ہی sequence موصول ہوتی ہے۔ آپ کی درخواست، system prompt، file contents اور tool results کو یکجا کیا جاتا ہے، پھر model پیش گوئی کرتا ہے کہ اس کے بعد کیا آنا چاہیے۔ کسی token کے ساتھ privilege bit منسلک نہیں ہوتی۔ format میں یہ بتانے والی کوئی چیز نہیں ہوتی کہ کون سا حصہ آپ نے authorize کیا ہے اور کون سا کسی اجنبی کی README file سے آیا ہے۔

یہ صفحہ threat model پیش کرتا ہے: حملہ آور کے زیرِ اختیار متن server پر چلنے والے agent تک کن راستوں سے پہنچتا ہے، ہر مقام پر حملہ آور کو کیا حاصل ہوتا ہے، اور کون سے دفاعی اقدامات کی لاگت کے مقابلے میں حقیقی فائدہ ہے۔ ہماری دیگر guides میں دی گئی containment advice تبھی قابلِ فہم ہوتی ہے جب آپ جانتے ہوں کہ agent کو کس چیز سے contain کرنا ہے۔

ماڈل مواد کو ہدایات سے الگ کیوں نہیں کر سکتا

Training مدد دیتی ہے، لیکن مسئلہ حل نہیں کرتی۔ موجودہ models کو اس طرح train کیا جاتا ہے کہ وہ retrieved text کو مشکوک سمجھیں، اور وہ کئی واضح کوششوں کو مسترد بھی کرتے ہیں۔ انکار ایک probability ہے، قطعی rule نہیں۔ attacker متن کو دوبارہ لکھ سکتا ہے، بار بار کوشش کر سکتا ہے، اور اسے ایسے format میں چھپا سکتا ہے جس کے لیے کسی نے منصوبہ بندی نہ کی ہو۔ اس کی کوشش کردہ عبارتوں کی تعداد محدود نہیں ہوتی۔

OWASP GenAI project اسے LLM01:2025 Prompt Injection کے طور پر track کرتا ہے اور اسے دو اقسام میں تقسیم کرتا ہے۔ Direct injection میں user کا اپنا prompt model کے رویے کو بدلتا ہے۔ Indirect injection میں external content، جیسے website یا file، model کے اس content کو process کرنے کے دوران اس کے رویے کو بدلتا ہے۔ Server پر indirect injection زیادہ اہم ہے، کیونکہ agent آپ کے لکھے ہوئے متن سے کہیں زیادہ text پڑھتا ہے۔

اس موضوع پر پہلی systematic study Greshake اور ان کے ساتھیوں کی Not what you've signed up for (2023) ہے۔ ان کا نتیجہ یاد رکھنے کے قابل ہے: جب کوئی application retrieved text کو ایسے model میں فراہم کرتی ہے جو tools call کر سکتا ہو، تو اس text کو process کرنا arbitrary code execution کے قریب ہوتا ہے۔

وہ شرط جو مطالعے کو سکیورٹی breach میں بدل دیتی ہے

مخالفانہ متن پڑھنا بذاتِ خود نقصان نہیں ہوتا۔ نقصان کے لیے مشین سے باہر نکلنے کا راستہ ضروری ہے۔

Simon Willison نے جون 2025 میں اس امتزاج کو lethal trifecta کا نام دیا۔ جو agent نجی ڈیٹا رکھتا ہو، غیر معتبر مواد کے سامنے exposed ہو، اور ڈیٹا باہر بھیج سکتا ہو، اسے اس طرح قائل کیا جا سکتا ہے کہ وہ پہلے ذریعے سے ڈیٹا نکال کر تیسرے ذریعے سے باہر بھیج دے۔

آپ کے VPS پر موجود coding agent کے پاس پہلے دن ہی یہ سب موجود ہوتا ہے۔ نجی ڈیٹا آپ کا source code، آپ کی .env فائل، آپ کی SSH keys اور آپ کی shell history ہے۔ غیر معتبر مواد ہر repository، page اور tool result پر مشتمل ہے جسے وہ پڑھتا ہے۔ باہر نکلنے کا راستہ git push، curl، npm publish، pull request body، یا آپ کے terminal میں ظاہر ہونے والا ایسا link ہے جس پر آپ click کرتے ہیں۔

آپ دوسری شرط ختم نہیں کر سکتے، کیونکہ غیر معتبر متن پڑھنا ہی وہ کام ہے جس کے لیے آپ نے agent کو مقرر کیا ہے۔ اس لیے ہر عملی دفاع باقی دو شرائط پر توجہ دیتا ہے۔

سرور پر coding agent تک غیر معتبر متن کہاں پہنچتا ہے

وہ repository جس میں agent کام کر رہا ہے

checkout میں موجود ہر فائل input ہے۔ Source comments، README.md، changelogs، test fixtures، vendored code، اور agent کی instruction files بھی، یعنی CLAUDE.md، AGENTS.md اور ان کے مساوی files۔ جب آپ agent سے codebase سمجھنے کو کہتے ہیں تو وہ یہ فائلیں پڑھتا ہے، کیونکہ آپ نے اسی کام کی ہدایت دی ہے۔

یہاں attacker ہر اس شخص تک رسائی حاصل کر لیتا ہے جو repository کو clone کرکے اس پر agent چلاتا ہے۔ Instruction files سب سے براہ راست راستہ ہیں، کیونکہ انہیں instructions کے طور پر پڑھا جاتا ہے۔ ایک pull request جو CLAUDE.md میں چار مفید lines اور agent کو redirect کرنے والی ایک line شامل کرے، انسانی reviewer کی سرسری نظر سے گزر سکتی ہے۔

Issues، pull requests اور code review comments

آپ کے tracker میں کوئی اجنبی جو کچھ بھی لکھ سکتا ہے، وہ اسی وقت agent تک پہنچ جاتا ہے جب آپ اسے triage کرنے کو کہتے ہیں۔ May 2025 میں Invariant Labs نے اسی نوعیت کی ایک GitHub MCP finding شائع کی۔ ایک developer کے agent کو ایک public repository اور private repositories تک رسائی حاصل تھی۔ ایک attacker نے public repository میں issue file کیا۔ جب developer نے agent سے open issues دیکھنے کو کہا تو agent نے private repository کا content پڑھ کر اسے public side پر ایک pull request میں لکھ دیا۔

اس report میں MCP server کے code defect کے بجائے architectural مسئلہ بیان کیا گیا ہے۔ Agent کے پاس وسیع اختیارات والا ایک access token تھا، وہ public inbox سے پڑھ سکتا تھا، اور اسے write permission حاصل تھی۔ معمول کے مفہوم میں کچھ misconfigured نہیں تھا، اسی لیے حل patching نہیں بلکہ scoping ہے۔

وہ web pages جنہیں agent fetch کرتا ہے

Documentation، forum answers، vendor page، search result۔ ان میں سے کوئی بھی ایسا text رکھ سکتا ہے جو آپ کے بجائے agent کے لیے لکھا گیا ہو۔ HTML کو text میں تبدیل کرنے سے attacker کو اضافی گنجائش ملتی ہے، کیونکہ وہ content بھی model تک پہنچ جاتا ہے جسے browser کبھی display نہیں کرتا۔

Attacker کو اس وقت control ملتا ہے جب agent پر سب سے کم نظر رکھی جا رہی ہوتی ہے۔ جب agent کسی چیز کی تلاش کے دوران page fetch کرتا ہے تو کوئی بھی اس کا مکمل text نہیں پڑھتا۔

MCP tool output

MCP (model context protocol) وہ عام طریقہ ہے جس سے agents external tools سے connect ہوتے ہیں۔ Results text کی صورت میں واپس آتے ہیں اور براہ راست context window میں چلے جاتے ہیں۔ یہاں ایک نہیں بلکہ دو surfaces ہیں۔ Tool کا واپس کیا ہوا data واضح surface ہے۔ Tool کا اپنا name اور description دوسرا surface ہے، جسے model یہ فیصلہ کرنے کے لیے پڑھتا ہے کہ tool کو کب call کرنا ہے۔ آپ کے control سے باہر کوئی server دونوں میں سے کسی کو بھی دو calls کے درمیان تبدیل کر سکتا ہے۔

جو attacker ایک tool کے output میں text شامل کر دے، وہ agent کے استعمال میں موجود ہر دوسرے tool تک پہنچ جاتا ہے۔ اسی طرح کم اہمیت والے کسی حصے میں کی گئی injection، زیادہ اہمیت والے کام کو control کرنے لگتی ہے۔

CI logs، build output اور dependency metadata

npm install ان packages سے text print کرتا ہے جو آپ نے نہیں لکھے۔ Test failure کسی library کا assertion message print کر سکتا ہے۔ Continuous integration (CI) job log میں third-party output کی ہزاروں lines ہوتی ہیں۔ Agent سے failing build ٹھیک کرنے کو کہیں تو وہ یہ سب پڑھتا ہے۔

یہاں attacker build machine تک پہنچتا ہے۔ اس machine پر عموماً deploy credentials اور registry tokens موجود ہوتے ہیں، اور laptop کے مقابلے میں اس پر کم توجہ دی جاتی ہے۔

حملہ آور کو حقیقت میں کیا حاصل ہوتا ہے

چار ممکنہ نتائج کے لیے منصوبہ بندی ضروری ہے۔

اسناد کی چوری۔ ایجنٹ process جس چیز کو پڑھ سکتا ہے، وہ سب خطرے کے دائرے میں شامل ہے: environment variables، ~/.aws/credentials، ~/.ssh، ایک gh token، یا Docker config file۔ انہیں باہر بھیجنے کے لیے curl کی ضرورت نہیں ہوتی۔ کسی branch پر commit، pull request کی description، کسی registry پر شائع کیا گیا package، یا حملہ آور کے زیرِکنٹرول نام کے لیے DNS lookup، یہ سب data کو server سے باہر منتقل کر دیتے ہیں۔

وہ code changes جنہیں آپ approve کرتے ہیں۔ 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 کے اندر پھیلاؤ۔ ایجنٹ اسی جگہ چلتا ہے جہاں آپ اسے چلاتے ہیں۔ اگر وہ server loopback پر موجود database، کسی internal admin service، آپ کے cloud provider کی metadata service، یا private network کے کسی دوسرے host تک پہنچ سکتا ہے، تو ایجنٹ کو چلانے والا کوئی بھی عمل بھی ان تک پہنچ سکتا ہے۔

خودکار منظوری کے طریقے آخری جانچ بھی ختم کر دیتے ہیں

پہلے سے مقررہ طریقے میں Claude Code کمانڈ چلانے یا فائل میں ترمیم کرنے سے پہلے اجازت طلب کرتا ہے۔ یہ prompt ہر مذکورہ سطح اور حقیقی کارروائی کے درمیان انسانی جانچ کا مرحلہ ہوتا ہے۔ وہ طریقے جو prompt ختم کر دیتے ہیں، یہ جانچ بھی ختم کر دیتے ہیں۔

دستاویزات bypassPermissions کے بارے میں واضح ہیں: اسے صرف ایسے الگ تھلگ ماحول، مثلاً containers یا VMs، میں استعمال کریں جہاں Claude Code نقصان نہ پہنچا سکے۔ Auto mode نسبتاً محتاط ہے۔ یہ tool calls کو پسِ منظر میں ہونے والی safety checks کے ساتھ خودکار طور پر منظور کرتا ہے، جو یہ تصدیق کرتی ہیں کہ کارروائیاں آپ کی درخواست سے مطابقت رکھتی ہیں۔ یہ checks بہت سی غلطیاں پکڑ لیتی ہیں۔ پھر بھی یہ model output کے بارے میں model judgement ہیں، اس لیے انہیں حدِ تحفظ نہیں بلکہ ایک filter سمجھیں۔

Administrator دونوں کو ختم کر سکتا ہے۔ settings file میں permissions.disableBypassPermissionsMode یا permissions.disableAutoMode کو "disable" پر set کریں، اور اس file کو managed settings میں رکھیں تاکہ checked-out project اسے override نہ کر سکے۔ ہماری Claude Code auto mode اور permission rules کی رہنمائی میں بتایا گیا ہے کہ ہر rule کہاں مؤثر ہوتا ہے۔

دفاعی اقدامات، ان کے فائدے کے لحاظ سے درجہ بندی

ان میں سے کوئی بھی مکمل حل نہیں ہے۔ ہر اقدام یا تو agent کے پاس موجود چیزوں کو محدود کرتا ہے، یا ان چیزوں کے استعمال کی صلاحیت کو محدود کرتا ہے۔

1. ایسی مشین جسے آپ ختم کر کے دوبارہ بنا سکیں، تاکہ compromise کی صورت میں آپ کا نقصان ایک گھنٹے تک محدود رہے، security incident نہ بنے۔
2. ایسے credentials جو آپ کے اپنے credentials سے الگ ہوں، صرف ایک repository تک محدود ہوں، اور مختصر مدت کے لیے مؤثر ہوں۔
3. agent کے commands کو ملنے والے environment میں کوئی طویل مدتی secrets موجود نہ ہوں۔
4. network egress اور file access پر operating system کا نفاذ، جو agent کے شروع کیے ہوئے ہر process پر لاگو ہو۔
5. writes اور network calls کے لیے approval prompts فعال رکھنا۔
6. ان مخصوص actions کے لیے hooks کو deterministic backstop کے طور پر استعمال کرنا جنہیں آپ واضح طور پر نام دے سکتے ہیں۔
7. merge کرنے سے پہلے diff پڑھنا۔

ترتیب اہم ہے۔ Items 1 سے 4 تک کے اقدامات اس وقت بھی مؤثر رہتے ہیں جب model مکمل طور پر حملہ آور کے کنٹرول میں ہو۔ Items 5 سے 7 تک کے اقدامات انسان کی توجہ پر منحصر ہیں، اور طویل agent run کے دوران عموماً یہی توجہ ختم ہو جاتی ہے۔

agent کو ایسی مشین پر چلائیں جسے آپ ضائع کر سکیں

ایک VPS جس پر صرف checkout اور ایک scoped token ہو، اس laptop کے مقابلے میں بہت کم قیمتی ہدف ہے جس پر آپ کی keys موجود ہوں۔ agent کو اپنے الگ unprivileged user کے طور پر چلائیں، نہ اپنے login account کے طور پر اور نہ root کے طور پر۔ ہماری guides coding agents کے لیے disposable VM اور VPS پر least-privilege users setup کا احاطہ کرتی ہیں، جبکہ VPS پر Claude Code کو محفوظ طریقے سے چلانا روزمرہ استعمال کا طریقہ بیان کرتی ہے۔

secrets کو environment سے باہر رکھیں

environment variable ہر child process کے لیے قابلِ مطالعہ ہوتا ہے، یعنی ہر اس command کے لیے بھی جسے agent چلاتا ہے۔ Claude Code کا sandbox ہر sandboxed command سے پہلے نامزد variables کو unset کر سکتا ہے۔ Linux پر sandbox کے لیے پہلے دو packages درکار ہیں:

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 ان hosts کو محفوظ کرتا ہے جن تک sandboxed commands پہنچ سکتی ہیں۔ credentials block کے لیے Claude Code v2.1.187 یا اس کے بعد کا version درکار ہے؛ یہ August 2026 میں چیک کیا گیا تھا۔ ایک session میں /sandbox چلائیں تاکہ معلوم ہو سکے کہ کون سی layers فعال ہیں اور کون سی dependencies missing ہیں۔ اصل کام کا بڑا حصہ یہ طے کرنا ہے کہ اس machine پر کون سے secrets کا موجود ہونا ضروری بھی ہے، اور secrets کو AI agent کی رسائی سے دور رکھنا اسی موضوع کی وضاحت کرتا ہے۔

operating system پر network egress محدود کریں

Firewall rule کو اس بات سے کوئی فرق نہیں پڑتا کہ model نے کیا فیصلہ کیا۔ agent کو dedicated 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 کی طرف point کرنے پر client ایک CONNECT request بھیجتا ہے اور proxy name lookup انجام دیتا ہے، لہذا agent کو اپنا outbound DNS (domain name system) درکار نہیں رہتا۔ sudo nft list ruleset سے کام کی تصدیق کریں، اور جب agent کسی نئی جگہ تک پہنچنے کی کوشش کرے تو drop rule کا counter بڑھتے ہوئے دیکھیں۔

Firewall changes لاگو کرتے وقت دوسری SSH session کھلی رکھیں۔ یہ بھی چیک کریں کہ آپ کا container runtime ان rules کے ساتھ کیا کرتا ہے: Docker اپنی chains خود لکھتا ہے، اور published Docker ports، ufw کو bypass کرتے ہیں اس سے پیدا ہونے والی غیر متوقع صورتِ حال بیان کرتا ہے۔

Hooks: وہ check جس سے model باتوں کے ذریعے نہیں بچ سکتا

Permission rules اور hooks کا نفاذ Claude Code کرتا ہے، model نہیں۔ Documentation میں یہ بات واضح ہے: آپ کے prompt یا CLAUDE.md کی instructions اس بات کو متاثر کرتی ہیں کہ Claude کیا کرنے کی کوشش کرتا ہے، لیکن وہ یہ نہیں بدل سکتیں کہ Claude Code کس چیز کی اجازت دیتا ہے۔ اصل قدر اسی فرق میں ہے۔ CLAUDE.md میں لکھی ہوئی "never run curl" جیسی سطر ایک suggestion ہے جس سے injected paragraph بحث کر سکتا ہے۔ Hook ایک ایسا process ہے جو exit code واپس کرتا ہے۔

.claude/settings.json میں PreToolUse hook register کریں:

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

Hook کو tool call JSON کی شکل میں standard input پر موصول ہوتی ہے۔ Exit code 2 call کو block کرتا ہے اور standard error سے reason 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 strings کی denylists میں خامیاں رہ جاتی ہیں۔ python3 -c لفظ curl استعمال کیے بغیر socket کھول دیتا ہے۔ make deploy target اسی call کو ایک مزید سطح کے اندر چھپا دیتا ہے۔ ان غلطیوں کے لیے hooks لکھیں جنہیں آپ واضح طور پر نام دے سکتے ہیں، اور جس boundary پر آپ حقیقتاً انحصار کرتے ہیں اسے kernel یا network پر نافذ کریں۔

Permission deny rules میں ایک اہم matching limit بھی ہے۔ Read اور Edit deny rules، Claude کے اپنے file tools اور Bash میں ان file commands پر لاگو ہوتے ہیں جنہیں وہ پہچانتا ہے، مثلاً cat، head، tail اور sed۔ یہ کسی Python یا Node script پر لاگو نہیں ہوتے جو خود file کھولتی ہے۔ Rules پہلے deny، پھر ask، اور آخر میں allow کے طور پر evaluate ہوتے ہیں، اس لیے deny rule میں allowlist exception شامل نہیں کی جا سکتی۔

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

باہر جانے والی چیزوں کی نگرانی کریں اور diff پڑھیں

Agent run سے ایک diff اور network calls کا ایک مجموعہ پیدا ہوتا ہے۔ کسی بھی چیز کو merge یا deploy کرنے سے پہلے دونوں کا جائزہ لینا چاہیے۔ diff پر self-hosted security review pass اس قسم کی تبدیلی پکڑتا ہے جو انسانی سرسری جائزے سے مختلف ہوتی ہے، جبکہ یہ جاننا کہ coding agent machine سے باہر کیا بھیجتا ہے آپ کو معمول کی traffic سمجھنے میں مدد دیتا ہے، تاکہ غیر معمولی request نمایاں ہو جائے۔

جو مسائل اب بھی حل طلب ہیں

آج content اور instruction کے درمیان کوئی قابلِ اعتماد علیحدگی موجود نہیں ہے۔ جاری ہونے والا ہر دفاع یا تو failure rate رکھنے والا filter ہوتا ہے یا نتائج کو محدود کرتا ہے۔ stack میں ایسی کوئی چیز موجود نہیں جو text کے کسی حصے کو data قرار دے اور یہ یقینی بنائے کہ اس پر کبھی عمل نہ کیا جائے۔

Filters مددگار بھی ہوتے ہیں اور ناکام بھی ہوتے ہیں۔ زیادہ تر injection attempts کو پکڑنے والے classifier کو ہر بار درست ہونا پڑتا ہے، جبکہ attacker کو صرف ایک بار کامیاب ہونا ہوتا ہے۔ اسی عدم توازن کی وجہ سے کسی دفاع کے لیے شائع شدہ success rate اگلی کوشش کا نقطۂ آغاز ہوتی ہے، ضمانت نہیں۔

سب سے امید افزا کام model level کے بجائے design level پر ہو رہا ہے۔ Defeating Prompt Injections by Design سے تعلق رکھنے والا CaMeL (Debenedetti اور ان کے ساتھی، 2025) پہلے trusted request سے control flow اور data flow اخذ کرتا ہے، تاکہ untrusted data program کے عمل کو تبدیل نہ کر سکے۔ اس کے بعد tools call ہونے پر capability checks نافذ کرتا ہے۔ AgentDojo benchmark پر paper کے اپنے اعداد و شمار اس کی لاگت ظاہر کرتے ہیں۔

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

بغیر دفاع والے agent نے 84 فیصد tasks حل کیے۔ CaMeL نے security guarantee کے ساتھ 77 فیصد tasks حل کیے۔ یہ ایک benchmark پر paper میں شائع شدہ اعداد و شمار ہیں، آپ کے workload کی پیمائش نہیں۔ ان دونوں کے درمیان فرق تقریباً اس لاگت کو ظاہر کرتا ہے جو آج ایک حقیقی guarantee کے لیے ادا کرنی پڑتی ہے۔

جب تک ایسا design آپ کے روزمرہ استعمال کے tools میں شامل نہیں ہو جاتا، یہ فرض کر کے منصوبہ بنائیں کہ agent کسی وقت compromised ہو سکتا ہے، اور اس واقعے کو معمولی رکھیں۔ disposable machine، محدود scope والے credentials، controlled egress اور diff پڑھنے کی عادت کی پوری وجہ یہی ہے۔

FAQ

کیا agent کو files میں موجود instructions نظرانداز کرنے کی ہدایت دے کر prompt injection روکی جا سکتی ہے؟

نہیں۔ یہ جملہ اسی context window میں موجود text ہے جس میں attack شامل ہے، اس لیے attacker کے text کے ساتھ برابر بنیاد پر مقابلہ کرتا ہے۔ Claude Code کی documentation یہ فرق واضح کرتی ہے: آپ کے prompt یا CLAUDE.md میں موجود instructions agent کے کام کا رخ متعین کرتی ہیں، لیکن یہ اس بات کو تبدیل نہیں کرتیں کہ tool کو کیا کرنے کی اجازت ہے۔ instruction file کو intent کے بیان کے طور پر سمجھیں، اور جس چیز پر آپ انحصار کرتے ہیں اسے permission rules، PreToolUse hook یا firewall rule میں رکھیں۔

اگر agent صرف میری اپنی repository استعمال کرے تو کیا prompt injection واقعی خطرہ ہے؟

ہاں، کیونکہ آپ کی repository میں بہت سا ایسا text موجود ہوتا ہے جو آپ نے خود نہیں لکھا۔ Dependency README files، lockfile URLs، test fixtures، vendored code اور npm install کا output عام task کے دوران شامل ہو جاتے ہیں۔ Issue tracker یا documentation site سے حاصل ہونے والی ہر چیز بھی اسی طرح آتی ہے۔ خطرہ اس بات کے ساتھ بڑھتا ہے کہ agent کتنا data پڑھتا ہے، اور مفید agent بہت سا data پڑھتا ہے۔

کیا agent کو container میں چلانے سے یہ مسئلہ حل ہو جاتا ہے؟

اس سے نقصان محدود ہوتا ہے، لیکن صرف اس صورت میں جب آپ credentials بھی الگ کر دیں۔ ایسا container جس میں آپ کا SSH agent forwarded ہو، environment میں cloud credentials موجود ہوں، اور network access unrestricted ہو، attacker کو تقریباً وہ سب کچھ دے دیتا ہے جو host دے سکتا ہے۔ Container کا اصل فائدہ یہ ہے کہ آپ کے پاس ایسا filesystem ہوتا ہے جسے delete کیا جا سکتا ہے، اور egress rules نافذ کرنے کے لیے صاف environment ملتا ہے۔ اسے ایک repository تک محدود token کے ساتھ استعمال کریں۔

خطرہ سب سے زیادہ کم کرنے والی واحد تبدیلی کیا ہے؟

ایسے environment سے long-lived credentials ہٹا دیں جس سے agent کے commands انہیں inherit کرتے ہیں، پھر اس machine کے لیے default-deny egress policy نافذ کریں۔ دونوں اقدامات مل کر lethal trifecta کی تیسری شرط توڑ دیتے ہیں: text اب بھی agent کو hijack کر سکتا ہے، لیکن جس data تک وہ پہنچتا ہے اسے بھیجنے کے لیے کوئی مفید راستہ نہیں رہتا۔ Approval prompts اور diff review بھی مدد دیتے ہیں، لیکن ان کے لیے ضروری ہے کہ انسان طویل run کے دوران مسلسل محتاط رہے۔ اسی لیے یہ دونوں اقدامات مذکورہ دو تبدیلیوں کے بعد آتے ہیں۔