AI Agent Security چیست؟ امنیت عامل‌های هوش مصنوعی، ابزارها و دسترسی‌های خودکار

پاسخ کوتاه: AI Agent Security یا امنیت عامل‌های هوش مصنوعی مجموعه‌ای از اصول، کنترل‌ها و روش‌های دفاعی برای محافظت از Agentهایی است که می‌توانند فراتر از تولید متن عمل کنند؛ یعنی تصمیم بگیرند، اطلاعات بازیابی کنند، از حافظه استفاده کنند، Tool و API فراخوانی کنند و روی سیستم‌های واقعی عملیات انجام دهند. امنیت AI Agent بر محدودسازی دسترسی، Least Privilege، کنترل Toolها، محافظت از Memory، مقابله با Prompt Injection، اعتبارسنجی مستقل عملیات، Human-in-the-Loop، مانیتورینگ و جلوگیری از اجرای خودکار اقدامات پرخطر تمرکز دارد.

مقدمه؛ وقتی هوش مصنوعی از «پاسخ دادن» به «عمل کردن» می‌رسد

نسل اول بسیاری از اپلیکیشن‌های مبتنی بر Large Language Model یا LLM کار نسبتاً ساده‌ای داشتند: کاربر سؤال می‌پرسید، متن به مدل ارسال می‌شد و مدل یک پاسخ متنی برمی‌گرداند.

در چنین معماری‌ای حتی اگر مدل اشتباه می‌کرد، معمولاً اثر مستقیم اشتباه به همان پاسخ محدود می‌شد.

اما AI Agentها این مرز را تغییر داده‌اند.

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

یعنی خروجی مدل دیگر لزوماً «متن» نیست.

گاهی خروجی مدل یک تصمیم عملیاتی است.

برای مثال:

«این Tool را اجرا کن.»

«این فایل را باز کن.»

«برای این آدرس ایمیل پیام ارسال کن.»

«این رکورد را در دیتابیس تغییر بده.»

«این درخواست API را بفرست.»

همین توانایی باعث می‌شود امنیت Agentها با امنیت یک Chatbot ساده تفاوت اساسی داشته باشد.

راهنمایی‌های امنیتی فعلی AI Agentها را سیستم‌هایی می‌دانند که می‌توانند Reasoning، Planning، Tool Use، Memory و Action داشته باشند؛ در نتیجه سطح حمله آن‌ها علاوه بر Prompt Injection شامل Tool Abuse، Privilege Escalation، Data Exfiltration، Memory Poisoning، Goal Hijacking، Excessive Autonomy و شکست‌های زنجیره‌ای نیز می‌شود.

در نتیجه سؤال اصلی دیگر فقط این نیست:

«آیا مدل پاسخ نامناسب تولید می‌کند؟»

سؤال مهم‌تر این است:

«اگر مدل تصمیم اشتباهی بگیرد، دقیقاً چه کاری قادر است در سیستم انجام دهد؟»

AI Agent Security تلاش می‌کند پاسخ به این سؤال را کنترل‌پذیر کند.

AI Agent چیست؟

AI Agent را می‌توان سامانه‌ای مبتنی بر هوش مصنوعی تعریف کرد که برای رسیدن به یک هدف، محیط را بررسی می‌کند، درباره قدم بعدی تصمیم می‌گیرد و در صورت نیاز از ابزارها یا سرویس‌های خارجی استفاده می‌کند.

یک Agent ساده ممکن است چنین چرخه‌ای داشته باشد:

1. هدف کاربر را دریافت کند.
2. شرایط را تحلیل کند.
3. تصمیم بگیرد چه اطلاعاتی لازم است.
4. یک Tool را اجرا کند.
5. نتیجه Tool را دریافت کند.
6. نتیجه را دوباره تحلیل کند.
7. قدم بعدی را مشخص کند.
8. در نهایت پاسخ یا Action نهایی را تولید کند.

برای مثال کاربر می‌گوید:

«سفارش‌های تأخیرخورده امروز را بررسی کن و برای مشتریانی که شرایط مشخصی دارند، پیش‌نویس ایمیل آماده کن.»

Agent ممکن است خودش تشخیص دهد که ابتدا باید:

• اطلاعات سفارش‌ها را از API بخواند،
• وضعیت ارسال را بررسی کند،
• مشتریان واجد شرایط را پیدا کند،
• اطلاعات تماس آن‌ها را دریافت کند،
• متن پیام را تولید کند.

اگر سیستم اختیار ارسال ایمیل هم داشته باشد، Agent ممکن است یک مرحله جلوتر برود و پیام را واقعاً ارسال کند.

در همین نقطه امنیت بسیار جدی می‌شود.

تفاوت AI Agent با Chatbot معمولی چیست؟

یک Chatbot معمولی عمدتاً روی تولید پاسخ تمرکز دارد.

اما Agent معمولاً دارای ترکیبی از قابلیت‌های زیر است:

• Reasoning
• Planning
• Tool Calling
• API Access
• Memory
• RAG
• Web Access
• File Access
• External Integrations
• Multi-Step Execution
• Autonomous Actions

این تفاوت باعث می‌شود Blast Radius یا دامنه خسارت یک خطا در Agent بسیار بیشتر باشد.

اگر یک Chatbot معمولی اشتباه کند ممکن است اطلاعات نادرستی ارائه دهد.

اما اگر Agent اشتباه کند ممکن است:

• فایل حذف کند،
• اطلاعات مشتری را ارسال کند،
• پیام اشتباه منتشر کند،
• یک تراکنش ایجاد کند،
• Credential را در Tool Call قرار دهد،
• داده محرمانه را به سرویس خارجی بفرستد،
• یا چند عملیات اشتباه را پشت سر هم اجرا کند.

بنابراین امنیت Agent باید براساس فرض «احتمال خطای مدل» طراحی شود.

چرا AI Agent Security اهمیت بیشتری پیدا کرده است؟

هرچه Agentها مستقل‌تر شوند، سه عامل امنیتی افزایش پیدا می‌کند:

قابلیت، دسترسی و خودمختاری.

