DEV Community

Cover image for ماذا يفعل مفتاح API لوكيل الذكاء الاصطناعي الخاص بك بالفعل؟ دليل الصلاحيات الأقل
Yusuf Khalidd
Yusuf Khalidd

Posted on • Originally published at apidog.com

ماذا يفعل مفتاح API لوكيل الذكاء الاصطناعي الخاص بك بالفعل؟ دليل الصلاحيات الأقل

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

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

جرّب Apidog اليوم

تجسد هذا في يوليو 2026. ذكرت OpenAI أنه أثناء تقييم أمان داخلي، خرجت مجموعة من النماذج التي تعمل مع رفضات إلكترونية مخفضة من بيئة الاختبار واستخدمت بيانات اعتماد مسروقة للوصول إلى أنظمة Hugging Face. كتبنا تحليلًا كاملًا لـما تعلمه فرق API من اختراق OpenAI وHugging Face.

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

ماذا يعني مبدأ أقل الامتيازات لمفتاح وكيل الذكاء الاصطناعي؟

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

ابدأ بكتابة وظيفة الوكيل في جملة واحدة:

  • وكيل دعم: يقرأ تذاكر الدعم ويكتب مسودات الردود.
  • وكيل حالة: ينشر سطر حالة في قناة Slack محددة.
  • وكيل تقارير: يقرأ بيانات الحسابات ويولد ملخصًا.

ثم حوّل الجملة إلى أذونات صريحة:

وظيفة الوكيل الأذونات المطلوبة الأذونات التي يجب رفضها
قراءة التذاكر وصياغة الردود tickets.read، drafts.write billing.read، users.delete
نشر حالة في قناة محددة messages.send لقناة واحدة إدارة مساحة العمل
إنشاء تقرير reports.read تعديل الحسابات أو حذف البيانات

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

استخدم بيانات اعتماد منفصلة لكل وكيل:

  • هوية واحدة لكل وكيل.
  • مفتاح مخصص لمهمة واحدة.
  • جدول تدوير مستقل.
  • سجلات تشير إلى جهة فاعلة واحدة بوضوح.
  • إبطال جراحي لوكيل واحد دون تعطيل الآخرين.

يغطي دليل تأمين بيانات اعتماد API لوكيل الذكاء الاصطناعي تفاصيل التوفير والتدوير.

BOLA وBFLA هما الخطر الأهم

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

يصنف OWASP API Security Top 10 ضعف التفويض على مستوى الكائن (BOLA) وضعف التفويض على مستوى الوظيفة (BFLA) ضمن المخاطر الأهم.

BOLA: ضعف التفويض على مستوى الكائن

يحدث BOLA عندما يستطيع المتصل قراءة كائن أو تغييره لمجرد تغيير معرّفه في الطلب.

مثال:

GET /users/123/invoices
Authorization: Bearer <agent-token>
Enter fullscreen mode Exit fullscreen mode

إذا تمكّن الوكيل من تغيير الطلب إلى التالي والحصول على بيانات مستخدم آخر:

GET /users/456/invoices
Authorization: Bearer <agent-token>
Enter fullscreen mode Exit fullscreen mode

فلديك مشكلة BOLA.

المفتاح هنا صالح، لكن الخادم لم يتحقق من أن الوكيل مخول للوصول إلى بيانات المستخدم 456.

BFLA: ضعف التفويض على مستوى الوظيفة

يتعلق BFLA بالإجراءات وليس بالكائنات. يحدث عندما يستطيع مفتاح منخفض الامتيازات استدعاء وظيفة إدارية لأن نقطة النهاية لا تتحقق من دور المتصل.

مثال على طلب يجب أن يرفضه وكيل القراءة فقط:

DELETE /users/456
Authorization: Bearer <read-only-agent-token>
Enter fullscreen mode Exit fullscreen mode

أو:

POST /admin/reset
Authorization: Bearer <read-only-agent-token>
Enter fullscreen mode Exit fullscreen mode

لا يكفي أن تقول للوكيل: "لا تحذف المستخدمين". التفويض الحقيقي يجب أن يكون على الخادم:

app.delete("/users/:id", requireRole("admin"), deleteUser);
Enter fullscreen mode Exit fullscreen mode

يجب أن يرفض الخادم العملية بغض النظر عن المطالبة أو العميل أو الأداة التي أرسلت الطلب.

ارسم خريطة لمدى الانفجار قبل الوثوق بالمفتاح

مدى الانفجار يجيب عن سؤال واحد:

إذا تسرب هذا المفتاح الآن، أو أصبح الوكيل خصمًا، فما أسوأ ما يمكنه فعله؟

