AI एजेंटों के लिए code signing: evidence के साथ session approval

ऐसा अनुमति अनुरोध जिसमें केवल «AI agent requests access» लिखा हो, इंसान से किसी अनजान चीज़ को मंज़ूरी दिलाता है। साझा development machine पर इसी तरह कोई कॉपी की गई स्क्रिप्ट, भूला हुआ terminal या गलत व्यक्ति द्वारा शुरू की गई प्रक्रिया स्वीकृत हो सकती है। सही सवाल अधिक स्पष्ट होना चाहिए: कौन-सी executable process अनुरोध कर रही है, उसे किसने साइन किया है, वह यहां कैसे पहुंची और इस रन के दौरान वह क्या कर सकती है?

Code signing इस निर्णय के लिए सबूत देता है। इससे चल रहे प्रोग्राम को signing authority से जोड़ा जा सकता है और यह देखा जा सकता है कि signed contents बदले हैं या नहीं। लेकिन इससे यह पता नहीं चलता कि एजेंट को दुर्भावनापूर्ण prompt मिला था या नहीं, भरोसेमंद publisher ने खराब release भेजी है या नहीं, या मांगी गई production action उचित है या नहीं। जब टीमें signature को व्यवहार की गारंटी समझ लेती हैं, तब समस्या शुरू होती है।

साझा Mac पर signing authority का इस्तेमाल ज्ञात agent clients को पहचानने, अनपेक्षित प्रक्रियाओं को रोकने और हर अनुमति को उसी प्रक्रिया तक सीमित रखने के लिए करें जिसने उसे हासिल किया है। इसके साथ स्पष्ट account boundary, सीमित credentials और ऐसे records रखें जिनसे अनुमति और उसके बाद की गई call दोनों को फिर से समझा जा सके।

Signature code की पहचान करता है, उसके पीछे का इरादा नहीं

Code signature यह स्थापित कर सकता है कि किसी खास code को किसने साइन किया और macOS अभी भी signed content को सत्यापित कर सकता है या नहीं। यह स्थापित नहीं करता कि उस code को आपके systems तक पहुंच मिलनी चाहिए। हर approval flow में यह अंतर साफ रहना चाहिए।

Apple के code-signing documentation, Technical Note TN2206, के अनुसार signatures code को validate करने और designated requirement व्यक्त करने का तरीका हैं। macOS बाद में इसी जानकारी से उसी code को पहचान सकता है। Designated requirement महत्वपूर्ण है, क्योंकि यह filename से अधिक सटीक होती है। agent नाम वाले executable को कहीं भी कॉपी करके उसका नाम बदला जा सकता है। अगर signing chain और requirement अभी भी valid हैं, तो signed identity ज्यादा लगातार और भरोसेमंद पहचान देती है।

यह निरंतरता एक व्यावहारिक सवाल का जवाब देती है: «क्या यह वही client है जिसे हमने अनुमति देने पर सहमति की थी?» लेकिन यह इन सवालों का जवाब नहीं देती:

• क्या एजेंट को ऐसी instructions मिली हैं जिन्हें production तक कभी नहीं पहुंचना चाहिए?
• क्या किसी user ने यह प्रक्रिया जानबूझकर, सही project directory से शुरू की?
• क्या प्रक्रिया के पास कोई extension, plugin या configuration है जो उसके व्यवहार को बदलती है?
• क्या अनुरोधित API call इसी task का हिस्सा है?
• क्या उस call के पीछे का credential task की जरूरत से ज्यादा access रखता है?

लोग अक्सर publisher के नाम को अंतिम निर्णय की तरह देखते हैं। ऐसा नहीं है। Signing authority बताती है कि उस artifact के लिए इस्तेमाल किए गए signing credential पर किसका नियंत्रण था। बड़ा publisher कई programs साइन कर सकता है। छोटी internal team भी पूरी तरह उपयुक्त build साइन कर सकती है। आपका approval decision ऐसी allowlist से observed identity की तुलना करे जिसे आपकी टीम समझा सके, न कि इस धुंधले एहसास से कि issuer का नाम जाना-पहचाना लगता है।

