لقد راقبت عن كثب دفع شركة تيثر لإدخال وكلاء الذكاء الاصطناعي في المدفوعات الرقمية، وبرز لي أمر واحد: منح وكيل ذكاء اصطناعي إمكانية الوصول إلى محفظة لا يعني بالضرورة تحديد ما إذا كان يُسمح له فعليًا بإنفاق الأموال. ويمكن أن يصبح هذا الفارق واحدًا من أكبر التحديات عندما تصبح الوكلاء الماليون المستقلون أكثر شيوعًا.
حدّد الرئيس التنفيذي لشركة تيثر، باولو أردوينو، رؤية أوسع يَتَمكن فيها البشر والآلات ووكلاء الذكاء الاصطناعي من التفاعل مع الأموال القابلة للبرمجة، مع بقاء المستخدمين مسيطرين على أموالهم. صُمّم «عدة تطوير محفظة تيثر» (WDK) لدعم هذه الرؤية، لكن أدوات المحفظة الأحدث تُبرز أيضًا مسؤولية مهمة للمطوّرين: تحديد حدود السلطة المالية لوكيل الذكاء الاصطناعي.
تفصل واجهة سطر أوامر WDK الخاصة بـTether بين وصول المحفظة والموافقة على المعاملات. يمكن للمستخدم إلغاء قفل المحفظة لجلسة مؤقتة، وبعد ذلك قد تطلب عملية أخرى تعمل ضمن حساب نظام التشغيل نفسه معاملات عبر نقطة نهاية المحفظة المحلية. لا يحتاج الوكيل بالضرورة إلى كلمة مرور المحفظة مرة أخرى مقابل كل عملية دفع.
يؤدي ذلك إلى تمييز مهم بين "إدارة المفاتيح ذاتيًا" و"التحكم في الإنفاق". إن إبقاء المفاتيح الخاصة تحت سيطرة المستخدم يحمي إدارة الأصول، لكنه لا يحدد تلقائيًا أي مستلم يمكن للذكاء الاصطناعي أن يدفع له، أو مقدار ما يمكنه إنفاقه، أو أي عمليات يمكنه تنفيذها.
تستمر جلسة واجهة سطر الأوامر الافتراضية لمدة خمس دقائق بعد إلغاء القفل، بينما يمكن للمستخدمين قفله في وقت أبكر أو إلغاء القفل مرة أخرى لإعادة تشغيل المؤقت. ويمكن أيضًا تهيئة الجلسة دون انتهاء تلقائي.
تساعد هذه الضوابط على تقليل مدة بقاء المحفظة غير المقفلة قابلة للوصول، لكن الجلسة القصيرة لا تنشئ تلقائيًا حدًا للإنفاق. قد يظل بإمكان الذكاء الاصطناعي إجراء عدة معاملات خلال الفترة التي تكون فيها المحفظة متاحة.
يصف Tether وصول المستخدم نفسه بأنه بديل عملي لمحفظة ساخنة، ويوصي بإجراءات مثل استخدام محفظة مخصصة، والاحتفاظ بكمية محدودة فقط داخلها، وفصل المحفظة ضمن حساب نظام تشغيل مخصص. هذه احتياطات وليست دليلًا على وجود ثغرة تم الإبلاغ عنها أو سرقة.
تضيف واجهة MCP طبقة أخرى. تحافظ أدواتها المدمجة على إدارة المحفظة الحساسة، مثل تصدير البذور وإلغاء القفل، خارج مجموعة الأدوات التي يواجهها الوكيل. ومع ذلك، يعتمد هذا الحماية على كيفية تهيئة البيئة. إذا كان لدى عميل ذكاء اصطناعي أيضًا وصول مستقل إلى سطر الأوامر (shell)، فقد لا تغطي قيود قائمة أدوات MCP كل مسار ممكن إلى المحفظة.
بالنسبة للتحويلات، توصي Tether بسير عمل أكثر أمانًا: أولًا معاينة المعاملة، ثم عرض تفاصيل مثل الشبكة والمستلم والرمز والمبلغ والرسوم التقديرية، وبعد ذلك الحصول على تأكيد قبل بثها.
لكن توجد نقطة حاسمة هنا: "التأكيد الموصى به" ليس بالضرورة هو نفسه "التفويض المفروض". قد يستطيع الخادم/الـdaemon الأساسي معالجة طلب معاملة صالح من محفظة غير مقفلة دون إثبات أن خطوات المعاينة والتأكيد السابقة قد حدثت بالفعل.
هذا يعني أن موقع فحص الأمان يهم. قد تبدو شاشة الموافقة المصقولة مطمئنة، لكن إذا كان هناك مسار آخر مسموح يمكنه تجاوز تلك الشاشة، فإن تقييد الإنفاق لا يكون أقوى من تصميم التطبيق المحيط به.
يمنح WDK المطورين أدوات إضافية عبر مجموعة تطوير البرمجيات (SDK). يمكن لسياسات المعاملات المحلية تعريف قواعد ALLOW وDENY لعمليات محددة تخص محفظة أو بروتوكول معين، بما في ذلك شروط تتضمن مستلمين معتمدين وأحجام المعاملات.
لكن هذه الضوابط ليست بيئة معزولة كاملة. فهي تعمل محليًا وضمن نطاق محدد، ما يعني أن على المطورين فهم العمليات وإشارات الحسابات التي تقع خارج تلك الفحوصات.
يصبح ذلك مهمًا بشكل خاص عندما يَعِد المطورون المستخدمين بحد إنفاق تراكمي.
على سبيل المثال، حظر معاملة واحدة تتجاوز 100 دولار لا يفرض تلقائيًا ميزانية يومية قدرها 500 دولار. يجب على التطبيق تتبّع الإنفاق السابق، والحفاظ على هذه المعلومات بشكل موثوق، والتعامل مع طلبات متزامنة بشكل صحيح. وبعبارة أخرى، تتطلب "حدود الإنفاق اليومية" المحاسبة إضافة إلى فحوصات على مستوى المعاملة.
تتبع أداة MCP Toolkit المنفصلة لدى Tether نهجًا مختلفًا. تستخدم أدوات الكتاب المدمجة فيها موافقة المستخدم الصريحة قبل بث المعاملات، بينما يمكن للمطورين اختيار الأدوات التي يريدون كشفها ويمكنهم إنشاء عمليات إضافية.
هذه المرونة مفيدة، لكنها أيضًا تضع مسؤولية أكبر على المطور. كلما أصبح الوكيل مخصصًا أكثر، زادت الحاجة إلى تحديد أذوناته بعناية.
تقدم Tether فعليًا مسارات مختلفة لمختلف حالات الاستخدام: واجهة سطر الأوامر (CLI) للمهام المحلية، وSDK للتطبيقات، وMCP Toolkit لخوادم وكلاء ذكاء اصطناعي مخصصة. وبذلك يمكن للمطورين اختيار مقدار الأتمتة ودرجة مشاركة البشر التي يريدونها.
المقايضة واضحة. "وافق على كل معاملة" يمنح المستخدمين تحكمًا مباشرًا في كل عملية دفع. "حدّد ميزانية إنفاق ودع الوكيل يعمل" يوفر أتمتة أكبر، لكنه يتطلب قواعد موثوقة تشمل المبالغ والمستلمين وأنواع المعاملات والإنفاق التراكمي.
بالنسبة للمستخدمين، ليست المسألة الحقيقية فقط ما إذا كانت محفظة الذكاء الاصطناعي مُدارة ذاتيًا أم أنها تعرض موجه موافقة.
الأسئلة المهمة هي: "كم يمكن لهذا الوكيل أن ينفق؟" "إلى أين يمكنه إرسال أموالي؟" و"ما الذي يحدد بالضبط نهاية صلاحيته؟"
يمكّن نهج Tether لإدارة المفاتيح ذاتيًا (self-custody) المطورين من بناء أنظمة مالية مدعومة بالذكاء الاصطناعي دون تسليم ملكية المحفظة إلى وسيط مركزي. لكن طبقة الحماية الأخيرة تقع على عاتق المنتج نفسه.
قد لا تكون أكبر التحديات هي منح وكلاء الذكاء الاصطناعي إمكانية الوصول إلى المال. قد يكون التحدي هو التأكد من أن السلطة التي نعطيها لهم محدودة تمامًا بالقدر الذي نعتقده.