सुरक्षित agent actions के लिए approval latency budget

Agent approvals दो विपरीत तरीकों से विफल हो सकती हैं। हर कार्रवाई के लिए किसी व्यक्ति से पूछें, तो agent अपना दिन review queue के पीछे इंतज़ार करते हुए बिताएगा। इंतज़ार परेशानी पैदा करता है, इसलिए decision point हटा दें, तो agent को ऐसी authority मिल जाएगी जिसकी कोई सार्थक निगरानी नहीं कर सकता।

Approval latency budget दोनों विफलताओं को रोकता है। यह बताता है कि agent की किसी खास श्रेणी की कार्रवाई के लिए मानवीय निर्णय में अधिकतम कितना समय लगना चाहिए, यह मापता है कि वह समय कहाँ जा रहा है और routine work उस सीमा में न आए तो workflow को फिर से बनाने के लिए मजबूर करता है। Budget लोगों से तेज़ी से click करवाने का target नहीं है। यह workflow और agent को दी गई authority पर लगी सीमा है।

मैंने teams को approval prompt को control का प्रमाण मानते देखा है, फिर पाया कि कोई developer अपने काम के बीच लगभग एक जैसी बीस requests मंज़ूर कर रहा है। वह व्यक्ति review नहीं कर रहा। वह एक धीमे relay की तरह काम कर रहा है। इसका समाधान शायद ही बेहतर reminder notification होता है। आम तौर पर ज़रूरत कम अस्पष्ट authority, कम अनावश्यक calls और उन कार्रवाइयों के लिए स्पष्ट escalation path की होती है जिनमें सचमुच friction होना चाहिए।

Approval latency budget मानवीय निर्णय की समय सीमा है

Approval latency budget वह अधिकतम स्वीकार्य समय है जो किसी request के review योग्य बनने और अंतिम allow या deny decision के बीच हो सकता है। यह action class के अनुसार बदलना चाहिए, क्योंकि pull request पढ़ना, temporary test resource बनाना और production access setting बदलना, इन तीनों की urgency और consequence एक जैसी नहीं होती।

Budget को action contract का हिस्सा मानें। अगर interactive task को आगे बढ़ाने के लिए agent को दो मिनट के भीतर जवाब चाहिए, तो system को या तो उस कार्रवाई को दो मिनट में समझने लायक बनाना होगा या सामान्य काम के दौरान उसके लिए approval माँगना छोड़ना होगा। अगर कोई task सुरक्षित रूप से सुबह तक रुक सकता है, तो उसे interruptive prompt की ज़रूरत बताने का कोई कारण नहीं है।

Budget के तीन हिस्से हैं:

• Queue wait: request बनने से reviewer के उसे खोलने तक का समय।
• Decision time: request खोलने से allow या deny तक का समय।
• Dispatch time: निर्णय से action शुरू होने या विफल होने तक का समय।

कई teams इन सबको एक संख्या में मिलाकर approval time कहती हैं। इससे सुधार का सही क्षेत्र छिप जाता है। बीस मिनट का queue wait routing, ownership या scheduling में बदलाव माँगता है। बीस मिनट का decision time बताता है कि request में context कम है, authority बहुत अधिक है या वह ऐसा निर्णय माँग रही है जिसे जल्दी में काम कर रहे व्यक्ति तक पहुँचना ही नहीं चाहिए था।

Budgets को abstract security tier के आधार पर नहीं, काम की deadlines के आधार पर तय करें। शुरुआत के लिए एक उचित table कुछ ऐसी हो सकती है:

ये उदाहरण हैं, universal policy नहीं। On call rotation वाली deployment team की window solo developer से अलग हो सकती है। बात यह है कि queue बनने से पहले expectation स्पष्ट हो।

जब तक आप इसे staff न कर सकें, इसके लिए service level agreement का इस्तेमाल न करें। Budget design limit है। यह बताता है कि कोई task interactive decision पर निर्भर नहीं हो सकता अगर निर्णय लेने वाले लोग सो रहे हों, meetings में हों या incident संभाल रहे हों। Agent को भी यह पता होना चाहिए। वह request तैयार कर सकता है, सुरक्षित alternate path चुन सकता है या स्पष्ट explanation के साथ रुक सकता है। उसे हर मिनट वही request फिर से नहीं भेजनी चाहिए।

