الوصول الفعلي في وكلاء الذكاء الاصطناعي: ما الذي يستطيع النظام الوصول إليه حقًا؟

ما هو الوصول الفعلي Effective Access؟

الوصول الفعلي Effective Access هو النطاق الحقيقي للبيانات والأنظمة والأدوات والموارد التي يستطيع نظام أو وكيل ذكاء اصطناعي الوصول إليها تقنيًا في البيئة الفعلية.

المفهوم لا يركز على ما يفترض أن يستطيع النظام الوصول إليه.

بل على ما تسمح به البنية التقنية فعليًا.

قد تقول المؤسسة:

هذا Agent مخصص لخدمة عميل واحد.

لكن إذا كانت Credential التي يستخدمها تسمح بالوصول إلى قاعدة بيانات العملاء كاملة، فإن Effective Access أوسع بكثير من Intended Access.

لماذا هذا المفهوم مهم؟

في Agentic AI، الخطر لا يرتبط فقط بما يطلب من Agent أن يفعله.

بل بما يستطيع فعله إذا:

• أخطأ.
• تعرض لـPrompt Injection.
• استخدم Tool بصورة غير متوقعة.
• حصل خلل في Workflow.
• تغيرت Permissions.
• تم استدعاء Integration جديدة.
• استخدمت Credential أوسع من اللازم.

لذلك يجب أن يقاس الخطر وفقًا للوصول الحقيقي.

النموذج الرباعي للوصول

يمكن التمييز بين أربع طبقات:

1. Intended Access.
2. Configured Access.
3. Effective Access.
4. Exercised Access.

هذا الفصل مهم لأنه يمنع الخلط بين التصميم والواقع والاستخدام الفعلي.

Intended Access

Intended Access هو ما تتوقع المؤسسة أن يستطيع النظام الوصول إليه وفق التصميم والسياسة والاستخدام المعتمد.

مثلًا:

Agent خدمة عملاء → سجل العميل الحالي فقط.

أو:

Agent مالي → الفواتير التي تخص الوحدة المعتمدة فقط.

Intended Access يعبر عن النية الحوكمية.

لكنه لا يثبت أن البيئة التقنية تفرض هذا الحد فعليًا.

Configured Access

Configured Access هو ما تم إعداده في الأنظمة التقنية.

مثل:

• IAM Role.
• Database Permission.
• API Scope.
• File Permission.
• Network Rule.
• MCP Tool Configuration.
• Credential Scope.

قد يكون Configured Access أوسع أو أضيق من Intended Access.

إذا كان أوسع، فهناك فجوة.

Effective Access

Effective Access هو ما يستطيع النظام الوصول إليه فعليًا عند جمع كل مصادر الوصول معًا.

وهذا قد يشمل:

• Direct Access.
• Delegated Access.
• Tool-mediated Access.
• API Access.
• MCP Access.
• Network-reachable Systems.
• Shared Credentials.
• Chained Agent Access.
• Indirect Data Paths.

Effective Access هو الصورة الحقيقية لسطح الوصول.

Exercised Access

Exercised Access هو ما استخدمه النظام فعليًا خلال فترة زمنية محددة.

مثل:

• الملفات التي قرأها.
• APIs التي استدعاها.
• قواعد البيانات التي استعلم عنها.
• الأدوات التي استخدمها.
• الأنظمة التي اتصل بها.

Exercised Access مهم للمراقبة.

لكن عدم استخدام صلاحية لا يعني أنها غير موجودة.

الفرق بين Effective Access وExercised Access

قد يملك Agent صلاحية واسعة لكنه لم يستخدمها بعد.

مثلًا:

Effective Access → يستطيع قراءة 2 مليون سجل

Exercised Access → قرأ 25 سجلًا فقط

هذا لا يعني أن الخطر محصور في 25 سجلًا.

الخطر الحقيقي يجب أن يأخذ في الاعتبار ما يستطيع Agent الوصول إليه إذا تغير سلوكه أو تم التلاعب به.

قراءة سيادة: Access Gap

يمكن تعريف Access Gap بأنه الفرق بين:

Intended Access و Effective Access

كلما اتسعت الفجوة، زادت مساحة المخاطر غير الضرورية.

مثال:

Intended Access → Customer Record واحد

Effective Access → Entire CRM

هذه فجوة كبيرة.

كيف ينشأ Effective Access؟

Effective Access لا يأتي من Permission واحدة فقط.

هو نتيجة تجميع عدة عناصر:

• Identity.
• IAM.
• Credentials.
• API Scopes.
• Database Permissions.
• File Permissions.
• Tools.
• MCP Servers.
• Network Paths.
• Data Stores.
• Delegation.
• Chained Agents.
• Orchestration.

لذلك لا يكفي مراجعة Role واحدة فقط.

العنصر الأول: Identity

كل وصول يبدأ من هوية.

قد تكون:

• Agent Identity.
• Service Account.
• Workload Identity.
• User Delegation.
• Shared Credential.
• API Key.
• OAuth Token.

السؤال هو:

