أمن MCP في الإنتاج

خادم MCP ليس مجرد واجهة برمجية أخرى، بل هو قناة تعليمات يقرأها النموذج ويتصرّف بناءً عليها. كل اسم أداة، وكل وصف معامل، وكل نص تعيده أداة، ينتهي في نافذة السياق نفسها التي يوجد فيها طلب المستخدم، والنموذج لا يملك وسيلة موثوقة للتمييز بين البيانات والأوامر. هذه الخاصية وحدها تجعل أمن Model Context Protocol تخصصًا مختلفًا عن أمن واجهات البرمجة، وتفسّر لماذا تكرّرت حوادث عام 2026 بهذا الشكل المتشابه.

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

ما الذي يغيّره MCP في نموذج التهديد لديك

في التكامل التقليدي يقرّر المطوّر أي استدعاء يجري، وبأي وسائط، وفي أي موضع من الشيفرة. أما مع MCP فيسلّم العميل إلى النموذج تعريفات الأدوات لكل الخوادم المتصلة، ويصبح النموذج هو من يختار ما يستدعيه وبأي معاملات. تختصر OWASP النتيجة بوضوح: يجمع MCP في مكان واحد حقن الأوامر النصية، ومخاطر سلسلة التوريد، ومشكلة النائب المُضلَّل.^[owaspcs]

• بيانات الأداة الوصفية تكاد تكون قابلة للتنفيذ. يقرأ النموذج الأوصاف ومخططات JSON بوصفها توجيهًا للعمل، فحقل description المسموم أقرب إلى شيفرة محقونة منه إلى توثيق.
• مخرجات الأداة مُدخلات غير موثوقة. صفحة ويب أو عنوان تذكرة أو صف من قاعدة بيانات يعود إلى السياق بالمرتبة نفسها التي يتمتع بها موجّه النظام.
• النموذج يرى كل الخوادم في آن واحد. وصف أداة من خادم خبيث قد يغيّر طريقة استخدام الوكيل لخادم آخر موثوق. هذا هو تظليل الأدوات، ولا تكشفه مراجعة كل خادم على حدة.^[owaspcs]

تصرّح المواصفة بأنها لا تحلّ ذلك نيابةً عنك: التفويض اختياري في تطبيقات MCP؛ وعند استخدام نقل HTTP ينبغي اتباع المواصفة، أما تطبيقات stdio فمطلوب منها أخذ بيانات الاعتماد من البيئة.^[spec-auth] وكل ما عدا ذلك — العزل، وسلامة الأدوات، والتحكم في الخروج — متروك لمن ينشر المضيف أو العميل أو الخادم.

حوادث 2026 التي حدّدت المعيار

أوضح حالتين هذا العام لم تأتيا من مختبرات استثنائية، بل من الإعدادات الافتراضية للمزوّدين أنفسهم. في الخامس من أغسطس 2026، وضمن مؤتمر Black Hat USA، اختبرت شركة Novee Security وكلاء البرمجة لدى Anthropic وGoogle وOpenAI ضمن الإعدادات التي يسلّمها كل مزوّد افتراضيًا. نتج عن العمل ثغرتان مسجّلتان، وكلتاهما مُصلحة. وما أتاحته كل واحدة منهما يختلف اختلافًا كبيرًا، وهنا مكمن الفائدة.^{[ghsa-google][ghsa-anthropic]}

يستحق النمط صياغة دقيقة لأنه يتجاوز هذه المنتجات الثلاثة: الخلل كان في الهيكل المحيط بالنموذج (harness) لا في النموذج نفسه. وسم أحد المكوّنات قيمةً بأنها آمنة، ثم تصرّف مكوّن لاحق بناءً عليها بصلاحية أعلى. ووفق ما نُشر في 7 أغسطس 2026 لم تظهر أي من الثغرتين في سجل CISA للثغرات المستغَلّة المعروفة، ولا يُظهر السجل العام استخدام أيٍّ من السلسلتين ضد هدف حقيقي؛ فالعبرة بصنف الخلل لا بحملة جارية.

اقرأ هذا إلى جانب النموذج التشغيلي في DevOps وMLOps وLLMOps: إن لم تستطع تسمية الحزمة الدقيقة التي أنتجت إجراءً ما — النموذج والموجّه ومخطط الأداة والسياسة — فلن تستطيع تفسير حادثة ولا الوثوق بالتراجع عن نشر.