Button click के बजाय request lifecycle मापें

अगर आपके timestamps notification के phone तक पहुँचने से शुरू होते हैं, तो approval delay को बेहतर नहीं कर पाएँगे। शुरुआत उस क्षण से करें जब system review योग्य action बनाता है। फिर request identifier की मदद से हर state transition record करें, ऐसा identifier जो retries और UI refreshes के बाद भी वही रहे।

ऐसा छोटा event record इस्तेमाल करें। Fields जानबूझकर साधारण हैं। साधारण records sort और join किए जा सकते हैं और incident review में टिके रहते हैं।

{
  "request_id": "req_7f31",
  "run_id": "run_241",
  "action_class": "bounded_write",
  "target": "issue tracker/project-amber",
  "created_at": "2025-03-08T14:02:01Z",
  "presented_at": "2025-03-08T14:02:03Z",
  "opened_at": "2025-03-08T14:09:18Z",
  "decided_at": "2025-03-08T14:10:06Z",
  "decision": "allow",
  "executed_at": "2025-03-08T14:10:07Z",
  "outcome": "success"
}

इस structure के साथ queue wait को opened_at - presented_at, decision time को decided_at - opened_at और dispatch time को executed_at - decided_at के रूप में निकालें। created_at भी रखें। इससे एक शांत defect पकड़ में आता है: ऐसा broker जो किसी के request देख पाने से पहले उसे रोककर रखता है।

एक query जटिल analytics stack के बिना भी measurements दिखा सकती है:

SELECT
  action_class,
  percentile_cont(0.50) WITHIN GROUP (ORDER BY opened_at - presented_at) AS p50_queue_wait,
  percentile_cont(0.95) WITHIN GROUP (ORDER BY opened_at - presented_at) AS p95_queue_wait,
  percentile_cont(0.95) WITHIN GROUP (ORDER BY decided_at - opened_at) AS p95_decision_time,
  count(*) FILTER (WHERE decision = 'deny') AS denied,
  count(*) AS total
FROM approval_requests
WHERE created_at >= current_timestamp - interval '14 days'
GROUP BY action_class;

अलग-अलग databases में percentile syntax अलग हो सकती है। Measurement वही रहता है। हर action class के लिए p50 और p95, count और deny rate के साथ report करें। Average किसी पाँच सेकंड के अनुभव को उन कुछ requests के साथ मिलाकर ठीक दिखा सकता है जो नब्बे मिनट तक पड़ी रहीं। p95 बताता है कि slow tail वास्तविक tasks को तोड़ रही है या नहीं।

यह भी record करें कि decision आने से पहले agent ने task cancel, retry या abandon किया था या नहीं। ऐसी देर से मिली approval, जो agent के दूसरा path चुनने के बाद execute हो, सामान्य denial से भी खराब है। इससे ऐसी action बनती है जो developer के सामने मौजूद काम से अब मेल नहीं खाती।

Reviewers को केवल decision time घटाने पर reward न दें। इससे सोच-समझकर किए गए denials performance problem जैसे दिखेंगे। Allows, denials, expirations और withdrawals का distribution साथ में देखें। Denials का अचानक कम होना और read times का बहुत छोटा होना अक्सर बताता है कि लोगों ने सीख लिया है कि allow पर click करने से परेशानी दूर हो जाती है।

Waiting time और review time अलग defects की ओर इशारा करते हैं

Queue wait और decision time एक ही clock साझा करते हैं, लेकिन उनके कारण और owners अलग होते हैं। उन्हें एक मानने से गलत fixes निकलती हैं।

जब requests गलत व्यक्ति तक पहुँचती हैं, बहुत से लोग मान लेते हैं कि कोई दूसरा निर्णय लेगा, notifications working hours के बाहर आती हैं या reviewer के पास अपने मौजूदा काम को रोकने का कोई कारण नहीं होता, तब queue wait बढ़ती है। और notifications जोड़ना अक्सर इसे और खराब करता है। इससे वही अस्पष्ट जिम्मेदारी अधिक लोगों में फैलती है।