بأي هوية ينفذ Agent؟

هذه الهوية تحدد نقطة البداية للوصول.

Shared Identity توسع الغموض

إذا استخدمت عدة Agents نفس الهوية، يصعب تحديد:

• من نفذ الفعل؟
• أي Agent استخدم الصلاحية؟
• أي Agent يجب تعطيله؟
• أي Workflow تسبب في الحدث؟

وهذا يضعف:

• Accountability.
• Auditability.
• Revocation.
• Least Agency.

العنصر الثاني: IAM

IAM تحدد جزءًا مهمًا من Effective Access.

يجب فحص:

• Roles.
• Policies.
• Groups.
• Inherited Permissions.
• Temporary Grants.
• Cross-account Access.
• Service-to-service Access.

أحد الأخطاء الشائعة هو تقييم Role المباشرة فقط وتجاهل الصلاحيات الموروثة.

Effective Access قد يكون نتيجة Permissions متراكمة

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

مثل:

Direct Role + Group Membership + Delegated Token + Tool Credential

الناتج النهائي قد يكون أوسع من كل عنصر منفرد.

العنصر الثالث: API Scopes

الـAPI قد تسمح بأكثر مما يحتاجه Agent.

مثل:

read:customer

مقابل:

read:all-customers

أو:

read-only

مقابل:

read-write

يجب فحص Scope الحقيقي وليس اسم Integration فقط.

العنصر الرابع: Database Permissions

Database Access قد يكون واسعًا بصورة غير واضحة.

راجع:

• Database.
• Schema.
• Table.
• Row.
• Column.
• Stored Procedures.
• Functions.
• Views.

Agent يحتاج سجلًا واحدًا لا يعني أنه يجب أن يمتلك SELECT على الجدول كاملًا.

Row-level Access

من أقوى طرق تقليل Effective Access استخدام:

• Row-level Security.
• Scoped Views.
• Tenant Isolation.
• Query Mediation.
• Purpose-bound Retrieval.

هذه الضوابط تقلل الوصول نفسه بدل الاعتماد على سلوك النموذج.

العنصر الخامس: File Access

قد يصل Agent إلى:

• Shared Drives.
• Cloud Storage.
• Local Files.
• Document Repositories.
• Source Code.
• Archives.

يجب معرفة:

• ما المجلدات؟
• ما أنواع الملفات؟
• هل الوصول Read أم Write؟
• هل يمكن Upload؟
• هل يمكن Delete؟

العنصر السادس: Tools

Tool قد تمنح وصولًا غير مباشر.

مثلًا:

Agent لا يملك Database Credential مباشرة.

لكن لديه Tool اسمها:

Customer Lookup Tool

إذا كانت Tool نفسها تستطيع قراءة قاعدة البيانات كاملة، فإن Effective Access يجب أن يأخذ ذلك في الاعتبار.

قراءة سيادة: Tool-mediated Access

Tool-mediated Access هو الوصول الذي يحصل عليه Agent عبر أداة وسيطة.

هذا مهم لأن مراجعة Credentials الخاصة بالـAgent وحدها قد تعطي صورة ناقصة.

Agent → Tool → Backend Service → Database

الوصول الفعلي قد يكون في الطبقة الخلفية.

العنصر السابع: MCP Servers

MCP Server يمكن أن يوسع Effective Access بسرعة.

قد يعرض:

• File Resources.
• Database Tools.
• Email Tools.
• Git Tools.
• SaaS Tools.
• Internal APIs.

السؤال ليس فقط:

ما MCP Server المتصل؟

بل:

ما الموارد والأدوات التي أصبح Agent قادرًا على استخدامها من خلاله؟

MCP Tool Exposure

إذا كان MCP Server يعرض عشرين أداة، وAgent يستطيع استدعاءها كلها، فإنها كلها جزء من Effective Access.

حتى إذا كان Prompt يطلب استخدام اثنتين فقط.

العنصر الثامن: Credentials

Credentials قد تكون:

• API Keys.
• OAuth Tokens.
• Service Account Keys.
• Certificates.
• Temporary Tokens.
• Secrets.

يجب فحص:

• Scope.
• Expiry.
• Rotation.
• Owner.
• Environment.
• Revocation.

Credential واسعة قد توسع Effective Access بشكل كبير.

العنصر التاسع: Network Paths

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

راجع:

• Internet Egress.
• Private Networks.
• VPC Peering.
• VPN.
• Internal DNS.
• Proxy Rules.
• Firewall Policies.
• Service Mesh.

Network Reachability جزء من Effective Access.

الوصول الممكن ليس فقط ما تم Integrate معه

إذا كان Agent يستطيع تقنيًا الوصول إلى Endpoint داخلي، فهذا قد يكون جزءًا من سطح الوصول حتى لو لم يكن هناك Workflow رسمي يستخدمه.

لذلك يجب فحص Reachability لا Integration فقط.

العنصر العاشر: Data Stores

قد توجد بيانات في أماكن غير واضحة مثل:

• Vector Stores.
• Caches.
• Logs.
• Conversation History.
• Agent Memory.
• Temporary Storage.
• Object Storage.
• Search Indexes.

هذه كلها قد تصبح مصادر وصول فعلي.

العنصر الحادي عشر: Delegated Access

قد ينفذ Agent باسم مستخدم أو خدمة أخرى.

مثل:

Agent → User OAuth Token → SaaS System

هنا يجب أن يدخل الوصول المفوض ضمن Effective Access.

إذا كان المستخدم يملك وصولًا واسعًا، قد يرث Agent جزءًا من هذا الوصول.

العنصر الثاني عشر: Chained Agents

في Multi-Agent Systems، Agent قد لا يمتلك الوصول مباشرة.

لكنه يستطيع استدعاء Agent آخر يملكه.

Agent A → Agent B → Tool → Sensitive System

إذا كان A يستطيع تشغيل B بلا قيود، فيجب التفكير في الوصول المتسلسل.

قراءة سيادة: Transitive Access

Transitive Access هو الوصول الذي يصبح ممكنًا عبر سلسلة من الوكلاء أو الأدوات أو الخدمات.

هذا يعني أن Effective Access لا يقتصر دائمًا على العلاقات المباشرة.

يجب السؤال:

ما الذي يستطيع Agent الوصول إليه عبر ما يستطيع استدعاءه؟

Orchestration قد توسع الوصول

Workflow Engine أو Orchestrator قد يربط Agent بخدمات لم تظهر في مراجعة الوكيل نفسه.

مثل:

Agent → Workflow → Integration → ERP

لذلك يجب أن تشمل المراجعة طبقة الأوركسترا.

Effective Access هو خاصية للنظام ككل

من الخطأ اعتباره خاصية للنموذج فقط.

Effective Access ينتج من:

Model + Identity + Permissions + Tools + MCP + Network + Credentials + Orchestration + Dependencies

ولهذا يجب تقييم النظام كاملًا.

كيف تقيس Access Gap؟

يمكن التعامل مع Access Gap على أنها الفرق بين:

Intended Access و Effective Access

لكن القياس لا يجب أن يكون عدديًا فقط.

يمكن تقييم الفجوة عبر أسئلة مثل:

• هل Effective Access أوسع من Use Case؟
• هل توجد بيانات لا يحتاجها Agent؟
• هل توجد أنظمة جانبية يستطيع الوصول إليها؟
• هل توجد Write Permissions غير لازمة؟
• هل توجد أدوات لا تستخدمها المهمة؟
• هل يوجد Network Egress غير ضروري؟
• هل يمكنه استدعاء Agent آخر أوسع صلاحية؟

كل إجابة نعم تعني أن هناك مساحة وصول إضافية تستحق التبرير أو التقليص.

قراءة سيادة: Access Gap Severity

يمكن تصنيف فجوة الوصول تشغيليًا إلى:

• Narrow Gap.
• Moderate Gap.
• Wide Gap.
• Critical Gap.

ليس كمعيار رسمي، بل كطريقة داخلية تساعد على ترتيب المعالجة.

مثال:

Intended Access → Read one customer record

Effective Access → Read all customers

قد تكون فجوة واسعة.

أما:

Intended Access → Read one folder

Effective Access → Read folder + sibling folder

فقد تكون أقل حدة، بحسب حساسية البيانات.

Authorization Graph

من أفضل طرق فهم Effective Access بناء رسم للعلاقات بين:

• Identities.
• Roles.
• Tools.
• MCP Servers.
• APIs.
• Services.
• Databases.
• Files.
• Network Destinations.
• Agents.

الفكرة هي الانتقال من قائمة Permissions إلى خريطة علاقات.

كيف يبدو Authorization Graph؟

يمكن تصور سلسلة مثل:

Agent → Workload Identity → IAM Role → MCP Server → Tool → Internal API → Database

أو:

Agent A → Agent B → Shared Credential → SaaS → Customer Data

كل مسار من هذه المسارات قد يخلق وصولًا لم يظهر عند فحص Agent وحده.

Direct vs Indirect Access

Direct Access هو الوصول المباشر.

مثل:

Agent → Database

أما Indirect Access فقد يكون:

Agent → Tool → Backend Service → Database

أو:

Agent → Agent B → API → Sensitive System

الاثنان يجب أن يدخلا في Effective Access.

قراءة سيادة: Access Path

Access Path هو المسار الكامل الذي يسمح لوكيل بالوصول إلى أصل أو بيانات أو نظام.

يمكن أن يحتوي المسار على عدة طبقات.

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

الوصول عبر أدوات وسيطة

Tool قد تنفذ عمليات أوسع مما يظهر من اسمها.

مثلًا:

Customer Search Tool

قد تبدو محدودة.

لكن Backend الخاص بها قد يملك:

• Read full CRM.
• Export.
• Search unrestricted.
• Cross-tenant access.

لذلك يجب تقييم الأداة وظيفيًا وتقنيًا، لا بالاسم فقط.

Effective Access وLeast Agency

Least Agency يطلب منح النظام أقل قدر من السلطة اللازمة.

لكن لا يمكن تطبيقه إذا لم تعرف Effective Access أصلًا.

بصيغة أبسط:

لا تستطيع تقليل ما لا تستطيع قياسه.

لذلك العلاقة هي:

Effective Access → يحدد الواقع

Least Agency → يحدد ما يجب تقليصه

مثال عملي

Intended Access:

Agent → Read current ticket

Effective Access:

Agent → Read all tickets → Access customer profile → Use email tool → Call external API

هنا Least Agency تعني تقليص Effective Access ليتوافق مع المهمة.

Effective Access وAI-BOM

AI-BOM يمكن أن يكون مصدرًا مهمًا لرسم Effective Access.

إذا كان AI-BOM يسجل:

• Data Sources.
• Tools.
• MCP Servers.
• APIs.
• Credentials.
• Target Systems.
• Network Access.

فيمكن استخدامه لبناء خريطة الوصول.

لكن AI-BOM وحده لا يكفي إذا لم يعكس الحالة الفعلية.

قراءة سيادة: Declared Access vs Observed Access

Declared Access هو ما يسجله AI-BOM أو التصميم.

Observed Access هو ما يظهر من:

• Logs.
• Network telemetry.
• API calls.
• Tool invocations.
• Database queries.
• Cloud audit events.

الفجوة بينهما قد تكشف Drift.

Effective Access وLethal Trifecta

Lethal Trifecta تعتمد جزئيًا على الوصول الفعلي للبيانات.

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

لذلك يجب تقييم:

Sensitive Data وفق Effective Access

وليس Intended Access فقط.

مثال على Lethal Trifecta

Agent:

• يستقبل Email خارجي.
• يملك Effective Access واسعًا إلى CRM.
• يملك Email Tool للإرسال.

حتى لو كان Prompt يقول:

"لا ترسل بيانات حساسة"

فالبنية نفسها تسمح بمسار خطر.

Effective Access وAgent Authority

هنا يجب التفريق بين:

Access و Authority

Effective Access يجيب:

ما الذي يستطيع النظام الوصول إليه تقنيًا؟

Agent Authority يجيب:

ما الذي فوضته المؤسسة للوكيل أن يفعله؟

قد يكون Access أوسع من Authority.

وهذه حالة مهمة جدًا.

مثال على الفرق

Agent يستطيع تقنيًا:

• Read.
• Modify.
• Delete.

لكن Authority المعتمدة هي:

• Read only.

إذن:

Effective Access أوسع من Agent Authority

وهنا توجد مشكلة تصميم.

Authority Envelope

Authority Envelope يحدد الحدود التي يجب أن تبقى السلطة داخلها.

يمكن أن تشمل:

• Data Boundary.
• Action Boundary.
• Financial Limit.
• Time Limit.
• Geographic Limit.
• Approval Condition.
• Transaction Limit.

لكن إذا كان Effective Access يتجاوز هذه الحدود، تصبح الحماية معتمدة على السلوك بدل التقنية.

قراءة سيادة: Access-Authority Misalignment

يمكن تعريف Access-Authority Misalignment بأنه وجود قدرة تقنية تتجاوز السلطة المؤسسية المفوضة.

مثال:

Authority → Draft recommendation only

Effective Access → Execute transaction

هذا Misalignment واضح.

لماذا Misalignment خطير؟

لأن المؤسسة قد تكون قد صممت السياسة بشكل صحيح، لكن البيئة التقنية تسمح بأكثر.

عند الخطأ أو التلاعب، النظام قد يستخدم Access لا يملك Authority مؤسسية لاستخدامه.

العلاقة مع Human Oversight

Human Oversight قد يقلل بعض المخاطر.

لكن إذا كان Agent يملك Effective Access واسعًا، يجب ألا يعتمد التحكم بالكامل على Approval.

الأفضل أن تكون الحدود التقنية نفسها أضيق.

العلاقة مع Kill Switch

كلما اتسع Effective Access، زادت أهمية Revocation.

يجب أن تعرف المؤسسة:

• أي Identity يجب تعطيلها؟
• أي Credential يجب إلغاؤها؟
• أي Tool يجب وقفها؟
• أي MCP Server يجب قطعها؟
• أي Network Path يجب إغلاقها؟

Effective Access الجيد يجب أن يكون قابلًا للعزل.

قراءة سيادة: Revocable Access

الوصول الجيد حوكميًا ليس فقط محدودًا.

بل يجب أن يكون:

• معروفًا.
• مراقبًا.
• قابلًا للإلغاء.
• قابلًا للتجزئة.
• قابلًا للتتبع.

إذا احتجت لإيقاف النظام كله لإلغاء Access صغيرة، فالتصميم غير دقيق.

Dynamic Access

Effective Access قد يتغير مع الزمن.

مثلًا:

• Temporary Role.
• JIT Access.
• Delegated Token.
• Session Token.
• Workflow Grant.
• Emergency Access.

لذلك لا يكفي Snapshot واحد.

