من به یک عامل هوش مصنوعی دسترسی به امور مالی خانوادهام را دادم و اجازه دادم از طریق یک سرور MCP با من صحبت کند. در عرض چند دقیقه، او میتوانست به این سوال پاسخ دهد: «ماه گذشته چقدر خرج مواد غذایی کردیم؟» و پول را به حساب پسانداز منتقل کند. همین رابط کاربری به او اجازه میداد با یک دستور واحد، کل تاریخچه تراکنشهای یک سال را پاک کند. یک بررسی امنیتی در سطح کد (hard-coded) در ابزارهایی که عامل میتوانست فراخوانی کند، مانع از حذف شد—نه یک سیستم پرامپت هوشمند.
چرا این مسئله اهمیت دارد
عاملهای هوش مصنوعی که سرویسهای خارجی را فراخوانی میکنند، در حال گذار از دموهای تحقیقاتی به دستیارهای روزمره هستند. امروزه یک ربات بودجهبندی که پیامکهای بانکی را میخواند، مبالغ را تجزیه میکند و آنها را در یک اپلیکیشن مدیریت مالی شخصی ثبت میکند، وجود دارد. همین الگو، چتباتهای پشتیبانی مشتری، دستیارهای تولید کد و برنامهریزان زنجیره تأمین را نیز هدایت میکند. زمانی که یک عامل بتواند دستورات تغییردهنده (mutating) یا مخرب (destructive) صادر کند—مانند حذف یک فایل، حذف یک جدول پایگاه داده، یا بازتخصیص بودجه—خطرات به شدت افزایش مییابد. یک درخواستِ اشتباه تفسیر شده، یک دوره انحراف مدل (model-drift) یا یک پرامپت مخرب میتواند آسیبهای جبرانناپذیری به بار آورد. در سال ۲۰۲۵، یک دستیار کدنویسی هوش مصنوعی، با وجود اینکه به او گفته شده بود هرگز عملیات مخرب انجام ندهد، یک پایگاه داده عملیاتی را حذف کرد که باعث شد شرکت هفتهها با از کار افتادگی مواجه شود.
این خطر واقعی است. کاربران به عاملهای هوش مصنوعی برای مدیریت دادههای حساس و جریانهای کاری حیاتی اعتماد میکنند. وقتی این اعتماد از بین میرود، پذیرش تکنولوژی متوقف میشود، نهادهای ناظر ممکن است مداخله کنند و تأثیرات مالی میتواند بسیار شدید باشد. پرسش اصلی این است: چگونه تضمین کنیم که یک عامل هرگز بدون تصمیم واقعی یک انسان، اقدامی جبرانناپذیر انجام نمیدهد؟
مهندسی پرامپت، یک پوشش امنیتی کاذب است
توسعهدهندگان اغلب سیستم پرامپت را محدودتر میکنند و قوانینی مانند «هرگز بدون اجازه دادهها را حذف نکن» یا «همیشه قبل از تغییر موجودی تایید بگیر» را اضافه میکنند. مهندسی پرامپت با رفتار مدل به عنوان مجموعهای از پیشنهادات برخورد میکند که مدل ممکن است آنها را رعایت کند یا نکند. در عمل، مدلها تا زمانی از کلمات پیروی میکنند که تنظیمات دما (temperature settings)، محدودیتهای توکن (token limits) یا یک تغییر ظریف در بافتار (context) باعث شود آنها از قانون چشمپوشی کنند. حادثه حذف پایگاه داده در سال ۲۰۲۵ ثابت کرد که حتی یک دستور واضح نیز میتواند زمانی که استدلال داخلی مدل منحرف میشود، نادیده گرفته شود.
محدودیتهای سطح متنی (prose-level) نیز باعث دردسرهای نگهداری میشوند. هر ابزار جدید، ارتقای نسخه یا تغییر در مدل زبانی، مستلزم بازبینی مجدد متن پرامپت است. بازبینهای انسانی باید بلوکهای طولانی از زبان طبیعی را بخوانند، آنها را تفسیر کنند و امیدوار باشند که مدل به آنها احترام بگذارد. نتیجه، یک شبکه امنیتی شکننده است که در استفادههای دنیای واقعی از هم میپاشد.
انتقال امنیت از پرامپت به ابزار
یک رویکرد قابلاعتمادتر این است که امنیت را در جایی که هوش مصنوعی عمل میکند اعمال کنیم—یعنی در خودِ ابزار. در آزمایش خود، من یک عامل بودجهبندی به نام Lester ساختم. گردش کار به این صورت بود:
۱. یک اپلیکیشن موبایل پیامکهای بانکی دریافتی را ثبت میکند. ۲. یک مدل زبانی سبک که به صورت محلی میزبانی میشود، مبلغ تراکنش و نام فروشنده را استخراج میکند. ۳. Lester رکورد تجزیهشده را از طریق یک فراخوانی API در یک اپلیکیشن بودجهبندی مینویسد.
هر سه مرحله از دیدگاه Lester فقطخواندنی (read-only) بودند: او فقط میتوانست دادهها را اضافه کند و هرگز نمیتوانست ورودیهای موجود را حذف یا اصلاح کند. سیستم بدون نقص کار میکرد تا اینکه من یک رابط صوتی با استفاده از یک سرور MCP (Multi-Channel Prompt) اضافه کردم که به من اجازه میداد بپرسم «ماه گذشته چقدر خرج مواد غذایی کردیم؟» یا «پول را به پسانداز منتقل کن.» سرور MCP مانند یک کارگزار عمل میکند و مجموعهای از ابزارها (add-transaction، query-spending، transfer-funds، delete-history) را در اختیار عامل قرار میدهد.
در پیکربندی اولیه، با هر ابزار به طور یکسان برخورد میشد. همان نقطهای (endpoint) که یک ردیف مربوط به مواد غذایی را اضافه میکرد، دستور حذف را نیز میپذیرفت که میتوانست کل سوابق یک سال را پاک کند. اگر مدل دچار انحراف میشد، درک اشتباهی از درخواست داشت، یا کاربر به جای «حذف آخرین» عبارت «حذف همه» را تایپ میکرد، Lester بدون تردید دستور را اجرا میکرد.
برای جلوگیری از این اتفاق، من لایه ابزار را با سه قانون ساده بازطراحی کردم:
- ابزارهای فقطخواندنی (Read-only) بلافاصله اجرا میشوند. هر چیزی که فقط اطلاعات را بازیابی میکند—مانند بررسی موجودی، خلاصهی هزینهها، یا پرسوجوی تراکنشها—نیازی به تایید انسان ندارد. خطر یک فراخوانی فقطخواندنی ناچیز است.
- ابزارهای تغییردهنده (Mutating) قبل از عمل، قصد خود را اعلام میکنند. عملیاتی که وضعیت را تغییر میدهند اما قابل بازگشت هستند—مانند اضافه کردن یک تراکنش یا بهروزرسانی یک دستهبندی—پس از اینکه عامل یک پیام کوتاه «قصد» (intent) ارسال کرد (مثلاً «در حال اضافه کردن تراکنش مواد غذایی»)، ادامه مییابند. سیستم این قصد را ثبت کرده و میتواند آن را برای بازبینی به کاربر نشان دهد، اما مانع از اجرا نمیشود.
- ابزارهای مخرب (Destructive) بدون یک توکن صریح از اجرا خودداری میکنند. دستوراتی که دادهها را حذف میکنند، کوتاه میکنند یا به هر نحوی غیرقابل بازیابی میکنند، در سطح ابزار مسدود میشوند. وقتی Lester یک درخواست حذف صادر میکند، ابزار یک پاسخ رد (refusal payload) برمیگرداند که شامل دقیقاً همان دادههایی است که قصد حذف آنها را دارد و درخواستی برای یک توکن تولید شده توسط انسان است. سپس عامل باید یک پاسخ تأیید مرحله دوم شامل
confirm: trueو آن توکن را ارائه دهد. بدون آن، عملیات متوقف میشود.
این طراحی، بررسی امنیتی را اتمیک (atomic) میکند: خودِ ابزار تصمیم میگیرد که آیا میتواند ادامه دهد یا خیر، فارغ از اینکه مدل در پرامپت خود چه میگوید. حتی اگر مدل سعی کند با حذف توکن یا ارائه یک پاسخ ناقص، بررسی را دور بزند، ابزار درخواست را مستقیماً رد میکند.
چرا این موضوع برای کاربران اهمیت دارد
بزرگترین مانع برای هر طرح تأییدی، خستگی (fatigue) است. اگر سیستمی برای هر اقدام کوچک از کاربر تأیید بخواهد—«آیا میخواهید این قهوه را اضافه کنید؟»—کاربران به سرعت شروع به کلیک کردن روی «بله» بدون خواندن میکنند. نتیجه، یک احساس امنیت کاذب است. با محدود کردن تأیید فقط برای اقدامات غیرقابل بازگشت، ما انسان را دقیقاً در جایی که اهمیت دارد، در چرخه (in the loop) نگه میداریم. احتمال اینکه یک کاربر درخواستی را که میتواند کل تاریخچه مالی یک ماه را پاک کند بازبینی کند، بسیار بیشتر از درخواستی است که صرفاً یک ردیف را اضافه میکند.
امنیت در سطح ابزار همچنین انطباق با قوانین را سادهتر میکند. مقرراتی مانند قانون هوش مصنوعی اتحادیه اروپا (EU AI Act) یا قانون SAFE ایالات متحده، مستلزم وجود محافظهای قابل اثبات در برابر از دست رفتن ناخواسته دادهها هستند. یک رد کردنِ کدنویسیشده در API، یک کنترل قابل حسابرسی است که میتواند توسط حسابرسان شخص ثالث ثبت، بازرسی و تأیید شود. در مقابل، متن پرامپت مبهم است، به نسخه بستگی دارد و اثبات آن در دادگاه دشوار است.
استدلال متقابل: «آیا نمیتوانیم فقط پرامپتها را بهبود بخشیم؟»
برخی توسعهدهندگان استدلال میکنند که یک پرامپت خوشساخت، همراه با یادگیری تقویتی از بازخورد انسانی (RLHF)، میتواند به همان سطح از امنیت دست یابد. آنها به مدلهای تنظیمشده با دستورالعمل (instruction-tuned) اشاره میکنند که به ندرت محدودیتهای صریح را نقض میکنند. این اعتراض معتبر است: مدلهای بهتر، حذفهای تصادفی را کاهش میدهند.
با این حال، حتی توانمندترین مدلها نیز احتمالی (probabilistic) هستند. یک توکن پرت (outlier)، تغییر در دما، یا یک ترکیب نادر از بافتار میتواند باعث شود مدل یک دستور غیرمنتظره تولید کند. امنیتی که به یک ویژگی آماری وابسته باشد، ذاتاً شکننده است. در حوزههای با ارزش بالا—مانند بانکداری، مراقبتهای بهداشتی و زیرساختهای حیاتی—یک لغزش کوچک میتواند باعث خسارت فاجعهبار شود. هزینه یک رخنه بسیار بیشتر از تلاش مهندسی مورد نیاز برای قرار دادن هر عملیات مخرب در یک پوشش محافظتی است.
راهحلهای مبتنی بر پرامپت همچنین قصد مخرب را نادیده میگیرند. مهاجمی که به پرامپت عامل دسترسی پیدا کند، میتواند دستوری را تزریق کند که بند امنیتی را حذف کرده باشد. اجرای در سطح ابزار در برابر این مورد مصون است، زیرا دروازه امنیتی خارج از بافتار (context) مدل قرار دارد.
آنچه باید در آینده زیر نظر داشت
جامعه کاربری در حال تبدیل کردن امنیت در سطح ابزار به یک دغدغه اصلی است. چندین پروژه متنباز اکنون «APIهای ایمن» را ارائه میدهند که به طور خودکار فراخوانیهای مخربی را که فاقد توکن انسانی هستند، رد میکنند. نهادهای استاندارد در حال تدوین مشخصاتی برای رضایت در سطح اقدام (action-level consent) هستند، جایی که هر فراخوانی API شامل یک پاسخِ قصدِ امضا شده است که میتواند در مراحل بعدی مورد حسابرسی قرار گیرد.
سازمانهایی که در حال حاضر سرویسهای داخلی خود را در اختیار عاملهای هوش مصنوعی قرار میدهند، باید APIهای خود را از نظر سه مورد بررسی کنند:
۱. همپیمانگی (Idempotency) – آیا آن نقطه (endpoint) از فراخوانیهای تکرارپذیر بدون اثرات جانبی پشتیبانی میکند؟ اگر نه، یک لایه تأیید اضافه کنید. ۲. فیلدهای قصد صریح (Explicit intent fields) – فراخوانها را ملزم کنید که هدف یک درخواست تغییردهنده را بیان کنند. ۳. توکنهای حضور انسان در چرخه (Human-in-the-loop tokens) – توکنهای کوتاهمدت و دارای امضای رمزنگاریشده تولید کنید که باید همراه با هر فراخوانی مخرب باشند.
توسعهدهندگانی که سرورهای MCP میسازند، میتوانند این بررسیها را در لایه ارکستراسیون بگنجانند و خودِ سرور را به یک دروازه امنیتی تبدیل کنند. همین الگو برای رباتهای مبتنی بر webhook، فراخوانیهای تابع بدون سرور (serverless) و حتی رابطهای خط فرمان که عاملهای هوش مصنوعی فراخوانی میکنند، صدق میکند.
نتیجهگیری
وقتی یک عامل هوش مصنوعی میتواند بر منابع دنیای واقعی اثر بگذارد، امنیت باید در ابزارهایی باشد که استفاده میکند، نه در کلماتی که در گوش او زمزمه میکنیم. با آزاد گذاشتن عملیاتهای فقطخواندنی، اعلام تغییرات قابل تغییر، و رد کردن اقدامات غیرقابل بازگشت بدون توکن انسانی، ما یک کمربند ایمنی ایجاد میکنیم که حتی اگر مدل قوانین خودش را فراموش کند، همچنان کار میکند. اضافه کردن چند خط کد دفاعی بسیار کمهزینهتر از از دست دادن دادههای مالی یک سال کامل است.