خطافات استدلال Claude: بوابة DLP لعام 2026 وثغراتها

تسمح خطافات الاستدلال (inference hooks) في Claude لمؤسسات Claude Enterprise بإرسال كل مطالبة (prompt) خاضعة للحوكمة إلى خادم أمان ذكاء اصطناعي خاص بها للحصول على قرار بالسماح أو الرفض قبل تشغيل عملية الاستدلال. أطلقت Anthropic هذه الميزة في النسخة التجريبية في 5 أغسطس 2026. وهي تقوم بفحص المطالبات ونتائج الأدوات — وليس ردود النموذج.

ملخص

طرحت Anthropic خطافات الاستدلال (inference hooks) في النسخة التجريبية لـ Claude Enterprise في 5 أغسطس 2026.¹ عندما تقوم المؤسسة بتفعيلها، تقوم Anthropic بتعليق كل طلب استدلال خاضع للحوكمة بينما تسأل خادماً يديره العميل — وتسميه Anthropic خادم أمان الذكاء الاصطناعي (AI security server) — عما إذا كان يمكن للمطلب المضي قدماً. يجيب الخادم بـ allow أو deny، والطلب المرفوض لا يصل أبداً إلى النموذج.²

الجزء المثير للاهتمام ليس في الإعلان، بل في التوثيق، الذي يتسم بصراحة غير معتادة بشأن ما لا تفعله الميزة. يوجد حدث خطاف واحد فقط اليوم، وهو prompt؛ أما فرض القيود على جانب الرد فهو "مخطط له كحدث لاحق".² القرارات لا يمكنها تنقيح النص، بل الحظر فقط. لا يتم إرسال بايتات الصور الخام أبداً، لذا لا يتم فحص لقطة شاشة لمستند سري. كما أنها لا تعمل على Amazon Bedrock أو Google Cloud، ولا يغطيها وضع الصوت.²

بالقراءة جنباً إلى جنب مع اكتشاف Anthropic بأن مستخدمي Claude Code يوافقون على 97% من مطالبات الإذن،³ يصبح الاتجاه واضحاً: القرار بشأن ما إذا كانت الخطوة التالية للوكيل (agent) مقبولة يتم نقله من الإنسان الجالس خلف لوحة المفاتيح إلى الكود — بعضه عبر مصنفات Anthropic، وبعضه عبر خادم العميل.

ما ستتعلمه

• ما هي خطافات استدلال Claude، وفقاً لمصطلحات Anthropic الخاصة
• كيف تعمل دورة قرار السماح أو الرفض، بما في ذلك قواعد مهلة الانتظار (timeout) وإعادة المحاولة
• ما الذي يتلقاه خادم أمان الذكاء الاصطناعي الخاص بك فعلياً، وما الذي لا يراه أبداً
• لماذا تعتبر نقطة خطاف نتائج الأدوات (tool-result hook) مهمة تحديداً للوكلاء و MCP
• ما الذي لا تغطيه خطافات الاستدلال، مباشرة من توثيق Anthropic الخاص
• كيف يحدد إعداد "الفشل المفتوح" (fail-open) و"الفشل المغلق" (fail-closed) تكلفة انقطاع خدمة منع تسريب البيانات (DLP)
• المشاكل التشغيلية الأكثر احتمالاً أن تتسبب في تعطل أول عملية نشر
• تناقض في وسيلة النقل بين الإعلان وتوثيق المطورين
• كيف يقارن هذا بـ DLP الخاص بـ Microsoft Purview لـ Microsoft 365 Copilot
• من هم موردو الأمن الذين نشروا عمليات تكامل (integrations)
• لماذا ينتقل قرار الموافقة بعيداً عن الإنسان، مع أرقام Anthropic الخاصة

ما هي خطافات استدلال Claude؟

