۳ لایهٔ امنیتی برای مهار عامل‌های هوش مصنوعی در محیط کسب‌وکار

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

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

در حال حاضر، شرکت‌های SaaS خواهان حضور عامل‌ها در داخل محصولات خود هستند، ارائه‌دهندگان نرم‌افزارهای مستقل (ISV) به دنبال قابلیت‌های هوشمند بدون بازسازی کامل اپلیکیشن‌ها هستند و ارائه‌دهندگان خدمات برون‌سپاری تجاری (BPO) قصد دارند رویه‌های عملیاتی تکرارپذیر را به خدماتی مقیاس‌پذیر تبدیل کنند. سازمان‌ها این عامل‌ها را در سیستم‌های مالی، تدارکات و بهداشت و درمان مستقر می‌کنند. با این حال، حاکمیت در محیط عملیاتی زمانی پیچیده می‌شود که یک عامل بتواند داده‌های سازمانی را بازیابی کند، APIها را فراخوانی نماید، ابزارهای MCP را اجرا کند، یک سیستم ثبت رکورد (System of Record) را به‌روزرسانی کند، عامل دیگری را فعال نماید یا درخواست تأیید کاربر را ارسال کند.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، انتقال از مدل‌های متنی به سیستم‌های عامل‌محور، لایه‌ای از تصمیم‌گیری را اضافه می‌کند که می‌تواند قوانین قطعی کسب‌وکار را دور بزند. در حالی که حاکمیت سنتی قطعی (Deterministic) است — یعنی کاربر نقشی دارد، API توابع تأییدشده‌ای را ارائه می‌دهد و اپلیکیشن قوانین تثبیت‌شده را اجرا می‌کند — عامل‌ها متفاوت عمل می‌کنند. آن‌ها درخواست‌ها را تفسیر می‌کنند، بستر (Context) را بازیابی می‌کنند، ابزارها را انتخاب می‌کنند، نتایج را ارزیابی می‌کنند و گام بعدی را تعیین می‌کنند.

به نقل از تحلیل فنی منتشر شده در dev.to در ۷ اوت ۲۰۲۶، حاکمیت در محیط عملیاتی باید کل مسیر اجرای عامل را پوشش دهد، نه فقط خروجی نهایی را. برای شرکت‌های SaaS و ارائه‌دهندگان BPO، این تغییر از یک دستیار ساده به یک عامل عملیاتی، لایه‌ای از تصمیم‌گیری را معرفی می‌کند که می‌تواند قوانین سنتی کسب‌وکار را نادیده بگیرد. برای مثال، وقتی مشتری یک سرویس SaaS از عامل می‌خواهد یک اختلاف در صورت‌حساب را حل کند، عامل باید داده‌های فاکتور را بخواند، تاریخچه حساب را مقایسه کند، یک تعدیل را پیشنهاد دهد و احتمالاً رکورد مشتری را به‌روزرسانی کند. هر یک از این مراحل سطح دسترسی و ریسک متفاوتی دارد. سازمان‌ها باید به‌وضوح بین آنچه یک عامل می‌تواند «بخواند»، «پیشنهاد دهد»، «درخواست کند» و «اجرا کند» تمایز قائل شوند.

هزینهٔ استقلال عامل‌ها

مدیریت هزینه‌های عامل‌ها با فاکتورهای ماهانه ساده‌ی مدل‌ها ممکن نیست. یک درخواست تجاری ساده اغلب منجر به چندین فراخوانی مدل، عملیات بازیابی (Retrieval) — مثل دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — عملیات Embedding، OCR، جستجوهای خارجی، اجرای ابزارها و فراخوانی عامل‌های دیگر می‌شود. تکرار عملیات (Retries) و اجراهای شکست‌خورده می‌تواند هزینه‌ها را به‌شدت افزایش دهد.

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

پلتفرم elsai این چالش را با سامانه مدیریت منابع عامل (ARMS) حل می‌کند. این سیستم امکان مشاهده و نظارت بر موارد زیر را فراهم می‌کند:

• میزان مصرف توکن و استفاده از مدل
• تأخیر (Latency) و ردپای اجرا (Execution Traces)
• فعالیت ابزارها و عملیات بازیابی

برای ارائه‌دهندگان SaaS، این شفافیت برای تجاری‌سازی حیاتی است. یک تیم محصول باید پیش از بسته‌بندی ویژگی‌های عامل در یک مدل اشتراکی، میزان مصرف را در سطح جریان کاری یا سطح مستاجر (Tenant) درک کند. ارائه‌دهندگان BPO از این داده‌ها برای تعیین هزینه واقعی عملیاتی پردازش یک پرونده و میزان نیاز باقی‌مانده به دخالت انسانی استفاده می‌کنند. در اینجا، هزینه به بخشی از حاکمیت تبدیل می‌شود زیرا تعیین می‌کند که آیا یک مدل عملیاتی از نظر تجاری پایدار است یا خیر.

کنترل اقتدار ابزارها

دادن دسترسی گسترده به یک پایگاه‌داده به یک عامل، یک شکست امنیتی است. تفاوت اصلی یک دستیار ساده با یک عامل عملیاتی در «دسترسی به ابزارها» است. مدلی که فقط تحلیل می‌کند ریسک کمی دارد، اما عاملی که می‌تواند رکورد یک قرارداد را تغییر دهد یا اطلاعات مشتری را عوض کند، اقتدار بسیار بالایی دارد.

رویکرد معماری پیشنهادی، ارائه قابلیت‌های محدود کسب‌وکار به‌جای دسترسی سیستمی است. elsai برای کنترل این دسترسی از پروتکل زمینهٔ مدل (MCP) استفاده می‌کند:

