पहचान विक्रेता Curity के CTO Jacob Ideskog ने इस सप्ताह एक लेख प्रकाशित किया जिसमें तर्क दिया गया कि अधिकांश उद्यम जो IAM स्टैक चलाते हैं वो एक मॉडल के आसपास डिज़ाइन किए गए थे — एक मानव लॉग इन करता है, सत्र टोकन प्राप्त करता है, उस सत्र के भीतर कार्यवाही करता है — जिसे AI एजेंटों की वर्तमान पीढ़ी तोड़ रही है। वे जो हेडलाइन सांख्यिकी उद्धृत करते हैं वो यह है कि गैर-मानवीय पहचान अब आधुनिक उद्यम प्रणालियों में सभी प्रमाणीकरणों के 90% से अधिक के लिए जिम्मेदार हैं। आप Curity की सटीक संख्या पर भरोसा करें या नहीं, दिशात्मक दावा हर क्लाउड सुरक्षा टीम पिछले एक साल से जो कह रही है उसके साथ संगत है: सेवा खाते, CI/CD पाइपलाइन, स्वचालन रनर्स, और अब LLM-संचालित एजेंट प्रमाणीकरण ट्रैफ़िक का बड़ा हिस्सा कर रहे हैं, और उनके आसपास के नियंत्रण मानव-केंद्रित डिज़ाइन धारणाओं के अनुप्रवाह में हैं जो अब वर्कलोड से मेल नहीं खाते।
Ideskog जिन विशिष्ट आर्किटेक्चरल विफलता मोड्स को सूचीबद्ध करते हैं वे वास्तविक हैं। वर्तमान IAM एक सत्र की शुरुआत में एक एकल प्रमाणीकरण द्वार मानता है। एजेंट इस तरह काम नहीं करते; वे सेवाओं के बीच मल्टी-स्टेप API चेन करते हैं, अक्सर मिनटों या घंटों तक फैले हुए, चरणों के बीच कोई मानव लूप में नहीं। वे जिसने एजेंट लॉन्च किया उसकी अनुमतियाँ विरासत में पाते हैं, जिसका मतलब है एक अकेला समझौता हुआ एजेंट टोकन एक हमलावर को एजेंट शुरू करने वाले उपयोगकर्ता का व्यापक अनुमति सेट देता है, उस संकीर्ण अनुमति सेट के बजाय जो एजेंट को लेना चाहिए था। स्थायी एक्सेस टोकन जो लॉग-इन कर्मचारी के लिए ठीक काम करते थे, जब एजेंट अपने आप तय कर रहा है कि कौन सी APIs कॉल करनी हैं तो एक देयता बन जाते हैं। और दोहरी-पहचान समस्या — एजेंट की अपनी पहचान है और वो किसी उपयोगकर्ता की ओर से कार्य करता है — के पास अधिकांश मौजूदा IAM स्टैक्स में कोई साफ़ प्राइमिटिव नहीं है।
अनुशंसित पैटर्न वास्तव में समझदार है और वास्तव में Curity के स्वामित्व का नहीं है। उपयोगकर्ता-केंद्रित के बजाय अनुप्रयोग-केंद्रित प्राधिकरण। स्थायी टोकन के बजाय विशिष्ट कार्यों और समय खिड़कियों के लिए स्कोप किए गए जस्ट-इन-टाइम, न्यूनतम-विशेषाधिकार क्रेडेंशियल। सत्र शुरू होने पर एकल द्वार के बजाय हर API कॉल पर निरंतर रनटाइम प्राधिकरण। संदर्भ ले जाने वाले टोकन: अभिनेता पहचान, प्रतिनिधित्व किया गया उपयोगकर्ता, इच्छित कार्य, वर्तमान विश्वास स्तर। इन सबके लिए तकनीकी प्राइमिटिव्स आज OAuth 2.0 में मौजूद हैं — दोहरी-पहचान के लिए token exchange (RFC 8693), अस्थायी एजेंट क्रेडेंशियल के लिए dynamic client registration (RFC 7591), और कार्य-स्कोप किए टोकन के लिए rich authorization requests (RAR, RFC 9396)। अंतर मानकों में नहीं है। यह है कि अधिकांश उद्यम IAM तैनाती या तो इन एंडपॉइंट्स को लागू नहीं करती, या उन्हें टॉगल के रूप में लागू करती हैं जिनका कोई उपयोग नहीं करता।
एजेंट प्लेटफ़ॉर्म्स पर काम कर रहे डेवलपर्स के लिए, व्यावहारिक पठन यह है कि एक्सेस-कंट्रोल कार्य वास्तविक इंजीनियरिंग है और अनुपालन विवरण नहीं। आपके प्लेटफ़ॉर्म जो एजेंट चलाते हैं उन्हें संभवतः अपनी पहचान चाहिए (उपयोगकर्ता से उधार ली गई नहीं), प्रति-कार्य जारी किए गए अल्पकालिक स्कोप किए क्रेडेंशियल (सत्र-लंबे नहीं), और एक रनटाइम प्राधिकरण परत जो टोकन जारी होने के बाद भी एक कार्य को अस्वीकार कर सकती है (क्योंकि विश्वास संकेत मध्य-सत्र बदल सकते हैं)। Curity ऐसे उत्पाद बेचता है; Okta भी अपने Workload Identity कार्य के साथ, AWS IAM Identity Center और Verified Permissions के साथ, और Aembit और Astrix जैसे कई छोटे खिलाड़ी भी। Ideskog के लेख में विक्रेता पिच आर्किटेक्चर पर ग़लत नहीं है, पर डेवलपर्स को OAuth 2.0 प्राइमिटिव्स का सीधे मूल्यांकन करना चाहिए और तैनाती पथ चुनना चाहिए, बजाय एजेंट IAM को एकल-स्रोत श्रेणी के रूप में मानने के। 90%-गैर-मानव संख्या वो हिस्सा है जो हर सुरक्षा टीम को यह समीक्षा करने पर मजबूर कर देगा कि वे क्या चला रहे हैं, चाहे वे आख़िर में कौन सा विक्रेता ख़रीदें।