तुम्हारी टीम ने पिछले दो हफ्तों में Notion, Jira और GitHub पर AI agents लॉन्च कर दिए। Onboarding बेशर्मी की हद तक आसान थी — एक API key (एक पासवर्ड जो सॉफ्टवेयर को दूसरे सॉफ्टवेयर से बात करने देता है), कुछ क्लिक्स, शायद एक चाय का ब्रेक। Agent तुम्हारे tickets पढ़ता है, code push करता है, Slack पर पोस्ट करता है। लगा कि future आ गया भई।

फिर pilot खत्म हुआ। या security टीम की नींद टूटी। या vendor बदल लिया। और अब तुम्हें वो सवाल का जवाब देना है जो किसी ने पूछने की जहमत ही नहीं उठाई: agent को बंद कैसे करें?

Cloud Security Alliance का survey, जो कल 21 अप्रैल को आया, इस gap पर नंबर डालता है: सिर्फ 21% enterprises के पास AI agents को decommission करने की कोई formal प्रक्रिया है। इधर, 65% ने पिछले साल agent-related security incidents का सामना किया है। Anthropic ने 8 अप्रैल को Managed Agents शिप किया, OpenAI ने 15 अप्रैल को Agents SDK अपडेट किया, और Google ने 22 अप्रैल को Cloud Next पर अपना agent platform पेश किया — दो हफ्तों में तीन production-grade लॉन्च। हर platform ने detailed onboarding guides पब्लिश कीं। किसी ने भी — literally शून्य ने — offboarding guide नहीं बनाई।

"बंद करना" असल में मतलब क्या है

Agent को decommission करना कोई स्विच ऑफ करना नहीं है। ये ऐसे employee को निकालने जैसा है जिसके पास हर ऑफिस की चाबी है, हर बातचीत याद है, और जिसने दर्जन automated workflows सेट किए हैं जो किसी और को समझ नहीं आते।

यहाँ वो checklist है जो किसी ने लिखी नहीं:

  • OAuth tokens रिवोक करो — OAuth वो सिस्टम है जो agent को तुम्हारी तरफ से tools (GitHub, Jira, Slack) access करने देता है। जब तुम agent को किसी tool से "connect" करते हो, तो एक token मिलता है — एक डिजिटल पास। वो पास agent की subscription बंद करने पर expire नहीं होता। बस वहीं पड़ा रहता है, valid और भूला हुआ।
  • Memory stores मिटाओ — Agents के पास अब persistent memory है: वो past conversations, decisions, और तुम्हारा data याद रखते हैं। Anthropic का Memory Stores API एक-एक करके memories delete करने देता है, लेकिन bulk-delete endpoint नहीं है। सब कुछ मिटाना है? हर एक memory enumerate करो और individually delete करो। मज़ा आएगा।
  • Scheduled actions कैंसिल करो — Agents cron schedules पर चल सकते हैं (automated recurring tasks, जैसे "हर सुबह 9 बजे ये repo चेक करो")। ये schedules बनाने वाले user की identity के तहत persist करते हैं। User कंपनी छोड़ दे, cron चलता रहेगा।
  • Open work reassign करो — अगर agent के पास open pull requests, assigned tickets, या pending reviews थे, तो वो अब एक भूत के नाम हैं।
  • Dependent agents को बताओ — Multi-agent setups में, दूसरे agents retired वाले को call कर सकते हैं। वो silently fail होंगे या, worse, हमेशा के लिए hang हो जाएंगे।

कोई भी platform इसमें से कुछ भी automate नहीं करता।

नंबर उतने बुरे नहीं, उससे भी बुरे हैं

Token Security के CEO Itamar Apelblat के अनुसार, जिनका 9 अप्रैल को इंटरव्यू हुआ: 65.4% agentic chatbots बनने के बाद कभी use नहीं हुए — फिर भी उनके पास production tools के live access credentials हैं। आधे से ज़्यादा external agent actions OAuth की जगह hard-coded credentials पर चलते हैं — मतलब standard identity management से revoke भी नहीं कर सकते।