Decision time तब बढ़ता है जब card reviewer को agent का intent खुद समझने पर मजबूर करता है। POST /v1/resources जैसा request review योग्य नहीं है। Reviewer को destination, operation, object count, इस्तेमाल की गई authority और दिखाई देने वाला consequence पता होना चाहिए। उसे terminal खोलकर source code देखना और यह अनुमान नहीं लगाना चाहिए कि request draft बनाएगी या customers को message भेजेगी।

एक उपयोगी approval card साधारण भाषा में पाँच सवालों के जवाब देता है:

1. किस agent run ने request बनाई और किस signed process ने वह run शुरू की?
2. Action किस external target तक पहुँचेगी?
3. क्या बदलेगा या कौन-सा data machine से बाहर जाएगा?
4. कौन-सी bounded authority इसे अनुमति देती है?
5. Reviewer deny करे या कुछ न करे तो क्या होगा?

ज़्यादा detail को बेहतर context न समझें। पूरा raw payload उस एक field को छिपा सकता है जो वास्तव में महत्वपूर्ण है। पहले संक्षिप्त consequence दिखाएँ, फिर ज़रूरत होने पर reviewer को command, secrets हटाए गए headers, endpoint और payload देखने दें। Deletion मंज़ूर करने वाले reviewer को प्रभावित object names चाहिए। HTTP read मंज़ूर करने वाले reviewer को host, path और query scope चाहिए। हर action के लिए उसके risk के अनुरूप evidence चाहिए।

बार-बार होने वाली गलती यह है कि teams broad session approval देकर queue wait घटाती हैं, जबकि reviewer धीमा इसलिए था क्योंकि action अस्पष्ट थी। इससे context problem authority problem में बदल जाती है। पहले request description और action boundary सुधारें।

उलटी गलती भी होती है: teams सौ सामान्य reads के लिए अलग-अलग confirmation माँगती हैं क्योंकि queue असुरक्षित लगती है। Queue इसलिए असुरक्षित है क्योंकि वह habituation पैदा करती है। कम प्रभाव वाले बार-बार prompts reviewer को content के बजाय shape और timing देखकर approve करना सिखाते हैं। जब कोई महत्वपूर्ण request आएगी, तब भी यही आदत बनी रहेगी।

Review queue बताती है कि workflow का रूप बदलना चाहिए

Queue केवल काम में देरी नहीं करती। वह agent और human दोनों का व्यवहार बदल देती है। Agent retries करता है, task को छोटी calls में बाँटता है या अधूरी योजना रोककर रखता है। Human बढ़ता हुआ ढेर देखता है और उसे batches में साफ़ करना शुरू करता है। हर response के साथ queue कम चिंताजनक लगती है, जब तक कोई असामान्य request परिचित requests के बीच छिपी रहती है।

एक आम विफलता देखें। Agent से issue tracker data के आधार पर release note तैयार करने को कहा गया है। पहले वह project list पढ़ता है, फिर हर issue लाता है, चुने हुए issues के comments पढ़ता है और अंत में draft note बनाता है। ऐसा workflow जो हर HTTP call पर approval माँगता है, एक छोटे task को दर्जनों prompts में बदल देता है।

9:30 पर developer पहले कुछ reads को ध्यान से मंज़ूर करता है। 9:45 पर उसकी meeting है। 10:30 तक agent ने retries और संबंधित calls queue कर दी हैं। Developer लौटता है, उसी service के requests की लंबी दीवार देखता है और जल्दी-जल्दी approve करता है। एक request draft note के बजाय public comment बना देती है, क्योंकि endpoint और intended outcome raw request text में दबे हुए थे। उस queue में developer के पास इसे पहचानने का वास्तविक मौका नहीं था।

गलत निर्णय public comment से पहले ही शुरू हो गया था। Workflow ने routine reads को visible write के साथ प्रतिस्पर्धा करने पर मजबूर किया। उसने human से लंबे interruption के बाद context याद रखने की अपेक्षा भी की। यह design defect है, reviewer की विफलता नहीं।

काम को meaningful intent के अनुसार group करके इसे ठीक करें। अगर read session कुछ mutate नहीं कर सकता, तो वह named service और task duration को cover कर सकता है। Draft creation एक explicit decision माँग सकती है, जिसमें draft location और audience स्पष्ट हों। Public publication अलग रहनी चाहिए, क्योंकि उसका consequence review question बदल देता है।

