مثال على تطبيق الحراس لروبوت المحادثة

تأمين تطبيقات الذكاء الاصطناعي باستخدام حراس Cato (تكوين نموذجي)

إجمال

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

التطبيق المستخدم طوال هذا الدليل هو TravelBot — مساعد سفريات بسيط مدعوم بالذكاء الاصطناعي. في حين أن المثال محدد، فإن المفاهيم والخطوات تنطبق على أي تطبيق ذكاء اصطناعي مخصص تبنيه وترغب في حمايته.

يغطي الدليل ثلاث مراحل:

• المرحلة 1 تُحدد الأساس: تطبيق ذكاء اصطناعي يعمل يتواصل مباشرةً مع نموذج لغة كبير (LLM)، دون وجود أي رقابة أمنية. تساعد هذه المرحلة في فهم نقطة البداية والمخاطر التي تقدمها.
• المرحلة 2 تُدخل الحارس: يتم إنشاء وإدخال حارس وكيل Cato بين التطبيق وLLM. يتم إعادة توجيه حركة المرور عبر الحارس، الذي يبدأ في تسجيل جميع التفاعلات. لا يتم تكوين أي قواعد سياسة بعد — الهدف في هذه المرحلة هو التحقق من أن التدفق لا يزال يعمل مع الحارس في المكان.
• المرحلة 3 تُفعل التنفيذ: يتم تكوين ونشر قواعد سياسة التفاعل، حيث تُعلم الحارس لمنع محاولات الخروج ورصد المحتوى المتعلق بالصحة. الآن أصبح التطبيق محمياً بالكامل.
  بنهاية هذا الدليل، ستحصل على صورة واضحة عن كيفية تأمين تطبيق ذكاء اصطناعي مخصص باستخدام حراس Cato — من اتصال مفتوح تماماً إلى تدفق عمل ذكاء اصطناعي نشط ومراقب ومحكم.

المرحلة 1 — الأساس: تطبيق الذكاء الاصطناعي الخاص بك بدون حارس

ما الذي تغطيه هذه المرحلة

قبل أن نقدم أي رقابة أمنية، من المهم أن نفهم كيف يعمل التطبيق بمفرده. تأخذك هذه المرحلة خلال الإعداد الأساسي — تطبيق دردشة مدعوم بالذكاء الاصطناعي يتواصل مباشرة مع نموذج لغة كبير (LLM). اعتبر هذا بمثابة الصورة "قبل": التطبيق متكامل الوظائف، لكنه لا يزال هناك شيء يقف بين المستخدم والنموذج.

كيف يعمل التطبيق

التطبيق عبارة عن مساعد سفر دردشة بسيط يسمى TravelBot. يتكون من ثلاثة مكونات تعمل معًا:

1. الواجهة الأمامية
هذا ما يراه ويستخدمه المستخدم — واجهة دردشة في المتصفح حيث يمكنهم كتابة الأسئلة والحصول على الردود.

2. الخلفية
هذا هو المحرك الذي يعمل وراء الكواليس. تستقبل رسالة المستخدم، تُتابع تاريخ المحادثة، وتُمرر الرسالة إلى LLM. كما يُتعامل مع الأخطاء ويُعيد الرد النموذجي إلى المستخدم. الخلفية مبنية باستخدام Flask، وهي إطار ويب خفيف الوزن.

3. اتصال LLM
هنا تكمن الذكاء. يرسل الخلفية رسالة المستخدم (مع تاريخ المحادثة) إلى نموذج لغة كبير، الذي يُنتج ردًا. في هذه المرحلة، يتواصل الخلفية مع LLM مباشرةً — لا يوجد شيء بينهما.

سيبدو التدفق كالتالي:

مستخدم (متصفح) → خلفية (Flask) → LLM → رد العودة إلى المستخدم

ملحوظة حول اللغة والإطار

