تفويض وكلاء AI: فجوة المسؤولية لعام 2026

إن وكيل الذكاء الاصطناعي الذي يتجاوز تعليماته يترك سجلات دقيقة في كل شركة تعامل معها — ولكن لا يوجد سجل واحد يثبت ما صرحت به أنت. إن قانون AI AGENT، الذي تم تقديمه في 21 يوليو 2026، سيتطلب من الوكلاء تسجيل إجراءاتهم. لكنه لا يحدد أبداً من يدفع ثمن الخطأ.

ملخص

قدم السيناتور مارك وارنر (D-VA) مشروع القانون S.5051، وهو قانون AI AGENT لعام 2026، في 21 يوليو 2026.¹² ومن شأنه أن يمنحك الحق في تعيين وكيلك الخاص للتصرف نيابة عنك على أي منصة إلكترونية لديها أكثر من 50 مليون عميل في الولايات المتحدة — بشرط أن يكون مزود هذا الوكيل قد سجل أولاً لدى FTC.¹

كما يتطلب من كل "وكيل مستخدم وصي" الاحتفاظ بسجلات فورية للإجراءات التي تم اتخاذها نيابة عنك.¹

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

وقد واجه القطاع الصناعي نفس العقبة أولاً. فبروتوكول AP2 — وهو بروتوكول Google الذي تم التبرع به لتحالف FIDO في أبريل 2026 — جنباً إلى جنب مع Verifiable Intent من Mastercard ومجموعات عمل الوكلاء الجديدة في FIDO، جميعها تقدم دليلاً على التفويض.³⁴⁵ ولكن لا أحد منها يقرر من يتحمل الرسوم.

هناك شركة واحدة قدمت إجابة ملموسة على الطاولة — وكانت جهة إصدار بطاقات، وليس هيئة تشريعية.⁶

ما ستتعلمه

• ما يتطلبه قانون S.5051 فعلياً، والجدول الزمني للامتثال الذي يبدأ عند سن القانون
• لماذا قد يشملك تعريف "مزود وكيل المستخدم الوصي" في مشروع القانون بصفة شخصية
• أين يتوقف كل من AP2 و Verifiable Intent و FIDO و AuthZEN الخاص بـ OpenID
• لماذا أجل مشروع هوية الوكيل التابع لـ NIST حالة المستهلك صراحةً
• كيف تتعامل Regulation E و Regulation Z مع عملية شراء قام بها وكيلك باستخدام بيانات اعتمادك
• ماذا فعلت American Express في أبريل وهو الأمر الذي لم يشرعه أحد

السجل الذي لا وجود له

لنبدأ بالسيناريو الذي أعاد هذه القصة إلى الأخبار.

تطلب من وكيل البحث عن قميص بسعر أقل من 30 دولاراً وعدم شرائه. يجد الوكيل واحداً ويطلبه على أي حال.

أنت تعترض على الرسوم. يظهر بائع التجزئة أن الطلب جاء من خلال حسابك. يظهر مزود الوكيل تعليماتك بعدم الشراء. يظهر معالج الدفع أن الرسوم قد تم سدادها.

كل سجل دقيق. ولكن لا يوجد أي منها يربط الرسوم بالمهمة التي أوكلتها فعلياً.

هذا الإطار يأتي من آششيس لويتل، الأستاذ المساعد لتدريس الذكاء الاصطناعي في جامعة كامبرلاندز، في مقال كتبه لـ The Conversation وأعادت Fortune نشره في 24 أغسطس 2026.⁷

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

ما يتطلبه قانون AI AGENT — وما يغفله

أصدر وارنر مسودة نقاش في 29 يونيو 2026 — صراحةً لجمع الملاحظات "قبل تقديمها بشكل رسمي" — ثم قدم مشروع القانون الرسمي بعد ثلاثة أسابيع.⁸¹

تمت قراءة S.5051 مرتين وإحالتها إلى لجنة مجلس الشيوخ للتجارة والعلوم والنقل في 21 يوليو. وحتى 27 أغسطس 2026، لا تزال هذه الإحالة هي آخر إجراء مسجل لمشروع القانون.² وقد تناولت أحدث مراجعة للجنة، في 5 أغسطس، خمسة مشاريع قوانين تتعلق بسلامة الأطفال على الإنترنت والذكاء الاصطناعي؛ ولم يكن S.5051 من بينها.⁹

