Authorization evidence: साबित करें कि AI agent की कार्रवाइयाँ पूरी हुईं

Approval record यह बताता है कि किसी व्यक्ति ने agent को कुछ करने की कोशिश की अनुमति दी। यह नहीं बताता कि request service तक पहुँची या नहीं, remote host ने command स्वीकार की या नहीं, अथवा अपेक्षित बदलाव हुआ या नहीं। Approval को completion का proof मानने से ऐसे audit trails बनते हैं जो incident reviewer के यह पूछने तक भरोसेमंद लगते हैं: «असल में हुआ क्या था?»

AI agents के मामले में यह अंतर और भी महत्वपूर्ण है, क्योंकि वे रोज़मर्रा के development task के दौरान कई वास्तविक कार्रवाइयाँ कर सकते हैं। कोई व्यक्ति agent process को एक बार मंज़ूरी दे सकता है, जिसके बाद process ticket बनाए, deployment setting बदले, production API से जानकारी ले या remote command चलाए। हर कार्रवाई के evidence का अर्थ अलग होता है। मानवीय निर्णय और उससे निकला outcome एक ही investigation का हिस्सा हैं, लेकिन वे एक-दूसरे की जगह नहीं ले सकते।

Approval permission दर्ज करता है, completion नहीं

Authorization evidence यह बताता है कि किसी पहचाने गए decision maker ने तय समय पर किसी परिभाषित कार्रवाई की अनुमति दी या नहीं। Execution evidence बताता है कि action gateway ने क्या करने की कोशिश की और target ने क्या जवाब दिया। केवल पहला उत्तर सुरक्षित रखने वाले audit design में बड़ी कमी रहती है।

मान लें कि agent को access token बनाने वाली API call की मंज़ूरी मिली। Gateway request भेजता है, लेकिन service उसे process करने के बाद और caller को response मिलने से पहले connection टूट जाता है। Approval अभी भी valid है। «approved» लिखे log से reviewer यह नहीं जान सकता कि token मौजूद है या नहीं। Gateway ने bytes भेजे, इसलिए «completed» लिखना और भी खराब है, क्योंकि इससे अनिश्चितता को झूठे तथ्य में बदल दिया जाता है।

SSH में भी यही गलती होती है। कोई व्यक्ति deploy.sh को मंज़ूरी देता है। SSH client authenticate करता है, remote shell शुरू होती है और script चलने के दौरान network connection टूट जाता है। क्या script पूरी हुई? क्या उसने system में कुछ बदलाव किए? Connection record इसका उत्तर नहीं दे सकता। आपको remote exit status चाहिए, अगर client को वह मिला हो, और अगर न मिला हो तो unknown outcome का स्पष्ट record चाहिए।

इन सवालों को अलग रखें:

• क्या किसी व्यक्ति या approved control ने इस agent process को authorize किया?
• Authorization में कौन-सी exact capability शामिल थी?
• क्या gateway ने action destination तक भेजा?
• Destination या transport ने कौन-सा result लौटाया?
• क्या बाद के reviewers यह जाँच सकते हैं कि किसी ने history में बदलाव नहीं किया?

कई teams इन पाँचों सवालों को agent_action नाम की एक event में समेट देती हैं। Dashboard के लिए यह सुविधाजनक है, लेकिन जब facts अलग-अलग हों, तो बेकार साबित होता है। संबंधित events को अलग-अलग store करें और interface में उन्हें साथ दिखाएँ।

NIST Special Publication 800-53 Rev. 5 का control AU-3 भी इसी तरह की व्यावहारिक माँग करता है। Audit record में क्या हुआ, कब हुआ, कहाँ हुआ, source क्या था, outcome क्या था और event किस identity से जुड़ा था, यह शामिल होना चाहिए। उपयोगी बात checklist की भाषा नहीं, बल्कि यह ज़ोर है कि outcome record का हिस्सा होना चाहिए। Permission decision उस field को नहीं भर सकता।

दोनों records में अलग fields चाहिए

एक साफ audit model किसी एक requested action के लिए एक authorization event और एक या अधिक execution events रखता है। दोनों में correlation identifier समान होता है, लेकिन हर record अपने claim को support करने वाले fields रखता है।

