Anthropic Compliance API: راجع التعليمات الدائمة بلا Shadow Prompt Database

أصبحت Anthropic تتيح عبر Compliance API قراءة النص الدائم الذي يحفظه أعضاء Claude Enterprise في Instructions for Claude وفي Global instructions الخاصة بـCowork. أهمية الـEndpoint الجديدة أن هذه التعليمات على مستوى الحساب قد تغيّر الإجابات وسلوك الوكلاء بصمت عبر المؤسسات. تستطيع فرق الأمن والامتثال ومنصة الذكاء الاصطناعي الآن جرد هذا الإعداد، لكن يجب التعامل مع النص كبيانات مستخدم حساسة، لا كمستودع Prompts جاهز. التصميم الآمن يستخدم Collector محدود الصلاحية، ويشفّر أقل قدر لازم من الأدلة، ويفصل Findings عن النص الخام، ويسجل كل وصول.

أعلنت Anthropic الميزة في 15 أكتوبر 2026 ضمن Claude Platform release notes. يفرّق هذا المقال بين السلوك الموثق وتوصيات التصميم. الميزة Beta ومخصصة لمؤسسات Claude Enterprise المؤهلة؛ وليست قدرة نموذج ولا تكشف Prompts العادية المرسلة إلى Claude API.

ماذا تعيد الواجهة فعلًا؟

الطلب الموثق هو GET /v1/compliance/organizations/{org_uuid}/user_preferences. تشرح وثائق بيانات المؤسسة أن كل Row تعرف عضوًا حاليًا وقد تحتوي conversation_preferences لتعليمات Claude في claude.ai، وcowork_global_instructions لتعليمات Cowork. لأن الإعدادين على مستوى الحساب، قد يظهر النص نفسه تحت كل مؤسسة ينتمي إليها العضو.

يعيد الرد افتراضيًا الأعضاء الذين ضبطوا قيمة واحدة على الأقل. يضيف include_unset=true جميع الأعضاء الحاليين ويضع null للقيمة غير المضبوطة. يمكن تحديد عشرة User IDs كحد أقصى في الطلب. يستخدم Pagination حقلي limit وpage؛ القيمة الافتراضية 20 والحد الموثق 100. Page Token قيمة Opaque يجب إعادتها بلا تعديل ومع الفلاتر نفسها. الصفحة القصيرة أو الفارغة لا تثبت انتهاء القراءة؛ استمر حتى يصبح next_page مساويًا لـnull.

تحتاج الواجهة Scope باسم read:compliance_user_data، ويعيد المفتاح الذي يفتقدها 403. لا يعمل Claude API Key عادي مع Compliance API. تفصل وثائق الإعداد بين Compliance Access Key وAdmin API Key ومفتاح استدعاء النماذج.

نقاط القرار واضحة: الواجهة Beta، لذلك ضع Parser خلف Adapter بإصدار. والتفضيلات على مستوى الحساب، لذلك امنع التكرار بـUser ID ثابت وContent Hash. مفتاح النموذج العادي لا يعمل، لذلك افصل Credentials داخل Trust Boundary مستقلة. الصفحة الواحدة لا تثبت الاكتمال، لذلك تابع next_page حتى null. أما Prompts الخاصة بأحمال API فهي خارج هذه الواجهة، فلا تسم الجرد Audit كاملة لكل Prompts.

حدّد هدف التدقيق قبل جمع النص

هناك ثلاثة أهداف مختلفة على الأقل، وكل هدف يحتاج دليلًا مختلفًا.

الأول جرد الإعدادات: من يملك تعليمات دائمة، ومتى شاهدتها المؤسسة آخر مرة. قد يكفي User ID وPresence Flags وKeyed Content Hash ووقت الملاحظة.

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

الثالث Incident Response: قد يحتاج النص الدقيق وChain-of-custody وLegal Hold. هذه فئة Retention مختلفة بتفويض صريح. لا تجعل أوسع Dataset مطلوبة للحوادث هي الوضع الافتراضي للجرد الروتيني.

جمع كل شيء لأن الواجهة تسمح به ينشئ Shadow Prompt Repository أكبر أثرًا عند الاختراق من الإعداد الأصلي. Data Minimization جزء من المعمارية، لا Privacy Checkbox لاحقة.

اعزل الجمع داخل Trust Boundary ضيقة

تحذر وثائق إعداد Compliance API من أن read:compliance_user_data تستطيع قراءة المحادثات والملفات والمشاريع وSession Transcripts والمستخدمين والتفضيلات وGroup Membership ضمن نطاق المفتاح. وتوصي Anthropic بمعاملة المفتاح كـProduction Database Credential. لا تنتهي صلاحيته تلقائيًا، ويصبح حذفه نافذًا مع الطلب التالي.

لذلك شغّل Collector داخل Workload معزولة لا تملك خروجًا شبكيًا إلا إلى Compliance API وEvidence Store المعتمد. خزّن المفتاح في Secrets Manager، ولا تضعه في Source Control أو Analytics Config أو Logs. افصل الجمع عن المراجعة: Collector تقرأ وتطبّع؛ خدمة منفصلة تقيم Records منقحة؛ والمراجع المخول وحده يطلب النص الدقيق.

استخدم مفاتيح وScopes منفصلة للمستهلكين غير المرتبطين. SIEM Pipeline التي تحتاج Activity Feed فقط لا يجب أن ترث read:compliance_user_data. ولا تشارك Delete Workflow تحمل delete:compliance_user_data المفتاح نفسه مع Inventory Job للقراءة فقط.

يوضح دليل معمارية الوصول السيبراني لدى Anthropic المبدأ نفسه بصورة أوسع: القدرة الإضافية تحتاج Credentials أقصر وEgress أضيق وموافقات قابلة للمراقبة.

ابنِ Snapshot قابلة للتكرار عبر كل الصفحات

عامل كل تشغيل كـSnapshot واحدة، لا كسلسلة User Rows مستقلة. خزّن Run Record تتضمن Organization ID والفلاتر ووقت البداية والنهاية وعدد الصفحات والأعضاء وRequest IDs وإصدار Parser ودليل terminal next_page=null. لا تسجل Snapshot مكتملة قبل نجاح الصفحة الأخيرة.

page = null
repeat:
  response = list_user_preferences(org, page, stable_filters)
  for each row:
    normalized = canonicalize(row)
    hash = HMAC(audit_key, normalized preference text)
    upsert(run_id, user_id, presence flags, hash, policy findings)
  page = response.next_page
until page is null
mark run complete

استخدم User ID المستقر كهوية، لا البريد. يمكن أن يتغير البريد، كما يضيف Personal Data غير لازمة للأنظمة اللاحقة. اربط كل Record بـOrganization ID وRun ID لأن المحتوى نفسه على مستوى الحساب قد يظهر بصورة مشروعة في Snapshots لعدة مؤسسات.

يجب ألا تصنع Retries Findings مكررة. استخدم Unique Key مثل run_id + organization_id + user_id. عند فشل صفحة، أكمل من آخر Page Token محفوظ مع include_unset وuser_ids نفسها. لا تحلل Page Token ولا تزيدها ولا تنشئها بنفسك.

لاكتشاف التغيير، قارن HMAC بدل Plaintext عندما يحتاج المراجع فقط معرفة أن Preference تغيرت. عند تدوير HMAC Key نفذ Re-baseline منضبطًا بدل إظهار كل عضو كتغيير جديد بصمت.

افصل Detection عن Interpretation

التعليمات الدائمة نص حر. تستطيع Keyword Rules التقاط أنماط واضحة، لكنها لا تثبت النية أو الخطر وحدها. يمكن لنموذج Classifier المساعدة في الفرز، لكن إرسال النص إلى نموذج آخر ينشئ Data Transfer إضافية وPrompt-injection Surface جديدة.

ابدأ بقواعد Deterministic للشروط عالية الثقة: Secret Formats وExternal Destinations وطلب تجاوز Approvals وبيانات ممنوعة وتعليمات أدوات غير آمنة. شغّل أي تصنيف بالنموذج داخل Data Boundary معتمدة وبـOutput Schema مقيدة. اعتبر Preference Text بيانات غير موثوقة لا تعليمات للـClassifier. ولا تمنح Classifier أدوات أو وصولًا للشبكة.

أعد Finding مع Evidence Spans وRule Version وConfidence وReviewer Status. لا تسمح لنتيجة آلية بحذف محتوى أو تعليق مستخدم أو تعديل تعليماته مباشرة. الإجراء عالي الأثر يحتاج Approval منفصلة وAudit Trail.

