تكامل Pillar Security مع TrueFoundry

‍يسرنا أن نعلن عن شراكتنا مع Pillar Security التي توفر ضوابط حماية تكيفية في وقت التشغيل مباشرةً إلى مسار حركة مرور وكلاء الذكاء الاصطناعي ونماذج اللغة الكبيرة (LLM).

يمكن للفرق التي توجه حركة مرور النماذج والوكلاء عبر بوابة الذكاء الاصطناعي من TrueFoundry الآن ربط Pillar Security كمزود ضوابط حماية من الدرجة الأولى للحصول على مسح في الوقت الفعلي وتطبيق للسياسات عبر المطالبات والاستجابات واستدعاءات الأدوات وتفاعلات MCP في بيئة الإنتاج. يعمل التكامل عند نقاط الربط الأربع لضوابط الحماية التي توفرها البوابة ولا يتطلب أي تغييرات على كود الوكيل أو التطبيق.

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

لماذا يحتاج الذكاء الاصطناعي الوكيلي للمؤسسات إلى طبقتين

TrueFoundry توفر طبقة التحكم لأنظمة الذكاء الاصطناعي في بيئة الإنتاج. من خلال بوابة الذكاء الاصطناعي، تقوم الفرق بمركزة توجيه النماذج وإدارة المفاتيح والتحكم في الوصول والمراقبة والحوكمة عبر نماذج اللغة الكبيرة (LLMs) والأدوات وسير العمل المتصلة بـ MCP. يمر كل طلب عبر طبقة وكيل واحدة حيث يتم التحقق من الهوية وتطبيق حدود المعدل والتقاط التتبعات.

Pillar Security توفر طبقة الأمان في وقت التشغيل. تقوم نماذج الكشف الخاصة بها بمسح المطالبات والاستجابات بحثًا عن محاولات كسر الحماية (jailbreak) وحقن المطالبات (prompt injection) وبيانات PII و PCI والأسرار واللغة السامة وهجمات الأحرف غير المرئية. تستند ضوابط الحماية التكيفية من Pillar إلى تمارين الفرق الحمراء (red teaming) التي تُجرى على نفس التطبيق وتضبط نفسها وفقًا للغرض التجاري المحدد للوكيل لتقليل الإيجابيات الخاطئة.

معًا، يوفر الحلان للفرق بنية إنتاج نظيفة. تتولى TrueFoundry النشر والتوجيه والتحكم التشغيلي. تتولى Pillar الفحص في وقت التشغيل واكتشاف التهديدات وتطبيق السياسات. يتم دعم Pillar Security كمزود ضوابط حماية من الدرجة الأولى داخل بوابة TrueFoundry مع نقاط ربط عند llm_input_guardrails و llm_output_guardrails و mcp_tool_pre_invoke_guardrails و mcp_tool_post_invoke_guardrails.

الفجوة في عمليات نشر الوكلاء في بيئة الإنتاج

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

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

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

ضوابط الحماية في وقت التشغيل على مسار البوابة

الفكرة المعمارية وراء هذا التكامل مباشرة وواضحة. إذا كانت جميع حركة مرور النماذج والأدوات و MCP تمر بالفعل عبر البوابة، فإن البوابة هي المكان الصحيح لتطبيق الأمان في وقت التشغيل. مع ربط Pillar ببوابة الذكاء الاصطناعي من TrueFoundry، يمكن للفرق فرض ضوابط الحماية على نفس المسار الذي يتم فيه توجيه حركة مرور الوكلاء وإدارتها بالفعل. يتم التقييم على حركة المرور الحية وليس على التتبعات التي تتم مراجعتها بعد التنفيذ.

يعمل Pillar Argus كطبقة تكيفية في وقت التشغيل. تطبق Pillar ماسحاتها الضوئية على كل تفاعل في بيئة الإنتاج حتى تتمكن فرق المنصة والأمان من مراقبة وتقييم وتطبيق السياسات على سلوك الوكيل أثناء حدوثه. تتضمن مخرجات الماسح الضوئي معرف جلسة وقيمة منطقية معلمة (flagged boolean) والمحفزات لكل فئة ومصفوفة أدلة تحتوي على النص المخالف وموقعه في الإدخال.

توفر Pillar فئات الكشف التالية في وقت التشغيل. اكتشاف كسر الحماية (Jailbreak) يحدد محاولات تجاوز تدريب النموذج على السلامة. حقن الأوامر يغطي الكشف عن الحقن المباشر وغير المباشر من خلال السياق المسترجع أو مخرجات الأداة. الكشف عن معلومات التعريف الشخصية (PII) وبيانات بطاقات الدفع (PCI) يغطي أكثر من أربعين فئة من البيانات الشخصية وبيانات بطاقات الدفع ويدعم إخفاءها قبل وصول البيانات إلى النموذج. الكشف عن الأسرار يحدد مفاتيح ورموز واجهات برمجة التطبيقات (API) وبيانات الاعتماد في الأوامر أو مخرجات النموذج. الإشراف على المحتوى و اللغة المسيئة يغطي الكشف عن المحتوى غير الآمن والمخالف للسياسات. الأحرف غير المرئية يكتشف الكشف عن الأحرف غير المرئية حمولات يونيكود المخفية المستخدمة لتهريب التعليمات لتجاوز المراجعة البشرية.

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