Authorization record को execution शुरू होने से पहले request की पहचान करनी चाहिए। Calling process identity, human decision, credential reference, intended channel, destination और requested operation दर्ज करें। Authorization scope को इतना सटीक रखें कि reviewer देख सके कि बाद की call उसके भीतर रही या नहीं।

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

{
  "event_type": "authorization.granted",
  "action_id": "act_01JX7K8N4Q",
  "session_id": "ses_01JX7JYQ2M",
  "time": "2025-03-08T14:21:18Z",
  "agent_process": {
    "pid": 4812,
    "code_signing_authority": "Example Development Team"
  },
  "human_decision": {
    "method": "local_confirmation",
    "actor": "local_user"
  },
  "requested_action": {
    "channel": "http",
    "credential_ref": "billing-api-prod",
    "method": "POST",
    "destination": "api.internal.example",
    "path": "/v1/refunds"
  }
}

इस record में default रूप से API secret, SSH private key, authorization header या raw request body नहीं होना चाहिए। Credentials से भरा audit store breach का दूसरा रास्ता बन सकता है। अगर reviewers को private content वाली requests में अंतर करना हो, तो सुरक्षित हिस्से का cryptographic digest और documented rules के अनुसार छोटा, redacted summary रखें।

Execution record gateway द्वारा action का प्रयास किए जाने से शुरू होता है। इसमें यह साफ होना चाहिए कि action किसी protocol boundary तक पहुँचा या नहीं और क्या वापस आया। HTTP के लिए method, destination, response status, transport error, response size और सीमित response classification दर्ज करें। SSH के लिए account, host identity, command representation, exit status, signal, अगर कोई हो, और client-side connection result दर्ज करें।

{
  "event_type": "execution.finished",
  "action_id": "act_01JX7K8N4Q",
  "time": "2025-03-08T14:21:20Z",
  "channel": "http",
  "attempt": 1,
  "delivery": "response_received",
  "result": {
    "http_status": 201,
    "response_bytes": 428,
    "response_digest": "sha256:..."
  }
}

केवल success: true को result field न बनाएँ। अलग-अलग protocols और products में success का अर्थ बदलता है। HTTP 201 का अर्थ है कि server ने resource बनने की सूचना दी। HTTP 202 का अर्थ है कि उसने बाद में process होने वाला काम स्वीकार किया। SSH exit status 0 का अर्थ है कि remote command ने success report की, फिर भी script के भीतर हुई failure को उसने नज़रअंदाज़ किया हो सकता है। Typed outcome reviewers को अस्पष्ट हरे label के बजाय facts देता है।

Trusted action boundary को correlation बनाना चाहिए

जिस component के पास credentials होते हैं और जो action करता है, उसे action ID बनाना चाहिए। Agent काम का अनुरोध कर सकता है, लेकिन उसे यह दर्ज करने का source नहीं होना चाहिए कि उसे क्या करने की अनुमति थी या gateway ने क्या भेजा।

यह तब महत्वपूर्ण है जब agent process buggy, compromised या लंबी tool conversation से भ्रमित हो। अगर वह खुद identifiers बनाए, तो बाद के outcome को पहले की request से जोड़ सकता है, असुविधाजनक calls छिपा सकता है या मनगढ़ंत status report कर सकता है। अच्छी तरह काम करने वाला agent भी restart के बाद context खो सकता है। Action boundary request, credential selection, outbound attempt और returned result को एक ही जगह देखती है।

ऐसा identifier चुनें जिसका कोई business meaning न हो और उसे कभी reuse न करें। Random या time-sortable unique ID ठीक रहती है। उसे हर local record में जोड़ें। जहाँ protocol अनुमति दे, उसे request identifier के रूप में बाहर भी भेजें। इससे service operators credential उजागर किए बिना अपने logs को gateway record से जोड़ सकते हैं।

HTTP request के लिए ऐसा dedicated header इस्तेमाल करें जिसे target system log करने के लिए तैयार हो, जैसे X-Action-ID। इस header को idempotency key न समझें। Action ID investigation में मदद करती है। Idempotency key supporting server को duplicate mutation पहचानने देती है। कभी-कभी एक ही value दोनों काम कर सकती है, लेकिन तभी जब service owner उसके अर्थ और retention period की पुष्टि कर दे।