خط الأساس الذي تفرضه المواصفة أصلًا

جزء كبير مما يسمى «أمن MCP» هو ببساطة تطبيق OAuth تطبيقًا سليمًا. أعادت مراجعة 2025-06-18 تصنيف خادم MCP بوصفه خادم موارد خالصًا في OAuth 2.1، ثم هذّبت مراجعة 2025-11-25 الاكتشاف والموافقة.^[spec-log] فإن كنت تشغّل خادم MCP بعيدًا، فما يلي ليس توصيات.^{[oauth21][rfc9700][nsa]}

الاكتشاف: RFC 9728 لا ملف README

يجب على خوادم MCP تنفيذ OAuth 2.0 Protected Resource Metadata والإعلان عن مدخل واحد على الأقل في authorization_servers، ويجب على العملاء استخدامه للاكتشاف. وعند ورود طلب غير موثّق يردّ الخادم بالرمز 401 مع ترويسة WWW-Authenticate تشير إلى وثيقة البيانات الوصفية.^{[spec-auth][rfc9728]}

curl -sSI https://mcp.example.com/mcp | grep -i '^www-authenticate'
# www-authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

curl -sS https://mcp.example.com/.well-known/oauth-protected-resource \
  | jq '{resource, authorization_servers, scopes_supported}'

curl -sS https://auth.example.com/.well-known/oauth-authorization-server \
  | jq '{issuer, token_endpoint, code_challenge_methods_supported}'

ربط الجمهور: الضابط الذي يوقف إعادة استخدام الرموز

يجب على العملاء إرسال المعامل resource المحدَّد في RFC 8707 في طلب التفويض وطلب الرمز معًا، بقيمة المُعرّف القياسي للخادم الهدف، ويجب إرساله سواء دعمه خادم التفويض أم لا.^[rfc8707] ويجب على الخادم التحقق من أن الرمز المقدَّم صادر له تحديدًا، ورفضه فيما عدا ذلك.^[spec-auth]

أما تمرير الرموز (token passthrough) — أي قبول رمز لم يصدر لك ثم تمريره إلى الخدمات التالية — فمحظور صراحةً. وحجّة المواصفة تشغيلية: يهدم مسار التدقيق، ويتجاوز حدود المعدّل وعمليات التحقق التي تعتمد على الجمهور، ويحوّل خادمك إلى وسيط لكل من يحمل رمزًا مسروقًا.^[spec-sec] وإذا كان خادم MCP لديك يستدعي واجهة برمجية أعلى، فهو عميل لديها ويحتاج رمزًا خاصًا به.

CANONICAL = "https://mcp.example.com/mcp"   # RFC 8707 resource identifier

def authorize(token: dict) -> None:
    aud = token.get("aud")
    aud = aud if isinstance(aud, list) else [aud]
    if CANONICAL not in aud:
        raise Unauthorized("token audience does not include this server")   # 401
    if not required_scopes(token).issuperset(scopes_for_current_tool()):
        raise Forbidden("insufficient scope")                               # 403
    # Never forward `token` upstream. Mint a separate one for the upstream API.

تسجيل العملاء: CIMD صار الخيار الموصى به

أضافت مراجعة 2025-11-25 وثائق البيانات الوصفية لمعرّف العميل (CIMD) بوصفها آلية التسجيل الموصى بها (SEP-991)، إلى جانب دعم OpenID Connect Discovery والموافقة التدريجية على النطاقات عبر WWW-Authenticate.^{[spec-log][cimd]} في CIMD يكون client_id عنوان HTTPS يشير إلى وثيقة JSON صغيرة تصف العميل؛ يجلبها خادم التفويض ويتحقق من عناوين إعادة التوجيه المسجّلة ويطبّق سياسته، دون تنسيق مسبق ودون تراكم التسجيلات المؤقتة التي يولّدها التسجيل الديناميكي للعملاء.

