Anthropic User Profiles: اعزل إجراءات السلامة لكل عميل

تمنح ميزة User Profiles الجديدة من Anthropic المنصات وبوابات AI وموزعي Claude هوية لدى المزود لكل عميل نهائي. عندما يُرفق Profile ID بطلبات Messages أوMessage Batches أوحساب التوكنز، تقول Anthropic إن إجراء السلامة يمكن أن يطبق على العميل الممثل بدل المنظمة كلها. ثم تستطيع Organization Webhooks إخطار Control Plane عند تقييد Profile أوحظره وعند انتهاء الإجراء. ومع ذلك يحتاج التصميم الإنتاجي إلى ربط داخلي ثابت، وأقل قدر من البيانات الشخصية، ومعالجة Webhook موقعة وIdempotent، ووظيفة مطابقة دورية، وصلاحيات يملكها التطبيق.

أعلنت Anthropic الميزتين في 20 أكتوبر 2026. تظهر User Profiles في مرجع API التجريبي تحت /v1/user_profiles. أما Organization Webhooks فهي قدرة Beta منفصلة تستخدم Header باسم webhooks-2026-10-07 وتحتاج إتاحة عبر فريق حساب Anthropic. أفصل أدناه بين السلوك الموثق وتوصيات بناء Control Plane متعددة المستأجرين.

ما الجديد ولماذا يهم منصات SaaS؟

حتى يعزل المزود إجراءً أمنيًا يحتاج Subject دائمًا يطبق عليه الإجراء. توثق Anthropic User Profile كسجل يمثل إما مستخدمًا نهائيًا فرديًا لمنتجك أوشركة تعيد بيع وصول Claude لها. ويمكن للطلب إرسال معرف uprof_ في Header باسم anthropic-user-profile-id.

هذا الفرق تشغيليًا مهم للمنتجات متعددة المستأجرين. عندما يستخدم كل العملاء Credential صاعدة واحدة بلا هوية فرعية، يرى المزود Traffic المنظمة دون حدود منتجك. تضيف User Profiles حد Attribution لدى المزود، لكنها لا تستبدل Tenant ID أوAuthentication أوحساب الفوترة أوضوابط إساءة الاستخدام أوAudit Log لديك؛ بل تكملها بكيان يعرفه المزود.

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

اختر حدود Profile بوضوح

استخدم access_type بقيمة application عندما يمثل Profile مستخدمًا فرديًا لمنتجك. واستخدم passthrough عندما يمثل شركة تعيد بيع وصول Claude لها. لا تنشئ Profile لكل Browser Session أوAPI Key أومحادثة؛ هذه المعرفات تتغير سريعًا وتشتت تاريخ الإجراءات. ولا تشارك Profile واحدة بين Tenants غير مرتبطين لمجرد أنهم يستخدمون نطاق بريد واحدًا.

جدول الربط العملي يكون محدودًا بالـTenant وثابتًا:

ai_subject(
  tenant_id,
  internal_subject_id,
  anthropic_profile_id,
  access_type,
  lifecycle_state,
  last_synced_at,
  UNIQUE(tenant_id, internal_subject_id),
  UNIQUE(anthropic_profile_id)
)

أنشئ Profile مرة واحدة عبر Provisioning Job دائمة، واحفظ المعرف المعاد، وأعد استخدامه في الطلبات. إذا انتهى طلب الإنشاء بTimeout بعد احتمال قبول المزود له، ابحث أوList قبل إعادة الإنشاء عشوائيًا. يذكر المرجع أن external_id القديم ليس Unique، لذلك لا يصلح كقيد قاعدة البيانات الذي يمنع التكرار.

اختر Subject في الطبقة نفسها التي تصرح الطلب. منتج محادثة للمستهلك يربط المستخدم المسجل غالبًا. Gateway للشركات بنمط passthrough تربط حساب العميل. وقد تحتاج أداة دعم لعدة متاجر إلى مستخدم داخلي وProfile شركة لدى Anthropic معًا؛ Profile الصاعدة لا تلغي التحقق محليًا من صلاحية الموظف على المتجر.

قلل البيانات ولا تدّع تحققًا غير موجود

تقبل API اسمًا اختياريًا وMetadata وتفاصيل عن المستخدم الخارجي. تقول Anthropic إن المنصة تزود هذه التفاصيل وإن Anthropic لا تتحقق منها. لذلك لا تصف Profile كهوية موثقة إلا إذا كان مسار الهوية لديك يثبت ذلك.

