چرا معماری عامل هوش مصنوعی شما یک ریسک امنیتی است

تا سال ۲۰۲۷، ۴۰٪ از استقرارهای هوش مصنوعی در سازمان‌ها با حوادث تزریق دستور (prompt injection) یا ربودن عامل (agent hijack) مواجه خواهند شد. این یک جهش عظیم نسبت به کمتر از ۵٪ در اوایل سال ۲۰۲۵ است.

لایه ارکستراسیون (orchestration layer) عامل‌ها را کاربردی می‌کند، اما در عین حال آن‌ها را به یک هدف تبدیل می‌کند.

یک شرکت لجستیک در سنگاپور اخیراً ۲.۳ میلیون دلار ضرر کرد. یک مهاجم یک دعوت‌نامه تقویم مخرب ارسال کرد. این کار باعث شد یک عامل زمان‌بندی (scheduling agent)، داده‌های CRM را به یک صندوق ورودی خارجی ارسال کند. مدل هیچ کد مخربی نداشت؛ بلکه دستورالعمل‌ها را به شکلی بی‌نقص اجرا کرد. مشکل از معماری بود.

عامل‌ها صرفاً چت‌بات نیستند. آن‌ها ابزارهایی هستند که فایل‌ها را می‌خوانند، APIها را فراخوانی می‌کنند و تراکنش‌ها را اجرا می‌کنند. مدل‌های امنیتی سنتی فرض می‌کنند که یک درخواست وارد می‌شود و یک پاسخ خارج می‌شود. عامل‌ها این مدل را در هم می‌شکنند.

عاملی که می‌تواند یک فایل PDF را خلاصه کند و درخواست بازگشت وجه (refund) ثبت کند، در واقع سه اپلیکیشن در یک زمان اجرا (runtime) است. هر فراخوانی ابزار یک ریسک است. هر نوشتن در حافظه یک ریسک است. اکنون هر ایمیل یا سندی، یک کد قابل اجرا محسوب می‌شود.

برای ساختن امن، به سه لایه نیاز دارید:

• هویت (Identity): هر فراخوانی ابزار باید هویتی مجزا از کاربر داشته باشد. • منشأ (Provenance): هر نوشتن در حافظه به متادیتا نیاز دارد تا نشان دهد از کجا آمده است. • قصد (Intent): هر مرحله از برنامه به یک شیء امضا شده نیاز دارد که سیستم‌های پایین‌دستی بتوانند آن را تأیید کنند.

اجازه ندهید عامل‌ها مستقیماً APIهای محیط عملیاتی (production) را فراخوانی کنند. از یک لایه ابزار میانجی (mediated tool layer) استفاده کنید. این لایه به عنوان فایروال جدید شما عمل می‌کند؛ آرگومان‌ها را اعتبارسنجی کرده و مجوزها را برای هر نشست (session) محدود می‌کند.

مراقب حافظه عامل خود باشید. مهاجمان از اسناد یا ایمیل‌های مسموم (poisoned) استفاده می‌کنند تا رفتار عامل را در طول زمان بازنویسی کنند. حملات مسموم‌سازی حافظه (Memory-poisoning) هر سال ۳۰۰٪ رشد می‌کنند.

بسیاری از تیم‌ها مدل‌سازی تهدید هوش مصنوعی را به خط لوله‌های (pipelines) فعلی خود اضافه می‌کنند. این کافی نیست. شما باید امنیت را به خودِ زمان اجرای عامل (agent runtime) اضافه کنید. تنها ۱۹٪ از سازمان‌ها نظارتی برای ناهنجاری‌های فراخوانی ابزار دارند. اکثر آن‌ها به لاگ‌های قدیمی تکیه می‌کنند که رفتار عامل را نادیده می‌گیرند.

با عامل خود مانند یک کارمند تازه‌کار با دسترسی به سیستم رفتار کنید. شما به یک استخدام جدید در روز اول دسترسی کامل root نمی‌دهید؛ این کار را با عامل‌های خود نیز انجام ندهید.

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

لایه‌های امنیتی خود را همین حالا بسازید. سعی نکنید آن‌ها را پس از وقوع یک رخنه امنیتی (breach) اصلاح کنید.

منبع: https://dev.to/yanoai/why-your-ai-agent-architecture-will-be-your-biggest-security-liability-by-2027-30la

جامعه یادگیری اختیاری: https://t.me/GyaanSetuAi