Agent approval prompts cross-run approval को कैसे रोकते हैं

Autonomous agents के लिए approval queue permission buttons का ढेर नहीं होती। यह attribution की एक live व्यवस्था है। जब दो या अधिक agent runs एक ही credential मांग सकते हों, एक ही API call कर सकते हों या एक ही SSH connection खोल सकते हों, तो approval देने से पहले reviewer को एक संकीर्ण सवाल का जवाब दे पाना चाहिए: कौन-सा running process मुझसे इस exact action को authorize करने के लिए कह रहा है?

अधिकांश approval interfaces इसलिए विफल होते हैं क्योंकि हर card ऐसे दिखता है जैसे वह “the agent” नाम के किसी generic actor से आया हो। एक terminal window वाले demo में यह label harmless लगता है। लेकिन स्थिति खतरनाक हो जाती है जब एक coding agent production incident ठीक कर रहा हो और दूसरा release तैयार कर रहा हो, दोनों एक ही client इस्तेमाल कर रहे हों और दोनों उसी service तक access मांग रहे हों। Reviewer को परिचित destination दिखाई देता है, वह broad task को पहचान लेता है और गलत run के लिए सही action approve कर देता है।

Approval attribution का फैसला है

Reviewer किसी HTTP request को अकेले approve नहीं करता। वह request को इसलिए approve करता है क्योंकि वह उसके अनुसार चल रहे किसी खास काम से जुड़ी है। अगर interface यह संबंध कायम नहीं रख सकता, तो approval button human control का रूप लिया हुआ अनुमान बन जाता है।

हर approval को पांच हिस्सों वाले statement की तरह देखें:

1. किसी खास executable या agent process ने इसे शुरू किया।
2. उस process का एक खास session अभी active है।
3. वह session किसी नामित task या work item से जुड़ा है।
4. वह एक concrete external action करना चाहता है।
5. Reviewer उस पूरे tuple को authorize या decline करता है।

पांचवां बिंदु जितना लगता है उससे अधिक महत्वपूर्ण है। “Deployment API तक access approve करें” पूरा statement नहीं है। Reviewer release run को build record पढ़ने देना चाहता हो सकता है, लेकिन किसी unrelated debugging run को release setting बदलने की अनुमति न देना चाहे। केवल destination अर्थ नहीं बता सकता।

यह फर्क इसलिए धुंधला हो जाता है क्योंकि अक्सर वही agent client दोनों runs बनाता है। Command line एक जैसी हो सकती है। Code-signing authority एक जैसी हो सकती है। Repository path भी एक जैसा हो सकता है। Agent लगभग एक जैसी requests भी बना सकता है। फिर भी दो simultaneous invocations एक ही security subject नहीं बन जाते।

मैंने teams को action summary में अधिक शब्द जोड़ते देखा है, जबकि असली कमी attribution की थी। वे “POST /deployments” को बदलकर “POST /deployments to trigger staging deployment for version 1.8.4” कर देते हैं। इससे operation समझने में मदद मिलती है, लेकिन reviewer के सामने फिर भी दो cards होते हैं, जो दोनों staging deployment का दावा करते हैं। बेहतर sentence missing session boundary को ठीक नहीं कर सकता।

Approval interface को identity hierarchy साफ दिखानी चाहिए। Action मुख्य object है। Initiating process और active session बताते हैं कि वह action क्यों दिखाई दिया। Task label reviewer को intent पहचानने में मदद करता है, लेकिन यह technical identifier की जगह नहीं लेता।

Signed process और running session अलग हैं

Code-signing identity system को बता सकती है कि code पर किसने sign किया, लेकिन यह नहीं बता सकती कि उस code के किस invocation ने pending request बनाई। Apple की code-signing documentation भी अलग भाषा में यही सीमा बताती है: code requirements code identity स्थापित करती हैं, जबकि designated requirement बताती है कि versions के बीच किस code को वही code माना जाए। यह caller के बारे में उपयोगी evidence है, run identifier का विकल्प नहीं।

