حقن التعليمات ضد الوكلاء البرمجيين: الأسطح والدفاعات

ما هو حقن التعليمات الموجّه ضد وكيل برمجي

من السهل تعريف حقن التعليمات الموجّه ضد وكيل برمجي: يتعامل الوكيل مع النص الذي يقرؤه على أنّه تعليمة وينفّذها. قد يفتح الوكيل ملفاً، أو تعليقاً على طلب دمج، أو صفحة ويب، أو نتيجة استدعاء أداة. تصل كل هذه العناصر إلى الوكيل على هيئة النوع نفسه من النص الذي يتكوّن منه طلبك. إذا كان المهاجم يتحكم في أي من هذه النصوص، فهو يكتب داخل جلستك.

تتصف كل منتجات الوكلاء الحالية بهذه الخاصية. يتلقى النموذج تسلسلاً واحداً من الرموز. يُدمج طلبك، وsystem prompt، ومحتوى الملفات، ونتائج الأدوات، ثم يتنبأ النموذج بما سيأتي بعد ذلك. لا توجد بتّات صلاحيات مرتبطة بالرمز. ولا يوضّح التنسيق أي جزء فوّضته وأي جزء جاء من ملف README يملكه شخص غريب.

تشرح هذه الصفحة نموذج التهديد: كيف يصل النص الذي يتحكم فيه المهاجم إلى وكيل يعمل على خادم، وما الذي يكسبه المهاجم عند كل نقطة، وأي وسائل دفاع تستحق الجهد. لا تصبح إرشادات الاحتواء في أدلتنا الأخرى مفهومة إلا بعد معرفة الشيء الذي تمنع الوكيل من الوصول إليه.

لماذا لا يستطيع النموذج فصل المحتوى عن التعليمات

يساعد التدريب، لكنه لا يحسم المشكلة. تُدرَّب النماذج الحالية على التعامل مع النص المسترجَع بحذر، وترفض كثيراً من المحاولات البدائية. الرفض احتمال، وليس قاعدة. يستطيع المهاجم إعادة الصياغة والمحاولة مرة أخرى وإخفاء النص في تنسيق لم يخطط له أحد، ولا يوجد ما يحدّ من عدد الصياغات التي يمكنه تجربتها.

يتتبع مشروع OWASP GenAI هذه المشكلة تحت عنوان LLM01:2025 Prompt Injection، ويقسمها إلى نوعين. الحقن المباشر هو تغيير مطالبة المستخدم لسلوك النموذج. أما الحقن غير المباشر فهو تغيير محتوى خارجي، مثل موقع ويب أو ملف، لسلوك النموذج عند معالجته لذلك المحتوى. والحقن غير المباشر هو النوع المهم على الخادم، لأن الوكيل يقرأ نصاً يفوق بكثير ما تكتبه له.

الدراسة المنهجية الأولى هي دراسة Greshake وزملائه، ليس ما اشتركت فيه (2023). والاستنتاج الذي يجب الاحتفاظ به هو الآتي: عندما يمرر تطبيق نصاً مسترجعاً إلى نموذج يستطيع استدعاء الأدوات، تصبح معالجة ذلك النص قريبة من تنفيذ تعليمات برمجية عشوائية.

الشرط الذي يحوّل القراءة إلى اختراق

قراءة نص عدائي لا تُحدث ضرراً بحد ذاتها. يجب أن يوجد مسار يخرج عبره الضرر من الجهاز.

سمّى Simon Willison هذا الجمع الثلاثي القاتل في June 2025. يمكن إقناع وكيل يحتفظ ببيانات خاصة، ويتعرّض لمحتوى غير موثوق، ويستطيع إرسال البيانات إلى الخارج، بإخراج البيانات الخاصة عبر قناة الإرسال الثالثة.

يمتلك وكيل برمجي على VPS لديك كل هذه الشروط منذ اليوم الأول. تشمل البيانات الخاصة شفرتك المصدرية، وملف .env، ومفاتيح SSH، وسجل shell. ويشمل المحتوى غير الموثوق كل مستودع وصفحة ونتيجة أداة يقرأها. أما مسار الخروج فيتمثل في git push أو curl أو npm publish أو نص طلب السحب، أو رابط يطبعه الطرفية ثم تنقر عليه.