يعرّف مشروع القانون وكيل المستخدم الوصي (custodial user agent) بأنه "وكيل قائم على البرمجيات مفوض صراحةً من قبل المستخدم للتفاعل مع مزود منصة إلكترونية كبيرة نيابة عن ذلك المستخدم بطريقة شفافة، وموثقة، ومحدودة النطاق، وقابلة للإلغاء".¹

أما المنصة الإلكترونية الكبيرة فهي تلك التي لديها أكثر من 50,000,000 عميل أو مشترك في الولايات المتحدة في أي شهر تقويمي خلال الـ 12 شهرًا السابقة.¹

إليك ما سيبدأ تنفيذه في اليوم الذي يدخل فيه القانون حيز التنفيذ.

تفويض NIST هو الجزء المثير للاهتمام تقنيًا. فإلى جانب المراسلات، ووسائل التواصل الاجتماعي، والتجارة الإلكترونية، والتمويل الشخصي، وخدمات AI، تطلب المادة 4(ج)(6) معايير تغطي بيانات اعتماد التفويض محدودة النطاق والقابلة للإلغاء، والتحقق من هوية الوكيل وحالة التسجيل، و"الاتصال في الوقت الفعلي وتنفيذ الإلغاء"، و"إنشاء سجلات قابلة للتدقيق للإجراءات التي يتخذها وكلاء المستخدمين الوصي نيابة عن المستخدمين".¹

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

تتبع الواجبات الواردة في القسم 3(g) نفس النمط. يجب على الوكيل حماية بيانات المستخدم، ويجب ألا يتصرف بطرق تتعارض مع توجيهات المستخدم أو توقعاته المعقولة، ويجب ألا يستخدم البيانات للإعلانات أو التنميط، ويجب أن "يحتفظ بسجلات فورية للإجراءات المتخذة نيابة عن المستخدم" ويسلمها عند الطلب — مع استثناء واحد، وهو السجلات التي طلب المستخدم من الوكيل حذفها مسبقاً.¹

لا يمكن التنازل عن هذه الواجبات بموجب عقد، أو شروط خدمة، أو أي شكل من أشكال موافقة المستخدم — وهو نص جوهري، بالنظر إلى حجم مخاطر الوكلاء اليوم التي يتم إخلاؤها من المسؤولية في اتفاقية ترخيص المستخدم النهائي (EULA).¹

القسم 3(g)(1)(F) هو قاعدة التفويض الفرعي: لا يمكن للوكيل نقل سلطته إلى وكيل كيان آخر أو نظام AI ما لم يكن المستخدم قد صرح بذلك صراحةً وبشكل محدد وقابل للإلغاء، وأن يتحمل الطرف المتلقي نفس الواجبات.¹ أي شخص يقوم ببناء عمليات تسليم بين وكلاء متعددين (multi-agent handoffs) يجب أن يقرأ هذا البند مرتين.

لكن إذا بحثت في مشروع القانون عن من يتحمل تكلفة المعاملة الخاطئة، ستصل إلى القسم 4(g)، الذي يوجه FTC و CFPB و FDIC و OCC والخزانة و DHS والتجارة و DOJ و SEC لتشكيل مجموعة عمل "لغرض تطوير مقترحات لمنع الأضرار التي تلحق بالشركات والحكومة والناتجة عن قيام وكلاء المستخدمين الحافظين باتخاذ إجراءات نيابة عن الأصيل نتيجة احتيال أو إساءة استخدام أو خطأ حقيقي".¹

مقترحات. وليس قاعدة. والأضرار المذكورة هي تلك التي تلحق بالشركات والحكومة — قميص المستهلك الذي يبلغ سعره 30 دولاراً ليس موضوع هذه الجملة.

بند التسجيل الذي قد يشملك

هناك تعريف واحد في القسم 2 يستحق اهتماماً أكثر مما ناله.

