امنیت Agentic AI از یک سؤال شروع میشود: عامل اجازه دارد چه کاری انجام دهد؟
وقتی agentها از چت وارد مرورگر، ایمیل، ابزار کدنویسی و سیستمهای کسبوکار میشوند، طراحی permission به معماری امنیتی جدید تبدیل میشود.
دبیر محصول و شهر هوشمند
چرا الان مهم است
امنیت permission در Agentic AI دیگر موضوعی مخصوص چند متخصص نیست؛ به یک سؤال عملیاتی برای مدیریت محصول و کسبوکار تبدیل شده است. OWASP و تیمهای امنیتی حالا سیستمهای agentic را یک حوزه ریسک جدا میبینند، چون عاملها میتوانند برنامهریزی کنند، ابزار صدا بزنند، مرور کنند، کد بنویسند و با اختیار واگذارشده عمل کنند. معنیاش این نیست که همه باید وحشت کنند، اما یعنی فرض قدیمی که «زیرساخت خودش درست میشود» دیگر کافی نیست.
اهمیت ماجرا از اینجاست که agent دقیقاً چون میتواند عمل کند مفید است، اما همان مسیر عمل میتواند داده جابهجا کند، پیام بفرستد، هزینه بسازد یا رکورد مهمی را تغییر دهد. تیمهای محصول معمولاً این را دیر میفهمند. جلسه لانچ درباره فیچر، قیمت و رشد حرف میزند، اما محدودیت واقعی ممکن است در permission، بازیابی حساب، برق، certificate، vendor یا پشتیبانی پنهان باشد.
برای تیمهای محصول AI، امنیت، IT و مدیرانی که pilot عاملها را تایید میکنند تغییر اصلی ساده است: تصمیم فنی حالا تبدیل به وعده قابل لمس به کاربر میشود. ورود امن یعنی بازیابی قابل فهم. عامل AI یعنی اختیار محدود. دیتاسنتر یعنی برق و سرمایش قابل اتکا. رمزنگاری یعنی محرمانگی امروز و فردا.
برای تیمهای فارسیزبان، خطر معمولاً از پروژههای کوچک شروع میشود: agent به ایمیل، پنل فروش، فایلهای شرکت یا ابزار اتوماسیون وصل میشود، قبل از اینکه نقش و مرز آن نوشته شده باشد. به همین دلیل این موضوع فقط یک خبر تکنولوژی نیست. روی بودجه، زمان تحویل، متن پشتیبانی، قرارداد خرید و نحوه توضیح ریسک به مشتری اثر میگذارد.
مقالههای مرتبط
دیتاسنترهای هوش مصنوعی به گلوگاه تازه رسیدهاند: برق، خنکسازی و اعتماد محلی
واقعیت محصول پشت تیتر خبر
اولین واقعیت این است که تکنولوژی انتزاعی فقط وقتی دردناک میشود که به workflow واقعی برسد. تا وقتی همهچیز کار میکند کسی سراغ معماری نمیرود. مشکل وقتی شروع میشود که حساب برنگردد، مدل scale نشود، agent کار اشتباه انجام دهد یا vendor جواب امنیتی روشن نداشته باشد.
واقعیت دوم وابستگی است. محصول دیجیتال امروز روی regionهای cloud، provider هویت، مدل AI، مرورگر، API، certificate، موبایل و تیم پشتیبانی سوار است. یک فیچر ساده روی صفحه ممکن است زنجیرهای پیچیده زیر خود داشته باشد.
واقعیت سوم اعتماد است. کاربر محدودیت روشن را راحتتر از شکست مبهم میپذیرد. اگر محصول بگوید چه چیزی مجاز است، چه چیزی مسدود میشود، بازیابی چطور انجام میشود و مسئول کیست، حس طراحیشده بودن میدهد. اگر این جوابها بعد از incident پیدا شوند، محصول بداهه به نظر میرسد.
برای همین باید قبل از اتصال به حساب واقعی باید ابزارها، scope، سطح تایید، audit log، قوانین memory و kill switch تعریف شود. این کاغذبازی نیست؛ راه تبدیل ابهام به مدل عملیاتی قابل مدیریت است.
برنامه عملی ۹۰ روزه
در ۳۰ روز اول سطح تماس را نقشهبرداری کنید. بنویسید موضوع کجا به کاربر، ابزار داخلی، داده، vendor، زیرساخت، پشتیبانی و compliance وصل میشود. هدف اسلاید زیبا نیست؛ هدف inventory مشترکی است که حتی آدمهای نگران هم بگویند دقیق است.
از روز ۳۱ تا ۶۰ control point تعریف کنید. کدام تغییر review میخواهد؟ کدام مسیر کاربر fallback لازم دارد؟ کدام vendor باید جواب مکتوب بدهد؟ چه اتفاقی rollback را فعال میکند؟ چه logی قبل از لانچ باید وجود داشته باشد؟
از روز ۶۱ تا ۹۰ failure rehearsal اجرا کنید. گم شدن دستگاه، مسدود شدن region، tool injection، تاخیر vendor، وابستگی certificate یا کمبود ظرفیت را شبیهسازی کنید. هدف ترساندن تیم نیست؛ هدف ساختن حافظه عملیاتی است.
در پایان این چرخه، سازمان باید بداند مالک چیست، به چه چیزی وابسته است، چه چیزی را میتواند برگرداند و چه چیزی را باید برای کاربر توضیح دهد. همین شفافیت یک trend بزرگ را به roadmap قابل اجرا تبدیل میکند.
مزیت پایدار از کجا میآید
مزیت پایدار معمولاً شبیه پرصداترین لانچ نیست. شبیه تیمی است که میتواند منتشر کند، ببیند، توضیح بدهد، بازیابی کند و بهتر شود بدون اینکه همه اطراف محصول را فرسوده کند.
مشتریها بیشتر از قبل evidence میخرند، نه فقط قابلیت. میخواهند بدانند تصمیمها چطور log میشوند، vendor چطور ارزیابی شده، بازیابی چطور کار میکند، هزینه چطور کنترل میشود و شرکت وقتی سیستم به مرز میرسد چه رفتاری دارد.
سؤال مدیریتی ساده است: اگر فرض اصلی تغییر کند، شرکت هنوز میتواند وعدهاش را نگه دارد؟ اگر جواب وابسته به قهرمانی پنهان چند نفر است، سیستم بالغ نیست. اگر وابسته به کنترلهای مستند است، محصول در حال تبدیل شدن به زیرساخت واقعی است.
امنترین agent ضعیفترین agent نیست؛ agentی است که اختیارش قابل دیدن، محدود و قابل بازیابی باشد.
“خبر خوب، خبری است که کاربر بعد از خواندن آن تصمیم بهتری بگیرد.”
درباره نویسنده
ندا رحیمی
دبیر محصول و شهر هوشمند
ندا درباره اینترنت اشیا، شهر هوشمند، تجربه کاربر، داده شهری و مسیر اجرای فناوری در سازمانهای ایرانی مینویسد.