इसे blanket instruction से हल न करें कि agent "issue tracker का उपयोग कर सकता है।" यह वाक्य बहुत कुछ छिपा देता है। इससे reviewer को पता नहीं चलता कि agent private issues पढ़ सकता है, labels edit कर सकता है, public comment कर सकता है या data delete कर सकता है। Scopes के नाम उन कार्रवाइयों से मेल खाने चाहिए जिन्हें लोग बाद में पहचान सकें।

यही तर्क SSH पर भी लागू होता है। Service log inspect करने का request और migration चलाने का request एक ही connection से जा सकते हैं, लेकिन उन्हें एक ही approval class में नहीं होना चाहिए। Connection identity, action identity नहीं है।

Approval scope transport के बजाय consequence के अनुसार होना चाहिए

अच्छी approval boundary यह बताती है कि व्यक्ति किस बात पर सहमत हो रहा है। HTTP बनाम SSH, command बनाम API call और local बनाम remote process, ये transport details हैं। Implementation के लिए वे महत्वपूर्ण हैं, लेकिन reviewer को यह नहीं बताते कि action reversible, external या महँगी है।

Consequence classes से शुरुआत करें। Read operations data disclose कर सकती हैं, इसलिए read का मतलब अपने-आप harmless नहीं है। Writes भी अलग-अलग होती हैं: private draft बनाना, production setting बदलना और message भेजना, तीनों state mutate करते हैं, लेकिन इनकी जाँच अलग तरह की होनी चाहिए। यह तय करने से पहले इन्हें अलग करें कि कौन-से interactions एक approval साझा कर सकते हैं।

फिर scope को उन dimensions में सीमित करें जिन्हें reviewer verify कर सकता है:

• Target: नामित host, repository, project या environment।
• Operation: read, draft बनाना, निर्दिष्ट field update करना या named command family चलाना।
• Object set: शामिल specific records, files या services।
• Duration: एक action, एक agent run या छोटी scheduled window।
• Consequence: private, reversible, externally visible या destructive।

Implementation की छोटी-छोटी बातों पर आधारित scopes से बचें। Allow POST requests transport rule है, approval boundary नहीं। POST draft बना सकता है या account हटा सकता है। Allow command line access में भी यही defect है। यह समझे हुए outcome के बजाय action का माध्यम देता है।

लोग अक्सर broad session approval की माँग करते हैं क्योंकि individual requests flow रोकती हैं। Flow रुकने की बात सही है, लेकिन जब session में असंबंधित operations मिल सकती हों, तो यही समाधान गलत है। Session तभी उचित है जब उसकी पूरी अवधि में target और permitted consequence स्पष्ट रहें। Agent release notes जुटाने से repository permissions बदलने पर जाए, तो उसे नया decision चाहिए।

जब किसी trusted run के भीतर भी consequence high रहे, तब per action confirmation इस्तेमाल करें। Publishing, deletion, access material rotate करना, network reachability बदलना और team के बाहर information भेजना आम तौर पर इसी श्रेणी में आते हैं। अपरिचित काम को दंड देने के लिए per action confirmation न लगाएँ। इसे वहाँ लगाएँ जहाँ हर occurrence में मानवीय judgment चाहिए।

Review controls ढीले करने से पहले routine work को फिर से बनाएं

जब approval latency budget से अधिक हो जाए, तो पहले उन requests को हटाएँ जिन्हें interactive बनना ही नहीं चाहिए था। इसका मतलब मनमानी actions की अनुमति देना नहीं है। इसका मतलब routine work को इतना bounded बनाना है कि human हर mechanical subcall के बजाय पूरे run या task को मंज़ूर कर सके।

Slow class पर इस क्रम में काम करें:

1. p95 requests का sample लें और हर request के आसपास का पूरा sequence पढ़ें। Retries और duplicate calls को आवश्यक calls से अलग गिनें।
2. उस पहली action को चिह्नित करें जहाँ consequence बदलता है। अक्सर explicit decision का सही स्थान यही होता है।
3. Deterministic reads को narrow task scope के भीतर consolidate करें, जिसमें known target हो और run समाप्त होने पर expiration हो।
4. External publication, deletion, permission changes और broad data export को अलग requests में बाँटें।
5. Task को ऐसे वास्तविक reviewer के साथ फिर test करें जिसने workflow design नहीं किया था। अगर वह approval से पहले expected result नहीं बता सकता, तो request को और सीमित करें।

