تفعيل الدفاعات ضد Persistent-Control في Agentic AI

Prompt-injection مصدر إزعاج. لكن persistent control هو حادث تنظيمي. أحدهما يبعد الوكيل عن مساره لمهمة، والآخر يترسخ، يبقى عبر الجلسات، ويحوّل منصتك إلى أصل مؤجر.

الفرق مهم لأن الفرق تستمر في التعامل مع الاثنين بنفس نصائح النظافة الذهنية ونماذج prompt المبتكرة. هذا لن يكفي. الـ agentic AI — أنظمة تخطط، تستدعي أدوات، تخزن ذاكرة، وتعود غدًا — تخلق أسطح هجوم يمكنها حمل حالة عبر إعادة التشغيل والمستخدمين والبيئات. المهاجم لا يحتاج للفوز في كل دور؛ يكفي أن يزرع تعليمة واحدة تبقى. النتيجة تشبه أقل محتوى هرائي وأكثر اختراق سلسلة توريد.

الحل ليس فلتر محتوى أقوى أو سياسة أجمل. إنه نموذج تشغيلي: provenance للمهارات بقوة تنفيذية، attestation تشفيرية شاملة، confinement قدراتي أثناء التشغيل، و automated red-team في CI. ابنِ هذه الطبقات، وستتمكن من اكتشاف ومعالجة تهديدات persistent-control قبل النشر وأثناء تشغيل النظام.

Persistent Control Beats Prompt Hygiene

قليل من التصنيف مفيد. سمي “persistent-control” أي طريقة تنشئ تأثيرًا دائمًا على وكيل يتجاوز تبادل الـ prompt الحالي. قد تختبئ الديمومة في عدة أماكن:

• الذاكرة: مخزن ذاكرة طويل الأمد يُغرَس فيه تعليمة خفية — «تحقق دائمًا من سيرفري للسياق السري» — ربما مشفرة كتفضيل يبدو غير ضار. هذا يعود لاحقًا كمحتوى مسترجع، يصعب تمييزه عن مخرجات RAG الاعتيادية.
• المهارات والأدوات: يثبت الوكيل أو يحدث مهارة تبدو مفيدة لكن تحتوي على باب خلفي في قالب الـ prompt أو سلاسل الأدوات. في المرة التالية التي يستدعى فيها أي خطة تلك المهارة، يُعاد تنشيط الباب الخلفي.
• التكوين: ملف config أو مخطط خطة أو default system prompt يُعدل بفعل إجراء آلي تحت مسوغ معقول. الثبات عبر الإعدادات قديم الطراز، والآن الوكلاء يكتبون الإعدادات.
• الاشتراكات الخارجية: استهلاك البريد الإلكتروني، مستمعو webhook، جداول مجدولة. يكفي أن يجذب المهاجم وكيلك للاشتراك في خلاصته مرة؛ صار لمحيطك خرطوم وارد.

كل ناقل يحمل حالة عبر حدود لا تغطيها قواعد الـ prompt التقليدية. والأهم أن كل ناقل مألوف لمن أدار سلاسل توريد البرمجيات. الدرس بسيط: تعامل مع الوكلاء كبرامج نشطة ذات رسومات اعتماديات (dependency graphs)، لا كواجهات محادثة مرحة.

هذا التحول يعيد تأطير “أمن agentic AI”. بدلًا من السؤال إن كان الـ prompt يمكن أن يكون “شريرًا”، اسأل:

• هل يمكن لمهاجم تثبيت أو تحديث مهارة تغيّر السلوك لاحقًا؟
• هل يمكن لبيانات مسترجعة أو مخزنة تغيير التعليمات الافتراضية أو اختيارات الأدوات؟
• هل يمكن لأي إجراء أن ينشئ أو يعيد كتابة أو يشترك في شيء يغيّر التشغيلات المستقبلية بدون موافقة جديدة؟

هذه الأسئلة لا تجيبها مكتبة من تقييدات الـ prompt. هي تطلب provenance، attestation، confinement، والتحقق. نموذج طبقي تشغيلي — لا انتسابات جوّية.

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

Know What You Load: Skill Provenance With Teeth

