مرز مشتری: جداسازی داده در سامانه‌های هوش مصنوعی مشترک

عامل پشتیبانی از یک مدیر احرازشده درخواست معتبری می‌گیرد: «فاکتورهای پرداخت‌نشده تیرماه حساب ما را نشان بده.» بازیابی شش سند مرتبط پیدا می‌کند. پنج سند متعلق به شرکت همان مدیر است؛ سند ششم به مشتری دیگری تعلق دارد که نام پروژه، واژگان فاکتور و بردار معنایی‌اش به‌طور اتفاقی مشابه است. مدل هر شش سند را روشن ارجاع می‌دهد و پاسخی آراسته می‌نویسد.

برای چنین رخدادی نیازی به jailbreak نیست. کاربر وارد سامانه شده، عامل مجوز جست‌وجوی فاکتور دارد، جست‌وجوی برداری درست کار کرده و پاسخ نیز به منبع متکی است. شکست در معماری رخ داده است: هویت مشتری مانند زمینه‌ای در prompt و یک فیلتر جست‌وجو رفتار کرده، نه مانند مرز غیرقابل‌دورزدن جریان اطلاعات.

پس تصمیم خواننده مشخص است: کدام اجزا را می‌توان میان مشتریان مشترک کرد، کدام اجزا به محیط اختصاصی نیاز دارند و هویت مشتری در کدام نقاط باید دوباره اعمال شود تا مدل هرگز جداسازی را فدای شباهت یا سهولت نکند؟ پاسخ به پیامد و تهدید بستگی دارد، اما یک قاعده همیشگی است: هر خواندن، نوشتن، استفاده مجدد، اقدام و مسیر شواهد باید ثابت کند موضوع، مبدأ و مقصد در همان مرز مجاز مشتری قرار دارند.

جداسازی مشتری همان ورود به حساب نیست

احراز هویت می‌گوید چه کسی اعتبارنامه را ارائه کرده است. مجوزدهی می‌گوید آن هویت اجازه دارد چه عملی را روی کدام منبع انجام دهد. جداسازی مشتری یک ناوردای دیگر اضافه می‌کند: منابع وابسته به یک شرکت، واحد کسب‌وکار، شخصیت حقوقی یا دامنه امنیتی نباید به دامنه دیگری جریان یابند؛ حتی اگر زیرساخت مشترک باشد و هر دو کاربر به‌خودی‌خود مشروع باشند.

اصول معماری SaaS آمازون این تفاوت را صریح می‌کند: کاربر ممکن است احرازشده و برای یک عمل مجاز باشد، اما بدون محدودیت مستقل بر پایه زمینه مشتری همچنان به منبع مشتری دیگر برسد. راهنمای اختصاصی آمازون برای هوش مصنوعی عاملی که در ژوئیه ۲۰۲۵ منتشر شد، همین اصل را به دانش عامل، حافظه، سرور MCP، ابزار، اعتبارنامه و ظرفیت مشترک مدل تعمیم می‌دهد.

این بحث ادامه الگوی گذرنامه عامل است. هویت محدود به وظیفه نشان می‌دهد کدام عامل و با تفویض چه کسی عمل می‌کند؛ مرز مشتری مشخص می‌کند آن هویت اصولاً کدام جمعیت از منابع را می‌تواند ببیند یا تغییر دهد. هیچ‌یک جای دیگری را نمی‌گیرد.

پیش از انتخاب زیرساخت، مشتری را تعریف کنید

«مشتری» برچسب امنیتی متعلق به برنامه است؛ مترادف کاربر، پایگاه داده، namespace یا سطح اشتراک نیست. می‌تواند شرکت، بیمارستان، صندوق تحت نظارت، شرکت تابعه یا واحد داخلی باشد. یک فرد نیز ممکن است در چند مشتری نقش متفاوت داشته باشد؛ پس عضویت باید نسخه‌دار باشد.

دفتر ثبت با شناسه پایدار و غیرقابل‌حدس بسازید و پیش از بازیابی یا inference پاکت تغییرناپذیر مشتری را حل کنید:

پاکت را در برابر تغییر محافظت و از وضعیت هویت مطمئن مشتق کنید؛ نه از بدنه درخواست، slug، خروجی مدل، metadata مشتری یا آرگومان MCP. سرویس پایین‌دست فقط می‌تواند دامنه را محدودتر کند.

