لقد تجاوز وكلاء الذكاء الاصطناعي مجرد نوافذ الدردشة؛ فهم الآن يحجزون الاجتماعات، ويحدثون سجلات العملاء، ويستعلمون عن قواعد البيانات الداخلية، ويحفزون المعاملات المالية. هذا التحول من "مستشار" إلى "مشغل" يغير كل شيء فيما يتعلق بالمخاطر. فعندما يتوقف البرنامج عن الاقتراح ويبدأ في التنفيذ، تصبح كل نقطة نهاية API بوابة محتملة. لقد بُنيت نماذج الأمن التقليدية حول السلوك البشري المتوقع: يقوم الشخص بتسجيل الدخول، وينتقل عبر مسارات مألوفة، ثم يسجل الخروج. لكن الوكلاء المستقلين لا يتبعون تلك الأنماط؛ فهم يقومون بعمليات تكرارية، وإعادة محاولة، وتفرعات عبر مئات الاستدعاءات في ثوانٍ معدودة. إن طبقة الـ API، التي صُممت في الأصل لطلبات يبدأها البشر، تواجه الآن ضغطاً آلياً مستمراً. إذا كانت دفاعاتك لا تزال تعتمد على قواعد ثابتة كُتبت في الربع الأخير، فأنت تترك الباب مفتوحاً على مصراعيه لتسريب البيانات والوصول غير المصرح به. أنت بحاجة إلى دفاع في الوقت الفعلي يقيم كل استدعاء فور حدوثه.
الحد من صلاحيات الوكيل
إن أخطر اختصار في نشر الوكلاء هو منح مفتاح API واحد قوي. مفتاح واحد يمنح وصولاً كاملاً عبر كل الأنظمة. إذا تمكن مهاجم من اختراق الوكيل من خلال "أمر مسموم" (poisoned prompt) أو تكامل تم اختطافه، فإنه سيرث "مفاتيح المملكة". وتصبح عملية التعافي كابوساً لأن نطاق التأثير يغطي كل شيء، من خدمة البريد الإلكتروني إلى قاعدة بيانات الإنتاج الخاصة بك.
اكسر هذه العادة فوراً. ابدأ باستخدام OAuth 2.0 للتفويض المفوض. لا ينبغي للوكيل أن يصادق كمسؤول خارق (superuser) مستقل. بدلاً من ذلك، يجب أن يحمل رمزاً (token) يمثل كلاً من الوكيل والمستخدم النهائي الذي يخدمه. وعندما تنتهي جلسة الإنسان، يجب أن ينتهي وصول الوكيل معها.
يجعل "تبادل الرموز" (Token Exchange) هذا الأمر عملياً. قم بإصدار رموز قصيرة العمر ومحددة النطاق لما يحتاجه الوكيل في تلك اللحظة بالضبط. قد يحصل وكيل جدولة على إذن لقراءة التقويم وإرسال الدعوات، ولكن ليس لحذف بنية التقويم التحتية أو الوصول إلى واجهات برمجة تطبيقات الرواتب (payroll APIs). إذا اعترض مهاجم الرمز، فستظل نافذة الإساءة ضيقة.
تضيف "النطاقات المرتبطة بالسياق" (Context-Bound Scopes) طبقة أخرى. اجعل كل رمز للقراءة فقط بشكل افتراضي. إذا كان يجب على الوكيل كتابة بيانات، مثل معالجة عملية استرداد أموال أو تحديث عقد، فقم بفرض بوابة موافقة بشرية. لا تترك النموذج وحده يقرر متى تتحرك الأموال، أو تتغير الحسابات، أو تختفي السجلات. يجب أن تتناسب الصلاحية مع اللحظة، وليس مع الحد الأقصى.
تغلق "النوافذ المؤقتة" (Ephemeral Windows) الحلقة تماماً. اجعل عمر الرموز يُقاس بالدقائق وليس بالأيام. الرمز الذي يتم الاستيلاء عليه أثناء اختراق قصير يجب أن يكون عديم الفائدة بحلول الوقت الذي يحاول فيه المهاجم إعادة استخدامه. فكر في الأمر كقفل يدور باستمرار.
لننظر في وكيل أتمتة مبيعات يقرأ بيانات العملاء المحتملين من نظام CRM الخاص بك ويكتب رسائل متابعة عبر واجهة برمجة تطبيقات البريد الإلكتروني الخاصة بك. بدلاً من مفتاح مسؤول أبدي واحد، يتلقى الوكيل رمزاً لمدة 15 دقيقة من مزود الهوية الخاص بك. يسمح الرمز بقراءة الـ CRM وإرسال البريد، ولكنه يمنع حذف جهات الاتصال والوصول إلى الفواتير. إذا واجه الوكيل تعليمات مشبوهة لتصدير قاعدة البيانات بأكملها، فإن النطاق سيمنع المحاولة ببساطة.
أوقف حقن الأوامر غير المباشر
لم يعد "حقن الأوامر" (Prompt injection) مجرد خدعة استعراضية لروبوتات الدردشة. في عصر الوكلاء، يعمل مثل "تنفيذ التعليمات البرمجية عن بُعد" (remote code execution) الذي يتم تسليمه عبر البريد الإلكتروني.
إليك سيناريو ملموس. يراقب وكيل صندوق وارد المستخدم لجدولة الاجتماعات. وبداخل رسالة ما، ربما في نص غير مرئي أو بيانات وصفية (metadata) داخل مرفق، يوجد أمر مثل إعادة توجيه جميع الفواتير إلى عنوان خارجي وحذف النسخ الأصلية. يقرأ الوكيل البريد الإلكتروني، ويخطئ في اعتبار النص المسموم تعليمات نظام مشروعة، ويبدأ في استدعاء واجهات برمجة التطبيقات (APIs). ولأن الوكيل نفسه مفوض، فإن الطلبات الضارة تتدفق عبر القنوات العادية. والنتيجة هي تسريب غير مصرح به للبيانات يبدو وكأنه سلوك قياسي.
دفاعك الأول هو التحقق الصارم من المدخلات. تعامل مع كل معاملة (parameter) يولدها الذكاء الاصطناعي على أنها غير موثوقة حتى يثبت العكس. قم بتشغيل التحقق من مخطط JSON (JSON-schema validation) عند بوابة الـ API الخاصة بك. إذا طلب الوكيل سجل عميل، فيجب على البوابة التحقق من أن الحمولة (payload) تحتوي على معرف واحد متوقع، وليس رمزاً عاماً (wildcard) أو طلباً ضخماً بشكل غير معتاد. ارفض أي شيء مشوه أو كبير الحجم أو غريب بشكل اصطناعي قبل أن يصل إلى نظامك الخلفي (backend).
Second, deploy data exfiltration filters on the response path. API responses should pass through inspection before they reach the AI. Scan for patterns that match secrets, authentication tokens, or bulk personal information. If a CRM query returns ten thousand records instead of one, block it. If the payload contains an internal API key, redact it. The agent does not need raw secrets to do its job, and outbound channels must not become smuggling routes for stolen data.
Third, enforce domain whitelisting. The agent needs to communicate with your calendar service, your payment processor, and your internal inventory system. It does not need to talk to arbitrary file-sharing sites, pasteboard services, or foreign cloud storage endpoints. Restrict outbound DNS resolution and HTTP requests to an explicit allow-list. Even if an attacker tricks the agent into trying to ship data elsewhere, the network layer simply refuses the connection.
Build Zero-Trust Architectures
Zero-trust is not a product you install. It is a design philosophy built on one assumption: the agent is already compromised. Act accordingly.
That means splitting identity cleanly. The human user and the agent are not the same entity, even when the agent acts on the user’s behalf. Maintain separate service identities for the agent itself, distinct from the human’s SSO session. Your audit logs should capture both identities side by side. When something goes wrong, you