यह तब महत्वपूर्ण होता है जब approval prompt की शुरुआत कुछ इस तरह हो:

Request from: Acme Agent CLI
Signed by: Example Engineering, Team ABCD1234

यह एक अच्छी शुरुआत है। Reviewer देख सकता है कि expected client ने access मांगा है या नहीं। लेकिन इससे यह पता नहीं चलता कि यह पांच मिनट पहले शुरू किया गया release assistant है, सुबह से खुला test assistant है या दूसरे terminal में चल रही copied shell command।

Process identity और session identity अलग सवालों के जवाब देते हैं:

सिर्फ चौथी row जोड़ने के कारण पहली दो rows न छिपाएं। Reviewer को unexpected client पहचानने के लिए process authority चाहिए। Concurrent expected clients को अलग करने के लिए session ID चाहिए। Technical identifier को काम की mental model से जोड़ने के लिए task label चाहिए।

व्यावहारिक नियम सरल है: process identity को provenance की तरह दिखाएं और session identity को authorized unit की तरह।

macOS पर केवल code-signing identifier approval label के रूप में खास तौर पर कमजोर है। Apple स्पष्ट रूप से बताता है कि कई signers एक ही signing identifier का दावा कर सकते हैं और identifier check को validation category तथा non-Apple code के लिए team identifier के साथ जोड़ने की सलाह देता है। केवल friendly bundle name या केवल claimed identifier दिखाने वाला card reviewer को platform द्वारा उपलब्ध evidence से भी कम जानकारी देता है।

Raw requirement language को मुख्य label न बनाएं। वह precise है, लेकिन अधिकांश reviewers उसे जल्दी पढ़कर निर्णय नहीं ले सकते। Signing authority को सरल भाषा में दिखाएं, technical requirement को details में उपलब्ध रखें और recognizable executable name से जोड़ें। फिर session identifier को ऐसी जगह रखें जहां बिना कुछ expand किए नजर पड़ जाए।

हर run को ऐसी session identity दें जो queue में बनी रहे

Session ID पहली protected call से पहले बननी चाहिए, पूरे run में स्थिर रहनी चाहिए और run समाप्त होने पर authorization set से हट जानी चाहिए। इससे कमजोर कोई भी व्यवस्था load के दौरान ambiguity पैदा करेगी।

Connection या process registration के समय high-entropy opaque ID बनाएं। Full value audit record में रखें, लेकिन prompt में छोटा, स्पष्ट prefix दिखाएं। Display form इतना लंबा हो कि दो active sessions के समान होने की संभावना बहुत कम रहे, और collision होने पर UI उसे साफ तौर पर दिखाए। ID को current time, queue position, repository name या अकेले process ID से न बनाएं।

एक उपयोगी internal record ऐसा हो सकता है:

{
  "session_id": "ses_7TQ4N8M2KDXP6R9V",
  "display_id": "7TQ4N8M2",
  "process": {
    "pid": 84172,
    "executable": "/usr/local/bin/agent-cli",
    "signing_authority": "Example Engineering (Team ABCD1234)"
  },
  "task": {
    "label": "Prepare the staging release notes",
    "workspace": "/Users/maya/work/app"
  },
  "started_at": "2026-07-22T16:42:11Z"
}

Task label किसी human-visible instruction या जानबूझकर चुने गए session title से आना चाहिए, न कि model-generated sentence से जो हर tool call के साथ बदलता रहे। Model label सुझा सकता है, लेकिन session शुरू होते ही system को उसे freeze कर देना चाहिए। यदि session “prepare release notes” से “rotate the production webhook credential” पर जाता है, तो reviewer को स्पष्ट task change या नया session मिलना चाहिए। Label को चुपचाप बदलने से history समझना कठिन होता है और run को पहले के सुरक्षित task की legitimacy उधार लेने का मौका मिलता है।