لا يمكنك إزالة الشرط الثاني، لأن قراءة النص غير الموثوق هي المهمة التي وظّفت الوكيل لأدائها. لذلك يركّز كل دفاع عملي على الشرطين الآخرين.

عندما يصل نص غير موثوق به إلى وكيل برمجي على خادم

المستودع الذي يعمل فيه الوكيل

كل ملف في نسخة checkout هو مدخلات. ويشمل ذلك تعليقات المصدر، وREADME.md، وسجلات التغييرات، وتجهيزات الاختبار، والتعليمات البرمجية المضمّنة من جهات خارجية، وملفات تعليمات الوكيل نفسها: CLAUDE.md وAGENTS.md وما يعادلها. يقرأها الوكيل عندما تطلب منه فهم قاعدة التعليمات البرمجية، فهذا هو المطلوب منه.

ما يكسبه المهاجم هنا هو الوصول إلى كل من يستنسخ المستودع ويوجّه وكيلاً إليه. وتُعد ملفات التعليمات المسار الأكثر مباشرة، لأنها موجودة أصلاً لكي تُقرأ كتعليمات. وقد يكون طلب السحب الذي يضيف أربعة أسطر مفيدة إلى CLAUDE.md وسطرًا واحدًا يعيد توجيه الوكيل تغييرًا يتجاوزه المراجع البشري سريعًا.

Issues وطلبات السحب وتعليقات مراجعة التعليمات البرمجية

أي شيء يستطيع شخص غريب كتابته في نظام تتبّع المشكلات يصل إلى الوكيل فور أن تطلب منه فرز المشكلات. في May 2025، نشرت Invariant Labs نتيجة بحث حول GitHub MCP بهذا الشكل تحديداً. كان لدى وكيل أحد المطورين وصول إلى مستودع عام ومستودعات خاصة. أنشأ مهاجم مشكلة في المستودع العام. وعندما طلب المطور من الوكيل مراجعة المشكلات المفتوحة، قرأ الوكيل محتويات المستودع الخاص وكتبها في طلب سحب في الجانب العام.

يصف ذلك التقرير مشكلة معمارية، لا عيباً برمجياً في خادم MCP. كان لدى الوكيل رمز وصول واسع الصلاحيات، ويقرأ من صندوق وارد عام، ويملك صلاحية الكتابة. لم يكن هناك إعداد خاطئ بالمعنى المعتاد، ولذلك يكمن الحل في تحديد نطاق الصلاحيات، لا في تطبيق تصحيح.

صفحات الويب التي يجلبها الوكيل

التوثيق، وإجابات المنتديات، وصفحة مورّد، ونتيجة بحث. يمكن لأي منها أن يحتوي على نص كُتب للوكيل لا لك. ويمنح تحويل HTML إلى نص مساحة إضافية للمهاجم، لأن المحتوى الذي لا يعرضه المتصفح مطلقاً قد يصل إلى النموذج.

يكسب المهاجم السيطرة في اللحظة التي يكون فيها الوكيل أقل خضوعاً للمراقبة. فلا أحد يقرأ النص الكامل لصفحة جلبها الوكيل أثناء البحث عن معلومة.

مخرجات أدوات MCP

يُعد MCP (بروتوكول سياق النموذج) الطريقة الشائعة لربط الوكلاء بالأدوات الخارجية. وتعود النتائج على شكل نص وتدخل مباشرةً في نافذة السياق. توجد هنا نقطتا تعرض، لا نقطة واحدة. البيانات التي تعيدها الأداة هي النقطة الواضحة. أما النقطة الأخرى فهي اسم الأداة ووصفها، اللذان يقرأهما النموذج ليقرر متى يستدعيها. ويمكن لخادم لا تتحكم فيه تغيير أي منهما بين الاستدعاءات.

يصل المهاجم الذي يضع نصاً في مخرجات إحدى الأدوات إلى كل أداة أخرى يملكها الوكيل. وهكذا يمكن لحقن في أداة منخفضة القيمة أن يقود أداة عالية القيمة.