خطافات الاستدلال هي ميزة في Claude Enterprise تقوم بتوجيه كل مطالبة خاضعة للحوكمة عبر خدمة HTTPS تديرها المؤسسة أو مورد الأمن الخاص بها، قبل تشغيل الاستدلال. ترسل Anthropic نص المحادثة إلى تلك الخدمة وتنتظر قرار السماح أو الرفض؛ والطلب المرفوض لا يصل أبداً إلى النموذج.²

التفصيل المعماري المهم هو مكان تنفيذ عملية التحقق. وفقاً للوثائق، "يعمل الـ hook على خوادم Anthropic، بعد خروج الطلب من العميل وقبل تشغيل النموذج"، لذا فهو "ينطبق على كل طلب خاضع للحوكمة بشكل موحد، دون الحاجة لتثبيت أو نشر أي شيء على أجهزة المستخدمين".² منشور الإعلان كان صريحاً بشأن الحالة السابقة: "حتى اليوم، كان فرض التنفيذ المدمج (native inline enforcement) مقتصرًا على الـ hooks الخاصة بجانب العميل في Claude Code".¹ تلك الـ hooks — PreToolUse وأمثالها — تعمل على جهاز المطور ويتم تكوينها لكل مستخدم على حدة.⁴ أما الـ inference hook فهو تكوين على مستوى المؤسسة لا يمكن للمستخدم إلغاء الاشتراك فيه عن طريق تعديل ملف إعدادات محلي.

يتطلب تكوينه الحصول على إذن organization:manage، وهو الإذن الذي تمتلكه أدوار Admin و Owner و Primary owner المدمجة. تذكر Anthropic أربع حالات استخدام: منع فقدان البيانات، وهو ما تسميه "أكثر عمليات النشر شيوعاً"؛ وأرشفة النصوص في الوقت الفعلي عبر خادم يسمح دائماً بالمرور؛ وتتبع بيانات المطالبات (prompt telemetry)؛ ومحركات السياسات التي تفرض قوائم السماح للنماذج، أو القيود المحددة للمشاريع، أو ضوابط ساعات العمل.²

كيف تعمل دورة قرار الحكم (verdict round trip)

يقوم المستخدم بإرسال مطالبة (prompt) عبر واجهة خاضعة للحوكمة. ترسل Anthropic طلب HTTPS POST إلى عنوان URL الذي قام المسؤول بتكوينه، محملاً بنص المحادثة. يقوم الخادم بتقييمه والرد خلال مهلة الحكم (verdict timeout) المحددة. في حالة allow، تستمر عملية الاستنتاج (inference). وفي حالة __PRESERViele__deny، يتم رفض الطلب ويرى المستخدم رسالة "محظور بواسطة السياسة" مجمعة من deny_reason الذي قدمه الخادم بالإضافة إلى رسالة ثابتة يحددها المسؤولون. يتم تسجيل كل عملية رفض في سجل نشاط المؤسسة (Activity Feed).²

قرار الحكم نفسه عبارة عن كائن JSON صغير. للسماح:

{
  "action": "allow"
}

للرفض، مع ذكر السبب الذي سيقرأه المستخدم النهائي:

{
  "action": "deny",
  "deny_reason": "This prompt appears to contain customer payment card data, which your organization's policy does not allow.",
  "reference_id": "scan_01HXPT4R9V"
}

يتم تحديد deny_reason بـ 500 حرف كحد أقصى ويتم قص القيم الأطول. أما reference_id فيتم تحديده بـ 50 حرفاً كحد أقصى، ويتم تسجيله في نشاط الامتثال inference_hooks_request_denied، ولا يظهر أبداً للمستخدم — مما يجعله مفتاح الربط بين سجلات الماسح الخاص بك وسجل التدقيق الخاص بـ Anthropic.⁵

هناك ثلاث قواعد تشغيلية مهمة:

المهلة قصيرة وقابلة للتكوين. يحدد المسؤول مهلة الحكم بين 1 و 10,000 مللي ثانية، مع قيمة افتراضية تبلغ 5,000 مللي ثانية. تغطي هذه الميزانية العملية بالكامل — الاتصال، ومصافحة TLS، والطلب والاستجابة.⁵