Lifecycle में स्पष्ट सीमाएं रखें:

• किसी भी credentialed action से पहले session बनाएं।
• हर request, approval, denial, cancellation और result को उसी session से जोड़ें।
• Initiating process exit करे या valid connection खो दे तो session बंद करें।
• Reviewer revoke चुने तो session तुरंत revoke करें।
• Close या revoke के बाद pending approvals अस्वीकार करें, भले ही card कुछ क्षण दिखाई देता रहे।

आखिरी बिंदु एक सूक्ष्म लेकिन आम race रोकता है। Reviewer को run A का card दिखता है। Run A exit हो जाता है। नया run B शुरू होता है और समान action मांगता है, जबकि पुराना card अभी input स्वीकार कर रहा है। यदि approval service उस click को “इस credential के लिए latest request” से जोड़ती है, तो reviewer A को देखते हुए B approve कर देता है। Card को एक immutable request ID और एक session ID से बांधें। इनमें से कोई invalid हो जाए तो सुरक्षित button केवल dismiss होना चाहिए।

“Session 1”, “Agent run” या “Current task” जैसे labels से बचें। दूसरा run शुरू होने तक वे ठीक लगते हैं। Label friendly हो सकता है, लेकिन interface को ऐसी identifier चाहिए जो process restart, laptop sleep या कई दिन बाद होने वाली incident review के बाद भी अर्थपूर्ण रहे।

पहली दो lines में सही facts रखें

Approval prompt की पहली दो lines reviewer को details खोले बिना इस request को हर दूसरी pending request से अलग पहचानने दें। पहले requested action रखें, फिर सीधे नीचे initiating process और session बताएं।

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

Allow POST to api.example.internal/v1/releases?
agent-cli, signed by Example Engineering, session 7TQ4N8M2
Task: Prepare the staging release notes

Creates a release record named "2026.07.22-rc3"
Credential: release-service-write
[Review request]                         [Deny] [Allow]

Action line बताती है कि क्या होगा और कहां। Attribution line बताती है कि किसने request की। Task line बताती है कि reviewer को request को किस काम से जोड़ना चाहिए। Preview शुरुआती निर्णय के लिए पर्याप्त consequence देती है। यह क्रम जानबूझकर रखा गया है।

“Approval requested” या “Agent wants to use a secret” से शुरुआत न करें। इनमें से कोई phrase busy queue को sort करने में मदद नहीं करता। Credential name से भी शुरुआत न करें। Credentials implementation details हैं। Reviewer आम तौर पर यह जानता है कि request सही release run की है या नहीं, इससे पहले कि वह तय करे कि release-service-write सही stored key है या नहीं।

SSH के लिए equivalent prompt में केवल “SSH access” न लिखें, remote host और command class का नाम दें। उदाहरण:

Allow SSH command on build-staging-03.example.internal?
agent-cli, signed by Example Engineering, session 7TQ4N8M2
Task: Verify the staging migration

Runs: /usr/local/bin/check-migration --database app_staging
Credential: deploy-ssh
[Review command]                         [Deny] [Allow]

यदि system सुरक्षित और readable preview नहीं बना सकता, तो यह बात साफ कहे। “Command arguments unavailable” कहना उस friendly sentence को गढ़ने से बेहतर है जो shell expansion, indirect script या uninspected input छिपा दे। Reviewer exact command खोल सकता है या request deny कर सकता है।

अच्छा prompt reviewer से timestamp देखकर initiating run का अनुमान लगाने को नहीं कहता। Time details और activity record में होना चाहिए। दो agents एक ही second में requests भेज सकते हैं और लोग timestamp से card को terminal से reliably match नहीं कर पाते। Time supporting evidence हो, attribution उठाने वाला label नहीं।

