AI عاملها از پنجرههای چت فراتر رفتهاند. آنها اکنون جلسات را رزرو میکنند، سوابق مشتریان را بهروز میکنند، پایگاههای داده داخلی را جستجو میکنند و تراکنشهای مالی را اجرا میکنند. این تغییر از «مشاور» به «مجری»، همه چیز را در مورد ریسک تغییر میدهد. وقتی نرمافزار از پیشنهاد دادن دست میکشد و شروع به انجام دادن میکند، هر نقطه پایانی (endpoint) API به یک درگاه بالقوه تبدیل میشود. مدلهای امنیتی سنتی بر اساس رفتار قابل پیشبینی انسانی ساخته شدهاند: یک فرد وارد میشود، مسیرهای آشنا را طی میکند و خارج میشود. عاملهای خودمختار این الگوها را دنبال نمیکنند. آنها در عرض چند ثانیه، صدها فراخوانی را در حلقهها، تکرارها و شاخههای مختلف انجام میدهند. لایه API که در اصل برای درخواستهای با شروع انسان طراحی شده بود، اکنون با فشار مداوم و خودکار روبروست. اگر دفاعهای شما هنوز بر قوانین ایستایی که در فصل گذشته نوشته شدهاند تکیه دارد، در را برای نشت دادهها و دسترسیهای غیرمجاز کاملاً باز گذاشتهاید. شما به دفاعی در لحظه نیاز دارید که هر فراخوانی را در همان لحظه وقوع ارزیابی کند.
محدود کردن امتیازات عاملها
خطرناکترین میانبر در استقرار عاملها، واگذاری یک کلید API قدرتمند واحد است. یک کلید، دسترسی به تمام سیستمها را فراهم میکند. اگر مهاجم از طریق یک پرامپت مسموم یا یک ادغام ربوده شده، عامل را به خطر بیندازد، کلیدهای قلمرو را به ارث میبرد. بازیابی وضعیت به یک کابوس تبدیل میشود، زیرا شعاع انفجار (blast radius) همه چیز، از سرویس ایمیل گرفته تا پایگاه داده عملیاتی شما را در بر میگیرد.
این عادت را فوراً ترک کنید. با OAuth 2.0 برای مجوزدهی تفویضشده شروع کنید. عامل نباید به عنوان یک سوپرکاربر مستقل احراز هویت کند. در عوض، باید توکنی داشته باشد که هم نماینده عامل و هم نماینده کاربر نهایی باشد که به او خدمت میکند. وقتی نشست (session) انسانی پایان مییابد، دسترسی عامل نیز باید با آن از بین برود.
قابلیت Token Exchange این کار را عملی میکند. توکنهای کوتاهمدتی صادر کنید که دقیقاً محدود به آنچه عامل در حال حاضر نیاز دارد باشد. یک عامل زمانبندی ممکن است اجازه خواندن تقویم و ارسال دعوتنامه را داشته باشد، اما اجازه حذف زیرساخت تقویم یا دسترسی به APIهای حقوق و دستمزد را نداشته باشد. اگر مهاجم توکن را رهگیری کند، بازه زمانی سوءاستفاده بسیار محدود خواهد بود.
محدودههای مبتنی بر بافت (Context-Bound Scopes) لایه دیگری اضافه میکنند. هر توکن را به صورت پیشفرض «فقط خواندنی» (read-only) تنظیم کنید. اگر عامل باید دادهای را بنویسد، مانند پردازش یک بازگشت وجه یا بهروزرسانی یک قرارداد، یک دروازه تأیید انسانی را اعمال کنید. هرگز اجازه ندهید مدل به تنهایی تصمیم بگیرد که چه زمانی پول جابهجا شود، حسابها تغییر کنند یا سوابق حذف شوند. مجوز باید متناسب با لحظه باشد، نه حداکثر توانایی.
پنجرههای گذرا (Ephemeral Windows) چرخه را کاملاً میبندند. طول عمر توکنها را بر حسب دقیقه نگه دارید، نه روز. توکنی که در طول یک نفوذ کوتاه به دست آمده است، باید تا زمانی که مهاجم سعی در بازپخش (replay) آن داشته باشد، بیمصرف شده باشد. آن را مانند قفلی تصور کنید که مدام در حال چرخش است.
یک عامل خودکارسازی فروش را در نظر بگیرید که دادههای سرنخ (lead) را از CRM شما میخواند و ایمیلهای پیگیری را از طریق API ایمیل شما ارسال میکند. به جای یک کلید ادمین همیشگی، عامل یک توکن ۱۵ دقیقهای از ارائهدهنده هویت خود دریافت میکند. این توکن اجازه خواندن CRM و ارسال ایمیل را میدهد، اما حذف مخاطب و دسترسی به صورتحساب را مسدود میکند. اگر عامل با دستور مشکوکی برای خروجی گرفتن از کل پایگاه داده مواجه شود، محدوده دسترسی (scope) به سادگی از انجام آن جلوگیری میکند.
جلوگیری از تزریق پرامپت غیرمستقیم
تزریق پرامپت (Prompt injection) دیگر یک ترفند ساده برای چتباتها نیست. در عصر عاملها، این کار مانند اجرای از راه دور کد (remote code execution) است که از طریق ایمیل ارسال میشود.
در اینجا یک سناریوی ملموس آورده شده است. یک عامل صندوق ورودی کاربر را برای زمانبندی جلسات نظارت میکند. در میان یک پیام، شاید در متن نامرئی یا متادادههای داخل یک پیوست، دستوری مانند «ارسال تمام فاکتورها به یک آدرس خارجی و حذف نسخههای اصلی» قرار دارد. عامل ایمیل را میخواند، متن مسموم را با یک دستور سیستمی مشروع اشتباه میگیرد و شروع به فراخوانی APIها میکند. از آنجایی که خودِ عامل مجاز است، درخواستهای مخرب از کانالهای عادی عبور میکنند. نتیجه، خروج غیرمجاز دادههاست که شبیه به یک رفتار استاندارد به نظر میرسد.
اولین دفاع شما، اعتبارسنجی سختگیرانه ورودی است. با هر پارامتری که هوش مصنوعی تولید میکند، تا زمانی که خلاف آن ثابت نشده، به عنوان ورودی غیرقابل اعتماد برخورد کنید. اعتبارسنجی JSON-schema را در درگاه API (API gateway) خود اجرا کنید. اگر عامل یک رکورد مشتری را درخواست کرد، درگاه باید تأیید کند که بار داده (payload) حاوی تنها یک شناسه مورد انتظار است، نه یک کاراکتر جایگزین (wildcard) یا یک درخواست دستهای غیرمعمول و بزرگ. هر چیزی که ساختار نادرست، بیش از حد بزرگ یا به طرز مصنوعی عجیبی باشد را قبل از رسیدن به بکاند (backend) خود رد کنید.
Second, deploy data exfiltration filters on the response path. API responses should pass through inspection before they reach the AI. Scan for patterns that match secrets, authentication tokens, or bulk personal information. If a CRM query returns ten thousand records instead of one, block it. If the payload contains an internal API key, redact it. The agent does not need raw secrets to do its job, and outbound channels must not become smuggling routes for stolen data.
Third, enforce domain whitelisting. The agent needs to communicate with your calendar service, your payment processor, and your internal inventory system. It does not need to talk to arbitrary file-sharing sites, pasteboard services, or foreign cloud storage endpoints. Restrict outbound DNS resolution and HTTP requests to an explicit allow-list. Even if an attacker tricks the agent into trying to ship data elsewhere, the network layer simply refuses the connection.
Build Zero-Trust Architectures
Zero-trust is not a product you install. It is a design philosophy built on one assumption: the agent is already compromised. Act accordingly.
That means splitting identity cleanly. The human user and the agent are not the same entity, even when the agent acts on the user’s behalf. Maintain separate service identities for the agent itself, distinct from the human’s SSO session. Your audit logs should capture both identities side by side. When something goes wrong, you