Approval timeouts पुरानी approvals को नई कार्रवाइयां करने से रोकते हैं

Approval किसी एक समय पर प्रस्तावित एक कार्रवाई की अनुमति होती है। यह ऐसा कूपन नहीं है जिसे agent अपनी सुविधा के अनुसार कभी भी भुना सके।

बात साफ लगती है, जब तक कोई agent production deploy, deletion या SSH command को queue में डालकर किसी इंसान के व्यस्त होने का इंतजार न करे। Reviewer एक उचित अनुरोध देखता है और उसे approve कर देता है, फिर दुनिया बदल जाती है। कोई नया build queue में आगे आ जाता है। Target set बदल जाता है। कोई environment alias दूसरी जगह point करने लगता है। Incident के कारण safety conditions बदल जाती हैं। अगर पुरानी approval अब भी चल सकती है, तो system ने कल की स्थिति पर लिया गया निर्णय आज की स्थिति पर अधिकार में बदल दिया है।

Approval timeouts इस समस्या का केवल एक हिस्सा हल करते हैं, लेकिन teams अक्सर इसी हिस्से को खुला छोड़ देती हैं। जिन कार्रवाइयों का अर्थ बदल सकता है, उनकी approvals पर छोटी और सख्त expiry लगाएं। फिर approval को exact proposed action से बांधें और execution से पहले बदल सकने वाली conditions की दोबारा जांच करें। दोनों काम करें। अकेला कोई एक control gap छोड़ देता है।

हर approval की एक freshness budget होती है

हर approval execution का इंतजार करते हुए समय खर्च करती है। Target जितना अधिक बदल सकता है, budget उतनी ही छोटी होनी चाहिए।

किसी disposable preview worker को restart करने का अनुरोध आधे घंटे तक उपयोगी रह सकता है। Production में release promote करने का अनुरोध कुछ ही मिनटों में stale हो सकता है, अगर कोई दूसरा release, rollback या incident response अगला सही कदम बदल सकता हो। Named backup snapshot हटाने वाली command जल्दी expire होनी चाहिए, खासकर जब snapshot list पर retention का सक्रिय काम चल रहा हो। Mutable host alias पर चलने वाली SSH command के लिए सबसे छोटी window रखें।

खराब default यह है कि लोगों को परेशान न करने के लिए एक बड़ा number चुन लिया जाए। आठ घंटे सुविधाजनक लगते हैं। व्यवहार में इससे lunch, रात या shift handoff के दौरान approvals जमा होती रहती हैं। Reviewer 10:02 पर deploy approve कर सकता है, उसे भूल सकता है और 16:40 पर देख सकता है कि उसके click को बहुत बाद की queue state ने इस्तेमाल कर लिया। Approval interface सावधान दिख रहा था, लेकिन execution path लापरवाह था।

Window तय करते समय यह संकरा सवाल पूछें: यह exact proposed action कितनी देर तक होने वाली कार्रवाई का सही वर्णन बनी रह सकती है?

अधिकांश teams के लिए शुरुआती policy कुछ ऐसी हो सकती है:

• Production deploy या rollback: 5 से 15 मिनट।
• Destructive deletion: 2 से 10 मिनट, यह इस बात पर निर्भर है कि object set fixed है या नहीं।
• Write effects वाली SSH command: 2 से 5 मिनट।
• Read-only SSH inspection: per-action approval नहीं, या जरूरत होने पर लंबी window।
• Pinned build वाले routine nonproduction changes: 15 से 30 मिनट।

ये operating defaults हैं, सार्वभौमिक नियम नहीं। अगर कोई automation loop हर कुछ सेकंड में target बदल सकता है, तो पांच मिनट भी बहुत लंबा है। अगर on-call reviewer को पहले evidence जुटाना हो, तो यह समय बहुत कम है। सही जवाब deadline को चुपचाप हमेशा बढ़ाते रहना नहीं है। Reviewer को जरूरी context दें और request को current state से दोबारा बनाना आसान करें।

GitHub Actions यहां एक महत्वपूर्ण अंतर दिखाता है: deployment job required review का इंतजार कर सकता है और approval मिलने पर pending job आगे बढ़कर अपने environment secrets हासिल कर सकती है। GitHub यह भी बताता है कि unapproved job 30 दिनों के बाद fail हो सकती है। इससे queues हमेशा के लिए जीवित नहीं रहतीं, लेकिन बदलते deployment के approval के लिए 30 दिन कोई उपयोगी freshness window नहीं है। अपनी gate में approval age को queue housekeeping नहीं, authorization का हिस्सा मानें।