کنترل‌های تثبیت‌شده را از طراحی ویژه هوش مصنوعی جدا کنید

چند منبع اصلی ویژگی‌های مهمی تعریف می‌کنند، اما هیچ‌کدام به‌تنهایی برنامه هوش مصنوعی مشترک را به سامانه‌ای جداشده تبدیل نمی‌کند.

فهرست کنترل‌های NIST SP 800-53 Rev. 5 اجرای جریان اطلاعات را با ویژگی مبدأ، مقصد و شیء و جداسازی منطقی یا فیزیکی تعریف می‌کند؛ اما دستور پیاده‌سازی RAG نیست.

راهنمای چندمشتری Kubernetes namespace، کنترل‌پلین مجازی، کلاستر اختصاصی، جداسازی node، شبکه، سهمیه و sandbox را پوشش می‌دهد. namespace بدون RBAC، شبکه، storage و کنترل workload مرز سخت نیست.

امنیت سطح سطر PostgreSQL 18 می‌تواند دسترسی را پیش‌فرض رد کند. بااین‌حال superuser، BYPASSRLS و معمولاً مالک جدول سیاست را دور می‌زنند؛ عملیات کل جدول بیرون RLS است و زیرپرس‌وجوی سیاست می‌تواند نشت race بسازد.

این موارد ویژگی‌های تأییدشده منابع‌اند. قرارداد لایه‌ای ادامه مقاله تحلیل ژرف است: روشی برای ترکیب آن‌ها با بازیابی، حافظه، کش، ابزار، فراخوانی مدل، لاگ و ارزیابی تا ناوردای مشتری در سراسر مسیر تصمیم باقی بماند.

برای هر لایه میان pool، bridge و silo انتخاب کنید

کل محصول را «چندمشتری» ننامید و یک تصمیم معماری واحد نگیرید. هر لایه سطح حمله، منحنی هزینه، بار عملیاتی و پیامد شکست مرزی خاص خود را دارد.

معماری مرجع هوش مصنوعی عاملی چندمشتری Google Cloud که آخرین بار ۱۸ ژوئن ۲۰۲۶ بازبینی شده، از hub-and-spoke با حاکمیت مرکزی و پروژه، datastore، runtime عامل، مرز سیاست و در صورت نیاز سرور MCP اختصاصی هر مشتری استفاده می‌کند. این یک الگوی قدرتمند bridge به silo است، نه دلیل اینکه هر workload الزاماً پروژه جداگانه می‌خواهد.

برای هر لایه حساسیت داده، اختیار برگشت‌ناپذیر، ورودی نامطمئن، محل نگهداری، کنترل مشتری، شعاع رخداد، نیاز restore و حذف و توان آزمون سیاست pool را بسنجید. سطح قیمت به‌تنهایی دلیل امنیتی نیست.

دامنه مشتری را پیش از شباهت معنایی اعمال کنید

جداسازی باید پایین‌تر از مدل و پیش از ranking رخ دهد. بازیابی گسترده و درخواست از مدل برای نادیده‌گرفتن اسناد مشتریان دیگر ممنوع است. پیام پنهان «فقط درباره حساب فعلی حرف بزن» نیز کنترل دسترسی نیست. OWASP LLM02:2025 درباره افشای اطلاعات حساس می‌گوید محدودیت prompt ممکن است دور زده شود و کنترل دسترسی سخت و محدودکردن منابع داده را توصیه می‌کند.

در پایگاه pool، زمینه مشتری را مطمئن به نشست متصل کنید؛ برای هر جدول سیاست سطر بخواهید؛ نقش برنامه را غیرمالک و بدون bypass بسازید؛ و USING و WITH CHECK را بیازمایید. در object storage، prefix را سمت سرور مشتق و credential بدون دسترسی namespace والد صادر کنید. در جست‌وجوی برداری، index مشتری یا predicate پیش از بازگشت candidate لازم است.

metadata filter فقط وقتی کنترل امنیتی است که موتور آن را سمت سرور اجرا کند و caller نتواند حذفش کند؛ وگرنه collection، account، project یا service را جدا کنید. راهنمای حافظه سازمانی scope پیش از ranking را لازم می‌داند؛ اینجا همان ترتیب شرط انتشار است.