Batching तभी मदद करती है जब batch खुद review योग्य हो। "Project Amber में ये चार draft issues बनाएं" उचित batch है, अगर card चारों issues और उनका destination बताती हो। "बाकी का सारा release work कर दें" batch नहीं है। यह open-ended delegation है।

Agent को केवल convenience के आधार पर अपनी batch boundary तय न करने दें। उसे task object दें: target, requested outcome, allowed data sources और expiry। Agent calls को इस object के नीचे रख सकता है, लेकिन target या consequence बदलते ही batch बंद होनी चाहिए। इससे incident review भी बेहतर होता है, क्योंकि log anonymous requests की लंबी stream के बजाय वास्तविक work unit दिखाता है।

Scheduled work को अलग redesign चाहिए। अगर human को रात में nightly maintenance action मंज़ूर करनी पड़ती है, तो team ने predictable failure बनाया है। या तो execution से पहले review window schedule करें, उचित budget वाले on call owner को assign करें या काम टाल दें। Unattended approval को automation का नाम न दें।

Retry करने की क्षमता पर विशेष ध्यान दें। अगर underlying action नहीं बदली है, तो agent को वही pending request identifier फिर इस्तेमाल करना चाहिए। हर retry के लिए नया approval card बनाना queue volume बढ़ाता है और reviewer का sequence पर भरोसा खत्म करता है। Target, payload, authority या intended consequence बदले, तो नई request बनाएं और बताएं कि क्या बदला।

Approval screen को सही निर्णय आसान बनाना चाहिए

Reviewer को intent का छोटा और स्पष्ट statement चाहिए, agent run को reverse engineer करने का निमंत्रण नहीं। Screen को उस decision के आसपास बनाएं जो उसे अभी लेना है, फिर गहरे evidence तक पहुँच दें, बिना उसे खोजने के लिए मजबूर किए।

सबसे पहले action outcome रखें: "Project Amber में private draft release note बनाएं" method और path से अधिक बताता है। इसके साथ target दिखाएँ। बताएं कि action data पढ़ती है, बदलती है, मिटाती है या भेजती है। अगर SSH इस्तेमाल हो रहा है, तो host का नाम दें और command इस तरह दिखाएँ कि redirection, file writes और privilege changes साफ़ दिखाई दें।

Authority context भी दिखाएँ। Reviewer को पता होना चाहिए कि request fresh agent process से आई है या पहले से approved run से, और क्या इस action के लिए special confirmation चाहिए। Process identity महत्वपूर्ण है, क्योंकि एक agent process की approval को उसी protocol पर बोलने वाले किसी असंबंधित process की चुपचाप अनुमति नहीं बनना चाहिए।

Sallyport इसके लिए एक fixed decision ladder इस्तेमाल करता है: locked vault हर action को deny करता है, नया agent process default रूप से session authorization पाता है और credential को हर use पर approval की आवश्यकता हो सकती है। First session card में process code-signing authority सबसे पहले दिखाई जाती है। यह उस व्यक्ति के सामने रखने के लिए सही detail है जो यह तय कर रहा है कि run वही है जिसे उसने शुरू करना चाहा था।

Screen को rules editor न बनाएं। Deadline के सामने खड़े reviewer को concrete request को approve, deny या inspect करना चाहिए। अगर team बार-बार exception चाहती है, तो interruption के क्षण से बाहर task scope या credential boundary फिर से बनाएं। Approval path में miniature policy language रखने से थके हुए लोगों से दबाव में security decisions program करवाने पड़ते हैं।

Denial informative होना चाहिए। Agent के लिए उपयोगी reason category लौटाएँ, जैसे expired, wrong target, narrower scope चाहिए या human review required। Untrusted agent को default रूप से private reviewer commentary न लौटाएँ। Agent को retry रोकने या safe alternate task चुनने के लिए पर्याप्त जानकारी चाहिए, internal deliberation का transcript नहीं।

Urgent request आने से पहले ownership और escalation तय करें