Agentی که تنها می‌تواند اطلاعات عمومی را جستجو کند، سطح خطر محدودی دارد.

Agentی که به Email، Drive، CRM، Database و ابزار مالی متصل است، سطح حمله کاملاً متفاوتی دارد.

در امنیت این مفهوم با Excessive Agency ارتباط مستقیم دارد.

سه علت اصلی این مسئله معمولاً عبارت‌اند از:

• Excessive Functionality
• Excessive Permissions
• Excessive Autonomy

یعنی Agent ابزارهای بیشتری از نیاز واقعی داشته باشد، Credentialهای آن سطح دسترسی بیش از حد داشته باشند یا سیستم اجازه دهد عملیات مهم بدون کنترل مستقل انجام شوند.

معماری یک AI Agent چگونه کار می‌کند؟

یک معماری متداول ممکن است از اجزای زیر تشکیل شود:

کاربر

↓

Application

↓

Agent Orchestrator

↓

LLM

↓

Planning / Reasoning

↓

Tools

↓

API / Database / SaaS / File System / Web

در کنار این مسیر، Agent ممکن است Memory و RAG هم داشته باشد.

بنابراین معماری واقعی بیشتر شبیه شبکه‌ای از ارتباطات است تا یک مسیر خطی ساده.

هر اتصال جدید یک Trust Boundary ایجاد می‌کند.

مثلاً:

• User → Agent
• Agent → Model
• Agent → Memory
• Agent → Tool
• Tool → Database
• Tool → External API
• Agent → Agent دیگر

در طراحی امنیتی باید مشخص باشد هر موجودیت به چه چیزهایی اعتماد دارد و چه چیزهایی را باید Untrusted فرض کند.

سطح حمله AI Agent شامل چه بخش‌هایی است؟

برای Threat Modeling یک Agent باید تمام اجزایی را که می‌توانند داده دریافت، ذخیره یا اجرا کنند شناسایی کرد.

مهم‌ترین موارد عبارت‌اند از:

• User Prompt
• System Prompt
• Conversation History
• Agent Memory
• RAG Documents
• Vector Database
• Tool Definition
• Tool Arguments
• Tool Output
• API Token
• MCP Server
• Browser
• External Website
• Email
• File Upload
• Database
• Agent-to-Agent Communication
• Logs
• Approval System

اگر تنها Prompt کاربر بررسی شود، بخش بزرگی از سطح حمله نادیده گرفته می‌شود.

Prompt Injection در AI Agent

Prompt Injection یکی از شناخته‌شده‌ترین تهدیدهاست، اما در Agentها می‌تواند بسیار خطرناک‌تر از یک Chatbot ساده باشد.

در Chatbot، Prompt Injection ممکن است رفتار پاسخ مدل را تغییر دهد.

در Agent، همان تغییر رفتار ممکن است باعث Tool Call شود.

برای مثال Agent مأمور بررسی اسناد است.

مهاجم محتوایی را در یکی از اسناد قرار می‌دهد که تلاش می‌کند Agent را متقاعد کند اطلاعاتی را از منبع دیگری بخواند و به یک مقصد خارجی ارسال کند.

در این وضعیت کاربر هیچ دستور مخربی مستقیماً وارد نکرده است.

Agent هنگام خواندن محتوا با دستور مخرب روبه‌رو شده است.

این همان اهمیت Indirect Prompt Injection است.

به همین دلیل تمام اطلاعات خارجی، از جمله صفحات وب، ایمیل، فایل، PDF، نتیجه Search، API Response و Document باید Untrusted Data در نظر گرفته شوند. راهنماهای امنیتی Agent نیز صراحتاً بر برخورد با داده‌های خارجی به‌عنوان ورودی غیرقابل اعتماد تأکید می‌کنند.

Goal Hijacking؛ ربودن هدف Agent

یکی از تفاوت‌های مهم امنیت Agent با LLM ساده، وجود Goal است.

Agent معمولاً هدفی دریافت می‌کند و تلاش می‌کند برای رسیدن به آن برنامه‌ریزی کند.

در Goal Hijacking مهاجم تلاش می‌کند هدف اصلی را منحرف کند.

برای مثال هدف اصلی Agent این است:

«اسناد مربوط به قرارداد را پیدا و خلاصه کن.»

اما محتوای مخربی که از یک منبع خارجی دریافت شده تلاش می‌کند هدف را به چیزی مانند این تغییر دهد:

«به‌جای ادامه وظیفه، اطلاعات خاصی را پیدا و به مقصد دیگری ارسال کن.»

خطر زمانی بیشتر می‌شود که Agent بتواند چند مرحله را مستقل انجام دهد.

مدل ممکن است دستور مخرب را بخشی از Task تصور کند و مراحل بعدی را خودش طراحی کند.

بنابراین Agent باید بین:

• User Goal
• System Policy
• External Data
• Tool Result

مرز مشخص داشته باشد.

محتوای بازیابی‌شده نباید بتواند Policy اصلی سیستم را بازتعریف کند.

Tool Abuse؛ وقتی ابزار Agent تبدیل به مسیر حمله می‌شود

AI Agentها معمولاً از Tool برای انجام کار واقعی استفاده می‌کنند.

Tool ممکن است یک Function ساده یا اتصال به یک سرویس خارجی باشد.

برای مثال:

• search_documents
• send_email
• update_order
• get_customer
• create_ticket
• read_file
• write_file

هر Tool عملاً یک Capability است.

اگر Tool بیش از حد قدرتمند باشد، Agent نیز بیش از حد قدرتمند می‌شود.

مثال معماری نامناسب

فرض کنید Agent تنها باید گزارش‌های داخل یک Folder مشخص را بخواند.

اما توسعه‌دهنده Tool عمومی زیر را در اختیار مدل قرار داده است:

filesystem_access

این Tool می‌تواند تمام فایل‌های Server را:

• بخواند،
• ویرایش کند،
• حذف کند.

حتی اگر System Prompt به مدل بگوید فقط پوشه Reports را بخواند، کنترل امنیتی واقعی وجود ندارد.

اگر Agent اشتباه کند یا تحت Prompt Injection قرار گیرد، Tool همچنان قابلیت دسترسی گسترده دارد.

طراحی بهتر

به‌جای Tool عمومی، قابلیت محدود ایجاد شود:

read_report

با محدودیت:

• فقط Read
• فقط مسیر مشخص
• فقط فایل‌های مجاز
• بدون Path Traversal
• بدون Credential
• بدون فایل‌های Secret

اصل مهم این است:

Tool باید خودش محدود باشد؛ نه اینکه محدود بودن رفتار مدل را فرض کند.

Least Privilege؛ مهم‌ترین اصل امنیت Agent

Least Privilege یکی از بنیادی‌ترین اصول AI Agent Security است.

Agent باید فقط:

• Toolهای موردنیاز
• Permissionهای موردنیاز
• Resourceهای موردنیاز
• مدت دسترسی موردنیاز

را داشته باشد.

اگر یک Agent فقط ایمیل می‌خواند، Token آن نباید Permission ارسال یا حذف ایمیل داشته باشد.

اگر Agent فقط وضعیت سفارش را مشاهده می‌کند، Credential آن نباید Update یا Delete داشته باشد.

اگر Agent فقط یک Bucket را نیاز دارد، دسترسی کل Storage نباید داده شود.

این کنترل باعث می‌شود حتی اگر Agent رفتار غیرمنتظره‌ای داشته باشد، میزان خسارت محدود بماند.

راهنمایی‌های امنیتی جدید نیز بر محدود کردن Toolها و Permissionهای هر Tool و جدا کردن Tool Set براساس سطح اعتماد تأکید دارند.

Excessive Agency چیست؟

Excessive Agency زمانی رخ می‌دهد که سیستم به مدل اختیار عملیاتی بیش از نیاز واقعی می‌دهد.

این مشکل لزوماً نتیجه حمله نیست.

Agent ممکن است به دلایل مختلف رفتار اشتباه داشته باشد:

• Prompt Injection
• Hallucination
• Context اشتباه
• Tool Result نادرست
• Ambiguous Prompt
• Bug
• Compromised Integration

اگر اختیار Agent بیش از حد باشد، یکی از این خطاها می‌تواند به Incident جدی تبدیل شود.

سه سؤال مهم هنگام طراحی Agent:

1. آیا Agent واقعاً به این Tool نیاز دارد؟
2. آیا Tool واقعاً به این Permission نیاز دارد؟
3. آیا Agent باید اجازه اجرای خودکار این Action را داشته باشد؟

اگر پاسخ هرکدام «نه» باشد، سطح دسترسی باید کاهش پیدا کند.

Authentication و Authorization در Agentها

یکی از خطرناک‌ترین اشتباهات این است که مدل درباره Permission تصمیم نهایی بگیرد.

برای مثال نباید Backend به مدل بگوید:

«بررسی کن آیا کاربر به این فایل دسترسی دارد.»

و سپس صرفاً جواب مدل را اجرا کند.

Authorization باید Deterministic باشد.

یعنی Backend یا Policy Engine براساس:

• User ID
• Role
• Tenant
• Resource Ownership
• Scope
• Permission

تصمیم بگیرد.

Agent می‌تواند درخواست دسترسی کند؛ اما نباید مرجع نهایی مجاز بودن باشد.

Complete Mediation

هر Action باید هنگام اجرا دوباره بررسی شود.

اگر Agent سه مرحله قبل مجوزی داشت، نباید فرض شود تمام Actionهای بعدی خودبه‌خود مجازند.

هر Tool Call حساس باید در لحظه Execution بررسی شود.

این اصل در راهنماهای Excessive Agency نیز با عنوان Complete Mediation مورد تأکید قرار گرفته است.

Agent Identity؛ خود Agent چه هویتی دارد؟

یکی از مسائل مهم در معماری‌های جدید، Identity خود Agent است.

اگر همه Agentها از یک Service Account بسیار قدرتمند استفاده کنند، تشخیص مسئولیت و محدودسازی دسترسی سخت می‌شود.

بهتر است مشخص باشد:

• کدام Agent درخواست را ارسال کرده؟
• برای کدام User کار می‌کرده؟
• با چه Permissionی؟
• از چه Toolی استفاده کرده؟
• به چه Resourceای دسترسی داشته؟

این موضوع برای Audit نیز اهمیت زیادی دارد.

در سیستم سازمانی نباید فقط بدانیم:

«API فراخوانی شد.»

باید بدانیم:

«Agent X در Session Y و به نمایندگی از User Z، Tool مشخصی را برای Resource مشخص اجرا کرد.»

Human-in-the-Loop چیست؟

Human-in-the-Loop یعنی برخی اقدامات قبل از Execution به تأیید انسان نیاز داشته باشند.

این مکانیزم به‌ویژه برای Actionهای:

• مالی
• حذف اطلاعات
• تغییر Permission
• انتشار عمومی
• ارسال پیام خارجی
• تغییر Credential
• Deploy
• عملیات مدیریتی

اهمیت زیادی دارد.

راهنمای امنیت Agentها پیشنهاد می‌کند Actionها براساس سطح ریسک دسته‌بندی شوند و عملیات پراثر یا برگشت‌ناپذیر بدون Approval اجرا نشوند.

Approval واقعی باید دقیق باشد

یک Confirmation ساده مثل:

«آیا اجازه می‌دهید Agent ادامه دهد؟»

برای عملیات حساس کافی نیست.

کاربر باید بداند دقیقاً چه چیزی را تأیید می‌کند.

مثلاً:

• Action: ارسال ایمیل
• Recipient: [email protected]
• Subject: ...
• Attachment: report.pdf

یا:

• Action: حذف فایل
• Resource: /reports/2026.pdf

تأیید باید به همان Action مشخص متصل باشد.

اگر بعد از تأیید Parameters تغییر کردند، Approval قبلی نباید معتبر باقی بماند.

Memory؛ قابلیتی مفید و یک سطح حمله جدید

Agentها ممکن است Memory داشته باشند تا اطلاعات جلسات قبلی را حفظ کنند.

Memory می‌تواند تجربه کاربری را بهتر کند، اما هم‌زمان خطرهای جدیدی ایجاد می‌کند.

