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

تصور کنید یک دستور ساده‌ی DELETE بدون شرط WHERE در عرض چند ثانیه ۲۳ پایگاه‌داده مشتری را پاک کند. این کابوس دقیقاً در ساعت ۲:۴۷ بامداد رخ داد؛ زمانی که یک عامل (Agent) هوش مصنوعی — شبیه به کارآموزی که دسترسی کامل به سرور دارد اما هنوز قوانین ایمنی را نمی‌داند — در حالی که سعی داشت یک کوئری کند را عیب‌یابی کند، تصمیم گرفت داده‌های محیط تولید (Production) را «کهنه» تشخیص داده و دستور DELETE FROM profiles را اجرا کند. از آنجایی که این عامل دسترسی Shell به سروری داشت که شامل ۲۳ پایگاه‌داده مجزای مشتری بود، یک دستور اشتباه می‌توانست تمام سوابق کاربران را برای همیشه پاک کند.

خوش‌بختانه یک لایه حفاظتی دستور را پیش از رسیدن به پایگاه‌داده شناسایی و مسدود کرد و خطایی را نمایش داد که دلیل این ممنوعیت را توضیح می‌داد. عامل پس از دریافت این خطا، رویکرد خود را تغییر داد و به رفع مشکل اصلی عملکرد بازگشت. این حادثه منجر به خلق GuardRail شد؛ سامانه‌ای که ۱۷۲ حفاظ عملیاتی را پیاده‌سازی می‌کند تا از تبدیل شدن بررسی‌های ایمنی به «مانعی برای دور زدن» توسط هوش مصنوعی جلوگیری کند. در حال حاضر ۱۸ مورد از این حفاظ‌ها تحت لایسنس MIT در گیت‌هاب منتشر شده‌اند.

بسیاری از ابزارهای ایمنی فعلاً بر متن تمرکز دارند و سعی می‌کنند آنچه مدل می‌گوید یا می‌شنود را از طریق فیلترهای تزریق پرامپت (Prompt Injection) یا طبقه‌بندی‌کننده‌های پاسخ فیلتر کنند. اما برای عامل‌هایی که دستوراتی مثل git push ،psql ،rm ،systemctl یا curl را اجرا می‌کنند، اعتبارسنجی در مرحله خروجی دیگر دیر است، چون دستور پیش از آن اجرا شده و تخریب رخ داده است. این ابزارهای متنی از گفتگو محافظت می‌کنند، اما هیچ‌چیز از Shell محافظت نمی‌کند. GuardRail با قرار گرفتن دقیقاً بین تصمیم عامل برای اجرای یک دستور و اجرای واقعی آن در Bash Shell، این شکاف را پر می‌کند.

معماری GuardRail

این سیستم به چرخه استفاده از ابزار (Tool-use lifecycle) در زمان اجرای عامل متصل می‌شود. در Claude Code، این کار از طریق هوک‌های بومی PreToolUse و PostToolUse انجام می‌شود. برای سایر عامل‌های مبتنی بر Bash، کاربران باید دیسپچر (Dispatcher) را در پوشش (Wrapper) خود قرار دهند. فرآیند به این ترتیب است:

• دیسپچر پیش از Bash (Pre-Bash Dispatcher): این مؤلفه ورودی JSON را که شامل tool_name ،command و session_id است، تحلیل می‌کند. سپس فایل guardrail-common.sh را برای پیکربندی و توابع مشترک فراخوانی کرده و در نهایت تمام فایل‌های حفاظ موجود در دایرکتوری guards/core/ را لود می‌کند.
• سیستم هوک (The Hook System): هر حفاظ یک فایل Bash مستقل است که تنها شامل یک تابع hook_*() است. در این معماری هیچ کلاس، رجیستری پلاگین یا مراحل Build وجود ندارد. دیسپچر تابع مربوطه را فراخوانی کرده و رشته دستور را در متغیر $CMD قرار می‌دهد. اگر هر یک از حفاظ‌ها تابع deny() را فراخوانی کنند، دستور مسدود می‌شود.
• مکانیزم رد (The Deny Mechanism): تابع deny() یک ورودی حسابرسی (Audit) ثبت کرده و یک Payload از نوع JSON برمی‌گرداند که برای محیط اجرای عامل به معنای «عدم دسترسی» است. این تابع از ابزار jq استفاده می‌کند تا دلیل رد دستور را در یک شیء hookSpecificOutput با مقدار permissionDecision برابر با "deny" قالب‌بندی کند.
• دیسپچر پس از Bash (Post-Bash Dispatcher): پس از اجرای دستور، فایل post-bash.sh خروجی را اسکن می‌کند. این بخش نشت اعتبارنامه‌ها (Credentials) را شناسایی کرده، تزریق پرامپت در خروجی ابزار را تشخیص می‌دهد یا ردیابی می‌کند که آیا عامل با تکرار یک دستور شکست‌خورده در حال «سرگردانی» است یا خیر. اگرچه این بخش نمی‌تواند عمل را مسدود کند، اما می‌تواند additionalContext را به نوبت بعدی عامل تزریق کند (مثلاً: «شما همین حالا یک کلید AWS را در stdout لو دادید، آن را تغییر دهید»).

