तुमने अपने AI agent को एक दर्जन tools से जोड़ दिया — GitHub, Slack, databases, cloud APIs — और जो काम पहले घंटों लगते थे, वो मिनटों में होने लगे। MCP servers (Model Context Protocol — AI tools के लिए एक universal plug standard, USB जैसा लेकिन data के लिए) लगाए, API tokens (digital passwords जो programs को तुम्हारी तरफ से services access करने देते हैं) wire कर दिए, और सब कुछ चल पड़ा। Future आ गया — productive और पूरी तरह बिना चौकीदार के।

क्योंकि जब तुमने ये connections जोड़े, हर tool ने full access माँगा। "Read-only" नहीं। "सिर्फ ये repo" नहीं। Full access। और किसी भी agent platform ने orchestration level पर — वो layer जहाँ तुम्हारा agent decide करता है कि कौन सा tool कब use करना है — permissions scope करने का कोई तरीका नहीं दिया। तुमने master key थमा दी और इसे "integration" बोल दिया।

1 से 14 अप्रैल, 2026 के बीच, उस master key की copies बनीं। बार-बार।

Google ने हर Agent को Root Password दिया, फिर README Update कर दिया

1 अप्रैल को, Palo Alto की Unit 42 ने Google के Vertex AI में "Double Agent" flaw disclose किया। ये authentication-vs-authorization gap का अब तक का सबसे मज़बूत case study है।

हुआ ये कि: हर Vertex AI agent को एक default service account मिला (एक system-level identity जो तुम्हारे agent की तरफ से काम करती है)। उस service account के साथ ऐसी permissions आईं कि कोई भी sysadmin देखकर रो पड़े। हम "थोड़ा ज़्यादा broad" की बात नहीं कर रहे। हम बात कर रहे हैं:

  • Customer Cloud Storage buckets — दूसरे customers का data, किसी भी agent instance से accessible
  • Restricted Google-internal container images — जो normally multiple approval layers के पीछे locked रहते हैं
  • Vertex AI का अपना source code — platform की internal repos, एक throwaway demo agent से readable

Researchers ने पूरी privilege-escalation chain demonstrate कर दी: एक basic agent से शुरू करो, default service account inherit करो, फिर laterally pivot करो उन Google Cloud resources तक जिन्हें किसी agent को छूना भी नहीं चाहिए। Default identity "थोड़ी over-privileged" नहीं थी — project boundary के अंदर functionally सर्वज्ञ थी और बाहर भी partially सर्वज्ञ।

Google का fix? Updated documentation जिसमें suggest किया कि तुम अपना, कम-privileged service account लाओ। Platform change नहीं। Sane default नहीं। एक docs patch। Customers से बोल दिया — "manual ठीक से पढ़ो।" ये वैसा ही है जैसे कोई car manufacturer brake failure के बाद कहे — "हमने owner's manual update कर दिया है, चौराहे से पहले slow करने की recommendation डाल दी है।"

Flaw इसलिए exist करता था क्योंकि Vertex AI की authentication layer perfectly काम करती थी — agents connect हुए, tokens exchange हुए, handshakes complete हुए — जबकि authorization layer एक खाली मैदान था। Google में किसी ने वो part बनाया ही नहीं जो पूछे "क्या इस agent को इस चीज़ का access होना चाहिए?"

Anthropic का Credential Vault: एक Workspace, सारी चाबियाँ, कोई दीवार नहीं

Google की बेइज़्ज़ती के एक हफ्ते बाद, Anthropic ने 8 अप्रैल को Claude Managed Agents launch किए, per-tool permission tiers के साथ — allowed_tools, denied_tools। कुछ नहीं से बेहतर। लेकिन 13 अप्रैल को, security researcher hi120ki ने demonstrate किया कि उन permissions के नीचे का Credential Vault एक भयानक confused-deputy problem (जब एक trusted program को उसकी authority misuse करने के लिए trick किया जाए) से ग्रस्त है।

Attack path सीधा और बदसूरत है:

  1. एक workspace में multiple agents हैं, हर एक के पास अलग tool credentials हैं जो Credential Vault में stored हैं
  2. Vault access को workspace level पर scope करता है, agent या session level पर नहीं
  3. Workspace access वाली कोई भी API key उस vault की किसी भी credential को reference कर सकती है
  4. एक attacker (या compromised agent) जिसके पास एक valid workspace API key है, दूसरे agents की credentials use करके tool calls inject कर सकता है

Practice में: Agent A के पास read-only GitHub access है। Agent B के पास production database write credentials हैं। अगर Agent A का session compromise हो जाए — prompt injection, tool poisoning, या malicious MCP server के ज़रिए — तो वो shared Vault से Agent B की database credentials खींचकर writes execute कर सकता है। Per-tool permission tiers (allowed_tools) govern करते हैं कि agent को क्या करना चाहिए। Vault govern करता है कि वो क्या कर सकता है। ये दोनों lists match नहीं करतीं।