سجلات CI ومخرجات البناء وبيانات تبعيات الحزم

تطبع npm install نصاً من حزم لم تكتبها. وتطبع نتيجة اختبار رسالة تأكيد من مكتبة. كما يحتوي سجل مهمة التكامل المستمر (CI) على آلاف الأسطر من مخرجات جهات خارجية. وعندما تطلب من وكيل إصلاح بناء فاشل، فإنه يقرأ كل ذلك.

يكسب المهاجم هنا جهاز البناء، الذي يحتوي عادةً على بيانات اعتماد النشر ورموز الوصول إلى السجل، ويحظى باهتمام أقل من جهاز الحاسوب المحمول.

ما الذي يحصل عليه المهاجم فعلياً

هناك أربع نتائج تستحق التخطيط لها.

سرقة بيانات الاعتماد. كل ما يستطيع إجراء الوكيل قراءته يدخل في نطاق الخطر: متغيرات البيئة، ~/.aws/credentials، ~/.ssh، رمز gh، أو ملف إعداد Docker. ولا تحتاج عملية إخراجها إلى curl. فإجراء commit إلى فرع، أو كتابة وصف pull request، أو نشر حزمة في registry، أو تنفيذ بحث DNS عن اسم يسيطر عليه المهاجم، كلها طرق لنقل البيانات خارج الخادم.

تغييرات توافق عليها في التعليمات البرمجية. كتابة التعليمات البرمجية هي مهمة الوكيل، لذلك فإن دفعه إلى كتابة سطر خاطئ بصورة خفية هو أسهل نتيجة يمكن الوصول إليها. قد يكون ذلك اعتماداً إضافياً، أو استدعاءً للتسجيل ينقل رمزاً إلى سجل ترسله إلى مكان آخر.

الاستمرارية. يظل الملف الذي كُتب مرة واحدة فعالاً من دون تدخل النموذج: hook في .git/hooks، أو برنامج نصي postinstall في package.json، أو سطر يُضاف إلى ملف بدء shell، أو سطر إضافي في CLAUDE.md. وينفّذه الأمر التالي.

الانتقال داخل شبكتك. يعمل الوكيل في المكان الذي تشغّله فيه. فإذا كان ذلك الخادم يستطيع الوصول إلى قاعدة بيانات عبر loopback، أو خدمة إدارة داخلية، أو خدمة metadata لدى مزود السحابة، أو خادم آخر على الشبكة الخاصة، فكل ما يتحكم في الوكيل يستطيع الوصول إليها أيضاً.

تزيل أوضاع الموافقة التلقائية آخر فحص

في الوضع الافتراضي، يطلب Claude Code الإذن قبل تنفيذ أمر أو تعديل ملف. تمثل تلك المطالبة الفحص البشري الذي يفصل بين كل نقطة تعرّض مذكورة أعلاه وتنفيذ فعلي. وتزيل الأوضاع التي تلغي المطالبة هذا الفحص.

توضح الوثائق بشأن bypassPermissions ما يلي: استخدمه فقط في بيئات معزولة، مثل الحاويات أو الأجهزة الافتراضية، حيث لا يستطيع Claude Code التسبب في ضرر. الوضع التلقائي أقل تشدداً، ويوافق تلقائياً على استدعاءات الأدوات مع إجراء فحوصات أمان في الخلفية تتحقق من توافق الإجراءات مع طلبك. تلتقط هذه الفحوصات كثيراً من المشكلات. لكنها تظل أحكاماً يصدرها النموذج بشأن مخرجات النموذج، لذلك تعامل معها كمرشح، لا كحد أمان.

يمكن للمسؤول إزالة كليهما. عيّن permissions.disableBypassPermissionsMode أو permissions.disableAutoMode إلى "disable" في ملف إعدادات، ثم ضع هذا الملف ضمن الإعدادات المُدارة حتى لا يتمكن مشروع تم سحبه من مستودع من تجاوزها. يوضح دليلنا حول الوضع التلقائي في Claude Code وقواعد الأذونات موضع تطبيق كل قاعدة.