وهذا مهم لأن التسجيل الديناميكي أحد مكوّنات هجوم النائب المُضلَّل. فحين يستخدم خادم MCP وسيط معرّف عميل ثابتًا مع خادم تفويض تابع لطرف ثالث، ويسمح في الوقت نفسه بالتسجيل الديناميكي، ويضع الطرف الثالث كعكة موافقة، يستطيع المهاجم تسجيل عميل بعنوان redirect_uri خاص به، وإعادة استخدام كعكة الضحية لتخطّي شاشة الموافقة، والحصول على رمز التفويض. والعلاج هو موافقة لكل عميل مخزّنة على الخادم ومُتحقَّق منها قبل تدفّق الطرف الثالث، مع مطابقة تامة لعنوان إعادة التوجيه ومعامل state يُستخدم مرة واحدة.^[spec-sec]

لا جديد هنا في هندسة الهوية؛ إنه الانضباط نفسه المطلوب في تصميم إدارة هوية قابلة للتوسّع، وهي المفاضلات نفسها التي تظهر عند الاختيار بين Keycloak وEntra ID. أعد استخدام خادم التفويض الذي تشغّله وتدقّقه بالفعل، ولا تدع كل خادم MCP يبني خادمه الخاص.

عشرة أنماط إخفاق والضابط الذي يغلق كلًا منها

قائمة OWASP MCP Top 10 وثيقة حيّة في مرحلة تجريبية (v0.1) ومن المقرر إصدار نسخة تالية في أكتوبر 2026، فتعامل معها كقائمة تحقق لا كهدف اعتماد.^[owasp10]

التحصين طبقةً طبقة

ثبّت تعريفات الأدوات، أو اقبل بهجمات rug pull

ينجح هجوم rug pull لأن المستخدم يعتمد الأداة مرة واحدة ثم لا ينظر إليها ثانية. والحل آلي: احسب بصمة التعريف عند الاعتماد وتحقّق منها قبل كل استدعاء.

import hashlib, json

def tool_fingerprint(tool: dict) -> str:
    canonical = json.dumps(
        {"name": tool["name"],
         "description": tool.get("description", ""),
         "inputSchema": tool.get("inputSchema", {})},
        sort_keys=True, separators=(",", ":"), ensure_ascii=False)
    return hashlib.sha256(canonical.encode()).hexdigest()

if tool_fingerprint(live_tool) != PINNED[server_id][live_tool["name"]]:
    raise ToolDefinitionDrift(server_id, live_tool["name"])   # fail closed

افشل مغلقًا. الأداة التي تغيّر وصفها بعد الاعتماد أداة جديدة، وتحتاج قرارًا بشريًا جديدًا لا إعادة محاولة صامتة.

اعزل الخوادم المحلية عزلًا حقيقيًا

خادم MCP المحلي ملف تنفيذي يعمل بصلاحيات العميل. وإرشاد المواصفة للإعداد بنقرة واحدة لا لبس فيه: اعرض الأمر بالضبط دون اقتطاع، ونبّه إلى أنه يعمل بصلاحيات العميل، واعزله بأقل وصول ممكن إلى نظام الملفات والشبكة.^[spec-sec] وفضّل stdio محليًا لأنه يحصر الوصول في عملية العميل. وإن لزم HTTP فاربطه بـ 127.0.0.1 — لا بـ 0.0.0.0 أبدًا — واشترط رمزًا، وتحقق من ترويسة Host في كل طلب.^[owaspcs]

docker run --rm -i \
  --network none \
  --read-only --tmpfs /tmp:rw,noexec,nosuid,size=64m \
  --cap-drop ALL --security-opt no-new-privileges \
  --pids-limit 128 --memory 512m --cpus 1 \
  --user 10001:10001 \
  -v "$PWD/workspace:/workspace:ro" \
  ghcr.io/example/mcp-server@sha256:<digest>

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

تحكّم في الخروج: ثغرة SSRF تقع في مسار الاكتشاف

يسهل إغفال هذه النقطة لأنها تستهدف العميل لا الخادم. فأثناء اكتشاف OAuth يجلب العميل عناوين يزوّده بها الخادم: عنوان resource_metadata من ترويسة WWW-Authenticate، ثم مدخلات authorization_servers، ثم نقاط النهاية في بيانات خادم التفويض. ويستطيع خادم خبيث توجيه أي منها إلى http://169.254.169.254/ فيقرأ بيانات اعتماد نسخة السحابة عبر عميلك.^[spec-sec]