احفظ فقط ما يحتاجه العقد التشغيلي. فضّل Reference غامضًا مولدًا للتكامل بدل Primary Key خام يكشف بنية نظامك. لا تضع البريد أوالأسماء أوAccess Tokens أوملاحظات الحالات أومقتطفات Prompts في Metadata. توضح وثائق CMEK لدى Anthropic أن name وexternal_id وmetadata الخاصة بـUser Profile تخزن بتشفير تديره Anthropic لا بمفتاح العميل، وتحذر صراحة من وضع بيانات شخصية حساسة في Metadata.

إذا أرسلت Hash مثل email_hash فعرّف Canonicalization والمفتاح والدوران والغرض. Hash بلا Salt لبريد شائع قابل للتخمين. HMAC بمفتاح مستقل أفضل للمطابقة، لكنه قد يبقى بيانات شخصية وفق الحوكمة. سجل الغرض والاحتفاظ بدل افتراض أن Hash جعله مجهولًا.

افصل حالات دورة الحياة. قد يوقف تطبيقك مستخدمًا بسبب فوترة متأخرة بينما تقول Anthropic إن Profile unrestricted؛ هذان قراران مختلفان. مثّل حالة الحساب المحلية وقرار السلامة المحلي وحالة المزود في حقول منفصلة، ثم احسب Admission Decision محافظة من الثلاثة.

أرفق Profile قبل كل طلب مدعوم

لا يفيد الربط إذا لم يصل المعرف الصحيح إلى API. ضع Profile Resolution داخل Gateway أوSDK Wrapper المركزي لطلبات Messages وMessage Batches وToken Counting. ارفض الطلب عندما لا يتطابق Tenant الموثق مع Profile. ولا تقبل anthropic-user-profile-id مباشرة من Client غير موثوق.

مرر Request ID داخليًا وسجل Profile ID وTenant ID والمسار والموديل والنتيجة في Audit Event محدودة الوصول. لا تنسخ Prompts إلى Logs عامة. عقد Gateway توضيحي:

authorize(session, tenant, capability)
profile = resolve_profile(tenant.id, session.subject_id)
assert profile.lifecycle_state == "active"
assert current_upstream_status(profile.id) allows request

response = anthropic.messages.create(
  headers = {"anthropic-user-profile-id": profile.id},
  body = validated_request
)
record_request_outcome(request_id, tenant.id, profile.id, response.status)

اكتب Contract Tests تفشل إذا أغفل مسار مدعوم الـHeader أواستخدم Profile من Tenant آخر. اختبر Batch وToken Counting منفصلين؛ Gateway التي تضع الهوية على Messages التفاعلية فقط تترك فجوة Attribution.

عامل Webhooks كإشارة لقراءة الحالة الحالية

ترسل Organization Webhooks نوعين: user_profile.enforcement_action_opened وuser_profile.enforcement_action_resolved. يحتوي الحدث Profile ID وEnforcement Action ID لا تفاصيل الإجراء. تطلب Anthropic من المستهلك جلب Profile الحالية لأن الأحداث قد تصل متأخرة أوخارج الترتيب. تلخص enforcement_status الإجراءات المفتوحة إلى banned أوrestricted أوunrestricted، ويجب معاملة أي قيمة مجهولة كـrestricted.

تحقق من توقيع Standard Webhooks على Body الخام باستخدام Signing Secret. افحص حداثة Timestamp، واحفظ Event ID تحت Unique Constraint، وأعد 2xx خلال خمس ثوانٍ، ثم نفذ الجلب غير متزامن. تقول الوثائق إن الحدث قد يتكرر بالمعرف نفسه، وإن فشل التسليم يعاد مرات قليلة فقط، وإن Endpoint قد تعطل بعد تكرار الفشل.

لذلك لا يفعل Receiver الآمن الكثير داخل الطلب:

1. يقرأ Body الخام وSignature Headers؛ 2. يتحقق من التوقيع والوقت قبل الوثوق بالحقول؛ 3. يضيف Event ID بشكل Idempotent؛ 4. يرسل Profile Refresh Job؛ 5. يعيد 204؛ 6. يجلب Profile الحالية ويحدث Local Projection داخل Transaction.

لا ترفع الحظر لمجرد وصول resolved event. اجلب Profile أولًا؛ فقد يبقى إجراء آخر مفتوحًا أووصل حدث أحدث. كذلك يعني 404 أن Profile حُذفت ويحتاج سياسة محلية صريحة، وليس تحويلًا تلقائيًا إلى unrestricted.

طابق دوريًا لأن Webhook ليست Ledger

توثق Anthropic فجوات مهمة: الأحداث التي بدأت قبل التسجيل لا يعاد إرسالها، وقد تسقط الأحداث بعد عدد محدود من Retry، وتتجاوز Endpoints المعطلة الأحداث بلا Backfill، كما أن حذف Profile ينهي الإجراءات بلا resolved event. لذلك تنحرف State Machine التي تعتمد على Webhook وحدها.

شغل Reconciliation Job دورية تعرض Profiles المفلترة بحالتي restricted وbanned، وتتبع next_page حتى تصبح null. تحذر الوثائق من أن الصفحة قد تحتوي عناصر أقل من limit أوحتى تكون فارغة قبل نهاية القائمة. لا تتوقف لأن صفحة قصيرة أوفارغة. قارن المصدر الرسمي مع Local Projection، وأصلح الفروق، ونبه على Profiles المفقودة بلا تفسير.

راقب أيضًا حالة Endpoint وفشل التوقيع ونسبة التكرار وزمن Refresh وانحراف المطابقة وعمر آخر Full Scan ناجحة. احفظ Signing Secret في Secret Manager. وعند تدويرها انشر إعداد Receiver الجديد فورًا؛ تقول Anthropic إن السر القديم يتوقف مباشرة وإن Retry للأحداث القديمة توقع بالسر الجديد.

يشرح دليل Webhook الموثوقة نمط Inbox وRetry بتفصيل أوسع. أما دليل تدقيق Anthropic Compliance API فهو ضابط مختلف: بيانات Compliance للتدقيق والمراجعة، بينما User Profiles وEnforcement Webhooks لإسناد الطلب وحالة السماح الحالية.

عرّف سلوك التقييد قبل الحادث

لا تحول Restriction أوBan إلى رسالة UI مرتجلة. عرّف Policy Matrix لكل حالة ومسار. قد يمنع Ban كل طلب جديد لهذه Profile. أما Restriction فقد تسمح فقط بما يقبله المزود فعلًا؛ يجب على Gateway احترام استجابة Upstream لا تخمين معنى التقييد.

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

اختبر Control Plane بProfiles اصطناعية: opened مكرر، resolved يصل قبل opened، إجراءان متزامنان، فقد Event ثم المطابقة، Endpoint معطلة، تدوير سر أثناء Retry، حذف Profile، وانقطاع Upstream. الخاصية المطلوبة ليست ترتيبًا مثاليًا للأحداث؛ بل التقارب نحو الحالة الحالية للمزود دون اختراق حدود Tenant.

متى لا تستخدمها كنظام هوية؟

تفيد User Profiles عندما ترسل منصة Traffic إلى Claude لعدة عملاء نهائيين وتحتاج Attribution وعزل إجراءات لدى المزود. لا تضيف قيمة كبيرة لخدمة داخلية واحدة بلا حد عميل نهائي. وهي ليست بديلًا عن OIDC أوSession Management أوRBAC أوConsent أوالفوترة أودليل العملاء.

Organization Webhooks ما تزال Beta، وتحتاج Enablement، ولا تتاح تحت بعض الإعدادات الموثقة ومنها المنظمات الجاهزة لـHIPAA. إذا احتاج منتجك Safety State Feed ولا يستطيع استخدام Webhook، فابنِ استراتيجية Polling واستجابات أخطاء موثقة بدل ادعاء تغطية فورية.

عقد التنفيذ واضح: اختر Subject ثابتة، وأنشئ Provider Profile واحفظها، وأرفقها مركزيًا بكل طلب مدعوم، وقلل بيانات الهوية، وتحقق من أحداث Webhook وأزل تكرارها، واجلب الحالة الحالية بدل الثقة بترتيب الأحداث، وطابق قائمة التقييد كاملة وفق جدول. بهذه البنية تستخدم حد العزل الجديد لدى Anthropic من دون خلطه مع الهوية والصلاحيات التي يبقى منتجك مسؤولًا عنها.

إعداد: Noor Yasser