حفاظهای امنیتی برای عاملهای هوش مصنوعی سازمانی
بیشتر توصیهها درباره حفاظهای هوش مصنوعی شبیه به یک تبلیغ فروش به نظر میرسند. آنها بر نمودارهای پرزرقوبرق و چکلیستها تمرکز دارند.
امنیت واقعی در محیط عملیاتی (production) کمتر جذاب است. این امنیت بر چیزهایی تکیه دارد که مدتها پیش از مدلهای زبانی بزرگ (LLMs) وجود داشتند.
من دو سال را صرف ساخت عاملهای هوش مصنوعی برای یکی از شرکتهای Fortune 100 کردم. این عاملها با خطاهای CI/CD، حوادث Kubernetes و مستندات زیرساختی سر و کار دارند.
در اینجا لایههای امنیتی که برای ایمن نگه داشتن آنها استفاده میکنیم، آورده شده است.
هویت در مرز عامل. هر عامل از یک هویت بار کاری (workload identity) استفاده میکند. هرگز از اعتبارنامههای مشترک استفاده نمیکند. محدوده IAM سقف امنیتی شماست. اگر عامل نیازی به دسترسی به پایگاه داده ندارد، نقش IAM نباید آن را داشته باشد. این مهمترین کنترل شماست.
لیستهای مجاز ابزارها (Tool allow-lists). پلتفرم تصمیم میگیرد که یک عامل به کدام ابزارها دسترسی داشته باشد. یک عامل جستجوی کد نباید ابزار ایمیل داشته باشد. ما برای این کار از پیکربندیهای ایستا (static configs) استفاده میکنیم. ما هرگز از ثبت پویای ابزار (dynamic tool registration) استفاده نمیکنیم.
کنترلهای خروجی شبکه (Network egress controls). عاملها فقط به نقاط پایانی (endpoints) موجود در لیست مجاز دسترسی دارند. ما از فیلترینگ DNS و یک پروکسی خروجی (egress proxy) استفاده میکنیم. این کار مانع از آن میشود که توهمات مدل (model hallucinations) منجر به فراخوانی آدرسهای URL اشتباه شود.
جداسازی اسرار (Secrets isolation). عاملها هرگز اسرار خام را نمیبینند. ما از توکنهای نشست کوتاهمدت که در حین فراخوانی ابزار تزریق میشوند، استفاده میکنیم. هرگز اسرار را در یک پرامپت (prompt) قرار ندهید. هر چیزی که در یک پرامپت باشد، میتواند ثبت (log) یا بازپخش (replay) شود.
ردپای کامل حسابرسی (Full audit trails). شما باید هر فراخوانی مدل و هر فراخوانی ابزار را ثبت کنید. این شامل ورودیها، خروجیها، آرگومانهای ابزار و هویت کاربر است. برای درک اینکه در طول یک حادثه چه مشکلی پیش آمده، به این دادهها نیاز دارید.
تایید انسانی. برای هر اقدامی که یک سیستم ثبت مرجع (system of record) را تغییر میدهد، پلتفرم باید متوقف شود. یک انسان باید آن اقدام را تایید کند. این شبکه ایمنی شماست.
از این اشتباهات رایج دوری کنید:
دستورالعملهای سطح پرامپت. گفتن «هرگز X را انجام نده» به یک مدل، امنیت محسوب نمیشود. یک کاربر میتواند مدل را فریب دهد. کنترل را به لایه IAM یا لایه ابزار منتقل کنید.
فیلترهای عمومی PII. این فیلترها نرخ خطای بالایی دارند. بهتر است دسترسی به دادهها را از طریق IAM محدود کنید تا عامل هرگز اطلاعات حساس را نبیند.
مدلهای حفاظتی (Guardrail models). استفاده از یک LLM دوم برای ارزیابی مدل اول، باعث ایجاد تأخیر (latency) میشود. این یک کنترل امنیتی واقعی نیست، بلکه صرفاً یک ترکیب مدل (model ensemble) است.
درسهایی که به سختی آموختم:
قبل از پرامپتها، IAM را اصلاح کنید. من زمانم را صرف تنظیم پرامپتها کردم، در حالی که باید نقشهای IAM را محدودتر میکردم. کنترلها را تا حد امکان به لایههای پایینتر در پشته (stack) منتقل کنید.
ردپای حسابرسی (audit trail) خود را بیش از حد دقیق طراحی کنید. ثبت کردن صرفاً پرسش (prompt) و پاسخ کافی نیست. شما به فراخوانیهای ابزار (tool calls) و آرگومانهای میانی نیاز دارید. ثبت (log) کردن در مراحل اولیه ارزان است، اما اصلاح آن در مراحل بعدی هزینهبر خواهد بود.
ارتباطات عامل (agent) را محدود کنید. در سیستمهای چندعاملی (multi-agent systems)، یک سقف مشخص برای فراخوانیهای عامل-به-عامل تعیین کنید. این کار از شکستهای زنجیرهای (cascading failures) جلوگیری میکند.
ایمنی هوش مصنوعی در مقیاس بالا، یک مشکل مدل نیست؛ بلکه یک مشکل پلتفرم است. با عاملهای خود با همان انضباط عملیاتی برخورد کنید که با هر سیستم تولیدی (production system) دیگری برخورد میکنید.
انجمن یادگیری اختیاری: https://t.me/GyaanSetuAi