AI agent SaaS admin access: broad tokens की जगह सीमित actions

AI एजेंट किसी सर्वशक्तिशाली administrator token के बिना SaaS administration संभाल सकते हैं। सुरक्षित design ज्यादा सीमित और मेहनत वाला है: हर अनुमत बदलाव को एक action के रूप में परिभाषित करें, उसे एक tenant और inputs के छोटे समूह से जोड़ें, credentials को model से बाहर रखें और जब परिणाम महत्वपूर्ण हो तो human decision जरूरी बनाएं।

Broad token setup के दौरान सुविधाजनक लगता है, क्योंकि इससे शुरुआती रुकावटें हट जाती हैं। लेकिन तब हर prompt, imported document, connector response और model की गलती संभावित administrator request बन जाती है। मैंने teams को इस access को «temporary» कहते देखा है और फिर महीनों बाद पता चला कि एक भूले हुए credential से उनकी छोटी-सी automation users, invoices, role assignments और workspace configuration पर अधिकार रखती है।

Least-privilege की आम सलाह सही है, लेकिन अधूरी है। Scopes अकेले शायद ही यह बता पाते हैं कि agent को किसी खास user को delete करना चाहिए या नहीं, किसी खास group में बदलाव करना चाहिए या subscription बदलनी चाहिए। Administrators को काम के अनुरूप सीमाएं चाहिएं, साथ ही ऐसा evidence भी चाहिए जिससे बाद में हर request को फिर से समझा जा सके।

Broad administrator tokens सामान्य काम को incident response बना देते हैं

एक administrator token agent को लगभग हर उस काम से ज्यादा अधिकार देता है जो आप उसे सौंपेंगे। अधिकांश SaaS administration चार अलग risk classes में आती है: किसी व्यक्ति का account संभालना, group membership बदलना, money पढ़ना या प्रभावित करना, और workspace में बदलाव करना। इन सबको एक ही permission set मानना routine support work को ownership transfer या account deletion तक पहुंचने का रास्ता देता है।

Request पर विचार करें, «इस सप्ताह जिन contractors की engagements खत्म हो गई हैं उन्हें हटाएं।» Agent को approved identities की भरोसेमंद सूची, target workspace और उन identities को suspend या deprovision करने की अनुमति चाहिए। उसे नया workspace बनाने, domain setting बदलने, invoices में बदलाव करने या खुद को administrator role देने की जरूरत नहीं है। फिर भी administrator API token आम तौर पर इनमें से कई या सभी calls की अनुमति देता है।

समस्या केवल तब शुरू नहीं होती जब model malicious या defective हो। यह तब भी शुरू होती है जब agent अस्पष्ट नाम वाला support ticket पढ़ता है, किसी spreadsheet में cell के भीतर छिपा hostile instruction पाता है या error के बाद गलत tenant पर request दोबारा भेजता है। Wide token इन सभी failures को मूल task से कहीं अधिक अधिकार देता है।

Token को action न समझें। Token पूछता है, «यह caller किन API routes तक पहुंच सकता है?» Action पूछती है, «यह run किस object पर, किन inputs के साथ, ठीक कौन सा बदलाव request कर सकता है?» यही अंतर तय करता है कि आपका control plane SaaS vendor तक पहुंचने से पहले unsafe request को रोक सकता है या नहीं।

एक service account को administrator role देने की लोकप्रिय सलाह आकर्षक है, क्योंकि vendor setup guides इसे आसान बनाती हैं और internal automation को जल्दी परिणाम चाहिए। Agents के लिए यह फिर भी गलत है। Service accounts deterministic programs के लिए बनाए गए थे, जिनका source, inputs और call paths administrators को नियंत्रित करने की उम्मीद होती है। Agent की अगली request बदलते context से बनती है। उसे छोटा blast radius दें।

वास्तविक administrative verbs की inventory से शुरू करें

Access inventory में products या job titles नहीं, actions की सूची होनी चाहिए। «Agent हमारे collaboration suite को administer करता है» उपयोगी जानकारी नहीं देता। «Agent approved offboarding records में नामित users को suspend करता है» ऐसी बात है जिसे engineer लागू कर सकता है और administrator review कर सकता है।