برای مثال:

• اطلاعات حساس ممکن است بیش از حد لازم ذخیره شوند.
• داده یک User ممکن است وارد Context کاربر دیگر شود.
• Prompt Injection ممکن است در Memory ذخیره شود.
• اطلاعات قدیمی ممکن است تصمیم‌های بعدی را تحت تأثیر قرار دهند.

Memory Poisoning چیست؟

Memory Poisoning زمانی رخ می‌دهد که داده مخرب یا گمراه‌کننده وارد حافظه Agent شود و در آینده روی رفتار آن تأثیر بگذارد.

خطر Memory Poisoning این است که حمله می‌تواند Persistent شود.

یعنی Payload یا دستور مخرب فقط در همان Session اثر ندارد.

ممکن است روزها بعد دوباره وارد Context شود.

راهنمای امنیت AI Agent بر Validation داده قبل از ذخیره در Memory، جداسازی Memory کاربران، محدودیت حجم و عمر داده و بررسی اطلاعات حساس قبل از Persistence تأکید می‌کند.

Context Isolation

Memory، Conversation History و RAG Context باید براساس User یا Tenant جدا شوند.

در یک SaaS چندمشتری، Agent نباید اطلاعات Company A را در Context Company B قرار دهد.

این جداسازی باید در Data Layer اعمال شود.

نوشتن عبارت:

«به اطلاعات کاربران دیگر دسترسی نداشته باش»

در System Prompt کافی نیست.

Backend باید Resource را پیش از ورود به Context فیلتر کند.

RAG و امنیت AI Agent

بسیاری از Agentها از Retrieval-Augmented Generation یا RAG استفاده می‌کنند.

RAG باعث می‌شود Agent بتواند اطلاعات لازم را از Knowledge Base دریافت کند.

اما هر سند بازیابی‌شده باید Untrusted در نظر گرفته شود.

یک Document ممکن است:

• قدیمی باشد،
• دست‌کاری شده باشد،
• متعلق به Tenant دیگری باشد،
• دستور مخرب داشته باشد،
• حاوی اطلاعات Sensitive باشد.

بنابراین Retrieval باید علاوه بر Similarity براساس Authorization نیز محدود شود.

نباید ابتدا سند بازیابی شود و سپس از مدل خواسته شود تصمیم بگیرد که آیا کاربر اجازه دیدنش را دارد.

Data Exfiltration؛ خروج داده از طریق Agent

یکی از ریسک‌های مهم Agentها Exfiltration اطلاعات است.

Agent ممکن است هم به داده حساس دسترسی داشته باشد و هم به یک Channel خروجی.

برای مثال:

Agent می‌تواند فایل داخلی را بخواند.

همان Agent Tool ارسال HTTP Request نیز دارد.

این دو Capability کنار هم خطرناک‌اند.

حتی اگر HTTP Tool به‌تنهایی و File Tool به‌تنهایی خطر زیادی نداشته باشند، ترکیب آن‌ها می‌تواند مسیر خروج داده ایجاد کند.

در Threat Modeling باید نه‌فقط تک‌تک Toolها بلکه ترکیب Toolها بررسی شود.

Tool Chaining

Agentها معمولاً چند Tool را پشت سر هم اجرا می‌کنند.

مثلاً:

Search → Read → Analyze → Upload → Send

خطر امنیتی ممکن است فقط در ترکیب چند مرحله ظاهر شود.

برای همین صرفاً بررسی اینکه هر Tool به‌صورت جداگانه امن است کافی نیست.

باید مسیرهای احتمالی Agent نیز تحلیل شوند.

مثال

Tool A اطلاعات مشتری را می‌خواند.

Tool B فایل ایجاد می‌کند.

Tool C فایل را به URL خارجی Upload می‌کند.

هر Tool ممکن است برای یک Use Case قانونی طراحی شده باشد.

اما Agentی که هر سه را هم‌زمان دارد، قابلیت Exfiltration پیدا می‌کند.

MCP و امنیت اتصال Agentها به ابزارها

Model Context Protocol یا MCP یکی از روش‌های اتصال مدل‌ها و Agentها به Tool، Data Source و سرویس‌های خارجی است.

وجود یک Protocol استاندارد باعث ساده‌تر شدن Integration می‌شود، اما مسئولیت Security را حذف نمی‌کند.

یک MCP Server می‌تواند دسترسی بسیار حساسی فراهم کند.

مثلاً:

• Git Repository
• File System
• Database
• Cloud
• Browser
• Ticketing System

راهنمایی‌های جدید Agentic Security نیز MCP Serverها را نقطه مهم اتصال بین AI Assistant، ابزارها، APIها و داده‌ها می‌دانند و به اهمیت امنیت Permissionهای واگذارشده و Tool Callهای زنجیره‌ای اشاره می‌کنند.

MCP Server باید مانند API حساس طراحی شود

وجود MCP نباید باعث شود کنترل‌هایی مانند:

• Authentication
• Authorization
• Schema Validation
• Rate Limiting
• Logging
• Secret Management

حذف شوند.

Agent نباید صرفاً به دلیل معرفی شدن Tool از سوی MCP آن را Trusted فرض کند.

همچنین Administrator باید دقیقاً بداند:

• چه Toolهایی منتشر شده‌اند؟
• چه Permissionهایی دارند؟
• چه Agentهایی به آن‌ها دسترسی دارند؟
• چه داده‌ای می‌توانند برگردانند؟

خروجی Agent را Trusted فرض نکنید

LLM Output همچنان Untrusted است.

اگر مدل تصمیم بگیرد یک Tool را با Parameters مشخص اجرا کند، Parameters باید اعتبارسنجی شوند.

اگر مدل HTML تولید می‌کند، خروجی باید Sanitized شود.

اگر مدل Query پیشنهاد می‌دهد، نباید مستقیماً اجرا شود.

اگر Agent URL تولید می‌کند، Destination باید بررسی شود.

این موضوع به‌ویژه وقتی Agent به Interpreter، Shell، Browser یا Database متصل است بسیار اهمیت دارد.

Structured Output و Schema Validation