قاعدة إعادة المحاولة أضيق من معظم أنظمة الـ webhook. تقوم Anthropic بـ "إعادة المحاولة مرة واحدة بالضبط، بعد تأخير قدره 100 مللي ثانية، وفقط عندما تفشل محاولة الاتصال".⁵ الخادم البطيء الذي يجيب في النهاية لا يحصل على فرصة ثانية؛ وبمجرد أن يستجيب خادمك، لا يتم إعادة محاولة العملية أبداً.

الاستجابة غير الـ 200 لا تعني الرفض. الوثائق واضحة تماماً: "لا تشير إلى الرفض باستخدام حالة خطأ. الاستجابة غير الـ 200 هي فشل، وليست رفضاً".⁵ أي قيمة لـ action غير allow أو deny يتم التعامل معها بالمثل كفشل في الـ webhook، مما يحول النتيجة إلى إعدادات معالجة الفشل الخاصة بك بدلاً من ذلك.

يتم توقيع الطلبات وفقًا لمواصفات Webhooks القياسية باستخدام رؤوس webhook-id و webhook-timestamp و webhook-signature.⁵⁶ تشير وثائق Anthropic نفسها إلى الخطأ الذي تقع فيه معظم عمليات التنفيذ: سر التوقيع هو base64 بالأبجدية القياسية، لذا فإن "مفكك التشفير الآمن لـ URL يستخرج بايتات المفتاح الخاطئة كلما احتوى السر على + أو /، وهو ما يحدث في معظم الأوقات."⁵

ما يراه خادم أمن الذكاء الاصطناعي الخاص بك فعليًا

النص المنسوخ (transcript) هو المحادثة كما يراها المستخدم النهائي، وصولاً إلى نقطة الاستنتاج: النصوص، استدعاءات الأدوات ونتائجها، النصوص المستخرجة من المرفقات، والأدوار السابقة. تذكر Anthropic أنها "لا تدرج أبدًا مطالبات النظام (system prompts)، أو تعريفات الأدوات، أو السياق الداخلي لـ Anthropic، أو التفكير الخفي لـ Claude، أو بايتات الملفات الخام."⁵

إليك شكل إطار المطالبة (prompt frame)، مقتصرًا على الحقول المهمة:

{
  "type": "prompt",
  "request_id": "req_abc123",
  "tenant_id": "11111111-1111-1111-1111-111111111111",
  "actor": {
    "type": "user",
    "id": "user_01AbCdEfGhIjKlMnOpQrStUv",
    "email_address": "alice@example.com"
  },
  "source": { "application": "claude-ai" },
  "session_id": "22222222-2222-2222-2222-222222222222",
  "model": "claude-sonnet-4-5",
  "messages": [
    {
      "role": "user",
      "content": [
        { "type": "text", "text": "Summarize the attached report." },
        {
          "type": "attachment",
          "file_name": "q2-report.pdf",
          "media_type": "application/pdf",
          "size_bytes": 48213,
          "text": "Q2 revenue grew 14% quarter over quarter..."
        }
      ]
    }
  ],
  "metadata": {}
}

هناك حقلان يستحقان اهتمام كاتب السياسات. source.application هو سلسلة نصية مفتوحة، وليس enum مغلقًا — القيم المعروفة اليوم هي claude-ai و claude-code، مع استخدام config-test لاختبارات الاتصال — وتحذر Anthropic: "تعامل مع source.application كبيانات وصفية توجيهية استشارية، وليس كحدود ثقة."⁵ أما actor فهو union يتم تمييزه بناءً على type، حيث أن "user" هو القيمة الوحيدة المرسلة اليوم، لذا فإن الخادم الذي يفترض وجود عنصر بشري سيحتاج إلى مراجعة في اللحظة التي يظهر فيها نوع actor غير بشري.

إن استبعاد التفكير الخفي لـ Claude هو خيار تصميمي هادئ ولكن له عواقب كبيرة. يرى الماسح الضوئي الخاص بك ما فعله العميل — استدعاءات الأدوات ووسائطها — ولكن ليس سلسلة الأفكار التي أدت إلى ذلك. اتخذت Anthropic نفس الاستبعاد في مصنف النصوص المنسوخة لـ Claude Code، والذي يكون "أعمى عن التفكير بالتصميم" حتى لا يتمكن العميل من الجدال لتجاوز الفحص.⁷ لم يتم ذكر الدافع هنا، ولكن النتيجة هي نفسها: لا يمكن أن يكون خطاف الاستنتاج (inference hook) مراقبًا لسلسلة الأفكار.

لماذا يهم خطاف نتيجة الأداة (tool-result hook) بالنسبة للعملاء و MCP

بالنسبة لمنتج دردشة، فإن فحص المطالبات هو قصة فقدان بيانات. أما بالنسبة للعميل (agent)، فإن نقطة الخطاف الثانية هي الأكثر إثارة للاهتمام.

يذكر الإعلان أنه عندما يستدعي Claude أداة — "بما في ذلك الأدوات المتصلة عبر MCP، والمهارات، والإضافات — يتم فحص استجابة الأداة قبل إرسالها مرة أخرى إلى النموذج."¹ يوضح المخطط الانسيابي في الوثائق نفس النقطة هيكليًا: النقاط المرتبطة بالخطاف هي حيث تصل المطالبة وحيث تعود نتيجة الأداة.² من الناحية الميكانيكية، تؤدي نتيجة الأداة العائدة إلى إطلاق طلب استنتاج محكوم إضافي، لذا فإنها تصل إلى خادمك كإطار مطالبة آخر — هذه المرة مع كتل tool_use و tool_result في النص المنسوخ.

تحتوي كتل tool_result على content (المخرجات كنص، مع استبدال الأجزاء الثنائية بعلامات مكانية)، و is_error، و tool_use_id، و — بشكل مفيد — tool_name، "بحيث يمكن للسياسة أن تشترط هوية الأداة دون الحاجة إلى الرجوع إلى كتلة سابقة."⁵

هذه نقطة ربط للسياسات (policy hook) تقع بالضبط على الحدود التي يدخل منها المحتوى غير الموثوق إلى سياق العميل (agent). ومن الجدير بالذكر أن نكون دقيقين بشأن ما توفره هذه الميزة وما لا توفره. فهي لا تجعل Claude محصناً ضد عمليات الحقن (injection-proof)؛ بل تمنح الكود الخاص بك نظرة على النص الذي أعاده خادم MCP قبل أن يتصرف النموذج بناءً عليه، ويعتمد اكتشاف أي شيء تماماً على السياسة التي تكتبها. ما تغير فعلياً هو من يمكنه كتابة هذه السياسة: سابقاً، كان تنفيذ فحص نتائج الأدوات في هذا المنتج من مسؤولية Anthropic؛ أما الآن فيمكن للعميل وضع منطق الكشف الخاص به على نفس المسار. إذا كنت تتعامل مع موصلات MCP كمسار دخول غير مراقب — وعمل Anthropic الخاص بسلامة العملاء يتعامل مع مخرجات الأدوات على أنها "المكان الذي يدخل منه المحتوى العدائي إلى السياق"⁷ — فهذا هو المكان المناسب لتجهيزه تقنياً دون الاعتماد على قيام كل مطور بتكوين جهازه الخاص.

ما لا تغطيه نقاط ربط الاستدلال (inference hooks)

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

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

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

الفشل المفتوح أو الفشل المغلق: الإعداد الذي يحدد تكلفة انقطاع الخدمة

كل نقطة فحص متزامنة تضيف تبعية جديدة، والوثائق تقول ذلك بوضوح: "يضيف فرض السياسات وقت الرحلة الذهاب والإياب لخادم الأمان الخاص بـ AI إلى زمن الاستجابة لكل طلب خاضع للحوكمة في مؤسستك."⁵

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