Decision को label से नहीं, action से बांधें

Approval में concrete action data होना चाहिए। «Production deploy approve करें» केवल एक label है। इससे reviewer को चलने वाली वस्तु के बारे में लगभग कुछ पता नहीं चलता।

Deploy के लिए decision को immutable artifact digest या commit identifier, destination, migration plan, configuration revision और release operation से बांधें। Delete के लिए immutable object list या query result के snapshot और deletion mode से बांधें। SSH के लिए verified host identity, user, command template, expanded arguments, relevant working directory और input files के bounded description से बांधें।

Teams सबसे ज्यादा इसी फर्क को धुंधला करती हैं:

• Intent की approval का अर्थ है कि reviewer किसी व्यापक उद्देश्य से सहमत है, जैसे «obsolete previews हटाएं»।
• Action की approval का अर्थ है कि reviewer इस executor द्वारा इन object identifiers को इस command से इस deadline से पहले हटाने पर सहमत है।

Change management में intent approval की जगह है। जब agent live system पर कार्रवाई कर सकता हो, तब यह execution approval का विकल्प नहीं बन सकती। अगर आप intent approve करके agent को बाद में targets तय करने देते हैं, तो आपने decision का महत्वपूर्ण हिस्सा agent को सौंप दिया है।

OWASP की Transaction Authorization Cheat Sheet किसी दूसरे domain में यही बात बताती है। इसमें कहा गया है कि transaction authorize करने वाले व्यक्ति को महत्वपूर्ण transaction data पहचानना और स्वीकार करना चाहिए। यह भी चेतावनी दी गई है कि authorization के बाद data बदलने से time-of-check to time-of-use failure पैदा होता है। उदाहरण financial है, लेकिन नियम यहां भी लागू होता है: approval data को modification से सुरक्षित रखना चाहिए और data बदलने पर existing authorization invalid होनी चाहिए।

Digest executor को तुलना के लिए कुछ सटीक देता है। किसी vague natural-language summary का hash बनाकर काम पूरा न मानें। प्रभाव नियंत्रित करने वाले fields को canonicalize करें, उन्हें deterministic तरीके से serialize करें और फिर उस canonical form का hash बनाएं।

{
  "request_id": "appr_01JX...",
  "action_type": "deploy",
  "action_digest": "sha256:8b1d...",
  "summary": {
    "artifact": "registry.example/app@sha256:4fa2...",
    "environment": "production",
    "operation": "promote",
    "config_revision": "7c0e...",
    "migration": "none"
  },
  "issued_at": "2026-07-22T14:03:00Z",
  "expires_at": "2026-07-22T14:13:00Z",
  "status": "pending"
}

summary इंसान के लिए है। action_digest executor के लिए है। दोनों रखें। इंसानों को उपयोगी facts दिखने चाहिए, जबकि services को exact equality check चाहिए। Agent एक भी bound field बदले, तो उसे नया request भेजकर नया decision लेना होगा।

Expiry और invalidation अलग failures हल करते हैं

Deadline पुरानी approvals को लंबे समय तक पड़े रहने से रोकती है। Invalidation relevant facts बदलते ही approval हटा देती है। दोनों जरूरी हैं, क्योंकि जब system पहले ही जानता है कि request reality से मेल नहीं खाती, तब timer का इंतजार करना लापरवाही है।

Action digest बदलने पर pending approval invalidate करें। यह नियम अनिवार्य है। उन dependencies के बदलने पर भी invalidate करें जो अर्थ को प्रभावित करती हैं: deployment का intended environment revision, selected deletion set, host key, release lock holder या required change ticket state।

हर असंबंधित event पर invalidate न करें। अगर कोई log line, unrelated commit या harmless metric shift approval खत्म कर दे, तो reviewers requests पर भरोसा खो देंगे और बिना जांचे approve करने लगेंगे। Rule को उन facts से जुड़ा होना चाहिए जो requested effect या safety preconditions को बदलते हैं।

दो नहीं, तीन states रखें:

1. pending का अर्थ है कि exact request को deadline से पहले अब भी approve किया जा सकता है।
2. approved का अर्थ है कि reviewer ने इसे approve कर दिया है, लेकिन executor ने इसे consume नहीं किया।
3. consumed का अर्थ है कि execution ने approval को ठीक एक बार claim किया है।