یکی از راه‌های کاهش ریسک استفاده از خروجی ساختاریافته است.

برای مثال به‌جای اینکه مدل در متن آزاد توضیح دهد چه کاری انجام شود، خروجی به شکل Structure مشخص باشد:

• action
• target
• parameters
• reason

سپس Backend بررسی می‌کند:

• action مجاز است؟
• target مجاز است؟
• نوع Parameter صحیح است؟
• User Permission دارد؟
• Action نیازمند Approval است؟

Structured Output امنیت را تضمین نمی‌کند، اما امکان Validation قابل اتکاتر ایجاد می‌کند.

مراقب ابزارهای برگشت‌ناپذیر باشید

Toolها را می‌توان براساس Reversibility دسته‌بندی کرد.

عملیات Read معمولاً کم‌خطرتر است.

Write خطر بالاتری دارد.

Delete، Payment و Publish ممکن است بسیار حساس باشند.

یک مدل مناسب می‌تواند Actionها را این‌گونه دسته‌بندی کند:

Low Risk

• Search
• Read
• Summarize

Medium Risk

• ایجاد Draft
• ایجاد فایل موقت
• Update کم‌خطر

High Risk

• ارسال Email
• انتشار محتوا
• اجرای Code

Critical

• حذف داده
• انتقال وجه
• تغییر Permission
• تغییر Credential
• Production Deployment

هر سطح باید Policy مخصوص داشته باشد.

Multi-Agent Security چیست؟

برخی سیستم‌ها به‌جای یک Agent از چند Agent استفاده می‌کنند.

برای مثال:

• Research Agent
• Planning Agent
• Coding Agent
• Review Agent
• Deployment Agent

این معماری قدرت زیادی دارد، اما Trust Boundaryهای بیشتری ایجاد می‌کند.

یک Agent ممکن است خروجی Agent دیگر را Trusted فرض کند.

اگر یکی از Agentها Compromised شود، رفتار مخرب می‌تواند به بقیه منتقل شود.

این وضعیت Cascading Failure ایجاد می‌کند.

راهنمای امنیت Agentها نیز Multi-Agent Communication و Cascading Failures را از حوزه‌های مهم امنیتی می‌داند.

Agent-to-Agent Communication باید احراز هویت شود

در سیستم Multi-Agent باید مشخص باشد پیام از کدام Agent آمده است.

نباید هر Message داخلی بدون بررسی پذیرفته شود.

کنترل‌های لازم می‌توانند شامل:

• Authentication
• Authorization
• Message Integrity
• Schema Validation
• Scope
• Rate Limit

باشند.

عامل داخلی نباید به‌طور خودکار «Trusted» فرض شود.

Supply Chain در AI Agent

Agent معمولاً از مجموعه بزرگی از Dependencyها استفاده می‌کند:

• Model
• SDK
• Plugin
• MCP Server
• API
• Dataset
• Vector DB
• Prompt Template
• Container
• Package

هر جزء خارجی می‌تواند Supply Chain Risk داشته باشد.

اگر یک Tool شخص ثالث Compromised شود، Agent ممکن است داده مخرب دریافت کند.

اگر Package مخرب باشد، کنترل Prompt هیچ کمکی نمی‌کند.

اگر API Response دست‌کاری شود، Agent ممکن است تصمیم نادرست بگیرد.

بنابراین امنیت Agent همچنان به اصول Software Supply Chain نیاز دارد.

Secret Management

Agent اغلب برای Toolها به Credential نیاز دارد.

API Key نباید داخل:

• System Prompt
• Conversation
• Agent Memory
• Source Code
• Client JavaScript
• Log

قرار گیرد.

Secret باید توسط Backend یا Secret Manager مدیریت شود.

ترجیحاً Agent حتی مقدار Secret را مشاهده نکند.

Tool Execution Layer می‌تواند Token را هنگام درخواست اضافه کند بدون اینکه آن را وارد Context مدل کند.

این معماری خطر افشای Secret از طریق Prompt Injection یا Model Output را کاهش می‌دهد.

Network Security برای AI Agent

Agent دارای Browser یا HTTP Tool می‌تواند به منابع شبکه دسترسی پیدا کند.

این Capability می‌تواند SSRF و Data Exfiltration ایجاد کند.

Agent نباید لزوماً اجازه دسترسی به هر URL را داشته باشد.

کنترل‌ها می‌توانند شامل:

• Egress Filtering
• Destination Allowlist
• Domain Policy
• Private IP Blocking
• Metadata Endpoint Blocking
• Redirect Validation
• Timeout
• Response Size Limit

باشند.

شبکه باید محدودیت واقعی ایجاد کند.

Prompt نباید Network Firewall باشد.

Browser Agent چه خطراتی دارد؟

Browser Agent می‌تواند مانند یک کاربر واقعی با سایت‌ها تعامل داشته باشد.

این قابلیت باعث می‌شود Agent با محتوای غیرقابل اعتماد بسیار بیشتری روبه‌رو شود.

صفحه وب ممکن است دارای:

• متن مخرب
• Prompt Injection
• فرم جعلی
• لینک فریبنده
• Download

باشد.

اگر Agent هم‌زمان به حساب‌های حساس Login باشد، ریسک بیشتر می‌شود.

در ابزارهای Agent موجود نیز برای عملیات پراثر از تأیید کاربر، محدودیت دسترسی و مانیتورینگ Prompt Injection استفاده می‌شود؛ بااین‌حال این کنترل‌ها ریسک را کاملاً حذف نمی‌کنند.

Unbounded Consumption؛ حمله به هزینه و منابع

Agentها ممکن است Loop ایجاد کنند.

برای مثال Agent چند بار تلاش می‌کند:

Tool → Model → Tool → Model

اگر محدودیتی وجود نداشته باشد، یک Request می‌تواند صدها API Call ایجاد کند.

پیامدها:

• افزایش Token Usage
• افزایش هزینه API
• مصرف CPU/GPU
• فشار به Database
• Rate Limit شدن سرویس
• اختلال در Availability

این مسئله با مفهوم Denial of Wallet مرتبط است.