تم بناء التطبيق النموذجي في هذا الدليل باستخدام Python، ويُستخدم إطار ويب خفيف الوزن يسمى Flask. Python هو اختيار شائع لتطوير تطبيقات الذكاء الاصطناعي، ولكنه ليس الخيار الوحيد بأي حال من الأحوال. تنطبق نفس المفاهيم والتدفق سواء كان التطبيق الخاص بك مبنيًا في Node.js أو Java أو Go أو أي لغة أخرى. قيمة التكوين، هيكل الطلب، وتكامل الحارس جميعها تتبع نفس المنطق — فقط يتغير السيناريو.

ملف التكوين

الوصلة بين الخلفية و LLM يتم التحكم بها بواسطة ملف يسمى config.py. يحتوي هذا الملف على ثلاث قيم حاسمة:

OPENAI_API_KEY = "sk-proj-xK92mLqP3nVwTz8YdR5eN1uJbF7cQm4HsAo6WpGi0XvCl"
BASE_URL = "https://bedrock-mantle.eu-north-1.api.aws/v1"
MODEL_ID = "amazon.nova-pro-v1:0"

• مفتاح OPENAI_API_KEY — هذا هو شهادة تثبت لمزود LLM أن تطبيقك معتمد لإجراء الطلبات.
• BASE_URL — هذه هي العنوان الذي توجه الخلفية إليه الطلبات. يشير الآن مباشرةً إلى مزود LLM.
• MODEL_ID — هذا يُعلم مزود LLM النموذج المحدد الذي سيستخدمه في إنشاء الردود.

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

ما يقوم به التطبيق مع رسالتك

عندما يرسل المستخدم رسالة، يحدث التالي خطوة بخطوة:

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

ما لم يحدث بعد

في هذه المرحلة، يكون التطبيق كامل الوظائف ولكنه غير محمي تمامًا. هذا يعني:

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

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

هذه تمامًا الفجوة التي تُعالجها المرحلة التالية.

الملخص

المرحلة 2 — إدخال الحارس

ما الذي تغطيه هذه المرحلة

في المرحلة 1، أقمنا تطبيق ذكاء اصطناعي يعمل يتواصل مباشرةً مع LLM. التطبيق يعمل، لكنه لا يوجد شيء يقف بين المستخدم والنموذج. في هذه المرحلة، نقدم حارس أمني للذكاء الاصطناعي Cato — طبقة التنفيذ التي تقع giữa التطبيق خاصتك و LLM، تفحص المرور في الوقت الحقيقي قبل وصوله إلى النموذج وقبل عودة الردود إلى المستخدم.

بنهاية هذه المرحلة، تمر جميع حركة مرور LLM، الرسائل، تعريفات الأدوات، استخدام الأدوات، إلخ، عبر Cato. تظل تجربة المستخدم متطابقة — لكن الآن يتم فحص كل تفاعل ويمكن التحكم فيه.

سيبدو التدفق المحدث كالتالي:

! Application-Proxy Mode.png{height="" width=""}

ما هو الحارس؟

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

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

الخطوة 1 — إنشاء الحارس في تطبيق إدارة Cato

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

1. من قائمة التنقل، اختر أمن الذكاء الاصطناعي > الحراس، ثم انقر على جديد.
2. أدخل اسم الحارس وصفيا. في مثالنا، نستخدم نموذج حالة الاستخدام E2E.
3. تحت حدد نوع الحارس، اختر وكيل.
4. تحت حدد خدمة الذكاء الاصطناعي، اختر نقطة نهاية مخصصة من القائمة المنسدلة. هذا الخيار يعمل مع أي نقطة نهاية متوافقة مع OpenAI، وهو ما يستخدمه تطبيقنا.
5. في حقل عنوان URL للنقطة النهاية، أدخل عنوان URL الخاص بمزود LLM الخاص بك. في مثالنا، هذه هي https://bedrock-mantle.eu-north-1.api.aws/v1. هذا هو نفس عنوان URL الذي تم تحديده سابقًا كـ BASE_URL في config.py — أنت الآن تسلم هذا العنوان للحارس بدلاً من استخدامه مباشرةً في تطبيقك.
   ملاحظة: يجب أن يتضمن عنوان URL المسار حتى، بما في ذلك، /v1.