expired, invalidated, rejected और failed के लिए terminal states भी जोड़ें। Agent network call retry करे, इसलिए rejected request को फिर से pending न बनने दें। Failed execution उसी approval को चुपचाप दोबारा इस्तेमाल न करे, जब तक आप साबित न कर सकें कि action शुरू ही नहीं हुई और relevant state नहीं बदली। अधिकतर action systems में agent से फिर पूछना ज्यादा सुरक्षित और समझाने में आसान है।

Executor को ये checks एक transaction या atomic compare-and-set operation में करने चाहिए:

if now >= expires_at: reject as expired
if status != approved: reject as unavailable
if stored_digest != supplied_digest: reject as changed
if live_preconditions fail: reject as stale
atomically change status from approved to consumed
execute the action

Action शुरू होने के बाद approval को consumed mark न करें। दो workers race कर सकते हैं, दोनों approved देख सकते हैं और दोनों execution कर सकते हैं। पहले atomic state transition से consume करें, फिर execution शुरू होने का record लिखें। अगर process consume होने के बाद बंद हो जाए, तो outcome को unknown मानें, जब तक executor यह साबित न कर दे कि target तक पहुंचा या नहीं। यह असुविधाजनक है। Destructive work का duplicate होना इससे भी खराब है।

Deploy approvals को artifact का पीछा करना चाहिए

जब artifact, destination, release plan या queue में उसका order बदलता है, deployment request stale हो जाती है। Branch names और moving tags पर्याप्त नहीं हैं।

Deploy prompt में immutable artifact की पहचान होनी चाहिए। यह image digest, signed release bundle hash या immutable build record हो सकता है। Reviewer को यह भी पता होना चाहिए कि executor database migrations चलाएगा, feature configuration बदलेगा, instances restart करेगा या पिछला deployment replace करेगा। ये details approval को प्रभावित करती हैं। उन्हें generic «deploy» button के पीछे छिपाने से लोग बिना सोचे approval देने लगते हैं।

एक मजबूत deploy approval contract में शामिल होते हैं:

• Immutable build identifier और source revision।
• Exact target environment और account या cluster identity।
• Release operation, जैसे promote, rollback या redeploy।
• लागू होने वाली configuration और migration revisions।
• Concurrency token या deployment generation।

Concurrency token तब महत्वपूर्ण होता है जब बाद का change पहले वाले request को supersede कर देता है। मान लें build A approval का इंतजार कर रहा है। Build B पूरा होकर checks पास कर लेता है और अब वही release बन जाता है जिसे आप भेजना चाहते हैं। अगर build A का request valid रहता है, तो reviewer गलती से पुराना build release कर सकता है। जब build B उसी release lane में आए, तो build A की pending approval invalidate करें। व्यस्त queue में reviewers timestamps देख लेंगे, इस पर निर्भर न रहें।

GitHub का deployment documentation environment protection को workflow concurrency से अलग रखता है। उसके concurrency controls किसी group में pending work cancel कर सकते हैं, जबकि environment approval यह नियंत्रित करती है कि job आगे बढ़ सकती है या नहीं। यह विभाजन उपयोगी है: queue policy तय कर सकती है कि current run कौन सा है, और approval gate तय कर सकती है कि वही exact current run चल सकती है या नहीं। इन्हें लापरवाही से मिलाने पर वही आम failure होता है, जिसमें सही व्यक्ति गलत run approve कर देता है।

Deploy से पहले executor को दोबारा जांच करनी चाहिए। Practical preflight में यह verify किया जा सकता है कि requested artifact अब भी मौजूद है, environment अब भी expected target identity पर map होता है, कोई newer release lane को hold नहीं कर रहा और migration plan approved digest से मेल खाता है। कोई भी check fail हो, तो request को invalidated mark करें और reviewer को fresh request दिखाएं। Build A approve हुआ था, इसलिए build B को चुपचाप substitute न करें। वह अलग action है।

एक लोकप्रिय लेकिन कमजोर pattern से बचें: pull request approve करके उसे production authorization मान लेना। Code review यह तय करता है कि proposed change codebase में होना चाहिए या नहीं। यह तय नहीं करता कि current incident, current migrations और current target state के बीच यह build अभी production में चलना चाहिए या नहीं। इन decisions को अलग रखें।

Delete prompts को frozen object set चाहिए

Deletion approvals तब खतरनाक हो जाती हैं जब request में resolved objects के बजाय query दी जाती है। «30 दिनों से पुराने backups हटाएं» हर मिनट अलग set का अर्थ हो सकता है।

