تصور کنید یک دستور اشتباه git add توسط یک عامل هوش مصنوعی، تمام کلیدهای دسترسی محیط تولید (Production) شما را لو دهد یا خط لوله CI را در اولین روز کاری‌تان در شرکت جدید نابود کند. برای مقابله با این ریسک، راهنمای کاربردی وب‌سایت dev.to در ۲۰ سپتامبر ۲۰۲۶ تشریح کرد که چرا برنامه‌نویسان جونیور باید پیش از نوشتن اولین پرامپت برای عامل خود، یک «لیست سیاه مسیرها» (Path Deny List) پیاده‌سازی کنند.
بیشتر عامل‌های هوش مصنوعی (AI Agents) — شبیه دستیاری که فقط به فکر تمام کردن سریع کار است و به عواقب آن فکر نمی‌کند — اولویت را به اجرای موفق محلی (Green Run) می‌دهند تا ریسک ادغام کد. آن‌ها دغدغه‌ای دربارهٔ «شعاع تخریب» یک تغییر ندارند و فایل‌های قفل (Lockfiles)، نمونه‌های محیطی و پیکربندی‌های CI را اهدافی آسان برای ویرایش می‌بینند. برای توسعه‌دهنده‌ای که همین امروز به یک مخزن (Repo) پیوسته است، ریسک بالاست؛ شما می‌توانید کد را کلون کنید و تست‌ها را اجرا کنید، اما هنوز نمی‌توانید تأثیر یک تغییر سیستمی را بسنجید.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد مطلق به خروجی مدل‌ها در محیط‌های حساس خطرناک است. تصور کنید عاملی بدون اجازه package-lock.json را به‌روزرسانی کند، یک فایل Workflow را بازنویسی نماید یا برای حدس زدن مقادیر، فایل‌های نمونه محیطی را تغییر دهد. این ویرایش‌ها نباید در اولین PR شما باشند. چون حافظهٔ انسان تحت فشار زمانی سریعاً دچار خطا می‌شود، تنها راهکار قابل‌اعتماد، یک فایل متنی «انجماد» (Freeze File) است که بتوان آن را جست‌وجو کرد؛ فایلی که برخلاف حافظه، هرگز فراموش نمی‌کند. این رویکرد مکمل راهکارهای سیستمی‌تر است، مشابه آنچه در مکانیسم مسیریاب وظایف برای جلوگیری از نشت داده‌های حساس در عامل‌های محلی بررسی کردیم.
کالبدشکافی یک لیست سیاه
به نقل از آموزش‌های dev.to، توسعه‌دهندگان باید با هر مسیر به یکی از دو صورت «مجاز» یا «منجمد» برخورد کنند. مسیرهای منجمد هرگز نباید وارد پنجرهٔ زمینه (Context Window) — مثل میز کاری کوچکی که فقط جای چند ورق دارد و مدل هر چه را خارج از آن ببیند فراموش می‌کند — شوند و نباید با دستور git add اضافه گردند.
برای تعیین موارد منجمد در روز اول، از این جدول تصمیم‌گیری استفاده کنید:
- اسرار (Secrets): فایل‌های
.envو.env.*و**/*.pem. این‌ها منجمد هستند چون اسرار از طریق پرامپت‌ها و Diffها نشت می‌کنند. در همین راستا، Private EDGE OS با انتقال کلیدهای API به گاوصندوق‌های محلی تلاش کرد تا ریشه‌ای‌ترین دلیل نشت این اسرار را در محیط‌های On-prem حذف کند. - ریسک تولید: مسیرهای
**/credentials*و**/*secret*. نام این فایل‌ها به تنهایی سیگنالی از ریسک بالا است. - فایل‌های قفل:
package-lock.jsonوyarn.lockوpnpm-lock.yamlوCargo.lockوgo.sumوpoetry.lock. تغییرات زیاد (Churn) در این فایل‌ها، تغییرات واقعی PR را پنهان می‌کند. - CI/CD: مسیرهای
.github/workflows/**و.gitlab-ci.yml. ویرایش‌های اینجا اغلب از چرخه بازبینی استاندارد شما خارج هستند. - حاکمیت: فایل‌های
CODEOWNERSکه تعیین می‌کنند چه کسی باید ادغام را تأیید کند. تغییر در این فایل یعنی تغییر در افرادی که باید امضای نهایی را بزنند. - داده‌ها: مسیرهای
**/migrations/**. بازنویسی داده‌ها برای اولین PR مناسب نیست. - زیرساخت: مسیرهای
infra/**وterraform/**وk8s/**. تغییرات در زیرساخت ابری نیاز به مالکیت و تخصص متفاوتی دارد. - مسیرهای امن:
README.mdوCONTRIBUTING.mdمعمولاً امن هستند اگر آن‌ها را بخوانید. همچنین فایل‌های سورس در مسیر مربوط به تیکت assigned شده مجازند، زیرا این همان کار محول شده است.
این جدول یک پیشنهاد است، نه سیاست تیم. بازبین‌ها ممکن است مسیرهای بیشتری را منجمد کنند؛ پس پیش از نهایی کردن لیست، از آن‌ها بپرسید و این لیست را به عنوان قانون مطلق نپذیرید.
پیاده‌سازی گام‌به‌گام
اجرا با یک موجودی‌برداری دستی در یک کلون تمیز شروع می‌شود. هنوز پنجره چت را باز نکنید. ابتدا با دستورات git clone و git status و git log --oneline -n 15 وضعیت فعلی را درک کنید تا بدانید در مخزن چه می‌گذرد.
موجودی‌برداری از درخت فایل‌ها
نام فایل‌های خطرناک را خودتان لیست کنید و از مدل نخواهید که آن‌ها را حدس بزند. بر اساس مستندات این راهنما، از دستور find برای شناسایی ریسک‌ها استفاده کنید:
find . -type f \( \ -name '.env' -o \ -name '.env.*' -o \ -name '*.pem' -o \ -name 'CODEOWNERS' -o \ -name '*lock.json' -o \ -name '*lock.yaml' -o \ -name 'Cargo.lock' -o \ -name 'go.sum' -o \ -name '.gitlab-ci.yml' \) -not -path './.git/*' | sort
این خروجی را به عنوان اولین سند (Artifact) خود ذخیره کنید. اگر خروجی find شلوغ بود، جست‌وجو را با ls -la در پوشه‌های خاص مثل .github/workflows یا infra یا terraform یا k8s محدود کنید. همین حالا فایل CODEOWNERS را بخوانید تا بدانید مالک Workflowها و مسیرهای زیرساخت کیست؛ شما امروز نباید آن درخت‌ها را Stage کنید.
ایجاد فایل انجماد
پس از موجودی‌برداری، یک فایل به نام .agent-untouchable در ریشه مخزن بسازید. فایل را ساده و کوتاه نگه دارید و در هر خط فقط یک الگو بنویسید. نمونه ورودی‌ها شامل موارد زیر است:
.env .env.* *.pem **/credentials* **/*secret* package-lock.json yarn.lock pnpm-lock.yaml Cargo.lock go.sum poetry.lock .github/workflows/** .gitlab-ci.yml CODEOWNERS **/migrations/** infra/** terraform/** k8s/** .agent-untouchable check-untouchable.sh
این فایل را تا زمانی که تیم درخواست کند، محلی نگه دارید. برای اینکه یک git reset اشتباه لیست شما را پاک نکند، یک کپی از آن را خارج از محیط کاری (Worktree) ذخیره کنید: cp .agent-untouchable "$HOME/.agent-untouchable.$(basename "$PWD")". این کار تضمین می‌کند که شما همچنان مالک منبع حقیقت (Source of Truth) هستید.
نصب بازبین (Checker)
برای اجباری کردن این انجماد، یک اسکریپت bash محلی به نام check-untouchable.sh پیشنهاد می‌شود. این اسکریپت نام فایل‌های Stage شده را با دستور git diff --cached --name-only استخراج کرده و با لیست سیاه مقایسه می‌کند و اگر مسیر منجمدی پیدا کند، با کد ۱ خارج می‌شود.
اسکریپت را با chmod +x check-untouchable.sh قابل اجرا کنید. برای سخت‌گیرانه‌تر شدن و ایجاد اصطکاک بیشتر، آن را به یک hook محلی متصل کنید: mkdir -p .git/hooks و اسکریپت را در .git/hooks/pre-commit بنویسید. این کار فقط ایندکس محلی شما را محافظت می‌کند و شاخه Remote را کنترل نمی‌کند، که برای اولین PR کافی است.
اعتبارسنجی دروازه
هرگز به دروازه‌ای که شکستش را ندیده‌اید اعتماد نکنید. گردش‌کار ایجاب می‌کند که عمداً یک فایل منجمد را Stage کنید (مثلاً git add package-lock.json) تا مطمئن شوید بازبین خط قرمز را فعال می‌کند. عبور بی‌صدا از بازبین، هیچ چیز مفیدی به شما نمی‌آموزد.
اگر الگوها فایل را پیدا نکردند، خطوط را دقیق‌تر کنید. به یاد داشته باشید که Globbing در Bash با زبان .gitignore متفاوت است. باید shopt -s globstar nullglob را در اسکریپت فعال کنید تا ستاره‌های بازگشتی (Recursive Stars) پشتیبانی شوند. دوباره Diff جعلی را تست کنید و خروجی شکست را در یادداشت‌های خود نگه دارید تا ثابت شود دروازه کار می‌کند.
محدود کردن پرامپت
تنها پس از اثبات بازبین است که می‌توانید با عامل صحبت کنید. مسیر تیکت و فایل لیست سیاه را به مدل بدهید، اما هرگز فایل‌های .env یا id_rsa یا کلیدهای .pem یا URLهای محیط تولید حاوی توکن را Paste نکنید. اگر README حاوی کلید نمونه است، آن را با REDACTED جایگزین کنید.
از پرامپتی استفاده کنید که مرزها را دو بار بیان کند. برای مثال: «فقط فایل‌های مسیر app/billing/ را ویرایش کن. مسیرهای موجود در .agent-untouchable را نخوان و ننویس. فایل‌های قفل را به‌روزرسانی نکن. Workflowها را ویرایش نکن. پیش از هر Patch، لیست فایل‌ها را برگردان.»
مدیریت خروجی عامل
پیش از پذیرش هر Patch، لیست کامل فایل‌ها را مطالبه کنید. برای مثال، اگر برای تیکت BILL-214 در مسیر app/billing/invoice.py درخواست داده‌اید اما عامل تغییراتی در app/billing/invoice.py و app/billing/invoice_test.py و package-lock.json و .github/workflows/ci.yml برگرداند، باید کل Patch را رد کنید.
به عنوان لطف، Workflow را «اصلاح» نکنید. مرز را دوباره یادآوری کنید: «فقط برای invoice.py و invoice_test.py پچ برگردان.» تنها آن دو فایل را Stage کنید، بازبین را روی ایندکس اجرا کنید و سپس تست‌های شناخته‌شده را بزنید (مثلاً python -m pytest -q یا npm test --silent). اگر تست‌ها را نمی‌شناسید، توقف کنید؛ شما نباید مخزنی را ویرایش کنید که نمی‌توانید آن را اجرا کنید.
این فرآیند کند، عمدی است. هدف برای یک برنامه‌نویس جونیور، یادگیری مخزن است، نه جمع‌آوری تعداد PRهای ادغام شده.
محدودیت‌ها و حالت‌های شکست
این گردش‌کار یک تور ایمنی محلی است، نه یک ابزار امنیتی کامل. این سیستم جایگزین اسکنرهای اسرار یا CODEOWNERS نیست. با این حال، باید مراقب روش‌های دور زدن این محدودیت‌ها بود؛ برای مثال، نقص‌های بحرانی در بررسی مسیرها نشان داده است که چگونه می‌توان از طریق Symlinkها به پوشه‌های غیرمجاز نفوذ کرد.
این حالت‌های شکست را پیش‌بینی کنید:
- تغییر نام: جابه‌جایی فایل به همراه
git add -Aممکن است از الگوهای قدیمی عبور کند. - فایل‌های تولید شده: یک Build ممکن است فایل قفلی ایجاد کند که شما قصد Stage کردنش را نداشتید.
- نشت کلیپ‌بورد: مسیرهای منجمد در گیت، در کلیپ‌بورد شما منجمد نیستند؛ بازبین نمی‌تواند جلوی Paste کردن در چت را بگیرد.
- تغییر خودکار: اگر عامل فایل
.agent-untouchableرا بازنویسی کند، سیستم به خطر می‌افتد. برای جلوگیری از این کار، نام خود این فایل را هم به لیست سیاه اضافه کنید.
علاوه بر این، بازبین فقط رویدادهای گیت را می‌بیند. یک عامل مصمم همچنان می‌تواند فایل منجمد را روی دیسک ویرایش کند؛ Hook فقط مانع از Stage شدن آن می‌شود.
چه کسانی باید این مراحل را رد کنند؟
این دروازه برای اولین PR یک جونیور است. در موارد زیر این مسیر را رد کنید:
- اگر استخدام شده‌اید تا دقیقاً CI را تغییر دهید.
- اگر تیکت شما مربوط به به‌روزرسانی فایل قفل (Lockfile bump) است.
- اگر در یک وضعیت بحرانی (Incident) هستید و مسیر منجمد، راه حل است.
- اگر مهندس Staff با دسترسی ادغام هستید.
از میزبان‌های ابری عامل برای مخازن خصوصی تاییدنشده استفاده نکنید، زیرا یک سرور رایگان، جایگزین بازبینی قانونی نیست.
ابزارها و افشا
این مقاله به عنوان بخشی از معرفی محصول MonkeyCode تهیه شده است. MonkeyCode یک پروژه عامل کدنویسی متن‌باز است که دسترسی رایگان به مدل‌ها و سرور ارائه می‌دهد. در حالی که باید لیست سیاه خود را برای تقویت مهارت جونیوری به صورت دستی بنویسید، می‌توانید از دسترسی رایگان این ابزار برای پیشنهاد الگوهای بیشتر استفاده کنید. از سرور رایگان فقط به عنوان محیط اجرای check-untouchable.sh استفاده کنید اگر لپ‌تاپ شما مشغول است، اما هرگز کلیدهای تولید را آپلود نکنید.
با تلقی کردن عامل به عنوان یک مشارکت‌کننده پرریسک و پیاده‌سازی انجماد مکتوب، توسعه‌دهندگان می‌توانند از سرعت هوش مصنوعی بدون قربانی کردن پایداری مخزن بهره ببرند.
گام بعدی شما
- یک فایل
.agent-untouchableبرای پروژه‌های فعلی خود بسازید و مسیرهای حساس را در آن لیست کنید. - اسکریپت
check-untouchable.shرا بهpre-commit hookگیت خود اضافه کنید تا از اشتباهات لحظه‌ای جلوگیری شود. - در پرامپت‌های خود، مرزهای دسترسی را به صورت صریح و دوگانه (Negative Constraints) تعریف کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو