एजेंट कार्रवाइयों के लिए प्रति-सत्र बनाम प्रति-कॉल अनुमति

AI एजेंट को उपयोगी बनने के लिए असीमित पहुंच की जरूरत नहीं होती। उसे मौजूदा काम के लिए उतना अधिकार चाहिए, जितने समय तक आप उस अधिकार को समझा सकें, और इंसानी निर्णय ऐसी जगह होना चाहिए जहां एक और कॉल जोखिम बदल दे। यही प्रति-सत्र और प्रति-कॉल अनुमति का व्यावहारिक अंतर है।

मैंने टीमों को दो उलटी गलतियां करते देखा है। एक टीम हर मामूली lookup को मंजूरी देती है और लोगों को चेतावनियां पढ़े बिना क्लिक करना सिखा देती है। दूसरी coding agent को लंबे समय वाला session दे देती है, फिर हैरान होती है जब कोई loop पचास tickets बना देता है, कई deployments शुरू कर देता है या इरादे से कहीं ज्यादा data export कर देता है। इनमें से कोई विफलता किसी अनोखे exploit से नहीं आती। दोनों का कारण approval boundary का गलत जगह होना है।

मुख्य keyword phrase, प्रति-सत्र बनाम प्रति-कॉल अनुमति, ऐसे चुनाव को बताती है जिसके लिए तीन बातें चाहिए: काम कितनी देर चलेगा, credential कितना अधिकार रखता है, और दोहराई गई वैध request क्या कर सकती है। HTTP verb, agent की बताई हुई योजना और यह तथ्य कि कोई developer निगरानी कर रहा है, इन तीन संकेतों से कमजोर हैं।

अनुमति तय सीमा के भीतर कार्रवाई करने का अधिकार है

प्रति-सत्र अनुमति किसी पहचानी गई agent process को उस run की अवधि तक credential इस्तेमाल करने का अधिकार देती है। प्रति-कॉल अनुमति हर बार credential इस्तेमाल होने पर निर्णय मांगती है। दोनों अलग सवालों का जवाब देती हैं। इन्हें एक जैसा मानने से या तो अंधा भरोसा पैदा होता है या बेकार की रुकावट।

Session का निर्णय कहता है: «मैं इस process को पहचानता हूं, इस सीमित run को स्वीकार करता हूं और इस credential से उपलब्ध कार्रवाइयां इस run के दौरान दोहराने के लिए पर्याप्त सुरक्षित हैं।» यह उस agent के लिए उचित निर्णय हो सकता है जो bug की जांच करते हुए कुछ issue records देख रहा हो। लेकिन ऐसी agent के लिए यह खराब निर्णय है जो अपनी reasoning के आधार पर जब चाहे production में बदलाव कर सकती है।

Call का निर्णय कहता है: «मैं अभी इस credential के इस खास उपयोग को स्वीकार करता हूं।» यह जानबूझकर धीमा है। Prompt को उस बिंदु पर आना चाहिए जहां व्यक्ति परिणाम समझ सके और पूरी task खोए बिना मना कर सके। अगर prompt कोई वास्तविक विकल्प नहीं देता, तो approval design गलत है। अगर वह irreversible action से पहले आता है, तो अतिरिक्त एक सेकंड आम तौर पर सस्ता है।

इसे authentication न समझें। Authentication local system को बताता है कि credential store कौन खोल सकता है। Authorization यह तय करता है कि agent run किसी खास credential का उपयोग कर सकता है या नहीं। Per-call control तीसरा सवाल पूछता है: क्या इस क्षण यह उपयोग नए इंसानी निर्णय का हकदार है?

यह फर्क सामान्य coding task में भी महत्वपूर्ण है। Agent एक API token से build status पढ़ सकती है और दूसरे से release शुरू कर सकती है। वही process पहले token को देखने के लिए पर्याप्त भरोसेमंद हो सकती है, लेकिन दूसरे के लिए स्पष्ट निर्णय जरूरी हो सकता है। Process identity उसके पहुंच सकने वाले हर endpoint के जोखिम को एक जैसा नहीं बना देती।

एक उपयोगी approval boundary में चार बातें होती हैं:

• कोई व्यक्ति बता सके कि agent क्या काम कर रही है।
• Credential का scope उस काम से मेल खाए, agent की संभावित पूरी job list से नहीं।
• काम या पहचानी गई process समाप्त होते ही अनुमति खत्म हो जाए।
• व्यक्ति सबसे खराब संभावित परिणाम बता सके, अगर agent किसी स्वीकृत action को दोहराए।