ينبغي للعملاء اشتراط HTTPS خارج العنوان المحلي، وحجب النطاقات الخاصة والمحلية للوصلة (10/8 و172.16/12 و192.168/16 و127/8 و169.254/16 وfc00::/7 وfe80::/10)، وتطبيق القواعد نفسها على كل قفزة إعادة توجيه، وتمرير عمليات النشر الخادمية عبر وكيل خروج. وتحذّر المواصفة صراحةً من كتابة تحقق العناوين يدويًا — إذ تتجاوز الترميزات الثمانية والست عشرية وIPv4 المسقطة على IPv6 معظم المحلّلات المنزلية — كما تحذّر من إعادة ربط DNS بين التحقق والاستخدام.^{[spec-sec][owaspssrf]}

وكلاء البرمجة في التكامل المستمر: أثمن هدف تملكه

الوكيل داخل خط التكامل المستمر يملك صلاحية الكتابة على المستودع وأسرار مسار العمل، ومدخلاته هي ما كتبه شخص غريب في تذكرة. وهذا بالضبط هو الإعداد الذي هاجمه بحث Black Hat.

on:
  issues:
    types: [opened]

permissions:
  contents: read
  issues: read
  id-token: none

jobs:
  triage:
    runs-on: ubuntu-latest
    environment: agent-sandbox
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@<commit-sha>
        with: { persist-credentials: false }

      - run: printf '%s' "$ISSUE_BODY" > /tmp/untrusted.md
        env:
          ISSUE_BODY: ${{ github.event.issue.body }}

      - run: agent-cli review --input /tmp/untrusted.md --sandbox read-only --no-network

• لا تُدرج أبدًا ${{ github.event.* }} داخل نص run:؛ مرّرها عبر متغير بيئة أو ملف.
• ملفات تعليمات المستودع مُدخل غير موثوق. هذا ما تقوله إرشادات OpenAI نفسها بعد أن سمح تشارك النسخة بين تشغيلين من Codex بأن يكتب الأول تعليمات الثاني.^[codex]
• شغّل الوكيل في آخر خطوة. تحذّر الإرشادات نفسها من أنه قد يترك ملفات لخطوات لاحقة ذات امتياز.^[codex]
• افصل التشغيلات في مهام مستقلة بنسخ مستقلة من المستودع، حتى لا يكتب تشغيل مدخلات التشغيل التالي.
• حدّث الهيكل المحيط. Gemini CLI 0.39.1 وrun-gemini-cli 0.1.22 وClaude Code 2.1.163، ثم دقّق كل مسار عمل يمكن لشخص خارجي تشغيله.

التدقيق: اجعل كل استدعاء قابلًا لإعادة البناء

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

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

جولة تحقق يمكنك تنفيذها اليوم

تسعة فحوص: 1) رفض الطلب غير الموثّق مع مؤشر صالح للاستخدام؛ 2) نشر بيانات المورد المحمي؛ 3) رفض رمز صادر لجمهور آخر؛ 4) عدم قبول HTTP العادي؛ 5) ألا تستمع الخوادم المحلية على كل الواجهات؛ 6) تطابق تعريفات الأدوات مع المعتمد؛ 7) تثبيت الصور ببصمة؛ 8) خلو خطوات الصدفة من إدراج بيانات الأحداث؛ 9) بلوغ إصدارات الهيكل المحيط النسخ المصلَحة أو تجاوزها.

# 1
curl -sS -o /dev/null -w '%{http_code}\n' https://mcp.example.com/mcp

# 2
curl -sSf https://mcp.example.com/.well-known/oauth-protected-resource | jq -e '.authorization_servers[0]'

# 3
curl -sS -o /dev/null -w '%{http_code}\n' -H "Authorization: Bearer $TOKEN_FOR_OTHER_AUDIENCE" \
  https://mcp.example.com/mcp

# 4
curl -sS -o /dev/null -w '%{http_code}\n' http://mcp.example.com/mcp

# 5
ss -ltnp | grep -E '0\.0\.0\.0|\[::\]'

# 6
mcp-inspect list-tools --server internal | sha256sum

# 7
grep -rEn 'image:\s*\S+:(latest|main|v?[0-9]+)\s*$' deploy/

# 8
grep -rn 'github\.event\.\(issue\|comment\|pull_request\)' .github/workflows/ | grep 'run:'

# 9
gemini --version; claude --version

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

ما ينبغي فعله هذا الأسبوع