Request बनाते समय query को object identifiers में resolve करें और snapshot marker record करें। Approval screen पर count, कुछ representative identifiers, retention basis और exact deletion mode दिखना चाहिए। Executor को approval के बाद broad query दोबारा नहीं चलानी चाहिए, बल्कि उसी frozen set का इस्तेमाल करना चाहिए।

अगर set बहुत बड़ा है और पूरा दिखाना संभव नहीं, तो reviewer को stable manifest identifier और संक्षिप्त breakdown दें। Prompt को केवल «8,421 items हटाएं» तक सीमित न करें। Count यह नहीं बता सकता कि list में गलत tenant, current backups या unexpected prefix शामिल है या नहीं।

इस request पर विचार करें:

{
  "action_type": "delete_objects",
  "scope": "archive/preview/",
  "selection": {
    "manifest_digest": "sha256:19e7...",
    "object_count": 184,
    "newest_object_at": "2026-06-19T03:11:00Z",
    "oldest_object_at": "2025-11-02T18:24:00Z"
  },
  "mode": "permanent",
  "expires_at": "2026-07-22T14:08:00Z"
}

Execution के समय पुष्टि करें कि manifest अब भी मौजूद है और हर object identifier अब भी expected version पर resolve होता है। अगर storage system versioning support करता है, तो deletion को names के बजाय versions से बांधें। Names दोबारा इस्तेमाल हो सकते हैं। Approval के बाद उसी path पर लिखा गया नया object पुराने object की death sentence inherit नहीं करना चाहिए।

जब request age या live inventory पर आधारित हो, तब छोटी deadline खास तौर पर जरूरी है। Request जितनी देर इंतजार करेगी, उतनी संभावना बढ़ेगी कि नया eligible object, restored item या reclassified record intended set बदल दे। अगर system set को freeze नहीं कर सकता, तो एक approval को broad deletion query authorize करने की अनुमति नहीं देनी चाहिए। इसके बजाय narrow और recent request मांगें।

Soft deletion और permanent deletion के लिए अलग prompts और अलग expiry windows रखें। Soft deletion reversible हो सकती है, लेकिन reversibility को vague approvals का बहाना न बनाएं। Recovery अक्सर धीमी, अधूरी या उन permissions पर निर्भर होती है जिन्हें deletion मांगने वाला व्यक्ति नियंत्रित नहीं करता।

SSH approvals लोगों की सोच से ज्यादा जल्दी stale होती हैं

SSH stale context के प्रति खास तौर पर संवेदनशील है, क्योंकि names, sessions, environment variables और working trees उसी command text के नीचे बदल सकते हैं।

systemctl restart api तब तक specific लगता है, जब तक आप यह न पूछें कि command किस machine पर जाएगी, वहां api किस ओर point करता है, कौन सा deployment सक्रिय है और क्या बाद के incident ने restart करने की वजह बदल दी है। अगर alias, mount या shell expansion बदल जाए, तो rm -rf /srv/tmp/job-123 एक host पर सुरक्षित और दूसरे पर विनाशकारी हो सकती है।

SSH action के लिए terminal transcript नहीं, structured command request approve करें। Request में host की verified identity, target user, fixed command template, पूरी तरह expanded allowed arguments, declared working directory और expected input digest शामिल होना चाहिए। अगर agent को shell चाहिए, तो open interactive session authorize करने के बजाय shell command को explicit payload तक सीमित करें।

एक उचित approval card कुछ ऐसी हो सकती है:

Host: prod-api-03, host key SHA256:K4f...
User: deploy
Command: /usr/local/bin/release-health --release 2026.07.22.4 --repair-cache
Directory: /srv/api
Effect: writes cache state, may restart one service
Expires: 14:08 UTC

यह अब भी इस बात का प्रमाण नहीं है कि command सुरक्षित है। लेकिन इंसान यह पहचान सकता है कि वह किस चीज को authorize कर रहा है। Executor फिर reconnect करके host identity की दोबारा पुष्टि करता है, command digest check करता है और deadline से पहले उसे चलाता है।

prod-api पर command की approval को DNS, inventory या bastion mapping के कारण बाद में किसी दूसरे host पर execution की अनुमति न बनने दें। Connection setup जहां अनुमति दे, वहां host की cryptographic identity से bind करें। Approval के इंतजार के दौरान legitimate host-key rotation हो, तो request invalidate करें। Maintenance के समय यह शोर जैसा लग सकता है, लेकिन एक machine के लिए approve की गई command को दूसरी machine पर भेजने से यह बेहतर है।

Read-only commands की अपनी category होनी चाहिए। Teams अक्सर हर SSH call पर approval इसलिए लगाती हैं क्योंकि उनके पास एक ही control होता है और वे उसे हर जगह लागू कर देती हैं। परिणाम approval fatigue होता है, फिर reviewers ऐसी commands पर click कर देते हैं जिन्हें वे पढ़ नहीं पाते। Harmless inspections को उन actions से अलग करें जो write, restart, access बदलती हैं या sensitive output उजागर करती हैं। जहां command के effects इसकी मांग करें, वहां per-call approval रखें और prompt को इतना छोटा रखें कि उसे पढ़ा जा सके।

Approval screen को बदलाव साफ दिखाना चाहिए

अगर reviewer को केवल agent का लिखा हुआ एक sentence दिखे, तो precise backend contract बेकार हो जाता है। Screen पर वे fields दिखनी चाहिए जो answer बदल सकती हैं।

Effect से शुरुआत करें: इस digest को इस environment में deploy करें; इस fixed manifest को permanently delete करें; इस verified host पर यह command चलाएं। Deadline ऐसी जगह रखें कि approve करने से पहले reviewer की नजर उस पर पड़े और समय unambiguous timezone में दिखाएं। Countdown केवल सुविधा है। Validity का फैसला executor का server-side timestamp करता है।

Request बदलने पर पुराने contents को उसी जगह replace करके approval button enabled न छोड़ें। उसे invalidated mark करें। Visible explanation के साथ नया request बनाएं, जैसे «artifact बदला» या «target inventory बदली»। जिस reviewer ने पिछला version approve किया था, उसे fresh decision लेना चाहिए। यही extra click इस control का उद्देश्य है।

NIST SP 800-63B-4 authentication intent को user intervention के रूप में बताता है, जो यह पुष्टि करता है कि claimant authenticate या reauthenticate करना चाहता है। Action approval में भी यही discipline चाहिए, लेकिन अधिक सीमित रूप में। Finger press या confirmation click displayed operation के लिए intent व्यक्त करे, agent को सामान्य रूप से आगे बढ़ने की अनुमति नहीं।

Prompts को time pressure का छल न बनने दें। Complex deletion के लिए दो मिनट की window reviewer को blind approval और expiry के बीच चुनने पर मजबूर करती है। Reviewer तक पहुंचने से पहले request inspection के लिए तैयार होनी चाहिए। Reviewer को पर्याप्त context मिलने के बाद छोटी execution deadline दें, ऐसी rushed decision deadline नहीं जो ध्यान से पढ़ने पर दंड दे।

Comment field तब उपयोगी हो सकती है जब reviewer को बताना हो कि कोई unusual action क्यों स्वीकार्य है। Ordinary work के लिए comment अनिवार्य न करें। Mandatory boilerplate ऐसा text बनाता है जिसे कोई नहीं पढ़ता। Overrides, exceptional expiry extensions या तय blast radius से बड़ी actions के लिए comment जरूरी करें।

Enforcement की जिम्मेदारी executor की है

जिस system के पास action करने का अधिकार है, उसे expiry, binding और one-time consumption लागू करना चाहिए। Workflow UI, chat bot या agent framework approval मांग सकता है, लेकिन अगर कोई दूसरा component उसे bypass कर सकता है, तो वही अंतिम निर्णायक नहीं हो सकता।

इसीलिए action gateway एक उपयोगी boundary है। Agent HTTP call या SSH command propose करता है। Gateway देखता है कि request की current approval है या नहीं, जरूरत होने पर credential inject करता है, operation करता है और result लौटाता है। Agent को ऐसा reusable credential कभी नहीं मिलना चाहिए जिससे वह बाद में approval path bypass कर सके।

Sallyport HTTP APIs और SSH के लिए इसी तरह काम करता है: agent अपने MCP shim के जरिए connect करता है, credentials app के encrypted vault में रहते हैं और app action करता है, secrets agent को नहीं देता। इसके per-call keys उन actions के लिए fresh confirmation मांगने की स्वाभाविक जगह हैं जिनका context जल्दी बदलता है। फिर भी timeout और action-binding logic request path में स्पष्ट होना चाहिए। इन checks के बिना confirmation भी उसी समस्या में stale हो सकती है।