एक सीमा अक्सर छूट जाती है: signing केवल उस code को verify करता है जिसे साइन किया गया था। यह अपने आप उस हर चीज़ को शामिल नहीं करता जिसे प्रक्रिया बाद में पढ़ती है। Configuration files, prompt files, environment variables, repository का data, downloaded extensions और remote responses, ये सभी सही ढंग से signed program के व्यवहार को बदल सकते हैं। अगर आप किसी एजेंट को इसलिए अनुमति देते हैं कि उसका binary जाना-पहचाना लगता है, तब भी उसकी कार्रवाइयों पर नियंत्रण जरूरी है।

Approval card को attribution record की तरह पढ़ें

Approval card में इतनी जानकारी होनी चाहिए कि operator अनुमति देने से पहले अनुरोध को वास्तविक प्रक्रिया से जोड़ सके। Signing authority को सबसे ऊपर रखें, क्योंकि process label की तुलना में उसकी नकल करना कठिन है। फिर भी उसे process path और session details के साथ दिखाना जरूरी है।

साझा machine पर access मांगने वाली प्रक्रिया के लिए मैं ये तथ्य एक ही जगह देखना चाहूंगा:

• Executable या app identity और उसका पूरा local path।
• उसे पहचानने के लिए इस्तेमाल की गई signing authority या designated requirement।
• Process ID और parent process, ताकि पता चले कि उसे किसने शुरू किया।
• macOS user account जिसका स्वामित्व उस पर है।
• Action channel और destination, जैसे API host या SSH host।

पहले तीन तथ्य अलग-अलग तरह की गड़बड़ियां पकड़ते हैं। जाना-पहचाना display name लेकिन अनपेक्षित path अक्सर copied binary या wrapper का संकेत होता है। जाना-पहचाना path लेकिन अनजान authority का अर्थ हो सकता है कि किसी ने उसे फिर से build किया, बदल दिया या symlink को किसी और जगह भेज दिया। जाना-पहचाना executable अगर अनपेक्षित parent से शुरू हुआ हो, तो संभव है कि उसे developer के बजाय किसी दूसरे automation tool ने शुरू किया हो।

साझा Mac पर user account केवल सजावटी जानकारी नहीं है। अगर दो engineers एक ही login साझा करते हैं, तो approval यह बहुत कम बताता है कि एजेंट किस व्यक्ति ने शुरू किया। Machine फिर भी बता सकती है कि call किस process ने की, लेकिन approval flow शुरू होने से पहले ही आपकी टीम ने स्पष्ट human boundary खो दी है। Incident के बाद terminal history पर बहस करने से अलग macOS accounts सस्ते पड़ते हैं।

लोगों को logo, छोटे command name या अकेली authority string के आधार पर अनुमति देना न सिखाएं। उन्हें पूरा expected tuple पहचानना सिखाएं: स्वीकृत agent client, अपेक्षित signing authority, अपेक्षित local location, उनका अपना account और task से जुड़ा destination। ऐसी card जिसमें यह अधिकांश evidence न हो, one-click approval को अनुमान में बदल देती है।

Approved identity बनाने से पहले executable की जांच करें

आपकी टीम जिस exact app या executable को अनुमति देने वाली है, उस पर live workflow में भरोसा करने से पहले उसकी जांच करें। Setup के दौरान यह जांच करें, expected result को internal runbook में दर्ज करें और client को जानबूझकर upgrade करने पर इसे दोहराएं।

macOS पर signing details दिखाने के लिए codesign इस्तेमाल किया जा सकता है। इसका detailed output standard error पर जाता है, इसलिए review artifact सेव करना हो तो उसे redirect करें:

codesign -dv --verbose=4 /Applications/ApprovedAgent.app 2\u003e\u00261

Output में आम तौर पर इस तरह के fields होते हैं:

Executable=/Applications/ApprovedAgent.app/Contents/MacOS/ApprovedAgent
Identifier=com.example.approved-agent
Format=app bundle with Mach-O thin (arm64)
CodeDirectory v=20500 size=...
Authority=Developer ID Application: Example Developer (ABCDE12345)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
TeamIdentifier=ABCDE12345
Sealed Resources version=2 rules=13 files=...

Identifier, leaf Authority और TeamIdentifier को साथ रखें। अकेला Team ID कमजोर approval rule है, क्योंकि एक organization कई applications साइन कर सकती है। अकेला identifier भी कमजोर है, क्योंकि कोई unsigned program वही bundle identifier बना सकता है। Chain ही इस statement को उपयोगी बनाती है।