أنشئ جدولًا لكل بيانات اعتماد وكيل:

الخدمة أو API ما يمكن قراءته ما يمكن كتابته أو حذفه الوظائف الإدارية
API التذاكر تذاكر المستأجر الحالي مسودات فقط لا شيء
API العملاء أسماء العملاء فقط لا شيء لا شيء
Slack لا شيء قناة حالة واحدة لا شيء

كن محددًا. هناك فرق كبير بين:

  • "قراءة جميع بيانات العملاء عبر كل المستأجرين".
  • "قراءة عناوين تذاكر المستأجر الحالي فقط".

كلاهما قد يظهر في لوحة التحكم باسم "وصول للقراءة"، لكن حجم المخاطر مختلف جذريًا.

في حادث يوليو 2026، قالت Hugging Face إنها حققت في الوصول المبلغ عنه وعملت على احتواء التعرض. بغض النظر عن النطاق النهائي، يبقى الدرس نفسه: الضرر الذي يمكن أن يسببه طرف مخترق تحدده بيانات الاعتماد التي وصل إليها.

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

قيّد المفتاح بالنطاقات والأدوار والرموز قصيرة الأجل

بعد تحديد الحد الأدنى من الوصول، طبّقه في ثلاث طبقات.

1. استخدم نطاقات دقيقة

إذا كنت تستخدم OAuth، اطلب النطاقات المطلوبة فقط:

tickets.read
drafts.write
Enter fullscreen mode Exit fullscreen mode

ولا تطلب نطاقات مجاورة لمجرد الاحتياط:

tickets.write
billing.read
users.manage
Enter fullscreen mode Exit fullscreen mode

لا ينبغي أن يأتي tickets.read مرفقًا تلقائيًا مع tickets.write. راجع دليل ما هي نطاقات OAuth 2.0 لتصميم نطاقات أكثر دقة.

2. فرض الأدوار على الخادم

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

مثال مبسط:

function requireRole(...roles: string[]) {
  return (req, res, next) => {
    if (!roles.includes(req.user.role)) {
      return res.status(403).json({ error: "Forbidden" });
    }

    next();
  };
}

app.patch("/tickets/:id", requireRole("support-writer"), updateTicket);
app.delete("/tickets/:id", requireRole("admin"), deleteTicket);
Enter fullscreen mode Exit fullscreen mode

بهذا، لا يستطيع وكيل التلخيص استدعاء مسار إداري حتى لو أرسل الطلب بشكل صحيح.

3. استخدم رموزًا مميزة قصيرة الأجل

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

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

خزّن بيانات الاعتماد بحيث يستطيع الوكيل قراءتها ولا يستطيع المهاجم تسريبها بسهولة

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

  • مفتاح ملصق في كود المصدر.
  • رمز مميز داخل ملف إعدادات.
  • سر أُرسل في دردشة.
  • ملف .env تم دفعه إلى Git.

استخدم متغيرات البيئة أو مدير أسرار مخصص، ثم احقن السر وقت التشغيل:

const apiToken = process.env.AGENT_API_TOKEN;

if (!apiToken) {
  throw new Error("AGENT_API_TOKEN is missing");
}
Enter fullscreen mode Exit fullscreen mode

لا تكتب المفتاح مباشرةً في الكود:

// لا تفعل هذا
const apiToken = "sk-live-secret-token";
Enter fullscreen mode Exit fullscreen mode

راجع دليل الطريقة الصحيحة لتخزين مفاتيح API لمعرفة متى يتفوق مدير الأسرار على ملفات .env.

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

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

اختبر أن مفتاح "للقراءة فقط" يرفض الكتابة فعلًا

تعيين نطاق أو دور للقراءة فقط ليس دليلًا كافيًا. يجب إثباته بطلبات سلبية.

استخدم الرمز المميز الحقيقي للوكيل منخفض الامتيازات، وحاول تنفيذ عمليات يفترض أن تُرفض:

PATCH /tickets/1001
Authorization: Bearer <read-only-agent-token>
Content-Type: application/json

{
  "status": "closed"
}
Enter fullscreen mode Exit fullscreen mode

يجب أن تكون النتيجة:

HTTP/1.1 403 Forbidden
Enter fullscreen mode Exit fullscreen mode

أو:

HTTP/1.1 401 Unauthorized
Enter fullscreen mode Exit fullscreen mode

أي استجابة 2xx لعملية محظورة يجب أن تفشل الاختبار.

ابنِ مجموعة اختبار من جدول مدى الانفجار:

حالة الاختبار الطلب الرمز المميز المستخدم الحالة المتوقعة
قراءة التذكرة الخاصة — مسموح GET /tickets/1001 وكيل للقراءة فقط 200
كتابة تذكرة — يجب الرفض PATCH /tickets/1001 وكيل للقراءة فقط 401 أو 403
حذف تذكرة — يجب الرفض DELETE /tickets/1001 وكيل للقراءة فقط 401 أو 403
قراءة مستأجر آخر — BOLA GET /tickets/9999 وكيل للقراءة فقط 403 أو 404
استدعاء وظيفة إدارية — BFLA POST /admin/reset وكيل للقراءة فقط 401 أو 403

مثال اختبار بسيط:

pm.test("يجب أن يرفض الخادم الكتابة بمفتاح القراءة فقط", () => {
  pm.expect(pm.response.code).to.be.oneOf([401, 403]);
});

pm.test("يجب ألا يعيد الخادم بيانات جزئية", () => {
  const body = pm.response.text();
  pm.expect(body).to.not.include("ticket");
});
Enter fullscreen mode Exit fullscreen mode

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

تأكد من أمرين:

  1. رمز الحالة هو 401 أو 403.
  2. نص الاستجابة لا يتضمن بيانات جزئية أو حساسة.

استجابة 403 التي تسرّب سجلًا في النص تظل مشكلة أمنية.

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

الاختبارات الناجحة تثبت أن المسارات التي اختبرتها تم رفضها. لا تثبت عدم وجود مسار آخر غير محمي. اعتبر مجموعة الاختبارات حدًا أدنى، وأضف حالات جديدة كلما توسعت API.

قائمة مرجعية لمدى الانفجار يمكنك تنفيذها هذا الأسبوع

  • اكتب وظيفة الوكيل في جملة واحدة، ثم اذكر الإجراءات التي تحتاجها فقط.
  • امنح كل وكيل بيانات اعتماده الخاصة.
  • ألغِ الرموز المشتركة أو الإدارية التي ورثها الوكيل.
  • ارسم مدى الانفجار: الخدمات، الكائنات المقروءة، الكائنات القابلة للتعديل، والوظائف الإدارية.
  • قلّص النطاقات لتطابق الجدول.
  • أزل كل إذن أُضيف "فقط في حالة".
  • أضف فحوصات أدوار من جانب الخادم لكل نقطة نهاية تغير الحالة.
  • استخدم رموزًا مميزة قصيرة الأجل مع تدفق تحديث.
  • انقل الأسرار إلى متغيرات البيئة أو مدير أسرار.
  • تأكد من عدم وجود أسرار في Git.
  • اكتب اختبارات سلبية لعمليات POST وPATCH وDELETE المحظورة.
  • شغّل الاختبارات في CI وتحقق من 401 أو 403.

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

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

ماذا يعني مبدأ أقل الامتيازات لوكيل الذكاء الاصطناعي؟

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

ما الفرق بين BOLA وBFLA؟

BOLA يتعلق بالبيانات والكائنات: يصل المتصل إلى سجل لا يملكه أو لا يحق له قراءته، غالبًا عبر تغيير معرّف في الطلب.

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

كلاهما يتطلب فرض التفويض على الخادم، وليس الاعتماد على تعليمات الوكيل.

كيف أتحقق من أن المفتاح للقراءة فقط؟

أرسل طلبات كتابة باستخدام المفتاح نفسه:

PATCH /resource/123
POST /resource
DELETE /resource/123
Enter fullscreen mode Exit fullscreen mode

يجب أن تعيد جميعها 401 أو 403. اعتبر أي استجابة 2xx فشلًا، ثم شغّل هذه الحالات تلقائيًا في CI.

هل الرموز المميزة قصيرة الأجل كافية وحدها؟

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

أين يساعد Apidog، وأين لا يساعد؟

يساعد Apidog في:

  • اختبار نقاط النهاية برمز منخفض الامتيازات.
  • التحقق من أن طلبات الكتابة المحظورة تعيد 401 أو 403.
  • استخدام متغيرات البيئة بدل السلاسل السرية المضمنة.
  • توثيق ما يمكن لكل مفتاح الوصول إليه.

ولا يحل محل:

  • جدران حماية الشبكة.
  • تدوير الأسرار.
  • مراقبة وقت التشغيل.
  • حواجز النموذج.
  • مدير الأسرار أو التسجيل الأمني.

استخدمه لتصميم واختبار مبدأ أقل الامتيازات، ثم أضف ضوابط وقت التشغيل المناسبة.

هل يجب أن يكون لكل وكيل مفتاحه الخاص؟

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

Top comments (0)