Why AI Agents Are a Different Class of Security Problem?

AI agents introduce new security risks because they can make autonomous decisions, use powerful tools, and perform real-world actions at high speed. Their access to sensitive systems, non-deterministic behavior, and broad permissions make failures harder to predict, audit, and contain.

How Competitors Turn MCP Security Into a Revenue Line?

Many vendors package essential MCP security features—such as identity-aware access, least-privilege controls, and human approval for sensitive actions—as premium offerings. This turns critical security capabilities into paid add-ons, increasing the operational cost of running production AI systems.

What is MCP security?

MCP security entails mechanisms that govern how AI agents access tools using the Model Context Protocol. Due to MCP allowing dynamic tool access, security must extend beyond basic API protection. It includes identity propagation, schema validation, and audit trails. TrueFoundry provides this through a central gateway that manages identity, security controls, and execution logs.

What are the security risks of MCP?

MCP security poses risks because agents dynamically interact with APIs. Security risks include prompt injection attacks, tool schema manipulation, and overprivileged service tokens. Multi-agent pipelines can propagate compromised context across sensitive systems. To mitigate these threats, tool calls must be validated and identity-based permissions enforced. TrueFoundry provides a secure gateway to govern these interactions.

Is Model Context Protocol safe to use?

MCP is a neutral protocol standardizing how AI models interact with tools. Whether it is safe depends on the security measures applied. Agents can gain elevated permissions and access private databases. However, by providing robust security infrastructure, such as the gateway provided by TrueFoundry, the protocol can be safely implemented to avoid exposing corporate resources.

How does Zero Trust apply to AI Agents using MCP?

Zero Trust assumes no entity is trustworthy. For an AI Agent using MCP, this means all tool calls must be authenticated and validated before execution to stop a malicious server. Agents must execute with the same privileges as the initiating user. TrueFoundry enforces Zero Trust by requiring identity propagation and monitoring all tool calls.

What is a confused deputy attack with respect to an AI-based Agent?

A confused deputy attack occurs when an AI Agent with high privileges is tricked into performing actions on behalf of a malicious actor, potentially leading to data leaks. Since the AI Agent holds valid privileges, the system may not detect the attack. Preventing this requires scoping agent privileges and validating tool call outputs.

Why is a standard API gateway not sufficient for an MCP system?

Conventional API gateways handle deterministic calls where endpoints are known. MCP-based agents behave differently; they discover tools and dynamically create parameters. Security must be enforced at the tool schema level, not just at the network level, to block malicious code. TrueFoundry extends traditional gateways to meet new security needs related to MCP.

ما هو أمان MCP: الدليل الشامل لمبدأ عدم الثقة مطلقًا لأنظمة الذكاء الاصطناعي الوكيلية؟

By أشيش دوبي

Published: July 4, 2026

Built for Speed: ~10ms Latency, Even Under Load

Blazingly fast way to build, track and deploy your models!

Handles 350+ RPS on just 1 vCPU — no tuning needed
Production-ready with full enterprise support

Get Started with Truefoundry Now Talk to the Expert

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

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

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

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

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

Secure every MCP tool call across your enterprise infrastructure with TrueFoundry

لماذا يمثل وكلاء الذكاء الاصطناعي فئة مختلفة من مشاكل الأمان

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

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

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

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

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

سرعة الاستغلال: في حالة حدوث فشل أو سوء استخدام خبيث، يمكن لوكلاء الذكاء الاصطناعي تشغيل استدعاءات أدوات متعددة وتنفيذ تعليمات برمجية في غضون ثوانٍ، مما يتسبب في أضرار جسيمة.

MCP security attack surface compared to traditional API security model

متجهات الهجوم التي يقدمها MCP بالفعل

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

توضح الأقسام أدناه نواقل الهجوم الرئيسية التي تنشأ عن الأنظمة الممكنة بواسطة MCP.

حقن الأوامر غير المباشر

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

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

تسميم الأدوات والتلاعب بالمخطط

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

يثق الوكيل ببيانات تعريف الأداة، وهذا هو المكان الذي يحدث فيه الاستغلال، مما يخلق مخاطر أمنية كبيرة للمؤسسة.

تسريب البيانات غير المصرح به من خلال تسلسل الأدوات

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

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

لا توجد حاجة لأمر محدد "إرسال البيانات للخارج"؛ يتم استغلال الوكيل من خلال مجموعات أدوات مشروعة، مما يعرض الأنظمة الحساسة للخطر.

TrueFoundry infographic detailing common enterprise MCP security vulnerabilities

تسميم السياق في مسارات عمل الوكلاء المتعددين

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

في الأنظمة التي يمرر فيها الوكلاء المعلومات، يقوم عميل MCP مخترق في المراحل الأولية بتمرير سياق خاطئ إلى الحالة المشتركة.

يتعامل الوكيل في المراحل النهائية مع السياق المخترق على أنه موثوق به ويواصل الانتشار دون تفاعل مع المستخدم الأصلي، مما يفسد عمليات الأعمال.