يقصد بـ "مزود وكيل مستخدم حافظ" أي كيان يشغل أو يقدم واحداً أو أكثر من وكلاء المستخدمين الحافظين — ويشمل ذلك المستخدم الذي يشغل وكيل مستخدم حافظ نيابة عن نفسه وليس نيابة عن أي مستخدم آخر.¹

اقرأ ذلك مقابل القسم 3(d)(1): يجب على مزود وكيل المستخدم الحافظ "أن يسجل لدى المفوضية كشرط من شروط، وقبل، وصول أي وكيل مستخدم حافظ يشغله أو يقدمه هذا المزود إلى واجهة" يغطيها القانون.¹

ظاهرياً، هذا يعني أن الهاوي الذي يشغل وكيلاً مستضافاً ذاتياً (self-hosted agent) ضد منصة مشمولة هو مزود يجب عليه التسجيل أولاً لدى FTC.

لكن مشروع القانون يخفف من ذلك. "يجوز للمفوضية وضع شروط ونطاق خدمة موحد، يمكن من خلاله لمزود وكيل المستخدم الحافظ التسجيل عبر الإقرار الذاتي"، ولدى FTC أو هيئة إصدار شهادات معترف بها 180 يوماً من تاريخ التقديم لتقييم التسجيل.¹ الإقرار الذاتي سيجعل التسجيل الفردي مجرد نموذج، وليس تدقيقاً.

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

أين توقفت هيئات المعايير

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

هناك مدخلان من هذه المدخلات يستحقان نظرة فاحصة.

AP2 v0.2 دفع الأمور أكثر نحو العمليات غير المراقبة. الإصدار نفسه في 28 أبريل الذي نقل AP2 إلى حوكمة محايدة، أطلق ما أسمته Google "تحديثات حرجة للمعاملات ذاتية التشغيل"، بما في ذلك مدفوعات "Human Not Present" التي تسمح للعملاء "بتنفيذ المدفوعات بشكل مستقل وآمن — مثل حجز وشراء تذاكر الإصدارات المحدودة في اللحظة التي تُطرح فيها للبيع — بناءً على تعليمات مستخدم مفوضة مسبقاً".³

تدفق العمل المفوض بدون وجود بشري لم يكن جديداً في حد ذاته؛ فقد وصف منشور إطلاق AP2 التوقيع المسبق على Intent Mandate لمهمة مثل "شراء تذاكر الحفل في اللحظة التي تُطرح فيها للبيع".¹⁰ ما أضافه الإصدار v0.2 هو دعم أكثر شمولاً لذلك. وفي كلتا الحالتين، فإن اتجاه المسار يتجه نحو المزيد من المعاملات التي يكون الدليل الوحيد على النية فيها هو تفويض (mandate) موقع مسبقاً.

AuthZEN تحل المشكلة المجاورة بشكل جيد. تقوم مسودة معيار AARP بتوحيد كيفية قول النظام "ليس الآن، وهذا هو المطلوب" — موافقة، قبول، سلطة مفوضة، شهادة إثبات — بحيث يمكن للعميل تعليق الطلب واستئنافه بمجرد أن يوافق عليه البشر.¹¹ أما ملف COAZ المصاحب فيستهدف أدوات Model Context Protocol، مما يسمح لها بإظهار فحوصات التفويض المطلوبة لاستدعاء أداة ما.¹¹

هذا هو العنصر الأساسي لـ "الإنسان في الحلقة" (human-in-the-loop) الذي كان مطورو الوكلاء يقومون ببنائه يدويًا. ومع ذلك، فإنه لا يزال يتحكم في ما إذا كان الإجراء سيحدث أم لا، وليس في من يدفع الثمن عندما يحدث إجراء خاطئ.

لإنصاف AP2، كانت المساءلة ضمن النطاق منذ البداية. فقد ذكر منشور الإطلاق الخاص بـ Google أنها واحدة من ثلاثة أسئلة يعالجها البروتوكول — "تحديد المساءلة في حالة حدوث معاملة احتيالية أو غير صحيحة" — ووصف تسلسل "النية-إلى-السلة-إلى-الدفع" بأنه ينشئ "سجل مراجعة غير قابل للإنكار" يوفر "أساسًا واضحًا للمساءلة".¹⁰