हाल के tickets, runbooks और audit entries इकट्ठा करें, फिर हर recurring task को verb, object और consequence में बदलें। Vendor के menu labels के आधार पर grouping न करें। SaaS consoles अक्सर human operator की सुविधा के लिए असंबंधित शक्तियों को एक ही Administrator role के पीछे रखते हैं, automated caller के लिए नहीं।

शुरुआती inventory में ये actions हो सकती हैं:

• Immutable user ID से user profile पढ़ना।
• Named approval record मौजूद होने के बाद user को suspend करना।
• User को एक approved group में जोड़ना।
• तय accounting period की invoices export करना।
• Workspace settings की fixed allowlist पढ़ना।

उस action को भी लिखें जिसकी जरूरत लोग चुपचाप बाद में मान लेते हैं। «कोई भी workspace setting update करना» action नहीं है। इसे session duration, allowed domains, external sharing या retention जैसी settings में बांटें। हर setting के failure modes और approvers अलग हो सकते हैं।

जहां vendor immutable IDs देता हो, action contract में उनका उपयोग करें। Email addresses बदलते हैं। Display names दोहराए जा सकते हैं। «Alex Kim» स्वीकार करके पहला match चुनने वाली request payroll reorganization का इंतजार करती हुई incident है। Agent को candidates खोजकर दिखाने दें, लेकिन बदलाव से पहले unique ID जरूरी रखें।

यह inventory एक असुविधाजनक तथ्य सामने लाती है: कुछ मांगी गई automation delegation के लिए तैयार नहीं है। अगर कोई यह नहीं बता सकता कि किसे हटाया जा सकता है, किन groups में बदलाव हो सकता है या source of truth कहां है, तो समस्या governance की है। AI agent इसे ठीक नहीं करेगा। वह missing decision को machine speed पर दिखाई देगा।

Action contract को target और payload सीमित करना चाहिए

Action catalog में friendly name और API endpoint से ज्यादा जानकारी होनी चाहिए। उसे target, accepted fields, authority का source और agent को लौटने वाला response सीमित करना होगा। वरना सीमित दिखने वाला wrapper arbitrary JSON को powerful administrator API तक भेज देगा।

यह example suspension action का वर्णन करता है। इसे जानबूझकर छोटा रखा गया है। Production implementation में schema validator इस्तेमाल किया जा सकता है, लेकिन constraints ऐसी जगह मौजूद होनी चाहिए जिसे agent अपने run के दौरान बदल न सके।

{
  "name": "suspend_user",
  "tenant": "acme-workspace",
  "method": "POST",
  "path_template": "/v1/users/{user_id}/suspend",
  "inputs": {
    "user_id": {"type": "string", "pattern": "^usr_[A-Za-z0-9]+$"},
    "approval_ref": {"type": "string", "pattern": "^OFF-[0-9]+$"},
    "reason": {"type": "string", "max_length": 240}
  },
  "forbidden_inputs": ["role", "owner", "tenant_id", "credential"],
  "requires_approval": true
}

forbidden_inputs वाली line एक सामान्य wrapper failure रोकती है। कोई safe endpoint बनाता है और फिर future needs के लिए generic options object जोड़ देता है। वह object is_admin, transfer_ownership या destination tenant जैसे fields के लिए tunnel बन जाता है। Unknown fields को reject करें। Future requirements के लिए नया action और review होना चाहिए।

Tenant को agent से स्वीकार करने के बजाय action definition में bind करें। अगर आप कई workspaces चलाते हैं, तो अलग action entries बनाएं और approver से destination select करवाएं। Request payload में tenant_id रखना तब तक सुविधाजनक लगता है जब तक agent एक customer environment का reference दूसरे में copy नहीं कर देता।