"कई organizations अभी भी AI agents को governed identities की तरह नहीं, बल्कि disposable productivity experiments की तरह treat कर रहे हैं," Apelblat ने Help Net Security को बताया।

वो polite हो रहे हैं। असल में कहना ये है: तुमने एक bot बनाया जिसे production database का read access दिया, बोर हो गए, और गाड़ी में चाबी लगाकर छोड़ दिया।

असली खतरा: zombie credentials

खतरा zombie agent खुद नहीं है। मरा हुआ agent जो चल नहीं सकता, वो harmless है। खतरा zombie credentials हैं — वो OAuth tokens, API keys, और service account permissions जो agent के बाद भी ज़िंदा रहते हैं।

एक agent जिसे Jira पढ़ने, GitHub पर push करने, और Slack में पोस्ट करने का authorization मिला था — वो permissions Anthropic या OpenAI को पैसे देना बंद करने पर नहीं जातीं। वो grants तुम्हारे identity provider, SaaS apps, cloud IAM (Identity and Access Management — वो system जो control करता है कि किसे किस चीज़ का access है) में रहते हैं। Agent platform को पता भी नहीं होता कि ये exist करते हैं, क्योंकि उसने ये दिए ही नहीं थे।

Microsoft ने ये problem तीन हफ्ते पहले पहचाना जब उसने 2 अप्रैल को Agent Governance Toolkit open-source किया — सात packages जो सभी 10 OWASP Agentic AI risks cover करते हैं (OWASP application security threats की standard catalog है), साथ में emergency "kill switch" और "trust decay" model जो समय के साथ agent permissions कम करता है। सुनने में शानदार लगता है। लेकिन docs ध्यान से पढ़ो: वो runtime security cover करते हैं — agent ज़िंदा है तब क्या होता है। Decommissioning या credential cleanup cover नहीं करते। Toolkit agent पर नज़र रखने में मदद करता है। दफनाने में नहीं।

CSA की Hillary Baron, AVP of Research, ने 21 अप्रैल को कहा: "AI agent security and governance एक interconnected system है जो visibility, lifecycle management, policy, और monitoring तक फैला है।" हिंदी में: तुम्हें हर agent को देखना है, उसकी पूरी life birth से death तक manage करनी है, rules set करने हैं, और सब कुछ watch करना है। Enterprises फिलहाल इसमें से लगभग कुछ भी नहीं करते।

ये पहले भी हो चुका है

Employee offboarding — जब कोई कंपनी छोड़ता है तो access revoke करने की formal process — को enterprises ने SCIM (services में user accounts automatically manage करने का protocol) और JML provisioning (Joiners, Movers, Leavers — HR-to-IT workflow) जैसे standards में codify करने में करीब 20 साल लगाए। बीस साल, और ज़्यादातर कंपनियां अभी भी गलत करती हैं।

Agent offboarding day zero पर है। लेकिन enterprises agents को उतनी तेज़ी से deploy करते हैं जितनी तेज़ी से उन्होंने कभी इंसानों को hire नहीं किया। CSA survey में पाया गया कि 51% shadow agents — ऐसे agents जिन्हें किसी ने officially approve नहीं किया — internal automation और scripting से आते हैं। तुम्हारे developers agents उसी तरह spin up करते हैं जैसे 2012 में EC2 instances करते थे: तेज़, सस्ते, और बिना ये सोचे कि सफाई कौन करेगा।

वो platform जो agent lifecycle management शिप करेगा — deploy-to-decommission workflow जिसमें credential cascade, memory purge, और dependency notification हो — वो enterprise procurement जीतेगा। तब तक, हर retired agent एक दरवाज़ा है जिसे लॉक करना तुम भूल गए। और तुम्हारे पास बहुत सारे दरवाज़े हैं।