إن وجود أساس للمساءلة لا يعني تخصيصها. ينطبق تقييم Luitel على العمود بأكمله: AP2 "لا يقرر من يتحمل الخسارة أو يحدد المدة التي يجب أن تحتفظ فيها كل شركة بتلك الأدلة وكيف يمكن استرجاعها لاحقًا".⁷

معرفة ما حدث بالضبط تخبرك من المخطئ، لكنها لا تخبرك أي ميزانية عمومية ستمتص التكلفة بينما يتم تسوية الأمر.

NIST أجلت بالضبط الحالة التي يمر بها المستهلكون

من شأن قانون AI AGENT أن يضع NIST على جدول زمني مدته 180 يومًا لوضع معايير التفويض القابلة للتحقق. عمل NIST الخاص بهوية الوكلاء جارٍ بالفعل — ونطاقه أضيق من نطاق مشروع القانون.

نشر المركز الوطني للتميز في الأمن السيبراني مسودة ورقة مفاهيمية بعنوان تسريع اعتماد هوية وتفويض البرمجيات ووكلاء AI في فبراير 2026، من تأليف Harold Booth و Bill Fisher و Ryan Galluzzo و Joshua Roberts.¹² استمرت فترة التعليقات من 5 فبراير إلى 2 أبريل 2026، والمشروع مدرج الآن تحت حالة "مراجعة التعليقات".¹³

تطرح الورقة الأسئلة الصحيحة: "كيف نتعامل مع تفويض السلطة في سيناريوهات 'نيابة عن'؟" "كيف نضمن عدم الإنكار لإجراءات الوكيل وربطها بتفويض بشري؟"¹²

ثم تضع حدودًا:

سيكون تركيز المشروع على حالات استخدام المؤسسات حيث يمكن الحفاظ على تحكم ورؤية أكبر على الوكلاء والأنظمة التي يصلون إليها. لن يتم معالجة تحدي تحديد وإدارة الوصول للوكلاء الخارجيين من مصادر غير موثوقة ضمن هذا الجهد الأولي، ولكن يمكن معالجة حالات الاستخدام التي تركز على الوكلاء الموجهين للجمهور أو الوكلاء الفرديين في إصدارات مستقبلية من المشروع.¹²

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

ومما يجدر ذكره، فإن المعايير التي تسميها NIST كمرشحة هي بالفعل مألوفة لمطوري الوكلاء: MCP، و OAuth 2.0/2.1 وامتداداتها، و OpenID Connect، و SPIFFE/SPIRE، و SCIM، و NGAC.¹² لبنات البناء موجودة، لكن التجميع العابر للحدود غير موجود.

القواعد القديمة كُتبت للبشر

إليك الجزء الذي يجعل الفجوة ملموسة اليوم، قبل أن يصبح أي من هذا قانونًا. هذه معلومات عامة حول اللوائح المنشورة، وليست استشارة قانونية.

الخصم وتحويلات الأموال الإلكترونية الأخرى. تحدد اللائحة E "تحويل الأموال الإلكتروني غير المصرح به" بأنه التحويل "الذي يبدأه شخص آخر غير المستهلك دون سلطة فعلية لبدء التحويل ولا يتلقى المستهلك منه أي فائدة".¹⁴

ثم يأتي الاستثناء. فالمصطلح لا يشمل التحويل الذي يتم "بواسطة شخص قدم له المستهلك جهاز الوصول إلى حسابه، ما لم يكن المستهلك قد أخطر المؤسسة المالية بأن التحويلات التي يقوم بها هذا الشخص لم تعد مصرحاً بها."¹⁴

أما التفسير الرسمي فهو أكثر صراحة: "إذا قدم المستهلك جهاز وصول ومنح سلطة إجراء تحويلات لشخص ما (مثل أحد أفراد الأسرة أو زميل في العمل) وتجاوز هذا الشخص السلطة الممنوحة له، فإن المستهلك يكون مسؤولاً بالكامل عن هذه التحويلات ما لم يكن قد أخطر المؤسسة المالية بأن التحويلات التي يقوم بها هذا الشخص لم تعد مصرحاً بها."¹⁴

