Micha Rave، الرئيس التنفيذي والمؤسس المشارك لشركة Hush Security – سلسلة المقابلات

Micha Rave، الرئيس التنفيذي والمؤسس المشارك لشركة Hush Security، هو مدير تنفيذي ذو خبرة في مجال الأمن السيبراني والتقنية، تمتد مسيرته عبر هندسة البرمجيات، إدارة المنتجات، الشبكات المؤسسية، أمن السحابة، والهوية. قبل أن يؤسس Hush Security في عام 2024، قضى أكثر من خمس سنوات في شركة Proofpoint كمدير أول لإدارة المنتجات لأمن السحابة، حيث كان مسؤولاً عن خطوط منتجات Zero Trust Network Access (ZTNA) وSecure Web Gateway (SWG). شغل سابقاً منصب نائب الرئيس لإدارة المنتجات في Meta Networks، مع تركيز على الشبكات المؤسسية والأمن، وتولى أدوار قيادية في مجال المنتج والهندسة في شركات HARMAN International وRedbend وSanDisk وHola وJungo وElbit Systems. يجمع خلفيته بين تطوير البرمجيات العملي وأكثر من عقدين من الخبرة في بناء وتسويق منتجات الأمن والشبكات والافتراضية والتقنية المدمجة.

Hush Security هي شركة أمن سيبراني تركز على تأمين وكلاء الذكاء الاصطناعي والهويات غير البشرية الأخرى من خلال استبدال الاعتمادات طويلة الأمد والأسرار الثابتة بالوصول القائم على الهوية وتحت سيطرة السياسات. تكتشف منصتها وكلاء الذكاء الاصطناعي، بما في ذلك الوكلاء الظلال والوكلاء المطورين داخليًا، وتمنحهم هويات قابلة للتحقق، وتدير تفاعلاتهم مع أنظمة المؤسسة باستخدام أذونات محدودة زمنياً ومحددة النطاق، وسياسات مركزية، وسجلات نشاط قابلة للتدقيق. تأسست الشركة على يد خبراء الأمن من الفريق وراء Meta Networks، التي استحوذت عليها Proofpoint في عام 2019. في يوليو 2026، جمعت Hush تمويلاً من السلسلة A بقيمة $30 million، حيث انضمت Akamai Technologies كمستثمر استراتيجي إلى جانب Battery Ventures وYL Ventures، مما رفع إجمالي التمويل إلى $41 million بينما توسع الشركة تقنيتها لحكم وكلاء الذكاء الاصطناعي المؤسسي والبنية التحتية غير البشرية.

قبل تأسيس Hush Security، أمضيت سنوات في بناء وقيادة منتجات الأمن، بما في ذلك أمن السحابة في Proofpoint. ماذا رأيت في السوق أقنعك بوجود حاجة لتأسيس Hush، وكيف تطورت تلك الفرضية الأصلية مع الارتفاع السريع للذكاء الاصطناعي الوكيل؟

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

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

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

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

تؤكد Hush أن وكلاء الذكاء الاصطناعي المؤسسيين يجب أن يمتلكوا هوياتهم الخاصة وأذونات مفوضة بدلاً من مجرد وراثة حقوق الوصول الخاصة بالبشر الذين يستخدمونهم. لماذا تكافح أنظمة إدارة الهوية والوصول (IAM) التقليدية مع الوكلاء المستقلين، وما الذي يحتاج إلى التغيير؟

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

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

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

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

ليس لدى الوكلاء سلوك ثابت. إذا منحت أحدهم صلاحية قراءة إلى نظام إدارة علاقات العملاء (CRM) وصلاحية كتابة إلى البريد الإلكتروني، فإنك لم تمنح إذنين فقط، بل منحت كل مسار بينهما. يحدّ مبدأ أقل صلاحية ما يمكن للوكيل الوصول إليه. لكنه لا يحدد ما ينبغي أن يفعله بهذه الصلاحيات.

أقل وكالة تضيف البُعد المفقود: أي الإجراءات، لأي مهمة، الآن. يحتاج وكيل فرز التذاكر إلى القراءة والتعليق. لا يحتاج إلى الإغلاق أو الحذف أو لمس الفوترة، حتى لو سمح الرمز بذلك. عندما تنتهي المهمة، ينتهي الوصول.

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

أقل امتياز يحدد من يحصل على المفاتيح. أقل وكالة تقرر ما يمكنهم فعله بمجرد الدخول.

غالبًا ما “نُقرض” هويتنا للوكيل، لكننا لا نريد أن يمتلك الوكيل نفس مستوى الصلاحيات التي نمتلكها – هذا هو تعريف أقل وكالة.

