وقتی یک مدل هوش مصنوعی صرفاً به سؤال پاسخ می‌دهد، مهم‌ترین نگرانی معمولاً کیفیت پاسخ است. اما زمانی که همان مدل اجازه پیدا می‌کند فایل پروژه را باز کند، ایمیل بخواند، رکورد CRM را تغییر دهد، در نرم‌افزار مدیریت پروژه تسک بسازد یا صفحه‌ای از سایت شرکت را ویرایش کند، مسئله کاملاً متفاوت می‌شود. از این نقطه به بعد دیگر فقط با یک ابزار تولید متن روبه‌رو نیستیم؛ با نرم‌افزاری مواجهیم که می‌تواند در محیط واقعی شرکت اقدام انجام دهد.
این موضوع در سال ۲۰۲۶ از یک بحث نظری فاصله گرفته است. Reuters در ۲ سپتامبر گزارش داد OpenAI در حال توسعه قابلیت‌های توقف خودکار برای برخی سیستم‌های AI است و هم‌زمان روی نظارت دقیق‌تر بر اقداماتی که سیستم‌ها برای انجام وظیفه انجام می‌دهند و سخت‌تر کردن دسترسی اینترنت در تست‌های ایمنی کار می‌کند. در سطح محصولات سازمانی نیز Salesforce Headless 360 قابلیت‌های پلتفرم را از طریق API، MCP و CLI در اختیار ایجنت‌ها قرار می‌دهد و بر کنترل، مشاهده‌پذیری، قواعد دسترسی و human-in-the-loop تأکید می‌کند. اگر هنوز تفاوت ایجنت هوش مصنوعی اختصاصی با ابزارهای عمومی AI برایتان روشن نیست، ابتدا مقاله قبلی همتاکد را بخوانید.
اتصال امن ایجنت هوش مصنوعی به نرم‌افزارهای شرکت یعنی ایجنت فقط به داده‌ها و ابزارهایی دسترسی داشته باشد که برای وظیفه مشخص خود نیاز دارد و اقدامات حساس را بدون کنترل انجام ندهد. MCP می‌تواند ارتباط استاندارد میان ایجنت و سرویس‌هایی مانند فایل‌ها، CRM یا ابزارهای وب فراهم کند، اما امنیت واقعی به احراز هویت، حداقل دسترسی، محدودسازی ابزار، ثبت رخداد، کنترل شبکه و تأیید انسانی وابسته است.
تفاوت اساسی میان یک اتصال معمولی و اتصال امن در این است که در حالت دوم، اختیار ایجنت از قبل تعریف می‌شود. مثلاً اگر هدف، بررسی صورت‌جلسات پروژه و استخراج تعهدات باشد، ایجنت لزوماً نباید اجازه حذف فایل، تغییر قرارداد یا ارسال ایمیل از حساب مدیرعامل را داشته باشد. اگر وظیفه ساخت پیش‌نویس نامه است، دسترسی به دکمه «ارسال نهایی» یک قابلیت اضافی و پرریسک است، نه بخشی ضروری از همان وظیفه.
MCP یا Model Context Protocol را می‌توان به‌صورت ساده یک «زبان مشترک برای معرفی ابزارها و داده‌ها به ایجنت» تصور کرد. همان‌طور که یک استاندارد مشترک می‌تواند اتصال تجهیزات مختلف را آسان‌تر کند، MCP نیز تلاش می‌کند روش ارتباط برنامه‌های هوش مصنوعی با منابع بیرونی را استاندارد کند.
Google Cloud توضیح می‌دهد که MCP برای ارتباط دوطرفه میان برنامه‌های مبتنی بر مدل زبانی و ابزارها، داده‌ها و سرویس‌های خارجی طراحی شده است. برخلاف RAG که معمولاً روی بازیابی اطلاعات برای بهتر شدن پاسخ تمرکز دارد، MCP می‌تواند امکان فراخوانی ابزار و انجام اقدام در سیستم‌های بیرونی را نیز فراهم کند.
Google Cloud نیز صراحتاً توضیح می‌دهد که MCP با وجود افزایش قابلیت مدل‌ها، ملاحظات امنیتی مهمی ایجاد می‌کند؛ زیرا ابزارهای متصل می‌توانند به داده دسترسی پیدا کنند یا حتی کد و عملیات اجرایی انجام دهند. کنترل رضایت کاربر، دسترسی داده، ایمنی ابزار، پایش و ممیزی همچنان ضروری است.
بنابراین MCP را نباید مترادف امنیت دانست. MCP روش اتصال است؛ امنیت نتیجه معماری‌ای است که پیرامون آن طراحی می‌کنید.
یک معماری مناسب معمولاً به‌جای یک دیوار امنیتی واحد، چند لایه مستقل دارد. اگر یک لایه اشتباه کند، لایه بعدی باید بتواند دامنه اثر را محدود کند.
اولین اصل این است که ایجنت نباید با حساب شخصی مدیر یا Administrator عمومی سیستم کار کند. بهتر است برای آن هویت یا Service Account مشخصی تعریف شود تا معلوم باشد کدام اقدامات توسط ایجنت انجام شده و چه مجوزهایی به آن اختصاص یافته است.
در اتصال‌هایی که از OAuth استفاده می‌کنند نیز Scope اهمیت زیادی دارد. مستندات OpenAI برای MCP و Connectors توضیح می‌دهد ابزارهایی که در دسترس قرار می‌گیرند به Scopeهای توکن OAuth وابسته‌اند. این یعنی اگر ایجنت فقط باید ایمیل‌ها را جست‌وجو کند، اعطای مجوزهایی فراتر از همان نیاز باید توجیه مشخص داشته باشد.
قاعده مدیریتی ساده است: ایجنت باید کمترین دسترسی لازم برای انجام وظیفه تعریف‌شده را داشته باشد.
اگر گزارش هفتگی از وضعیت پروژه می‌سازد، دسترسی خواندن ممکن است کافی باشد. اگر قرار است پیش‌نویس تسک ایجاد کند، اجازه نوشتن باید به محدوده مشخصی محدود شود. اگر برای انجام وظیفه نیازی به اطلاعات مالی، پوشه منابع انسانی یا CRM کل شرکت ندارد، این منابع نباید اصلاً در Context یا مجموعه ابزارهای آن ظاهر شوند.
وجود یک MCP Server با ده‌ها ابزار به این معنی نیست که همه آن ابزارها باید در اختیار مدل باشند. مستندات OpenAI امکان محدود کردن ابزارهای در دسترس از طریق allowed_tools را مطرح می‌کند و برای اقدامات حساس نیز توصیه می‌کند جریان approval در نظر گرفته شود.
یکی از اشتباهات رایج این است که اولین نسخه ایجنت مستقیماً به محیط Production متصل شود. پایلوت باید تا جای ممکن در محیط آزمایشی، دیتای نمونه، حساب تست یا محدوده‌ای از داده واقعی که اثر عملی محدودی دارد اجرا شود.
اگر وظیفه ایجنت با چند سرویس مشخص انجام می‌شود، دلیلی ندارد دسترسی نامحدود به تمام اینترنت داشته باشد. OpenAI در توضیح شیوه اجرای امن Codex اعلام کرده که دسترسی خروجی نامحدود را در اختیار آن قرار نمی‌دهد و از سیاست شبکه برای اجازه دادن به مقصدهای مورد انتظار، مسدودسازی مقصدهای نامطلوب و درخواست تأیید برای دامنه‌های ناشناخته استفاده می‌کند.
برای یک شرکت نیز همین منطق قابل استفاده است: دامنه‌ها، APIها و مقصدهای مجاز باید از پیش تعیین شوند و خروج اطلاعات به سرویس ناشناخته یک رفتار عادی تلقی نشود.
کلید API، رمز عبور، OAuth Token یا اطلاعات اتصال دیتابیس نباید در متن دستورهای ایجنت، فایل‌های عمومی پروژه یا Promptهای قابل مشاهده نگهداری شود. این اطلاعات باید در Secret Manager، Keyring یا سازوکار امن مشابه ذخیره شوند و تنها هنگام اجرای ابزار در اختیار لایه لازم قرار گیرند.
برای مدیر غیر‌فنی، یکی از مفیدترین روش‌ها این است که اختیار ایجنت را به چهار سطح عملی تقسیم کند. این چهار سطح به تصمیم‌گیری درباره هر ابزار کمک می‌کند.
| سطح دسترسی | ایجنت چه کاری می‌کند؟ | مثال در شرکت | کنترل پیشنهادی |
|---|---|---|---|
| خواندن | اطلاعات موجود را مشاهده و تحلیل می‌کند، بدون تغییر سیستم | خواندن صورت‌جلسه، مشاهده رکورد CRM، بررسی ایمیل دریافتی | Scope فقط‌خواندنی، محدودیت پوشه و پروژه، ثبت دسترسی |
| پیشنهاد دادن | خروجی یا اقدام پیشنهادی می‌سازد اما چیزی در سیستم تغییر نمی‌دهد | پیشنهاد پاسخ به مشتری، پیشنهاد تغییر برنامه پروژه، پیشنهاد اصلاح صفحه سایت | نمایش منبع، بازبینی کاربر، بدون Write Permission |
| ایجاد پیش‌نویس | یک شیء قابل بازبینی ایجاد می‌کند اما آن را نهایی نمی‌کند | Draft ایمیل، Draft صفحه WordPress، تسک پیشنهادی با وضعیت Draft | Write محدود، محیط staging یا وضعیت Draft، ثبت نسخه |
| اجرای نهایی | اقدامی با اثر واقعی انجام می‌دهد | ارسال ایمیل، تغییر وضعیت قرارداد، انتشار صفحه، حذف فایل | تأیید انسانی، کنترل نقش، لاگ کامل، قابلیت لغو یا Rollback |
این ماتریس یک نکته مهم را روشن می‌کند: «اتوماسیون» الزاماً به معنی سپردن آخرین مرحله به AI نیست. در بسیاری از فرایندهای حرفه‌ای، بیشترین صرفه‌جویی زمانی در سه سطح اول اتفاق می‌افتد. ایجنت می‌تواند اسناد را بخواند، اطلاعات را مرتب کند و پیش‌نویس تقریباً نهایی بسازد، در حالی که مسئولیت تصمیم بیرونی همچنان با انسان باقی می‌ماند.
Human-in-the-loop به این معنی نیست که کارمند مجبور باشد هر کلیک کوچک ایجنت را تأیید کند. اگر طراحی به این شکل باشد، مزیت اتوماسیون از بین می‌رود. هدف این است که مرز میان اقدامات کم‌ریسک و اقدامات دارای پیامد واقعی مشخص شود.
برای مثال، جست‌وجوی یک فایل در پوشه پروژه یا استخراج تاریخ از قرارداد می‌تواند بدون وقفه انجام شود. ساخت یک پیش‌نویس نامه نیز معمولاً ریسک محدودی دارد. اما «ارسال نامه به کارفرما» وضعیت متفاوتی دارد، زیرا یک اقدام بیرونی و قابل استناد است. تغییر مبلغ قرارداد، حذف سند، پرداخت، انتشار محتوا یا تغییر Permission کاربران نیز باید در گروه اقدامات حساس قرار گیرد.
Prompt Injection فقط مسئله‌ای مربوط به «کاربری که دستور بد می‌دهد» نیست. یک ایجنت سازمانی ممکن است ایمیل، فایل PDF، صفحه وب یا اطلاعات دریافتی از سیستم خارجی را بخواند. داخل همین محتوا می‌تواند متنی وجود داشته باشد که تلاش کند رفتار مدل را تغییر دهد؛ مثلاً از ایجنت بخواهد دستور اصلی را نادیده بگیرد یا اطلاعاتی را به مقصد دیگری ارسال کند.
OpenAI در مستندات MCP و Connectors صراحتاً prompt injection را زمانی که مدل به ابزارهای دارای داده حساس یا قابلیت انجام اقدام متصل است، یک ملاحظه امنیتی مهم معرفی می‌کند. همین مستندات توصیه می‌کنند اتصال به سرورهای مورد اعتماد انجام شود، ورودی و خروجی بررسی شود و اقدامات حساس پشت approval باقی بمانند.
دفاع مناسب یک دستور جادویی در Prompt نیست. باید چند لایه وجود داشته باشد: محتوای خارجی به‌عنوان «داده غیرقابل اعتماد» تلقی شود، ابزارهای قابل استفاده محدود باشند، داده حساس بدون ضرورت وارد Context نشود، مقصدهای شبکه allowlist شوند و مدل حتی در صورت فریب خوردن نتواند مستقیماً یک اقدام حساس خارج از Permission خود انجام دهد.
در یک سیستم سازمانی باید بتوان بعداً پاسخ داد: چه کسی درخواست را شروع کرد؟ ایجنت کدام ابزار را فراخواند؟ چه داده‌ای را خواند؟ چه پارامتری فرستاد؟ چه نتیجه‌ای دریافت کرد؟ کدام اقدام نیازمند تأیید بود؟ چه کسی آن را تأیید کرد؟ چه چیزی در سیستم تغییر کرد؟
OpenAI در توضیح استقرار داخلی Codex به ثبت رخدادهایی مانند درخواست کاربر، تصمیم approval، نتیجه اجرای ابزار، استفاده از MCP و تصمیم‌های allow/deny شبکه اشاره می‌کند. این نوع مشاهده‌پذیری برای هر ایجنتی که وارد فرایند واقعی سازمان می‌شود، الگوی مفیدی است.
فرض کنیم یک دفتر معماری هم‌زمان چند پروژه دارد. صورت‌جلسات، مکاتبات کارفرما، برنامه زمان‌بندی و فایل‌های پروژه در چند سیستم نگهداری می‌شوند. هدف این است که ایجنت بعد از دریافت اسناد جدید، تعهدات و موعدها را استخراج کند و به تیم پروژه برای پیگیری کمک کند.
ایجنت با هویت اختصاصی خود به پوشه همان پروژه دسترسی Read-Only دارد. پوشه مالی شرکت، اسناد منابع انسانی و پروژه‌های دیگر برای این هویت قابل مشاهده نیستند. اگر ایمیل نیز وارد فرایند شده، بهتر است دسترسی به صندوق یا Label مرتبط با پروژه محدود شود، نه کل تاریخچه ایمیل مدیر.
ایجنت صورت‌جلسه را می‌خواند و مواردی مثل مسئول هر اقدام، موعد تحویل، درخواست کارفرما و موارد نیازمند تصمیم را استخراج می‌کند. در این مرحله هنوز هیچ رکوردی در CRM یا نرم‌افزار مدیریت پروژه تغییر نکرده است.
مزیت این مرحله آن است که تیم می‌تواند دقت ایجنت را با هزینه و ریسک پایین ارزیابی کند. اگر استخراج اشتباه باشد، اثر آن به یک گزارش داخلی محدود می‌شود.
پس از اطمینان نسبی از کیفیت استخراج، ایجنت می‌تواند یک پیش‌نویس نامه برای کارفرما و چند تسک پیشنهادی برای تیم بسازد. اما نامه هنوز ارسال نشده و تسک‌ها نیز می‌توانند در وضعیت Draft یا Pending Approval قرار بگیرند.
مثلاً ایجنت می‌نویسد: «طبق صورت‌جلسه جلسه هماهنگی، ارسال نسخه اصلاح‌شده پلان تا سه‌شنبه بر عهده تیم طراحی است» و یک تسک متناسب پیشنهاد می‌دهد. مدیر پروژه منبع استنتاج را می‌بیند و می‌تواند متن یا موعد را اصلاح کند.
پس از تأیید مدیر پروژه، ابزار اجرایی فعال می‌شود: تسک در سیستم ثبت می‌شود یا ایمیل از حساب تعیین‌شده ارسال می‌شود. Approval باید همراه با اطلاعات دقیق اقدام باشد تا مدیر بداند چه چیزی در آستانه اجراست.
اگر تغییر مربوط به اطلاعات حساس‌تری مانند مبلغ قرارداد، وضعیت پرداخت، حذف سند یا تغییر دسترسی یک عضو تیم باشد، حتی در مراحل بلوغ بالاتر نیز می‌توان تأیید انسانی را دائمی نگه داشت.
این مدل باعث می‌شود کار اصلی ایجنت ــ خواندن حجم زیادی از اطلاعات، استخراج، تطبیق و آماده‌سازی ــ خودکار شود، بدون اینکه برای دستیابی به بهره‌وری، کنترل تصمیم‌های مهم سازمان کنار گذاشته شود.
اتصال ایجنت به وب‌سایت نمونه روشنی از تفاوت میان «کمک گرفتن» و «واگذاری اختیار انتشار» است. Elementor در Roadmap رسمی خود قابلیت Elementor MCP را با ETA سپتامبر ۲۰۲۶ قرار داده و توضیح داده است که ابزارهایی مانند Claude و Codex می‌توانند مستقیماً برای ایجاد و ویرایش صفحات به سایت Elementor متصل شوند. Roadmap همچنین قابلیت‌هایی برای یافتن، تغییر و ایجاد Theme Partها توسط AI نشان می‌دهد.
این Roadmap نشانه مهمی از جهت حرکت ابزارهای سایت‌ساز است، اما تا زمان انتشار و مستندات نهایی نباید درباره جزئیات Permission Model قابلیت آینده فرض کرد. از منظر معماری داخلی شرکت، سه سطح زیر باید مستقل دیده شوند:
پیش از اتصال ایجنت، زیرساخت فنی و معماری طراحی سایت باید مشخص باشد؛ در غیر این صورت، ایجنت فقط اجرای تغییرات بی‌قاعده را سریع‌تر می‌کند.
| مدل استفاده | اختیار ایجنت | ریسک | نقطه شروع پیشنهادی |
|---|---|---|---|
| پیشنهاد تغییر صفحه | متن، ساختار یا تغییر طراحی را پیشنهاد می‌دهد؛ هیچ چیز روی سایت نمی‌نویسد | پایین | بهترین نقطه شروع |
| ساخت پیش‌نویس | Page/Revision یا نسخه Staging می‌سازد اما منتشر نمی‌کند | متوسط و قابل‌کنترل | مناسب پس از تست اولیه |
| انتشار مستقیم | تغییر را مستقیماً روی سایت Production منتشر می‌کند | بالا | مناسب شروع پروژه نیست |
حتی در سطح پیشنهاد نیز ایجنت نباید خارج از قواعد طراحی UX/UI، دیزاین سیستم و تصمیم‌های تجربه کاربری موجود، ساختار صفحه را آزادانه تغییر دهد.
انتشار مستقیم از همان روز اول معمولاً ارزش تجاری اضافه‌ای متناسب با افزایش ریسک ایجاد نمی‌کند. یک اشتباه می‌تواند قیمت، متن حقوقی، فرم تماس، ساختار صفحه یا بخش قابل مشاهده برای مشتری را تغییر دهد. بنابراین ابتدا باید هویت محدود، Backup، Versioning، Staging، لاگ و جریان Approval عملیاتی شوند.
پیش از اتصال هر ایجنت به سیستم واقعی شرکت، پاسخ روشن به این موارد لازم است:
وجود پاسخ «بله» به همه این پرسش‌ها به معنی حذف کامل ریسک نیست، اما نشان می‌دهد اتصال از یک آزمایش ساده فراتر رفته و به یک سیستم قابل مدیریت نزدیک شده است.
به‌جای شروع با «ایجنت شرکت»، یک فرایند مشخص انتخاب کنید: استخراج تعهدات از صورت‌جلسه، خلاصه وضعیت پروژه، بررسی مکاتبات یک پروژه یا جمع‌آوری داده برای گزارش هفتگی.
دسترسی باید محدود به داده لازم باشد و ایجنت در این مرحله هیچ عملیات Write انجام ندهد. معیارهای کیفیت نیز از ابتدا مشخص شوند: آیا اطلاعات مهم را پیدا می‌کند؟ خطاهایش از چه نوع هستند؟ آیا اطلاعات نامرتبط وارد پاسخ می‌شوند؟
پس از ارزیابی مرحله اول، اجازه ساخت خروجی قابل ویرایش داده شود؛ مانند Draft ایمیل، پیش‌نویس گزارش، Draft تسک یا نسخه Staging صفحه سایت. این مرحله معمولاً نقطه‌ای است که ارزش اقتصادی سیستم به‌وضوح قابل اندازه‌گیری می‌شود، زیرا زمان آماده‌سازی کاهش می‌یابد اما ریسک اجرای خودکار هنوز محدود است.
در این مرحله تنها عملیات مشخصی که قبلاً آزمایش شده‌اند اجازه اثرگذاری روی سیستم واقعی پیدا می‌کنند. هر درخواست باید قبل از اجرا به فرد مسئول نشان داده شود و لاگ مشخص کند چه کسی آن را تأیید کرده است.
اینجا زمان مناسبی برای آزمایش سناریوهای غیرعادی نیز هست: فایل ناقص، اطلاعات متناقض، درخواست خارج از Scope، محتوای مشکوک و تلاش برای استفاده از ابزار غیرمجاز.
پس از جمع‌آوری شواهد کافی می‌توان برخی اقدامات تکراری و کم‌ریسک را از Approval دائمی خارج کرد. این تصمیم باید بر اساس لاگ و تجربه عملی باشد، نه صرفاً تصور اینکه «مدل دقیق است».
در مقابل، عملیات پرپیامد مانند پرداخت، حذف اطلاعات، تغییر سطح دسترسی، انتشار محتوای حساس، تغییر داده قراردادی یا ارسال رسمی به مشتری می‌توانند حتی در سیستم بالغ نیز تحت تأیید انسانی باقی بمانند.
برای شروع، لازم نیست ایمیل، CRM، فایل‌ها، سایت و نرم‌افزار مدیریت پروژه هم‌زمان به یک ایجنت متصل شوند. نقطه شروع بهتر، انتخاب یک فرایند واقعی و پرتکرار است که ورودی و خروجی مشخص دارد؛ مثلاً تبدیل صورت‌جلسه پروژه به مجموعه اقدامات، تهیه Draft مکاتبات یا آماده‌سازی تغییرات سایت در محیط آزمایشی.
فرایند طراحی ایجنت اختصاصی و اتوماسیون باید با ارزیابی مسیر داده، سطح دسترسی، نقاط تأیید انسانی و ابزارهای مجاز آغاز شود. سپس می‌توان یک پایلوت محدود طراحی کرد تا پیش از گسترش دسترسی، ارزش و ریسک آن روی یک فرایند واقعی سنجیده شود.
اگر هدف شما بررسی چنین سناریویی برای شرکت است، می‌توانید از طریق صفحه تماس با همتاکد فرایند موردنظر را برای ارزیابی اولیه و طراحی پایلوت محدود مطرح کنید.
حرکت بازار به سمت ایجنت‌هایی است که فقط پاسخ نمی‌دهند، بلکه به ابزارهای واقعی سازمان متصل می‌شوند. Elementor اتصال AI به محیط ساخت صفحات را در Roadmap خود قرار داده و Salesforce داده، Workflow و قابلیت‌های سازمانی را از طریق API، MCP و CLI در اختیار ایجنت‌ها می‌گذارد. در سوی دیگر، تمرکز فزاینده روی محدودسازی شبکه، نظارت بر ابزار، توقف سیستم و ثبت رفتار نشان می‌دهد که «قدرت انجام کار» باید همراه با «قدرت کنترل» توسعه پیدا کند.
برای اکثر شرکت‌ها، راه درست از دسترسی کامل شروع نمی‌شود. مسیر منطقی از Read-Only آغاز می‌شود، به پیشنهاد و Draft می‌رسد، سپس اقدامات مشخص پشت تأیید انسانی فعال می‌شوند و فقط بعد از مشاهده کافی، بخش کوچکی از عملیات کم‌ریسک می‌تواند خودکار شود.
MCP می‌تواند اتصال را ساده‌تر و استانداردتر کند، اما خودش تضمین امنیت نیست. امنیت واقعی از حداقل دسترسی، هویت مستقل، allowlist ابزار، محیط آزمایشی، کنترل شبکه، مدیریت اسرار، مقابله با prompt injection، لاگ قابل ممیزی و Human-in-the-loop ساخته می‌شود.
MCP یک استاندارد برای ارتباط برنامه‌های AI با ابزارها و منابع داده است و نباید آن را به‌تنهایی یک مکانیزم امنیتی دانست. امنیت اتصال به نحوه احراز هویت، Scope دسترسی، ابزارهای مجاز، کنترل داده، محدودیت شبکه، ثبت رخداد و Approval بستگی دارد. Google Cloud نیز در توضیح MCP تأکید می‌کند که اتصال به ابزارهای خارجی ملاحظات امنیتی خاص خود را ایجاد می‌کند.
بله، از نظر فنی می‌توان ایجنت را از طریق Connector، API یا MCP به سرویس ایمیل متصل کرد، اما مجوز باید متناسب با وظیفه باشد. برای سناریوی خلاصه‌سازی یا جست‌وجو معمولاً بهتر است از دسترسی خواندن و محدوده مشخص شروع شود و قابلیت ارسال ایمیل به‌صورت مستقل فعال نشود.
دسترسی خواندن فقط اجازه مشاهده داده موجود را می‌دهد. در سطح پیشنهاد، ایجنت نتیجه را خارج از سیستم عملیاتی ارائه می‌کند. در سطح Draft، اجازه ایجاد یک شیء قابل بازبینی مانند Draft ایمیل، Revision سایت یا تسک Pending داده می‌شود. اجرای نهایی زمانی است که تغییر واقعی و بیرونی اتفاق می‌افتد و ریسک بالاتری دارد.
هر اقدامی که پیامد مالی، قراردادی، حقوقی، ارتباط با مشتری، حذف اطلاعات، تغییر Permission یا انتشار عمومی دارد، کاندید جدی تأیید انسانی است. اقدامات کم‌ریسک و قابل برگشت را می‌توان پس از تست و مشاهده کافی با اصطکاک کمتری اجرا کرد.
ایجنت ممکن است محتوای یک ایمیل، فایل یا صفحه وب را بخواند که درون آن دستور مخرب یا گمراه‌کننده قرار گرفته است. اگر ایجنت هم‌زمان ابزار قدرتمندی در اختیار داشته باشد، چنین محتوایی می‌تواند تلاش کند رفتار آن را تغییر دهد. محدودسازی Permission و ابزارها، بررسی ورودی و خروجی و Approval اقدامات حساس، دامنه اثر چنین حمله‌ای را کاهش می‌دهد.
برای شروع خیر. مدل کم‌ریسک‌تر این است که ابتدا فقط تغییر پیشنهاد شود و در مرحله بعد ایجنت اجازه ساخت Draft یا Revision در Staging داشته باشد. انتشار مستقیم Production بهتر است تنها پس از تثبیت Permission، Backup، Logging، Versioning و Approval بررسی شود.
یک فرایند پرتکرار، مشخص و کم‌ریسک انتخاب کنید؛ برای مثال خواندن صورت‌جلسات یک پروژه، استخراج مسئولیت‌ها و موعدها و ساخت Draft تسک یا نامه. ابتدا Read-Only را آزمایش کنید و فقط پس از مشاهده کیفیت، مجوزهای نوشتن محدود را اضافه کنید.
اشتراک این مطلب برای دوستان خود