لاحظ أين تكمن ثغرة النجاة. تتوقف المسؤولية عندما تخبر البنك بأن التفويض قد انتهى — وليس عندما تخبر الوكيل.

أما ما إذا كان الوكيل الذكي (AI agent) — أو الشركة التي تشغله — يُعتبر "شخصاً" لهذا الغرض، فهو أمر لم يتم اختباره بعد. تحدد اللائحة E "الشخص" بأنه "شخص طبيعي أو منظمة، بما في ذلك شركة، أو وكالة حكومية، أو تركة، أو صندوق ائتماني، أو شراكة، أو ملكية فردية، أو تعاونية، أو جمعية."¹⁴ والبرمجيات ليست مدرجة في هذه القائمة، لكن المزود الذي يقف خلفها هو منظمة.

بطاقات الائتمان. تضع اللائحة Z حداً أقصى لمسؤولية حامل البطاقة عن الاستخدام غير المصرح به بقيمة 50 دولاراً أو المبلغ الذي تم الحصول عليه قبل إخطار الجهة المصدرة، أيهما أقل.¹⁵ ولكن "الاستخدام غير المصرح به" يعني استخدام بطاقة الائتمان "بواسطة شخص، غير حامل البطاقة، لا يملك سلطة فعلية أو ضمنية أو ظاهرة لهذا الاستخدام، ولا يحصل حامل البطاقة من ورائه على أي فائدة"، ويجب تحديد ما إذا كانت هذه السلطة موجودة "بموجب قانون الولاية أو أي قانون آخر معمول به."¹⁵

ثم يغلق التفسير الرسمي الدائرة بنفس الطريقة التي تفعلها اللائحة E: "إذا قدم حامل البطاقة بطاقة ائتمان ومنح سلطة إجراء معاملات ائتمانية لشخص ما (مثل أحد أفراد الأسرة أو زميل في العمل) وتجاوز هذا الشخص السلطة الممنوحة له، يكون حامل البطاقة مسؤولاً عن المعاملة (المعاملات) ما لم يكن قد أخطر الدائن بأن استخدام بطاقة الائتمان من قبل هذا الشخص لم يعد مصرحاً به."¹⁵

استبدل الزميل بوكيل ذكي، وسيتوقف سقف الـ 50 دولاراً عن أداء الدور الذي يفترضه معظم الناس — إذا كان الوكيل، أو مزوده، يُعتبر "شخصاً" مُنح سلطة التصرف.

لم يتم صياغة أي من الإطارين مع وضع البرمجيات المستقلة في الاعتبار، ولا يوجد توجيه منشور من CFPB يطبق أياً منهما بشكل مباشر على الوكيل الذكي حتى أغسطس 2026. هذا الغموض هو الوضع الفعلي الحالي — وليس فجوة يسدها قانون AI AGENT Act.

جهة إصدار واحدة دعمت الإجابة مادياً

في 14 أبريل 2026، أطلقت American Express مجموعة أدوات المطورين لتجارب التجارة الوكيلية (ACE) وبجانبها "حماية مشتريات الوكيل" (Agent Purchase Protection).⁶

تتكون المجموعة من خمسة عناصر: تسجيل الوكيل، تفعيل الحساب، نية الشراء، تمرير بيانات الدفع المرمزة (tokenized)، وتسليم اختياري لسياق سلة التسوق من التاجر.⁶ وشمل الشركاء الداعمون عند الإطلاق كلاً من OpenAI وGoogle وMicrosoft وStripe وPayPal وAdyen وCloudflare وDelta وExpedia وHilton.⁶

أما الحماية فهي الجزء الذي أغفلته معايير حفظ السجلات. وقد وصف لوك جيب، النائب التنفيذي للرئيس ورئيس الابتكار العالمي في Amex، الحالة مباشرة:

إذا لم يرتكب التاجر أي خطأ ولم يرتكب حامل البطاقة أي خطأ، ولكن الوكيل (agent) هو من ارتكب الخطأ، فهذا يمثل نموذجاً جديداً في التجارة القائمة على الوكلاء اليوم، وهو أمر لم يتم التوصل إلى حل له بعد — كيفية التعامل مع ذلك.⁶