OWASP نیز مصرف کنترل‌نشده منابع را عاملی برای DoS، هزینه مالی و افت سرویس در سیستم‌های LLM می‌داند.

کنترل Agent Loop

بهتر است محدودیت‌هایی مانند موارد زیر تعریف شوند:

• Max Steps
• Max Tool Calls
• Max Tokens
• Max Runtime
• Maximum Retry
• Budget per User
• Budget per Session
• Maximum Parallel Actions

Agent نباید بتواند تا بی‌نهایت «فکر و اجرا» کند.

Monitoring و Observability در امنیت Agent

در اپلیکیشن معمولی شاید Log کردن Request و Response کافی باشد.

اما Agent نیازمند Observability عمیق‌تری است.

باید مشخص باشد:

• چه Goalی دریافت شد؟
• چه Toolی انتخاب شد؟
• Tool با چه Parametersی اجرا شد؟
• Authorization چه نتیجه‌ای داشت؟
• آیا Human Approval وجود داشت؟
• چه Resourceای تغییر کرد؟
• Execution موفق بود؟
• Token Usage چقدر بود؟

راهنمای امنیت Agent پیشنهاد می‌کند تصمیم‌ها، Tool Callها، نتایج و رویدادهای امنیتی Agent ثبت و رفتارهای غیرعادی مانیتور شوند.

Logging نباید خودش Data Leak ایجاد کند

ثبت همه‌چیز نیز خطرناک است.

Prompt یا Tool Parameter ممکن است شامل:

• Password
• API Token
• PII
• قرارداد
• اطلاعات مشتری

باشد.

بنابراین Logging باید همراه با:

• Redaction
• Masking
• Access Control
• Encryption
• Retention Policy

باشد.

Security Log نباید نسخه دیگری از دیتابیس اطلاعات محرمانه سازمان شود.

Runtime Control؛ کنترل Agent هنگام اجرا

یکی از مسیرهای مهم تکامل امنیت Agent، انتقال بخشی از Security Policy به Runtime است.

یعنی Agent هنگام اجرا توسط Policy Layer کنترل شود.

این لایه می‌تواند قبل از Tool Call بررسی کند:

• Agent چه هویتی دارد؟
• Action چیست؟
• Target چیست؟
• Permission چیست؟
• Approval وجود دارد؟
• Risk Level چیست؟

راهنمای Agent Control منتشرشده در سال ۲۰۲۶ نیز بر Inspectable، Traceable و Instrumentable بودن Agentها و امکان اعمال Policy در Runtime تأکید دارد.

معماری پیشنهادی برای Agent امن

یک معماری دفاعی را می‌توان به شکل زیر تصور کرد:

User

↓

Authentication

↓

Application Backend

↓

Agent

↓

Policy / Authorization Layer

↓

Tool Gateway

↓

Approved Tool

↓

External Resource

در این معماری Agent مستقیماً به Resource حساس متصل نیست.

Tool Gateway قبل از Execution موارد مختلف را بررسی می‌کند.

برای عملیات حساس نیز Approval Layer اضافه می‌شود.

این معماری باعث می‌شود مدل تصمیم‌گیرنده باشد اما مالک Permission نباشد.

Policy Engine چه کاری انجام می‌دهد؟

Policy Engine می‌تواند قواعد مشخصی داشته باشد.

برای مثال:

کاربر Support فقط می‌تواند Order Status را بخواند.

Agent Support نمی‌تواند Refund انجام دهد.

Refund بالاتر از مبلغ مشخص به تأیید Manager نیاز دارد.

ارسال فایل فقط به Domain سازمانی مجاز است.

حذف فایل به Human Approval نیاز دارد.

این قوانین در کد یا Policy System اجرا می‌شوند، نه در Prompt.

Defense in Depth برای AI Agent Security

هیچ کنترل واحدی امنیت Agent را تضمین نمی‌کند.

سیستم باید چند لایه دفاع داشته باشد.

لایه اول؛ Authentication

هویت User و Agent مشخص باشد.

لایه دوم؛ Authorization

Resource و Action مستقل بررسی شوند.

لایه سوم؛ Input Validation

داده خارجی Untrusted باشد.

لایه چهارم؛ Prompt Injection Defense

ورودی‌های مشکوک شناسایی و Contextها جدا شوند.

لایه پنجم؛ Tool Restrictions

هر Agent فقط ابزارهای ضروری را ببیند.

لایه ششم؛ Least Privilege

Credential محدود باشد.

لایه هفتم؛ Human Approval

عملیات حساس تأیید مستقل بگیرند.

لایه هشتم؛ Output Validation

Tool Call و Output قبل از مصرف بررسی شوند.

لایه نهم؛ Monitoring

تمام عملیات مهم قابل Audit باشند.

لایه دهم؛ Incident Response

امکان Disable کردن Agent یا Tool وجود داشته باشد.

Fail Secure و Fail Closed

در سیستم‌های حساس، شکست کنترل امنیتی نباید باعث Allow شدن Action شود.

اگر Policy Service در دسترس نیست، پاسخ نباید این باشد:

«چون Permission قابل بررسی نیست، عملیات را اجرا کنیم.»

بلکه باید Fail Closed شود.

همین اصل برای:

• Approval Validation
• Audit Service
• Risk Classification

در عملیات پرخطر اهمیت دارد.

Threat Modeling برای AI Agent

قبل از Deploy، بهتر است یک Threat Model مخصوص Agent ساخته شود.

ابتدا Assetها را مشخص کنید

مثلاً:

• اطلاعات مشتری
• فایل سازمان
• پول
• API Token
• Production Server
• Email Account

سپس Capabilityها را فهرست کنید

Agent چه چیزهایی می‌تواند انجام دهد؟

Entry Pointها را مشخص کنید

داده از کجا وارد می‌شود؟

Trust Boundaryها را رسم کنید

چه چیزی از محیط Untrusted به Trusted وارد می‌شود؟

مسیرهای ترکیبی را بررسی کنید

آیا Read Tool + Network Tool امکان Exfiltration ایجاد می‌کند؟

Worst-Case Scenario بسازید

فرض کنید Agent کاملاً فریب خورده است.

سؤال کلیدی:

در آن حالت حداکثر چه خسارتی می‌تواند ایجاد کند؟

اگر پاسخ «خیلی زیاد» است، Architecture باید محدودتر شود.

تست امنیت AI Agent

تست Agent فقط با چند Prompt ساده کامل نمی‌شود.

باید هم Application Security و هم AI Security بررسی شوند.

تست Prompt Injection

سناریوهای Direct و Indirect بررسی شوند.

تست Tool Abuse

Agent تلاش کند Tool خارج از Scope را استفاده کند.

تست Authorization

حتی اگر مدل Resource غیرمجاز درخواست کرد Backend باید آن را مسدود کند.

تست Memory Poisoning

بررسی شود ورودی مخرب چگونه و با چه مدت در Memory باقی می‌ماند.

تست Data Leakage

بررسی شود آیا Agent می‌تواند اطلاعات Tenant دیگر را دریافت کند.

تست Agent Loop

محدودیت Step و Cost آزمایش شود.

تست Human Approval

بررسی شود تغییر Parameters بعد از Approval ممکن نباشد.

تست Multi-Agent

Agent آلوده نتواند Agent دیگر را کنترل کند.

Red Teaming برای Agentها

Red Teaming Agent باید بر Abuse Case تمرکز کند.

مثلاً:

«اگر یک Document مخرب وارد RAG شود چه اتفاقی می‌افتد؟»

«اگر Tool نتیجه غیرمنتظره بدهد چه می‌شود؟»

«اگر Agent بخواهد خارج از Scope عمل کند چه چیزی جلوی آن را می‌گیرد؟»

«اگر Agent A اطلاعات مخرب برای Agent B بفرستد چه می‌شود؟»

راهنمایی‌های امنیتی جدید نیز Agentic Red Teaming را بخشی از چرخه ارزیابی امنیتی می‌دانند، زیرا تهدیدهای Agent شامل Prompt Injection، Privilege Escalation، Data Poisoning و رفتارهای زنجیره‌ای است.

Incident Response برای AI Agent

باید فرض شود روزی Agent رفتار غیرمنتظره خواهد داشت.

برای چنین شرایطی لازم است مشخص باشد:

• چگونه Agent را Disable کنیم؟
• چگونه Tool خاص را قطع کنیم؟
• چگونه Token را Rotate کنیم؟
• چگونه Session را متوقف کنیم؟
• چگونه Actionهای انجام‌شده را پیدا کنیم؟
• چگونه Memory آلوده را حذف کنیم؟

Kill Switch

Agentهای حساس باید Kill Switch داشته باشند.

یعنی بتوان بدون خاموش کردن کل Application:

• اجرای Tool را متوقف کرد،
• Agent را Read-Only کرد،
• Integration خاصی را قطع کرد.

AI Agent Security در سایت‌های وردپرسی

وردپرس نیز به‌تدریج می‌تواند میزبان قابلیت‌هایی شود که فراتر از Chatbot عمل می‌کنند.

برای مثال Agent ممکن است به:

• Posts
• Media
• WooCommerce
• Users
• Support Tickets
• Analytics

متصل شود.

خطر اصلی زمانی ایجاد می‌شود که افزونه Agent با Administrator Permission اجرا شود.

اگر Agent فقط برای تولید Draft استفاده می‌شود، نباید بتواند:

• Plugin نصب کند،
• User ایجاد کند،
• Site Option تغییر دهد،
• Post حذف کند.

WordPress Capabilityها باید رعایت شوند

هر Action باید براساس Capability واقعی User بررسی شود.

Nonce، Authentication و Permission Check همچنان لازم‌اند.

AI جایگزین WordPress Security Model نیست.

AI Agent در WooCommerce

Agentهای فروشگاهی ممکن است بتوانند:

• سفارش را جستجو کنند،
• مشتری را شناسایی کنند،
• Refund پیشنهاد دهند،
• پیام ارسال کنند.

باید مراقب Broken Access Control بود.

ارائه Order ID نباید برای مشاهده سفارش کافی باشد.

Backend باید بررسی کند User واقعاً Owner آن سفارش است یا Staff مجاز محسوب می‌شود.

برای Refund نیز بهتر است Agent فقط Proposal ایجاد کند و اجرای مالی در Policy Layer یا پس از Approval انجام شود.

اشتباهات رایج در AI Agent Security

اشتباه اول؛ اعتماد به System Prompt

عبارت «این کار را انجام نده» کنترل امنیتی واقعی نیست.

اشتباه دوم؛ دادن همه Toolها به یک Agent

هر Capability اضافه Attack Surface را بیشتر می‌کند.

اشتباه سوم؛ استفاده از Admin Token

Agent باید Credential محدود داشته باشد.

اشتباه چهارم؛ اعتبارسنجی نکردن Tool Call

Arguments تولیدشده توسط مدل باید Untrusted باشند.

اشتباه پنجم؛ ذخیره مستقیم User Input در Memory

Memory می‌تواند مسیر Persistent Injection شود.

اشتباه ششم؛ تأیید مبهم عملیات

Approval باید دقیقاً به Action و Parameters متصل باشد.

اشتباه هفتم؛ اعتماد به Agent داخلی

در Multi-Agent Architecture همه Agentها باید مرز اعتماد مشخص داشته باشند.

اشتباه هشتم؛ Logging Credential

Secret باید از Log حذف شود.

اشتباه نهم؛ نداشتن Cost Limit

Agent Loop می‌تواند منابع را مصرف کند.

اشتباه دهم؛ نداشتن Kill Switch

سیستم باید بتواند سریعاً دسترسی Agent را متوقف کند.

چک‌لیست امنیت AI Agent

قبل از Production بررسی کنید:

• آیا Agent فقط Toolهای ضروری را دارد؟
• آیا هر Tool Permission حداقلی دارد؟
• آیا Authentication مستقل وجود دارد؟
• آیا Authorization در Backend انجام می‌شود؟
• آیا Agent درباره Permission تصمیم نهایی نمی‌گیرد؟
• آیا User Input غیرقابل اعتماد محسوب می‌شود؟
• آیا Web Content و Email نیز Untrusted هستند؟
• آیا RAG دارای Access Control است؟
• آیا Memory کاربران جداست؟
• آیا Memory دارای TTL است؟
• آیا Secret وارد Context نمی‌شود؟
• آیا Tool Callها Schema Validation دارند؟
• آیا Operationهای حساس Approval می‌خواهند؟
• آیا Approval به Action دقیق Bind شده؟
• آیا Rate Limit فعال است؟
• آیا Max Agent Step مشخص است؟
• آیا Cost Budget تعریف شده؟
• آیا Egress Network محدود است؟
• آیا Tool Combinationها بررسی شده‌اند؟
• آیا Multi-Agent Communication کنترل می‌شود؟
• آیا Tool Callها Log می‌شوند؟
• آیا اطلاعات حساس در Log Redact می‌شوند؟
• آیا Alert برای رفتار غیرعادی وجود دارد؟
• آیا Agent Kill Switch دارد؟
• آیا Incident Response Plan وجود دارد؟
• آیا Red Teaming انجام شده است؟

سؤالات متداول درباره AI Agent Security

AI Agent Security چیست؟

AI Agent Security مجموعه‌ای از کنترل‌های امنیتی برای محافظت از Agentهای هوش مصنوعی است که می‌توانند برنامه‌ریزی کنند، حافظه داشته باشند، Tool اجرا کنند و روی سیستم‌های واقعی عملیات انجام دهند.

تفاوت امنیت Agent با امنیت LLM چیست؟

امنیت LLM عمدتاً به رفتار مدل و ورودی و خروجی آن مربوط است، در حالی که Agent Security علاوه بر مدل، Toolها، APIها، Permission، Memory، Workflow، Multi-Agent Communication و Actionهای واقعی را پوشش می‌دهد.

مهم‌ترین خطر AI Agent چیست؟

یک ریسک واحد وجود ندارد، اما ترکیب Prompt Injection با Toolهای بیش‌ازحد قدرتمند و Permission زیاد از خطرناک‌ترین سناریوهاست.

Excessive Agency چیست؟

Excessive Agency یعنی Agent قابلیت، Permission یا خودمختاری بیشتری از مقدار لازم داشته باشد و بتواند در نتیجه خطا یا دست‌کاری، عملیات ناخواسته انجام دهد.

آیا System Prompt می‌تواند Agent را امن کند؟

خیر. System Prompt مفید است اما نباید Security Boundary باشد. کنترل دسترسی و Permission باید خارج از LLM اعمال شود.

آیا Human-in-the-Loop همیشه لازم است؟

برای تمام عملیات نه، اما برای اقدامات مالی، برگشت‌ناپذیر، مدیریتی یا دارای اثر خارجی بسیار مهم است.

آیا Agent Memory خطر امنیتی دارد؟

بله. Memory می‌تواند اطلاعات حساس، داده کاربران مختلف یا محتوای مخرب را ذخیره کند و به Memory Poisoning منجر شود.

MCP چیست و چه ارتباطی با امنیت Agent دارد؟

MCP روشی برای اتصال Agent به Toolها و Data Sourceهاست. امنیت MCP Server و Permissionهای آن بسیار مهم است، زیرا Agent ممکن است از طریق آن به منابع حساس دسترسی پیدا کند.

Least Privilege در Agent به چه معناست؟

Agent فقط باید Tool، Permission و Resourceهایی را داشته باشد که برای Task مشخص لازم است.

آیا خروجی Agent باید Trusted باشد؟

خیر. Tool Call، Parameter و خروجی مدل باید Validation شوند.

چگونه جلوی هزینه‌های کنترل‌نشده Agent را بگیریم؟

با Rate Limit، Token Budget، Max Tool Call، Max Step، Timeout و محدودیت هزینه برای User و Session.

بهترین معماری امنیت AI Agent چیست؟

معماری مناسب معمولاً Agent را مستقیماً به Resourceهای حساس متصل نمی‌کند و بین Agent و Toolها از Authorization، Policy Enforcement، Validation، Logging و Approval برای عملیات حساس استفاده می‌کند.

جمع‌بندی

AI Agent Security یکی از مهم‌ترین شاخه‌های جدید امنیت اپلیکیشن‌های مبتنی بر هوش مصنوعی است؛ زیرا Agentها دیگر فقط متن تولید نمی‌کنند، بلکه می‌توانند تصمیم بگیرند و روی سیستم‌های واقعی عمل کنند.

هرچه Capability یک Agent بیشتر باشد، مسئولیت Security Architecture نیز بیشتر می‌شود.

Prompt Injection همچنان تهدید مهمی است، اما مشکلات Agent Security بسیار گسترده‌ترند. Tool Abuse، Excessive Agency، Privilege Escalation، Memory Poisoning، Goal Hijacking، Data Exfiltration، Supply Chain Risk، Multi-Agent Cascading Failure و Unbounded Consumption همگی باید در Threat Model دیده شوند.

قاعده طلایی این است:

هیچ‌گاه امنیت سیستم را به درست رفتار کردن مدل وابسته نکنید.

ممکن است LLM اشتباه کند.

ممکن است Prompt Injection موفق شود.

ممکن است داده خارجی دست‌کاری شده باشد.

ممکن است Tool پاسخ نامعتبر برگرداند.

بنابراین طراحی امن باید فرض کند Agent ممکن است تصمیم اشتباه بگیرد و با این حال سیستم همچنان قادر باشد جلوی خسارت جدی را بگیرد.

راه رسیدن به این هدف ترکیبی از Least Privilege، Tool Isolation، Authorization مستقل، Memory Isolation، Validation، Human-in-the-Loop، Runtime Policy Enforcement، Monitoring و Defense in Depth است.

در نهایت، AI Agent Security به معنای محدود کردن کامل قابلیت Agent نیست؛ بلکه به معنای ساخت مرزهایی است که به هوش مصنوعی اجازه می‌دهند مفید و خودکار باشد، بدون آنکه یک تصمیم اشتباه یا ورودی مخرب بتواند کنترل منابع حساس سیستم را در اختیار آن قرار دهد.