قراءة سيادة: Time-aware Effective Access

Time-aware Effective Access يعني تقييم الوصول مع الزمن.

السؤال ليس فقط:

ما الذي يستطيع Agent الوصول إليه؟

بل:

متى يستطيع الوصول إليه؟ ولكم من الوقت؟ وفي أي Workflow؟ وبأي Token؟

الوصول داخل Multi-Agent Systems

Multi-Agent Systems تجعل القياس أصعب.

قد يكون لكل Agent Scope محدود.

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

Agent A → invokes Agent B → invokes Agent C → accesses Sensitive System

قراءة سيادة: Aggregate Agent Access

Aggregate Agent Access هو مجموع الوصول الممكن عبر مجموعة Agents مترابطة.

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

Effective Access في بيئات SaaS

قد تمنح SaaS Integration وصولًا واسعًا عبر OAuth.

راجع:

• Scopes granted.
• Tenant coverage.
• Data classes.
• Admin consent.
• User delegation.
• Refresh tokens.

OAuth Consent واسع قد يكون أحد أكبر مصادر Effective Access غير المرئي.

Effective Access في Cloud

في Cloud Environments، راجع:

• IAM roles.
• Cross-account roles.
• Service identities.
• Secret stores.
• Storage permissions.
• Network policies.
• Serverless permissions.
• Managed identity bindings.

Agent داخل Cloud قد يرث Access من البيئة نفسها.

Effective Access في RAG

RAG قد يبدو Read Only.

لكن يجب فحص:

• ما corpus؟
• ما Vector Store؟
• هل هناك Tenant Isolation؟
• هل توجد Metadata Filters؟
• هل يمكن Query كل index؟
• هل Retrieval يعيد بيانات حساسة؟

RAG نفسه قد يوسع Effective Access.

Effective Access في Memory

Agent Memory قد تحمل معلومات من جلسات أو مستخدمين سابقين.

راجع:

• Memory scope.
• User isolation.
• Tenant isolation.
• Retention.
• Write access.
• Readback rules.

إذا كانت Memory مشتركة، فقد تنشئ وصولًا غير متوقع.

Effective Access وShadow AI

Shadow AI قد يمتلك Access غير موثق إطلاقًا.

مثل:

• Personal SaaS account.
• Browser extension.
• IDE plugin.
• Unapproved API key.
• Local model with shared folder access.

إذا لم يكن الأصل موجودًا في Inventory، فلن يظهر Effective Access في التقييم.

قراءة سيادة: Unknown Access

Unknown Access هو أي وصول فعلي لا يظهر في السجل المؤسسي أو Baseline.

هذا من أخطر الأنواع لأنه لا يخضع عادة للمراجعة.

لماذا الوصول غير المعروف أخطر من الوصول الواسع أحيانًا؟

الوصول الواسع المرئي يمكن تقليصه.

أما الوصول غير المعروف فقد لا تدرك المؤسسة وجوده أصلًا.

لذلك Discovery جزء أساسي من Effective Access Governance.

بناء Effective Access Baseline

قبل تشغيل Agent في بيئة فعلية، يجب أن تعرف المؤسسة ما هو الوصول المعتمد له.

يمكن أن يحتوي Baseline على:

• Approved Purpose.
• Approved Identity.
• Approved Data Sources.
• Approved Systems.
• Approved APIs.
• Approved Tools.
• Approved MCP Servers.
• Approved Network Destinations.
• Approved Credentials.
• Approved Delegations.
• Approved Agent-to-Agent Calls.
• Approved Access Duration.
• Approved Write Permissions.
• Approved Administrative Permissions.

الهدف هو إنشاء صورة مرجعية يمكن مقارنة الواقع بها.

Baseline ليس Inventory فقط

Inventory يجيب:

ما المكونات الموجودة؟

أما Effective Access Baseline فيجيب:

ما مسارات الوصول المسموح بها بين هذه المكونات؟

قد يكون لديك Inventory كامل، ومع ذلك لا تعرف أن:

Agent A → يستطيع استدعاء Tool B → التي تستخدم Credential C → للوصول إلى System D

لهذا يجب توثيق العلاقات، لا العناصر فقط.

قراءة سيادة: Access Baseline

Access Baseline هو السجل المعتمد لمسارات الوصول التي يفترض أن تكون متاحة للنظام.

يمكن استخدامه لاحقًا لاكتشاف:

• Excess Access.
• Unknown Access.
• Access Drift.
• Unauthorized Delegation.
• Unexpected Network Paths.

Discovery قبل التقييد

لا يمكن تقليص Effective Access دون اكتشافه أولًا.

ابدأ بجمع أدلة من:

• IAM.
• Cloud control plane.
• API gateways.
• Databases.
• MCP configurations.
• Tool registries.
• Secrets managers.
• Network policies.
• SaaS integrations.
• OAuth consent.
• Agent orchestration.
• Audit logs.

ثم اربطها بالـAgent الصحيح.

لا تعتمد على Documentation فقط

Documentation قد تقول إن Agent يستخدم ثلاثة أنظمة.

