AgentGuard با ردیابی درخت نحو از تزریق پرامپت در جریان‌های پیچیده جلوگیری می‌کند

تصور کنید تنها یک تغییر ساده در نام متغیرها یا یک تخصیص متغیر تکانه کافی باشد تا کل یک عامل هوش مصنوعی در برابر حملات تزریق پرامپت (Prompt Injection) بی‌دفاع شود. ابزار AgentGuard در نسخه ۰.۵.۰ این آسیب‌پذیری را با جایگزینی الگوهای متنی ساده با مکانیسمی پیشرفته به نام ردیابی آلودگی مبتنی بر درخت نحو انتزاعی (AST-based taint tracking) برطرف کرده است.

بیشتر ابزارهای امنیتی برای یافتن الگوهای خطرناک به عبارت‌های منظم (regex) تکیه می‌کنند، اما regex کد را مانند یک متن ساده و تخت می‌بیند. این روش زمانی شکست می‌خورد که ورودی کاربر از طریق چندین متغیر عبور کند — فرآیندی که به آن جریان «چند-پرشی» (multi-hop flow) می‌گویند — تا در نهایت به مدل زبانی (LLM) برسد. برای مثال، یک قانون regex شاید بتواند عبارت prompt = f"You are helpful. {user_input}" را شناسایی کند، اما نمی‌تواند زنجیره‌ای را ردیابی کند که در آن یک پرس‌وجو ابتدا از request.json.get() استخراج شده، سپس فضاهای خالی آن حذف شده، به حروف بزرگ تبدیل شده و در نهایت وارد یک قالب .format() شود. همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، پایداری در گردش‌های کاری عامل‌محور مستلزم درک ساختاری از کد است و AST دقیقاً همین درک را فراهم می‌کند تا ابزار بتواند ساختار واقعی کد را بفهمد. این رویکرد ساختاری مشابه آنچه در ابزار VibeGuard برای شناسایی الگوهای توهم‌گونه در کدنویسی AI دیدیم، بهره‌وری تحلیل‌های استاتیکی را به شدت افزایش می‌دهد.

به نقل از گزارش فنی این ابزار، AgentGuard اکنون از ماژول ast پایتون استفاده می‌کند تا کد منبع را به یک درخت نحو تبدیل کرده و نحوه حرکت داده‌ها را نقشه‌برداری کند. این فرآیند از چهار مرحله مشخص پیروی می‌کند:

خط‌لوله ردیابی آلودگی

• شناسایی منبع (Source Identification): ابزار عباراتی که داده‌های غیرقابل‌اعتماد تولید می‌کنند را علامت‌گذاری می‌کند. این بخش گره‌های ast.Name را با مجموعه‌ای از الگوهای شامل user_input ،user_msg ،user_message ،request ،req ،query ،message و msg بررسی می‌کند. همچنین گره‌های ast.Call را برای دسترسی به ویژگی‌هایی نظیر request.args.get("q") ،request.json["key"] و تابع input() زیر نظر می‌گیرد.
• انتشار (Propagation): آلودگی در طول تخصیص‌ها دنبال می‌شود. وقتی یک منبع به متغیری تخصیص یابد، آن متغیر «آلوده» می‌شود. این وضعیت در موارد زیر حفظ می‌گردد:
  • فراخوانی متدها: مانند processed = user_input.strip()
  • رشته‌های f-string: مانند prompt = f"Hello {user_input}"
  • قالب‌بندی: مانند prompt = template.format(q=query)
  • اتصال رشته‌ها: مانند prompt = "Hello " + user_input
  • ساخت لیست/دیکشنری: مانند messages = [{"role": "user", "content": user_input}]
• تشخیص سینک یا مصب (Sink Detection): زمانی که داده‌های آلوده به یک «سینک» برسند، یک یافته (Finding) فعال می‌شود. این اتفاق هنگام تخصیص متغیر به prompt یا messages و یا در طول فراخوانی توابعی نظیر openai.chat.completions.create(messages=<tainted>) رخ می‌دهد. این لایه‌ی دفاعی مکمل سیستم‌هایی است که مانند Aegis-Layer با استفاده از سدهای ریاضی تلاش می‌کنند نشت داده‌ها را در لحظه متوقف کنند.
• پاک‌سازی (Sanitization): ردیاب در صورتی که داده‌ها از توابعی عبور کنند که صریحاً آن‌ها را ایمن می‌کنند، برچسب آلودگی را حذف می‌کند. این توابع شامل str() ،int() ،float() ،len() و توابع صریح escape هستند. برای نمونه، عبارت safe = str(user_input)[:100] به عنوان داده پاک‌سازی شده تلقی می‌شود.