Authorization: action_id=act_01JX7K8N4Q
Outbound request: POST /v1/refunds
Request header: X-Action-ID: act_01JX7K8N4Q
Response: 201 Created
Execution record: action_id=act_01JX7K8N4Q, delivery=response_received

Records को जोड़ने के लिए केवल timestamps पर निर्भर न रहें। Clocks में अंतर हो सकता है, requests overlap कर सकती हैं और agents एक ही second में समान calls कर सकते हैं। Timestamps क्रम समझने में मदद करते हैं, parentage साबित नहीं करते।

Session ID भी महत्वपूर्ण है, लेकिन यह व्यापक सवाल का उत्तर देता है: यह request किस agent process run ने की? दोनों IDs सुरक्षित रखें। Session बताता है कि किस process को standing permission मिली थी। Action ID बताती है कि कौन-सी particular operation को कौन-सा particular result मिला।

HTTP status codes सीमित लेकिन उपयोगी evidence हैं

HTTP response local approval से मजबूत execution evidence देता है, लेकिन उसकी व्याख्या करनी पड़ती है। Final status और उसके अर्थ को समझाने के लिए पर्याप्त context log करें। 200 range के बाहर आने वाले हर status को failure न मानें।

200 OK या 201 Created server की स्पष्ट report है। 204 No Content अक्सर बिना response body के सफल operation का अर्थ रखता है। 202 Accepted अलग है: target ने request को asynchronous processing के लिए ले लिया, लेकिन final work बाद में fail हो सकता है। Execution record में accepted_for_async_processing लिखें और जब service यह सुविधा देती हो, तो बाद की status check या callback को उसी action से जोड़ें।

Redirects पर सावधानी चाहिए। अगर gateway redirects follow करता है, तो original और final destination दोनों log करें और यह भी लिखें कि हर hop पर credential injection rule लागू हुआ या नहीं। Unexpected host को authorization header भेजना credential leak है, सामान्य redirect नहीं। व्यवहार में cross-host redirects को तब तक reject करें, जब तक operator ने target relationship को स्पष्ट रूप से configure न किया हो।

Client errors और server errors भी उपयोगी facts देते हैं। 403 साबित करता है कि service ने request deny की। 409 बता सकता है कि duplicate या conflicting state पहले से मौजूद है। 429 कहता है कि target ने फिलहाल काम स्वीकार नहीं किया। 500 का अर्थ है कि server ने fault report किया, यह नहीं कि कोई बदलाव नहीं हुआ। Response body result स्पष्ट कर सकती है, लेकिन उसे redaction और size limits के बाद ही store करें। Error responses में success responses से अधिक operational detail हो सकती है।

Transport failures के लिए अलग outcome values रखें। dns_failure, tls_validation_failure, connect_timeout, write_interrupted, response_timeout और connection_reset जैसे अंतर दर्ज करें। इससे reviewer समझ सकता है कि certainty कहाँ समाप्त होती है।

सबसे जोखिम भरी स्थिति वह है जब gateway request लिखना शुरू करने के बाद interrupted हो जाए। Service ने action किया हो सकता है। State को unknown_remote_outcome चिह्नित करें। केवल इसलिए failed न लिखें कि client को response नहीं मिला। अगर call state बदलती है, तो agent को रुककर सुरक्षित reconciliation method इस्तेमाल करनी चाहिए। यह method idempotency key से service को query करना, request identifier से resource पढ़ना या human से target की जाँच करवाना हो सकती है।

SSH के लिए remote process evidence चाहिए

SSH audit records अक्सर «host से connected» पर रुक जाते हैं। इससे सिर्फ इतना साबित होता है कि client ने SSH session बनाया। Command का result इससे पता नहीं चलता और exact host की पहचान भी नहीं होती, जब तक host key verification दर्ज न हो।

हर SSH action के लिए destination hostname, उपलब्ध हो तो resolved address, verified host key fingerprint, requested account, authentication method reference, normalized command और final client result दर्ज करें। Remote command शुरू हो जाए, तो उसका exit status और terminating signal भी रखें। Standard output और standard error को sensitive operational data मानें, automatic log material नहीं।

