أمن الوكلاء هو مشكلة أنظمة: من حقن الأوامر إلى التحكم في وقت التشغيل

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
يتوصل استطلاع رئيسي أُجري عام 2026 حول أمن وكلاء النماذج اللغوية الكبيرة (LLM) إلى نتيجة يجب على فرق العمل في المؤسسات أخذها على محمل الجد: بمجرد أن يتمكن النموذج من استخدام الأدوات، والاحتفاظ بالحالة، والتصرف نيابة عن شخص آخر، فإن الأمن لا يعود مجرد مشكلة تتعلق بتصفية الأوامر (Prompts). بل يصبح مشكلة أنظمة تمتد عبر تدفق المعلومات، والصلاحيات المفوضة، والحالة المستمرة.
1. لماذا يختلف أمن الوكلاء عن سلامة النماذج اللغوية الكبيرة
ينطلق الاستطلاع من حقيقة معمارية بسيطة: وكيل النموذج اللغوي الكبير يقوم بأكثر من مجرد توليد النصوص. فهو قد يخطط، ويستدعي الأدوات، ويتصفح، وينفذ الأكواد، ويحدث الحالة، وينسق مع وكلاء آخرين. هذه القدرات تحول مخرجات النموذج إلى مدخلات لمسار التحكم في البرمجيات.
هذا يغير نمط الفشل. فالتعليمات الضارة المخبأة في صفحة ويب يمكن أن تؤثر على استدعاء لاحق لأداة ما. ونتيجة الأداة المسمومة يمكن أن تصبح سياقاً لقرار آخر. ومدخل الذاكرة المخترق يمكن أن يستمر لما بعد الجلسة الأصلية. والاعتماد المفوض يمكن أن يحول خطة سيئة إلى تأثير جانبي حقيقي. وفي نظام متعدد الوكلاء، قد تنتشر المعلومات الملوثة نفسها إلى ما هو أبعد من الوكيل الذي واجهها لأول مرة.
لذلك، يؤطر الاستطلاع أمن الوكلاء حول ثلاث خصائص متفاعلة:

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

يوضح منظور دورة الحياة هذا أيضاً سبب كون الدفاعات "ضعيفة التركيب"، كما يصفها الاستطلاع. فقد يحظر مرشح المحتوى فئة واحدة من النصوص الضارة ولكنه لا يفعل شيئاً حيال الصلاحيات المفرطة. وقد تحتوي بيئة الاختبار (Sandbox) تنفيذ الكود ولكنها لا تمنع استدعاء واجهة برمجة تطبيقات (API) مصرح به. وقد توقف بوابة الموافقة تأثيراً جانبياً واحداً ولكنها لا توقف كتابة مسمومة في الذاكرة. وقد يجعل التتبع الحادث قابلاً للملاحظة دون منعه.
لذا، ينبثق الأمن من التركيب من الحدود، والامتيازات، وضوابط الدولة، والأدلة.
3. مواءمة الاستبيان مع TrueForge و TrueFoundry
إن أدق مواءمة للمنتج ليست القول بأن "TrueFoundry تحل مشكلة أمن الوكلاء"، بل هي التساؤل عن أي جزء من نموذج أنظمة الاستبيان يمكن لكل طبقة أن تتحكم فيه بشكل واقعي.
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.

















.png)
.png)
.png)
.png)
.png)






.png)