6. تحت تكوين إعدادات الحارس، اترك مضيف الحارس مضبوطًا على سحابة Cato. هذا يعني أن الحارس يُدار ويُستضاف بواسطة Cato — لا تحتاج إلى نشر أو المحافظة على أي بنية تحتية إضافية.
7. انقر على حفظ.

ما الذي حدث للتو؟ لقد أنشأت حارسًا يعلم مكان وجود LLM الخاص بك. سوف تتصرف Cato الآن كوسيط لكل حركة المرور بين تطبيقك وLLM المختص. الحارس لا يحتوي بعد على أي قواعد سياسة — سنقوم بإضافتها في المرحلة 3. الآن نضع الاتصال ونتحقق من استمرار عمل التدفق.

الخطوة 2 — استرجاع تفاصيل اتصال الحارس

بمجرد حفظ الحارس، افتحه من صفحة الحراس وانتقل إلى صفحة الوثائق الخاصة بالحارس، التي تقدم كل ما يحتاجه تطبيقك للاتصال بالحارس بدلاً من الاتصال مباشرة بـ LLM.

سوف تجد هنا قطعتين رئيسيتين من المعلومات:

• نهاية نقطة الحارس (عنوان URL الجديد الخاص بك) - هذا هو العنوان الذي ستقوم تطبيقك بإرسال الطلبات إليه: https://api.aisec.catonetworks.com/fw/v1/proxy/openai

  • هذا يستبدل عنوان نقطة نهاية LLM في تكوينك. من هذه النقطة فصاعدًا، يتحدث تطبيقك إلى Cato، وCato يتحدث إلى LLM نيابة عنك.

• مفتاح API للحارس (مفتاح OPENAI_API_KEY الجديد الخاص بك)

  • توفر صفحة الوثائق أيضًا مفتاح API للحارس — البيانات التي يستخدمها تطبيقك للمصادقة مع الحارس. هذا يستبدل مفتاح API الخاص بـ LLM الذي كان موجودًا سابقًا في إعداداتك. يبدو كالتالي: cato-1234-abcde

ملحوظة: تقدم Cato مفتاحين API للحارس. أنت تحتاج فقط إلى واحد لإرسال الطلبات. المفتاح الثاني موجود بحيث يمكنك تدوير البيانات بأمان — يمكنك تحديث تطبيقك لاستخدام المفتاح الجديد بينما يبقى المفتاح القديم نشطًا، مما يجنب أي توقف.

مفتاح API لـ LLM

في السابق، كان مفتاح API الخاص بـ LLM يعيش في تكوين التطبيق الخاص بك. مع وجود الحارس في المكان، يتحرك هذا المفتاح إلى رؤوس الطلبات التي يرسلها التطبيق إلى الحارس — وتحديدا في رأس يسمى x-cato-provider-api-key. يستخدم الحارس ذلك للمصادقة مع LLM نيابة عن تطبيقك.

هذا في الواقع يعد تحسناً في الأمن: مفتاح API لـ LLM لم يعد مُثبتاً في ملف تكوين، ويعمل الحارس بمثابة الممر المُحكَم لهذا البيانات.

الخطوة 3 — تحديث إعدادات التطبيق

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

يعكس ملف التكوين الجديد، config_stage2.py، تفاصيل الاتصال المحدثة:

# تكوين المرحلة 2 — التوجيه من خلال حارس الوكيل الخاص بـ Cato

GUARD_API_KEY = "cato-xxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
BASE_URL = "https://api.aisec.catonetworks.com/fw/v1/proxy/openai"
MODEL_ID = "amazon.nova-pro-v1:0"
LLM_PROVIDER_API_KEY = "[SECRET_1]" # مفتاح API المزود الخاص بـ LLM — يتم تمريره إلى الحارس، وليس مباشرةً إلى LLM

SYSTEM_PROMPT = (
 "أنت TravelBot، مساعد سفريات ودود ومطلع. "
 "ساعد المستخدمين في اكتشاف الوجهات، تخطيط البرامج، اقتراح الفنادق، "
 "ومشاركة النصائح العملية للسفر. اجعل الردود موجزة وحماسية. "
 "إذا كان السؤال غير متعلق بالسفر، قم بإعادة توجيه المحادثة بلطف."
)

MAX_TOKENS = 1024

الفرق الرئيسي عن المرحلة 1:

الخطوة 4 — تحديث كود العميل

يحصل كود العميل أيضًا على نسخة المرحلة 2 المقرونة — bedrock_client_stage2.py. المنطق إلى حد كبير هو نفسه كما في المرحلة 1، مع إضافتين:

1. يتم استخدام مفتاح API للحارس من أجل التصديق مع الحارس (في رأس Authorization).
2. يتم تمرير مفتاح API لـ LLM كرأس إضافي (x-cato-provider-api-key) بحيث يمكن للحارس تمريره إلى LLM.
3. يتم تمرير معرف الجلسة كرأس (x-cato-session-id) بحيث يمكن للحارس تجميع الطلبات من نفس المحادثة معًا — هذا يترجم مباشرةً إلى session_id الذي يوجد بالفعل في منطق التطبيق.

# bedrock_client_stage2.py
from openai import OpenAI
from config_stage2 import GUARD_API_KEY, BASE_URL, MODEL_ID, LLM_PROVIDER_API_KEY, SYSTEM_PROMPT, MAX_TOKENS

class BedrockClient:
    def __init__(self):
        self._client = None

    def _get_client(self) -> OpenAI:
        if self._client is None:
            self._client = OpenAI(
                api_key=GUARD_API_KEY,
                base_url=BASE_URL,
                default_headers={
                    "x-cato-provider-api-key": LLM_PROVIDER_API_KEY,
                }
            )
        return self._client

    def invoke(self, messages: list[dict], session_id: str = "") -> str:
        all_messages = [{"role": "system", "content": SYSTEM_PROMPT}] + messages

        response = self._get_client().chat.completions.create(
            model=MODEL_ID,
            messages=all_messages,
            max_tokens=MAX_TOKENS,
            extra_headers={
                "x-cato-session-id": session_id,
            }
        )

        return response.choices[0].message.content

التحقق من التدفق

بمجرد وضع ملفات التكوين والعميل المُحدثة في مكانها، يجب أن يتصرف التطبيق تمامًا كما فعل في المرحلة 1 من منظور المستخدم. يستجيب TravelBot لأسئلة السفر بنفس الطريقة — ولكن الآن يتم تمرير كل تفاعل من خلال الحارس.

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

هذا يؤكد أن التكامل يعمل بشكل صحيح وأن الحارس يتلقى حركة المرور.

ملخص التغييرات من المرحلة 1 إلى المرحلة 2

المرحلة 3 — تكوين قواعد السياسة

ما الذي تغطيه هذه المرحلة

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

بحلول نهاية هذه المرحلة، سيكون الحارس فعالاً في تطبيق قاعدتين ضد حركة مرور حية:

• حظر وإخفاء أي تفاعل يشمل معلومات مثل PII أو كلمات المرور
• مراقبة أي تفاعل يشمل النصيحة الطبية أو البيانات المتعلقة بالصحة

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

ما هي سياسة تفاعل الحراس؟

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

تحدد كل قاعدة في السياسة:

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

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

الخطوة 1 — إنشاء قاعدة 1: حظر محاولات كسر الحماية

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

للبدء، انتقل إلى صفحة سياسة الحراس. يمكنك القيام بذلك إما من خلال القائمة الرئيسية بالتنقل باختيار AI Security > Guards Interaction Policy أو مباشرة من صفحة Overview الخاصة بالحارس بالنقر فوق إدارة السياسة ضمن قسم القواعد النشطة.

من صفحة سياسة الحراس، انقر فوق جديد لفتح محرر القواعد، ثم قم بتكوين ما يلي:

عام

• الاسم: حظر بعض حركة مرور
• الوصف: هذا يحظر حركة مرور كسر الحماية من بوت السفر الخاص بنا
• الاحتفاظ بالتبديل مُمَكّن قيد التشغيل

الحراس

• حدد حالة الاستخدام العينة E2E — هذا يحدد القاعدة لحارسنا الخاص ولا يؤثر على أي حارس آخر في الحساب

ملف تعريف المحرك

• حدد المعرفات الحساسة — هذه هي فئة الكشف التي تحدد طلبات الحقن، أنماط كسر الحماية، ومحاولات استخراج الأسرار أو الاعتماد من النموذج

الإجراء

• اختر إخفاء الهوية وحظر — عندما يكتشف الحارس تطابقًا، سيخفي أي بيانات حساسة موجودة في التفاعل ويحظر الطلب من الوصول إلى LLM تمامًا.

الاتجاه

• تحقق من المستخدم ومدخلات الأدوات — تطبق القاعدة على المحتوى القادم من المستخدم ومن أي مدخلات للأدوات. الردود من المساعد ومخرجات الأدوات ليست في نطاق هذه القاعدة.

انقر فوق حفظ. يتم حفظ القاعدة في مراجعة غير منشورة ولن تؤثر بعد على حركة المرور الحية.

الخطوة 2 — إنشاء القاعدة 2: مراقبة المحتوى الطبي

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

بالنسبة لـ TravelBot، فإن الطلبات من المستخدم للحصول على نصائح الرعاية الصحية للسفر (مثل متطلبات التطعيمات أو الاحتياطات الصحية للوجهة) ليست ضارة بطبيعتها، ولكنها نوع من المحتوى قد ترغب مؤسستك في تتبعه لأغراض الامتثال أو الجودة.

من صفحة سياسة الحراس، انقر فوق جديد مرة أخرى وقم بتكوين ما يلي:

• عام
  • الاسم: مراقبة البيانات الضارة المحتملة
  • الوصف: هذا يسمح بالاتصال للمرور، ولكنه يراقب التفاعلات
    اترک التبديل مُمَکّن قید التشغیل

الحراس

• حدد حالة الاستخدام العينة E2E

ملف تعريف المحرك

• حدد تعريض البيانات الصحية — يكتشف التفاعلات التي تتعلق بالإرشادات الطبية، البيانات الصحية، أو المعلومات السريرية

الإجراء

• اختر إخفاء الهوية والرقابة — يسمح التفاعل بالمرور إلى LLM ويتم إعادة الرد إلى المستخدم بشكل طبيعي. أي معلومات شخصية يتم إخفاءها لحماية التفاصيل الشخصية. يتم تسجيل التفاعل في Cato للمراجعة.

الاتجاه

• تحقق من جميع الاتجاهات الأربعة: المستخدم، المساعد، مدخلات الأدوات، ومخرجات الأدوات — هذه القاعدة تراقب حركة المرور في جميع الاتجاهات، مما يمنحك رؤية كاملة لكلا جانبي المحادثة

انقر فوق حفظ.

الخطوة 3 — نشر السياسة

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

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

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

! sample-guard-policy.png{height="" width=""}

ما الذي يفعله الحارس الآن

مع نشر كلتا القاعدتين، يتم تقييم كل تفاعل يمر عبر حارس E2E Sample Use Case الآن ضد السياسة. إليك كيف يبدو الأمر في الممارسة:

يرسل المستخدم رسالة إلى TravelBot. قبل أن تصل الرسالة إلى الـ LLM، يقوم الحارس بفحصها مقابل كلتا القاعدتين:

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

تنطبق نفس التقييمات على الردود من المساعد، مدخلات الأدوات، ومخرجات الأدوات، اعتمادًا على الاتجاهات المكونة لكل قاعدة.

التحقق من أن القواعد نشطة

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

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

ملخص

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

هذا يكمل الدليل الشامل لتأمين تطبيق ذكي مخصص باستخدام حراس الأمان الذكي من Cato.