Owner के बिना approval budget एक इच्छा बन जाता है। हर action class के लिए वह व्यक्ति या rotation तय करें जो उसके चल सकने की अवधि में decision के लिए जिम्मेदार हो। Team review delegate कर सकती है, लेकिन इस तथ्य को delegate नहीं कर सकती कि किसी को decision लेना ही होगा।

हर budget boundary पर क्या होगा, यह तय करें। आधा budget बीतने पर, अगर request अनदेखी है, तो system assigned reviewer को एक बार notify कर सकता है। Budget limit पर low consequence request expire हो सकती है। High consequence request expire होकर task owner या on call rotation को notify करनी चाहिए, हमेशा pending नहीं रहनी चाहिए। Exact timing से अधिक महत्वपूर्ण है कि state visible और finite हो।

Business hours का ईमानदारी से इस्तेमाल करें। अगर developer रात में locally agent चलाता है और action के लिए teammate की approval चाहिए, तो task को इंतज़ार करना पड़ सकता है। यह स्वीकार्य है। विफलता तब होती है जब interface immediate progress का संकेत देता है और agent unattended queue के खिलाफ retry करता रहता है।

Escalation को authority कभी broad नहीं करनी चाहिए। Escalated request बेहतर स्थिति वाले reviewer तक जाए, automatic allow path तक नहीं। Incidents के दौरान यह अंतर महत्वपूर्ण है, जब urgency लोगों को हर control bypass करने के लिए प्रेरित करती है। Preapproved emergency procedures हो सकती हैं, लेकिन उनमें narrow action, named ownership और बाद की review स्पष्ट होनी चाहिए। "Production टूट गया है" approval scope नहीं है।

Agent delay के साथ people cost भी देखें। अगर लगभग सभी prompts एक developer को मिलते हैं, तो median latency अच्छी होने पर भी routing problem है। अगर हर reviewer को हर request दिखती है, तो team ने security labels वाला shared inbox बनाया है। दोनों patterns fatigue और कमजोर accountability पैदा करते हैं।

Queue को decisions के sequence की तरह audit करें

उपयोगी audit trail से final action से अधिक चीज़ें reconstruct होनी चाहिए। इसमें agent run, reviewer को दिखाई गई request, decision, वास्तविक external call और cancellation या retry दिखना चाहिए। इस sequence के बिना team यह नहीं जान सकती कि देर से मिली approval ने obsolete action चलाई या denial के बाद agent ने अपनी योजना बदली।

Approval evidence और action evidence को identifiers से जोड़कर रखें, लेकिन उन्हें एक न समझें। Approval यह बताती है कि stated intent को किसने authorize किया। Action record बताता है कि वास्तव में क्या attempt किया गया और target ने क्या लौटाया। Agent की request आधे रास्ते में विफल हो या remote service payload को अनपेक्षित ढंग से समझे, तो investigator को दोनों चाहिए।

Sallyport एक ही encrypted, hash-chained audit log से Sessions journal और Activity journal दोनों बनाता है। इसका sp audit verify command ciphertext पर offline chain जाँचता है और vault key की ज़रूरत नहीं पड़ती। यह तब उपयोगी है जब कोई agent credentials खोले बिना log integrity test करना चाहता हो।

Audit record को weekly review of exceptions में इस्तेमाल करें, ऐसे data vault की तरह नहीं जिसे कोई पढ़ता ही न हो। Expired requests, सबसे धीमे p95 examples, denied actions और लंबे इंतज़ार के बाद चली actions निकालें। हर मामले में एक ठोस सवाल पूछें: देरी ownership, unclear intent, oversized scope या अलग scheduling की ज़रूरत वाले task से आई थी?

Approval speed के आधार पर लोगों को grade न करें। Workflow को इस आधार पर grade करें कि वह task deadline से पहले समझने योग्य decision accountable व्यक्ति तक पहुँचाता है या नहीं। अगर बार-बार review केवल habitual allows पैदा करती है, तो repetition हटा दें। अगर किसी rare action को सोचने के लिए समय चाहिए, तो उसे उतना समय, context और ownership दें।

एक सप्ताह के lifecycle timestamps इकट्ठा करके शुरुआत करें। सबसे खराब p95 queue wait वाली एक action class चुनें, दस complete request sequences देखें और उस boundary को बदलें जिसने सबसे अधिक duplicate prompts बनाए। यह काम आपको किसी और dashboard से अधिक बताएगा।