Response भी महत्वपूर्ण है। User ID, prior state, new state, timestamp और vendor request identifier, अगर API देता हो, लौटाएं। Vendor endpoint unrestricted account object लौटाता है, इसलिए recovery data, personal fields या tokens से भरा पूरा object agent को न दें। Output control उस material को सीमित करता है जो agent की आगे की reasoning में जा सकता है।

Vendor support करता हो तो idempotency के लिए explicit field रखें। Network failure के बाद retry से known result मिलना चाहिए, दूसरा invitation, duplicate charge या repeated group mutation नहीं। Action request ID store करें और retries को उससे जोड़ें। Language model से vague error message के आधार पर पिछली call सफल हुई या नहीं, इसका अनुमान न लगवाएं।

OAuth scopes जरूरी हैं, लेकिन अक्सर बहुत मोटे होते हैं

OAuth scopes credential की सीमा तय करते हैं और vendor द्वारा दिए गए सबसे narrow scopes का उपयोग करना चाहिए। वे अपने आप operational rule व्यक्त नहीं करते। users.write जैसा scope tenant के हर user पर suspension, deletion, profile edits और role changes की अनुमति दे सकता है। Agent को इनमें से सिर्फ़ एक की जरूरत हो सकती है।

RFC 6749 scopes को ऐसे strings के रूप में परिभाषित करता है जो access request सीमित करते हैं, जबकि उनका अर्थ authorization server पर छोड़ देता है। इसी वजह से vendors के बीच scope names बहुत अलग होते हैं और administrators केवल label देखकर safe behavior नहीं समझ सकते। Approved scope के अंतर्गत आने वाली हर write method के लिए vendor API reference पढ़ें। Scope names security review नहीं हैं।

RFC 8707 OAuth requests में resource indicators जोड़ता है, ताकि client किसी खास protected resource के लिए token मांग सके। जहां SaaS provider इसका support करता हो, resource restrictions का उपयोग करें, खासकर जब एक ही identity कई tenants या APIs तक पहुंच सकती हो। Resource indicator token के intended audience को सीमित कर सकता है। फिर भी यह provider को नहीं बताता कि agent users को suspend कर सकता है, delete नहीं।

जहां संभव हो credentials को action family के अनुसार अलग रखें। Read-only directory credential की authority billing change credential जैसी नहीं होनी चाहिए, सिर्फ़ इसलिए कि दोनों monthly report support करते हैं। इससे rotation कम बाधित होती है और vendor token leak या गलत configuration होने पर नुकसान सीमित रहता है।

एक खास खतरनाक pattern पर नजर रखें: client छोटा scope set मांगता है, लेकिन administrator service के जरिए उसे exchange करता है जो arbitrary downstream paths स्वीकार करती है। Inventory में OAuth grant सीमित दिखता है, जबकि पीछे का service account unrestricted authority रखता है। पूरी call path जांचें। Effective permission वही है जो vendor request लागू करते समय मौजूद होती है।

Bearer tokens को agent configuration, prompt files, shell history या tool output में न रखें। Exposure के बाद redaction token को फिर आपके नियंत्रण में नहीं लाती। Agent को सामान्य parameters के साथ named action request करनी चाहिए। अलग component सिर्फ़ उस outbound call के लिए credential जोड़े और constrained result लौटाए।

User और group changes के लिए अलग escalation paths चाहिए

User lifecycle automation तब सुरक्षित होती है जब वह chat instruction के बजाय घोषित identity source का पालन करे। RFC 7644 में निर्दिष्ट SCIM identity resources को provision और manage करने का protocol है। यह create, replace, patch, query और deprovision operations के लिए standard shape देता है। यह तय नहीं करता कि किसी को administrator बनाने की request वैध है या नहीं।

जब authoritative directory उपलब्ध हो, routine joiner, mover और leaver work के लिए SCIM या vendor की supported lifecycle API इस्तेमाल करें। Agent को उस source से proposed change तैयार करने की अनुमति दें और request को उस identity record से जोड़ें जिसने इसे उचित ठहराया। अगर कोई व्यक्ति कहता है «Sam को हटाएं», तो agent record खोजकर matched identity दिखाए। समान नामों में अनुमान न लगाए।

