deso-pk/make-trust-irrelevantسلطة مفروضة من النواة وأمان وقت التشغيل لأنظمة Linux والبرمجيات المستقلة ووكلاء الذكاء الاصطناعي.
سلطة مفروضة من النواة وأمن وقت التشغيل لأنظمة Linux والتطبيقات والبرمجيات المستقلة ووكلاء الذكاء الاصطناعي.
KERNHELM هو ركيزة أمنية عامة لنظام التشغيل تضع حدًا صارمًا للسلطة عند أدنى مستوى قابل للفرض عمليًا في حزمة البرمجيات — تحت الذكاء الاصطناعي والتطبيقات والخدمات ومساحة المستخدم العادية.
الغرض منه بسيط في التعبير عنه:
يجوز للبرمجيات أن تطلب السلطة. لكن يجب ألا تكون قادرة على تصنيع السلطة التي تمنح تلك القوة.
ينقل KERNHELM القرار النهائي بشأن التأثيرات المميزة المحكومة إلى حدود النواة.
يجوز للبرمجيات فوق تلك الحدود أن تكون بالغة القدرة.
يجوز لها أن تخطط.
يجوز لها أن تستنتج.
يجوز لها أن تؤتمت.
يجوز لها أن تدير التطبيقات.
يجوز لها أن تدافع عن الجهاز.
يجوز لها أن تعمل باستمرار كعميل ذكاء اصطناعي مستقل.
يجوز لها حتى أن تكون ذكاءً اصطناعيًا متقدمًا.
لكن القدرة وحدها لا تخلق الإذن.
الفصل المعماري مطلق بحكم التصميم:
الشيء الذي يطلب تأثيرًا غير مسموح له أن يكون الشيء الذي يقرر ما إذا كانت لديه سلطة إحداث ذلك التأثير.
بلغة أمنية عادية، KERNHELM محاولة لتجاوز السؤال:
"هل نثق بهذا البرنامج؟"
نحو السؤال:
"هل يمتلك هذا التأثير المُحاول تحديدًا سلطة صالحة؟"
هذا التمييز هو جوهر المشروع.
بالنسبة لأمن وكلاء الذكاء الاصطناعي، يمكن صياغة المبدأ نفسه بطريقة أخرى:
يجوز لعميل الذكاء الاصطناعي أن يقرر ما يريد فعله. لكن ذلك القرار يجب ألا يصنّع السلطة المطلوبة لتحقيقه.
KERNHELM ليس صندوقًا رمليًا للذكاء الاصطناعي.
ليس حاوية تطبيقات.
ليس غلافًا للأذونات حول برنامج معين.
ليس كاشفًا لحقن المطالبات (prompt injection).
ليس مصنّفًا لسلوك النموذج.
ليس مفتاح إيقاف طارئ للذكاء الاصطناعي.
ليس محرك سياسات تقليديًا في مساحة المستخدم.
ليس مجرد طبقة أخرى للتحكم في وصول وكلاء الذكاء الاصطناعي تعمل بجانب البرمجيات التي تقيّدها.
إنه معمارية سلطة عامة لنظام التشغيل نفسه.
الصندوق الرملي يجيب أساسًا على:
أين يُسمح لهذا البرنامج بالعمل؟
KERNHELM يطرح سؤالًا أعمق:
من أين تأتي سلطة إحداث هذا التأثير المميز أصلًا؟
صيغة مختصرة مفيدة هي:
الصندوق الرملي يقيّد أين يمكن للبرمجيات أن تعمل. KERNHELM يقيّد من أين يمكن أن تأتي السلطة.
أزل الذكاء الاصطناعي من الجهاز تمامًا، ويظل KERNHELM منطقيًا.
متصفح، أو خادم خفي (daemon)، أو مدير حزم، أو عملية مساعدة، أو لعبة، أو أداة تعريفات، أو حمولة خبيثة، أو مهاجم بعيد يعمل عبر برمجيات مخترقة، أو ذكاء اصطناعي — كلها في النهاية تواجه مشكلة السلطة الأساسية نفسها.
لهذا السبب KERNHELM ركيزة أمنية عامة وليس مجرد نظام احتواء للذكاء الاصطناعي.
الذكاء الاصطناعي مجرد أحد أوضح التطبيقات وأقواها المحتملة لهذه المعمارية.
تعتمد أمن وكلاء الذكاء الاصطناعي الحديثة، وأمن الذكاء الاصطناعي الوكيلي، وأمن وقت تشغيل الذكاء الاصطناعي بشكل متزايد على آليات مثل:
كل هذه الآليات يمكن أن تكون مفيدة.
KERNHELM يسأل عما يحدث تحتها.
إذا تعرّض عميل ذكاء اصطناعي مستقل للاختراق، أو التلاعب، أو حقن المطالبات، أو سوء التهيئة، أو نجا من آلية احتواء عالية المستوى، فهل ينبغي لذلك الحدث أن يمنح البرمجيات الناتجة سلطة واسعة على الجهاز تلقائيًا؟
جواب KERNHELM هو لا.
الهروب من الصندوق الرملي يجب ألا يتحول تلقائيًا إلى هروب من السلطة.
عبور حد احتواء واحد يجب ألا يصنّع بحد ذاته سلطة للتأثيرات المحمية عند جدار النواة.
وبالمثل:
حقن المطالبات يجب ألا يصنّع سلطة.
اختراق وكيل يجب ألا يصنّع سلطة.
فشل احتواء الذكاء الاصطناعي يجب ألا يتحول تلقائيًا إلى فشل في السلطة على مستوى الجهاز بأكمله.
لهذا السبب يقترب KERNHELM من أمن وقت تشغيل الذكاء الاصطناعي من تحت وقت تشغيل الوكيل العادي.
قد تقرر الطبقات الأعلى:
what the agent wants to do
KERNHELM يسأل:
whether the resulting machine effect possesses authority to happen
معظم أنظمة التحكم بالذكاء الاصطناعي تهتم بالتحكم في سلوك الوكيل أو أذوناته أو أدواته أو بيئته.
يعالج KERNHELM طبقة أخرى:
حتى لو وصل الوكيل إلى نقطة محاولة إحداث التأثير الفعلي على نظام التشغيل، فهل توجد سلطة مستقلة صالحة لهذا التأثير بالتحديد؟
هذا التمييز مهم بشكل خاص للوكلاء المستقلين والطويلي التشغيل لأن فشل الاستدلال أو الاحتواء أو المراقبة أو السياسة لا ينبغي أن يتحول تلقائيًا إلى سلطة غير مقيّدة على المضيف.
لذلك فإن KERNHELM ليس مفتاح إيقاف للذكاء الاصطناعي.
نموذجه المقصود أكثر تفصيلًا:
ارفض التأثير غير المصرّح به مع السماح للعمل المصرّح به بشكل منفصل بالاستمرار.
يوضح العرض العام التالي هذا التمييز مباشرة.
تحاول تعليمة خبيثة داخل مستند غير موثوق التسبب في حذف ملف محمي.
يتلقى البرنامج التعليمة ويحاول الحذف.
لا يحتاج KERNHELM إلى تصنيف التعليمة بشكل صحيح على أنها خبيثة أو تحديدها كحقن موجّه.
يطرح حد سلطة النواة سؤالًا أضيق:
هل يمتلك هذا الحذف بالتحديد، ضد هذا الهدف بالتحديد، سلطة مقبولة صالحة؟
لا يمتلكها.
يرفض KERNHELM العملية ويبقى الملف موجودًا.
ثم يصرّح المستخدم مباشرة بالحذف عبر المسار المُحوكم.
لا يصبح البرنامج أكثر موثوقية.
لا يتغير الملف التنفيذي.
لا ينتقل الملف إلى صندوق رمل آخر.
ما يتغير هو السلطة.
تُجرى محاولة الحذف مرة أخرى بسلطة مقبولة مطابقة.
يسمح KERNHELM بالتأثير المُحوكم ويُحذف الملف.
التسلسل الموضّح هو:
untrusted document instruction
↓
software attempts DELETE
↓
no matching admitted authority
↓
KERNHELM DENY
↓
file remains
followed by:
direct user authorization
↓
bounded authority admitted
↓
software attempts DELETE
↓
authority matches effect + target
↓
KERNHELM ALLOW
↓
file is deleted
النتيجة المهمة هي:
نفس البرمجيات. نفس الهدف. نفس فئة التأثير. سلطة معترف بها مختلفة.
لم تكن البرمجيات بحاجة إلى أن تصبح أكثر موثوقية حتى تتغير سلطتها.
هذا هو KERNHELM.
تمنح أجهزة الكمبيوتر الحديثة البرمجيات بشكل روتيني سلطة واسعة قائمة.
قد تكون العملية قادرة على:
بسبب المستخدم، أو مستوى الامتياز، أو الحاوية، أو مساحة الأسماء، أو مجموعة القدرات، أو هوية الخدمة، أو سياق التنفيذ الذي تصادف أنها تعمل ضمنه.
يخلق هذا سلسلة أمنية مألوفة:
authority is granted broadly
↓
software is expected to behave correctly
↓
software is compromised, confused, manipulated, or simply wrong
↓
the inherited authority is still real
الوكلاء الذكيون المستقلون يجعلون هذه المشكلة الأمنية القديمة أكثر وضوحًا بكثير.
مع تزايد قدرة البرمجيات على التخطيط، واستخدام الأدوات، وتشغيل التطبيقات، وإدارة الأنظمة، والحفاظ على حالة طويلة الأمد، والتصرف بإشراف بشري متضائل، تصبح السلطة المحيطة الواسعة ذات عواقب متزايدة.
تخفف أنظمة الأمان التقليدية هذه المشكلة من خلال آليات مهمة تشمل:
لا يتطلب KERNHELM أن تختفي هذه الآليات.
يمكنه تقوية نظام لا يزال يستخدمها.
لكن سؤاله طويل الأمد أكثر جوهرية:
لماذا ينبغي للبرمجيات أن تمتلك سلطة محيطة قائمة واسعة في المقام الأول؟
يستكشف KERNHELM ما إذا كان يمكن بدلاً من ذلك أن تعتمد التأثيرات المميزة على سلطة صريحة ومحدودة ومُعترف بها بشكل مستقل لا تستطيع البرمجيات الطالبة إنشاءها لنفسها.
عادةً ما يُعبَّر عن "الثقة الصفرية" كمبدأ سياسي:
لا تفترض أن الفاعل ينبغي أن يكون موثوقًا لمجرد مكانه أو هويته التي يدّعيها.
يدفع KERNHELM هذه الفكرة إلى أسفل المكدس.
هدفه طويل الأمد هو جعل الثقة نفسها أقل صلة بما إذا كان يمكن أن تحدث تأثيرات مميزة.
بدلاً من الاعتماد بشكل أساسي على:
trusted process
↓
broad privilege
↓
expected good behavior