پس از بازیابی، پیش از ساخت prompt ویژگی مشتری و مرجع هر شیء بازگشتی را دوباره بررسی کنید. این کنترل دوم دفاع چندلایه است، نه مجوز تضعیف کنترل اول. ناهماهنگی باید به توقف امن و علامت امنیتی منجر شود و محتوای بیگانه را از prompt، trace، صف repair و درخواست ارسالی به ارائه‌دهنده مدل بیرون نگه دارد.

اجازه ندهید state مشترک در پشتی شود

پایگاه داده آشکار معمولاً تنها مسیر بین مشتریان نیست. همه stateهایی را که می‌توانند بر نتیجه اثر بگذارند یا آن را نگه دارند فهرست کنید:

• تاریخچه گفت‌وگو، summary، scratchpad و حافظه ماندگار؛
• کش پاسخ دقیق و معنایی، کلید کش ارائه‌دهنده و embedding cache؛
• index بازیابی، chunk سند، ویژگی reranker و فایل موقت؛
• نتیجه ابزار، checkpoint workflow، payload تلاش دوباره و dead-letter queue؛
• لاگ، trace، screenshot، صف بازبینی انسانی و export پشتیبانی؛
• مجموعه بازخورد، corpus ارزیابی، candidate تنظیم مدل و fixture بازپخش.

هر کلید در جایی که اشتراک مجاز است باید هویت مطمئن مشتری و نسخه سیاست، purpose، release و شواهد مؤثر بر هم‌ارزی را داشته باشد. راهنمای کش معنایی توضیح می‌دهد که شباهت، تصمیم امنی برای استفاده مجدد نیست؛ cache hit میان مشتریان حتی با پرسش و منبع عمومی یکسان ممنوع است، مگر آن شیء هنگام ایجاد صریحاً عمومی طبقه‌بندی و در namespace عمومی جدا ذخیره شده باشد.

حذف نام مشتری از trace مخلوط پاک‌سازی نیست؛ snippet، شناسه، عبارت نادر، آرگومان ابزار، زمان و embedding ممکن است حساس بمانند. محتوا را پیش از observability مشترک کمینه کنید و مرجع تفکیک‌شده، تصمیم سیاست، شمارش، hash و کد نتیجه را نگه دارید؛ دسترسی payload خام باید محدود و قابل ممیزی باشد.

آموزش و ارزیابی نیز مقصدند. ticket مشتری A نباید بی‌صدا مثال یا داده تنظیم مدل برای مشتری B شود. یادگیری مشترک تصمیم صریح درباره حق استفاده، حریم خصوصی، purpose و کیفیت می‌خواهد.

خود ابزار باید مرز را اجرا کند

عامل ممکن است زمینه مشتری درست داشته باشد اما ابزاری را فراخوانی کند که customer_id دلخواه می‌پذیرد. این طراحی confused deputy است: مدل می‌تواند هدفی متفاوت با هدف مجاز اعتبارنامه پیشنهاد کند.

در هر gateway ابزار یا سرور MCP، دامنه مشتری را از workload احرازشده و پاکت امضاشده وظیفه به دست آورید. شناسه مشتری پیشنهادی مدل را نادیده بگیرید، رد کنید یا فقط با مقدار معتبر مقایسه کنید؛ هرگز آن را منبع اختیار ندانید. اعتبار عامل را با اعتبارنامه پایین‌دست کوتاه‌عمر و محدود به مشتری، ابزار دقیق، رده عملیات، خانواده منبع، purpose و expiry مبادله کنید. resource server نیز باید همان مرز را در آخرین محل خواندن یا اثر اجرا کند.

این طراحی مکمل راهنمای مجوز ابزار است: least privilege تعیین می‌کند عامل چه می‌تواند بکند و جداسازی مشتری تعیین می‌کند به منبع چه کسی می‌تواند دست بزند. در سرور MCP مشترک، connection، credential cache، mount فایل، متغیر محیط، artifact موقت و پیام خطا را جدا کنید. اگر سرور چنین تضمینی نمی‌دهد، آن را برای هر مشتری جدا مستقر کنید.