Session ID को faint footer में भी न छिपाएं। Identifier diagnostic debris नहीं है। Parallel queue में यही field reviewer को लगभग समान दो cards को interchangeable मानने से रोकती है।

Queue को false merging के बिना grouping चाहिए

Parallel work visual sorting की समस्या पैदा करता है। Cards को session के अनुसार group करना मदद कर सकता है, लेकिन जब UI requests के महत्वपूर्ण फर्क को collapse कर दे तो grouping खतरनाक हो जाती है।

Reviewer को एक session की सभी pending actions साथ देखने दें, लेकिन अलग प्रभाव वाली actions के लिए एक-एक approval decision बनाए रखें। Release assistant की तीन read-only API calls compact group में दिखाई जा सकती हैं। लेकिन issue पढ़ने, deployment record लिखने और remote migration चलाने वाला session तीन अलग decisions दिखाए, क्योंकि उनके consequences अलग हैं।

गलत pattern ऐसा global banner है:

agent-cli requests access to 5 services
[Allow all]

यह button reviewer से हर item को run से जोड़ने या effects देखने से पहले collection approve करने को कहता है। यह queue fatigue को भी बढ़ाता है। Reviewer जितनी बार banner देखेगा, उतनी ही संभावना होगी कि वह काम पर लौटने के लिए उसे साफ करने की आदत बना ले।

बेहतर queue session headers को context की तरह इस्तेमाल करती है, broad authorization की तरह नहीं:

Session 7TQ4N8M2 · agent-cli · Prepare the staging release notes
2 pending requests

  GET api.example.internal/v1/builds/rc3             [Allow]
  POST api.example.internal/v1/releases              [Review]

Session C5J1W6PA · agent-cli · Investigate test failure #1842
1 pending request

  SSH build-staging-03.example.internal              [Review]

Reviewer run के अनुसार जल्दी scan कर सकता है, लेकिन हर row अलग claim रखती है। यदि system per-session authorization state देता है, तो header में scope साफ लिखें: “यह session इसके exit होने तक authorized है।” इस state को हर per-call action की approval जैसा न दिखाएं। Per-session authorization run को actions मांगने की अनुमति देती है, unexpected actions को expected नहीं बनाती।

Ordering errors को भी प्रभावित करती है। पूरी तरह chronological queue पांच runs की requests को इस तरह मिला सकती है कि reviewer किसी एक run का context बनाए न रख सके। पूरी तरह session-grouped queue किसी noisy session के पीछे urgent request छिपा सकती है। Reviewer को दोनों views दें: attribution के लिए default grouped view और incident response के लिए time-sorted view। दोनों में session badge दिखता रहे।

सिर्फ destination और credential समान होने के कारण cards merge न करें। एक ही endpoint पर लिखने वाले दो अलग runs वही ambiguity पैदा करते हैं जिसे queue को हल करना है। Similarity run identity को अधिक prominent बनाने का कारण है, approvals को मिलाने का नहीं।

Approval उसी exact request से बंधा होना चाहिए जिसे reviewer ने देखा

सही run की पहचान करने वाला prompt भी गलत request authorize कर सकता है, यदि approval immutable action के बजाय mutable template पर लागू हो। Reviewer को specific request representation approve करनी चाहिए, ऐसी future request नहीं जो वही route, command या credential दोबारा इस्तेमाल करे।

Card दिखने से पहले canonical action record बनाएं। HTTP के लिए कम से कम method, normalized origin और path, नाम से चुने गए headers, credential alias और body का digest शामिल करें। SSH के लिए normalized host identity, requested account, port, command bytes और credential alias शामिल करें। Full protected material trusted component के अंदर रखें। केवल इसलिए agent को वह न दें कि reviewer को prompt दिखाना है।

फिर approval को canonical record से बांधें:

{
  "approval_id": "apr_K9H2D7LQ",
  "session_id": "ses_7TQ4N8M2KDXP6R9V",
  "action_digest": "sha256:2a13c4e0...",
  "expires_at": "2026-07-22T16:47:11Z",
  "decision": "allow_once"
}