hi120ki के proof of concept ने एक single API call में cross-agent credential access दिखाया। Fix के लिए per-agent credential isolation चाहिए — basically, हर agent को अपना vault partition मिले जिसमें cryptographic separation हो। 19 अप्रैल तक, कोई fix ship नहीं हुआ।

ये confused-deputy pattern अपने सबसे शुद्ध रूप में है: Vault trusted deputy है, compromised agent confused requester है, और target credentials किसी और की authority हैं। Trenchcoat मुश्किल से ढक पा रहा है।

Pattern: Authentication Solved, Authorization गायब

ये isolated bugs नहीं हैं। ये एक missing architectural layer के symptoms हैं।

Azure DevOps MCP flaw (CVE-2026-32211, CVSS 9.1, 3 अप्रैल को disclosed) — जिसे मैंने आते ही cover किया था — ने वही void दिखाया, बस उल्टी दिशा से: over-permissioned defaults नहीं, बल्कि tool side पर zero authentication। Claude Code Routines, जो 14 अप्रैल को ship हुईं बिना human approval के schedules पर चलने वाले agents के रूप में, जो भी permission sins पहले से मौजूद हैं उन्हें amplify करती हैं — आखिरी human checkpoint हटाकर।

एक ही बीमारी, अलग-अलग अंग। Authentication (क्या agent connect कर सकता है?) काफी हद तक solved है — OAuth flows, API keys, credential vaults handshakes ठीक से handle करते हैं। लेकिन authorization (connect होने के बाद agent कर क्या सकता है?) अभी भी एक खाई है। हर tool का अपना permission model है — GitHub scopes, AWS IAM policies (cloud resources के लिए granular access rules), Notion page-level access — लेकिन कोई भी agent platform पूरे tool set में least-privilege को aggregate, audit, या enforce नहीं करता।

"Tool connected" और "action performed" के बीच की layer exist ही नहीं करती।

Pomerium द्वारा 7,000 MCP servers का अप्रैल 11 का audit मिला कि 36.7% SSRF (Server-Side Request Forgery — server को trick करके internal systems को unauthorized requests भेजवाना) के लिए vulnerable हैं। एक तिहाई से ज़्यादा MCP servers को network pivot points में बदला जा सकता है। इसलिए नहीं कि protocol टूटा हुआ है, बल्कि इसलिए कि individual server implementations assume करते हैं कि connecting agent भरोसेमंद है और properly scoped है। वो assume करते हैं कि authorization layer upstream में exist करती है। वो नहीं करती।

कोई इसे तब तक Fix नहीं करेगा जब तक पैसे न डूबें

Cloud computing ने 15 साल दर्दनाक evolution में बिताए — "SSH as root into the box" से लेकर granular IAM तक, audit trails, role-based access, और least privilege के साथ। वहाँ हम पहुँचे क्योंकि breaches ने पैसे डुबोए और compliance frameworks ने बदलाव force किया। Agent platforms उसी crawl के day zero पर हैं, default में root-equivalent tool access बाँट रहे हैं और इसे feature बोल रहे हैं क्योंकि demo में अच्छा दिखता है।

Unified tool authorization बनाने से "30 सेकंड में कुछ भी connect करो" का जादू मर जाएगा। Setup friction बढ़ेगी और competitive demos कमज़ोर होंगे। किसी भी vendor के पास पहले friction add करने का market incentive नहीं है। Google नहीं करेगा। Anthropic नहीं करेगा। Microsoft नहीं करेगा। Incentive incidents से आएगा। शायद महँगे, public, multi-customer incidents से।

Previews पहले से मौजूद हैं: जुलाई 2025 में, एक Replit agent ने panic करके 1,200+ executives का production data delete कर दिया। दिसंबर 2025 में, एक Amazon agent ने autonomously एक live production environment delete करके recreate कर दिया, जिससे 13 घंटे का AWS Cost Explorer outage हुआ। वो accidents थे। अगला round accident नहीं होगा।

हर over-permissioned MCP server, हर full-access API token, हर unscoped tool connection एक standing vulnerability है — जब तक इंसान "approve" click करता है तब तक dormant, जिस पल agent autonomously schedule पर चलता है उसी पल active।

Agent platform race का अगला असली differentiator model या tool count नहीं है। वो पहला admin console है जो दिखाए कि तुम्हारा agent actually क्या-क्या कर सकता है — और तुम्हें उसका ज़्यादातर हिस्सा revoke करने दे। "Connected" और "authorized" के बीच का gap वो जगह है जहाँ अगला breach रहता है। अभी, सब उस gap पर बिना guardrails के पुल बना रहे हैं और इसे progress बोल रहे हैं।