أهم ما يميز مشروع TOLAP الجديد من AWS ليس الاختصار نفسه، بل موضع تطبيق السياسة الأمنية.

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

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

يمثل الإصدار العام الأول إشارة مفيدة إلى أن أمن الوكلاء يبتعد عن السؤال البسيط: «هل يحق لهذه الهوية استدعاء واجهة برمجة التطبيقات؟» ويتجه إلى سؤال أصعب: «ما الذي يمكن لهذا الاستدعاء المحدد أن يكشفه أو يغيره بالضبط؟»

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

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

ما الذي أطلقته AWS

تصف AWS Open Source مشروع TOLAP بأنه طبقة لتطبيق السياسة عند نقطة المصدر. المستودع متاح بموجب ترخيص Apache 2.0، ويضم مخططاً للسياسات، ومكتبات لتطبيقها في ‎.NET‎ وPython وTypeScript، وخادماً مرجعياً للسياسات، وأمثلة ووثائق، وتكاملات مع أطر شائعة للوكلاء والأدوات.

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

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

تقول AWS إن حزم تطوير البرمجيات الخاصة بالمشروع تشترك في مخطط سياسات مُص版本، وفي تجهيزات اختبار مشتركة، بحيث يُفترض أن تتصرف التطبيقات بالطريقة نفسها عبر اللغات المختلفة. ويضم المستودع أيضاً تكاملات مع حزم MCP، وStrands، وLangChain، وLangChain.js، وVercel AI SDK، وMastra، وOpenAI Agents، وPydantic AI، وSemantic Kernel، وBedrock Agents. ولا تحول هذه التكاملات TOLAP إلى خادم MCP؛ فالمشروع يغلّف الدالة التي تستخدمها طبقة الأدوات، بينما يظل جلب البيانات من مسؤولية التطبيق.

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

لماذا لا يكفي التفويض العادي للأدوات

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

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

  • أي العملاء يحق للموظف الذي أرسل الطلب رؤيتهم؛
  • ما الأعمدة التي ينبغي حذفها؛
  • هل يجوز أن تتضمن النتيجة عملاء خارج منطقة الموظف؛
  • هل يمكن إعادة العنوان كاملاً؛
  • هل يُسمح للاستعلام بإرجاع 5,000 صف؛
  • هل تحولت عملية قراءة بهدوء إلى عملية تصدير.

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

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

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

الإصدار يضيف أكثر من تصفية الصفوف والحقول

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

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

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

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

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

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

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

ما الذي يتغير لفرق MCP وأدوات الوكلاء

يظهر الأثر العملي الأكبر لدى الفرق التي تضيف أدوات بوتيرة أسرع من وتيرة تصميم التفويض.

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

وتظهر المشكلة نفسها خارج MCP. فقد يصبح كل من أداة OpenAI Agents، أو مسترجع LangChain، أو مجموعة إجراءات Bedrock Agent، أو نقطة نهاية لاستدعاء الدوال، أو غلاف Python مخصص، حد إفشاء غير مقصود. يتعمد نهج TOLAP العمل تحت إطار النموذج: ضع السياسة حول الدالة التي تتحدث إلى المصدر، ثم حافظ على نموذج التطبيق نفسه عندما تتغير طبقة التنسيق.

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

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

الحدود التي تظل من اختصاص التطبيق

لا يلغي TOLAP الحاجة إلى ضوابط الأمن التقليدية.

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

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

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

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

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

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

خطة تقييم عملية

لا تحتاج الفرق إلى اعتماد حزمة TOLAP بأكملها كي تستفيد من الدروس التي يقدمها الإصدار. فالتصميم يقترح مراجعة عملية لأدوات الوكلاء الموجودة.

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

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

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

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

وأخيراً قِس الاحتكاك الذي يواجهه المطورون. فطبقة أمنية يصعب دمجها أكثر من اللازم ستُتجاوز. ليس السؤال الصحيح هو ما إذا كان الغلاف يستطيع التعبير عن كل سياسة يمكن تخيلها، بل ما إذا كانت المؤسسة تستطيع جعل المسار الآمن هو الأسهل لكل موصل وإطار عمل تدعمه.

لماذا يستحق هذا الإصدار المتابعة

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

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

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

النصيحة المباشرة لفرق المنصات والأمن هي الآتية: لكل أداة وكيل تلامس بيانات حساسة، حدّد أصغر نتيجة مفيدة قبل أن يراها النموذج. طبّق هذا التعريف برمجياً عند حدود البيانات، وأبقِ بيانات الاعتماد عاجزة عن تجاوزه، وسجّل السياسة التي اتخذت القرار. يمنح إطلاق TOLAP من AWS الفرق مشروعاً مفتوح المصدر ملموساً لفحصه، كما يجعل مناقشة هذه البنية أسهل.

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

المصادر

تستند الإشارات الواردة في المقال إلى مدونة AWS Open Source حول تقديم TOLAP، ومستودع TOLAP لدى AWS Labs، ووثائق البنية المعمارية للمشروع. ويتضمن السياق المقارن مواد Microsoft Learn حول أمن الذكاء الاصطناعي، وورقة NIST NCCoE عن هوية البرامج ووكلاء الذكاء الاصطناعي وتفويضهم، ودراسة أكاديمية عن معماريات التفويض للوكلاء الذين يستخدمون الأدوات، ونقاشاً مجتمعياً حول الصلاحيات المحدودة وتفويض الوكلاء.