عامل‌های هوش مصنوعی شما تنها تا زمانی امن هستند که مرزهایی وجود داشته باشد که هرگز نتوانند از آن‌ها عبور کنند. در ۲۷ اوت ۲۰۲۶، شرکت EDB استدلال کرد که تکیه بر حفاظ‌ها (Guardrails) در سطح مدل یک شکست ساختاری است، زیرا عامل‌های خودمختار ذاتاً پیش‌بینی‌ناپذیرند.
وقتی سازمان‌ها به عامل‌ها اجازه می‌دهند بدون تأیید هر مرحله توسط انسان، برنامه‌ریزی کنند، تصمیم بگیرند و در سیستم‌های مختلف عمل کنند، یک سؤال حیاتی در بررسی‌های معماری پیش می‌آید: وقتی یک عامل سعی می‌کند کاری را انجام دهد که هرگز مجاز به آن نبوده، چه چیزی واقعاً جلوی او را می‌گیرد؟
بسیاری از شرکت‌ها در حال حاضر سعی می‌کنند با افزودن لایه‌هایی از دستورالعمل‌ها، سیاست‌ها و نظارت روی مدل، امنیت را تأمین کنند. این روش شکست می‌خورد چون حاکمیت را شبیه به یک «قول» از طرف عامل می‌بیند، نه یک محدودیت فیزیکی در سیستم. تصور کنید قانونی داشته باشیم که بگوید «هرگز درِ ماشین را باز نکن»؛ یک عامل ممکن است تا زمانی که آتش‌سوزی رخ نداده یا کسی آسیب ندیده باشد، این قانون را به صورت تحت‌اللفظی دنبال کند، اما در لحظه‌ی بحران، این قانون باید فوراً بر اساس بستر (Context) معکوس شود. چون عامل‌ها قدرت قضاوت مستقل برای لغو دستورات خود را ندارند، به قوانینی نیاز دارند که در بستر لحظه‌ای عمل کنند.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، لایه‌های نرم‌افزاری هرگز جایگزین محدودیت‌های سخت‌افزاری یا ساختاری نمی‌شوند. این چالش‌ها در واقع بخشی از یک معماری گسترده‌تر هستند که در آن سه لایه امنیتی برای مهار عامل‌ها در محیط‌های سازمانی تعریف شده تا از شکست‌های عملیاتی جلوگیری شود.
محدودیت ساختاری حفاظ‌ها
کنترل‌ها در لایه‌ی عامل تنها به اندازه‌ی پیش‌بینی‌پذیری خروجی مدل قابل اعتماد هستند. اما خودمختاری دقیقاً همان ویژگی‌ای است که پیش‌بینی خروجی را سخت می‌کند. نظارتی که وابسته به بررسی یک اقدام قبل از وقوع باشد، نمی‌تواند با سیستمی که در میلی‌ثانیه و در چندین سامانه به‌طور هم‌زمان عمل می‌کند، رقابت کند.
به نقل از گزارش EDB، حاکمیت باید در لایه‌ی داده‌های عملیاتی اجرا شود. این تنها نقطه‌ای است که سیستم می‌تواند دسترسی را در میلی‌ثانیه رد کند، فارغ از اینکه عامل چگونه ساخته شده یا چگونه تصمیم گرفته است عمل کند. وقتی کنترل، ویژگیِ خودِ پایگاه‌داده باشد، ماهیت احتمالی مدل دیگر یک ریسک سیستمی ایجاد نمی‌کند. این رویکرد در واقع پاسخی به نیاز برای مدیریت ریسک از طریق تعریف سطوح مختلف خودمختاری است تا هر اقدام بر اساس سطح خطر آن کنترل شود.
لایه‌ی داده به عنوان نقطه‌ی اجرا
عامل‌ها با پرس‌وجو، بازیابی، تبدیل و اقدام روی داده‌ها ارزش خلق می‌کنند. یک سیاست که می‌گوید عامل نباید به دسته‌ی خاصی از داده‌ها دسترسی داشته باشد، تنها زمانی معنا دارد که سیستم بتواند در لحظه‌ی درخواست، آن دسترسی را مسدود کند.
علاوه بر این، اصل قابلیت حسابرسی تنها زمانی معنا می‌یابد که سازمان بتواند دقیقاً بازسازی کند که عامل چه کرد، به چه داده‌ای دست زد، برای کدام کاربر عمل کرد و نتیجه چه بود. با انتقال حاکمیت به لایه‌ی داده، کنترل تبدیل به ویژگی پایگاه‌داده می‌شود، نه وعده‌ای که مدل زبانی داده است.
چارچوب اجرا
EDB برای انتقال امن عامل‌ها به محیط تولید، یک مدل حاکمیتی بر اساس سه ضرورت اصلی پیشنهاد می‌کند:
۱. اجرا و الزام (Enforce it)
- کنترل دسترسی مبتنی بر نقش و ویژگی (RBAC/ABAC) باید در لحظه‌ی پرس‌وجو برای کاربران و عامل‌ها اجرا شود.
- ماسک کردن پویا (Dynamic Column Masking) برای پنهان کردن داده‌های حساس باید از همین مسیر سیاستی پیروی کند.
- هویت عامل باید به عنوان یک موجودیت درجه‌یک با «هدف اعلام‌شده» (Declared Purpose) در ابتدای هر نشست تعریف شود، در حالی که هویت کاربرِ درخواست‌کننده نیز حفظ شود.
۲. مشاهده و اثبات (See it and prove it)
- طبقه‌بندی و برچسب‌گذاری داده‌ها باید موتور محرک سیاست‌های زیرساختی باشد.
- ثبت وقایع (Audit Logging) در سطح نشست باید دقیقاً ثبت کند کدام عامل، برای چه کاربر و تحت چه هدف اعلام‌شده‌ی خاصی عمل کرده است.
- ردیابی تبار (Lineage Tracking) در خط لوله‌ها ضروری است تا هر نتیجه را بتوان به درخواست اولیه‌ای که آن را تولید کرده است، بازگرداند.
۳. یکپارچه‌سازی و مقاوم‌سازی (Unify and harden)
مدیریت سیاست‌ها باید متمرکز و در محیط‌های مختلف قابل انتقال باشد.
رمزنگاری در حالت سکون (At rest) و در حال انتقال (In transit) اجباری است.
اجرا باید در محیط‌های درون‌سازمانی (On-prem)، ابری و محیط‌های حاکمیتی ایزوله (Air-gapped) یکسان و سازگار باشد.
نقش هدف اعلام‌شده
پریانکا جین (Priyanka Jain)، معاون مدیریت محصول در EDB، تأکید می‌کند که «هدف اعلام‌شده» تمایز اصلی است. او اشاره می‌کند که هدف اعلام‌شده به ویژگی‌ای تبدیل می‌شود که لایه‌ی دسترسی از پیش آن را می‌شناسد و مانند نقش کاربر یا امنیت سطح ردیف (Row-level security)، در همان مسیر سیاستی ارزیابی می‌شود.
با تبدیل نیت عامل به یک ویژگی قابل فهم برای لایه‌ی دسترسی، سیستم هدف عامل را با همان منطقی می‌سنجد که شغل یا دپارتمان یک انسان را ارزیابی می‌کند. مکانیسم اجرا تغییر نمی‌کند؛ آنچه تغییر می‌کند این است که هدف عامل بخشی از ارزیابی و بخشی از سندی است که بعداً ثابت می‌شود.
این رویکرد، مدل امنیتی را از یک «درِ قفل‌شده» — که جلوی تمام کارها را می‌گیرد — به یک «قلاده دیجیتال» تبدیل می‌کند. این قلاده دقیقاً تعریف می‌کند عامل تا کجا پیش برود، به چه چیزی دست بزند، چه چیزی را تغییر دهد و چه زمانی باید کار را به یک اپراتور انسانی ارجاع دهد.
حاکمیت و متن‌باز
برای صنایع تحت نظارت، این سطح از کنترل پیش‌نیاز ورود به محیط تولید است. EDB این چارچوب را بر پایه‌ی Postgres متن‌باز می‌سازد تا سازمان‌ها حاکمیت داده‌های خود را حفظ کنند. این کار مانع از آن می‌شود که شرکت‌ها حاکمیت خود را به یک لایه‌ی انحصاری (Proprietary) بسپارند که قادر به بازرسی یا مالکیت آن نیستند.
ترکیب حاکمیت داده و اجرای سطح منبع، یک قابلیت «خوب است داشته باشیم» نیست، بلکه پیش‌شرط استقرار عامل‌ها در بخش‌های حساس است. استفاده از یک بنیاد متن‌باز باعث می‌شود سازمان‌ها کنترل کنند داده‌هایشان کجا قرار دارد و چه کسی به آن دسترسی دارد.
این چرخش در معماری به رهبران و تیم‌های ریسک اجازه می‌دهد به مدل عملیاتی اعتماد کنند. وقتی پایگاه‌داده خودش نقطه اجرا باشد، سازمان می‌تواند بدون تکیه بر «آرزومندی» در مورد همراستاسازی مدل (Model Alignment)، با سرعت در پذیرش هوش مصنوعی پیش برود.
این رویکرد فرض بنیادی ایمنی هوش مصنوعی را تغییر می‌دهد: ما دیگر امیدوار نیستیم که بازیگر در محدوده بماند، بلکه مرزهایی می‌سازیم که بازیگر هرگز نتواند از آن‌ها عبور کند. با افزایش توانایی سیستم‌های عامل‌محور، دقت در تعیین محل کنترل، تنها راه حفظ سرعت بدون قربانی کردن امنیت است.
برای پیاده‌سازی این مدل، سازمان‌ها باید مجوزهای فعلی پایگاه‌داده خود را بازبینی کنند و تعیین کنند که آیا عامل‌های هوش مصنوعی آن‌ها در حال حاضر تحت یک هویت مشترک عمل می‌کنند یا به عنوان موجودیت‌های متمایز با اهداف محدودشده فعالیت می‌کنند.
گام بعدی شما
- مجوزهای فعلی پایگاه‌داده خود را بازبینی کنید و ببینید آیا عامل‌های شما با یک هویت مشترک عمل می‌کنند یا هر کدام هویت و هدف محدودی دارند.
- بررسی کنید که آیا سیستم ثبت وقایع شما قادر است «نیت» یا «هدف» هر درخواست عامل را به طور مجزا ذخیره کند یا خیر.
- برای داده‌های حساس، به جای تکیه بر پرامپت‌های سیستمی، لایه‌ی دسترسی پایگاه‌داده را برای مسدود کردن دسترسی‌ها تنظیم کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو