Infisical Agent Vault: كيف يُبقي وسيط بيانات الاعتماد مفاتيح API بعيدًا عن وكلاء الذكاء الاصطناعي

تُعيد الإدارة التقليدية للأسرار بيانات الاعتماد إلى التطبيقات والخدمات التي تستخدمها. أما Infisical Agent Vault فيسلك طريقًا مختلفًا: لا يحمل الوكيل بيانات الاعتماد الحقيقية أبدًا.

يشرح هذا الدليل كيف يعمل نمط وسيط بيانات الاعتماد، وأين يُقلّل المخاطر وأين لا يفعل. وهو منظَّم حول نموذج من ثلاث طبقات نسمّيه العنصر النائب / الوسيط / المحيط (Placeholder / Proxy / Perimeter):

• العنصر النائب (Placeholder): لا يحمل الوكيل سوى قيمة بديلة، وليس المفتاح الحقيقي أبدًا.
• الوسيط (Proxy): يحتفظ وسيط منفصل ببيانات الاعتماد الحقيقية، ويطبّق السياسات ويحقنها في الطلبات المعتمدة.
• المحيط (Perimeter): تُجبر الشبكة كل اتصال صادر على المرور عبر ذلك الوسيط.

لماذا يُفسد تسليم الأسرار لوكلاء الذكاء الاصطناعي النموذج القديم

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

الوكلاء يكسرون هذا العقد. يقول مستودع Agent Vault ذلك صراحةً: الإدارة التقليدية للأسرار تعيد بيانات الاعتماد إلى التطبيقات والخدمات، وهذا ينهار مع وكلاء الذكاء الاصطناعي الذين يمكن خداعهم عبر حقن الأوامر (prompt injection) لتسريب الأسرار. وقد طرح توني دانغ (Tony Dang)، المدير التقني في Infisical، الحجة نفسها عند الإطلاق: بُنيت إدارة الأسرار لعالم تجلب فيه التطبيقات بيانات الاعتماد وتستخدمها، وهذا الافتراض لم يعد صالحًا مع وكلاء الذكاء الاصطناعي.

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

ولا تسدّ الدفاعات على مستوى النموذج هذه الثغرة. تستشهد ورقة OWASP المرجعية لحقن الأوامر بدراسة Hughes وزملائه (2024)، التي أفادت بنسبة نجاح للهجمات بلغت 89% على GPT-4o و78% على Claude 3.5 Sonnet باستخدام ما يصل إلى 10,000 موجّه معزَّز لكل طلب. قاست تلك الدراسة نجاح كسر القيود (jailbreak) بموجّهات معزَّزة على طريقة Best-of-N، ولم تقِس عدد المرات التي يؤدي فيها حقن الأوامر غير المباشر إلى تسريب الأسرار. ونحن نقرؤها سببًا لعدم اعتبار رفض النموذج حدًّا أمنيًا.

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

كيف يعمل وسيط بيانات الاعتماد في Agent Vault

تصف Infisical أداة Agent Vault بأنها وسيط أمامي (forward proxy) يعترض اتصالات TLS ويحقن بيانات الاعتماد، وقد صُمّم لأحمال عمل الوكلاء. ويسير التدفق على النحو التالي:

1. يحصل الوكيل على قيمة نائبة أو رمز جلسة بدلًا من مفتاح API الحقيقي.
2. تمرّ حركة HTTP الخاصة به عبر الوسيط، عادةً لأن متغير البيئة HTTPS_PROXY مضبوط.
3. يعترض الوسيط اتصال TLS، ويتحقق من المضيف الوجهة مقابل الخدمات المهيّأة لديه، ويُدرج بيانات الاعتماد الحقيقية في الطلب الصادر.
4. يُرسَل الطلب إلى الخدمة الأصلية ومعه بيانات الاعتماد الحقيقية، ثم تعود الاستجابة إلى الوكيل.

في النسخة الثنائية مفتوحة المصدر، يشغّل الخادم واجهة HTTP API للإدارة على المنفذ 14321 ووسيط HTTP/HTTPS شفافًا على المنفذ 14322.

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

الثقة بالشهادات خطوة من خطوات النشر

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

قاعدتان تحددان ما إذا كان الضمان قائمًا

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