• رویکرد PowerBuilder: در معماری PowerBuilder که برای elsai آماده شده است، قابلیت‌های تاییدشده بک‌اند به‌جای دسترسی مستقیم به دیتابیس، از طریق ابزارهای MCP ارائه می‌شوند. این ساختار در راستای لایه‌بندی حاکمیتی برای مقیاس‌پذیری امن طراحی شده تا ریسک‌های دسترسی به داده‌ها به حداقل برسد.
• استراتژی اول-خوانش: مدل ابتدا با عملیات پرس‌وجو و خلاصه‌سازی (Read-only) شروع می‌کند.
• دسترسی انتخابی به نوشتن: قابلیت‌های تغییر داده (Write) تنها به‌صورت انتخابی و از طریق رویه‌های ذخیره شده (Stored Procedures) موجود اعمال می‌شود تا اعتبارسنجی، قوانین کسب‌وکار و فرآیندهای حسابرسی (Audit) اپلیکیشن، مرجع نهایی باقی بمانند.
• حفظ هویت: برای محصولات SaaS، عامل‌ها تحت هویت کاربر فعلی و مجوزهای مستاجر از طریق APIهای REST یا GraphQL عمل می‌کنند. اقدامات نوشتاری به‌جای دور زدن منطق امنیتی، از طریق APIهای محصول ادامه می‌یابند.

عملیاتی کردن سیاست‌ها و پرامپت‌ها

بسیاری از سازمان‌ها استانداردهای امنیتی، ماتریس‌های تأیید، SOPها و قوانین خاص مشتری را دارند، اما این‌ها معمولاً در اسناد هستند، نه در کد. elsai Guardrails این کنترل‌ها را به محیط اجرا می‌آورد.

این حفاظ‌ها (Guardrails) — شبیه به نرده‌های ایمنی در لبهٔ یک پل که اجازه نمی‌دهند کسی از مسیر خارج شود — سیاست‌ها را بر ورودی‌ها، خروجی‌ها، دسترسی به داده‌ها، استفاده از ابزارها و رفتار اجرا اعمال می‌کنند. این امر حاکمیت را از یک بررسی پس‌رویدادی (Retrospective) به یک اجرای عملیاتی تبدیل می‌کند:

• تأمین: اگر سیاست سازمان تأیید مدیر را برای awarding تامین‌کننده لازم می‌داند، جریان کار پیش از وقوع آن اقدام متوقف می‌شود.
• محدودیت داده‌ها: محدودیت‌های خاص هر مستاجر تعیین می‌کند عامل به کدام ابزارها و اطلاعات دسترسی داشته باشد.
• سقف‌های مالی: اگر تراکنشی از حد اختیارات تفویض‌شده فراتر رود، عامل به‌جای اجرا، باید مورد را ارجاع (Escalate) دهد.

مدیریت پرامپت‌ها نیز از رشته‌های کدگذاری‌شده (Hard-coded) به دارایی‌های کنترل‌شده تبدیل شده است. دستورالعمل‌ها نسخه‌بندی، تست، تایید، به محیط عملیاتی منتقل و در صورت نیاز بازگردانی (Rollback) می‌شوند. اگر رفتار عامل تغییر کند — مثلاً تعداد پرونده‌های ارجاعی را افزایش دهد — تیم‌ها می‌توانند با استفاده از اتصال بین مدیریت دستورالعمل و ARMS تعیین کنند که کدام نسخه از دستورالعمل، کدام مدل و کدام ابزارها در زمان اجرا فعال بوده‌اند.

ضرورت حضور انسان در چرخه

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

مدل elsai نقاط توقفی (Interruption Points) را پشتیبانی می‌کند که در آن جریان کار متوقف شده، تصمیم را به کاربر ارائه می‌دهد و تنها پس از تایید یا رد، از سر گرفته می‌شود. این رویکرد به‌طور اساسی با بررسی خروجی پس از آنکه عامل عمل خود را انجام داده است، متفاوت است.

• برای ارائه‌دهندگان BPO: این سیستم به اپراتورها اجازه می‌دهد تا فقط روی استثناها و تصمیمات باارزش تمرکز کنند.
• برای شرکت‌های SaaS: ساختارهای تایید موجود مشتریان حفظ می‌شود.
• برای سازمان‌ها: تضمین می‌شود که معرفی عامل‌ها باعث حذف مسئولیت‌پذیری (Accountability) تثبیت‌شده نمی‌شود.

این رویکرد یکپارچه، ابزارهایی مثل Agentkit، MCP، Instructions Manager، Guardrails، تأیید انسانی و ARMS را به یک زیربنای واحد تبدیل می‌کند. این امر به سازمان‌ها اجازه می‌دهد بدون جایگزینی سیستم‌های قدیمی (Legacy)، عامل‌ها را در چندین جریان کاری مستقر کنند. در واقع، این زیرساخت به سازمان‌ها کمک می‌کند تا با حذف وابستگی به روش‌های ناپایدار استخراج داده، ارتباطی مستقیم و استاندارد با داده‌های سازمانی برقرار کنند.

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

گام بعدی شما

برای پیاده‌سازی این مدل، ابتدا با بازبینی مجوزهای فعلی APIهای خود شروع کنید و شناسایی کنید کدام اقدامات «نوشتن» (Write) به یک نقطه توقف اجباری برای تأیید انسانی نیاز دارند.

• به‌جای دادن دسترسی مستقیم به دیتابیس، توابع محدود و تاییدشده‌ای را برای عامل‌ها تعریف کنید.
• سیستمی برای ردیابی هزینه هر جریان کاری (Workflow) به‌جای ردیابی کلی توکن‌ها طراحی کنید.

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