Execution के समय उस action से digest फिर बनाएं जो वास्तव में machine से बाहर जाएगा। यदि वह अलग है, तो approval अस्वीकार करें और नया card बनाएं। बदली हुई request को चुपचाप “close enough” न मानें। बदला URL parameter payment को redirect कर सकता है, बदला header account scope बदल सकता है और बदला shell argument inspection command को write में बदल सकता है।

यहीं कई अच्छी सोच वाले systems विफल होते हैं। वे reviewable summary दिखाते हैं, “credential X को endpoint Y के लिए इस्तेमाल करें” approve करते हैं और फिर agent को उसी broad grant के अंतर्गत दूसरी request करने देते हैं। Reviewer ने दूसरी request review नहीं की। System ने एक explicit decision को invisible policy rule में बदल दिया।

Pending approval के लिए छोटा expiry रखें। उद्देश्य coffee break लेने वाले reviewer को दंड देना नहीं है, बल्कि context बदलने के बाद पुराने decision के लागू होने से रोकना है। Agent को बाद में भी action चाहिए तो उसी process और session details के साथ fresh request कर सकता है। Reviewer देख सकेगा कि वह अभी भी उसी काम से जुड़ी है या नहीं।

Automated decisions में human involvement पर NIST material automation bias और उन low-friction approval loops की चेतावनी देता है जो alert fatigue को सामान्य बनाते हैं। व्यावहारिक निष्कर्ष सीधा है: approval पर click करना आसान बनाने से वह meaningful नहीं हो जाता। Interface को decision इतना छोटा बनाना चाहिए कि उसे inspect किया जा सके और इतना specific कि उसकी जवाबदेही तय हो।

Detail view को विवाद सुलझाना चाहिए, पैदा नहीं करना चाहिए

Compact approval card request का हर byte नहीं दिखा सकता। फिर भी उसमें ऐसा detail view होना चाहिए जो unfamiliar, costly या suspicious action के समय careful reviewer के सवालों का जवाब दे।

HTTP action के लिए complete method और URL, default रूप से redacted headers, secrets के स्पष्ट treatment के साथ body fields, credential alias, initiating process identity, session ID, task label और request creation time दिखाएं। Body binary या बहुत बड़ी हो तो उसका size, content type और digest दिखाएं। एक-line prose summary को पर्याप्त विकल्प न मानें।

SSH के लिए host, user, port, जहां उपलब्ध हो वहां host verification state, exact command, relevant working directory और behavior को प्रभावित करने वाले environment values दिखाएं। Command preview में quoting और argument boundaries जस की तस रहें। Array को loosely joined shell string में दिखाने से safe command unsafe या unsafe command harmless लग सकती है।

Safety के लिए redaction और convenience के लिए omission अलग बातें हैं। Bearer token, private key, password या sensitive body value को prompt से redact करें। Path, target account, remote host, command या changed field को केवल card लंबा होने के कारण न छिपाएं। अक्सर यही facts बताते हैं कि request इस run की है या नहीं।

Detail view में stable request fingerprint रखें। Reviewer teammate को message करके कह सके, “मैंने session 7TQ4N8M2 की request apr_K9H2D7LQ deny की,” और teammate को ठीक एक record मिले। लोगों को “लगभग 4:40 का दूसरा deployment prompt” कहने पर निर्भर न करें। Incident में precision चाहिए होती है।

Review surface पर यह भी साफ लिखें कि approval किसे authorize करेगा और किसे नहीं। उदाहरण:

Allow once
This decision authorizes only this POST request with digest 2a13c4e0…
It does not authorize later calls from session 7TQ4N8M2.

यह sentence अपनी जगह के लायक है। इससे reviewer broad grant मानने से बचता है और implementer उसी button label के पीछे scope बढ़ाने से।