الثانية هي الإلزام، أي طبقة المحيط. تشير Infisical إلى أن ضبط HTTPS_PROXY وحده لا يضمن مرور الحركة عبر الوسيط، لأن الوكيل يستطيع إلغاء ضبطه. فالمتغير لا يوجّه إلا العملاء الملتزمين. أما النشر الكامل فيُحكم إغلاق الشبكة بحيث تُجبَر كل الحركة الصادرة على المرور عبر Agent Vault.

سطح التحكم: قوائم السماح ووضع الرفض والجلسات والتدقيق

الوسيط الذي يحقن بيانات الاعتماد هو أيضًا مكان طبيعي لوضع السياسات.

مطابقة المضيفين ووضع الرفض. افتراضيًا، يمرّر الوسيط مفتوح المصدر الطلبات التي لا تطابق أي خدمة مهيّأة بوصفها حركة وسيط عادية. وتحويل الخزنة إلى وضع الرفض الصارم (unmatched_host_policy=deny) يرفض تلك الطلبات برمز HTTP 403.

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

جلسات محددة زمنيًا. في الإصدار التجاري من Agent Vault، تنتهي كل جلسة وكيل وفق جدول تحدده أنت، ويفقد الوكلاء العاملون صلاحية الوصول خلال 60 ثانية من انتهاء الجلسة. الجلسات القصيرة تحدّ من المدة التي يستطيع فيها تشغيل مُختطَف مواصلة استخدام الوصول عبر الوسيط.

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

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

ما يحمي منه النمط وما لا يحمي منه

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

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

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

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

معالجة رموز MCP. تنص أفضل ممارسات الأمان في MCP على أنه يجب على خوادم MCP ألا تقبل أي رموز لم تُصدَر صراحةً لخادم MCP. ووسيط بيانات الاعتماد لا يغني عن عمليات التحقق الصحيحة من الجمهور داخل خوادم MCP لديك.

Agent Vault مفتوح المصدر مقابل التجاري: ما الذي تغيّر ولماذا يهم

يأتي Agent Vault من Infisical، التي تقول إنها تعالج مليارات الأسرار شهريًا لصالح الفرق وخطوط CI/CD والخوادم.

لاحظت مراجعة Codeline المستقلة عند الإطلاق نحو 800 نجمة، ووسم Preview، وواجهة API قابلة للتغيير صراحةً. ووصفت أيضًا البنية الداخلية: تغلّف كلمة المرور الرئيسية مفتاح تشفير بيانات عشوائيًا عبر Argon2id بمعاملات افتراضية هي 3 تكرارات و64 MiB من الذاكرة و4 خيوط. وافتراضيًا تحتفظ النسخة الثنائية بكل الحالة في قاعدة بيانات SQLite محلية لا تحتاج إلى إعداد، بينما يُعدّ PostgreSQL الخيار المخصص للإنتاج.

وفي غضون بضعة أشهر، وبحسب إحصاء لاحق من Infisical، تجاوز Agent Vault حاجز 2,000 نجمة على GitHub، مع عشرات الآلاف من عمليات التثبيت وملايين من تشغيلات الوكلاء. هذه أرقام صادرة عن المورّد ولم يجرِ التحقق منها بشكل مستقل.

ملاحظة حول التسمية: تسمّي Infisical الإصدار المدفوع «Agent Vault التجاري» عند الحديث عن الجلسات، وتسمّي مكوّن الوسيط فيه Agent Proxy عند الحديث عن إعادة التصميم. ونستخدم المصطلحين هنا بالطريقة نفسها.

التغيير الأكبر معماري. فعند مراجعة الإصدار الأول، أوضحت Infisical أنها جمعت مفهومين مختلفين في مفهوم واحد: مخزن الأسرار ووسيط الأسرار. في Agent Vault التجاري، يفصل Agent Proxy بينهما ويأتي مع 30+ إعدادًا مسبقًا للخدمات الشائعة، بما في ذلك مزوّدو نماذج اللغة الكبيرة مثل Anthropic وOpenAI، وخدمات مثل GitHub وSlack وDatadog. أما المستودع مفتوح المصدر، فتقول الشركة إنه سيبقى متاحًا ويمكنك تشغيله، لكنه لا يخضع لصيانة نشطة ولم يُبنَ يومًا لعمل الفرق.

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

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