این تغییر معماری اجازه می‌دهد سناریوهایی شناسایی شوند که در آن‌ها یک پرس‌وجوی کاربر ابتدا حذف فاصله شده، به حروف بزرگ تبدیل شده و سپس در یک قالب قرار می‌گیرد؛ توالی‌ای که در آن regex چهار خط کاملاً نامرتبط را می‌بیند. سیستم یک دیکشنری به نام tainted_vars را برای ردیابی این تخصیص‌ها در زمان واقعی (Real-time) نگه می‌دارد. هنگامی که ابزار با عبارت x = tainted_expr مواجه شود، x را به دیکشنری اضافه می‌کند و وقتی با x = safe_expr مواجه شود، آن را حذف می‌نماید.

قابلیت‌ها و نمونه‌های فعلی

نسخه ۰.۵.۰ اکنون می‌تواند جریان‌های پیچیده‌ای را که پیش‌تر از دید سیستم دور می‌ماندند، شکار کند:

• جریان‌های چند-پرشی: شناسایی زنجیره‌ای از چهار تخصیص متغیر متوالی از منبع تا فراخوانی LLM.
• آرگومان‌های نام‌گذاری شده: ردیابی انتشار آلودگی از طریق متدهای قالب‌بندی مانند .format(q=query).
• محتوای آرایه: شناسایی رشته‌های آلوده که درون آرایه‌ی messages جاسازی شده‌اند.

در مقابل، این ابزار به‌درستی پرامپت‌های سخت‌کد شده (Hardcoded) مانند prompt = "What is the weather?" را نادیده می‌گیرد زیرا هیچ منبع آلودگی در آن‌ها وجود ندارد. برای توسعه‌دهندگان، این به معنای گذار از امنیت مدل «ضربه به موش» (Whack-a-mole) است. با این حال، نسخه ۰.۵.۰ محدودیت‌های شناخته‌شده‌ای دارد:

• زبان: در حال حاضر فقط از پایتون پشتیبانی می‌کند؛ پشتیبانی از JavaScript و TypeScript در نقشه راه (Roadmap) قرار دارد.
• دامنه: ردیابی فقط در سطح یک فایل (Intra-file) است و آلودگی از مرزهای فایل عبور نمی‌کند (تحلیل بین-روالی یا Interprocedural ندارد).
• منطق: ردیابی جریان کنترل (Control flow) وجود ندارد و شاخه‌های if/else به‌صورت مجزا تحلیل نمی‌شوند.
• پاک‌سازی: تلقی کردن str() به عنوان یک پاک‌ساز، رویکردی محافظه‌کارانه است و ممکن است برای تمام زمینه‌ها ایمن نباشد.

در یک محک (Benchmark) با ۳۲ نمونه که همراه با انتشار نسخه ۰.۵.۰ ارائه شد، قانون مبتنی بر AST (با شناسه ASI01-TAINT-TRACK) به نرخ شناسایی ۱۰۰٪ برای جریان‌های چند-پرشی مورد آزمایش دست یافت. این ابزار شامل ۳۸ تست برای تضمین پایداری است. قوانین AST در کنار قوانین regex موجود اجرا می‌شوند تا سرعت regex را با دقت AST ترکیب کنند.

گام بعدی شما

• نصب ابزار با مجوز MIT از طریق دستور pip install --upgrade dfx-agentguard برای بررسی کدهای فعلی.
• اجرای اسکن روی دایرکتوری‌های منبع با دستور agentguard src/ --format text.
• بررسی مجدد توابع پاک‌سازی (Sanitization) در کد خود، زیرا فرض ایمن بودن مطلق str() ممکن است در برخی محیط‌ها ریسک‌پذیر باشد.

اما اثر این تغییر در شناسایی حملات پیچه‌تر بر روی مدل‌های چندوجهی حتی حیاتی‌تر است — به تحلیل ما درباره‌ی امنیت مدل‌های VLM مراجعه کنید.