هناك تأثير من الدرجة الثانية يجدر معرفته قبل الاختيار. فشل الـ webhook المستمر المنسوب إلى خادمك يؤدي إلى تفعيل قاطع الدائرة (circuit breaker): حيث تتوقف Anthropic عن الاتصال بالخادم تمامًا وتُطبق معالجة الفشل على كل طلب. وتكون عملية الاستعادة يدوية — حيث يجب على المسؤول إصلاح الخادم وإعادة تفعيل خيار "فرض الأحكام" (Enforce verdicts).⁵ إذا جمعت بين إعداد الفشل المفتوح وقاطع دائرة مفعل، فستحصل على مؤسسة تعتقد أنها تفرض السياسات بينما هي لا تفعل، حتى يقوم شخص ما بفحص لوحة التحكم.

ضوابط النشر التدريجي هي الحل الصحيح، وهي مرنة: حيث يراقب "وضع الظل" (shadow mode) الأحكام على حركة المرور الحية دون حظر أي شيء، وتقوم "نسبة النشر" بفحص جزء مختار من الطلبات، بينما تعفي "الاستثناءات" أدوارًا محددة تمامًا.² كما أن وضع الظل هو الطريقة الصادقة الوحيدة لتقدير تكلفة زمن الاستجابة قبل أن تؤثر على كل موظف.

العقبات التي قد تواجه أول عملية نشر

هناك أربعة تفاصيل في وثائق التكامل من السهل إغفالها ولكن اكتشافها في بيئة الإنتاج يكون مكلفًا.

حد حجم الجسم (body limit) لديك صغير جدًا على الأرجح. يتم إرسال النصوص الكاملة دون اقتطاع، بحد أقصى 10 ميجابايت. توضح Anthropic نمط الفشل: "العديد من الإعدادات الافتراضية الشائعة أصغر بكثير، بما في ذلك client_max_body_size في nginx عند 1 ميجابايت و express.json() في Express عند 100 كيلوبايت، ويُعتبر الجسم المرفوض فشلاً في الـ webhook، لذا في ظل معالجة الفشل السماح بالطلب، سيصل المطالب (prompt) كبير الحجم إلى النموذج دون فحص."⁵ إن المحادثات الأطول والأكثر احتواءً على المرفقات — وهي الأكثر عرضة لحمل بيانات خاضعة للتنظيم — هي بالضبط تلك التي يسمح بها إعداد nginx الافتراضي بالمرور.

يجب السماح بأنواع الأحداث غير المعروفة، وفقاً للمواصفات. توجه قاعدة التوافق المستقبلي الخوادم بأنه عندما يكون type على المستوى الأعلى غير معروف، يجب "إرجاع حكم بالسماح بدلاً من حالة خطأ"، لأن الخطأ يُعتبر فشلاً في الـ webhook، والفشل المستمر يؤدي إلى تفعيل قاطع الدائرة (circuit breaker).⁵ هذا تصميم بروتوكول منطقي، وله نتيجة تستحق الذكر: عندما يصل فرض القيود من جانب الاستجابة كنوع حدث جديد، فإن الخادم المكتوب وفقاً لمواصفات اليوم سيسمح بتلك الأحداث افتراضياً حتى يقوم شخص ما بتحديثه. الترقية ليست تلقائية، والفشل يكون صامتاً.

يجب أن تكون نقطة النهاية (endpoint) قابلة للوصول علنياً وخالية من عمليات إعادة التوجيه. عنوان URL يبدأ بـ https:// على المنفذ 443، ومضيف قابل للتوجيه علنياً — حيث يتم رفض نطاقات الشبكات الخاصة (private)، والـ loopback، ونطاقات الـ carrier-grade NAT عند وقت الاتصال — وشهادة موثوقة علنياً، وبدون عمليات إعادة توجيه. تصل الطلبات من 160.79.106.0/24، والتي يمكنك إضافتها للقائمة البيضاء، رغم أن Anthropic تشير إلى أن القائمة البيضاء "ليست بديلاً عن التحقق من التوقيع" لأن هذا النطاق يحمل حركة مرور أخرى صادرة من Anthropic.⁵