चौथी बात अधिकांश checklists से ज्यादा खराब designs पकड़ लेती है। अगर जवाब है «यह एक और मामूली request करेगी», तो session approval ठीक हो सकता है। अगर जवाब में पैसे, customer communication, production state, deletion, access changes या बड़ा export शामिल है, तो हर action के पास इंसानी निर्णय रखें।

काम की अवधि तय करती है कि session का वादा कितना मायने रखता है

Session तब सबसे सुरक्षित होता है जब वह छोटा हो, एक task तक सीमित हो और एक ऐसी process से जुड़ा हो जो काम पूरा होते ही बंद हो जाए। जो session चुपचाप असंबंधित काम तक चलता रहे, वह friendly नाम वाला स्थायी permission है।

अवधि जोखिम बदलती है क्योंकि agent पहली intended action पूरी करने के बाद reasoning बंद नहीं करती। वह retry कर सकती है, नई subtask पर जा सकती है, दूसरी repository देख सकती है या किसी file अथवा ticket से मिली गलत instruction का पालन कर सकती है। Process जितनी देर जीवित रहती है, आपका मूल mental model उतना कम उपयोगी होता जाता है। Failing tests देखने के लिए दस मिनट का run समझ में आता है। पूरी दोपहर चलता process नया context जमा कर चुका होता है, लक्ष्य बदल चुके होते हैं और hostile या misleading input मिलने के मौके बढ़ जाते हैं।

जहां संभव हो, clock के बजाय task boundary इस्तेमाल करें। Process exit ईमानदार end condition है: स्वीकृत agent अब मौजूद नहीं है। Fixed timeout fallback है, बराबर का control नहीं। पंद्रह मिनट पर agent अभी मूल काम कर रही हो सकती है, या कोई अलग tool वही authority ले चुका हो सकता है। केवल समय यह नहीं बता सकता कि इनमें से क्या हुआ।

सीमित session के लिए approval देने से पहले काम की unit लिखें। अच्छा विवरण ठोस होता है: «failing continuous-integration run देखें और findings के साथ draft comment खोलें।» खराब विवरण है «release में मदद करें।» व्यापक भाषा agent को छोटे diagnostic job को release work में बदलने की जगह देती है।

इन task shapes पर विचार करें:

लोगों को interruption पसंद नहीं, इसलिए लोकप्रिय shortcut है कि हर task के लिए session approve कर दें। Low-consequence calls पर prompts आने की शिकायत जायज है। समाधान credentials को सीमित करना और routine work को वास्तविक sessions में समूहित करना है, न कि लंबे agent run को all-access window बना देना।

Agent restarts में भी यही सावधानी रखें। Command शुरू करने वाले व्यक्ति को restart continuity जैसा लग सकता है, लेकिन यह नई process होती है और अलग instructions, code या plugins लोड कर सकती है। Restart के बाद नई session authorization मांगें। यह bureaucracy नहीं है। मूल निर्णय किसी खास executable authority और run से जुड़ा था, developer के उस अस्पष्ट इरादे से नहीं कि आज दोपहर क्या करना है।

Credential की संवेदनशीलता secret के प्रकार से नहीं, capability से शुरू होती है

Credential इस वजह से sensitive है कि वह क्या करा, दिखा या delegate कर सकता है, न कि इसलिए कि उसका कोई खास नाम है। केवल एक public build artifact पढ़ने वाली API key उस token से कम खतरनाक हो सकती है जो private workspace के administrators तक पहुंच देता है। Deployment host तक पहुंचने वाली SSH key का failure mode billing API को call करने वाले token से अलग है, लेकिन दोनों को per-call control की जरूरत हो सकती है।

हर credential को remote system की वास्तविक permissions के आधार पर classify करें। «Read token» जैसे label को बिना जांचे स्वीकार न करें। कुछ services export endpoints को read मानती हैं। कुछ supposedly read-only endpoints report generation शुरू कर सकती हैं, scarce capacity खर्च कर सकती हैं या ऐसा data लौटा सकती हैं जिसे agent को bulk में कभी नहीं देखना चाहिए।

Approval level चुनने से पहले मैं चार सवाल पूछता हूं:

1. क्या यह credential local machine के बाहर state बदल सकता है?
2. क्या यह ऐसी जानकारी दिखा सकता है जिसे agent के context या output में सुरक्षित रूप से नहीं रखा जा सकता?
3. क्या यह सीधे या किसी शुरू किए जा सकने वाले workflow के जरिए अधिक access दे सकता है?
4. क्या caller पैसे खर्च कर सकता है, quota इस्तेमाल कर सकता है या contractual अथवा reputational commitment बना सकता है?

