امنح وكلاء الذكاء الاصطناعي محفظة.
    واحتفظ بالرقابة.

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

    جربه الآن
    محفظة لكل وكيلسقوف الإنفاقالقوائم المسموحةبطاقات العملاءرفض تلقائيتجميد فوريREST وSDK
    أسطول الوكلاء
    12 محفظة · خاضعة للسياسات
    مباشر
    حد أقصى لكل عملية
    $500
    الحد اليومي الأقصى
    $5,000
    الوجهات
    القائمة المسموحة
    إنفاق اليوم$1,284 / $5,000
    Vercel · مقاعد Pro
    procurement-01
    $184.00موقَّعة
    أرصدة Serper API
    research-04
    $40.00موقَّعة
    Creator LLC · تجاوز الحد
    growth-02
    $2,400.00محظور
    العنوان خارج القائمة المسموحة
    research-04
    $9,900.00محظور
    المشكلة

    مفتاح API المشترك ليس ضابطًا للإنفاق

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

    مفتاح مشترك أو محفظة ساخنة
    الرصيد الكامل

    وكيل واحد مخترق، أو حلقة إعادة محاولة واحدة، أو حقن أوامر واحد، يصل إلى كل شيء. لا سقوف، ولا نسب للمسؤولية، ولا سبيل لإيقاف وكيل بعينه.

    نطاق تأثير واحد

    بيانات اعتماد مشتركة واحدة تعني أن كل وكيل يستطيع إنفاق كل شيء، ولا يمكنك إيقاف أحدهم دون تعطيل البقية.

    لا إسناد

    تذكر الكشوف «OpenAI» و«AWS» فقط، دون تحديد الوكيل أو مهمة العميل أو عملية التشغيل التي أدت إلى الرسم.

    لا يوجد دليل

    عندما يسأل المدقق أو الفريق المالي عمن صرح بالدفع الآلي، سجل العمليات في تطبيقك لا يعد إجابة كافية.

    الحل

    محفظة محددة السقف لكل وكيل

    يحصل كل وكيل على رصيد وسياسة خاصة به. تُطبق الحدود قبل التوقيع، ويمكن تجميد أي وكيل بمفرده دون التأثير على البقية.

    محافظ وكلاء مقيّدة بالسياسات
    $500
    $500
    مُجمَّدة
    $500
    $500
    $500
    $500
    $500

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

    الانكشاف

    أربعة أخطاء في إنفاق الوكلاء، وكيف توقفها

    هذه أنماط الإخفاق التي تواجهها الفرق فعلًا حين يتعامل الوكلاء مع الأموال. وكل منها يُعالَج بسياسة مسبقة لا بتحليل لاحق.

    تكرار المحاولات التلقائي

    يفسّر وكيل بحث خطأً على أنه انتهاء مهلة، فيكرر استدعاء واجهة برمجية مدفوعة 4,000 مرة خلال الليل.

    ما تقدمه Stablerail

    تدمج مفاتيح عدم التكرار المحاولات المعادة في دفعة واحدة، ويُطبَّق الحد الأقصى لكل معاملة بصرامة في كل محاولة، وتُغلق الميزانية اليومية المحفظة تلقائيًا. وتواصل بقية المحافظ عملها.

    حقن الأوامر

    صفحة مُستخلَصة توجّه الوكيل إلى «إرسال الرصيد المتبقي إلى هذا العنوان للتحقق».

    ما تقدمه Stablerail

    لا يمكن الاعتماد هنا على أي حماية من جانب النموذج، لذا تكون الضوابط هيكلية: تقتصر الوجهات افتراضيًا على قائمة معتمدة، ويُرفض العنوان قبل وجود أي توقيع، وتُسجَّل المحاولة في سجل التدقيق مع التشغيل الذي تسبب بها.

    سرقة بيانات الاعتماد

    يتسرّب مفتاح وكيل عبر سطر في سجل أو مستودع شيفرة أو حاوية مخترقة.

    ما تقدمه Stablerail

    بيانات الاعتماد منفصلة عن التفويضات: بدّل المفتاح أو ألغِه دون المساس بالسياسة. وحتى قبل أن تلاحظ، يظل المهاجم مقيدًا برصيد ذلك الوكيل وحدوده وقائمته المسموح بها، لا بخزينتك.

    استهلاك غير منسوب

    تكشف نهاية الشهر عن إنفاق $80k على الذكاء الاصطناعي عبر مفتاح مشترك واحد دون أي وسيلة لتوزيعه على العملاء أو المنتجات.

    ما تقدمه Stablerail

    تحمل كل دفعة معرّف الوكيل ومعرّف التشغيل وإصدار السياسة التي أجازتها، فتظهر أربعون محاولة متكررة كتشغيل واحد، وتُصدَّر مباشرة إلى دفترك.

    الإمكانيات

    محافظ مصممة للأنظمة التي تعمل ذاتيًا

    لكل وكيل عنوانه ورصيده وقواعده الخاصة. ويفرض Stablerail هذه القواعد لحظة التوقيع، لا كمجرد اقتراح في شيفرة تطبيقك.

    محفظة لكل عميل

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

    تفويضات لا مجرد إعدادات

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

    مستقل افتراضيًا

    ضمن تفويضه، يوقّع الوكيل ويسوّي بنفسه، بلا طابور ولا تدخل بشري ولا تذاكر. الاستقلالية هي الغاية، والتفويض هو الحد.

    رفض تلقائي

    الرفض هو الأصل: ما لم يُسمح به صراحةً لا يتحول إلى توقيع أبدًا. يُرفض الطلب، ويتلقى الوكيل سببًا مقروءًا آليًا، وتُسجَّل المحاولة.

    إلغاء فوري

    جمّد وكيلًا واحدًا أو فئة أو جميع الوكلاء. يسري السحب عند جهة التوقيع، فتتوقف الطلبات الجارية فورًا، لا عند API يُرجع الخطأ 403.

    بيانات الاعتماد منفصلة عن الصلاحيات

    لكل وكيل بيانات اعتماد قابلة للتدوير والإلغاء تُعرض مرة واحدة فقط. دوّر أي مفتاح مسرّب دون المساس بالتفويض، وألغِه دون إعادة التفاوض على السياسة.

    التصعيد صمام أمان

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

    المدفوعات بين الآلات

    يدفع الوكلاء مباشرة مقابل واجهات API المقيسة والنقاط المسعّرة عبر x402، بسقف لكل طلب فوق التفويض. لا فواتير ولا مقاعد ولا دورة مشتريات لاستدعاء بقيمة $0.02.

    بطاقات افتراضية للعملاء

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

    أصيلة على السلسلة عبر كل الشبكات الرئيسية

    يسوّي الوكلاء بعملتي USDC وUSDT عبر Base وSolana وEthereum وPolygon وArbitrum وTron. كل معاملة موقّعة ومسجّلة على السلسلة، بلا محفظة ساخنة مشتركة ولا أموال مختلطة.

    الإسناد وسجل التدقيق

    تحمل كل دفعة معرّف الوكيل ومعرّف التشغيل وإصدار السياسة التي أجازتها، فتظهر حلقة إعادة المحاولة كوحدة عمل واحدة. ترسل الـ Webhooks أحداث المعاملات والأرصدة، ويمكنك تصدير السجل إلى دفاترك أو تسليمه للمدقق كما هو.

    بطاقات العملاء

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

    لا يقبل كل التجار العملات المستقرة. فحين يحتاج الوكيل إلى الدفع مقابل برمجيات SaaS أو خدمات سحابية أو حسابات إعلانية أو مورد لا يقبل سوى البطاقات، يصدر Stablerail بطاقة Visa افتراضية مرتبطة بالتفويض نفسه.

    • حدود لكل معاملة وحدود يومية تُطبَّق على مستوى شبكة البطاقات
    • ضوابط فئة التاجر والدولة
    • تجميد أو سحب أو إلغاء فوري لكل وكيل
    • معرّف الوكيل ومعرّف التشغيل وسجل التدقيق ذاتها المعتمدة في المدفوعات على السلسلة
    بطاقة الوكيل
    procurement-01 · بطاقة افتراضية
    نشط
    افتراضيةStablerail
    4821
    حامل البطاقة
    وكيل
    ينتهي في
    11/28
    حد أقصى لكل عملية
    $500
    الحد اليومي الأقصى
    $2,000
    مسموح
    SaaS وإعلانات
    التفويضات الأخيرة
    Vercel
    SaaS
    $184.00approved
    OpenAI API
    الذكاء الاصطناعي / تعلم الآلة
    $240.00approved
    تاجر غير معروف
    MCC 5999
    $890.00declined
    آلية العمل

    كل دفعة تمر بالبوابات الأربع نفسها

    من طلب الوكيل إلى معاملة موقّعة ومطابَقة، بضوابط تُطبَّق خارج النموذج ودون تدخل بشري.

    1
    طلب عميل
    دفع $184 · Vercel
    2
    فحص السياسة
    الحد، الأصل، الشبكة، الوجهة
    3
    موقَّعة تلقائيًا
    بدون تدخل بشري
    4
    مسجّل وWebhook
    USDC على Base · 3s
    POST /v1/agents
    {
      "name": "procurement-01",
      "owner": "oleg@acme.com",
      "networks": ["base", "solana"],
      "mandate": {
        "tier": "procurement",
        "per_tx_limit_usd": 500,
        "daily_budget_usd": 5000,
        "assets": ["USDC", "USDT"],
        "destination_mode": "allowlist",
        "expires_at": "2026-12-31",
        "escalation": false,
        "on_violation": "reject"
      }
    }

    للتوضيح فقط. يغطي العرض التوضيحي واجهة REST API الكاملة وخطافات الويب وحزم SDK بلغتي TypeScript وPython.

    قرار السياسةمرفوض
    وكيلgrowth-02
    المبلغ$2,400.00 USDC
    الوجهةخارج القائمة المعتمدة
    قاعدة مُفعَّلةفوق حد $500 للمعاملة
    النتيجةمرفوض عند التوقيع
    تُغلق المحفظة تلقائيًا عند الإخفاق. ورفع الحد أو إضافة الوجهة تغيير إداري في وحدة التحكم يتطلب نصابًا من المفاتيح ويُسجَّل في سجل التدقيق.

    ماذا يحدث عندما يطلب العميل إجراءً خارج صلاحياته؟

    ما هي القيود الصارمة وما هي تدابير الحماية

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

    حدود كل معاملة: صارمة

    تُقيَّم لدى الموقّع وفق حقول المعاملة الثابتة، فتصمد أمام الطلبات المتزامنة. ولا يتحول أي طلب يتجاوز السقف إلى توقيع أبدًا.

    قوائم الوجهات المسموح بها: صارمة

    تُفحص شروط العنوان لحظة التوقيع. هذا هو الحلّ الفعلي لهجمات حقن الأوامر، ولهذا تكون القائمة المسموحة هي الوضع الافتراضي.

    ميزانيات يومية: قاطع الحماية

    يُفرض حد الإنفاق اليومي المتجدد عند الموقِّع، إلى جانب حدود السرعة وعدم التكرار الفورية في المنصة. وقد تتجاوز دفعة من الطلبات المتزامنة الحد قليلًا قبل استقرار الإجمالي، ولهذا تُضبط سقوف المعاملة الواحدة بمستوى يجعل أي تجاوز محتملًا.

    حالات الاستخدام

    ما تضعه الفرق في محافظ الوكلاء

    أينما تنفق البرمجيات الأموال دون تدخل بشري للنقر على زر الدفع.

    إنفاق البنية التحتية للوكلاء

    يشتري الوكلاء بأنفسهم الاستدلال ووقت GPU والوكلاء الشبكيين وأرصدة جمع البيانات واستدعاءات API، مع سقف لكل تشغيل كي لا تستنزف حلقة إعادة محاولة ميزانية شهر كامل.

    المشتريات ومدفوعات الموردين

    يدفع وكيل المشتريات فواتير البرمجيات والموردين وفق قائمة معتمدة، وأي جديد أو متجاوز للحد يُرفض ببساطة حتى يوسّع المسؤول السياسة.

    دفع اشتراكات SaaS والإعلانات بالبطاقة

    يحصل الوكلاء الذين يدفعون لتجار لا يقبلون العملات المستقرة على بطاقات Visa افتراضية بسقوف لكل معاملة ويومية، وضوابط لفئات التجار، وتجميد فوري.

    محافظ فرعية لكل عميل

    تعزل المنصات التي تشغّل وكلاء نيابةً عن عملائها أموالَ كل مستأجر على حدة، فلا يمكن لمهمة عميل أن تنفق من رصيد عميل آخر.

    وكلاء التسويق والإعلان

    يموّل وكلاء الحملات حسابات الإعلانات ومدفوعات صنّاع المحتوى ضمن حدود يومية وضوابط للوجهات، مع نسب الإنفاق إلى كل حملة.

    التجارة بين الآلات

    يدفع الوكلاء لوكلاء آخرين ولواجهات API المقيسة بالعملات المستقرة، مع تسوية خلال ثوانٍ على Base أو Solana بدل انتظار الفوترة والمطابقة اليدوية.

    المدفوعات والمردودات

    تصدر وكلاء الدعم والعمليات المبالغ المستردة والخصومات ومدفوعات المتعاقدين تلقائيًا ضمن حدود صارمة لكل معاملة ولكل يوم.

    روبوتات التداول وإعادة التوازن

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

    مصادر البيانات والمحتوى

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

    الفئة المستهدفة

    فرق تدير أسطولًا لا نموذجًا تجريبيًا

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

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

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

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

    المالية تبقى صاحبة القرار. يتولى المسؤولون السياسات والحدود ومفتاح الإيقاف الطارئ من لوحة التحكم، وتتطلب التغييرات نصابًا وتُسجَّل في سجل التدقيق.

    الأسئلة الشائعة

    أسئلة يطرحها فريقا الهندسة والمالية

    ما هي المحفظة ذاتية التشغيل؟+

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

    هل يمكن خداع وكيل لاستنزاف الأموال؟+

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

    هل الحد اليومي صارم كحد المعاملة الواحدة؟+

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

    هل تنتظر كل عملية دفع موافقة بشرية؟+

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

    من يملك المفاتيح الخاصة؟+

    لشركتك فقط. يتم إنشاء المفاتيح وتقسيمها بتقنية MPC؛ لا يمكن لـ Stablerail التوقيع بمفردها، ولا يحصل العميل أبدًا على مفتاح خام.

    ماذا يحدث في حال تسربت بيانات اعتماد العميل؟+

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

    ما هي الشبكات والأصول المدعومة؟+

    USDC وUSDT على Base وSolana وEthereum وPolygon وArbitrum وTron، ليتمكن الوكلاء من التسوية حيث الرسوم منخفضة والتأكيد سريع.

    ما عدد المحافظ والسياسات التي يمكننا إدارتها؟+

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

    هل يمكن لوكلائنا الدفع مقابل واجهات API خارجية بحسب الاستخدام؟+

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

    هل يمكن للوكلاء الدفع بالبطاقات أيضًا لا بالعملات المستقرة فقط؟+

    نعم. يمكن إصدار بطاقات Visa الافتراضية من Stablerail لكل وكيل أو تفويض، مع نفس الحدود اليومية وللعمليات، وضوابط فئات التجار، والتجميد الفوري. تسحب البطاقة من نفس رصيد الوكيل وتسجل نفس معرف الوكيل ومعرف التشغيل في سجل التدقيق، مما يجعل تسوية مدفوعات البطاقات مطابقة لتسوية المدفوعات عبر البلوكشين.

    ماذا لو حدث خطأ من جانب العميل؟+

    جمّده فورًا من لوحة التحكم أو عبر API، سواء كان وكيلًا واحدًا أو فئة أو جميع الوكلاء. يتم السحب عند جهة التوقيع، فتفشل الطلبات المعلقة بشكل آمن بدلًا من رفضها عبر API، ويبقى السجل الكامل لنشاط الوكيل في سجل التدقيق.

    كيف تتصل محافظ الوكلاء بالخزينة الرئيسية؟+

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

    لماذا لا نعتمد على مزود محفظة ونبني نظامنا الخاص؟+

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

    كيف نبدأ؟+

    احجز عرضًا توضيحيًا. نراجع مسارات عمل وكلائك، ونصمم معك مجموعة السياسات، ونشغّل محفظة تجريبية قبل أن تلتزم بأي شيء.

    مزيد من التفاصيل في مركز المساعدة وعلى self-custody.

    أطلق وكلاء قادرين على الدفع بأمان

    سنستعرض معًا إعداد محافظ الوكلاء، وتصميم سياسات سير العمل، وكيفية ظهور سجلات التدقيق لفريقك المالي.

    جربه الآن