Normalized command review value बनाए रखते हुए exposure घटाती है। उदाहरण के लिए, secret argument वाली command को जस का तस रखने के बजाय executable, fixed options, sensitive argument positions और protected values का digest रखें।

requested_command: /usr/local/bin/rotate-service-token --project payments --token [redacted]
command_digest: sha256:...
remote_exit_status: 0
remote_signal: null
connection_result: clean_close

Exit status 0 remote command का evidence है, हर business effect के होने का proof नहीं। खराब shell script curl चला सकती है, उसकी error को नज़रअंदाज़ कर सकती है और फिर भी 0 पर exit कर सकती है। Script आपके नियंत्रण में हो, तो required operation fail होने पर उसे साफ failure और nonzero return के लिए बनाएँ। नियंत्रण में न हो, तो command outcome को ठीक-ठीक log करें और उससे अधिक दावा न करें।

Interactive SSH sessions को लेकर सावधान रहें। «permission granted» और «commands executed» के बीच इनमें बहुत बड़ा gap बन सकता है। सीमित remote command, agent को general interactive shell देने से बेहतर evidence देती है। कई commands की ज़रूरत हो, तो reviewed script में स्पष्ट exits रखें या हर command के लिए अलग action record बनाएँ। Agent को terminal में मनमाने ढंग से टाइप करने देने जितना आकर्षक यह नहीं है, लेकिन इसकी जाँच बहुत आसान है।

Host verification बंद न करें। अगर client ने network attack के दौरान या गलती से host बदलने के बाद unverified host स्वीकार किया हो, तो build-01 पर command चलने वाला record बहुत कम अर्थ रखता है। Execution event में verified host key fingerprint रखें। इससे reviewers hostname label और cryptographic identity में अंतर कर सकेंगे।

Timeout का अंत uncertainty में होना चाहिए, retry storm में नहीं

Teams को सबसे अधिक परेशान करने वाली failure अक्सर mutating API call से शुरू होकर timeout पर समाप्त होती है। Agent को permission मिली। Gateway ने connection खोला और request भेजी। Target ने बदलाव कर दिया, लेकिन response गायब हो गया, या target को अंतिम bytes मिले ही नहीं। Caller को दोनों स्थितियाँ एक जैसी दिखती हैं।

मान लें कि agent API के ज़रिए production incident ticket बनाता है। वह भेजता है:

POST /v1/incidents
Idempotency-Key: inc_72f9c
X-Action-ID: act_01JX7K8N4Q

Client इंतज़ार करता है और फिर response_timeout दर्ज करता है। केवल approval वाला audit trail कहता है कि व्यक्ति ने ticket को मंज़ूरी दी। सरल action log कहता है कि ticket creation fail हो गया। दोनों claims सुरक्षित नहीं हैं।

सही execution record कहेगा कि gateway ने request का प्रयास किया और उसे response नहीं मिला। इसमें action ID और idempotency key reference सुरक्षित रहनी चाहिए। इसके बाद agent service से inc_72f9c से जुड़ी state पूछे, अगर service ऐसा lookup देती है। Service existing ticket बताए, तो original action की ओर इशारा करने वाला reconciliation event log करें। Record न मिले और service का idempotency contract retry की अनुमति देता हो, तो उसी idempotency key के साथ एक बार retry करें, नई key के साथ नहीं।

इस sequence में तीन अलग facts हैं:

1. व्यक्ति ने original request को मंज़ूरी दी।
2. Gateway initial outcome की पुष्टि नहीं कर सका।
3. बाद की read या idempotent replay से final state स्थापित हुई।

Reconciliation के बाद timeout को मिटाएँ नहीं। यह बताता है कि बाद की action क्यों हुई। इससे यह भी पता चलता है कि team के पास recurring transport issue तो नहीं, जिसे polished success count छिपा दे।

SSH में भी ऐसी ही failure होती है। Local client का session खोने के बाद remote command चलती रह सकती है। जब तक command निश्चित रूप से idempotent न हो, automatic retries से बचें। Remote operation ID, नियंत्रित permissions वाली status file या state report करने वाली target API को प्राथमिकता दें। इनमें से कुछ भी न हो, तो unknown outcome दर्ज करें और human review माँगें। Agent को machine speed पर duplicate deployment commands चलाने देने से पहले ही काफी नुकसान हो चुका है।