इसके बाद signed contents verify करें:

codesign --verify --deep --strict --verbose=2 /Applications/ApprovedAgent.app

सफल result अक्सर बिना output के मिलता है। Failure किसी बदले हुए nested component या दूसरी signing समस्या की ओर संकेत करता है। --deep codesign से nested code के भीतर भी जाने को कहता है। Inspection के लिए यह उपयोगी है, लेकिन इसे इस बात का प्रमाण न मानें कि bundled हर component आपकी security policy के अनुरूप है। Apple के अनुसार deep verification recursive verification करता है और bundle के internal signing design की सीधे समीक्षा की जरूरत को छिपा सकता है।

Managed software channel के बाहर से मिले app के लिए Gatekeeper assessment भी लें:

spctl --assess --type execute --verbose=4 /Applications/ApprovedAgent.app

spctl और codesign जुड़े हुए लेकिन अलग सवालों के जवाब देते हैं। codesign artifact के विरुद्ध signatures verify करता है। spctl पूछता है कि system की assessment policy इसे स्वीकार करती है या नहीं। Passing assessment provenance का उपयोगी संकेत है। इसका मतलब यह नहीं कि app के commands, scripts या remote behavior production के लिए सुरक्षित हैं।

Reviewed path दर्ज करें। अगर कोई व्यक्ति बाद में /Applications में देखे गए app जैसे label के कारण /Users/alex/bin/agent को अनुमति देता है, तो उसने यह जांच दोहराई नहीं है। Path भी evidence का हिस्सा है।

Interpreter का signature उसके द्वारा चलाई गई script को सुरक्षित नहीं बनाता

Signed terminal, runtime या shell launch के समय दी गई किसी भी script की जिम्मेदारी नहीं ले सकता। कई ऐसे approvals के पीछे यही अंतर होता है जो बातचीत में सही लगते हैं लेकिन व्यवहार में असफल हो जाते हैं।

मान लें कोई developer इस तरह का command चलाकर एजेंट शुरू करता है:

/usr/bin/python3 /Users/dev/work/demo/tools/agent_runner.py

System Python का known signature हो सकता है। यह तथ्य केवल interpreter binary के बारे में बताता है। इससे agent_runner.py, repository से import की गई files, पढ़ी गई .env file या standard input से मिली instructions के बारे में कुछ पता नहीं चलता। अगर approval UI केवल python3 दिखाती है, तो attacker को interpreter बदलने की जरूरत नहीं होगी, script या project state बदलना पर्याप्त होगा।

यही समस्या node, shells, editor extensions और generic automation runners में भी आती है। «इस runtime publisher से signed processes को approve करें» जैसा व्यापक नियम ऐसे बहुत से व्यवहार को स्वीकृत कर देता है जिसकी किसी ने समीक्षा नहीं की। यह लोकप्रिय है क्योंकि approvals कम हो जाते हैं। लेकिन meaningful credentials तक पहुंचने वाले किसी भी channel के लिए यह गलत है।

दो में से एक model चुनें और टीम में स्पष्ट करें कि आपने कौन-सा चुना है। मजबूत model में signed, purpose-built agent client को अनुमति दी जाती है और उसका session process ही access मांगने वाला program होता है। अधिक flexible model interpreters की अनुमति देता है, लेकिन हर script launch को अलग session मानता है और interpreter की authority के साथ script path, project directory, arguments और parent process भी दिखाता है।

Standard tools से running process का basic context देखा जा सकता है:

ps -p 4821 -o pid=,ppid=,user=,command=
ps -p 4812 -o pid=,ppid=,user=,command=

पहला command agent process और दूसरा उसका parent दिखा सकता है। Command line की तुलना developer के काम से करें। अगर child expected project के terminal से आया है, तो evidence मेल खाता है। अगर वह unattended scheduler, browser helper या किसी दूसरे agent से आया है, तो request को सामान्य developer approval न मानें।

Script-based client के लिए script digest को approval record का हिस्सा बनाएं। बदलावों को स्पष्ट करने के लिए एक सरल local check काफी है:

shasum -a 256 /Users/dev/work/demo/tools/agent_runner.py

Digest script को भरोसेमंद नहीं बनाता। यह ठोस जवाब देता है कि approved script runs के बीच बदली है या नहीं। Expected digest केवल reviewed release या controlled project state के लिए रखें। Chat messages से hashes copy करने की रस्म न बनाएं।