Cancellation और revocation के परिणाम साफ दिखने चाहिए

कभी reviewer गलत card approve करेगा या देखेगा कि run गलत दिशा में जा रहा है। Recovery तेज, स्पष्ट और approval में इस्तेमाल हुई उन्हीं identifiers से जुड़ी होनी चाहिए।

UI में एक request deny करने और एक session revoke करने के लिए अलग actions रखें। Deny का अर्थ है “यह action न करें।” Revoke का अर्थ है “इस running process का authorization समाप्त हो गया, इसकी pending approvals cancel करें और आगे की actions deny करें।” इनके परिणाम अलग हैं, इसलिए दोनों को अस्पष्ट “Stop” button में न मिलाएं।

Reviewer session revoke करे तो confirmation में process, session ID और task का नाम हो:

Revoke session 7TQ4N8M2?
agent-cli is running “Prepare the staging release notes.”
Pending requests from this session will be cancelled. New protected actions
from this process will be denied until it starts a new session.
[Keep session] [Revoke session]

यदि request पहले से execute हो रही है, तो इसे ईमानदारी से बताएं। Revocation future privileged actions रोक सकती है, लेकिन remote service द्वारा स्वीकार की जा चुकी HTTP request को undo या शुरू हो चुकी remote command को halt नहीं कर सकती। Activity record में दिखना चाहिए कि action pending, sent, completed, failed या cancelled थी। “Revoked” ऐसे न लिखें कि external effect गायब होने का अर्थ निकले।

हर card में session ID दिखाने का यह भी कारण है। तनावपूर्ण incident में reviewer को suspicious prompt से उस control तक सीधा रास्ता चाहिए जो उस run को रोकता है। Queue में केवल “agent-cli” हो तो revocation उपयोगी run को बंद करके खराब run को active छोड़ सकती है।

Session journal और activity journal में identifiers एक जैसी होनी चाहिए। एक record बताएगा कि process session 7TQ4N8M2 शुरू हुआ, authorization मिला और revoke हुआ। दूसरा बताएगा कि हर state change से पहले और बाद में उसने कौन-सी individual action करने की कोशिश की। यदि दोनों records अलग labels इस्तेमाल करें, तो responders उन joins को दोबारा बनाने में समय गंवाएंगे जिन्हें product को स्पष्ट करना चाहिए था।

Users से पहले wrong-run approval का परीक्षण करें

इस failure को red team या production outage के बिना test किया जा सकता है। एक ही agent client के दो instances को एक ही workspace पर चलाएं और उनसे समान protected calls करवाएं। Test तभी सफल है जब reviewer busy queue देखते हुए हर request सही पहचान सके।

यह exercise करें:

1. Run A शुरू करें और task label रखें “Inspect failed staging build.”
2. Run B शुरू करें और task label रखें “Publish staging release record.”
3. दोनों runs से कुछ seconds के भीतर वही credential मांगवाएं।
4. उनकी पहली requests समान रखें, जैसे उसी API origin पर दो calls।
5. एक action बदलें ताकि उसे दूसरे run के लिए approve करने पर test environment में साफ और अवांछित प्रभाव पड़े।

फिर ऐसे व्यक्ति से केवल run B की request approve करने को कहें जिसने UI नहीं बनाया। Queue position से यह न बताएं कि B कौन-सा card है। देखें कि वह किस चीज पर निर्भर करता है। यदि वह timestamps, card order या इस याद पर निर्भर करता है कि कौन-सा terminal पहले खोला था, तो interface विफल है। यदि वह अलग screen खोले बिना process authority, session ID, task, destination और action दिखा सके, तो आपके पास उपयोगी शुरुआती design है।

Stale approval behavior भी test करें। Run A का card बनाएं, run A समाप्त करें, run B शुरू करें और पुराने card पर click करें। System को click अस्वीकार करके बताना चाहिए कि request अब active नहीं है। Review के बाद request body या SSH argument बदलकर test दोहराएं। System को बदली action पर पुराने approval को लागू करने के बजाय नया approval मांगना चाहिए।