Group membership पर कई teams जितना विचार करना चाहिए, उससे कम करती हैं। Engineering नाम का group एक product में harmless हो सकता है, जबकि दूसरे में source access, deployment privileges या financial reporting दे सकता है। Groups को friendly names से नहीं, उनके द्वारा दिए जाने वाले permissions से classify करें। Privileged groups के लिए अलग action family, named approver और छोटी session lifetime रखें।

Role assignment साधारण profile maintenance नहीं है। इससे यह बदलता है कि आगे कौन बदलाव कर सकता है, संभवतः agent के audit path के बाहर भी। Role elevation, ownership transfer, recovery-method changes और federation configuration को ऐसे actions के पीछे रखें जिनमें हर call पर human decision जरूरी हो। कई organizations में agent को request तैयार करके evidence इकट्ठा करना चाहिए, जबकि final operation व्यक्ति vendor console में करे।

असफल offboarding flow सामान्य दिख सकता है। Agent को [email protected] का ticket मिलता है, वह display name से search करता है, समान नाम वाले active employee को पाता है और उसे high-access group से हटा देता है। फिर operator ticket ठीक करने के बाद intended contractor record पर retry करता है। API के अनुसार दोनों actions सफल हैं। गलती action design में है: name search और privileged mutation को एक unreviewed step में अनुमति दी गई।

Discovery और mutation को अलग करके workflow ठीक करें। Agent को immutable IDs और current group memberships के साथ candidate identities लौटाने दें। Approval record में selected ID होना जरूरी करें। Suspension या group-removal action फिर केवल उसी ID को स्वीकार करे। यह अतिरिक्त handoff bureaucracy नहीं है। यह ambiguous query को permission change बनने से रोकता है।

Billing permissions को पैसा चलने से पहले रुक जाना चाहिए

Billing data को अक्सर automation की जरूरत होती है, लेकिन billing authority की स्पष्ट सीमा है: invoice पढ़ना और किससे charge लिया जाए, यह बदलना अलग बातें हैं। Reporting, payment updates, subscription changes, refunds और tax settings को एक credential के पीछे न रखें, सिर्फ़ इसलिए कि vendor इन्हें Billing Admin functions कहता है।

Read-only export action reasonable maximum वाली date range स्वीकार कर सकती है, invoice identifiers और totals लौटा सकती है और request record कर सकती है। जब तक किसी वास्तविक task में जरूरत न हो, agent context में full payment instruments, tax documents या arbitrary customer billing profiles न भेजें। Access और response data दोनों कम करें।

इन actions को high-consequence मानें, भले vendor API उन्हें routine बनाती हो:

• Payment method या billing contact बदलना।
• Seats, subscription tier या consumption limits बढ़ाना।
• Subscription cancel करना या credit जारी करना।
• Tax, legal entity या purchase order information बदलना।
• ऐसा user बनाना जो billing administer कर सके।

Per-call approval जरूरी करें और उसमें exact vendor tenant, account या subscription ID, old value, proposed value और financial effect दिखाएं, जब API ये जानकारी दे सकती हो। «Approve billing update» ऐसा approval prompt है जिसे बिना पढ़े click किया जाएगा। Approver को स्पष्ट दिखना चाहिए कि क्या बदलेगा।

Budget guardrails भी model के बाहर होनी चाहिए। अगर subscription action कोई limit बढ़ा सकती है, तो action definition में fixed ceiling रखें या human द्वारा approved value select किए जाने तक change reject करें। Agent से यह निर्णय न करवाएं कि context window में मौजूद policy document के आधार पर spend increase उचित है या नहीं।

कुछ teams billing risk को actions के daily digest से हल करने की कोशिश करती हैं। Digest review के लिए उपयोगी है, लेकिन charge होने से पहले उसे रोक नहीं सकता। इसे read operations और low-impact reconciliations के लिए रखें। Irreversible financial call से पहले consent लें।

Workspace settings को permanent freedom नहीं, change window चाहिए

