Tekunda Team
العودة إلى المقالات
Tekunda Team
مراجعة أمان AppExchange للتطبيقات الوكيلة: إيه اللي مختلف
الإجابة باختصار: التطبيقات الوكيلة بتعدّي من نفس مراجعة الأمان الخاصة بـ AppExchange زي أي حزمة مُدارة تانية. اللي بيتغيّر هو المساحة اللي بتغطيها المراجعة. سيلزفورس بتحدد نطاق الاختبار عن طريق تتبّع مسار البيانات، وفي تطبيق شغال بنموذج لغوي بقت بيانات العميل بتدخل جوه prompt، وكتير بتخرج بره المؤسسة لنموذج، وترجع كنص ممكن يشغّل إجراء. جهّز تلات إجابات قبل ما تقدّم: إيه اللي بيدخل الـ prompt، وإيه اللي بيخرج من المؤسسة، والوكيل مسموح له يعمل إيه نيابة عن المستخدم.
إيه اللي بيتغيّر فعلاً لما تبقى الحزمة وكيلة؟
لأغراض المراجعة، التطبيق الوكيل هو أي حزمة بتشحن agent actions أو topics أو prompt templates، أو بتنادي نموذجاً لغوياً من Apex أو Flow. الإرشادات ما اتكتبتش من جديد عشان ده (Salesforce Developers)، لكن النطاق كبر، لأن سيلزفورس بتقرر تختبر إيه بتتبّع البيانات، وحركة البيانات هنا أكتر بكتير من حزمة CRM تقليدية.
في الحزمة المُدارة التقليدية كانت المسارات الخطرة محدودة: SOQL، والمشاركة، وكام callout، وشوية مخرجات Visualforce. أما التطبيق الوكيل فبيبني كمان prompts من سجلات العملاء، ويبعتها لمكان ما، وبعدين يتصرف بناءً على الرد. كل قفزة من دول مكان هيبص عليه المراجع.
المراجعون بيسألوا إيه عن التعامل مع الـ prompt؟
لازم تقدر تورّي، جوه مؤسسة Developer Edition اللي بتقدّمها، نص الـ prompt جاي منين بالظبط وإيه اللي بيقيّده. عملياً خمس نقط:
- سلامة التعليمات: النص اللي بيكتبه المستخدم ما ينفعش يقدر يعيد كتابة تعليمات النظام. اعتبر أي حقل نص حر بيوصل للـ prompt مدخلاً معادياً.
- التأسيس بيحترم الصلاحيات: السجلات اللي بتأسس عليها الـ prompt لازم تتقرا في سياق المستخدم الحالي، مع تطبيق المشاركة وأمان مستوى الحقول. الوكيل اللي بيلخّص سجل المستخدم أصلاً مش قادر يفتحه هو انتهاك مشاركة، بس بأدب أكتر.
- مخرجات النموذج غير موثوقة: ما ترندرهاش خام في الـ markup، وما تدمجهاش في استعلام. قواعد الحقن القديمة بتنطبق على النص المولَّد برضه.
- أقل بيانات ممكنة في الـ prompt: ابعت الحقول اللي المهمة محتاجاها، مش السجل كله.
- انضباط السجلات: لو بتخزّن الـ prompts أو الردود للتشخيص، فأنت بتخزّن بيانات عملاء. قول كده بوضوح، وحدّد نطاقه، وسيب للمشرف يقفله.
إيه اللي لازم يكون صح في خروج البيانات؟
دي السؤال اللي الحزم التقليدية نادراً ما اضطرت تجاوب عليه كويس، وهنا بالظبط بتضيع أسابيع من العروض الوكيلة. لو في مكوّن خارج سيلزفورس، التقديم بيطلب روابط المكوّنات الخارجية وبيانات الدخول بتاعتها، وتقرير فحص Checkmarx، وتقرير اختبار أمان تطبيقات ديناميكي (Salesforce Developers). وزيادة على كده، من واقع خبرتنا، المراجع هيحب يشوف الآتي مكتوب:
- قائمة صريحة بالكائنات والحقول اللي مسموح لها تخرج من المؤسسة، لكل خاصية على حدة.
- named credential لكل نقطة نهاية للنموذج، عشان النقطة وبيانات المصادقة ما يبقوش جوه كود Apex أبداً (مساعدة سيلزفورس).
- مين ماسك بيانات الاعتماد: مفتاح العميل نفسه، ولا مفتاحك أنت نيابة عنه. قول أنهي واحد، وليه.
- مزوّد النموذج بيحتفظ بإيه، ولمدة قد إيه، وفي أنهي منطقة جغرافية.
- هل يقدر المشرف يقفل النداء الخارجي ويفضل التطبيق شغال.
وإيه وضع النداءات لنماذج طرف تالت؟
المكان اللي بتحط فيه حدود الثقة هو اللي بيحدد نصيبك من المراجعة. لو بتستخدم خدمات الذكاء الاصطناعي بتاعة المنصة، فالحد ده مسؤولية سيلزفورس في معظمه. أما لو بتنادي نموذجاً خارجياً مباشرة من حزمتك، فكل حاجة بقت عليك تثبتها: نقطة النهاية، والمصادقة، وسلوك التطبيق لما المزوّد يقع أو يرجّع كلام مالوش معنى، وعزل كل مشترك عن التاني. وادّي المراجعين وصولاً تجريبياً شغالاً للمكوّن الخارجي، مش وصفاً مكتوباً ليه.
الوكيل مسموح له يعمل إيه نيابة عن المستخدم؟
في اللحظة اللي الإجراء بيكتب أو بيمسح أو بيبعت أو بيدفع، المراجعة بتبطل تبقى عن الكود وتبقى عن الصلاحية. اِدِّي أضيق permission set تكفي الإجراء، واشتغل في سياق المستخدم، واطلب تأكيداً بشرياً لأي حاجة مش قابلة للرجوع، وسجّل الوكيل عمل إيه ونيابة عن مين. سيلزفورس قالت المعيار بوضوح لما فتحت سوق الوكلاء للشركاء:
لازم تكون قادر تثق في الذكاء الاصطناعي. ده معناه إننا لازم نفهم الصلاحيات ونحترم حدود الأمان، وعملاؤنا من المؤسسات لازم يفضلوا ملتزمين بمتطلبات الامتثال في حلولهم. (أليس شتاينجلاس، نائب الرئيس التنفيذي والمدير العام لمنصة سيلزفورس، diginomica)
تجهّز إيه قبل التقديم؟
- حزمة مُدارة ومُصدَرة. الحزم غير المُدارة وحزم البيتا بتترفض.
- مؤسسة Developer Edition متثبت فيها الحل، ببيانات عيّنة نظيفة وبيانات دخول وتعليمات استخدام.
- توثيق أي نتائج إيجابية كاذبة في تقارير الفحص.
- تقارير الفحص وبيانات الدخول لكل مكوّن خارجي، وضمنها بوابة النموذج عندك.
- وصف لمسار البيانات في صفحة واحدة لكل خاصية ذكاء اصطناعي: المُشغِّل، والحقول المرسلة، والوجهة، ومدة الاحتفاظ، ومفتاح الإيقاف للمشرف.
أول أربع حاجات هي مستندات التقديم الموثّقة. الخامسة مش على القائمة، وهي بالظبط اللي بتحوّل مراجعة من كذا جولة لمراجعة بتعدّي من أول مرة، لأنها بتجاوب على أسئلة تتبّع البيانات قبل ما المراجع يضطر يسألها.
هل AgentExchange مراجعة مختلفة؟
AgentExchange اتفتح في TDX 2025 بأكتر من 200 شريك بينشروا أربع أنواع من المكوّنات: actions وprompt templates وtopics وagent templates، وسيلزفورس بتقول إنها كلها عدّت مراجعة الأمان (diginomica). اعتبره نفس المعيار متطبّق على وحدات أصغر. الـ action الواحد بيحمل نفس الأسئلة التلاتة زي التطبيق الكامل، بس بكود أقل تختبي وراه.
تِكوندا شريك PDO لدى سيلزفورس، وعدّينا حزم من مراجعة الأمان في الرعاية الصحية واللوجستيات والتصنيع، منها حزمة Syntilio CareHub المُدارة اللي بتخدم 12 مؤسسة رعاية أو أكتر على AppExchange. لو بتحزّم تطبيقاً وكيلاً، اتكلم معانا قبل أول تقديم، أحسن من بعد أول رفض.
FAQ
هل خاصية الذكاء الاصطناعي بتحتاج مراجعة أمان منفصلة؟
لا. بتتراجع كجزء من حزمتك، لكنها بتوسّع نطاق الاختبار، لأن مسار البيانات بقى يخرج من الكائنات ويعدّي جوه prompt.
ينفع أشحن مفتاح API الخاص بالنموذج جوه الحزمة؟
تقدر تبني الحلين، بس كن واضحاً في اختيارك. المفتاح المشترك بيخلّي عزل المشتركين وموافقة كل عميل مسؤوليتك أنت تثبتها.
هل لازم أطبّق قواعد المشاركة على بيانات التأسيس؟
أيوه. التأسيس عملية قراءة، وقواعد المشاركة وأمان مستوى الحقول بتنطبق عليها، والملخص اللي بيسرّب حقل مخفي بيسقط زيه زي الاستعلام الخام.
إيه أكتر سبب بيرجّع التقديمات الوكيلة؟
خروج بيانات غير موثّق. الكود غالباً كويس، اللي ناقص هو بيان واضح لأي بيانات عملاء بتخرج من المؤسسة، ورايحة فين، وقاعدة هناك قد إيه.