किसी सवाल का जवाब हां होना हमेशा per-call approval को अनिवार्य नहीं बनाता। लेकिन इसका मतलब है कि session approval के लिए task अधिक सीमित, scope अधिक कड़ा और rollback संभव होना चाहिए। अगर कई जवाब हां हैं, तो हर बार पूछना आम तौर पर ईमानदार विकल्प है।

पहले scope घटाएं, फिर approval लगाएं। केवल एक repository पढ़ सकने वाला token आपको पूरे organization की हर repository पढ़ने वाले token से कहीं बेहतर session decision देता है। केवल एक staging environment तक सीमित credential को session को देना उस credential से सुरक्षित है जो production चला सकता है। Agent के पास महंगी requests करने का अधिकार आ जाने के बाद इंसानी approval बहुत व्यापक token की भरपाई नहीं कर सकता।

SSH पर विशेष ध्यान दें क्योंकि लोग इसे अक्सर «सिर्फ shell access» कहते हैं। Shell access बड़े और बदलते action surface तक transport है। असली जोखिम account, host, network reachability, उपलब्ध commands, deployment hooks और account द्वारा पढ़ी जा सकने वाली files पर निर्भर करता है। एक restricted account जो एक diagnostic command चला सकता है, session के लिए ठीक हो सकता है। Deployment account, customer data वाले host या access controls बदल सकने वाले account को per-call approval के पीछे रखें, जब तक आप उसे सीमित न कर सकें।

Credential rotation को इस analysis से बचने का रास्ता न बनने दें। व्यापक production rights वाली नई key भी व्यापक production rights ही रखती है। खराब run के बाद उसे rotate करने से भविष्य के दुरुपयोग की सीमा घटती है, लेकिन पहले सफल हो चुकी remote calls वापस नहीं आतीं।

दोहराव मामूली action को महंगा बना देता है

कोई request अकेले स्वीकार्य हो सकती है और फिर भी agent के उसे दोहराने पर unsafe बन सकती है। Prompt में दिखी पहली action ही नहीं, repeated action को classify करें।

यहीं teams HTTP method names पर जरूरत से ज्यादा भरोसा करती हैं। RFC 9110 कहता है कि safe methods read-only होने के लिए intended हैं: GET, HEAD, OPTIONS और TRACE। वह यह भी चेतावनी देता है कि safe method के जरिए server unsafe behavior दिखाए तो client को जिम्मेदार नहीं ठहराया जा सकता, क्योंकि resource owner वह behavior चुनता है। यह बात महत्वपूर्ण है। GET endpoint का semantic उद्देश्य information retrieve करना हो सकता है, फिर भी application उसे महंगा बना सकती है, massive export दिखा सकती है, audit field update कर सकती है या downstream work शुरू कर सकती है। Method names investigation शुरू करने में मदद करते हैं, पूरी जांच नहीं करते।

Idempotence का भी लोग गलत अर्थ लगाते हैं। Request idempotent तब होती है जब उसे दोहराने का server state पर intended effect उसे एक बार करने जैसा ही हो। इसका अर्थ यह नहीं कि दोहराना harmless है। true flag सेट करने वाली PUT request idempotent हो सकती है, फिर भी production feature activate कर सकती है। DELETE पहली deletion के बाद idempotent हो सकता है, फिर भी कोई महत्वपूर्ण चीज हटा सकता है। GET protocol के अर्थ में safe हो सकता है, फिर भी agent loop करने पर rate limit खत्म कर सकता है।

Endpoint के repeat behavior को disposable account या staging environment में जांचें। वही request दो बार भेजें, फिर remote state और side effects दोनों देखें और पूछें कि agent इसे सौ बार भेजे तो क्या होगा। केवल response body पर न रुकें। भेजे गए messages, queued jobs, बने audit records, इस्तेमाल हुआ quota, fired webhooks और कहीं और copy हुआ data भी देखें।

Objects बनाने वाले endpoint के लिए, अगर service support करती हो, idempotency key इस्तेमाल करें। यह request shape network retry के कारण दूसरा payment, ticket या provisioning request बनने से रोकती है, जब पहली response खो जाए:

POST /v1/provisioning-requests HTTP/1.1
Authorization: Bearer injected-by-gateway
Idempotency-Key: agent-run-8b2f1-request-17
Content-Type: application/json