Workspace settings को कम महत्वपूर्ण समझना आसान है, क्योंकि admin console में वे toggles जैसे दिखते हैं। External sharing, domain verification, session duration या data retention की setting एक साथ हर user को प्रभावित कर सकती है। इससे छोटी API request सैकड़ों सामान्य account edits से ज्यादा महत्वपूर्ण बन जाती है।

हर setting या tightly related setting family के लिए अलग setting action define करें। हर definition में allowed values, जिस current-state read पर वह निर्भर है और rollback value शामिल होनी चाहिए। Agent को general settings endpoint पर arbitrary configuration blob भेजने की अनुमति न दें। General endpoints समय के साथ जोखिमपूर्ण होते हैं: vendors नए fields जोड़ते हैं और आपकी पहले से सीमित automation को वे powers मिल जाती हैं जिनकी आपने समीक्षा नहीं की।

Action को write प्रस्तावित करने से तुरंत पहले current value पढ़ना जरूरी करें। Approval में दोनों values और impact का scope दिखना चाहिए। इससे operator किसी stale plan को approve नहीं करेगा, जबकि कोई दूसरा administrator setting पहले ही बदल चुका हो।

Login, sharing, provisioning या data retention बाधित कर सकने वाली settings के लिए change window रखें। Agent current configuration इकट्ठी कर सकता है, change request draft कर सकता है और तय window में ही action कर सकता है। Urgent remediation के लिए explicit reason field और immediate notification path वाला अलग emergency action रखें। Emergency access को सामान्य automation exception की तरह न छिपाएं।

अगर vendor nonproduction tenant देता हो तो rollback वहीं test करें। अगर नहीं देता, तो reversible setting चुनें और automation से पहले vendor behavior document करें। «Agent इसे वापस कर देगा» rollback plan नहीं है, खासकर जब original request timeout हो गई हो या vendor ने write के दौरान value normalize कर दी हो।

Human approval तब काम करता है जब वह एक खास run से जुड़ा हो

Approval तभी उपयोगी है जब approver देख सके कि कौन request कर रहा है, क्या किया जाएगा और permission कितनी देर रहेगी। «AI assistant» के लिए generic approval standing authority बन जाती है, बस भाषा बेहतर लगती है। Session approval को एक agent process से जोड़ें और process समाप्त होने या उसका उद्देश्य बदलने पर उसे revoke करें।

उन changes के लिए per-call approval रखें जिनमें target और payload risk लाते हैं: privileged group membership, role elevation, billing changes, deletion, ownership transfers और workspace-wide settings। Low-impact calls के सीमित sequence, जैसे users पढ़ना और offboarding candidates तैयार करना, के लिए session approval इस्तेमाल करें। हर directory lookup पर click न मांगें। लोग पढ़ना बंद कर देंगे।

Sallyport यह विभाजन absolute vault gate, per-session authorization और हर उपयोग पर optional per-key approval के माध्यम से लागू करता है। इसका agent-facing MCP path stored credential को agent के सामने लाए बिना HTTP या SSH actions चला सकता है।

जहां operating system इसे स्थापित कर सकता हो, approval record में calling process identity शामिल करें। केवल process name कमजोर evidence है, क्योंकि कोई भी process परिचित नाम चुन सकता है। Code-signing authority, process lifetime और action request approver को unexpected tool से आई request अस्वीकार करने के लिए पर्याप्त context देते हैं।

Approval ऐसे action catalog की भरपाई नहीं कर सकता जो बहुत ज्यादा अनुमति देता है। अगर prompt कहता है «workspace settings बदलें» और approval card भी वही phrase दोहराता है, तो human को proposal कहीं और से समझना पड़ेगा। Approval payload को concrete बनाएं। Design को named tenant, object, old value, proposed value और reason पर निर्णय लेने के लिए मजबूर करना चाहिए।

Evidence agent session के बाद भी बचा रहना चाहिए

SaaS vendor का audit log जरूरी है, लेकिन वह शायद यह न बताए कि agent ने request क्यों की, कौन सा local process इसे शुरू कर रहा था या किसी व्यक्ति ने इसे approve किया था। अलग action record रखें जो agent run, approval event, action contract, outbound request, vendor response और revocation event को जोड़े।