الرموز الثابتة في ملفات التكوين

بينما تعد نظافة بيانات الاعتماد مشكلة معروفة، تقدم أنظمة MCP نقاط ضغط جديدة. تتجاوز سرعة النماذج الأولية للوكلاء ممارسات الأمان، وتصبح الرموز الثابتة في ملفات التكوين ضحايا.

غالبًا ما تتضمن أنظمة MCP بيانات اعتماد سحابية مبرمجة بشكل ثابت في ملفات التكوين التي تنتشر في أنظمة التحكم في الإصدار والبيئات.

الرموز الثابتة التي لا تحتوي على تدوير ولا نطاق هي من بين الإخفاقات الأكثر شيوعًا الموثقة في بنية MCP.

مبادئ الثقة المعدومة المطبقة على MCP

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

Block prompt injection attacks before they reach your agent with TrueFoundry

الأمان القائم على مبدأ الثقة المعدومة مقابل الأمان التقليدي لـ MCP — مقارنة

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

Dimension	Traditional API Security	Zero Trust MCP Security
Trust Model	Perimeter-based, internal actors trusted by default	No implicit trust; every request verified regardless of origin
Identity Scope	Human users and service accounts	Includes autonomous agent identities with lifecycle tracking
Token Management	Static tokens with periodic rotation	Short-lived, scoped tokens with automatic refresh per session
Audit Coverage	Request-level logging	Tool call, agent decision, input, and output logging
Anomaly Detection	Network and access pattern monitoring	Behavioral monitoring across full agent action chains

كيف يحول المنافسون أمان MCP إلى مصدر دخل؟

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

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

TrueFoundry strategy for establishing robust zero-trust MCP security

كيف تقدم TrueFoundry أمان MCP القائم على مبدأ الثقة المعدومة بدون تكاليف المؤسسات الإضافية

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

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

بوابة MCP مركزية: يعمل MCP Gateway من TrueFoundry كنقطة دخول محكومة واحدة لجميع حركة مرور الوكلاء إلى الأدوات، مما يمنع الإجراءات غير المصرح بها وغير المقصودة. يجب تسجيل كل خادم MCP في سجل موثق قبل أن يتمكن الوكلاء من الوصول إليه، مما يلغي نقاط ضعف التكوين المتناثرة.
التنفيذ الأصلي بالنيابة عن: يرث الوكلاء الصلاحيات الدقيقة للمستخدم الذي بدأ المهمة. يضمن التكامل المدمج مع Okta وAzure AD تطبيقًا متسقًا وقابلًا للتدقيق عبر سير العمل.
ضوابط ما قبل وبعد الاستدعاء: تتحقق TrueFoundry من صحة كل استدعاء أداة مقابل المخططات المحددة قبل التنفيذ وتفحص المخرجات بعد ذلك. يفرض هذا مبدأ الثقة المعدومة على طبقة البروتوكول، متجنبًا مخاطر أمنية جسيمة لبروتوكول MCP.
قابلية المراقبة الكاملة وميزات الأمان مضمنة بشكل قياسي: يتم تسجيل كل استدعاء أداة وإجراء وكيل ببيانات وصفية منظمة داخل شبكتك الافتراضية الخاصة (VPC)، مما يحل المخاوف الأمنية الرئيسية. تأتي سجلات التدقيق والتحكم في الوصول المستند إلى الأدوار (RBAC) بشكل قياسي، وليست محجوبة خلف مستويات ترقية المؤسسات باهظة الثمن، مما يضمن سلسلة توريد آمنة.

الخلاصة: لا تدع الوكلاء يحكمون على أعمالهم بأنفسهم

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

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

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

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

Transition your AI agents from risky prototypes to secure enterprise production deployments

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

ما هو أمان بروتوكول MCP؟

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

ما هي المخاطر الأمنية لبروتوكول MCP؟

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

هل بروتوكول سياق النموذج آمن للاستخدام؟

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

كيف ينطبق مبدأ "عدم الثقة مطلقًا" (Zero Trust) على وكلاء الذكاء الاصطناعي الذين يستخدمون MCP؟

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

ما هو هجوم "الوكيل المرتبك" (Confused Deputy Attack) فيما يتعلق بوكيل يعتمد على الذكاء الاصطناعي؟

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

لماذا لا تكفي بوابة API القياسية لنظام MCP؟

تتعامل بوابات API التقليدية مع الاستدعاءات المحددة مسبقًا حيث تكون نقاط النهاية معروفة. تتصرف الوكلاء المعتمدون على MCP بشكل مختلف؛ فهم يكتشفون الأدوات وينشئون المعلمات ديناميكيًا. يجب فرض الأمان على مستوى مخطط الأداة، وليس فقط على مستوى الشبكة، لحظر التعليمات البرمجية الضارة. توسع TrueFoundry البوابات التقليدية لتلبية الاحتياجات الأمنية الجديدة المتعلقة بـ MCP.

TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.

Built for Speed: ~10ms Latency, Even Under Load

Schedule your Demo Now