Per-session और per-call approval अलग जोखिमों का उत्तर देते हैं

Per-session authorization यह स्थापित करती है कि कोई particular agent process अपने run के दौरान approved action channels का इस्तेमाल कर सकता है। जब human को कम प्रभाव वाले, छोटे और सीमित sequence की अपेक्षा हो, तब यह approval fatigue घटाती है। इससे बाद की calls individually reviewed decisions नहीं बन जातीं।

Per-call approval चुने हुए credential के हर इस्तेमाल पर human decision दर्ज करती है। इसका इस्तेमाल उन operations के लिए करें जहाँ हर destination, mutation या remote command पर fresh attention चाहिए। Execution record फिर भी आवश्यक रहता है। कोई व्यक्ति destructive API call को मंज़ूरी दे सकता है और service उसे reject, partially process या timeout कर सकती है।

Reviewer पूछे, «इस बदलाव को किसने मंज़ूरी दी?», तो अंतर साफ दिखता है। Session record कह सकता है, «इस signed agent process को इस channel को call करने की permission थी।» Per-call record कह सकता है, «किसी व्यक्ति ने इस exact request को इस समय मंज़ूरी दी।» इनमें से कोई यह नहीं बताता कि «क्या यह हुआ?» उस सवाल का उत्तर केवल execution evidence दे सकता है।

Approval prompts में human के meaningful decision के लिए पर्याप्त information दिखाएँ: calling process identity, credential reference, destination, method या command और क्या request state बदलती है। केवल «Allow agent access?» लिखने वाला prompt click तो दर्ज करता है, intent बहुत कम।

सुसंगत evidence तैयार करने से पहले विशाल policy language बनाने की कोशिश न करें। Teams अक्सर कम prompts चाहने पर rules की ओर जाती हैं। Rules actions को सीमित कर सकते हैं, लेकिन approval, attempt, response और unknown outcome में अंतर करने वाले audit model की जगह नहीं ले सकते। पहले facts को स्पष्ट बनाएँ, फिर तय करें कि automation कहाँ सुरक्षित है।

Hash chains history की रक्षा करती हैं, claim की सच्चाई की नहीं

Append-only, hash-chained log बाद में की गई tampering का पता लगाने में मदद करती है। हर event में ऐसा digest शामिल होता है या उसमें योगदान देता है जो पहले के records पर निर्भर करता है। कोई पुराने authorization में बदलाव करे, failed request हटाए या sequence को reorder करे, तो verification fail हो जाती है, जब तक कि वह बदले हुए point से आगे पूरी chain फिर से न लिख दे और trusted chain head को replace न कर दे।

Agent activity के लिए यह property महत्वपूर्ण है, क्योंकि सबसे शर्मनाक records अक्सर वही होते हैं जिन्हें कोई हटाना चाहता है: denied action, failed deployment, गलत service को भेजी गई request या अपेक्षा से अधिक देर तक चला session। ऐसा log जिसे administrators चुपचाप edit कर सकते हैं, गंभीर review में टिकेगा नहीं।

लेकिन hash chaining झूठी entry को सच नहीं बनाती। अगर untrusted agent «HTTP 201» देता है और log उस झूठ को ईमानदारी से chain कर देती है, तो chain केवल यह साबित करती है कि झूठ सुरक्षित रहा। Collector को action boundary पर event observe करना चाहिए। Gateway को response मिलने या transport failure का पता चलने के बाद execution result बनाना चाहिए।

NIST SP 800-92, Guide to Computer Security Log Management, कहता है कि logs को generation, transmission, storage, analysis और disposal के दौरान सुरक्षित रखना चाहिए। व्यावहारिक सीख केवल text files को centralize करना नहीं है। Raw event source सुरक्षित रखें, sequence की रक्षा करें, records बदलने वालों को नियंत्रित करें और verification को संभव बनाएँ, बिना उन secrets तक व्यापक access दिए जिनका actions ने इस्तेमाल किया।