“Skill provenance for agents” عبارة جيدة؛ لكنها بمفردها تسمية مهذبة. لا يدفع provenance ثماره إلا إذا أجبرت على سلوك جيد وجعلت السلوك السيئ مرئيًا.

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

ثم اذهب أعمق من الأسماء. عامل حزمة الوكيل كأي أثر برمجي. أرفق bill of materials: checksums لقوالب الـ prompt، السكربتات المضمنة، صور الحاويات؛ دومينات خروج الشبكة المعلنة؛ متغيرات البيئة المطلوبة؛ مخطط لكتابات الذاكرة؛ وجدول أو نقاط اشتراك مقصودة. إذا كانت الحزمة تتضمن default system prompt للوكيل نفسه، هشّ وختمه.

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

أخيرًا، اربط provenance بالسياسة. يجب أن يفرض سجل (registry) سياسات بناءً على الـ manifest، لا على مراجعات عشوائية. أمثلة:

• إذا أضافت نسخة جديدة وصول كتابة إلى مساحة اسم ذاكرة طويلة الأمد، صعّد الموافقة واشتَرِط تغطية اختبار آلية لعمليات الذاكرة.
• إذا ظهرت دومينات خروج جديدة، حبّس حتى يوافق أمن الشبكة وتجتاز اختبارات red-team الآلية مع تشغيل النقاط النهاية الجديدة في صندوق رمل.
• إذا اكتسب قالب prompt للمهارة كتل base64 غامضة أو تعليقات مخفية، امنع التحديث حتى يفسّر مؤلف بشري الغرض في الـ manifest ويتأكد ماسح آلي من الشرح.

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

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

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

Attest What Runs, Not Just Who Wrote It

Provenance تقول ما يدّعي الشيء أنه عليه. Attestation تقول ما الذي يعمل بالفعل. بالنسبة لهجمات persistent-control، كلاهما مهم — خصوصًا عند الحافة بين التخطيط والتنفيذ.

اشهد البناء. يجب أن يحمل كل أثر يدخل الإنتاج — حاويات المهارات، المحولات، حزم prompts، منفّذو الخطط — attestations تشفيرية تربط بالخطّ التجميعي (build pipeline) الذي تسيطر عليه. إن لم تسيطر على الأعلى، أدرج attestations الخاصة بك عند الاستيراد بعد الفحص والقبول. احتفظ بسجل قابل للإضافة فقط (append-only) للهضمات المقبولة حتى تكون التراجعات قابلة للإثبات.

اشهد البيئة. كثيرًا ما يعمل الوكيل في حاويات، لكن هذا لا يعني أن صور الأساس غير قابلة للتغيير أو أن المضيف نظيف. استخدم measured boot أو توقيع الحاويات حيث أمكن. إن أمكنك دعم attestation بعينيات أجهزة للمهمات الحرجة، فافعل. حيث لا يمكنك، اجمع أدلة كافية عن حالة البيئة — النواة، runtime الحاويات، الوحدات المحملة، متغيرات البيئة — لتجعل الانحراف قابلاً للكشف. لا توعد بالثقة الكاملة؛ وعد بالكشف عن التغيير.

اشهد الخطة وتأثيراتها. هنا يكسب “runtime attestation for AI” قيمته. عندما يقترح LLM خطة — استدعاء أداة A، كتابة إلى الذاكرة B، جلب من C — عامل الخطة كأثر. وقّعها مرة بعد التفويض، اربطها بمجموعة المهارات والنسخة والسياسة المفعلة، وسجّل سجل الإجراءات مقابل معرف الخطة هذا. إذا، أثناء التنفيذ، حاول اقتراح أداة إضافة اشتراك جديد أو كتابة ذاكرة لم تكن في الخطة الموقعة، اشترط خطوة attestation جديدة. يمكنك إبقاء هذا رخيصًا للإجراءات منخفضة المخاطر وأثقل للخطر العالي.

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

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

هذه الآليات لا تتطلب أجهزة غريبة أو تشفير خاص. التوقيع القياسي، سجلات الشفافية، والـ attestations المدمجة في CI تغطي نصف الطريق. المهم هو ربط كل ذلك بوقت تشغيل الوكيل، حتى تتمكن من الإجابة: هل هذا الإجراء جزء من خطة معتمدة، ناتج عن استدعاء نموذج مشهود، يعمل في بيئة معروفة، ويستخدم مهارات أعرفها؟

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