يستحق MCP التبنّي. فالبروتوكول يزيل صنفًا حقيقيًا من عناء التكامل، ونقلت مراجعة 2025-11-25 قرارات أمنية مهمة من الأعراف إلى نص المواصفة. لكنه يُسلَّم بوصفه قدرة لا مستوى تحكّم. والضوابط المهمة هي تلك التي تعرفها أصلًا من عمل الهوية وسلسلة التوريد، مطبَّقة على حدٍّ لم ترسمه معظم الفرق بعد.

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

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

هل MCP آمن افتراضيًا؟

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

ما هو تسميم الأدوات في MCP؟

هو التلاعب بالأدوات التي يعتمد عليها الوكيل حتى يتغيّر سلوك النموذج. وتجمع OWASP تحته ثلاث تقنيات فرعية: rug pull حين يتغيّر وصف أداة معتمدة بعد الموافقة؛ وتسميم المخطط حين يضلّل تعريف الواجهة نفسه النموذج؛ وتظليل الأدوات حين يغيّر وصف خادم خبيث طريقة استخدام أدوات خادم آخر موثوق. وتثبيت بصمة على الاسم والوصف ومخطط الإدخال والتحقق منها قبل كل استدعاء يغلق الأوليين ويكشف الثالثة.

هل يلزم استخدام OAuth لخادم MCP؟

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

ما هو تمرير الرموز ولماذا هو محظور؟

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

هل تُستغل ثغرات MCP فعليًا في الواقع؟

حتى تاريخ النشر لا تظهر CVE-2026-12537 ولا CVE-2026-54316 في سجل CISA للثغرات المستغَلّة المعروفة، ولا تُظهر التقارير العامة استخدام أي من السلسلتين ضد هدف. غير أن مستودعًا عامًا لإعادة إنتاج ثغرة Claude Code قائم منذ يونيو 2026، فاعتبر سرعة التحديث لديك هي العامل الحاسم، لا توافر أداة الاستغلال.

كيف أمنع خادم MCP خبيثًا من الوصول إلى شبكتي الداخلية؟

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

ما هي وثائق البيانات الوصفية لمعرّف العميل (CIMD)؟

هي آلية لتسجيل العملاء أضيفت خيارًا موصى به في مراجعة MCP 2025-11-25 ضمن SEP-991. يكون client_id عنوان HTTPS يشير إلى وثيقة JSON تصف العميل وعناوين إعادة التوجيه الخاصة به، ويجلبها خادم التفويض ويتحقق منها عند الحاجة. وهذا يتجنّب معرّفات العملاء المضمّنة في الشيفرة وتراكم التسجيلات المؤقتة الناتجة عن التسجيل الديناميكي، ويزيل أحد مكوّنات هجوم النائب المُضلَّل.

المصادر ومراجع إضافية

نص المواصفة، ووثائق RFC الصادرة عن IETF، ومواد مشاريع OWASP، وورقة المعلومات الأمنية الصادرة عن وكالة الأمن القومي الأمريكية، والإرشادات الرسمية للمزوّدين المستخدمة في هذه المقالة.

1. Model Context Protocol — Authorization (specification 2025-11-25)
2. Model Context Protocol — Security Best Practices
3. Model Context Protocol — Key Changes, revision 2025-11-25
4. SEP-991 — OAuth Client ID Metadata Documents for MCP
5. RFC 9728 — OAuth 2.0 Protected Resource Metadata
6. RFC 8707 — Resource Indicators for OAuth 2.0
7. RFC 9700 — Best Current Practice for OAuth 2.0 Security
8. OAuth 2.1 — draft-ietf-oauth-v2-1-13
9. OWASP MCP Top 10 (beta, v0.1)
10. OWASP Cheat Sheet Series — MCP Security
11. OWASP Cheat Sheet Series — SSRF Prevention
12. NSA Artificial Intelligence Security Center — CSI: MCP Security Design Considerations for AI-Driven Automation
13. GHSA-fg94-h982-f3mm — Out-of-Band Data Exfiltration via Pre-Approved HuggingFace Domain in WebFetch
14. NVD — CVE-2026-54316
15. GHSA-wpqr-6v78-jr5g — Google run-gemini-cli security advisory
16. NVD — CVE-2026-12537
17. OpenAI — codex-action security guidance