لكن Logs قد تكشف خمسة.

Configuration قد تكشف سبعة.

Network telemetry قد تكشف مسارًا ثامنًا.

لذلك يجب مقارنة:

Declared Configured Observed

قراءة سيادة: Effective Access Discovery

Effective Access Discovery هو عملية اكتشاف جميع مسارات الوصول المباشرة وغير المباشرة والمتسلسلة التي يستطيع النظام استخدامها فعليًا.

هذه العملية يجب أن تشمل:

• Identity paths.
• Permission paths.
• Tool paths.
• Network paths.
• Delegation paths.
• Agent chains.

Maximum Effective Access

من المفيد ألا تسأل فقط:

ما الذي يستخدمه Agent عادة؟

بل:

ما أقصى نطاق يمكنه الوصول إليه باستخدام جميع القدرات المتاحة له حاليًا؟

هذا هو Maximum Effective Access.

قراءة سيادة: Maximum Effective Access

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

هذا لا يعني أن Agent سيستخدم هذا الوصول.

لكنه يحدد حدود Blast Radius الممكنة.

الفرق بين Effective Access وMaximum Effective Access

يمكن أن يكون Effective Access في Workflow محدد محدودًا.

لكن نفس Agent قد يمتلك قدرات أخرى غير مستخدمة في ذلك الـWorkflow.

لذلك يمكن النظر إلى:

Effective Access → الوصول الممكن ضمن السياق الحالي

Maximum Effective Access → أقصى وصول ممكن عبر جميع المسارات المتاحة

هذا التمييز مفيد عند تحليل أسوأ سيناريو معقول.

مثال على Maximum Effective Access

Agent يستخدم عادة:

• CRM Read.
• Ticketing Read.

لكن Identity نفسها تسمح أيضًا بـ:

• CRM Write.
• Customer Export.
• Marketing API.
• Shared Drive.

إذن الاستخدام اليومي لا يعكس السطح الكامل.

تصميم Access Matrix

يمكن للمؤسسة بناء Matrix لكل Agent تحتوي على:

الهدف ليس إنتاج Score شكلي.

الهدف رؤية أين يتجاوز الواقع الحاجة.

Access Matrix والتدقيق

يمكن للمدقق أخذ كل صف والتحقق منه من Configuration فعلية.

مثلًا:

Data → افحص Database grants.

Tools → افحص Tool registry.

MCP → افحص Server configuration.

Network → افحص firewall وegress rules.

Identity → افحص IAM وtokens.

تقليص Effective Access

بعد Discovery، تبدأ المعالجة.

يمكن استخدام:

• Scoped identities.
• Narrow IAM roles.
• Row-level security.
• Column restrictions.
• Read-only APIs.
• Tool allowlists.
• MCP tool filtering.
• Network allowlists.
• Short-lived credentials.
• JIT access.
• Tenant isolation.
• Dedicated service accounts.
• Separate execution services.

لا تستخدم Prompt كـAccess Control

Prompt يمكن أن يقول:

"لا تقرأ إلا ملف العميل الحالي."

لكن إذا كانت Tool تسمح بقراءة كل الملفات، فالوصول الفعلي لم يتقلص.

Prompt هو Instruction.

Access Control يجب أن يفرضه النظام التقني.

Policy Enforcement خارج النموذج

كلما أمكن، ضع حدود الوصول في طبقات خارجية مثل:

• IAM.
• API Gateway.
• Database policy.
• MCP gateway.
• Network control.
• Tool broker.
• Workflow policy.

هذا يقلل الاعتماد على امتثال النموذج للتعليمات.

Effective Access وPolicy Enforcement Point

يمكن وضع Policy Enforcement Points عند نقاط مثل:

Agent → Tool Gateway

Agent → MCP Gateway

Agent → API Gateway

Agent → Database Proxy

Agent → Execution Service

هذه الطبقات تستطيع فرض الوصول قبل تنفيذ الطلب.

مراقبة Exercised Access

بعد التشغيل، راقب ما يستخدمه Agent فعليًا.

اجمع:

• Tool calls.
• API calls.
• Database queries.
• File reads.
• File writes.
• Network destinations.
• MCP invocations.
• Agent-to-agent calls.
• Credential use.
• Privileged actions.

هذا يعطي Exercised Access.

مقارنة Exercised Access مع Effective Access

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

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

Observed usage لا يحدد وحده ما يجب حذفه، لكنه يقدم Evidence للمراجعة.

قراءة سيادة: Dormant Access

Dormant Access هو وصول متاح تقنيًا لكنه لا يظهر له استخدام فعلي خلال فترة مناسبة.

وجوده لا يعني بالضرورة أنه غير مشروع.

لكنه يستحق السؤال:

لماذا ما زال موجودًا؟

Access Drift

Effective Access قد يتوسع دون قرار صريح واحد.

قد يحدث ذلك نتيجة:

• IAM change.
• Group membership.
• New tool.
• New MCP Server.
• API scope expansion.
• Network rule change.
• Credential replacement.
• SaaS consent.
• Agent chaining.
• Workflow modification.