{"environment":"staging","version":"2025.04.18"}

वही idempotency key फिर मिलने पर service को original result लौटाना चाहिए। Response में अक्सर वही object identifier और success status होता है, नया object नहीं। Service की documentation में यह behavior देखें और खुद भी test करें। Idempotency key retries से duplicate creation घटाती है, अनुचित deployment को उचित नहीं बनाती और agent को हर गलत कोशिश के लिए नई key बनाने से नहीं रोकती।

इनमें से कोई repeat profile हो तो per-call approval उपयुक्त है:

• हर call कोई नई चीज बनाती है, जैसे invoice, account, ticket, message या order।
• हर call live state बदलती है और पिछली state को फिर से बनाना कठिन है।
• हर call कोई दूसरा page, दूसरा archive या किसी दूसरे customer का data उजागर कर सकती है।
• हर call public या customer-facing प्रभाव बना सकती है।
• हर call पैसे खर्च करने वाला या सीमित capacity घेरने वाला काम शुरू कर सकती है।

Repeated calls का remote side पर असर मामूली हो, credential का scope छोटा हो और task का स्पष्ट exit हो, तो session repeated calls के लिए ठीक है। यह दावा साबित करने की जिम्मेदारी team की है। «Agent शायद loop नहीं करेगी» endpoint की कोई property नहीं है।

Read-only label जोखिम तय नहीं करता

Read access remote record को बदल न सके, फिर भी privacy, operational और prompt-injection risk पैदा कर सकता है। Data exposure को परिणामों वाली action मानें, खासकर तब जब agent retrieved data को summarize, copy या अगले कदम का आधार बना सकती हो।

मान लें agent को support system खोजने की अनुमति है। एक ticket और उसके attachments तक सीमित task के लिए session उचित हो सकता है। वही credential उस run के लिए बहुत कठिन हो जाता है जो हर ticket enumerate कर सकता है, exports ला सकता है या private customer conversations को local context में खींच सकता है। Endpoint हर जगह GET इस्तेमाल कर सकता है। जोखिम verb नहीं, data boundary तय करती है।

असहज सवाल यह है कि क्या agent को लौटाया गया result खुद देखने की अनुमति है। Credential gateway tokens को agent से दूर रखता है, लेकिन इससे हर result अपने-आप सुरक्षित नहीं हो जाता। Responses में secrets अक्सर leak होते हैं: configuration endpoints connection strings लौटाते हैं, user records personal data रखते हैं, command output में environment variables होते हैं और error responses internal paths या identifiers दिखाते हैं।

जब कोई result sensitive information की category दिखा सकता हो या agent का search space खुद बढ़ सकता हो, तब read के लिए per-call approval चुनें। इसमें broad search, exports, secret retrieval, account enumeration और cat जैसे commands शामिल हैं जो बदलती सामग्री वाली directories पर चलें। Data को run में छोड़ने से पहले व्यक्ति को target देखने का मौका मिलना चाहिए।

Routine reads के लिए request shape सीमित करें। Project, repository, environment या API resource group तक सीमित credential को प्राथमिकता दें। जहां service page limits देती हो, server-side limits लगाएं। संभव हो तो unrestricted search endpoint के बजाय agent को ऐसा query mechanism दें जो explicit identifiers स्वीकार करे। इन विकल्पों से approval prompts घटते हैं क्योंकि allowed call खुद छोटी होती है।

Incident response में एक failure pattern दिखता है। Agent logs देखने के लिए harmless request से शुरू करती है, log line में token पाती है और फिर broad archive में उस token की हर occurrence खोजती है। इंसान के मन में original session approval troubleshooting तक सीमित था, लेकिन credential scope और query shape ने collection की अनुमति दी। Operator activity list में कोई mutation नहीं देखता और run को safe मान लेता है। संवेदनशील action retrieval थी।

क्या मांगा गया, कौन सा credential इस्तेमाल हुआ और call को session action या per-call action के रूप में approve किया गया था, इसका अलग record रखें। इससे investigator compromised agent और खराब approval choice में फर्क कर सकता है। यह उन credentials को भी सामने लाता है जिनका scope और छोटा होना चाहिए। केवल सफल mutations log करने से सबसे कठिन retrieval failures छिपे रहते हैं।

Prompts को उन फैसलों से जोड़ें जो व्यक्ति सचमुच ले सकता है