Request fields सावधानी से record करें। Action को फिर से समझने के लिए पर्याप्त detail चाहिए, लेकिन audit system को secrets के एक और ढेर में न बदलें। Identifiers, state transitions, जहां उचित हो request hashes, vendor request IDs और sensitive values का protected representation store करें। Incident के दौरान detailed records कौन पढ़ सकता है, यह पहले तय करें।

Tamper evidence महत्वपूर्ण है, क्योंकि compromised local process unsafe call के बाद trace मिटाने की कोशिश कर सकता है। Hash-chained log आपको यह verify करने देता है कि entries को बाद की records फिर से लिखे बिना बदला या हटाया नहीं गया। यह साबित नहीं करता कि हर action समझदारी भरी थी। यह बताता है कि record में continuity बनी हुई है या नहीं, जो अलग और उपयोगी दावा है।

उदाहरण के लिए, Sallyport encrypted, hash-chained audit log से session और activity journals project करता है और sp audit verify vault secret की जरूरत के बिना उस chain को offline जांचता है। यह verification incident procedure का हिस्सा होना चाहिए, ऐसा command नहीं जिसे लोग जरूरत पड़ने के बाद खोजें।

Actual authority path पर आधारित revocation drill बनाएं। Agent run समाप्त करें, future action requests deny करें, exposure संभव हो तो प्रभावित SaaS credential revoke या rotate करें, audit record verify करें और vendor-side changes की तुलना action log से करें। जो team केवल chat session revoke कर सकती है, उसने administrative access revoke नहीं किया है।

Access को हिस्सों में बदलें और आसान shortcuts से इनकार करें

Migration तब सफल होती है जब आप एक broad permission path को एक narrow action path से बदलते हैं, failure conditions में उसे साबित करते हैं और फिर पुराना authority path हटा देते हैं। हर SaaS integration को एक साथ redesign करने की कोशिश broad administrator token को «project खत्म होने तक» बनाए रखेगी। वह फिर permanent बन जाएगा।

ऐसा task चुनें जिसका source of truth स्थिर और outcome reversible हो। Suspended-account preparation आम तौर पर account deletion से बेहतर है। Invoice export payment changes से बेहतर है। Existing call sequence capture करें और फिर उस task द्वारा वास्तव में इस्तेमाल किए जाने वाले हर endpoint और field की पहचान करें। अधिकांश teams पाती हैं कि supposedly necessary admin credential किसी ऐसे odd endpoint के लिए मौजूद है जिसकी दोबारा समीक्षा किसी ने नहीं की।

Happy path पर भरोसा करने से पहले नए action path को जानबूझकर गलत inputs के साथ चलाएं। Unknown field भेजें। दूसरे tenant का user ID भेजें। Simulated timeout के बाद retry करें। Expired approval reference वाली request submit करें। सही परिणाम audit entry के साथ rejection है, best-effort guess नहीं।

फिर legacy token को agent configuration, build logs, agent की पहुंच वाले secret stores और backup scripts से हटाएं। यदि वही broad role अगली automation के लिए उपलब्ध रहता है, तो rotation पर्याप्त नहीं है। Confirm करें कि agent अपने पढ़े जा सकने वाले credential से vendor को सीधे call नहीं कर सकता।

उन tasks के लिए exception register रखें जिन्हें अभी भी console में human की जरूरत है। इसमें required vendor action, narrow API route न होने का कारण, approved operators और review date शामिल करें। जो exceptions दिखाई देती हैं, उनकी फिर समीक्षा होती है। Runbook में छिपी exceptions अगली broad-token justification बन जाती हैं।

हर प्रस्तावित agent privilege के लिए test सीधा है: क्या आप exact target, permitted change, approval condition और पीछे छोड़े जाने वाले evidence का वर्णन कर सकते हैं? अगर नहीं, तो agent के पास अभी task नहीं है। उसके पास दुर्घटना की प्रतीक्षा करता administrator token है।