Colliding names भी test करें। दो tasks का नाम “Fix CI” हो सकता है। दो repositories की directory का नाम समान हो सकता है। दो branches एक ही release number साझा कर सकती हैं। Friendly text लोगों की मदद करता है, लेकिन पूरा design तब भी काम करना चाहिए जब friendly text ambiguous हो।

Sallyport का per-session authorization इस boundary को स्थापित करने की स्वाभाविक जगह देता है: नए agent process की पहली call approval के लिए उस run की पहचान करती है, जबकि per-call keys हर उपयोग के लिए अलग approval मांग सकती हैं। इन controls के सामने session label और process authority visible रखें, वरना parallel runs फिर एक अस्पष्ट “agent” में बदल जाएंगे।

Audit trail को approval decision दोहराने योग्य होना चाहिए

Audit trail तभी उपयोगी है जब वह बाद में बता सके कि reviewer ने क्या देखा और system ने क्या execute किया। “User approved API access” रिकॉर्ड करना पर्याप्त नहीं है। इससे मुख्य सवाल अनुत्तरित रहता है: किस run के लिए, किस action के लिए और किस displayed context के साथ access approve हुआ?

हर decision के लिए immutable identifiers और presentation facts रिकॉर्ड करें:

{
  "event": "approval_granted",
  "approval_id": "apr_K9H2D7LQ",
  "session_id": "ses_7TQ4N8M2KDXP6R9V",
  "process_identity": "agent-cli / Example Engineering (Team ABCD1234)",
  "task_label": "Prepare the staging release notes",
  "action_digest": "sha256:2a13c4e0...",
  "displayed_action": "POST api.example.internal/v1/releases",
  "decision_scope": "once",
  "recorded_at": "2026-07-22T16:44:03Z"
}

Canonical action record को उचित encryption और access controls के साथ अलग या इसी के साथ रखें। Audit event investigator को बताए कि card पर क्या लिखा था; canonical record साबित करे कि trusted component ने कौन-से bytes और destination इस्तेमाल किए। यदि दोनों अलग हों, तो इसे logging detail नहीं, security defect मानें।

Hash-chained log history के rewrite का पता लगाने में मदद करता है, लेकिन vague event content को ठीक नहीं करता। आप cryptographically साबित कर सकते हैं कि “approval granted” बदला नहीं गया, फिर भी यह न जान पाएं कि approval किस request को मिला। Integrity और attribution अलग समस्याएं हैं। दोनों चाहिए।

Sallyport एक encrypted, hash-chained audit log में session-level और individual-call records रखता है। उसका sp audit verify command ciphertext पर offline chain verify करता है। यह उपयोगी है क्योंकि reviewers stored secrets verification step के सामने लाए बिना यह evidence रख सकते हैं कि log rewrite नहीं हुआ।

अंतिम design test सरल है। किसी completed action को चुनकर पीछे की ओर जाएं: क्या investigator process, specific session, उस समय दिखाया गया task label, exact reviewed request, reviewer का decision scope और outcome पहचान सकता है? फिर किसी session से आगे की ओर आएं: क्या हर pending, denied, approved, cancelled और executed action क्रम में दिखाई देती है? यदि किसी दिशा में अनुमान लगाना पड़े, तो approval queue अभी भी wrong-run mistake को आमंत्रित कर रही है।

Parallel agents approval queues को सामान्य बना देंगे। समाधान reviewers को और cards के नीचे दबाना या एक broad “allow all” control देना नहीं है। हर running process को durable session identity दें, उसे action के पास वहीं रखें जहां लोग देखते हैं और हर click को उस request से बांधें जिसे reviewer ने inspect किया था। कई agents एक साथ active हों, तब approval को अर्थपूर्ण बनाने का यही तरीका है।