Approval rules से पहले shared machines में account boundaries चाहिए

Shared development Mac तब संभालना आसान होता है जब हर human अलग account इस्तेमाल करे और हर agent run का स्पष्ट owner हो। अगर सब एक ही login इस्तेमाल करते हैं, तो signing authority attribution की कमी पूरी नहीं कर सकती।

हर developer के लिए अलग macOS accounts बनाएं और रोजमर्रा के काम के लिए communal administrator login से बचें। Agent process उसी व्यक्ति के account में चले जिसने उसे शुरू किया। तब उसकी project files, terminal history, environment variables और approval decisions का meaningful owner होगा। Shared repositories के लिए shared operating system accounts जरूरी नहीं हैं।

अच्छे setup में sensitive destinations भी अलग होने चाहिए। Development, staging और production के लिए अलग credential entries और ऐसे labels रखें जिनसे operator को intent साफ दिखे। inventory-staging की approval चुपचाप production credential न चुने, भले दोनों एक ही API client की ओर point करते हों। अगर credential naming environment छिपाती है, तो जरूरी क्षण में human सही निर्णय नहीं ले सकता।

Physical access भी महत्वपूर्ण है। Unlocked shared Mac के सामने बैठा व्यक्ति active account में process शुरू कर सकता है और owner के approval prompt पर click करने का इंतजार कर सकता है। जाते समय screen lock करें, sleep के बाद fresh login आवश्यक करें और common space में privileged terminal खुला न छोड़ें। ये साधारण controls हैं, इसलिए teams incident के बाद सफाई करने तक इन्हें टालती रहती हैं।

Shared-machine risk का समाधान approved signing authorities की एक विशाल list प्रकाशित करना नहीं है। ऐसी list बढ़ते-बढ़ते editors, language runtimes, package managers, build tools और helper applications तक पहुंच जाती है। तब वह केवल यह बताती है कि machine development के लिए इस्तेमाल होती है। External actions मांग सकने वाले agents के लिए approved set छोटा रखें और हर identity के शामिल होने का कारण लिखें।

Session approval हमेशा के लिए व्यक्ति को नहीं, एक प्रक्रिया को बांधे

Session approval को एक observed agent process के लिए उतनी ही अवधि तक मान्य होना चाहिए जितनी देर वह process चलता है। Process exit होते ही approval खत्म हो जाए। यह हर harmless request पर निर्णय लेने और काम खत्म होने के बाद भी permission बचाए रखने के बीच अच्छा संतुलन है।

Calendar timeout से अधिक महत्वपूर्ण process boundary है। Agent exit होकर restart होता है तो वह नया execution context है। उसका working directory, modified binary, extensions, parent या keyboard पर मौजूद व्यक्ति अलग हो सकता है। Restart पर नई authorization मांगने से operator को ये बदलाव देखने का एक और अवसर मिलता है।

यहीं code signing उपयोगी बनता है। Approval flow authority को सबसे पहले दिखा सकता है, ताकि operator expected client पहचान सके, जबकि session binding उस पहचान को indefinite grant बनने से रोकती है। Agent process exit हो तो approval भी उसके साथ खत्म होनी चाहिए। अगर operator को suspicious behavior दिखे, तो code signature की विस्तृत जांच से पहले session revoke करने का तुरंत तरीका होना चाहिए।

Authorization को authentication से अलग रखें। Touch ID या password यह साबित कर सकता है कि मौजूदा macOS user ने approval दी। यह process की पहचान नहीं करता। Code signing process की पहचान में मदद कर सकता है। इनमें से कोई भी यह तय नहीं करता कि destination और action उचित हैं। अच्छा approval card इन तीनों प्रकार के evidence को अलग-अलग दिखाता है।

सामान्य repository work में session decision development API के विरुद्ध बार-बार होने वाली read operations को cover कर सकता है। लेकिन deployment configuration बदलने, credentials rotate करने, records हटाने या production host से SSH connection खोलने जैसी कार्रवाई पर उसी call के लिए fresh decision लें। Friction वहां रखें जहां consequence बदलता है, random timer के बाद नहीं।

Signing authority उन failures को नहीं रोकती जिनसे लोग इसकी उम्मीद करते हैं