عقد النسخة التجريبية (beta contract) غير مستقر صراحةً. تحمل صفحة التكامل تحذيراً خاصاً بها: "قد تتغير أسماء الحقول، وأشكال الطلبات، والرؤوس (headers) قبل التوفر العام."⁵ قم بكتابة الخادم بحيث يتجاهل الحقول غير المعروفة، ومفاتيح metadata غير المعروفة، وقيم source.application الجديدة، وقيم actor.type الجديدة، وأنواع كتل المحتوى غير المعروفة — وكل هذه الأمور تطلبها الوثائق بالاسم.

تناقض واحد يستحق المعرفة حول وسيلة النقل (transport)

يصف منشور الإعلان ووثائق المطورين وسيلة النقل بشكل مختلف، كما أن منشور الإعلان يتناقض مع نفسه.

تقول المدونة "كل طلب استدلال يتم توجيهه عبر اتصال WebSocket موقع إلى خادم أمني" — ثم، بعد قسمين، تصف "بروتوكولاً مفتوحاً يعتمد على الـ webhook مع مخطط (schema) منشور".¹ أما وثائق المطورين فتصف الحالة الثانية فقط: طلب HTTPS POST لكل طلب خاضع للحوكمة، موقع وفقاً لمواصفات Standard Webhooks، مع رؤوس ثابتة تشمل User-Agent: anthropic-dlp/1، وخادم عينة يحافظ على الاتصال مفتوحاً بين الأحكام عبر HTTP/1.1 keep-alive.⁵⁶

قم بالبناء بناءً على الوثائق. فهي الصفحة التي تحدد المخطط الذي يجب عليك تنفيذه، ووصف وسيلة النقل في صفحة تسويقية ليس عقداً لواجهة برمجة التطبيقات — فموردو الأمن الذين قدموا عمليات تكامل يصفون عملية POST، وليس socket.⁸ إذا كانت ورقة البيانات التي تقيمها تبدأ بـ "WebSocket"، فهذا مؤشر بسيط على أي صفحة قرأها المورد.

كيف يقارن هذا بـ Microsoft Purview DLP لـ Copilot

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

يمتلك Microsoft Purview منذ فترة موقع سياسة لـ Microsoft 365 Copilot و Copilot Chat مخصص لـ DLP. يمكن للمسؤولين كتابة سياسات تمنع Copilot من بناء استجاباته على عناصر مصنفة كحساسة، ويمكنهم تقييد Copilot من معالجة المطالبات (prompts) التي تحتوي على معلومات حساسة، يتم مطابقتها مع أنواع المعلومات الحساسة التي توفرها Microsoft أو أنواع مخصصة.⁹ هذا الحل هو حل داخلي (first-party) ومدمج، ويسبق ظهور الـ inference hooks — لذا فإن أي شخص يحاول بيع هذا الأمر لك كشيء جديد يجب سؤاله عما يقصده بذلك بالضبط.

الفرق ليس في تطور عملية الكشف. لغة الشروط في Purview ناضجة، وتصف Palo Alto Networks تكامل الـ inference-hooks الخاص بها بأنه يعيد استخدام نفس الأساسيات التي تتوقعها من أي منتج DLP ناضج: المطابقة الدقيقة للبيانات (exact data matching)، وكشف الأنماط، والمصنفات القابلة للتدريب.⁸ الفرق يكمن في من يكتب ويقوم بتشغيل المقيم (evaluator). منطق التنفيذ في Purview موجود لدى Microsoft، ويتحدث لغة سياسات Microsoft، ويغطي منتجات Microsoft. أما الـ inference hook فيقوم بتسليم النص الخام إلى خدمة HTTPS يختارها العميل — سواء كانت محرك DLP تجاري، أو مصنف داخلي، أو مائة سطر من كود Python لم يسمع عنها أحد خارج فريق الأمن الخاص بك. النموذج الأول يطلب منك التعبير عن سياستك وفق تصنيفات المورد؛ أما الآخر فيطلب منك تشغيل خدمة إنتاجية في المسار الحرج لكل مطالبة.

