دسترسی عامل‌های هوش مصنوعی به ابزارها، نشت داده‌های خصوصی را تسهیل می‌کند

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

اگر یک عامل ابزاری ارزان‌قیمت پیدا کند، آن را می‌خرد، جست‌وجو را اجرا می‌کند و پاسخی مفید می‌گیرد. اما اگر این جست‌وجو شامل یادداشت‌های داخلی شما درباره تمدید قرارداد باشد، شما عملاً استراتژی مذاکراتی خود را به یک ارائه‌دهنده خارجی گزارش کرده‌اید. حتی اگر ابزار در حالت «فقط خواندنی» باشد، باز هم داده‌های شما از محیط امن شرکت خارج شده است. این آسیب‌پذیری‌ها نشان می‌دهد که چرا بسیاری از معماری‌های فعلی چت‌بات‌ها در برابر بازرسی‌های سخت‌گیرانه حریم خصوصی سال ۲۰۲۶ شکست می‌خورند و نیاز به بازنگری بنیادین دارند.

در ۸ اکتبر ۲۰۲۶، شرکت Composio قابلیت Instant را عرضه کرد. این ویژگی دسترسی به بیش از ۱۰۰ ابزار پولی — از جمله ابزارهای تحقیق، غنی‌سازی داده، تبدیل صوت به متن و تولید رسانه — را بدون نیاز به ثبت‌نام جداگانه در هر سرویس فراهم می‌کند. طبق اعلام این شرکت، این اقدام اصطکاک مهندسی را حذف می‌کند، اما یک فرض خطرناک ایجاد می‌کند: اینکه ابزارهای «فقط خواندنی» امن هستند. در واقعیت، ابزاری که نمی‌تواند سیستم شما را تغییر دهد، همچنان می‌تواند حساس‌ترین یادداشت‌های داخلی شما را به یک API شخص ثالث صادر کند. طبق مستندات Composio، این قابلیت در ۱۰ اکتبر به عنوان «آزمایشی» علامت‌گذاری شد و تأکید شده که ورودی‌ها به ارائه‌دهنده می‌رسند و هیچ تضمینی برای عدم ذخیره‌سازی داده‌ها وجود ندارد.

برای حل این مشکل، بابی هال (Bobby Hall)، توسعه‌دهنده مستقل، یک پیاده‌سازی مرجع از «گیت انتشار داده» (Data Release Gate) را با زبان TypeScript منتشر کرد. همان‌طور که در تحلیل‌های قبلی ما درباره امنیت مدل‌های بازمتن اشاره کردیم، مشکل اصلی این است که کنترل‌های بودجه و لیست‌های مجاز (Allowlists) معمولاً فقط می‌پرسند «آیا این فراخوانی ارزان است یا در دسترس؟». آن‌ها نمی‌پرسند «آیا این گیرنده خاص، اجازه دریافت این فیلدهای خاص را برای این وظیفه دارد؟». این رویکرد در واقع تکامل‌یافته‌ی همان لایه مجوز است که پیش‌تر به عنوان سدی در برابر اجرای غیرمجاز APIها توسط عامل‌ها معرفی شده بود. یک ابزار جست‌وجو برای افشای اطلاعات نیازی به مجوز send_email ندارد؛ ورودی آن صرفاً پیامی است که به ارائه‌دهنده ارسال می‌شود.

سازوکار گیت داده

راهکار پیشنهادی، قدرت تصمیم‌گیری را از مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — گرفته و به یک سیاست برنامه‌ای قطعی (Deterministic) منتقل می‌کند. به‌جای اینکه اجازه دهیم مدل یک رشته پرس‌وجوی خام بنویسد (که می‌تواند هر پاراگراف خصوصی را شامل شود)، مدل باید یک «پیشنهاد ساختاریافته» ارسال کند. این پیشنهاد تنها شامل سه مورد است: نام ابزار، شناسه‌های رکورد و نام فیلدهای خاص درخواست‌شده.

سپس برنامه این پیشنهاد را در برابر سه منبع داخلی معتبر اعتبارسنجی می‌کند:

• دامنه وظیفه احراز هویت‌شده: تعریف مستاجر (Tenant)، ابزارهای مجاز، گیرندگان و فیلدها.
• سجل ابزارهای بررسی‌شده: نگاشت گیرندگان به منابع اعتبارنامه و کلاس‌های داده پذیرفته‌شده (مثلاً «عمومی» در برابر «داخلی»).
• ذخیره‌گاه رکوردها: شامل مقادیر واقعی، مالکیت مستاجر و طبقه‌بندی فیلدها. این ساختار مدیریت داده‌ها شباهت زیادی به لایه مدیریت دانش Foundry IQ مایکروسافت دارد که برای سازماندهی اطلاعات ایجنت‌ها طراحی شده است.