जब prompts इतने अधिक हों कि पढ़े ही न जाएं या इतने अस्पष्ट हों कि उनका आकलन न हो सके, तो approval fatigue design failure है। Per-call approval तभी काम करती है जब हर prompt reviewer को किसी ठोस परिणाम को स्वीकार या अस्वीकार करने के लिए पर्याप्त जानकारी दे।

अच्छा prompt calling process, credential या action category, destination और material effect बताता है। «Allow API request» किसी को अच्छा निर्णय लेने में मदद नहीं करता। «Signed agent process release credential का उपयोग करके production deployment मांग रही है» करता है। Sensitive read के लिए prompt को केवल «GET request» कहने के बजाय data set या target का नाम देना चाहिए। SSH के लिए host और command, या अर्थपूर्ण command class दिखाएं।

Prompt overload का समाधान destination छिपाना नहीं है। Friendly task name देखकर request approve करने वाला developer typo, malicious instruction या agent के बदले हुए रास्ते को नहीं पकड़ पाएगा। Prompt में इतना विवरण होना चाहिए कि intended work और actual action के बीच mismatch दिख सके।

साथ ही, हर routine request के लिए लोगों से raw HTTP body पढ़ने की मांग न करें। इससे ceremonial approvals पैदा होती हैं। बार-बार होने वाली low-impact calls को सीमित session में रखें और per-call prompts उन operations के लिए बचाएं जो वास्तविक decision boundary पार करती हैं। व्यक्ति को कम prompts दिखने चाहिए, लेकिन बाकी prompts महत्वपूर्ण होने चाहिए।

हर credential configuration के पास छोटा approval note रखें। यह policy language नहीं है और इसे policy बनने की जरूरत नहीं। «एक repository के build-status reads के लिए केवल session; हर production release को approve करें» जैसा वाक्य बाद की reviews को ठोस बनाता है। अगर team ordinary work और consequential action को अलग करने वाला एक वाक्य नहीं लिख सकती, तो credential शायद बहुत व्यापक है।

Session authorization में दिखाई जाने वाली process identity पर भी ध्यान दें। इंसानों को केवल ऐसे command line को नहीं, बल्कि executable authority को approve करना चाहिए जिसे copy या बदला जा सकता है। Signed parent process और unsigned helper अलग trust decisions हैं। अपरिचित authority मिलने पर run रोकें, बदलाव का कारण पहचानें और केवल expected होने पर approve करें। Urgent task के कारण क्लिक करना organization को impersonation path स्वीकार करना सिखाता है।

Approval setting बदलने से पहले decision matrix इस्तेमाल करें

छोटी matrix prompts के प्रति व्यक्तिगत सहनशीलता पर होने वाले विवाद रोकती है। Action को उसके consequence के आधार पर score करें और जब score दो दिशाओं में संकेत करे तो कड़ा स्तर चुनें।

Table mixed answers दे तो बीच का रास्ता न चुनें, workflow अलग करें। Diagnostics के लिए agent को session-approved credential दें और remediation के लिए per-call credential। इससे बार-बार reads approve करने या mutations से बचने के लिए broad session देने की तुलना में workflow अधिक स्वाभाविक रहता है।

एक उदाहरण देखें। Agent failed deployment की जांच करती है। उसे build logs पढ़ने, किसी खास staging environment का status लेने और संभवतः एक service restart करने की जरूरत है।

Logs और status calls session approval के तहत चल सकती हैं, अगर token केवल उसी project तक पहुंचे और diagnosis के बाद process बंद हो जाए। Restart के लिए अलग credential और per-call approval होना चाहिए क्योंकि इससे running state बदलती है। Service restart आम तौर पर safe हो, तब भी बार-बार restart active work रोक सकते हैं, मूल कारण छिपा सकते हैं और automatic recovery loops शुरू कर सकते हैं। Agent को restart एक उचित fix लगा, इससे वह routine नहीं बन जाता।

अब एक बात बदलें: status API हर production environment को query कर सकती है और log retrieval unredacted customer payloads ला सकता है। Diagnostic credential के लिए session approval अब ठीक नहीं है। Team को पहले access सीमित करना चाहिए। उसी broad credential को per-call approval के पीछे रखने से एक तरह की failure घटती है, लेकिन data selector unconstrained हो तो reviewer हर retrieval request का भरोसेमंद आकलन नहीं कर सकता।

इसीलिए प्रति-agent एक ही setting खराब model है। Approval action channel और credential scope से जुड़ी होनी चाहिए। अगर boundaries जानबूझकर बनाई जाएं, तो एक agent run दोनों levels को सुरक्षित रूप से मिला सकता है।