Sallyport agent runs और individual calls को एक write-blind, encrypted, hash-chained audit log से project करता है। इसका sp audit verify command vault key की आवश्यकता के बिना ciphertext पर offline chain verify करता है। यह design history integrity जाँचने वाले reviewer को production credentials इस्तेमाल करने वाली process से अलग रखता है।

Verification command को स्पष्ट result और checked range दोनों देने चाहिए। उदाहरण के लिए:

$ sp audit verify
verified: 1847 records
chain: valid
first_record: 2025-03-01T08:15:02Z
last_record: 2025-03-08T14:21:20Z

Valid chain यह तय नहीं करती कि external API ने अपना वादा पूरा किया या नहीं। वह यह स्थापित करती है कि gateway द्वारा सुरक्षित रखा गया approval और received outcome का account बिना पता चले बदला नहीं गया।

अलग-अलग event counts नहीं, उनके joins की समीक्षा करें

Audit review तब विफल होती है जब teams approvals, successful calls और denied calls को अलग-अलग charts में गिनती हैं, लेकिन उनके बीच के joins की जाँच नहीं करतीं। उपयोगी review unit एक action timeline है: request, authorization decision, execution attempts, result और कोई reconciliation।

उन records से शुरू करें जिनका matching partner नहीं है। बिना execution event वाला authorization cancelled request, gateway crash या logging fault दिखा सकता है। बिना prior authorization वाला execution event bypass का संकेत हो सकता है। Reconciliation के बिना unknown remote outcome अधूरा operational work है, बंद failure नहीं।

ऐसे छोटे queries या reports रखें जो इन सवालों को मजबूर करें:

• कौन-सी approved mutating actions unknown remote outcome पर समाप्त हुईं?
• किन calls को authorization scope से बाहर response मिला?
• कौन-सी SSH commands बिना exit status के समाप्त हुईं?
• किन per-session approvals से expected task समाप्त होने के बाद भी actions हुईं?
• कौन-से action IDs local records में हैं, लेकिन target service logs में नहीं?

अंतिम query में सावधानी चाहिए। Target log में request ID न होना यह बता सकता है कि target ने उसे retain नहीं किया, clock window गलत है या logs किसी दूसरी team के पास हैं। इसे investigation signal मानें, wrongdoing का proof नहीं।

Sallyport की session journal और activity journal इस विभाजन को व्यावहारिक बनाती हैं: एक view agent run और उसकी revocation state दिखाता है, दूसरा individual calls। Reviewers को session और action identifiers के ज़रिए दोनों के बीच जाना चाहिए, किसी एक journal को पूरी कहानी नहीं मानना चाहिए।

Certainty के लिए स्पष्ट vocabulary रखें। authorized, attempted, response_received, remote_exit_received, denied, failed_before_send और unknown_remote_outcome एक अकेले success flag से अधिक आसानी से defend किए जा सकते हैं। Team इन terms का लगातार इस्तेमाल करने लगे, तो कठिन cases friendly green dashboards में गायब नहीं होंगे।

Agent को व्यापक access देने से पहले evidence बनाएँ

शुरुआत के लिए complex control plane ज़रूरी नहीं। Credential use को trusted action boundary के पीछे रखें, वहीं action ID बनाएँ, human decision को result से अलग दर्ज करें और unknown outcomes को failure में बदलने के बजाय सुरक्षित रखें। इससे incident responders को ऐसी sequence मिलती है जिसे वे service और host records के साथ जाँच सकते हैं।

इसके बाद record को केवल happy path पर नहीं, failure के दौरान भी test करें। Request को approve करके send के बाद connection काटें। ऐसा SSH command चलाएँ जो nonzero exit लौटाए। DNS failure उत्पन्न करें। Agent session revoke करें और जाँचें कि बाद की calls denial records पा रही हैं। देखें कि reviewer किसी source file खोले या agent से उसका अर्थ पूछे बिना हर event समझा सकता है या नहीं।

Agent को credential अपने पास रखे बिना action करने की अनुमति दी जा सकती है। उसे यह तय करने की अनुमति नहीं दी जा सकती कि हुआ क्या था। Decision record रखें, execution result रखें और network साथ न दे तो uncertainty को स्पष्ट रहने दें।