مدیریت میان مشتریان capability جدا می‌خواهد، نه wildcard: purpose پشتیبانی، پرونده، منابع محدود، زمان کوتاه، تأیید دسترسی حساس و audit trail مستقل.

مثال عملی: دستیار مشترک فاکتور

یک دستیار SaaS برای ۸۰۰ شرکت را در نظر بگیرید. بیشتر مشتریان compute و PostgreSQL مشترک دارند؛ مشتریان تحت نظارت storage، جست‌وجو، کلید و worker اختصاصی پشت همان حاکمیت مرکزی می‌گیرند.

مدیر زیر T-731 وارد می‌شود. gateway نسخه ۴۴ عضویت را حل و وظیفه Q-9921 را برای ۹۰ ثانیه جست‌وجوی فقط‌خواندنی امضا می‌کند. orchestrator نمی‌تواند پاکت را تغییر دهد. PostgreSQL نقش غیرمالک با forced row security دارد و جست‌وجوی برداری به‌جای filter آزاد، handle سمت سرور می‌گیرد.

بازیابی پنج chunk می‌دهد. guard پیش از prompt، مشتری، رده داده و نسخه سیاست را بررسی می‌کند. guard خروجی نیز هر فاکتور و نشانی ارجاع‌شده را زیر همان پاکت می‌سنجد. هیچ ابزاری مجوز export یا پرداخت ندارد.

حالا فرض کنید migration index به‌اشتباه یک chunk متعلق به T-552 را در collection مشتری T-731 می‌نویسد. guard پیش از prompt ناهماهنگی را می‌بیند، بدون پاسخ متوقف می‌شود، فقط شناسه و hash را بدون متن بیگانه ثبت می‌کند، collection را غیرفعال و incident امنیتی باز می‌کند. از مدل نمی‌خواهد پاراگراف را حذف کند. مالک index داده را از manifestهای مشتری بازسازی می‌کند، کل جمعیت را می‌آزماید و مشخص می‌کند کدام درخواست‌ها امکان برخورد با collection آلوده داشته‌اند.

ویژگی مهم مصونیت کامل اجزا از خطا نیست؛ مهم این است که خرابی یک partition خودکار به افشای قابل‌مشاهده برای مشتری تبدیل نشود.

جداسازی را مانند ناوردای خصمانه بیازمایید

unit test با دو شناسه تمیز کافی نیست. ماتریسی تولیدشده از کاربر، نقش، مشتری، وضعیت، منبع، رابط و زمان بسازید. این موارد را پوشش دهید:

1. کاربر معتبر با object ID بیگانه، slug حدس‌زده، URL کپی‌شده یا deep link کهنه؛
2. کاربر عضو دو مشتری که وسط وظیفه بلندمدت context را عوض می‌کند؛
3. حذف عضویت در حالی که حافظه، کش، retry یا tool call هنوز در حال اجراست؛
4. سند با metadata جعلی یا prompt injection برای namespace دیگر؛
5. collision کلید کش، tenant خالی، namespace پیش‌فرض و تفاوت حروف یا encoding؛
6. ورودی آلوده index، batch مخلوط، restore پشتیبان، reindex، export و job حذف؛
7. مسیر پشتیبانی privileged، migration، analytics و break-glass؛
8. retry پس از expiry اعتبارنامه و worker دیررس با نسخه عضویت قدیمی؛
9. لاگ، صف review، dataset ارزیابی و بسته incident در دست تیم نادرست؛
10. بار noisy neighbour برای فعال‌کردن fallbackای که اشتباهاً جداسازی را حذف می‌کند.

آزمون را از API عمومی تا effect target واقعی اجرا کنید. برای هر مشتری canary مصنوعی بسازید و candidate، prompt، output، cache hit، درخواست ابزار، پیوست لاگ یا ورود ارزیابی بیگانه را alert کنید.

با شواهد مرزی کار کنید، نه با اطمینان لفظی

هم تلاش ردشده و هم اثبات موفق مرز را پایش کنید:

برای اثبات guard، payload بیگانه را لاگ نکنید. شناسه محافظت‌شده مشتری، component، object handle، نسخه سیاست، تصمیم و trace کافی است. monitoring مرکزی نباید دریاچه داده‌ای با کنترل ضعیف‌تر از تولید شود.