كيف تنفذ البوابة الحواجز الوقائية

تعمل بوابة TrueFoundry AI على إطار عمل Hono، وتتعامل وحدة بوابة واحدة مع أكثر من 250 طلبًا في الثانية على 1 vCPU و1 جيجابايت من ذاكرة الوصول العشوائي مع زمن انتقال إضافي يبلغ حوالي 3 مللي ثانية. وحدات البوابة عديمة الحالة ومحدودة بوحدة المعالجة المركزية وتتوسع أفقيًا لتصل إلى عشرات الآلاف من الطلبات في الثانية من خلال وحدات إضافية. يتم فصل مستوى التحكم ومستوى البوابة. تعيش التكوينات بما في ذلك قواعد الحواجز الوقائية وتعريفات النموذج وحدود المعدل في مستوى التحكم وتتم مزامنتها مع وحدات البوابة عبر NATS. يبقى مسار الطلب الفعلي في الذاكرة دون أي استدعاءات خارجية تتجاوز مزود LLM.

يتم تنفيذ الحواجز الوقائية عند أربع نقاط ربط منفصلة في دورة حياة الطلب.

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

llm_output_guardrails يتم تفعيلها بعد استجابة نموذج اللغة الكبير (LLM) ولكن قبل إرجاع الاستجابة إلى المتصل. تعمل حواجز الإخراج بشكل تسلسلي. ينتظر الموزع (gateway) مخرجات النموذج ويرسلها إلى Pillar للفحص قبل تسليمها للعميل. هذه هي نقطة التنفيذ لاكتشاف تسرب معلومات التعريف الشخصية (PII) وكشف الأسرار والتوليد السام وأي محتوى غير آمن ينتجه النموذج.

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

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

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

واجهة التكامل

يتم تكوين Pillar في لوحة تحكم TrueFoundry كتكامل حاجز بمدخلين. الأول هو مفتاح API الصادر عن وحدة تحكم Pillar. والثاني هو تكوين الماسح الضوئي الذي يحدد فئات الكشف التي يجب تشغيلها لهذا التكامل.

بمجرد تسجيل التكامل، تعرضه البوابة كمحدد يمكن الإشارة إليه من أي قاعدة حماية. يتم تكوين القواعد عبر كتلة قواعد YAML. تستخدم كل قاعدة كتلة "when" بشرطين. الهدف تتطابق مع النموذج أو خوادم MCP أو أدوات MCP أو بيانات تعريف الطلب. الموضوعات تتطابق مع هوية المستخدم أو الفريق باستخدام عوامل التشغيل "in" و "not_in". ثم تحدد القاعدة أي تكاملات حماية سيتم تشغيلها على أي من نقاط الربط الأربع.

قاعدة أساسية تشغل Pillar على المدخلات والمخرجات لنموذج OpenAI تستخدمه جميع الفرق تبدو كالتالي.‍

name: guardrails-control
type: gateway-guardrails-config
rules:
  - id: pillar-baseline
    when:
      target:
        operator: or
        conditions:
          model:
            values:
              - openai-main/gpt-4o
            condition: in
      subjects:
        operator: and
        conditions:
          in:
            - team:everyone
    llm_input_guardrails:
      - pillar/pillar-default-profile
    llm_output_guardrails:
      - pillar/pillar-default-profile
    mcp_tool_pre_invoke_guardrails: []
    mcp_tool_post_invoke_guardrails: []

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

يتم دعم التجاوزات لكل طلب عبر X-TFY-GUARDRAILS الرأس. يحمل الرأس كائن JSON يحدد محددات الحماية لأي مجموعة من نقاط الربط الأربع. يتيح هذا لفرق التطوير تثبيت سياسة أكثر صرامة أو تساهلاً لمكالمة معينة دون تعديل التكوين العام.

يتم التقاط كل قرار حماية في تتبع الطلب. يتضمن النطاق نقطة الربط التي تم تشغيلها ومحدد التكامل والحكم وزمن استجابة استدعاء الحماية والأدلة التي أعادتها Pillar. يتم إصدار التتبعات بشكل غير متزامن عبر NATS وتصديرها عبر OTEL إلى أي واجهة خلفية للمراقبة قام الفريق بتكوينها. تعرض لوحة تحكم Pillar نفس الأحداث من جانبها مع نصوص هجوم كاملة وتصنيفات مفصلة لمراجعة الامتثال.

ملخص البنية

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

لا يلزم تغيير أي شيء آخر في التطبيق. لا يوجد SDK لتثبيته على العميل ولا حاوية جانبية (sidecar) لنشرها بجانب الوكيل ولا برمجيات وسيطة أمنية لكل خدمة للصيانة. البوابة موجودة بالفعل في مسار الطلب وتتصل Pillar بهذا المسار عبر واجهة برمجة التطبيقات الخاصة بها. تستمر تعليمات العميل البرمجية المتوافقة مع OpenAI في العمل دون تعديل.

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

ابدأ الآن

تعرف على المزيد حول الـ بوابة TrueFoundry للذكاء الاصطناعي و منصة Pillar Security. قم بتوصيل Pillar في إعدادات ضوابط TrueFoundry، وأشر إلى محدد التكامل من أي قاعدة تستهدف نماذجك أو خوادم MCP.