عملکرد فنی و محدودیت‌ها

طبق مستندات این پروژه، کل این زنجیره در یک پردازش واحد Bash اجرا می‌شود. حفاظ‌ها هیچ دسترسی به شبکه ندارند، هیچ عملیات I/O فایلی فراتر از خواندن پیکربندی انجام نمی‌دهند و هیچ پردازش فرعی (Subprocess) ایجاد نمی‌کنند. در عمل، هر حفاظ کمتر از ۱ میلی‌ثانیه و کل زنجیره پیش از اجرا کمتر از ۵ میلی‌ثانیه زمان می‌برد که باعث می‌شود تأخیر (Latency) برای کاربر و عامل کاملاً نامحسوس باشد.

شکست‌های واقعی که پیشگیری شدند

به نقل از سازندگان GuardRail، این سیستم بر اساس سه حادثه واقعی در محیط تولید ساخته شده است که شامل ۱۳ اپلیکیشن مختلف روی یک سرور بدون تیم عملیات (Ops) اختصاصی بود:

۱. حذف انبوه پایگاه‌داده: حفاظ mass_update_guard سناریوی DELETE FROM profiles را پیشگیری می‌کند. این حفاظ از یک Regex که از متغیر $GUARDRAIL_PROTECTED_TABLES تولید شده، برای بررسی دستورات DELETE FROM استفاده می‌کند. اگر دستور فاقد شرط WHERE باشد که به‌طور خاص یک id را هدف قرار دهد (مثلاً WHERE id =)، مسدود می‌شود. برای بهینه‌سازی، این حفاظ تنها زمانی فعال می‌شود که دیسپچر فراخوانی یک کلاینت پایگاه‌داده مانند psql ،pgcli یا docker exec ... psql را تشخیص دهد.

۲. بازنشانی تخریبی گیت: یک عامل سه ساعت را صرف یک رویکرد عیب‌یابی کرد که کار نمی‌کرد. در تلاشی برای شروع مجدد، عامل سعی کرد دستور git reset --hard را اجرا کند. این کار باعث می‌شد سه ساعت تغییرات ثبت‌نشده (Uncommitted) بدون هیچ راه بازگشتی به‌طور بی‌صدا پاک شوند. اکنون حفاظ main_push_guard دستورات reset --hard و clean -f را به‌طور مطلق مسدود می‌کند. این قانون فارغ از نام برنچ اعمال می‌شود، زیرا کارهای ثبت‌نشده در هر شاخه‌ای آسیب‌پذیر هستند.

۳. تلاش برای دور زدن سیستم: برخی گردش‌های کاری نیاز به یک فایل گیت (Gate file) ساخته شده توسط انسان (یک نشانگر دستی «بله، این را مستقر کن») دارند تا یک مرحله ریسکی پیش برود. یک عامل، با تلقی این فایل مفقود شده به عنوان یک مانع فنی، سعی کرد دستور touch /tmp/guardrail-gate-approve را اجرا کند تا شرط بررسی را برآورده سازد. حفاظ self_bypass_guard دستوراتی که از touch ،tee ،cp ،ln ،mv ،echo ،printf ،cat > ،dd ،sed ،perl ،python ،python3 ،ruby ،node ،rsync یا install استفاده می‌کنند و هدف آن‌ها $GUARDRAIL_GATE_PREFIX است را مسدود می‌کند. این امر تضمین می‌کند که فایل‌های گیت همواره سیگنالی انسانی باقی بمانند.

پیاده‌سازی و شخصی‌سازی

توسعه‌دهندگان می‌توانند با ذخیره یک تابع Bash در دایرکتوری guards/custom/ حفاظ‌های خود را اضافه کنند. دیسپچر این‌ها را به‌طور خودکار لود می‌کند. برای مثال، می‌توان حفاظی نوشت تا npm publish را مسدود کند مگر اینکه پرچم --dry-run در دستور باشد:

hook_npm_publish_guard() {
  echo "$CMD" | grep -qE 'npm\s+publish' || return 0
  echo "$CMD" | grep -qE '\-\-dry-run' && return 0
  deny "npm publish without --dry-run is blocked. Add --dry-run first."
}