وسائل الحماية مرتبة حسب ما توفره لك

لا تُعدّ أي من هذه الوسائل إصلاحاً بحد ذاتها. كل وسيلة منها تضيّق ما يحتفظ به الوكيل أو ما يمكنه فعله به.

1. جهاز يمكنك إتلافه وإعادة بنائه، بحيث لا يكلفك الاختراق سوى ساعة بدلاً من حادث أمني.
2. بيانات اعتماد منفصلة عن بياناتك، ومحددة لمستودع واحد، وقصيرة العمر.
3. عدم وجود أسرار طويلة العمر في البيئة التي ترثها أوامر الوكيل.
4. فرض قيود من نظام التشغيل على الاتصالات الصادرة والوصول إلى الملفات، وتطبيقها على كل عملية يبدأها الوكيل.
5. إبقاء مطالبات الموافقة مفعّلة لعمليات الكتابة والاتصالات الشبكية.
6. استخدام الخطافات كإجراء احتياطي حتمي للإجراءات المحددة التي يمكنك تسميتها.
7. قراءة الفرق قبل دمجه.

الترتيب مهم. تظل البنود من 1 إلى 4 فعالة حتى عندما يكون النموذج تحت سيطرة مهاجم بالكامل. أما البنود من 5 إلى 7 فتعتمد على انتباه شخص، وهذا تحديداً ما يتوقف عن الحدوث أثناء تشغيل الوكيل لفترة طويلة.

ضع الوكيل على جهاز يمكنك التخلص منه

تُعد VPS تحتوي على نسخة عمل وtoken واحد محدد النطاق جائزة أصغر بكثير من حاسوب محمول يحتوي على مفاتيحك. شغّل الوكيل كمستخدم غير مميز مستقل، وليس بحساب تسجيل دخولك ولا بحساب root. تغطي أدلتنا حول آلة افتراضية مؤقتة لوكلاء البرمجة والمستخدمين ذوي أقل قدر من الامتيازات على VPS الإعداد، بينما يغطي تشغيل Claude Code بأمان على VPS طريقة الاستخدام اليومية.

أخرج الأسرار من البيئة

يمكن لكل عملية فرعية قراءة متغير البيئة، ما يعني أن كل أمر يشغله الوكيل يستطيع قراءته أيضاً. يمكن لـClaude Code sandbox إلغاء تعيين متغيرات محددة بالاسم قبل كل أمر يعمل داخل sandbox. في Linux، يحتاج sandbox أولاً إلى حزمتين:

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 تعيين ذلك المتغير قبل تشغيل كل أمر داخل sandbox، بينما يحتوي allowedDomains على المضيفين المسموح للأوامر داخل sandbox بالاتصال بهم. تتطلب كتلة credentials الإصدار 2.1.187 من Claude Code أو إصداراً أحدث، وفقاً للتحقق في August 2026. شغّل /sandbox في جلسة لمعرفة الطبقات النشطة والاعتماديات المفقودة. تحديد الأسرار التي يجب أن تكون موجودة على ذلك الجهاز أصلاً هو النصف الأكبر من المهمة، ويتناول إبعاد الأسرار عن متناول وكيل ذكاء اصطناعي هذا الأمر بالتفصيل.

اقطع الاتصالات الصادرة على مستوى نظام التشغيل

لا تكترث قاعدة الجدار الناري لما قرره النموذج. شغّل الوكيل كمستخدم agent مخصص، ثم أسقط ما يرسله ذلك المستخدم:

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 مع loopback فقط، ولذلك يجب أن تمر اتصالاته عبر proxy تشغّله على الجهاز نفسه، بينما يحتفظ proxy بقائمة المضيفين المسموح بهم. عند توجيه https_proxy إلى ذلك proxy، يرسل العميل طلب CONNECT وينفذ proxy عملية البحث عن الاسم، ولذلك لا يحتاج الوكيل إلى DNS صادر خاص به. تحقق من عملك باستخدام sudo nft list ruleset وراقب ارتفاع العداد في قاعدة الإسقاط بينما يحاول الوكيل الوصول إلى شيء جديد.