جزئیات فنی و محدودیت‌ها

برای جلوگیری از دور زدن امنیت توسط مدل، این گیت چندین محدودیت معماری سخت‌گیرانه را اجرا می‌کند:

• منطق قطعی: گیت از ۲۵ بررسی قطعی استفاده می‌کند. برای اجرا به هیچ کلید API، فراخوانی مدل یا هزینه‌ای نیاز ندارد.
• تجزیه سخت‌گیرانه (Strict Parsing): تجزیه‌کننده به‌جای نادیده گرفتن کلیدهای اضافی، آن‌ها را رد می‌کند. این کار مانع از آن می‌شود که مدل یک آرگومان پرس‌وجوی متن-آزاد اضافه کند یا سعی کند برچسب «عمومی» را به یک پاراگراف خصوصی بچسباند.
• محدودیت شناسه‌ها: لیست شناسه‌ها به ۱۰ مورد محدود شده و نمی‌تواند شامل موارد تکراری باشد.
• حفاظت از پروتوتایپ: جست‌وجو در سجل نیازمند ویژگی‌های own است تا نام‌هایی مثل toString از طریق پروتوتایپ شیء حل نشوند.
• اتمیته دسته‌ای: تابع تنها زمانی یک خروجی ارسال می‌کند که کل دسته تایید شده باشد. اگر یک رکورد عمومی و سپس رکوردی متعلق به مستاجر دیگر بیاید، کل درخواست رد می‌شود، نه اینکه بخشی از داده‌ها ارسال شود.

اجرای مرز امنیتی

سیستم از یک حلقه سخت‌گیرانه برای بررسی تک‌تک فیلدها قبل از بازگشت هرگونه داده استفاده می‌کند. منطق اصلی در فایل gate.ts روی شناسه‌های رکورد و فیلدها پیمایش کرده و مالکیت و تطابق مستاجر را تایید می‌کند و سپس بررسی می‌کند که آیا برچسب فیلد در لیست برچسب‌های تاییدشده مسیر قرار دارد یا خیر.

اگر مدلی یک فیلد «عمومی» درخواست کند اما رکورد متعلق به مستاجر دیگری باشد، سیستم خطای tenant-mismatch می‌دهد. اگر ابزار فقط برای داده‌های عمومی تایید شده باشد اما مدل فیلدی با برچسب «داخلی» بخواهد، خطای data-class-not-approved صادر می‌شود. برای مثال، مسیر companySearch ممکن است فیلدهای عمومی را بپذیرد، در حالی که مسیر crmLookup بسته به گیرندگان مجاز، هر دو نوع فیلد عمومی و داخلی را قبول کند.

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

تست محلی و اعتبارسنجی

توسعه‌دهندگان می‌توانند این منطق را به‌صورت محلی با Node.js نسخه ۲۲.۲۰.۰ یا جدیدتر تست کنند. با کلون کردن مخزن agent-data-release-gate و اجرای npm test و دستور node --experimental-strip-types test.ts می‌توان ۲۵ بررسی را در سناریوهای مختلف شکست تست کرد:

• publicSearch: تایید (گیرنده=research-provider، اعتبارنامه=instant، فیلدها=company,domain)
• privateSearch: رد (عدم تایید کلاس داده)
• connectedNotes: تایید (گیرنده=tenant-crm، اعتبارنامه=connected، فیلدها=notes)
• crossTenant: رد (عدم تطابق مستاجر)

محدودیت‌های گیت

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

این رویکرد، پارادایم امنیتی را از «آیا عامل می‌تواند از این ابزار استفاده کند؟» به «آیا این گیرنده مجاز است این تکه داده خاص را برای این وظیفه خاص ببیند؟» تغییر می‌دهد.

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

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

گام بعدی شما

• اگر از ابزارهای Third-party در عامل‌های خود استفاده می‌کنید، ورودی‌های ارسالی به APIها را مانیتور کنید تا مطمئن شوید فیلدهای حساس ارسال نمی‌شوند.
• پیاده‌سازی یک لایه اعتبارسنجی قطعی (Deterministic) را بین خروجی مدل و فراخوانی ابزار جایگزین اعتماد مطلق به مدل کنید.
• مخزن agent-data-release-gate را برای درک نحوه جداسازی «اجازه دسترسی به ابزار» از «اجازه انتشار داده» بررسی کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.