OneCLI
بوابة بيانات اعتماد مفتوحة المصدر لوكلاء الذكاء الاصطناعي: خزّن مرة واحدة واحقن في كل مكان، والمفاتيح لا تظهر للوكيل أبدًا
تقرير معمّق
-
OneCLI عبارة عن بوابة اعتماد مفتوحة المصدر لوكلاء الذكاء الاصطناعي المحتضنة في دفعة Y Combinator Summer 2026 ولديها أكثر من 2800 نجمة على GitHub. إنه يحل إحدى أصعب المشكلات الأمنية في عصر الوكيل: يحتاج الوكيل إلى استدعاء واجهات برمجة التطبيقات الخارجية، ولكن تسليم المفتاح مباشرة إلى الوكيل يعادل لصق كلمة المرور الآمنة على الباب. يتمثل حل OneCLI في إدراج بوابة وكيل شفافة بين الوكيل والخدمة المستهدفة. يتم تشفير بيانات الاعتماد الحقيقية وتخزينها في البوابة. يحتفظ الوكيل فقط برمز العنصر النائب، وتكمل البوابة استبدال "المفتاح المزيف → المفتاح الحقيقي" في لحظة إرسال الطلب. في وقت كتابة هذا التقرير، تم تنزيل المشروع أكثر من 320.000 مرة وتم اختياره كطبقة بيانات الاعتماد الافتراضية بواسطة NanoClaw.
-
شارك في تأسيس OneCLI كل من جاي بن أهارون وجوناثان فيشنر. تركز خلفيات المؤسسين على الهندسة الأمنية: كان جاي هو المهندس الأول في شركة Argon (التي استحوذت عليها شركة Aqua Security لاحقًا)، وعمل جوناثان في مجال الوصول إلى شبكة الثقة المعدومة في شركة Axis Security (التي استحوذت عليها شركة HPE لاحقًا)، وكلاهما قادم من المخابرات العسكرية الإسرائيلية. في السابق، عمل الاثنان معًا على أداة قاعدة البيانات مفتوحة المصدر ChartDB (أكثر من 20000 نجمة على GitHub). جاء الدافع وراء الإنشاء من التجربة الشخصية: عندما كانوا يقومون ببناء طبقة تنسيق الوكيل لـ ChartDB، لم يتمكنوا من العثور على طريقة آمنة لتوزيع بيانات الاعتماد على الوكلاء المستقلين. توصلت أبحاث الفريق إلى أن جميع الفرق تقريبًا التي تستخدم Agent إما قامت بترميز مفتاح API في ملف .env أو ارتجلت حل الوكيل. في يوليو 2026، أصبح المشروع مفتوح المصدر رسميًا وظهر على Hacker News "Show HN"، وسرعان ما اكتسب اهتمام المجتمع. قامت Y Combinator بالترويج لـ OneCLI علنًا من خلال حساب X الرسمي الخاص بها في 23 يوليو 2026، مع تعريفها بأنها طبقة بنية تحتية "تسمح لوكلاء الذكاء الاصطناعي بالقيام بعمل حقيقي دون تخزين كلمات المرور". يستخدم OneCLI ترخيص Apache-2.0 ولا يزال في مرحلة التكرار السريع المبكرة (الإصدار 1.42.0+)، لكن شركات مثل Docker وMindsDB وZoho وCoralogix وما إلى ذلك بدأت في استخدامه.
-
ينقسم سير العمل الأساسي لـ OneCLI إلى ثلاث خطوات. في الخطوة الأولى، يقوم المشغل بتخزين بيانات اعتماد واجهة برمجة التطبيقات الحقيقية في مخزن OneCLI المشفر؛ في الخطوة الثانية، يتم إصدار مفتاح نائب (مثل FAKE_KEY) لكل وكيل، ويستخدم الوكيل هذه المفاتيح المزيفة عند تقديم طلبات HTTP؛ في الخطوة الثالثة، تعترض بوابة OneCLI الطلب، وتكمل فك التشفير واستبدال بيانات الاعتماد قبل أن يغادر الطلب البوابة وفقًا لقواعد مطابقة المضيف والمسار، وأخيرًا تعيد توجيه الطلب الذي يحمل بيانات الاعتماد الحقيقية إلى الخدمة المستهدفة. خلال العملية برمتها، لا يتواصل الوكيل مطلقًا مع المفتاح الحقيقي في أي وقت. في حزمة التكنولوجيا، يتكون OneCLI من ثلاث طبقات. تعد بوابة HTTP عالية الأداء المكتوبة بلغة Rust مسؤولة عن اعتراض الطلبات الصادرة وإدخال بيانات الاعتماد. يحمل الوكيل رمز الوصول من خلال رأس تفويض الوكيل لإكمال مصادقة الهوية. يتم استخدام لوحة معلومات الويب التي أنشأها Next.js لإدارة الوكلاء والمفاتيح والأذونات. تقوم البوابة ديناميكيًا بتوزيع بيانات الاعتماد التي يجب إدخالها لكل طلب من خلال واجهة برمجة التطبيقات التي تعرضها لوحة المعلومات. تستخدم طبقة تخزين بيانات الاعتماد تشفير AES-256-GCM. يتم فك تشفير المفتاح فقط عند حدوث طلب. بعد فك التشفير، تتم مطابقته بدقة وفقًا لأنماط المضيف والمسار ثم يتم إدخاله في شكل رؤوس طلب أو معلمات URL. النشر بسيط للغاية ويمكن أن يبدأ بأمر واحد فقط: docker run -d --name onecli -p 10254:10254 -p 10255:10255 -v onecli-data:/app/data ghcr.io/onecli/onecli بعد بدء التشغيل، قم بزيارة http://localhost:10254 لإنشاء وكيل، وإضافة مفتاح، ثم قم بتوجيه وكيل HTTP الخاص بالوكيل إلى localhost:10255. لا يتطلب إطار عمل الوكيل أي تعديل للكود - يمكن الوصول إليه طالما أنه يدعم إعداد متغير البيئة HTTPS_PROXY. يتضمن ذلك Claude Code وCodex وCursor وCline والأطر السائدة مثل OpenClaw وNanoClaw وLangChain وCrewAI. يوفر OneCLI أيضًا أداة سطر أوامر onecli CLI، والتي تسمح للوكلاء بإدارة هوياتهم ومفاتيحهم بشكل مستقل من خلال أوامر Shell - يستطيع Agent Orchestrator إنشاء وكلاء جدد وتعيين بيانات الاعتماد وتكوين القواعد في برنامج نصي دون التشغيل اليدوي للوحة المعلومات.يدعم الوضع المحلي التشغيل بدون تسجيل دخول لمستخدم واحد دون تكوين NEXTAUTH_SECRET. يمكن لتعاون الفريق تمكين مصادقة Google OAuth. تحتوي كافة متغيرات البيئة على قيم افتراضية معقولة، والتي يتم إنشاؤها تلقائيًا عند عدم تعيين SECRET_ENCRYPTION_KEY.
-
OneCLI حاليًا مجاني تمامًا ومفتوح المصدر (Apache-2.0). تدعم الطبقة المجانية ما يصل إلى وكيلين ولا يلزم وجود بطاقة ائتمان. فريق المشروع حاليًا هو شركة ناشئة تحتضنها Y Combinator ولم يعلن بعد عن خطة تسعير محددة للنسخة التجارية الرسمية. تتضمن مسارات الأعمال التي يمكن التنبؤ بها دعمًا متعدد الوكلاء لإصدارات المؤسسات ومحركات السياسات المتقدمة وتكامل موفر الهوية على مستوى المؤسسة والخدمات السحابية المُدارة.
-
لقد كانت استجابة المجتمع الشاملة لـ OneCLI إيجابية، خاصة داخل مجتمع أمان الوكيل. أشار بعض المطورين في سلسلة مناقشة Hacker News إلى أن الحلول مثل حلول وكيل الاعتماد ليست جديدة (مثل Fly.io’s Tokenizer، وBuzzFeed SSO agent، وما إلى ذلك)، ولكن التطبيقات المصممة خصيصًا لسيناريوهات AI Agent قد خفضت بالفعل عتبة التنفيذ. شارك بعض المطورين أيضًا خططًا لاستخدام HashiCorp Vault مع البرامج النصية لتحقيق تأثيرات مماثلة، لكنهم اعترفوا بأن تجربة OneCLI "الجاهزة" أفضل. يُظهر الفيديو التجريبي الذي تم الترويج له بواسطة الحساب الرسمي لـ Y Combinator العملية الكاملة لاستدعاء Claude Code لواجهة برمجة تطبيقات GitHub من خلال بوابة OneCLI - يحتفظ الوكيل فقط بـ FAKE_KEY طوال العملية، ويتم حقن PAT الحقيقي بواسطة البوابة في لحظة تقديم الطلب. التقييمات من الجالية الصينية بناءة بشكل أساسي. أجرى بعض المطورين في حديقة المدونات اختبارات فعلية على OneCLI ويعتقدون أن "تكلفة التحويل الخاصة به تقترب من الصفر". ومع ذلك، بالنسبة للفرق التي تقوم بالفعل بتشغيل وكلاء بيئة الإنتاج، يجب إيلاء اهتمام خاص لإدارة شهادات HTTPS الخاصة بالبوابة وعزل الشبكة. وعلق آخرون بأن الإدارة المركزية لبيانات الاعتماد تعني أيضًا المخاطر المركزية - إذا تم اختراق خادم OneCLI، فسيكون لدى المهاجم هدفًا قيمًا للغاية.
-
تلقت OneCLI صحافة إيجابية من مصادر موثوقة متعددة. يُنظر إلى الترويج العام لـ Y Combinator على أنه إشارة إلى الصناعة بأن المسرّع يعتقد أن البنية التحتية لأمن الوكيل هي مسار مستقل يستحق التركيز. وقد أبلغت The Agent Times وWorld AI 360 ووسائل إعلام أخرى عن ذلك، ويُعتقد عمومًا أن نمط تصميم OneCLI - الذي يعزل بيانات الاعتماد خارج ذاكرة الوكيل - من المتوقع أن يصبح طبقة أمان قياسية لبنية الوكيل. من منظور مشهد المنتجات التنافسية، تأتي المنافسة الرئيسية التي تواجهها OneCLI من نوعين من الحلول. أحد هذه الأنواع هو أدوات إدارة المفاتيح التقليدية (HashiCorp Vault، AWS Secrets Manager، 1Password). تحل هذه الأدوات مشكلة التخزين، لكنها لا تحل مشكلة الحقن - لا يزال هناك خطر التسرب بعد حصول العميل على المفتاح. النوع الآخر هو إطار عمل الوكيل الناشئ (مثل بروتوكول MCP)، لكن تعريف أداة MCP يستهلك نافذة سياق الوكيل، ويتعامل كل خادم MCP مع المصادقة بشكل مستقل، ويفتقر إلى إدارة بيانات الاعتماد الموحدة. يتمثل تحديد موضع OneCLI المتمايز في العثور على مساحة فارغة بين هذين النوعين من الحلول: حل كل من التخزين والحقن دون استهلاك نافذة سياق الوكيل.
-
OneCLI لا يخلو من المخاطر. تكمن المشكلة الأساسية في نموذج MITM CA - تحتاج البوابة إلى الاحتفاظ بمفتاح CA لإصدار شهادات لأهداف عشوائية، مما يعني أنه على جهاز مشترك أو متعدد المستأجرين، يمكن أن تؤدي ثغرة أمنية في تصعيد الامتيازات إلى كشف مفتاح CA. يتطلب النشر عناية إضافية عند عزل حاوية Docker ومساحات أسماء الشبكة. على الرغم من أن المشروع يتكرر بسرعة وينمو المجتمع بسرعة، إلا أنه لا يزال في مرحلة v1.x، وقد تتغير واجهة برمجة التطبيقات وتنسيق التكوين مع ترقية الإصدار. بالنسبة للمؤسسات التي تتطلب ضمانات استقرار طويلة الأجل، يوصى باستخدام OneCLI كحل قابل للتقييم للتحقق من النموذج الأولي، مع الاحتفاظ بإدارة بيانات الاعتماد التقليدية كحل احتياطي. هناك مشكلة أخرى لا يمكن تجاهلها وهي الثقة المركزية - حيث تعمل بيانات الاعتماد المركزية في إدارة بوابة واحدة على تحسين كفاءة التشغيل والصيانة، ولكنها تعني أيضًا أن البوابة نفسها تصبح نقطة واحدة لهدف التفجير. يحتاج المشغلون إلى إجراء تقوية إضافية للبوابة، بما في ذلك على سبيل المثال لا الحصر: تقييد عناوين IP للوصول إلى لوحة المعلومات، وتمكين التخزين الخارجي لسجلات التدقيق، وتدوير مفاتيح التشفير بانتظام.
-
يعد OneCLI هو الأنسب لكلا النوعين من الفرق. الفئة الأولى هي فرق التطوير والتشغيل التي تقوم بتشغيل وكلاء الترميز (Claude Code، Codex، Cursor). يحتاج هؤلاء الوكلاء إلى الاتصال بشكل متكرر بواجهات برمجة التطبيقات الخارجية مثل GitHub وSlack وJira وما إلى ذلك، وقد يحتوي كل سطر من المخرجات على مفاتيح. الفئة الثانية هي فريق يقوم ببناء نظام تعاون متعدد الوكلاء يحتاج إلى إدارة وتدقيق الوصول إلى واجهة برمجة التطبيقات (API) لجميع الوكلاء بشكل موحد. تشمل السيناريوهات غير المناسبة ما يلي: الوكلاء الذين يعملون فقط في شبكات معزولة تمامًا، والفرق التي لديها بالفعل عمليات نشر ناضجة لـ HashiCorp Vault ولا ترغب في إضافة بنية تحتية إضافية، والمؤسسات المعيارية التي تتطلب عمليات تدقيق صارمة للامتثال (مثل SOC 2 Type II). بالنسبة للأخيرة، يوصى بالانتظار حتى يكمل OneCLI تدقيق أمان الجهة الخارجية قبل التفكير في النشر على مستوى الإنتاج.
-
تصطدم OneCLI بدقة بنقطة الألم الحقيقية في تعميم وكلاء الذكاء الاصطناعي - أمان بيانات الاعتماد - وتوفر حلاً هندسيًا أنيقًا وعمليًا. حكمها الأساسي هو أنه "لا ينبغي للوكيل حتى أن يلمس المفتاح" وينفذ هذا المبدأ على المستوى المعماري. خلال الفترة الانتقالية الحرجة للوكلاء من الألعاب إلى الإنتاجية، من المتوقع أن يصبح OneCLI هو معيار الأمان للبنية التحتية للوكلاء. ولكن لا يمكن التحقق من قيمتها الحقيقية بشكل كامل حتى يتم الانتهاء من تدقيق جهة خارجية وإصدار الإصدار المستقر 2.0.
مراجعات المستخدمين
-
2hyqkek—جربت OneCLI فحُلّت مشكلة إدارة مفاتيح Claude Code نهائيًا. كنت سابقًا أحشر كل أنواع مفاتيح API في ملف .env، أما الآن فيعمل كل شيء بأمر docker واحد، ولا يعرف الـ Agent المفاتيح الحقيقية إطلاقًا. شعور الأمان ارتفع كثيرًا. -
珊瑚37—يقارنه البعض بـ HashiCorp Vault، لكنني أرى أن التموضع مختلف. Vault ثقيل جدًا؛ ولفريق صغير يطور الـ Agents، فإن النشر بنقرة واحدة في OneCLI مريح حقًا. -
RGonzales_Plus—بوابة HTTP مكتوبة بلغة Rust، وأداؤها مستقر فعلًا. قست زمن الاستجابة، وبعد إضافة وكيل OneCLI لم أشعر تقريبًا بأي عبء إضافي؛ أسرع بكثير من جلب المفتاح من Vault في كل مرة. -
王月珍—رأيت الحساب الرسمي لـ YC يروّج لـ OneCLI فذهبت للاطلاع عليه. الفكرة ممتازة فعلًا: ليست منع الـ Agent من استدعاء الواجهات البرمجية، بل ألا يلمس الـ Agent المفاتيح أصلًا. أنا أؤيد فلسفة التصميم هذه. -
FrankHicksIII—شكك أحدهم على Hacker News قائلاً: أليس هذا مجرد وكيل مصادقة؟ صحيح أن حلولاً مشابهة وُجدت من قبل، لكنه مُحسَّن خصيصاً لسيناريوهات الوكلاء وجاهز للاستخدام فوراً، وهذا يكفي. -
AnnGray—النشر بسيط؛ سطر واحد من docker run ويعمل كل شيء. لكن هناك فخ: عليك معالجة مشكلة الشهادة الموقعة ذاتيًا بنفسك؛ فإذا لم تثق حاوية الـ Agent بشهادة CA فلن تمر حركة HTTPS. -
流年472—أسلوب OneCLI ذكّرني بحالة واقعية قرأتها سابقاً: منح مسؤول الأمن في شركة كبرى وكيلاً صلاحيات، فبدأ الوكيل بحذف رسائل البريد بجنون. لو كانت هناك حينها طبقة سياسات على مستوى البوابة، لربما حُذفت بضع رسائل فقط بدلاً من حذفها جميعاً. -
8j0wz—جربت OneCLI مع NanoClaw وكانت التجربة سلسة للغاية. الوكيل لا يعلم بوجود المفاتيح أصلاً، فلا يمكنه تسريبها حتى لو أراد. بالنسبة للفرق الحساسة أمنياً، هذه التوليفة تستحق التجربة. -
HaroldStephensIII—دمجت OneCLI في سير عملي على Cursor، وهيأت واجهات API الخاصة بـ GitHub وOpenAI وSlack جميعها. عملية الإعداد بديهية جداً، فلوحة الويب تدير الوكلاء والمفاتيح، ودقة تفصيل الصلاحيات كافية. -
AshleyOrtiz—قلقي الوحيد هو خطر المركزية. جميع المفاتيح تمر عبر بوابة OneCLI، وإذا اختُرقت هذه البوابة ضاع كل شيء. صحيح أن التخزين المشفر متقن، لكنني ما زلت متحفظاً بعض الشيء تجاه نقطة الفشل الواحدة في بيئة الإنتاج. -
康明_1—قارنت عدة أدوات لإدارة بيانات الاعتماد، وكان OneCLI الأكثر ملاءمة للمطورين الأفراد. Authsome لا يحتاج بنية تحتية لكنه بلا تدقيق، وVault ثقيل جداً. يتميز OneCLI بموقعه في المنطقة الوسطى تماماً. -
Isabella.Morgan—إمكانية الربط مع Bitwarden ميزة رائعة؛ فلا حاجة لتخزين المفاتيح في قاعدة بيانات OneCLI المحلية، إذ تُسحب مباشرة من Bitwarden. وبالنسبة للفرق التي تستخدم مدير كلمات مرور بالفعل، تكلفة الانتقال منخفضة جداً. -
KeithStewartJr—اطلعت على الكود، وطبقة بوابة Rust مكتوبة بإتقان. تشفير ثابت AES-256-GCM مع فك التشفير عند الطلب فقط، ولا توجد نقاط ضعف واضحة في التصميم. أتطلع إلى إضافتهم سير عمل الموافقات وقواعد المراقبة لاحقاً. -
Jacqueline.Adams—رغم أن OneCLI يمنع تسريب المفاتيح، فإنه لا يستطيع منع الوكيل المخوَّل من العبث. فإذا كان لدى الوكيل صلاحية استدعاء Stripe API فبإمكانه الخصم كما يشاء. هذه المشكلة ما زالت بحاجة إلى سير عمل موافقات، والبوابة وحدها لا تكفي. -
Laura_MooreIII—أتابعه منذ ظهوره في Show HN، وقد بلغ الآن أكثر من 2800 نجمة، والنمو سريع فعلاً. هذا يدل على أن هذه المشكلة تمس شريحة واسعة من الناس. رخصة Apache-2.0 مع دعم YC، يستحق المتابعة. -
7wnel5q—بعد نشر OneCLI حصلت على مكسب غير متوقع: سجلات التدقيق مفيدة للغاية. سابقاً لم يكن بالإمكان معرفة أي واجهات API استدعاها الوكيل ومتى، أما الآن فكل شيء واضح تماماً، وارتفعت كفاءة تتبع المشكلات كثيراً. -
EHughesIII—بنية الثلاثي Gateway + Dashboard + التخزين المشفر واضحة جداً. أداء بوابة Rust ليس مشكلة، ولوحة Next.js سلسة الاستخدام. غير أن بعض أجزاء التوثيق مقتضبة أكثر من اللازم، وقد يحتاج المبتدئون إلى بعض الاستكشاف. -
smallpeacock198—اتبعت خطوة بخطوة مقال الاختبار العملي المنشور على Cnblogs، واستغرق النشر المحلي أقل من عشر دقائق. استدعيت GitHub API عبر Claude Code ولم أرَ طوال الوقت سوى FAKE_KEY. هذا الاستبدال الشفاف يبدو فعلاً كتقنية سحرية. -
Brian.Martinez168—بالنسبة لشخص مثلي يعمل في تطوير وكلاء الذكاء الاصطناعي، حلّ OneCLI أكثر مشكلة مزعجة: كنت قبل كل عرض توضيحي أضطر للتحقق من أن ملف .env لم يُرفع بالخطأ في commit. الآن لم أعد قلقاً من ذلك. -
Web_3Wave—ما زال في مرحلة 1.x، لذا قد تتغير واجهة API بشكل متكرر. إذا كنت ستستخدمه في بيئة الإنتاج فأنصح بتثبيت الإصدار، وإلا ستقع في متاعب إذا تغيّر تنسيق الإعدادات بعد الترقية. -
purplepanda996—ربطت OneCLI بنظام الوكلاء المتعددين لدى فريقنا، بحيث تعزل ثلاثة مشاريع مفاتيحها وسياساتها كل على حدة. تصميم العزل على مستوى المشروع عملي جداً، فبيانات العملاء المختلفين لا تختلط أبداً. -
许桂强—أريد فقط أن أعرف متى سيدعم التكامل مع 1Password، فوجود Bitwarden وحده محدود بعض الشيء. كثيرون في فريقي يستخدمون 1Password، وآمل أن تُضاف هذه الميزة. -
DianeMitchell_Plus60—أمر واحد في Docker وكان كل شيء جاهزاً، مريح فعلاً. لكن عند تجربتي لوكيل Node.js وجدت أن متغير البيئة HTTP_PROXY غير مدعوم جيداً في إصدارات Node القديمة، ويلزم الإصدار 22 فما فوق. -
LoganRodriguez_20234—تقييم إيجابي. أجريت تجربة سابقاً نجح فيها هجوم حقن أوامر عادي في انتزاع مفتاح OpenAI من متغيرات البيئة. بعد استخدام OneCLI جربت الهجوم نفسه مرة أخرى، فوجدت أن الوكيل لا يملك المفتاح أصلاً، فلا سبيل لتسريبه حتى لو أراد. -
OMpow—تصميم محرك السياسات ممتاز، إذ يمكن تهيئة قواعد سماح/حظر وحدود معدل مستقلة لكل وكيل على حدة. هذا أعمق بكثير من مجرد إدارة المفاتيح، فهو عملياً تحكم بالصلاحيات على مستوى طبقة الشبكة. -
云烟737—الاعتماد على PostgreSQL يشكل عائقاً؛ فاضطرار المطور الفردي إلى تثبيت قاعدة بيانات فقط لتشغيله أمر مبالغ فيه. لحسن الحظ قالوا إن هناك نسخة مدمجة تعتمد على PGlite لا تحتاج إلى قاعدة بيانات مستقلة، وأتطلع إلى الدعم الرسمي. -
AfraRomkes—تحدثت مع مسؤول DevOps في فريقنا، وهو يرى أن نهج وكيل MITM في OneCLI ينطوي على مخاطر امتثال في بيئات تقنية المعلومات الخاضعة للتنظيم في الصين. فالشهادات الموقعة ذاتياً قد لا تُقبل في تدقيقات الحماية المصنفة، وينصح بالانتباه لهذه النقطة. -
WLopezX736—مقال التحليل في The Agent Times مكتوب جيداً ويضع إصبعه على المشكلة الأساسية: يحل OneCLI مشكلة تسريب المفاتيح، لكنه لا يحل مشكلة إساءة الوكلاء لاستخدام الصلاحيات. ومع ذلك فالمزايا تفوق العيوب، فعلى الأقل حلّوا المشكلة الأخطر أولاً. -
goldendog167—فتحت Issue للسؤال عن سير عمل الموافقات، ورد المطور بسرعة قائلاً إنها موجودة بالفعل على خارطة الطريق. مشروع مدعوم من Y Combinator، فلا أتوقع أن تكون وتيرة التطوير بطيئة. -
星辰_14—بعد قراءة وجهة النظر حول CLI والوكلاء التي أعاد karpathy نشرها، أجد أن تصميم OneCLI يتوافق فعلاً معها. فواجهة CLI هي الواجهة الأصلية للوكلاء، وإدارة بيانات الاعتماد في طبقة CLI أكثر جوهرية وشمولية من إدارتها في طبقة التطبيق.