Valid signing chain trusted client को खराब input मिलने, compromised developer account से malicious code साइन होने या approved process द्वारा गलत request करने से नहीं रोक सकती। इन्हें अलग failure paths मानें और हर एक के सामने सही control रखें।

पहला path prompt या repository instruction attack है। Code assistant कोई malicious comment पढ़ता है जो उसे configuration file को HTTP request के जरिए बाहर भेजने को कहता है। Executable वही approved और correctly signed client हो सकता है। Approval में destination और requested channel दिखना चाहिए, क्योंकि signature उसके द्वारा follow की गई instruction के बारे में कोई evidence नहीं देती।

दूसरा path ऐसा legitimate update है जिसकी आपकी टीम ने समीक्षा नहीं की। Publisher उसी authority के अंतर्गत नई release साइन कर सकता है। अगर आप उस authority की हर future release को identity और release source देखे बिना approve करते हैं, तो आपकी पूरी policy publisher ownership बन जाती है। Low-risk local tooling के लिए यह स्वीकार्य हो सकता है। Production credentials इस्तेमाल करने वाले agent के लिए यह पर्याप्त नहीं है।

तीसरा path local process manipulation है। Signed app कोई plugin load कर सकता है, environment variable inherit कर सकता है या ऐसे parent process के साथ चल सकता है जो अनपेक्षित arguments देता है। macOS protections tampering के कुछ रूप कम करती हैं, लेकिन approval system को वास्तविक process context फिर भी दिखाना चाहिए। जब evidence आपस में न मिले, request deny करें और machine की जांच करें। केवल इसलिए सामान्य explanation न गढ़ें कि authority string जानी-पहचानी है।

चौथा path excess privilege है। सही तरह पहचाना गया client भी ऐसा credential इस्तेमाल कर सकता है जिसे task की जरूरत से कहीं अधिक permissions मिली हों। Credentials को उस API, host, repository और environment तक सीमित करें जिसकी agent को जरूरत है। Code signing बता सकता है कि credential का इस्तेमाल किस client ने किया, लेकिन बाद में credential की authority कम नहीं कर सकता।

इसीलिए «signed equals safe» एक नुकसानदेह सलाह है। यह साफ सुनाई देती है और prompts कम करती है, लेकिन destination, action summary या session boundary के बिना approvals को बढ़ावा देती है। Signing signal इंसान को known code और unknown code के बीच फर्क करने में मदद करता है। इसे निर्णय के बाकी हिस्से को मिटाने नहीं देना चाहिए।

Irreversible या high-impact credentials पर हर call की approval रखें

जब एक request ऐसा परिणाम पैदा कर सकती हो जिसे session approval चुपचाप अनुमति नहीं देनी चाहिए, तब हर credential use पर human decision लें। सीमा executable के भरोसेमंद दिखने से नहीं, action के impact से तय होनी चाहिए।

उन credentials पर per-call approval रखें जो production data लिख या मिटा सकते हैं, identities या permissions बदल सकते हैं, बाहरी commitments बना सकते हैं, software release कर सकते हैं या sensitive SSH environment में प्रवेश कर सकते हैं। Operator को use के समय credential label और destination दिखना चाहिए। «use secret» जैसा generic message दबाव के समय उनसे बहुत कुछ याद रखने की उम्मीद करता है।

कम प्रभाव वाले काम को उपयोगी बनाए रखें। अगर developer को test API के हर read पर approval देनी पड़े, तो वह पढ़े बिना click करना सीख जाएगा। इससे control बेअसर हो जाता है और गंभीर prompts छूटने लगते हैं। Session approval तब अच्छी तरह काम करती है जब agent expected process identity के साथ development target पर repetitive, bounded work कर रहा हो।

Decision ladder इतनी सरल हो कि कठिन सप्ताह के बाद भी लोग उसे समझा सकें। पहले locked credential vault हर action deny करे। फिर नई agent process को session authorization चाहिए। आखिर में selected credentials पर हर use के लिए approval आवश्यक हो। इन निर्णयों को ऐसी custom policy language में न छिपाएं जिसे केवल एक व्यक्ति समझ सके। Hidden exceptions shared-machine rules को धीरे-धीरे कमजोर करती हैं।

Sallyport इस three-control model को सीधे लागू करता है: locked vault actions deny करता है, नई agent process default रूप से session authorization मांगती है और चुने गए credential पर हर use में approval लगाई जा सकती है। इसकी approval card process code-signing authority से शुरू होती है, जो कई users के एक Mac साझा करने की स्थिति में सही शुरुआत है।