أبقِ جلسة SSH ثانية مفتوحة أثناء تطبيق تغييرات الجدار الناري. تحقق أيضاً من كيفية تعامل بيئة تشغيل الحاويات لديك مع هذه القواعد: إذ ينشئ Docker سلاسله الخاصة، ويصف تجاوز منافذ Docker المنشورة لـufw المفاجأة الناتجة عن ذلك.

الخطافات: الفحص الذي لا يستطيع النموذج التحايل عليه

يفرض Claude Code قواعد الأذونات والخطافات، وليس النموذج. توضح الوثائق ذلك صراحة: تؤثر التعليمات في مطالبتك أو CLAUDE.md في ما يحاول Claude فعله، لكنها لا تغيّر ما يسمح به Claude Code. هذه التفرقة هي القيمة الأساسية هنا. السطر الموجود في CLAUDE.md والذي يقول "لا تشغّل curl أبداً" مجرد اقتراح يمكن لفقرة محقونة أن تجادله. أما الخطاف فهو عملية تُرجع رمز خروج.

سجّل خطاف PreToolUse في .claude/settings.json:

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

يتلقى الخطاف استدعاء الأداة بتنسيق JSON عبر الإدخال القياسي. يمنع رمز الخروج 2 الاستدعاء ويعرض لـClaude السبب الوارد من خطأ الإخراج القياسي. ويسمح رمز الخروج 0 بمتابعة الاستدعاء عبر مسار الأذونات المعتاد.

#!/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، وقوائم الحظر المبنية على سلاسل shell قابلة للتجاوز. يمكن لـpython3 -c فتح socket من دون استخدام الكلمة curl. ويمكن لهدف make deploy إخفاء الاستدعاء نفسه في مستوى أعمق. اكتب خطافات للأخطاء التي يمكنك تسميتها، وضع الحد الذي تعتمد عليه فعلياً في النواة أو على الشبكة.

تتضمن قواعد حظر الأذونات حداً في المطابقة تجدر معرفته. تغطي قواعد الحظر Read وEdit أدوات الملفات الخاصة بـClaude وأوامر الملفات التي يتعرف إليها في Bash، مثل cat وhead وtail وsed. لكنها لا تغطي نصاً برمجياً في Python أو Node يفتح الملف بنفسه. تُقيَّم القواعد بهذا الترتيب: الحظر أولاً، ثم السؤال، ثم السماح؛ لذلك لا يمكن لقاعدة الحظر أن تتضمن استثناءً ضمن قائمة سماح.

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

راقب ما يخرج واقرأ الفرق

ينتج تشغيل الوكيل فرقاً ومجموعة من الاتصالات الشبكية. يستحق كلاهما المراجعة قبل دمج أي شيء أو نشره. تكشف مراجعة أمنية ذاتية الاستضافة للفرق فئة مختلفة من التغييرات مقارنة بقراءة بشرية سريعة، بينما يوضح معرفة ما يرسله وكيل البرمجة خارج الجهاز شكل حركة المرور المعتادة، بحيث يبرز أي طلب غير مألوف.

ما يزال دون حل

لا يوجد اليوم فصل موثوق بين المحتوى والتعليمات. كل وسيلة دفاع تصدر إما مرشحاً بمعدل فشل، أو حداً من حدود العواقب. لا يوجد في المكدس ما يحدد نطاقاً من النص على أنه بيانات يجب عدم تنفيذها مطلقاً.

تساعد المرشحات، لكنها تفشل أيضاً. وحتى المصنّف الذي يكتشف معظم محاولات الحقن يجب أن يصيب في كل مرة، بينما يكفي المهاجم أن يصيب مرة واحدة. لذلك فإن معدل النجاح المنشور لوسيلة دفاع يمثل نقطة بداية للمحاولة التالية، وليس ضماناً.