حافظ على الخصوصية دون إتلاف قيمة التدقيق

قد يكتفي السجل الروتيني الآمن بالآتي:

- User ID مستقر وOrganization ID؛ - هل كل Preference Field مضبوطة؛ - Keyed Hash للنص بعد التطبيع؛ - Policy Finding Codes وMatched Spans بعد التنقيح؛ - observed_at وRun ID وإصدارات Parser وRules؛ - قرار المراجع وسببه.

خزّن Raw Text فقط عندما يتطلبه الهدف المعلن. شفّرها بمفتاح مستقل، وقيّد البحث، وعطّل Analytics Indexing، واستخدم Retention قصيرة، وسجل كل قراءة. لا تنسخ التعليمات الخام إلى Tickets أو SIEM Events لأن الوصول هناك أوسع عادة والتحكم في Retention أصعب.

توثق معمارية تكامل Compliance API أن الوصول إلى الواجهة نفسها يولد compliance_api_accessed activities. أدخل هذه السجلات كي ينسب المحقق القراءة إلى مفتاح محدد. وتوصي الوثائق باستخدام user_id لا البريد كمفتاح ربط أساسي، وحفظ Provenance Metadata وContent Hashes لسلسلة الحيازة.

افهم فجوات التغطية

هذه الواجهة ليست Universal Prompt Inventory. تعيد Preferences على مستوى حساب الأعضاء الحاليين. ولا تدعي كشف تعليمات المشاريع أوSystem Prompts للتطبيقات أوPrompts طلبات API أوTool Definitions أوكل إعداد محلي قد يؤثر في Agent.

تنص أسئلة Compliance API الشائعة على أن Claude Console وأحمال Claude API الموثقة بمفتاح API لا تعرض Prompt Text أوModel Responses عبر Compliance API. ولـSession Transcripts استثناءات موثقة تشمل بعض جلسات Claude Code عبر Clouds خارجية أومفتاح API، وجلسات Zero Data Retention، وThinking Blocks، وتعريفات الأدوات.

لذلك استخدم ثلاث حالات: observed وnot set وnot covered. لا تحول not covered إلى compliant أوempty. يجب أن تسمي Coverage Metadata سطح المنتج ومسار المصادقة والمؤسسة ووقت الملاحظة.

متى لا تستخدم الواجهة؟

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

ولا تستخدمها إذا كان المطلوب مجرد نشر إرشادات لتعليمات آمنة. قد يحل Template وتوعية المستخدم وProduct Policy المشكلة بلا جمع مركزي. ولا تعتبر الواجهة بديلًا عن Tool Authorization: حتى التعليمات التي راجعتها لا تمنح صلاحية إرسال بريد أوتعديل بنية تحتية أوكشف بيانات.

في الوكلاء التي يملكها التطبيق، احتفظ بالـPrompts وسياسات الأدوات فيVersioned Configuration تسيطر عليها. يشرح دليل Anthropic Models API Model Metadata، ويشرح دليل Claude Haiku 5.5 Versioned Request Bundles. Account Preferences سطح مختلف يملكه المستخدم.

قائمة جاهزية الإنتاج

تأكد أن المؤسسة مؤهلة وأن الواجهة ما تزال Beta. وثق هدف التدقيق والأساس النظامي. استخدم Compliance Access Key مستقلة بأضيق Scope. اعزل Collector وSecrets. اقرأ كل الصفحات حتى next_page=null. حافظ على الفلاتر نفسها عبر Retries. امنع التكرار حسب User ID وRun. خزّن Presence وKeyed Hashes افتراضيًا، ولا تحتفظ بـPlaintext إلا بمبرر. عامل النص كـUntrusted Input. افصل Findings عن Enforcement. سجّل Coverage Gaps. راقب compliance_api_accessed events. اختبر Key Rotation وفشل Pagination وPartial Snapshots وSchema Changes وحذف الأدلة المصدرة.

تجعل الواجهة الجديدة تعليمات Claude الدائمة قابلة للملاحظة لدى فرق المؤسسة. قيمتها ليست نسخ كل Prompt إلى Database أخرى؛ بل بناء Control ضيقة وقابلة للتفسير تثبت ما تمت ملاحظته، وتحدد الإعداد الخطر، وتحترم بيانات المستخدم، وتصرح بوضوح بما لا تستطيع الواجهة رؤيته.

إعداد: Noor Yasser