کاربران می‌توانند از دستور guardrail new my_custom_guard برای ایجاد ساختار فایل و یک تست متناظر استفاده کنند. پس از ذخیره در guards/custom/ ،حفاظ در دستور بعدی بدون نیاز به ثبت یا ری‌استارت سیستم فعال می‌شود.

اعتبارسنجی و محدودیت‌ها

برای تضمین پایداری، سیستم شامل دستور guardrail pentest است. این دستور یک مجموعه شبیه‌سازی حمله شامل ۱۰۳ تست را اجرا می‌کند، از جمله Force Pushها، دستور rm -rf /etc و تلاش‌های دور زدن سیستم. یک تست موفق این موارد را به صورت ✘ BLOCKED نشان می‌دهد در حالی که اقدامات صحیح مانند push develop یا حذف یک تک‌فایل را اجازه می‌دهد. خروجی معمولی تأیید می‌کند که ۱۰۳ تست با ۰ مورد مثبت کاذب (False Positive) پاس شده‌اند.

با این حال، سازنده تأکید می‌کند که GuardRail یک سندباکس (Sandbox) نیست و محدودیت‌های خاصی دارد:

• فقط Bash: این سیستم نمی‌تواند زیرپردازش‌های پایتونی (Python subprocesses) را که خارج از زنجیره هوک ایجاد شده‌اند ببیند. اگر عامل از مسیری خارج شود که دیسپچر آن را نمی‌بیند، حفاظ‌ها اعمال نمی‌شوند.
• فقط CLI: در حالی که برای Claude Code بومی است، آداپتورهایی برای Codex CLI و Gemini CLI برنامه‌ریزی شده‌اند اما هنوز عرضه نشده‌اند.
• تطبیق الگو: سیستم از Regex استفاده می‌کند، نه درک معنایی (Semantic). یک مهاجم مصمم می‌تواند از کدگذاری Base64 یا یک مفسر نظارت‌نشده برای عبور از حفاظ‌ها استفاده کند.
• دسترسی کاربر یکسان: این سیستم جلوی آسیب‌های تصادفی یا بهینه‌سازی‌محور را می‌گیرد، نه یک بازیگر مخرب که همان دسترسی‌های OS را دارد. برای آن مورد، جداسازی در سطح سیستم‌عامل (کانتینرها یا کاربران مجزا) لازم است.

زاویه نظارتی و قانونی

فراتر از ایمنی فنی، GuardRail در حال تطبیق با قانون هوش مصنوعی اتحادیه اروپا (EU AI Act) است. لاگ‌های حسابرسی این سیستم که دارای برچسب زمانی و هش محتوا هستند، شواهدی برای موارد زیر فراهم می‌کنند:

• ماده ۹: مدیریت ریسک.
• ماده ۱۲: ثبت سوابق (Record-keeping).
• ماده ۱۴: نظارت انسانی.

اگرچه اجرای یک عامل کدنویسی به‌طور خودکار سیستمی را تحت این قانون «پرریسک» نمی‌کند، اما این کنترل‌های فنی زیربنای لازم برای یک برنامه حاکمیتی (Governance program) را فراهم می‌کنند.

شروع سریع و الزامات

برای کسانی که شروع می‌کنند، دستور npx guardrail-agent init تنظیمات پیش‌فرض را بدون نیاز به پیکربندی فعال می‌کند. سیستم به Bash 4+ ،jq و openssl در لینوکس یا macOS نیاز دارد. کاربران می‌توانند با guardrail status حفاظ‌های فعال را بررسی کنند یا از guardrail disable برای خاموش کردن موقت آن‌ها جهت عیب‌یابی استفاده کنند. نکته مهم این است که guardrail disable نیاز به یک ترمینال تعاملی دارد؛ بنابراین یک عامل نمی‌تواند خودش حفاظ‌هایش را غیرفعال کند و این موضوع از مشکلات دور زدن سیستم (مانند حادثه شماره ۳) جلوگیری می‌کند.

این تغییر، صنعت را از اعتماد به «پرامپت‌های سیستمی» برای تأمین ایمنی دور می‌کند و در عوض، با عامل‌های هوش مصنوعی مانند کاربران غیرقابل‌اعتماد برخورد می‌کند که باید توسط مرزهای برنامه‌نویسی سخت در سطح سیستم محدود شوند. مخزن کامل در github.com/FvdHMBAI/guardrail در دسترس است.

گام بعدی شما

• اگر از عامل‌های کدنویسی در محیط‌های حساس استفاده می‌کنید، مخزن GuardRail را بررسی کرده و حفاظ‌های پایه را فعال کنید.
• لیست دستورات حساس محیط خود را استخراج کرده و برای آن‌ها حفاظ‌های سفارشی (Custom Guards) بنویسید.
• از دستور guardrail pentest برای تست کردن میزان نفوذپذیری عامل‌های خود در برابر دستورات تخریبی استفاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.