तुमने अपने AI agent को Slack, GitHub, और Jira से connect किया। Platform ने एक प्यारा सा dialog दिखाया: "Slack access allow करें?" तुमने yes दबा दिया। लगा कि सब control में है। ज़िम्मेदारी से काम हो रहा है।
पर नहीं भाई। Agent ने तुम्हारे CEO को DM में एक bug report भेज दिया जो #engineering channel के लिए था। उस permission gate ने कभी पूछा ही नहीं कि recipients कौन हैं, channel कौनसा है, या "Slack access" का मतलब असल में क्या होता है जब एक machine के हाथ में चाबियाँ हों।
तीन platforms, एक ही pattern, zero depth
दो हफ्ते पहले बात हो रही थी कि agent platforms में meaningful authorization है ही नहीं — agents के पास root access है और sudo बनाने वाला कोई नहीं। वो बात अब पुरानी हो चुकी। तीनों major platforms ने अपना जवाब भेज दिया है: tool-approval workflows, वो "Are you sure?" prompts जो AI agent (एक program जो तुम्हारी तरफ से काम करता है, सिर्फ chat नहीं करता) कुछ बड़ा करने से पहले pop up होते हैं। Authorization gap भरा नहीं गया है। बस उसके ऊपर wallpaper लगा दिया गया है।
Google का ADK Cloud Next (22-24 April) में action confirmations लेकर आया। Anthropic के Managed Agents, 8 April को launch हुए, पहले दिन से per-tool permission policies के साथ। OpenAI का Agents SDK 15 April के update में needs_approval callbacks लेकर आया। तीन कंपनियाँ, एक ही idea पर converge कर रही हैं — जैसे तीन architects ने independently एक ही टपकती छत design कर दी हो।
Pattern तीनों में identical है: तुम tool level पर approve या deny करते हो। "Allow Slack" या "Deny Slack"। Binary। On या off। Building के gate पर ID check करने वाला bouncer, जबकि अंदर हर apartment का दरवाज़ा खुला है।
असली खतरा कहाँ है
एक गलत tool call का blast radius — जो नुकसान वो actually कर सकता है — parameters में छिपा है: message किस Slack channel में जाएगा, कौनसी Git branch पर force-push होगा, production database पर कौनसी SQL query चलेगी, agent किस Jira project में auto-generated tickets की बाढ़ ला देगा।
Fair enough, Google ADK और OpenAI tool-call parameters को developer-written callbacks में pass करते हैं। तुम return amount > 1000 जैसा code लिख सकते हो expensive operations block करने के लिए। लेकिन यहाँ critical फ़र्क है: platform तुम्हें hook देता है, safety net नहीं। Rules तुम खुद लिखो, raw Python में, हर tool के लिए, हर parameter के लिए, हर edge case के लिए। कोई declarative policy engine नहीं। कोई built-in allowlists नहीं। कोई dashboard में "सिर्फ #engineering और #random में post करो" वाला toggle नहीं।
Anthropic का implementation और भी simple है — उनकी permission policies purely tool names पर operate करती हैं। user.tool_confirmation event बस दो responses accept करता है: "allow" या "deny"। Argument constraints के लिए कोई field नहीं। कोई conditional logic नहीं। Agent या तो Slack use कर सकता है या नहीं।
जैसा कि security researcher Simon Willison ने September 2024 में लिखा: "एक बार जब LLM agent ने untrusted input ingest कर लिया, तो उसे इतना constrain किया जाना चाहिए कि उस input से कोई भी consequential action trigger होना impossible हो।" Tool-level gates ये achieve नहीं करते। वो constrain करते हैं कि कौनसे actions exist करते हैं, ये नहीं कि वो actions करते क्या हैं।
ये फिल्म पहले भी देखी है
ये pattern 2008 के mobile permissions का copy-paste है। Android 1.0 में blanket "camera access" मिलता था — selfie app और एक document scanner जो चुपचाप तुम्हारी desk की photos खींच रहा है, दोनों में कोई फ़र्क नहीं। Google को सात साल लगे और Android 6.0 Marshmallow (2015) आया तब runtime permission scoping आई — contextual controls कि app camera कैसे use करता है, सिर्फ करता है या नहीं नहीं।
Agent platforms आज Android 1.0 stage पर हैं। Permission dialog exist करता है। Security जैसा feel होता है। लेकिन है नहीं।
Microsoft ने वो बात बोल दी जो सब सोच रहे थे
22 April को Microsoft के developer blog ने एक सीधी बात कही: "Instruction-following alone को security boundary नहीं मानना चाहिए।" उनकी अपनी red-team testing — जो इसी महीने open-source किए गए Agent Governance Toolkit के तहत हुई — ने prompt-only guardrails के साथ 26.67% policy violation rate दिखाया। हर चार में से एक dangerous call निकल जाता है अगर तुम LLM पर भरोसा करके बैठ जाओ कि वो खुद ही police कर लेगा।
AGT सबसे करीब है एक real solution के: एक middleware layer जो तुम्हारे agent और उसके tools के बीच बैठता है, YAML, OPA, या Cedar में लिखी declarative policy rules enforce करता है। ये actually parameters inspect करता है। ये actually argument values पर gate करता है। लेकिन ये middleware है जो तुम खुद bolt on करते हो — किसी भी agent platform में native नहीं है। अच्छा jugaad है, पर jugaad ही है।
सही तरीके से करने की कीमत
Parameter-level gating genuinely मुश्किल है। इसमें semantic understanding चाहिए — ये जानना कि #general public channel है जबकि #exec-compensation नहीं है। ये हर tool call में latency add करता है उन systems में जो पहले से context window limits (AI कितना text एक बार में "देख" सकता है) से जूझ रहे हैं। और सबसे बुरी बात, ये approval fatigue पैदा करता है: gates जितने granular होंगे, users उतनी तेज़ी से बिना पढ़े "approve all" दबाना सीख लेंगे — बिल्कुल वही behavior जो permissions को नाटक बना देता है।
तुम्हें actually क्या करना चाहिए
जब तक platforms parameter-aware gates native feature के तौर पर ship नहीं करते, तुम्हारे पास दो ईमानदार options हैं। एक: middleware बनाओ जो tool-call arguments को allowlists के against check करे — safe channels, safe branches, safe query patterns। दो: accept करो कि "Allow Slack" click करने का मतलब है "agent को Slack API जो कुछ भी support करता है वो सब करने दो," और उसी हिसाब से plan करो।
तुम्हारे agent platform पर permission dialog एक placebo है। ये control करता है कि agent कौनसे दरवाज़े खोल सकता है, लेकिन ये नहीं कि agent कमरे के अंदर क्या करता है। तीन platforms ने April 2026 में एक ही ताला ship किया, और किसी ने भी deadbolt नहीं लगाया।