در احتمال افشا، cache و index را freeze، credential را revoke، شواهد را حفظ و جمعیت در معرض را مشخص کنید و تکلیف اطلاع‌رسانی را اجرا کنید. راهنمای شواهد ممیزی یادآور می‌شود ادعا وجود سیاست نیست؛ ادعا اجرای آن در همه مسیرهای اثرگذار است.

دروازه انتشار جداسازی مشتری

پیش از ورود workflow هوش مصنوعی مشترک به تولید بررسی کنید:

• واحد مشتری، چرخه عمر عضویت، نقش میان‌مشتری و رده داده عمومی یا خنثی صریح تعریف شده است؛
• context مشتری از وضعیت هویت مطمئن می‌آید و برای عمر وظیفه در برابر تغییر محافظت می‌شود؛
• انتخاب pool، bridge و silo برای هر لایه همراه با دلیل پیامد و تهدید ثبت شده است؛
• همه مسیرهای database، object store، index، memory، cache، queue، tool، log و evaluation طبقه‌بندی شده‌اند؛
• مجوز پیش از بازیابی و دوباره پیش از ساخت prompt یا اقدام اجرا می‌شود؛
• مدل نمی‌تواند دامنه مشتری را انتخاب، گسترش یا override کند؛
• credential کوتاه‌عمر، audience-bound و tenant-scoped است و در منبع نهایی بررسی می‌شود؛
• آزمون خصمانه تغییر عضویت، کار دیررس، metadata آلوده، restore، export و fallback را پوشش می‌دهد؛
• runbook رخداد می‌تواند یک مشتری یا یک لایه مشترک را بدون حذف شواهد یا افشای مشتری دیگر غیرفعال کند.

چه زمانی قرارداد را دوباره بررسی کنیم

برای هر رده مشتری، region، ارائه‌دهنده مدل، cache، حافظه، MCP، dataset، نقش support، export، migration یا تحلیل میان مشتریان مرز را بازبینی کنید؛ همچنین پس از افشا، bypass، خطای restore یا افزایش اختیار ابزار.

هدف اختصاصی‌کردن همه سرورها نیست؛ اشتراک‌گذاری باید عمدی و قابل‌اثبات باشد. مدل و عملیات می‌توانند مشترک بمانند، اگر هویت مشتری بیرون prompt و همراه وظیفه باشد و در هر خواندن، حافظه، استفاده مجدد، اقدام و یادگیری اجرا شود.

یادداشت منابع — بازبینی‌شده در ۱۶ اوت ۲۰۲۶

• AWS Prescriptive Guidance: اجرای جداسازی مشتری برای هوش مصنوعی عاملی — راهنمای ژوئیه ۲۰۲۵؛ اعمال زمینه مشتری در دانش، حافظه، ابزار، MCP، اعتبارنامه و ظرفیت مشترک بررسی شد.
• AWS SaaS Architecture Fundamentals: جداسازی مشتری — تفاوت احراز هویت، مجوزدهی و جداسازی منبع بر پایه مشتری بررسی شد.
• Google Cloud: سامانه هوش مصنوعی عاملی چندمشتری — آخرین بازبینی ۱۸ ژوئن ۲۰۲۶؛ معماری hub-and-spoke، پروژه، datastore، runtime، مرز سیاست و گزینه‌های MCP هر مشتری بررسی شد.
• Kubernetes: چندمشتری — آخرین تغییر ۲۲ مه ۲۰۲۵؛ طیف جداسازی و محدودیت namespace بدون کنترل‌پلین و data plane پشتیبان بررسی شد.
• PostgreSQL 18: سیاست امنیت سطح سطر — رفتار default-deny، استثنای مالک و bypass، سیاست restrictive و هشدار race و covert channel بررسی شد.
• NIST SP 800-53 Rev. 5 — انتشار سپتامبر ۲۰۲۰ با نسخه‌های اصلاحی بعدی؛ AC-4 و مفاهیم اجرای جریان اطلاعات و جداسازی منطقی یا فیزیکی بررسی شد.
• OWASP LLM02:2025 افشای اطلاعات حساس — خطر افشا، محدودیت کنترل prompt، کنترل دسترسی سخت و محدودکردن منبع داده بررسی شد.