إجابة Amex: "طالما أننا نتعامل مع وكيل مسجل استخدم مجموعة أدوات المطورين الخاصة بنا للدخول والتسجيل وقاموا بمشاركة نية العميل... فعندئذ سندعم تلك المعاملة ونعوض المستهلك حتى لا يتحمل أي خسارة مادية."⁶

كما أن صياغة Gebb للسبب تستحق الاقتباس أيضاً، لأنها تشرح الفرق الهيكلي بين البروتوكول والضمان: "لم يقم أحد بعد بإدخال الجهة المصدرة (أو البنك) في المعادلة. وهنا، عندما تبدأ في إدخال الجهة المصدرة في المعادلة، تبدأ في الحصول على مسؤولية مالية قانونية عن المعاملات."⁶

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

ماذا يعني هذا إذا كنت تقوم ببناء وكلاء (agents)

هناك أربعة أمور تترتب على ذلك، ولا يتطلب أي منها تمرير مشروع القانون.

سجل النية، وليس الإجراءات فقط. تميل إمكانية مراقبة الوكيل (agent observability) إلى التركيز على استدعاءات الأدوات والمخرجات. ما تحتاجه النزاعات هو تعليمات المستخدم الأصلية، والقيود المهيكلة المستمدة منها، ودليل على أن المستخدم رأى ووافق على تلك النسخة المهيكلة قبل بدء التشغيل. قم بتخزين الثلاثة جميعاً، مع ختم زمني وغير قابلة للتغيير.

احمل معرف ارتباط (correlation ID) عبر كل خطوة. مقترح Luitel هو مرجع للمهمة — فريد لوظيفة واحدة، لا يحمل رقم حساب أو اسم، قصير المدى، وموجود في سجل كل شركة مشاركة.⁷ يمتلك المهندسون بالفعل شكل هذا في W3C Trace Context. تعامل مع إمكانية التتبع عبر الشركات كمتطلب للمنتج، وليس مجرد تحسين تشغيلي.

قم ببناء بوابة الموافقة الآن. يمنحك AARP الخاص بـ AuthZEN نمطاً قياسياً لـ "السياسة لا يمكنها التصريح بهذا بعد، إليك ما تحتاجه" — وطريقة للتسليم، والانتظار حتى يتدخل بشري، وإعادة التقييم بدلاً من الالتفاف حول الرفض.¹¹

إذا كنت قد كتبت بالفعل نظام الموافقة الخاص بك، فإن المسودة تستحق القراءة قبل تثبيتها. ينطبق المنطق نفسه على كيفية تحديد نطاق الوصول إلى الأدوات من خلال نموذج تفويض المؤسسات الخاص بـ MCP وكيفية منح الوكيل نفسه هوية قابلة للتحقق.

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

الخلاصة

اكتملت معظم القطع المفقودة في بنية تفويض الوكلاء بين مارس ويوليو من هذا العام: سجل نوايا مقاوم للتلاعب في Verifiable Intent، وحوكمة محايدة ومجموعة عمل جديدة في FIDO، ومعيار يتطلب الموافقة المسبقة في AuthZEN، وتفويض تشريعي لـ NIST لتحديد التفويض القابل للتحقق — كل ذلك بالإضافة إلى التفويضات الموقعة من AP2 منذ سبتمبر 2025.

كل هذه الأدوات توفر أدلة أفضل. لكن لا واحدة منها تحدد من يدفع.

هذا ليس سهواً في أي جهد فردي — بل هو الحد الذي تتوقف عنده هيئات المعايير وتبدأ عنده أنظمة المسؤولية القانونية. كان بإمكان قانون AI AGENT Act تجاوز هذا الحد لكنه اختار مجموعة عمل بدلاً من ذلك. كما أجل المشروع التجريبي لـ NIST صراحةً حالة المستهلك. وأوضح إجابة ملموسة حتى الآن جاءت من جهة إصدار بطاقات ذات نظام مغلق وميزانية عمومية.

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

المراجع