من الذي نشر عمليات تكامل

يذكر الإعلان شركات Netskope و Palo Alto Networks و Proofpoint و Zscaler — ولكن اقرأ الجملة بعناية. فهي تقترح توجيه الـ inference hooks "إلى نفس الخادم الذي ترفع إليه أدواتك الأخرى تقاريرها، بما في ذلك" هؤلاء الموردون.¹ هذا تصريح حول مكان وجود بنية DLP التحتية لديك بالفعل، وليس ادعاءً بأن جميع الشركات الأربع قد شحنت عمليات تكامل في اليوم الأول.

ثلاث من الشركات الأربع فعلت ذلك. نشرت Palo Alto Networks تدوينة وتوثيقاً للمنتج لتكامل Prisma AIRS الذي يستقبل الـ hook ويعيد الحكم.⁸ ونشرت Proofpoint مقالاً يصف تكاملها الذي يطبق سياسات DLP الحالية على مطالبات Claude.¹⁰ كما نشرت Zscaler تكاملاً أيضاً.¹¹ وبالإضافة إلى الشركات الأربع المذكورة، توثق Check Point تكاملاً في دليل مسؤول Workforce AI Security الخاص بها،¹² ونشرت Akto تكاملاً أيضاً.¹³

تعتبر Netskope هي الغياب المثير للاهتمام. فقد أعلنت عن تكامل مع Claude في 21 مايو 2026، ولكن عبر Compliance API — وهو المسار الذي يتم بعد الواقعة — بدلاً من الـ inference hooks.¹⁴ تعامل مع هذه القائمة كحد أدنى وليس كإحصاء شامل. هذا ما ظهر في 11 أغسطس 2026، وأي مورد قام بالشحن بهدوء لن يظهر فيها.

لماذا ينتقل قرار الموافقة بعيداً عن العنصر البشري

الـ inference hooks هي نصف نمط. والنصف الآخر هو ما نشرته Anthropic حول التحكم الذي تعمل بجانبه.

في مارس 2026، أفاد الفريق الهندسي في Anthropic أن مستخدمي Claude Code يوافقون على 93% من مطالبات الإذن، وقاموا ببناء "الوضع التلقائي" (auto mode) — وهو مصنف يفصل في استدعاءات الأدوات بدلاً من المستخدم — خصيصاً لمعالجة "إجهاد الموافقة".⁷ وبحلول إعلان 7 أغسطس بأن الوضع التلقائي سيصبح هو الافتراضي، ارتفعت هذه النسبة إلى 97%، إلى جانب تباين حاد: يرفض المستخدمون 39% من الخطط التي يقدمها Claude للموافقة، ولكن 3% فقط من طلبات الإذن الفردية.³ الناس يدققون في الشيء الذي يبدو وكأنه قرار، ويمررون الشيء الذي يبدو وكأنه مربع حوار.

الدراسة الداعمة هي الجزء الذي يستحق الاقتباس. في تجربة محكومة شملت 1,053 مختبراً محترفاً مأجوراً، تم استبدال مطالبة إذن واحدة في منتصف الجلسة بأمر خطير بوضوح. اكتشف المراجعة البشرية ذلك في 13.6% من الحالات — 143 من أصل 1,053 — بينما اكتشف الوضع التلقائي ذلك بنسبة 89%. في مواجهة مباشرة، حظر الوضع التلقائي 800 أمر وافق عليها البشر، بينما حظر البشر 6 أوامر سمح بها الوضع التلقائي. تدهور الأداء البشري مع طول الجلسة، من حوالي 17% في البداية إلى حوالي 5% بعد خمسين مطالبة سابقة؛ بينما ظل معدل حظر المصنف ثابتاً.³

