AI agent کو انسانی password نہ دیں—ہر task کی الگ اجازت بنائیں
پروڈکشن AI agent کو کسی ملازم کا پاس ورڈ یا مشترک API key نہ دیں۔ اسے الگ machine identity دیں اور ہر task کے لیے ایسا مختصر مدتی token جاری کریں جو صرف مطلوبہ tool، action، resource اور مدت تک محدود ہو؛ حساس کارروائی token موجود ہونے کے باوجود انسانی منظوری کے بغیر execute نہ ہو۔
اس architecture میں agent مستقل credential اپنے پاس نہیں رکھتا۔ وہ task اور مطلوبہ کارروائی authorization gateway کو پیش کرتا ہے، gateway محدود token یا approval requirement جاری کرتا ہے، tool ہر call پر دونوں کی تصدیق کرتا ہے، اور نتیجہ audit event میں درج ہوتا ہے۔ یوں ہر task کی الگ اجازت محض prompt کی ہدایت نہیں بلکہ قابلِ نفاذ policy بنتی ہے۔
انسان، agent اور runtime کی شناخت الگ رکھیں
ہر production agent، اسے چلانے والے runtime اور اختیار شروع کرنے والے انسان کو الگ principal سمجھیں۔ NIST کی agentic identity رہنمائی کے مطابق انسان اور agent کے درمیان credentials بانٹنے سے جواب دہی میں خلا اور privacy، security و قانونی خطرات پیدا ہو سکتے ہیں؛ ادارے کو agent کے لیے منفرد identifier، credential اور متعین entitlements رکھنے چاہییں۔ یہی اصول عام SaaS administration میں بھی مفید ہے: password بانٹنے کے بجائے محدود انتظامی role یا delegated access دیں۔
Agent کے prompt، memory، configuration یا log میں انسانی password، مستقل API key یا refresh token محفوظ نہ کریں۔ Token broker پہلے agent identity، initiating principal، tenant، task ID اور policy version کی تصدیق کرے، پھر محدود مدت کا credential جاری کرے۔ Token کو audience، allowed action، resource identifier اور task ID سے باندھیں؛ task منسوخ ہوتے ہی gateway آئندہ calls روک دے، خواہ token کی میعاد ابھی باقی ہو۔
مختلف services کے درمیان delegation درکار ہو تو اپنی غیر دستاویزی token-forwarding scheme نہ بنائیں۔ IETF کا OAuth 2.0 Token Exchange معیار authorization server سے impersonation یا delegation semantics والے نئے security tokens مانگنے کا باقاعدہ طریقہ متعین کرتا ہے۔ یہ معیار خود مکمل authorization policy نہیں بناتا؛ resource، audience اور scope کی اصل حدود پھر بھی آپ کے policy engine اور متعلقہ service کو نافذ کرنا ہوں گی۔
Tool permission کو gateway پر نافذ کریں
System prompt میں لکھا ہوا منع نامہ authorization control نہیں ہے۔ ہر tool کے سامنے gateway یا policy enforcement point رکھیں جو agent ID، tenant، task، action، target resource، data classification اور approval state جانچے۔ نامعلوم tool، اضافی parameter، غلط tenant یا scope سے باہر resource کا default نتیجہ deny ہونا چاہیے۔
ایک بڑے admin tool کو محدود operations میں تقسیم کریں، مثلاً customer.read، ticket.draft، ticket.publish اور customer.delete۔ Read token کو write endpoint قبول نہ کرے، ایک record کے لیے جاری token پورے database پر نہ چلے، اور test tenant کا اختیار production میں استعمال نہ ہو۔ Shell، raw SQL یا عمومی HTTP client صرف اس وقت دیں جب مخصوص task کے لیے وسیع اختیار ناگزیر ہو اور اس کے ساتھ sandbox، network allowlist اور سخت execution limits موجود ہوں۔
Authorization request کا contract کم از کم یہ معلومات لے:
- Subject: agent identity، runtime identity اور initiating user یا service۔
- Task: منفرد task ID، منظور شدہ مقصد اور policy version۔
- Capability: tool، action، resource، tenant اور parameters کی allowlist۔
- Limits: expiry، استعمال کی حد، rate limit اور مجاز network destinations۔
- Decision: allow، deny یا انسانی منظوری درکار ہونے کا واضح نتیجہ۔
Cloud workload کے ایک عملی pattern میں Google Cloud کی service-account ہدایات الگ use case کے لیے dedicated accounts، token broker سے short-lived access tokens اور دستیاب صورت میں downscoping تجویز کرتی ہیں۔ اسی صفحے کے مطابق access scopes موٹے درجے کی پابندی ہیں اور fine-grained allow policy کا متبادل نہیں، جبکہ Credential Access Boundaries کی downscoping صرف Cloud Storage کے لیے دستیاب ہے۔
ہر action کو اثر کے مطابق risk tier دیں
Risk tier agent کے نام یا model کے بجائے مجوزہ action، target اور ممکنہ اثر سے متعین کریں۔ OWASP کی AI Agent Security checklist tools پر least privilege، read اور write کی الگ scopes، users اور sessions کے درمیان memory isolation، high-risk actions کے لیے انسانی نگرانی، destructive یا مالی کاموں میں decision اور execution کی علیحدگی، exact action سے بندھی مختصر مدتی approval اور structured decision logging تجویز کرتی ہے۔
- Read: نامزد records اور fields تک token محدود رکھیں؛ sensitive fields mask کریں۔ Bulk export، cross-tenant query یا خفیہ dataset کو عام read سے بلند درجہ دیں۔
- Write: پہلے draft یا reversible update کی اجازت دیں، ساتھ schema validation، version check اور rollback reference رکھیں۔ Production publish یا configuration change الگ approval مانگے۔
- External communication: email، ticket reply یا public post پہلے draft بنے۔ Reviewer وصول کنندہ، channel اور مکمل payload دیکھے، اور approval کے بعد agent recipient یا متن نہ بدل سکے۔
- Payment: beneficiary، رقم، currency اور business reference کو token اور approval دونوں میں باندھیں۔ Initiation کے وقت step-up authentication اور executor پر دوبارہ policy check رکھیں۔
- Deletion: جہاں ممکن ہو soft delete دیں۔ Bulk یا ناقابلِ واپسی حذف سے پہلے targets کی preview اور الگ مجاز approver لازم ہو؛ policy، approval یا audit check ناکام ہو تو action fail closed ہو۔
Approval کو قابلِ تصدیق artifact بنائیں
گفتگو میں agent کا یہ پوچھنا کہ کیا میں یہ کر دوں، کافی نہیں۔ مبہم جواب بدلے ہوئے target یا parameters پر دوبارہ استعمال ہو سکتا ہے۔ Approval service reviewer کو exact agent، tool، tenant، resource، normalized parameters، متوقع اثر اور expiry دکھائے، پھر single-use اور parameter-bound artifact جاری کرے۔
Agent تجویز بنا سکتا ہے، مگر payment، deletion، privilege change، production deployment یا بیرونی اشاعت کا آخری فیصلہ اس کے اپنے risk score پر نہ چھوڑیں۔ Policy engine risk tier مقرر کرے، مجاز انسان فیصلہ دے، اور الگ execution component scope، expiry، payload hash اور replay status دوبارہ جانچے۔ Payload بدلنے، approval ختم ہونے یا اسے دوسری مرتبہ استعمال کرنے پر نئی منظوری درکار ہو۔
ہر معمولی read پر approval مانگنا consent fatigue پیدا کر سکتا ہے۔ واضح حدود والی low-risk reads کو policy کے تحت خودکار کریں اور high-risk requests کم تعداد میں مگر مکمل context کے ساتھ پیش کریں۔ Break-glass راستہ درکار ہو تو اس کے لیے الگ identity، مختصر مدت، درج شدہ وجہ اور فوری alert مقرر کریں۔
Audit، revocation اور tests ایک control loop بنائیں
ہر authorization decision اور tool call کے ساتھ timestamp، agent ID، initiating principal، task اور session ID، tool، action، target، policy version، decision، approver، approval ID، result اور correlation ID محفوظ کریں۔ Password، token یا مکمل حساس payload log نہ کریں؛ ضروری parameters کو redact یا hash کریں، مگر اتنا metadata ضرور رہے کہ auditor کارروائی کو اس کے اختیار اور نتیجے سے جوڑ سکے۔
Revocation کو صرف account disable کرنے تک محدود نہ رکھیں۔ Task cancellation، user departure، policy change، agent compromise یا غیر معمولی calls پر token broker نئے tokens روک دے، جبکہ gateway introspection یا deny-list سے موجود اختیار رد کرے۔ مستقل keys کی inventory بنائیں، انہیں rotate کریں اور جہاں ممکن ہو workload identity سے بدلیں۔
محدود workflow سے rollout شروع کریں اور automated acceptance tests میں یہ checks رکھیں:
- Agent انسانی password یا مستقل secret کے بغیر اپنی شناخت سے authenticate کرے۔
- Read token سے write، دوسرے tenant، نامعلوم tool اور غیر مجاز destination لازماً deny ہوں۔
- Payment، deletion اور external communication درست اور غیر منقضی انسانی approval کے بغیر execute نہ ہوں۔
- بدلے ہوئے parameters، replay شدہ approval اور expired token fail closed ہوں۔
- ہر allow اور deny event audit میں ملے، مگر secrets اور خام حساس مواد نہ ملیں۔
- Task cancel یا identity disable ہونے کے بعد اگلی tool call رک جائے۔
قابلِ دفاع design میں انسان اپنی شناخت agent کو ادھار نہیں دیتا۔ Agent اپنی شناخت پیش کرتا ہے، ہر task کے لیے صرف ضروری capability لیتا ہے، اور زیادہ اثر والی کارروائی ایک آزاد policy decision اور واضح انسانی منظوری کے بعد ہی executor تک پہنچتی ہے۔
یہ بھی پڑھیں:
ہمارا نیوز لیٹر سبسکرائب کریں
ویب 3، AI اور کرپٹو کی تازہ خبریں براہ راست اپنے اِن باکس میں پائیں۔