Audit trails खराब निर्णय समझाते हैं, उसे पलट नहीं सकते

Tamper-evident record agent run की जांच करने, active session revoke करने और यह तय करने देता है कि agent ने action दोहराई थी या नहीं। लेकिन जो call आप पहले ही approve कर चुके हैं, उसे remote service स्वीकार करने से यह नहीं रोकता।

Activity के दो views रखें। Session record बताता है कि किसने run किया, कब शुरू किया, उसके पास कौन सी process authority थी और क्या किसी ने उसे revoke किया। Call record बताता है कि agent ने कौन सा credential path इस्तेमाल किया, किस destination से संपर्क किया और call को session authorization मिली थी या fresh approval। दोनों जरूरी हैं। Sessions की list यह साबित नहीं कर सकती कि समस्या किस action से हुई, जबकि process context के बिना calls का ढेर यह नहीं बता सकता कि शुरुआत किसने की।

Audit integrity को slogan नहीं, testable चीज बनाएं। Hash-chained log में stored sequence से कोई record बदलने, हटाने या reorder करने पर verification fail होना चाहिए। Test सरल है: known-good copy verify करें, copy में एक byte बदलें और फिर verify करें। Verifier को बताना चाहिए कि chain अब validate नहीं होती, जबकि original अब भी verify हो। यह test fixture में करें, production audit store को कभी edit करके नहीं।

Sallyport अपने Sessions और Activity journals को write-blind encrypted, hash-chained audit log से project करता है और sp audit verify vault key के बिना ciphertext पर offline chain check करता है। यह separation तब उपयोगी है जब records जांचने वाले व्यक्ति को vault द्वारा सुरक्षित credentials या action payloads नहीं मिलने चाहिए।

Logs एक आम approval mistake भी दिखाते हैं: session को देखना बंद करने का बहाना मानना। उन runs की review करें जिनमें असामान्य रूप से बहुत calls हुईं, नई destination से संपर्क हुआ, task description से कहीं ज्यादा देर चलीं या credential को उसकी सामान्य category से बाहर इस्तेमाल किया गया। इन patterns को पहचानने के लिए rules engine जरूरी नहीं। हर सप्ताह छोटे sample की human review scope creep को सामान्य आदत बनने से पहले पकड़ सकती है।

जब agent गलत व्यवहार करे, configuration बदलने से पहले process identity, task input, session record, call sequence और remote service logs सुरक्षित रखें। फिर «क्या agent compromise हो गई थी?» से अधिक सीमित सवाल पूछें। क्या credential scope ने action की अनुमति दी थी? क्या approval level repeat risk के अनुरूप था? क्या prompt में उसे अस्वीकार करने के लिए पर्याप्त जानकारी थी? Authorization के बाद process बदली थी? इन जवाबों से सुधार निकलते हैं। Autonomy पर सामान्य रोक से नहीं।

छोटी शुरुआत व्यापक exception से बेहतर है

ऐसे एक workflow से शुरू करें जिसका असर आप अस्पष्ट शब्दों के बिना बता सकें, फिर सबसे अधिक नुकसान कर सकने वाले credential पर per-call approval लगाएं। कई वास्तविक runs देखने के बाद routine हिस्से को सीमित session में ले जाएं।

Mac-based agent setup के लिए Sallyport API और SSH credentials को encrypted vault में रखता है और secret agent को देने के बजाय action खुद execute करता है। इससे credential exposure घटता है, लेकिन approval boundary चुनते समय उतनी ही सावधानी चाहिए क्योंकि remote action फिर भी वास्तविक रहती है।

पहली configuration developer को थोड़ा अधीर बनाए, अंधा नहीं। अगर हर run में build-status reads के लिए prompts की पूरी stack आती है, तो scope या task grouping पर काम चाहिए। अगर एक approval के बाद agent एक घंटे तक production बदल सकती है, तो session बहुत व्यापक है। इंसान को loop से बाहर करने से पहले credential और task boundary ठीक करें।

अगला approval choice operational terms में लिखें: यह signed process, इस task के लिए, exit होने तक ये low-impact calls कर सकती है; दूसरे credential के हर उपयोग पर fresh decision चाहिए क्योंकि उससे ऐसी चीज बदल सकती है जिसे हम आसानी से वापस नहीं कर सकते। यह वाक्य reviewers को दबाव में भी एक समान standard देता है। इससे अधिक अस्पष्ट बात अंततः स्थायी exception बन जाएगी।