هناك لحظة في كل مشروع وكيل ذكاء اصطناعي تسير هكذا تقريبًا: يعمل العرض التوضيحي بشكل مثالي، يفسر الوكيل اللغة الطبيعية، ويستدعي واجهات برمجية التطبيقات الصحيحة، ويعيد البيانات الصحيحة. ثم تبدأ في التفكير في المستخدمين الحقيقيين.
ما الذي يمنع جلسة وكيل مستخدم واحد من رؤية بيانات مستخدم آخر؟ ماذا لو تم خداع الوكيل عبر حقن النصوص التوجيهية؟ ماذا لو استدعى أداة بطريقة غير متوقعة؟
هذه ليست حالات حافة. هذه قرارات تصميم تحتاج إلى اتخاذها قبل الإطلاق.
يوفر قالب azd جديد من Curity وMicrosoft مرجعًا فعالًا لهذه المشكلة بالضبط.
المشكلة الجوهرية: المصادقة ≠ التفويض
تتعامل معظم عينات الوكلاء مع مصادقة المستخدمين بشكل جيد. إنها تتعامل مع التفويض بشكل سيئ. معرفة من هو المستخدم لا يخبرك بأي بيانات يجب أن يراها.
يقوم تطبيق العميل التقليدي باستدعاءات API يمكن التنبؤ بها. وكيل الذكاء الاصطناعي غير محدد — يفسر اللغة الطبيعية ويقرر ما يستدعيه. يمكن أن يكون مبدعًا. يمكن أيضًا أن يكون مخطئًا. وإذا تم التلاعب به عبر حقن النصوص التوجيهية، فأنت بحاجة إلى قواعد لا تعتمد على تصرف الذكاء الاصطناعي بشكل جيد.
الحل الذي يوضحه هذا القالب: رموز قصيرة الأمد تحمل المعلومات الصحيحة تمامًا لكل قفزة.
كيف تعمل سلسلة الرموز
يستخدم القالب رموز الوصول OAuth 2.0 مع تبادل الرموز لتضييق الأذونات في كل خطوة. يتم تبادل رمز المستخدم مرتين قبل الوصول إلى خادم MCP:
- التبادل الأول — يضيق النطاق ويحول الرمز المبهم إلى JWT
- التبادل الثاني — يضيف هوية الوكيل وجمهورًا جديدًا لقفزة خادم MCP
كيف يبدو رمز خادم MCP:
{
"scope": "stocks/read",
"sub": "62c839b8...",
"aud": "https://mcp.demo.example",
"customer_id": "178",
"region": "USA"
}
customer_id مُدمج في الرمز بواسطة خادم التفويض، ولا يتم تمريره كمعامل يتحكم فيه الوكيل. واجهة برمجة التطبيقات تتحقق من الرمز، وليس تعليمات الوكيل.
هذا يعني: حتى لو خدع شخص ما الوكيل لمحاولة جلب بيانات عميل آخر، فلن يصرح الرمز بذلك.
ما الذي ينشره القالب
بعدة أوامر azd تحصل على:
- وكيل خلفي على Microsoft Foundry (C#، SDKs Microsoft A2A وMCP)
- خادم MCP يكشف نموذج API للمحافظ الاستثمارية
- Curity Identity Server كخادم تفويض، إلى جانب Entra ID للمصادقة
- بوابات API خارجية وداخلية تتعامل مع تبادل الرموز وتسجيل التدقيق
- Bicep لجميع البنية التحتية Azure: Container Apps، VNet، ACR، Azure AI Foundry، Key Vault، Azure SQL Database، التخزين
النمط بأكمله قابل للفحص والتخصيص.
مبدأ التصميم الجدير بالاستعارة
حتى لو لم تستخدم Curity، فإن النمط قابل للنقل: يجب أن لا يمتلك الوكلاء أبدًا وصولًا دائمًا لواجهة برمجة التطبيقات. يجب أن يستخدم كل إجراء رمزًا قصير الأمد بأدنى نطاق ضروري لذلك الاستدعاء المحدد، صادرًا لهوية الوكيل المحددة، يحمل الادعاءات التي تحتاجها واجهة برمجة التطبيقات لاتخاذ قرارات التفويض.
هذا يصمد أمام الوكلاء المبدعين والأخطاء وحقن النصوص التوجيهية بطرق لن تصمد أمامها “تأكد فقط من أن الوكيل لا يفعل أشياء سيئة” أبدًا.
خلاصة
أنماط الأمان لوكلاء الذكاء الاصطناعي لا تزال قيد التطوير عبر الصناعة. هذا القالب هو أحد أكثر التطبيقات المرجعية اكتمالًا التي رأيتها — يغطي تدفق التفويض الفعلي، وليس المصادقة فحسب.
المنشور الأصلي: Least privilege AI agents: A new azd template from Curity and Microsoft