Approval और call को अलग events की तरह audit करें

Agent sessions और individual actions के लिए अलग records चाहिए, क्योंकि अकेला कोई भी record incident के हर सवाल का जवाब नहीं दे सकता। Session record बताता है कि किस process को कब authorization मिला और वह कब खत्म हुई। Action record बताता है कि approval के बाद उसने क्या करने की कोशिश की, किस channel या destination पर की और क्या result मिला।

एक उपयोगी investigation sequence इस तरह दिखता है:

1. उस process के लिए session record खोजें जिसने access मांगा था।
2. User account, executable path, signing authority, parent process और approval time जांचें।
3. उस session में की गई calls खोजें और destinations की तुलना assigned task से करें।
4. Session active हो तो उसे revoke करें, फिर misuse दिखने पर संबंधित credential को disable या rotate करें।
5. Project files बदलने या client reinstall करने से पहले records सुरक्षित रखें।

Order महत्वपूर्ण है। Teams अक्सर code पढ़ने से शुरुआत करती हैं और वास्तव में क्या हुआ, उसका evidence खो देती हैं। पहले authorization और action का sequence स्थापित करें। फिर executable, repository state, shell history और संबंधित configuration की जांच करें।

यहां tamper evidence उपयोगी है। ऐसा audit record जिसे local process rewrite कर सकता हो, तब बहुत कम भरोसा देता है जब वही process जांचे जा रहे event का हिस्सा हो। Hash chaining verifier को recorded sequence में alteration या removal पकड़ने का तरीका देती है, हालांकि यह साबित नहीं करती कि हर संभव event capture हुआ था। इस सीमा को स्पष्ट रखें। Tamper evidence सर्वज्ञता नहीं है।

Sallyport session और activity journals को एक encrypted, hash-chained audit log से project करता है, और sp audit verify vault credential की जरूरत के बिना chain को offline check करता है। Incident के बाद या किसी दूसरे reviewer को records देने से पहले routine verification करना इससे व्यावहारिक बनता है।

Approval decisions को व्यक्तिगत पसंद के बजाय दोहराने योग्य बनाएं

टीम को यह समझाने में सक्षम होना चाहिए कि किसी agent session को approval क्यों मिली, बिना उस व्यक्ति की याददाश्त पर निर्भर हुए जिसने click किया था। हर allowed agent client के लिए छोटा approval profile लिखें और उसे repository के operating instructions के पास रखें।

Profile में expected app या executable path, identifier, signing authority, normal parent process, intended user accounts, permitted environments और वे credentials शामिल होने चाहिए जिन पर हर call में decision चाहिए। यह केवल bureaucracy नहीं है। इससे नए engineer को observable standard मिलता है और on-call व्यक्ति odd request को पसंद-नापसंद पर बहस किए बिना reject कर सकता है।

इनमें से कोई भी चीज बदलने पर profile की समीक्षा करें: agent client update हो, टीम नया runtime wrapper अपनाए, किसी credential को अधिक permission मिले या पहले local workflow किसी shared service तक पहुंचने लगे। Signing identity बदले तो उस software source के माध्यम से बदलाव verify करें जिस पर आपकी टीम भरोसा करती है। Unexpected authority को एक बार click करके बाद में जांचने की आदत न बनाएं।

Shared Mac पर जानबूझकर failure drill चलाएं। Expected account से approved client शुरू करें और displayed authority तथा session behavior की पुष्टि करें। फिर signed interpreter के जरिए unapproved script चलाएं, client को किसी दूसरे account से launch करें और per-call approval वाले credential का अनुरोध करें। हर स्थिति में operator के लिए सही behavior स्पष्ट होना चाहिए। अगर prompts बहुत समान दिखें, तो वास्तविक गलती से पहले दिखाई जाने वाली जानकारी बेहतर करें।

Code signing उपयोगी है क्योंकि यह अस्पष्ट process name को जांचे जा सकने वाले evidence से बदल देता है। इसका काम यहीं तक सीमित रखें। सामने के काम के लिए known process को approve करें, credential scope छोटा रखें और suspicious session को evidence सुरक्षित रहते हुए तुरंत revoke करने योग्य बनाएं।