دليل عملي وقائمة تحقق قبل الإطلاق لوكلاء MCP وCLI وSDK

تتبع هذه الخطوات الطبقات الثلاث، وتنطبق على كلا الإصدارين.

طبقة العنصر النائب

1. جرد بيانات الاعتماد. لكل وكيل، أدرج كل بيانات اعتماد، والمضيف الذي تُستخدم معه، وأضيق نقاط النهاية وأساليب HTTP التي يحتاجها.
2. استبدل القيم النائبة بالمفاتيح. استبدل المفاتيح الحقيقية في متغيرات بيئة الوكيل وملفات الإعداد بقيم نائبة أو رموز جلسات.

طبقة الوسيط

1. افصل الوسيط. شغّله على جهاز منفصل أو خلف حد شبكي يفصله عن الوكلاء. لا يوضع مخزن بيانات الاعتماد أبدًا في بيئة تشغيل الوكيل.
2. الرفض افتراضيًا. فعّل وضع الرفض للمضيفين غير المطابقين، وأضف إدخالات قائمة السماح لكل وكيل، لا لكل فريق.
3. راجع ما يعود. ضع علامة على نقاط النهاية المدرجة في قائمة السماح التي قد تعيد استجاباتها بيانات اعتماد أو سرًا، مثل واجهات API لتحديث OAuth وسكّ الرموز وإنشاء المفاتيح وقراءة الأسرار. أبعِدها عن الوكيل ما لم تستطع تبرير هذا الانكشاف.
4. حدّد نطاق رموز MCP. تُحفظ مفاتيح API الأصلية لكل خادم MCP في الوسيط، لا في إعداداته. ارفض رموز العملاء التي لم تُصدَر صراحةً لخادم MCP، ولا تمرّرها أبدًا إلى الخدمات اللاحقة.

طبقة المحيط

1. افرض مسار الخروج. استخدم قواعد الجدار الناري أو سياسات شبكة Kubernetes أو قواعد مشغّلات CI بحيث يكون الوسيط هو المسار الوحيد لخروج الوكيل. ثم اضبط HTTPS_PROXY بعد ذلك إرشادًا للعملاء الملتزمين.
2. ثبّت الثقة بشهادة CA. أضف شهادة CA الخاصة بالوسيط إلى مخزن الثقة في كل بيئة تشغيل للوكيل، مع إبقاء التحقق مفعّلًا.
3. تحقّق من عملاء HTTP. لا تلتزم كل بيئات التشغيل بمتغيرات الوسيط. تشير وثائق Infisical إلى أن fetch المدمجة في Node.js لا تقرأ HTTPS_PROXY افتراضيًا، لذا تحتاج إلى --use-env-proxy أو NODE_USE_ENV_PROXY=1 على Node 24 أو أحدث. ونقترح التأكد من دعم هذا الخيار في الإصدار الدقيق لبيئة التشغيل التي تنشرها قبل الاعتماد عليه.

أثبِت ذلك

1. اختبر الإلغاء والحقن. اضبط مددًا قصيرة للجلسات، وأنهِ جلسة في منتصف التشغيل وتأكد من توقف الوصول. ثم أجرِ اختبار حقن أوامر تجريبيًا (canary) يطلب من الوكيل طباعة مفاتيحه، وتحقق من أن القيم النائبة وحدها هي ما يظهر.

وكلاء CLI مثل Claude Code

تُدرج Infisical أداة Claude Code ضمن الوكلاء الذين يعملون عبر Agent Vault. بالنسبة لوكلاء CLI، الإعداد الموثوق هو حاوية أو آلة افتراضية لا تسمح قواعد شبكتها بالاتصالات الصادرة إلا إلى الوسيط، مع قيم نائبة في كل موضع يتوقع فيه الوكيل مفاتيح API. يستطيع وكيل CLI تشغيل أوامر الصدفة، لذا افترض أنه قادر على إلغاء ضبط متغيرات البيئة، ودع الشبكة تفرض المسار.

وكلاء SDK المخصصون

دقّق كل عميل HTTP في شجرة الاعتماديات. المكتبة التي تتجاهل إعدادات الوسيط يجب أن تفشل بشكل مغلق على مستوى الشبكة، لا أن تتصل مباشرةً في صمت.

اقرأ قائمة السماح كما يقرؤها مهاجم

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

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