قامت Hush مؤخرًا بجمع $30 مليون من السلسلة أ، لتصل إجمالي التمويل إلى $41 مليون، مع انضمام Akamai كمستثمر استراتيجي إلى جانب Battery Ventures وYL Ventures. ماذا يجلب انخراط Akamai إلى جانب رأس المال، وكيف تتوقع أن يؤثر الشراكة على توسع Hush في أمان وكلاء الذكاء الاصطناعي للمؤسسات؟

تقع Akamai في مسار حركة المرور لمعظم مؤسسات العالم، وهذا بالضبط المكان الذي يجب أن يعيش فيه أمان الوكلاء. لا تحكم على الوكيل من لوحة تحكم بعد حدوثه. تحكم فيه مباشرةً، في اللحظة التي يستدعي فيها أداة أو واجهة برمجة تطبيقات. بنيت Akamai أعمالها على هذا النموذج.

إلى جانب رأس المال، يجلبون ثلاثة أشياء: توزيع إلى المسؤولين التنفيذيين للأمن (CISOs) الذين يسألون بالفعل كيف يتحكمون في الوكلاء وحركة مرور MCP؛ توثيق أن هوية الوكيل فئة حقيقية، ليست مجرد ميزة؛ وعقود من الخبرة في تأمين حركة المرور بين الآلات على نطاق عالمي، وهو ما ستصبح عليه حركة مرور الوكيل إلى الأداة قريبًا.

بروتوكول سياق النموذج (MCP) يصبح بسرعة طبقة مهمة لربط وكلاء الذكاء الاصطناعي بالأدوات وبيانات المؤسسات. من منظور الأمان، ما المخاطر الجديدة التي يطرحها MCP، وكيف ينبغي للمنظمات التفكير في الهوية والتفويض بين الوكيل، خادم MCP، والموارد الأساسية؟

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

هناك ثلاث مشكلات جديدة الآن:

1. MCP الظلي – لا أحد يعرف عدد الخوادم التي تعمل أو ما الذي تتعامل معه.
2. انتشار الاعتمادات – معظم الخوادم تصادق باستخدام رمز ثابت يمنح كامل السطح، لذا يحصل الوكيل على كل ما يستطيع الرمز القيام به.
3. السلسلة المتق collapsed – المورد يرى فقط اعتماد خادم MCP، لذا لا يستطيع معرفة أي وكيل، وبالنيابة عن أي مستخدم، قام بالنداء. يجب أن تكون الهوية في قاعدة كل تفاعل، ويجب أن يكون الوصول مؤقتًا، محددًا ومبنيًا على صلاحيات الوكيل والمستخدم.

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

أنت لا تعيد البناء. لا أحد يقول غير ذلك قد واجه مؤسسة. معظم ما نحميه يسبق مصطلح الهوية غير البشرية، ولا يُعاد كتابته.

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

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

يغطي النموذج نفسه خدمة Java عمرها خمسة عشر عامًا وخادم MCP تم إعداده الأسبوع الماضي. ابدأ من حيث تكمن المخاطر، أثبت الفعالية، واستمر.

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

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

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

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

ستصبح الأنظمة متعددة الوكلاء أصعب في الفهم. لا يجب أن تكون سلسلة الحفظ لكل إجراء كذلك.

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

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

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

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

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

سيكون النموذج خاطئاً أحياناً. الهوية المحدودة، والإسناد، والأسس السلوكية تجعل الأخطاء قابلة للبقاء.

تركز Hush أساساً على تأمين الذكاء الاصطناعي، لكن كيف تستخدمون الذكاء الاصطناعي داخل Hush نفسها؟ هل هناك مجالات مثل اكتشاف الهويات غير البشرية، تحليل أنماط الوصول، تحديد الأولويات للمخاطر، أو فرض السياسات حيث يمكن للذكاء الاصطناعي تحسين منصة الأمان بشكل ملحوظ؟

نستخدمه حيثما يثبت قيمته.

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

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

تقول Hush إن عدة شركات من قائمة Fortune 500 تستخدم تقنيتها الآن، بينما قامت Kyndryl بنشر Hush داخلياً وبدأت في إعادة بيعه للعملاء المؤسسين. ماذا تتعلمون من هذه النشرات واسعة النطاق حول مشاكل الحوكمة الواقعية التي تواجهها الشركات عندما تنتقل وكلاء الذكاء الاصطناعي من التجربة إلى الإنتاج؟ 

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

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

الملكية مفقودة. اسأل من هو المسؤول عن وكيل، أو عن NHI وستحصل على اسم فريق في أحسن الأحوال، أو مقاول غادر، أو صمت.

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

لم يخلق الوكلاء مشاكل حوكمة جديدة. بل أخذوا المشكلات التي تجاهلتها المؤسسات لعقد من الزمن مع حسابات الخدمة وجعلوها أسوأ بكثير.

شكراً لكم على المقابلة الرائعة، القراء الذين يرغبون في معرفة المزيد يجب أن يزوروا Hush Security.