Semantic firewall ہر AI agent نہیں بچاتا، اصل حد privileged tool ہے

Semantic firewall ایک pre-execution mediation تہہ ہے: یہ AI agent سے آنے والے prompt، memory update، tool argument، command یا data payload کو اثر پیدا ہونے سے پہلے جانچ کر allow، block، redact، rewrite یا review کے لیے روک سکتی ہے۔ اس کا کام مجوزہ کارروائی کے ارادے، سیاق اور منزل کو دیکھنا ہے، نہ کہ agent کو خود بخود محفوظ قرار دینا۔

اصل حفاظتی حد privileged tool پر قائم ہوتی ہے۔ اگر agent کی identity کو production database حذف کرنے، credentials پڑھنے یا حساس data باہر بھیجنے کا وسیع اختیار حاصل ہو تو semantic auditor کی ایک غلط اجازت نقصان کے لیے کافی ہے؛ identity، least privilege، sandbox اور sink-side authorization ہی اس غلطی کا ممکنہ اثر محدود کرتے ہیں۔

Semantic firewall کہاں بیٹھتا اور کیا دیکھتا ہے؟

یہ control agent runtime اور اس boundary کے درمیان ہونا چاہیے جہاں متن کسی state change یا executable action میں بدلتا ہے۔ صرف ابتدائی user prompt کو filter کرنا ناکافی ہے، کیونکہ خطرناک ہدایت retrieved document، email، tool response، persistent memory یا دوسرے agent کے message سے بھی آ سکتی ہے۔

Operant کے 27 اگست 2026 کے اعلان کے مطابق اس کا Semantic Firewall prompts، model responses، tool calls، commands اور data movement پر inline allow، block یا redact فیصلے دیتا ہے اور اسی روز AI Defense Platform میں دستیاب کیا گیا۔ یہ functionality اور availability کمپنی کا اپنا دعویٰ ہے، آزاد تقابلی نتیجہ نہیں؛ عمومی architecture pattern کو اس vendor label سے الگ رکھنا چاہیے۔

کوئی implementation تبھی مفید ہے جب وہ ہر اہم execution path پر واقعی inline ہو۔ اگر agent کسی براہ راست SDK، browser automation، غیر رجسٹرڈ MCP server یا background job کے ذریعے mediator کے بغیر کارروائی کر سکتا ہے تو firewall اس call کا مطلب جانچ ہی نہیں پائے گا۔

Source سے sink تک اصل حفاظتی راستہ

Security architect کے لیے مفید نقشہ model کے نام سے نہیں بلکہ source، transformation اور sink سے شروع ہوتا ہے۔ ہر منتقلی کے ساتھ provenance، requesting identity، task scope، data classification اور مطلوبہ capability محفوظ نہ ہو تو semantic auditor کے پاس قابل دفاع فیصلہ کرنے کے لیے پورا context نہیں ہوگا۔

1. Sources: user prompt، retrieved file، web content، email، دوسرے agent کا message، tool output اور محفوظ memory۔
2. Transformations: model response، planning step، memory update، skill selection اور tool arguments کی تیاری۔
3. Mediation point: policy engine مجوزہ action، arguments، payload، identity اور task scope کو آخری محفوظ مقام پر جانچتا ہے۔
4. Privileged sinks: shell، package installer، database write، payment API، identity provider، cloud control plane، email sender یا external upload endpoint۔
5. Enforcement: allow، محدود rewrite یا redaction، انسانی منظوری، sandbox میں execution یا block؛ verdict کے ساتھ audit record بھی محفوظ ہو۔

TokenWall کے تحقیقی preprint میں memory updates، retrieved files، tool arguments اور inter-component messages کے source-to-sink records بنا کر privileged sinks سے پہلے مقامی inspection اور مبہم high-risk cases کی stronger arbitration تجویز کی گئی ہے۔ CIK-Bench پر اسی مخصوص configuration کا attack success rate 12.5 فیصد، benign executable pass rate 97.4 فیصد اور benign cases پر اضافی latency 0.69 سیکنڈ رہی؛ بچ جانے والا attack rate خود بتاتا ہے کہ یہ مکمل تحفظ کی ضمانت نہیں۔

Pre-execution mediation کہاں فائدہ دیتی ہے؟

اس تہہ کی خاص قدر وہاں ہے جہاں endpoint تکنیکی طور پر جائز ہو مگر arguments، destination یا مقصد خطرناک ہو۔ ایک CRM export API allowlist میں شامل ہو سکتی ہے، لیکن پورا customer table ذاتی mailbox پر بھیجنے کی درخواست task scope سے باہر ہوگی؛ semantic policy action، payload اور destination کو ایک ہی فیصلے میں دیکھ سکتی ہے۔

یہ delayed risk کے خلاف بھی دوسرا checkpoint فراہم کرتی ہے۔ ایک poisoned document فوری command چلانے کے بجائے memory میں ایسی ہدایت محفوظ کر سکتا ہے جو کئی turns بعد tool call بنے؛ memory write اور آخری privileged sink دونوں mediated ہوں تو آلودہ state کو محفوظ ہونے اور پھر اثر پیدا کرنے سے پہلے الگ الگ روکا جا سکتا ہے۔

Redaction پورا workflow بند کیے بغیر حساس fields نکال سکتی ہے، مگر صرف model کا یہ کہنا کافی نہیں کہ data صاف ہو گیا۔ Rewrite کے بعد schema validation، destination policy اور data-loss controls کو یہ ثابت کرنا چاہیے کہ ممنوع fields واقعی خارج ہیں اور tool کو اضافی capability نہیں ملی۔

یہ تہہ کہاں ناکام یا نامکمل رہتی ہے؟

پہلا مسئلہ coverage gap ہے: asynchronous jobs، cached credentials، tool کے اندر ہونے والی ثانوی calls یا mediator سے باہر کا execution path مرکزی inspection کو نظر نہیں آتا۔ Architecture diagram میں صرف agent-to-tool arrow دکھانا کافی نہیں؛ ہر ایسے راستے کی inventory درکار ہے جہاں state، authority، code یا data کسی محفوظ boundary کو عبور کرتا ہے۔

دوسرا مسئلہ classification error ہے۔ مبہم business language جائز کارروائی کو false positive کے طور پر روک سکتی ہے، جبکہ encoded payload، معمولی wording change یا کئی بے ضرر نظر آنے والی calls میں تقسیم شدہ کارروائی false negative بن سکتی ہے۔ ایک research benchmark کے نتائج کو دوسرے models، زبانوں، tools اور enterprise policies پر عمومی شرح نہیں سمجھا جا سکتا۔

تیسرا مسئلہ enforcement plane کا اپنا اعتماد ہے۔ TokenWall کی threat model بھی یہ فرض کرتی ہے کہ حملہ آور underlying host کو compromise، firewall کو bypass یا tamper، اور محفوظ runtime metadata یا audit logs کو تبدیل نہیں کر سکتا؛ حقیقی deployment میں انہی assumptions کو الگ controls سے نافذ کرنا ہوگا۔ Agent policy بدل سکے، auditor بند کر سکے یا bypass credential پڑھ سکے تو semantic inspection خود ایک کمزور privileged dependency بن جاتی ہے۔

Privileged tool ہی آخری حد کیوں ہے؟

Semantic firewall اندازہ لگاتا ہے کہ درخواست policy کے مطابق معلوم ہوتی ہے یا نہیں؛ authorization system طے کرتا ہے کہ caller حقیقتاً کیا کر سکتا ہے۔ NIST کی least-privilege تعریف users یا ان کی طرف سے کام کرنے والے processes کو assigned task کے لیے درکار کم سے کم access تک محدود کرتی ہے۔ AI agent بھی ایسا ہی process ہے، اس لیے semantic approval اضافی شرط ہے، بنیادی credential نہیں۔

مضبوط design میں ہر agent اور حساس tool کی الگ workload identity ہو، credentials مختصر مدت اور task سے بندھے ہوں، read اور write scopes جدا ہوں، اور destructive operations کے لیے step-up approval یا two-phase commit رکھا جائے۔ Code execution کو محدود filesystem، network egress policy اور resource quotas والا sandbox ملنا چاہیے؛ agent isolation کی عملی حدیں اسی capability boundary کا متعلقہ پہلو ہیں۔

Authorization آخری tool یا service پر دوبارہ نافذ ہونی چاہیے۔ اگر semantic layer bulk export کو مناسب سمجھ لے لیکن database identity صرف محدود rows پڑھ سکتی ہو، تو غلط verdict کا blast radius پہلے ہی چھوٹا رہتا ہے؛ یہی selected title میں privileged tool کو اصل حد کہنے کی وجہ ہے۔

Design review میں کن سوالات کا جواب درکار ہے؟

Vendor کا یہ کہنا کافی نہیں کہ system intent سمجھتا ہے۔ Architecture review میں یہ معلوم ہونا چاہیے کہ mediation کن prompts، memories، tools، commands اور payloads پر نافذ ہے؛ bypass paths کیسے بند ہیں؛ policy اور identity کس trust boundary میں رہتے ہیں؛ اور timeout، malformed verdict یا auditor failure پر runtime fail-open ہوتا ہے یا fail-closed۔

• ہر privileged sink کے سامنے deterministic authorization موجود ہو، خواہ semantic verdict allow ہو۔
• اردو، انگریزی اور code-mixed prompts پر false-positive، false-negative اور bypass tests ادارے کی اپنی data classifications کے ساتھ ہوں۔
• اوسط کے ساتھ tail latency، escalation rate، blocked benign actions اور missed attacks الگ ناپے جائیں۔
• Audit record میں source provenance، normalized arguments، policy version، workload identity، verdict اور آخری tool outcome شامل ہوں۔
• Policy engine unavailable ہو تو high-risk calls کا failure behavior پہلے سے متعین اور آزمودہ ہو۔

Semantic firewall agent loop میں مفید contextual checkpoint ہے، مگر capability boundary نہیں۔ محفوظ architecture میں یہ مشکوک semantic flow کو اثر سے پہلے روکتا ہے، جبکہ identity، least privilege، sandbox اور sink-side validation یہ یقینی بناتے ہیں کہ بچ جانے والی غلطی پورے production environment کے اختیار میں تبدیل نہ ہو۔

یہ بھی پڑھیں:

• OpenAI کا AI sandbox سے نکل گیا: Hugging Face واقعے کے اصل سبق
• Claude AI صرف chatbot نہیں: کام، coding اور منصوبوں کی اصل حدیں
• 700 AI ایجنٹس نے Hugging Face پر حملہ کیا—اصل ناکامی کہاں ہوئی؟