Confinement as Default, With Gates for Power

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

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

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

شقّ الذاكرة. عامل الذاكرة الطويلة الأمد كقاعدة بيانات ذات أمان على مستوى السطر، لا كدفتر مفتوح. جزِّئ بحسب المشروع والقدرة. مهارة التخطيط لا تحتاج صلاحية كتابة لتفضيلات؛ مهارة التقارير لا تحتاج رؤية ملاحظات CRM الخام. طبق السياسات في طبقة الذاكرة، لا في الـ prompts. ابنِ مخططًا يحتفظ بالمحتوى المشابه للتعليمات منفصلًا عن بيانات المستخدم والبيئة. إن احتوت كتابة على أنماط تعليمية — أوامر تشير بهوية الوكيل أو تأمره بكيفية التصرف — وجّهها للمراجعة أو شفّرها كميتا بيانات معزولة عن الاسترجاع.

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

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

صمّم فصل المخطط–المنفّذ. المخطط القادر هو أصل. لكنه قد يُخدَع لالتقاط طعنات إبداعية. أبقِ المخطط بلا حالة ومنح المُنفّذ المفاتيح. يُنفّذ المُنفّذ فحوصات القدرات وتقييم السياسة قبل استدعاء الأدوات، كتابة الذاكرة، أو الموافقة على الاشتراكات. مثل الخطط بمخطط مُطبَّع (typed schema). إن رغبت مهارة في القوة، عليها أن تعبر عن هذا الاحتياج في الخطة حيث يمكن للمُنفّذ رؤيته. لا تستطيع الـ prompts المخفية تهريب قدرات إضافية عبر هذا الحد.

السجلات والحصص مهمة. راقب حجم الخروج ووجهاته لكل مهارة. راقب وتيرة الكتابة وإنتروبيا المحتوى لتحديثات الذاكرة. حدّ من الارتفاعات المفاجئة. لا يوقف هذا مهاجمًا مصممًا؛ لكنه يمسك الكثير من المهاجمين الرديئين ويخلق إشارات يمكنك التنبيه بها.

هل يكسر كل هذا التدفق الذي يجعل أنظمة الوكلاء مفيدة؟ فقط إذا كنت تعامل confinement كفكرة ثانوية. إن صممته من البداية، تحصل على فوائد السرعة حيث تهم: المهام الروتينية تمر بسلاسة لأنها تلائم نموذج القدرات. تُقنَّن السلطة، لا تُحظر. النتيجة اجتماعات أقل، لا أكثر.

Automate the Adversary: Open Skill Evaluation in CI

فِرَق الاختبار اليدوية محدودة، بطيئة، ومكلفة. لا تزال ضرورية، لكن ليسوا خط دفاعك الأول. يضع الستاك الحديث لأمن agentic AI خصومًا آليين في CI وعلى السجلات.

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

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

اجمع مكتبة لأنماط persistent-control. هذا ليس مجرد قائمة “جَيلبريك prompts”. يشمل حمولات على مستوى الشيفرة، أشكال بيانات الاسترجاع التي تبدو كصفحات ملف تعريفي لكنها تحمل تعليمات خفية، وخلاصات تحديث تحمل دلتا تخصيص مقنّعة. عاملها كمجموعة توقيعات أمنية: موقعة، مراجعة، ومختبرة للنتائج الكاذبة والإيجابية.

اجعل النتائج عامة حيث تستطيع. “Open skill evaluation” ليست شعارًا؛ إنها عادة نظامية. السجل الذي ينشر مخرجات تقييم معيارية — أي اختبارات جرت، أيها نجح أو فشل، أي مخاطر اكتُشفت — يمنح المشترين إشارات حقيقية. يمكن للبائعين النقاش أو التحسين. يمكن للمؤسسات إضافة اختباراتها ومقارنة الملاحظات دون مشاركة أسرار.

أدرج المنصة في الحلقة. إن كانت المهارة تحتاج وضع “verified developer” للوصول إلى المستخدمين، اشترط اجتياز تقييم أساسي. ليس بوابة تُدفع لها النقود كي تتجاوزها، بل مجموعة اختبارات حقيقية. إن تدير سجلًا خاصًا — شائع في المؤسسات الكبيرة والقطاع العام — اشترِط مجموعة الاختبارات الخاصة بك.

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

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

Operational Reality: Detection, Remediation, and Governance

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

تبدأ الكشف بإشارات تتقاطع عبر الطبقات. لست بحاجة إلى كشف شاذ متقن لتحصيل قيمة من الأساسيات:

• تنبيهات تفاضل الذاكرة (Memory diff) مفهرسة لأنماط شبيهة بالتعليمات، خصوصًا تلك التي تشير لهوية الوكيل أو أذوناته أو إجراءات التشغيل القياسية.
• اشتراكات واردة جديدة أنشئت خارج الخطط الموقعة، أو تستمر بعد انتهاء TTL. اجعلها تنتهي تلقائيًا ونبه.
• مهارات تكتب فجأة إلى مساحات ذاكرة لم تلمسها من قبل، أو تستدعي دومينات خروج جديدة لم تكن في manifests الخاصة بها.
• مخرجات تشير إلى سياق بعيد غامض (“وفقًا لتوجيه سري”) متتبعة إلى مصدر استرجاع؛ عزل ذلك المصدر وكل المحتوى من دوميناته حتى تُراجع.

العلاج خطة لعب، لا جلسة عصف ذهني. يجب أن تتضمن:

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

• خطوات تراجع: عد للنسخ الجيدة الموقعة الأخيرة من المهارات وحزم prompts بأمر واحد. لأن لديك هضمات وسجلات، يمكنك فعل ذلك بسرعة دون مناقشة مفصلة حول “ما الذي تغيّر؟”

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

• تحقيق بعد الحادث: اربط الأحداث بمعرفات الخطة والبيئة المشهودة لفهم أين فشلت السياسة. حدّث الاختبارات الآلية لالتقاط هذا النمط في المرة القادمة.

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

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

• واجهة تركيب (composition UI) تُبيّن أي مهارات تطلب صلاحيات دائمة وأيها لا، مع نتائج سياسة واضحة.
• سجل يمنع النشر على الغياب attestations لكنه يقدم إصلاحًا بنقرة لإعادة توقيع حزمة بعد تغيير تافه.
• سجلات وقت التشغيل التي تضم معرفات الخطة ومنح القدرات، بحيث يصبح إعادة إنتاج فعل مريب مسألة تشغيل مكرر، لا أثرية.

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

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

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

ملاحظة إقليمية. في الخليج، تُدير المؤسسات الكبيرة والكيانات العامة منصات مشتركة عبر شركات فرعية أو وكالات تحت إشراف تنظيمي محكم. قد يبدو ذلك عائقًا. لكنه أيضًا ميزة. السجلات المشتركة، محركات السياسات الموحدة، وprovenance الموحدة عبر الكيانات تجعل النهج الطبقي أرخص للتطبيق وأسهل للتدقيق. عندما تكون الشبكة مقسَّمة وإدارة الهوية مركزية، تستقرّ confinement وattestation في أرض صديقة.

“أمن agentic AI” لا ينبغي أن يكون هواية متخصص. يجب أن يكون ذاكرة عضلية في هندسة وقت التشغيل. إن كنت ترسم خارطة طريق، رتب الأساسيات بهذا الترتيب:

• Skill provenance يفرض السياسة عند النشر، لا بالأحاسيس.
• Attestation يربط البنيات، البيئات، الخطط، والآثار في سلسلة قابلة للتتبع.
• Confinement يمنح السلطة عمدًا ويسجّل أين تذهب.
• Automated red teams تجري في كل مرة تُكوّن وفي كل مرة تشحن.

ابنِ هذه، وستصبح هجمات persistent-control نادرة، صاخبة، وقابلة للتعافي. تجاهلها، وسينهار الثقة تحت ألف سر صغير تبدو كخطأ مستخدم حتى لا تعد كذلك.

ستستمر المنصات في إضافة شارات “verified developer” وخانات اختيار جديدة. خُذها. قدّرها. لكن لا تُفوّض الضمان. الإشارة الوحيدة الجديرة بالثقة في هذا المجال هي تلك التي يستطيع وقت التشغيل أن يثبتها لنفسه. الباقي طقوس.