Approval state executor के पास रखें या उसे executor के लिए cryptographically verifiable बनाएं। Signed approval token काम कर सकता है, अगर उसमें request identifier, action digest, issue time, expiry, reviewer identity और nonce शामिल हों। Executor को फिर भी revocation check करनी होगी और nonce को एक बार consume करना होगा। Request invalidate होने के बाद भी valid रहने वाला signed token बस अच्छी तरह signed stale approval है।

Clocks को सावधानी से संभालें। Expiry decisions के लिए trusted service clock इस्तेमाल करें, timestamps UTC में रखें और expiry instant पर या उसके बाद approvals reject करें। Agent की local clock और browser countdown केवल display aids हैं। वे authorization inputs नहीं हैं।

Logs को समझाना चाहिए कि execution क्यों हुआ या नहीं हुआ

Approval expire होने पर teams को «denied» से ज्यादा जानकारी चाहिए। उन्हें जानना होता है कि reviewer ने जवाब नहीं दिया, approval के बाद request बदला, executor को failed precondition मिला या किसी दूसरे worker ने approval पहले ही consume कर ली।

Immutable event trail लिखें, जो proposal, displayed summary, approval decision, invalidation या expiry, preflight checks, execution attempt और result को जोड़े। हर event में action digest रखें। Request दोबारा बनाई गई हो, तो replacement request identifier record करें, लेकिन यह संकेत न दें कि पिछली approval आगे चली गई।

एक उपयोगी event shape ऐसी हो सकती है:

{
  "event": "approval.invalidated",
  "request_id": "appr_01JX...",
  "action_digest": "sha256:8b1d...",
  "reason": "release_lane_superseded",
  "replaced_by": "appr_01JY...",
  "recorded_at": "2026-07-22T14:06:22Z"
}

Expired approvals को consume करने की कोशिशें भी record करें। इससे ऐसे agents का पता चलता है जो blind retry करते हैं, गलत clocks वाले workers और वे UI paths जो refresh नहीं हुए। इससे incident reviewer expired request और production तक पहुंची action के बीच फर्क कर सकता है।

Sallyport का Sessions journal और Activity journal encrypted, hash-chained audit log से project होते हैं। sp audit verify command ciphertext पर offline उस chain की जांच करती है। ऐसा trail तभी उपयोगी है जब event vocabulary ईमानदार हो। केवल सफल calls ही नहीं, expiry, invalidation और failed preflight events भी शामिल करें, ताकि dashboard साफ दिखाने के लिए महत्वपूर्ण failures छिप न जाएं।

Auditability को prevention न समझें। New state पर चल गई पुरानी approval का perfect record failure का evidence है। Prevention check executor के request भेजने या SSH channel खोलने से पहले चलना चाहिए।

Expired requests को दोबारा बनाना आसान रखें

Short windows तभी काम करती हैं जब नया request बनाना पुराने request से बहस करने से आसान हो। अगर regeneration के लिए ticket number फिर से भरना, command हाथ से दोबारा बनाना और तीन लोगों को ढूंढना पड़े, तो teams हर timeout को इतना बढ़ाने का दबाव डालेंगी कि उसका अर्थ ही खत्म हो जाए।

Agent को fresh state से resubmit करने में सक्षम होना चाहिए, लेकिन उसे नए facts साफ दिखाने होंगे। अगर केवल expiry बदली है और सभी bound fields वही हैं, तो नया request वही human-readable summary रख सकता है, लेकिन उसे नया identifier और deadline मिलनी चाहिए। अगर कोई action field या live precondition बदली है, तो बताएं कि क्या बदला। Reviewer से opaque hashes की तुलना न करवाएं।

Expiry extension को exception रखें। अगर ऐसा विकल्प देते हैं, तो executor से सभी preflight checks फिर चलवाएं और reviewer को current summary दोबारा दिखाएं। «30 मिनट बढ़ाएं» वाला button, जो पुराने token को renew कर देता है, बेहतर typography वाला approval bypass है।

चार चीजों को मापने से शुरुआत करें: approvals कितनी बार expire होती हैं, approved actions execution से पहले कितनी बार invalidated होती हैं, requests कितनी देर wait करती हैं और कौन से action types repeated retries पैदा करते हैं। इन परिणामों से पता चलेगा कि deadline बहुत छोटी है, queue धीमी है या agent stable inputs मिलने से पहले requests बना रहा है।

Stale approval को शांत और स्पष्ट तरीके से fail होना चाहिए: executor उसे reject करे, log कारण बताए और अगर काम अब भी उचित हो तो agent current decision मांगे। यही छोटी-सी refusal human control को उस action से जोड़े रखती है जो वास्तव में होने वाली है।