هذا هو Access Drift.

قراءة سيادة: Access Drift

Access Drift هو الاختلاف الذي ينشأ مع الزمن بين Access Baseline المعتمد والوصول الفعلي للنظام.

قد يكون التغيير صغيرًا في كل مرة.

لكن تراكمه قد ينتج Effective Access أوسع بكثير من التصميم الأصلي.

Change Triggers

يجب إعادة تقييم Effective Access عند:

• تغيير Agent Identity.
• تعديل IAM Role.
• إضافة Group Membership.
• إضافة API.
• توسيع API Scope.
• إضافة Tool.
• إضافة MCP Server.
• تغيير MCP Tool Exposure.
• إضافة Data Source.
• تغيير RAG corpus.
• تغيير Memory architecture.
• إضافة Network Destination.
• تفعيل Internet Egress.
• إضافة Delegation.
• إضافة Agent-to-Agent communication.
• تغيير Orchestrator.
• تغيير Credential.
• نقل النظام إلى Environment جديدة.

الوصول يجب أن يعاد تقييمه بعد Model Change أحيانًا

تغيير Model وحده لا يغير IAM بالضرورة.

لكن قد يغير:

• Tool-use behavior.
• Planning capability.
• Autonomous execution.
• Ability to chain actions.

لذلك إذا أصبح Model قادرًا على استغلال وصول كان سابقًا غير مستخدم، فقد تتغير المخاطر حتى لو بقيت Permissions نفسها.

قراءة سيادة: Capability-Access Interaction

الخطر لا يعتمد على Access وحده.

بل على التفاعل بين:

Capability و Access

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

Effective Access والمراقبة المستمرة

لا يكفي تقييم الوصول عند الإطلاق.

يجب أن تكون هناك آلية دورية أو مستمرة لـ:

• Discover.
• Compare.
• Detect Drift.
• Review.
• Reduce.
• Revalidate.

خصوصًا في الأنظمة الوكيلية التي تتغير Integrations الخاصة بها بسرعة.

أدلة التدقيق المطلوبة

يمكن للمؤسسة الاحتفاظ بأدلة مثل:

• IAM exports.
• Role assignments.
• Group memberships.
• API scope definitions.
• OAuth grants.
• Database grants.
• Network policies.
• MCP manifests/configurations.
• Tool allowlists.
• Secret ownership records.
• Access logs.
• Agent invocation logs.
• Architecture diagrams.
• AI-BOM.
• Approval records.
• Revalidation records.

أسئلة تدقيق Effective Access

يمكن للمدقق أن يسأل:

1. ما Intended Access لهذا Agent؟
2. ما Identity التي يستخدمها؟
3. ما Roles المرتبطة بها؟
4. هل توجد Permissions موروثة؟
5. ما APIs التي يستطيع استدعاءها؟
6. ما Tools المتاحة؟
7. ما MCP Servers المتصلة؟
8. ما Tools التي يعرضها كل MCP Server؟
9. ما Data Stores القابلة للوصول؟
10. ما Network Destinations الممكنة؟
11. هل يوجد Internet Egress؟
12. هل توجد Shared Credentials؟
13. هل يوجد Delegated Access؟
14. هل يستطيع استدعاء Agents أخرى؟
15. هل توجد Transitive Access Paths؟
16. ما Maximum Effective Access؟
17. ما Access Gap؟
18. هل توجد Dormant Access؟
19. هل تغير الوصول منذ آخر اعتماد؟
20. هل يمكن إلغاء الوصول بسرعة؟

اختبار الوصول الفعلي

لا تعتمد فقط على سؤال مالك النظام.

يمكن اختبار:

• هل يمكن Agent قراءة Record خارج Use Case؟
• هل API تسمح بـWrite؟
• هل Tool تستطيع الوصول إلى Resource غير معلن؟
• هل MCP يعرض Tool إضافية؟
• هل Credential تعمل على Environment أخرى؟
• هل Network يسمح بـDestination غير معتمد؟
• هل Agent يستطيع استدعاء Agent أعلى صلاحية؟

يجب تنفيذ الاختبارات ضمن بيئة آمنة ومصرح بها.

Access Graph كدليل تدقيق

من المفيد الاحتفاظ بخريطة مثل:

Agent → Identity → Role → Tool → API → Resource

وإظهار:

• Direct paths.
• Indirect paths.
• Delegated paths.
• Transitive paths.

هذه الخريطة تسهل اكتشاف نقاط التوسع.

Effective Access أثناء الحوادث

عند وقوع Incident، من أول الأسئلة:

ما الذي كان يستطيع Agent الوصول إليه فعلًا وقت الحادث؟

وليس فقط:

ما الذي استخدمه؟

يجب تحديد:

• Identities active.
• Credentials active.
• Tools exposed.
• MCP connections.
• Network routes.
• Data sources.
• Delegations.
• Agent chains.

هذا يساعد على تحديد نطاق التعرض المحتمل.

Effective Access وBlast Radius