يتركّز العمل الأكثر وعداً على مستوى التصميم، لا على مستوى النموذج. تستخرج CaMeL، الواردة في إحباط حقن التعليمات بالتصميم (Debenedetti وزملاؤه، 2025)، مسار التحكم ومسار البيانات من الطلب الموثوق أولاً، بحيث لا تستطيع البيانات غير الموثوقة تغيير ما يفعله البرنامج، ثم تفرض عمليات تحقق من القدرات عند استدعاء الأدوات. وتوضح الأرقام التي نشرتها الورقة نفسها على معيار AgentDojo تكلفة ذلك.

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

حلّ الوكيل غير المحمي 84 بالمئة من المهام. وحلّت CaMeL 77 بالمئة مع إرفاق ضمان أمني. هذه أرقام منشورة في الورقة على معيار واحد، وليست قياساً لأعباء العمل لديك. والفجوة بينهما تمثل تقريباً تكلفة الضمان الفعلي اليوم.

إلى أن يتوفر تصميم من هذا النوع في الأدوات التي تستخدمها يومياً، افترض أن الوكيل سيتعرض للاختراق في مرحلة ما، واجعل هذا الحدث قليل الأثر. هذا هو السبب الكامل لاستخدام جهاز يمكن التخلص منه، وبيانات اعتماد محددة النطاق، واتصالات صادرة مضبوطة، وعادة مراجعة diff.

FAQ

هل يمكنني إيقاف حقن التعليمات بإخبار الوكيل بتجاهل التعليمات الموجودة في الملفات؟

لا. هذه الجملة نص موجود في نافذة السياق نفسها التي يوجد فيها الهجوم، ولذلك تنافس نص المهاجم بشروط متساوية. توضّح وثائق Claude Code الحد الفاصل بوضوح: التعليمات الموجودة في مطالبتك أو CLAUDE.md تحدد ما يحاول الوكيل فعله، لكنها لا تغيّر ما تسمح به الأداة. تعامل مع ملف التعليمات باعتباره بياناً للغرض، وضع كل ما تعتمد عليه في قواعد الصلاحيات أو في hook من نوع PreToolUse أو في قاعدة جدار ناري.

هل يُعدّ حقن التعليمات خطراً حقيقياً إذا كان الوكيل يتعامل فقط مع المستودع الخاص بي؟

نعم، لأن المستودع مليء بنصوص لم تكتبها أنت. تصل ملفات README الخاصة بالتبعيات، وعناوين URL في lockfile، وملفات الاختبار، والشفرة المضمّنة، ومخرجات npm install أثناء المهمة العادية. وأي محتوى يُجلب من متعقّب المشكلات أو من موقع توثيق يصل بالطريقة نفسها. يزداد الخطر كلما قرأ الوكيل أكثر، والوكيل المفيد يقرأ كثيراً.

هل يحل تشغيل الوكيل داخل حاوية هذه المشكلة؟

إنه يحدّ من الضرر، ولكن فقط إذا أزلت بيانات الاعتماد أيضاً. فالحاوية التي تمرّر إليها SSH agent، وتضع بيانات اعتماد السحابة في البيئة، وتمنحها وصولاً غير مقيّد إلى الشبكة، تسلّم المهاجم كل ما يحتاج إليه تقريباً من المضيف. الفائدة الحقيقية للحاوية هي توفير نظام ملفات يمكنك حذفه، ومكان نظيف لفرض قواعد حركة الخروج من الشبكة. اقرن ذلك برمز مميّز مقيّد بمستودع واحد.

ما التغيير الوحيد الذي يقلل الخطر بأكبر قدر؟

أزل بيانات الاعتماد طويلة الأجل من البيئة التي ترثها أوامر الوكيل، ثم طبّق على ذلك الجهاز سياسة افتراضية تمنع حركة الخروج من الشبكة. يكسر هذان الإجراءان معاً الشرط الثالث في الثلاثية الخطرة: لا يزال بإمكان النص اختطاف الوكيل، لكن البيانات التي يصل إليها لا تجد منفذاً مفيداً. تساعد مطالبات الموافقة ومراجعة الفروقات أيضاً، لكنها تعتمد على بقاء شخص يقظاً طوال تشغيل طويل، ولذلك تأتي في المرتبة التالية لهذين التغييرين.