لا تدعي Anthropic أن المصنف ممتاز. ففي تقريرها الصادر في مارس، وضعت معدل السلبيات الكاذبة (false-negative rate) لـ 52 إجراءً حقيقياً مختارة تتسم بالاندفاع الزائد عند 17%، ووصفته بأنه "الرقم الصادق"، وقالت إن الوضع التلقائي "ليس بديلاً مباشراً للمراجعة البشرية الدقيقة في البنى التحتية عالية المخاطر".⁷ ويكرر منشور أغسطس هذا التحذير.³ الحجة هنا مقارنة وليست مطلقة.

لاحظ أين لا يتغير الوضع الافتراضي. يصبح الوضع التلقائي هو الافتراضي في 14 أغسطس للجلسات الجديدة في خطط Pro و Max و Team؛ ولكنه "يظل اختيارياً في الوقت الحالي في Claude Enterprise"، و Claude API، و Bedrock، ومنصة الوكلاء (Agent Platform) من Google Cloud، و Microsoft Foundry.³ هذه هي نفس نقاط الربط (hooks) التي تحكم الاستدلال السطحي. في الفئات الموجهة للمستهلكين والفرق، قامت Anthropic بتغيير الافتراضي وقدمت الحكم بنفسها. أما في فئة المؤسسات، فقد قدمت نقطة ربط وتركت للعميل إحضار نظامه الخاص.

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

ما يجب التحقق منه قبل تفعيل الميزة

• قم بتشغيل "وضع الظل" (shadow mode) لفترة كافية لرؤية توزيع زمن الاستجابة (latency) الحقيقي لحركة المرور الخاصة بك، وليس المتوسط. مهلة الحكم هي 5,000 مللي ثانية افتراضياً، وكل طلب محكوم يتطلب رحلة ذهاب وإياب.⁵
• قرر بدقة بين "الفشل المفتوح" (fail-open) مقابل "الفشل المغلق" (fail-closed)، ودوّن ذلك، وقم بإعداد تنبيهات لقاطع الدائرة (circuit breaker). قاطع دائرة مفعل مع "فشل مفتوح" يعني عدم تنفيذ السياسات بصمت.⁵

الخلاصة

تعد خطافات الاستنتاج (Inference hooks) ميزة تجريبية موثقة جيداً تقوم بشيء واحد بدقة: فهي تسمح للمؤسسات التي تستخدم Claude Enterprise بوضع الكود الخاص بها في مسار كل مطالبة (prompt) محكومة ونتيجة أداة، والحصول على إجابة ثنائية (نعم/لا) قبل تشغيل النموذج. والوثائق صريحة بشكل غير معتاد بشأن الحدود — لا يوجد فرض على جانب الاستجابة، ولا تنقيح، ولا بايتات صور، ولا Bedrock، ولا Google Cloud، ولا صوت — وهو أمر ذو قيمة للمقيم أكثر من قيمة الإعلان نفسه.

النقطة التي تستحق النقاش ليست ما إذا كانت البوابة تعمل، بل ما يحدث في الأيام التي لا تعمل فيها: ما إذا كانت مؤسستك قد اختارت "الفشل المفتوح" (fail-open) أو "الفشل المغلق" (fail-closed) عن قصد، وما إذا كان هناك من يراقب تنبيهات قاطع الدائرة (circuit breaker)، وما إذا كانت السياسة الكامنة وراء الحكم لها مسؤول. فنقطة التفتيش التي لا يقوم أحد بضبطها هي مجرد نسخة أبطأ من عدم وجود نقطة تفتيش على الإطلاق — وعلى عكس المراجع المرهق، فإن السياسة القديمة لا تترك أي أثر يدل على أنها توقفت عن الاهتمام.