DEV Community

Edison Flores
Edison Flores

Posted on

‏فيزا لديها بروتوكول للوكلاء الموثوقين، وماستركارد لديها Verifiable Intent. وهذه هي الطبقة التي لا يمنحك أي منهما (بالعربية)

#ai #security #agents #ar

نسخة مختصرة بالعربية. النسخة الكاملة بالإنجليزية —بما في ذلك نقاش الإبطال (revocation) الذي فتحه Alex Shev في التعليقات— هي النسخة المرجعية.

لماذا بالعربية

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

ما الذي حدث للتو

في 2026 توقّفت شبكات الدفع عن الحديث عن «تجارة الوكلاء» بشكل مجرّد وبدأت بنشر المواصفات:

  • فيزا نشرت Trusted Agent Protocol (TAP): مستودع مفتوح يضم المواصفة وتطبيقاً مرجعياً كاملاً (سجلّ الوكلاء، وخلفية وواجهة التاجر، ووكيل حيّ). كل طلب من الوكيل يحمل توقيعاً تشفيرياً مع طابع زمني ومعرّف جلسة فريد ومعرّف مفتاح وخوارزمية — مرتبط بنطاق التاجر وبالعملية المحددة، بحيث لا يمكن إعادة تشغيله.
  • ماستركارد أطلقت Verifiable Intent (VI): يتحقق التاجر من اعتماد النية الموقّعة في الوقت الحقيقي داخل تدفّق التفويض، قبل أن يتحرك المال.
  • في المحيط: x402 (كوينبيز → مؤسسة لينكس) وAP2 (جوجل + فيزا + ماستركارد + باي بال + نحو 60 شريكاً).

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

الفجوة التي لا يغطّيها أحد

ما لا يستطيع طرف ثالث فعله بهذه البروتوكولات:

  1. تدقيق المُتحقِّق. من أين تعلم أن الجهة التي تقول «هذا الوكيل موثوق» ليست فاسدة أو مرقّعة أو تحفظ الإجابات عن ظهر قلب؟ في بروتوكول الشبكة، تثق بالحُكم لأنك تثق بالشبكة. استدلال دائري.
  2. إعادة إنتاج الاعتماد. هل يستطيع خارجي إعادة بناء المصنوع من البايتات العامة والحصول على النتيجة نفسها، بتّاً ببتّ؟
  3. إيجاد دليل غير قابل للتعديل. أين السجل الملحقي (append-only)، المستضاف لدى طرف ثالث، الذي يثبت ما نُشر ومتى — والذي لا يستطيع حتى الناشر نفسه إعادة كتابته؟

الفرق في سطر واحد: TAP وVI تمنحان الوكيل إذناً بالتعامل داخل شبكة. أما ATC فتمنح أيّ كان دليلاً قابلاً للتحقق خارج كل الشبكات — دون اتصال، بلا عضوية، وبلا مفتاح API.

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

الدروس الثلاثة التي طبّقناها

  1. من فيزا: الطزاجة يجب أن تكون من الطرفين ومستمدة من البايتات. المُشغّل المرجعي عندنا يفرض نافذة صلاحية من الطرفين — issued_at <= NOW < expires_at. بطاقة مؤرّخة في المستقبل (متجهتنا premature-atc، الصادرة 2030-01-01) تفشل تماماً كالبطاقة المنتهية. والفحص يُستنبط من بايتات البطاقة ذاتها لا من بيانات جانبية — فبيان جانبي كاذب أو محذوف لا يقلب الحُكم.
  2. من ماستركارد: التحقق مكانه داخل التدفّق — ونسختنا تعمل دون اتصال. تُتحقق بطاقة ATC دون اتصال في أجزاء من الثانية: فحص Ed25519 واحد مقابل مراسٍ مثبّتة، صفر نداءات شبكية، صفر مفاتيح API، صفر عضويات. تحققٌ داخل التدفّق دون استئذان التدفّق.
  3. من كلتيهما: سجلّ — لكن ملحقي وخارج سيطرتنا. كل إصدار من حزمة المطابقة عندنا موقع مضادّاً ومُرتكز في Rekor، سجل الشفافية العام من Sigstore. الإدخال رقم 3 (logIndex 2764479676) يحمل بصمات كامل حزمة v1.3.3. لو حاولنا تعديل التاريخ بصمت، لفضحنا السجل.

الإيصالات (كلها قابلة للتحقق من غريب، روابط حيّة)

الخلل الذي دفعنا إلى v1.3.3 اكتشفه غريب شغّل أدواتنا نفسها ضدنا. ليست فضيحة — هذا هو المنتج وهو يعمل.

خاتمة صادقة

العمالقة سيفوزون بطبقة الإذن في تجارة الوكلاء — فالشبكات وُجدت لذلك. أما ما نبنيه نحن فهو القطعة التي لا تبيعها الشبكات ببنيتها: دليل لا يتطلب الثقة بالبائع. عندما تسأل مؤسسة «من يدقّق المدقّقين؟»، لا يمكن أن تكون الإجابة «المدقّقون». يجب أن تكون: أيّ كان يستطيع — وهذه هي الأوامر.

لقد صادقوا على الطبقة. ونحن نحتفظ بالإيصالات.

— AliceLabs / MarketNow · marketnow.site · UTA على GitHub

Top comments (0)