كلما اتسع Effective Access، اتسع Blast Radius المحتمل.

لذلك تقليص Effective Access ليس مجرد تحسين IAM.

هو طريقة لتقليل أثر:

• Model error.
• Prompt Injection.
• Credential compromise.
• Tool compromise.
• Malicious input.
• Workflow failure.

دورة حياة Effective Access

يمكن دمج المراجعة في دورة الحياة:

Design → تعريف Intended Access

Build → إعداد Configured Access

Test → اكتشاف Effective Access

Deploy → اعتماد Baseline

Operate → مراقبة Exercised Access

Change → Revalidation

Incident → تحديد Maximum Effective Access

Retire → Revoke identities and credentials

عند إيقاف Agent

Retirement ليس حذف التطبيق فقط.

يجب:

• Revoke credentials.
• Disable identities.
• Remove roles.
• Remove OAuth grants.
• Disconnect MCP.
• Disable tools.
• Remove network policies.
• Revoke delegated access.
• Update AI-BOM.

وإلا قد يبقى Access بعد انتهاء النظام.

أخطاء شائعة

من الأخطاء الشائعة:

• مساواة Intended Access بـEffective Access.
• مراجعة Prompt بدل IAM.
• مراجعة Role مباشرة وتجاهل Inherited Permissions.
• تجاهل Tool-mediated Access.
• تجاهل MCP Tool Exposure.
• تجاهل Network Reachability.
• تجاهل OAuth scopes.
• تجاهل Shared Credentials.
• تجاهل Delegated Access.
• تجاهل Chained Agents.
• تجاهل RAG وMemory.
• الاعتماد على Inventory دون Access Paths.
• الاعتماد على Logs فقط لمعرفة ما يستطيع النظام فعله.
• اعتبار عدم الاستخدام دليلًا على عدم وجود صلاحية.
• عدم بناء Baseline.
• عدم اكتشاف Access Drift.
• عدم إعادة التقييم بعد التغييرات.
• عدم فصل Access عن Authority.
• استخدام Prompt كبديل لـAccess Control.
• عدم إلغاء الصلاحيات عند Retirement.

قائمة تحقق سريعة

قبل اعتماد Agent، تحقق:

• هل Intended Access موثق؟
• هل Agent Identity معروفة ومستقلة؟
• هل IAM Scope محدود؟
• هل API Scopes معروفة؟
• هل Database Scope محدود؟
• هل File Access معروف؟
• هل Tools محصورة؟
• هل MCP Exposure معروف؟
• هل Network Paths مقيدة؟
• هل Credentials محدودة وقابلة للإلغاء؟
• هل Delegated Access موثق؟
• هل Transitive Access معروف؟
• هل Agent Chains مرسومة؟
• هل Maximum Effective Access معروف؟
• هل Access Gap مقبول؟
• هل Access Baseline محفوظ؟
• هل Exercised Access مراقب؟
• هل Access Drift قابل للاكتشاف؟
• هل Change Triggers معرفة؟
• هل Retirement يتضمن Revocation؟

الخلاصة

الوصول الفعلي لا يُقاس بما كتب في Prompt، ولا بما يتوقعه مالك النظام، ولا حتى بما استخدمه Agent حتى الآن.

يُقاس بما تسمح به البيئة التقنية فعلًا.

في الأنظمة الوكيلية، قد يتشكل Effective Access من عدة طبقات في الوقت نفسه:

• Identity.
• IAM.
• Credentials.
• APIs.
• Databases.
• Files.
• Tools.
• MCP.
• Network.
• Delegation.
• Other Agents.
• Orchestration.

ولهذا يجب على المؤسسة أن تنتقل من سؤال:

ما الذي يفترض أن يصل إليه Agent؟

إلى:

ما الذي يستطيع الوصول إليه فعليًا، مباشرة أو بصورة غير مباشرة، الآن؟

ثم تقارن ذلك بالهدف المعتمد وسلطة الوكيل ومبدأ Least Agency.

المرجع

يستند هذا المقال إلى المبادئ الأمنية الواردة في:

PCI Security Standards Council Security Considerations for AI Systems — Information Supplement Version 1.0 — September 2026.

تؤكد المادة الأصلية أهمية تقليل وصول أنظمة الذكاء الاصطناعي وصلاحياتها وأدواتها، وحماية البيانات الحساسة، ومراقبة الأنظمة وإعادة التحقق منها مع تغير البيئة. :contentReference[oaicite:0]{index=0}

أما النموذج الرباعي:

Intended Access Configured Access Effective Access Exercised Access

ومفاهيم:

Access Gap Access Path Tool-mediated Access Transitive Access Access-Authority Misalignment Time-aware Effective Access Aggregate Agent Access Unknown Access Access Baseline Maximum Effective Access Dormant Access Access Drift Capability-Access Interaction

فهي صياغات تشغيلية تستخدمها سيادة AI في هذا المقال لتنظيم تحليل الوصول الفعلي، وليست مصطلحات رسمية منسوبة إلى PCI SSC.