AI agent کے hooks نیا supply-chain راستہ بن گئے—ساتوں نظام متاثر
3 ستمبر 2026 کو جاری HookPry تحقیق نے AI agent کے lifecycle hooks میں نیا supply-chain attack path دکھایا۔ HookPry کے اصل preprint کے مطابق 1,000 controlled تجربات میں ساتوں آزمودہ agent harnesses پر externally verified نقصان دہ اثر پیدا ہوا، جبکہ کسی ایک harness کی بلند ترین کامیابی کی شرح 92.5 فیصد تھی۔
یہ تحقیق کسی جاری حقیقی حملے یا ہر installation کے لازماً غیر محفوظ ہونے کا ثبوت نہیں۔ 4 ستمبر کی آزاد تکنیکی رپورٹ بھی واضح کرتی ہے کہ 92.5 فیصد مجموعی شرح نہیں بلکہ سب سے بلند per-harness نتیجہ ہے، اور ساتوں نظام متاثر ہونے کا مطلب controlled tests میں ہر harness پر کم از کم ایک کامیاب اثر ہے۔
1,000 تجربات نے کیا ثابت کیا
محققین نے OpenHarness، OpenClaw، Claude Code، Codex CLI، OpenCode، Hermes اور WorkBuddy کو پانچ LLM backends کے ساتھ 25 harness-backend امتزاج میں آزمایا۔ چالیس attack cases کے ہر run میں صرف hook load ہونے، subprocess شروع ہونے یا configuration بن جانے کو کامیابی نہیں مانا گیا؛ پہلے سے مقرر external oracle کو مطلوبہ host-side اثر کی تصدیق کرنا تھی۔
1,000 runs میں 770 مکمل کامیاب، 34 جزوی اور 196 ناکام رہے؛ کوئی run model کی طرف سے واضح طور پر block نہیں ہوا۔ اس طرح micro-averaged end-to-end success rate 77.0 فیصد بنی، جبکہ harnesses کا غیر وزنی macro-average 77.9 فیصد تھا۔ بلند ترین overall شرح Hermes پر 92.5 فیصد اور کم ترین Claude Code پر 52.5 فیصد رہی۔
دس آزمودہ مقاصد میں credentials جمع کرنا، data exfiltration، compute resource hijacking، command-and-control، source یا configuration tampering، tool-output manipulation، privilege escalation، persistence، evasion اور دوسرے projects تک propagation شامل تھے۔ یہ نتائج synthetic files، عارضی test environments اور مخصوص permissions سے نکلے ہیں؛ مختلف operating systems، shells، enterprise policies اور network controls پر یہی شرح فرض نہیں کی جا سکتی۔
hook model کے مشاہدے سے باہر کیوں چلتا ہے
Lifecycle hook کسی event—مثلاً session شروع ہونے، tool استعمال ہونے یا file بدلنے—کو shell command سے باندھتا ہے۔ event آنے پر harness registered binding پڑھ کر subprocess چلاتا ہے؛ LLM کو command منتخب کرنے، اس کی تشریح کرنے یا نئی منظوری دینے کی ضرورت نہیں ہوتی۔ model بعض events پیدا ہونے پر اثرانداز ہو سکتا ہے، مگر event match ہونے کے بعد command binding اور dispatch harness کے control path میں رہتے ہیں۔
اسی بنا پر chat transcript یا model refusal مکمل حفاظتی تصویر نہیں دیتے۔ host process کے پاس environment variables، filesystem اور network تک جو اختیار ہو، hook subprocess کو بھی اس کا کچھ یا پورا حصہ مل سکتا ہے؛ نتیجہ adoption، event occurrence، hook authorization اور دستیاب privileges پر منحصر رہتا ہے۔
یہ architecture صرف paper کا مفروضہ نہیں۔ Microsoft کی VS Code hooks دستاویزات کے مطابق hooks خود VS Code جیسی permissions کے ساتھ shell commands چلاتے ہیں؛ غیر معتبر configuration اور scripts کا جائزہ، least privilege اور credentials کی حفاظت ضروری ہے۔ دستاویز یہ بھی متنبہ کرتی ہے کہ agent اگر hook script بدل سکتا ہو تو اپنے لکھے ہوئے code کو اسی run میں execute کرا سکتا ہے۔
benign plugin کی update کیسے خطرہ بنتی ہے
HookPry کا threat model ایک versioned plugin سے شروع ہوتا ہے جو ابتدا میں benign ہو اور عام marketplace یا community registry کے ذریعے install ہو۔ attacker کے پاس victim machine یا repository تک براہ راست رسائی نہیں، وہ prompt یا tool result inject نہیں کرتا، installation مجبور نہیں کرتا اور sandbox escape بھی استعمال نہیں کرتا۔ اس کا اختیار plugin metadata، versioning اور lifecycle-hook configuration تک محدود ہے۔
بعد کی update اسی plugin identity کے تحت نیا hook شامل یا موجودہ binding تبدیل کرتی ہے۔ معمول کا lifecycle event آنے پر harness attacker کے منتخب command کو چلا دیتا ہے، حالاں کہ ابتدائی review کے بعد نئی command کے لیے الگ authorization نہ ہوئی ہو۔ یوں اعتماد plugin کی مستقل شناخت سے جڑا رہتا ہے، مگر executable authority versions کے درمیان بدل جاتی ہے۔
HookPry اس راستے کو تین حصوں میں بناتا ہے: Adversarial Manifest Optimization ابتدائی plugin کو قابلِ دریافت بناتی ہے، Temporal Decoupling benign installation اور hook-bearing update کو وقت میں الگ کرتی ہے، اور Least Common Interface مشترک attack intent کو ہر harness کی native event، command اور configuration شکل میں منتقل کرتا ہے۔ حملہ پھر بھی خودکار یا یقینی نہیں: plugin کا install اور update ہونا، متعلقہ event آنا اور subprocess کو مطلوبہ resources ملنا لازم ہے۔
محفوظ update policy میں کن controls کی ضرورت ہے
تحقیق اور vendor documentation کو ملا کر عملی نتیجہ یہ نکلتا ہے کہ hook JSON، manifest اور متعلقہ script کو عام settings نہیں بلکہ executable code سمجھا جائے۔ سابقہ plugin approval کو بدلی ہوئی hook authority پر خودکار طور پر منتقل کرنا اسی trust gap کو برقرار رکھتا ہے جسے HookPry نے نشانہ بنایا۔
- Version اور hash مقرر کریں: production اور developer systems پر approved plugin version، manifest اور hook configuration کا hash محفوظ کریں؛ خودکار update کے بجائے تبدیلی کے بعد دوبارہ اجازت لیں۔
- Semantic diff دکھائیں: ہر update میں event binding، command، script path، arguments، working directory، environment اور OS-specific override کا جائزہ لیا جائے۔
- Hook files کو write-protect کریں: agent اور plugin process کو hook configuration یا execute ہونے والی scripts خاموشی سے بدلنے کی اجازت نہ دیں۔
- Secrets الگ رکھیں: long-lived cloud keys، production tokens اور deployment credentials agent process کے عمومی environment میں نہ رکھیں؛ مختصر مدت اور task-specific access استعمال کریں۔
- Least privilege نافذ کریں: hooks کو محدود user، ضروری filesystem paths اور مقرر network destinations تک باندھیں؛ جہاں ممکن ہو isolated container یا sandbox استعمال کریں۔
- Runtime audit محفوظ کریں: plugin version، configuration hash، triggering event، resolved command، execution identity، exit status اور outbound connection کو ایک trace میں جوڑیں۔
Static scanning اکیلا کافی ثابت نہیں ہوا۔ paper کے 40 malicious اور 40 matched benign synthetic artifacts پر Microsoft Defender نے صفر malicious samples پکڑے، HookPolicy نے 20 اور Semgrep نے 19 پکڑے؛ تینوں کے مجموعے نے بھی 19، یعنی 47.5 فیصد malicious artifacts چھوڑ دیے۔ یہ مخصوص frozen corpus اور configurations کا نتیجہ ہے، تمام endpoint products کے بارے میں عمومی فیصلہ نہیں، مگر update authorization، isolation اور runtime monitoring کی الگ ضرورت دکھاتا ہے۔
تحقیق کی حد اور اگلا فیصلہ کن مرحلہ
HookPry اس وقت arXiv preprint ہے، peer-reviewed field study نہیں۔ marketplace adoption، حقیقی users کی installation یا update rate، مختلف enterprise policies اور future product versions اس کے 1,000-run تجربے میں شامل نہیں تھے؛ کسی بڑے پیمانے کی عملی exploitation بھی ثابت نہیں کی گئی۔
مصنفین نے ساتوں harness vendors کو نتائج responsibly disclose کرنے اور جواب کا انتظار کرنے کی بات لکھی ہے، مگر preprint میں مکمل vendor responses، patches یا ہر موجودہ version کی remediation status موجود نہیں۔ اب فیصلہ کن سوال یہ ہے کہ harnesses اور marketplaces بدلے ہوئے hooks کو الگ executable permission سمجھ کر نئی consent، signature binding اور محدود subprocess privileges نافذ کرتے ہیں یا نہیں۔ تب تک درست نتیجہ یہی ہے: controlled تجربات میں ساتوں آزمودہ نظام متاثر ہوئے، مگر حقیقی deployment کا خطرہ installation، update adoption، event اور host permissions کے مجموعے پر منحصر ہے۔
یہ بھی پڑھیں:
ہمارا نیوز لیٹر سبسکرائب کریں
ویب 3، AI اور کرپٹو کی تازہ خبریں براہ راست اپنے اِن باکس میں پائیں۔