AI एजेंट अब केवल चैट विंडो तक सीमित नहीं रहे। वे अब मीटिंग बुक करते हैं, ग्राहकों के रिकॉर्ड अपडेट करते हैं, आंतरिक डेटाबेस से जानकारी निकालते हैं और वित्तीय लेनदेन (financial transactions) शुरू करते हैं। सलाहकार (advisor) से ऑपरेटर (operator) बनने का यह बदलाव जोखिम (risk) के बारे में सब कुछ बदल देता है। जब सॉफ़्टवेयर सुझाव देना बंद कर देता है और काम करना शुरू कर देता है, तो हर API एंडपॉइंट एक संभावित प्रवेश द्वार बन जाता है। पारंपरिक सुरक्षा मॉडल अनुमानित मानवीय व्यवहार के इर्द-गिर्द बनाए गए थे: एक व्यक्ति लॉग इन करता है, परिचित रास्तों पर क्लिक करता है, और लॉग आउट कर देता है। स्वायत्त एजेंट (Autonomous agents) उन पैटर्न का पालन नहीं करते हैं। वे सेकंडों में सैकड़ों कॉल्स के माध्यम से लूप करते हैं, पुनः प्रयास (retry) करते हैं और अलग-अलग शाखाओं (branch) में जाते हैं। API लेयर, जिसे मूल रूप से मानव-प्रेरित अनुरोधों के लिए डिज़ाइन किया गया था, अब निरंतर स्वचालित दबाव का सामना कर रही है। यदि आपकी सुरक्षा अभी भी पिछली तिमाही में लिखे गए स्थिर नियमों (static rules) पर निर्भर है, तो आप डेटा लीक और अनधिकृत पहुंच (unauthorized access) के लिए दरवाज़ा खुला छोड़ रहे हैं। आपको वास्तविक समय (real-time) की सुरक्षा की आवश्यकता है जो हर कॉल का मूल्यांकन उसके होते ही कर सके।
एजेंट के विशेषाधिकारों (Privileges) को सीमित करें
एजेंट परिनियोजन (deployment) में सबसे खतरनाक शॉर्टकट एक शक्तिशाली API की (key) सौंप देना है। एक ही की (key) हर सिस्टम में सभी एक्सेस प्रदान कर देती है। यदि कोई हमलावर पॉइज़न्ड प्रॉम्प्ट (poisoned prompt) या हैक किए गए इंटीग्रेशन के माध्यम से एजेंट से समझौता कर लेता है, तो उन्हें पूरे साम्राज्य की चाबियाँ मिल जाती हैं। रिकवरी एक दुस्वप्न बन जाती है क्योंकि इसका प्रभाव क्षेत्र (blast radius) आपकी ईमेल सेवा से लेकर आपके प्रोडक्शन डेटाबेस तक सब कुछ कवर करता है।
इस आदत को तुरंत बदलें। डेलिगेटेड ऑथराइजेशन (delegated authorization) के लिए OAuth 2.0 से शुरुआत करें। एजेंट को एक स्टैंडअलोन सुपरयूज़र के रूप में प्रमाणित (authenticate) नहीं होना चाहिए। इसके बजाय, इसके पास एक ऐसा टोकन होना चाहिए जो एजेंट और उस एंड-यूज़र दोनों का प्रतिनिधित्व करे जिसकी वह सेवा कर रहा है। जब मानवीय सत्र (human session) समाप्त होता है, तो एजेंट की पहुंच भी उसके साथ समाप्त हो जानी चाहिए।
टोकन एक्सचेंज (Token Exchange) इसे व्यावहारिक बनाता है। ऐसे अल्पकालिक (short-lived) टोकन जारी करें जिनका दायरा (scope) केवल उतना ही हो जितनी एजेंट को अभी आवश्यकता है। एक शेड्यूलिंग एजेंट को कैलेंडर पढ़ने और इनवाइट भेजने की अनुमति मिल सकती है, लेकिन कैलेंडर इंफ्रास्ट्रक्चर को हटाने या पेरोल API तक पहुँचने की नहीं। यदि कोई हमलावर टोकन को बीच में ही रोक लेता है, तो दुरुपयोग की अवधि सीमित रहेगी।
कॉन्टेक्स्ट-बाउंड स्कोप्स (Context-Bound Scopes) एक और परत जोड़ते हैं। हर टोकन को डिफ़ॉल्ट रूप से 'रीड-ओनली' (read-only) रखें। यदि एजेंट को डेटा लिखना ही है, जैसे रिफंड प्रोसेस करना या कॉन्ट्रैक्ट अपडेट करना, तो मानवीय अनुमोदन गेट (human approval gate) लागू करें। मॉडल को कभी भी अकेले यह तय न करने दें कि पैसा कब स्थानांतरित होगा, खाते कब बदलेंगे, या रिकॉर्ड कब गायब होंगे। अनुमति उस क्षण के अनुरूप होनी चाहिए, न कि अधिकतम क्षमता के।
एफेमेरल विंडोज़ (Ephemeral Windows) इस चक्र को पूरी तरह से बंद कर देती हैं। टोकन की लाइफटाइम को दिनों में नहीं, बल्कि मिनटों में मापें। एक संक्षिप्त समझौते के दौरान प्राप्त किया गया टोकन हमलावर के उसे दोबारा इस्तेमाल (replay) करने के प्रयास करने तक बेकार हो जाना चाहिए। इसे लगातार घूमते हुए ताले के रूप में सोचें।
एक सेल्स ऑटोमेशन एजेंट पर विचार करें जो आपके CRM से लीड डेटा पढ़ता है और आपके मेल API के माध्यम से फॉलो-अप ईमेल लिखता है। एक स्थायी एडमिन की (admin key) के बजाय, एजेंट को आपके आइडेंटिटी प्रोवाइडर से 15 मिनट का टोकन मिलता है। टोकन CRM रीड और मेल सेंड की अनुमति देता है, लेकिन कॉन्टैक्ट डिलीट करने और बिलिंग एक्सेस को रोकता है। यदि एजेंट को पूरे डेटाबेस को एक्सपोर्ट करने का कोई संदिग्ध निर्देश मिलता है, तो स्कोप (scope) बस उस प्रयास को रोक देता है।
इनडायरेक्ट प्रॉम्प्ट इंजेक्शन (Indirect Prompt Injection) को रोकें
प्रॉम्प्ट इंजेक्शन अब चैटबॉट्स के लिए कोई दिखावा मात्र नहीं रह गया है। एजेंटिक युग (agentic era) में, यह ईमेल के माध्यम से भेजे गए रिमोट कोड एक्ज़ीक्यूशन (remote code execution) की तरह काम करता है।
यहाँ एक ठोस परिदृश्य (scenario) है। एक एजेंट मीटिंग शेड्यूल करने के लिए उपयोगकर्ता के इनबॉक्स की निगरानी करता है। किसी संदेश के भीतर, शायद अदृश्य टेक्स्ट या अटैचमेंट के भीतर मेटाडेटा में, एक कमांड छिपा हो सकता है जैसे कि सभी इनवॉइस को एक बाहरी पते पर फॉरवर्ड करना और मूलों को हटाना। एजेंट ईमेल पढ़ता है, पॉइज़न्ड टेक्स्ट को वैध सिस्टम निर्देश समझ लेता है, और API कॉल करना शुरू कर देता है। क्योंकि एजेंट स्वयं अधिकृत (authorized) है, इसलिए दुर्भावनापूर्ण अनुरोध सामान्य चैनलों के माध्यम से प्रवाहित होते हैं। इसका परिणाम अनधिकृत डेटा एक्सफिल्ट्रेशन (data exfiltration) होता है जो मानक व्यवहार जैसा दिखता है।
आपका पहला बचाव सख्त इनपुट वैलिडेशन (input validation) है। AI द्वारा उत्पन्न प्रत्येक पैरामीटर को तब तक अविश्वसनीय मानें जब तक कि अन्यथा सिद्ध न हो जाए। अपने API गेटवे पर JSON-schema वैलिडेशन चलाएं। यदि एजेंट किसी ग्राहक रिकॉर्ड का अनुरोध करता है, तो गेटवे को यह सत्यापित करना चाहिए कि पेलोड में केवल एक अपेक्षित आइडेंटिफायर है, न कि कोई वाइल्डकार्ड या असामान्य रूप से बड़ा बैच अनुरोध। किसी भी गलत तरीके से बने (malformed), अत्यधिक बड़े, या कृत्रिम रूप से अजीब अनुरोध को अपने बैकएंड तक पहुँचने से पहले ही अस्वीकार कर दें।
Second, deploy data exfiltration filters on the response path. API responses should pass through inspection before they reach the AI. Scan for patterns that match secrets, authentication tokens, or bulk personal information. If a CRM query returns ten thousand records instead of one, block it. If the payload contains an internal API key, redact it. The agent does not need raw secrets to do its job, and outbound channels must not become smuggling routes for stolen data.
Third, enforce domain whitelisting. The agent needs to communicate with your calendar service, your payment processor, and your internal inventory system. It does not need to talk to arbitrary file-sharing sites, pasteboard services, or foreign cloud storage endpoints. Restrict outbound DNS resolution and HTTP requests to an explicit allow-list. Even if an attacker tricks the agent into trying to ship data elsewhere, the network layer simply refuses the connection.
Build Zero-Trust Architectures
Zero-trust is not a product you install. It is a design philosophy built on one assumption: the agent is already compromised. Act accordingly.
That means splitting identity cleanly. The human user and the agent are not the same entity, even when the agent acts on the user’s behalf. Maintain separate service identities for the agent itself, distinct from the human’s SSO session. Your audit logs should capture both identities side by side. When something goes wrong, you