स्वायत्त प्रोग्रामिंग टूल के लिए macOS Keychain

जब कोई क्रेडेंशियल इस्तेमाल नहीं हो रहा होता, तब macOS Keychain उसकी अच्छी सुरक्षा करता है। इससे वह किसी स्वायत्त प्रोग्रामिंग टूल के लिए पूरी सुरक्षा सीमा नहीं बन जाता। किसी प्रक्रिया को API टोकन या निजी कुंजी मिल जाए, तो वह आम तौर पर उसकी प्रतिलिपि बना सकती है, उसे दिखा या बाहर भेज सकती है और ऑपरेटर के काम खत्म मान लेने के बाद भी उसका उपयोग जारी रख सकती है।

यह अंतर सामान्य डेस्कटॉप ऐप के मुकाबले एजेंट के लिए अधिक मायने रखता है। इंसान मेन्यू कमांड चुनकर तत्काल परिणाम देखता है। एजेंट टेक्स्ट समझता है, टूल चलाता है, आउटपुट के आधार पर आगे बढ़ता है और घंटों काम कर सकता है। Keychain स्टोरेज पूछता है, «यह रहस्य कौन पढ़ सकता है?» ब्रोकर वाला निष्पादन कठिन सवाल पूछता है, «क्या यही प्रक्रिया अभी यही कार्रवाई कर सकती है, बिना रहस्य पाए?» PAM सत्र प्रमाणीकरण इससे जुड़ा अलग सवाल पूछता है कि लॉगिन सत्र किसने खोला। इन तीन नियंत्रणों को एक मानने पर ऐसी कमियां बचती हैं जो डेमो में नहीं दिखतीं, पर घटना के बाद जांच में परेशान करती हैं।

Keychain संग्रहित क्रेडेंशियल बचाता है, हर उपयोग नहीं

Keychain रहस्य को एन्क्रिप्ट करके रखता है और macOS सुरक्षा सेवाओं से पहुंच नियंत्रित करता है। टोकन के लिए यह .env फाइल, shell इतिहास, रिपॉजिटरी या एजेंट कॉन्फिगरेशन से कहीं बेहतर जगह है। आइटम पर पहुंच नियंत्रण लगाया जा सकता है और सिस्टम उसे देने से पहले उपयोगकर्ता की मौजूदगी मांग सकता है। ये अनधिकृत पढ़ाई और साधारण फाइल चोरी के विरुद्ध वास्तविक सुरक्षा हैं।

रहस्य दिए जाने पर सीमा खत्म हो जाती है। सहायक प्रोग्राम टोकन को टेक्स्ट में लौटाए, तो टोकन सहायक, IPC रास्ते और पाने वाली प्रक्रिया में मौजूद है। वह डिबग संदेश, अपवाद, ट्रांसक्रिप्ट, क्रैश रिपोर्ट, swap, कॉपी किए गए environment, child process या दुर्भावनापूर्ण अनुरोध में जा सकता है। Keychain उन bytes को वापस नहीं बुला सकता। बाद में उसे लॉक करने से मेमोरी में कॉपी bearer token अमान्य नहीं होता।

Apple का Keychain Services दस्तावेज पासवर्ड, कुंजी और प्रमाणपत्र को रखने और निकालने की बात करता है। «निकालना» समर्थित परिणाम है। Keychain हर रहस्य को गैर-निर्यात योग्य signing key नहीं बनाता। कुछ cryptographic keys को access control के साथ बनाकर private material निकाले बिना security API से इस्तेमाल किया जा सकता है, पर सामान्य API token को कहीं HTTP header बनना ही पड़ता है। सवाल यह है कि कौन सा भरोसेमंद component अनुरोध बनाकर भेजता है।

Production token के बजाय फेंके जा सकने वाले मान से जांच करें। उसे रखें, एजेंट वाला ही रास्ता उसे निकाले और देखें कि प्रक्रिया लौटे bytes के साथ क्या कर सकती है:

security find-generic-password -a agent-test -s example-api -w

आउटपुट में रहस्य और फिर newline आता है:

test_token_7f3a...

एजेंट या उसके नियंत्रण वाला shell यह कमांड चला सकता है, तो storage layer अपना निर्णय ले चुका है। Terminal में मान छिपाना केवल इंसान का दृश्य बदलता है। प्रक्रिया आउटपुट redirect, encode या अनुरोध में शामिल कर सकती है।

स्वीकृत पाठक अनचाहा निर्यातक बन सकता है

जो principal जोखिम पैदा करता है, वह अक्सर अनजान हमलावर नहीं बल्कि आपका स्वीकृत टूल होता है। उपयोगी बनने के लिए स्वायत्त प्रक्रिया को files, build tools, package commands और network clients की व्यापक पहुंच चाहिए। उसी प्रक्रिया को पढ़ने योग्य क्रेडेंशियल दें, तो prompt injection, संक्रमित dependency या गलत command सामान्य पहुंच को निर्यात में बदल सकते हैं।

Code-signing requirement Keychain item पढ़ सकने वाले app को सीमित कर सकती है। अलग unsigned या अलग तरह से signed process के विरुद्ध यह मदद करती है। लेकिन स्वीकृत app shell चलाता हो, plugin लोड करता हो, अविश्वसनीय repository निर्देश लेता हो या tool protocol खोलता हो, तो लाभ घट जाता है। हमलावर से प्रभावित व्यवहार signed binary ही चला सकता है।

Delegation की समस्या भी है। स्वीकृत desktop helper token पढ़कर standard input से agent को दे, तो Keychain helper देखता है, अंतिम उपयोगकर्ता नहीं। Helper उसे environment variable में रखे, तो environment पाने वाले हर child को token मिल सकता है। मूल access decision यह नहीं बताता कि आगे कौन सा operation करना था।

Architecture diagram की पेटी देखने के बजाय secret को data की तरह खोजें:

• Plaintext सबसे पहले किस process को मिलता है?
• क्या child, plugin, shell command या transcript उसकी copy पा सकता है?
• क्या पाने वाला destination, HTTP method, path या SSH host चुनता है?
• कौन सी घटना उसका अधिकार खत्म करती है और क्या पहले निकला material मिटता है?

टीमें अक्सर पहला सवाल हल करके बाकी छोड़ देती हैं। डिजाइन स्थिर अवस्था में सुरक्षित दिखता है, लेकिन एजेंट शुरू होते ही लंबे समय तक रहने वाले plaintext credential जैसा काम करता है।

PAM लॉगिन साबित करता है, एजेंट की मंशा नहीं

Pluggable Authentication Modules, यानी PAM, सेवा को login सीमा पर authentication policy लगाने देते हैं। macOS में sudo, login और remote login रास्ते नाम वाले PAM configurations उपयोग करते हैं। PAM stack user को authenticate, account को check, credentials स्थापित और session को खोल या बंद कर सकता है। इससे तय होता है कि कोई व्यक्ति privileged operating-system session शुरू कर सकता है या नहीं।

PAM आम तौर पर चल रहे एजेंट की हर HTTP API call नियंत्रित नहीं करता। Authentication के बाद process मिली OS identity और capabilities से काम करता है। वह token पढ़ सकता हो, तो PAM पहले का Touch ID gesture या password entry किसी बाद के एक request से नहीं जोड़ता। कोई अन्य component फर्क न लागू करे, तो PAM POST /releases को GET /status से अधिक संवेदनशील भी नहीं समझता।

«Session» कई अलग जीवनकालों का नाम है। PAM session login या sudo गतिविधि को घेर सकता है। Terminal session window में बचा रह सकता है। Agent session एक process run, बातचीत या resumed task हो सकता है। API session bearer token जितना लंबा हो सकता है। एक को खत्म करने से बाकी अपने आप खत्म नहीं होते।

एक विफलता ऐसे होती है: operator shell खोलने के लिए authenticate करता है, agent चलाता है और Keychain access स्वीकार करता है। Agent deployment token पढ़ता है। घंटों बाद operator बातचीत बंद कर देता है, पर child process के environment में token बचा रहता है। PAM ने मूल session को सही authenticate किया और Keychain ने read सही approve किया। दोनों आगे का उपयोग नहीं रोक पाए, क्योंकि action के जीवनकाल का मालिक कोई नहीं था।

OS account को session खोलने देना हो तो PAM उपयोग करें। उसे session के भीतर हर action के लिए नई मानवीय मंशा का प्रमाण न मानें। PAM वह अर्थ नहीं देता।

प्रमाणीकरण और प्राधिकरण अलग सवाल हैं

Authentication बताता है कि principal कौन है या उसने कौन सा credential दिखाया। Authorization तय करता है कि वह दिए context में क्या कर सकता है। Secret storage material को approved read या cryptographic operation तक रखता है। ये नियंत्रण साथ काम कर सकते हैं, पर एक-दूसरे की जगह नहीं लेते।

Autonomous tool में principal का सही नाम लें। «User» बहुत अस्पष्ट है। Keyboard पर operator, signed agent executable, नया agent process, MCP server, shell child और remote API account अलग principals हैं। एक approval सब पर लागू हो, तो design को साफ कहना चाहिए।

दैनिक काम में process run व्यावहारिक इकाई है। Operator पहचाने गए agent process को उसके exit तक approve करता है और नए run के लिए नया निर्णय लेता है। Silent restart पुरानी मंजूरी नहीं पाता। बहुत संवेदनशील credential के लिए सीमा छोटी होनी चाहिए: approved run में भी हर उपयोग पर मंजूरी।

Per-call approval अपने आप सुरक्षित नहीं है। केवल «Network access दें?» कहने वाला dialog निर्णय के लिए बहुत कम बताता है। उसमें requesting process और जोखिम बदलने वाले विवरण दिखें: credential alias, HTTP method और destination, या SSH user और host। Approval fatigue भी रोकनी होगी। Harmless read और production write एक जैसे बाधित करें, तो इंसान दोनों को बिना पढ़े मंजूर करेगा।

Process identity को path या display name तक सीमित न करें, क्योंकि दोनों copy होते हैं। macOS में code-signing requirement निर्णय को signing authority और designated requirement से जोड़ सकती है, जबकि process identifier running instances को अलग करता है। Operator को वही signing fact दिखाएं जो system ने verify किया, न कि ऐसा friendly name जिसे अविश्वसनीय binary दोहरा सके।

Code signing सही व्यवहार सिद्ध नहीं करता। वह signing model में origin बताता है, intent नहीं। सही signed agent repository की hostile instruction मान सकता है और signed plugin host attacker-controlled content लोड कर सकता है। Session approval का अर्थ होना चाहिए कि पहचाना process exit तक broker से action मांग सकता है, यह नहीं कि software का हर request सुरक्षित है।

Descendants का संबंध पहले तय करें। हर child पर automatic trust लंबे process tree को revoke करना कठिन बनाता है और general shell को जरूरत से अधिक अधिकार देता है। हर छोटे helper पर human prompt automation तोड़ता है। साफ design authorization को approved agent की broker connection पर रखता है। Children credential inherit नहीं करते और protected actions तक केवल mediated channel से पहुंचते हैं, जिसे parent session के साथ revoke किया जा सकता है।

Process exit उपयोगी automatic end है, पर operator को तत्काल revoke भी चाहिए। Broker को queued और future actions रोकने, session handle invalid करने और निर्णय दर्ज करने चाहिए। पहले से भेजे remote request को रोकना protocol और service पर निर्भर है; revoke पूरा काम वापस नहीं करता।

Restart भी जांचें। कुछ clients update, helper crash के बाद reconnect या नए process में बातचीत resume करते हैं। सुविधा वाला code इसे एक logical session मानता है। Security boundary नए process को नया माने, जब तक deliberate authenticated handoff continuity सिद्ध न करे। Agent का conversation ID प्रमाण नहीं है, क्योंकि वह copy हो सकता है।

इससे एक decision ladder बनती है:

1. क्या credential store unlocked और उपलब्ध है?
2. क्या नया agent process अपने जीवनकाल में काम कर सकता है?
3. क्या इस credential के हर उपयोग पर निर्णय चाहिए?
4. क्या trusted executor operation को सीमित और दर्ज करेगा?

पहले तीन authority नियंत्रित करते हैं, चौथा execution और evidence। इन्हें अस्पष्ट «trusted agent» flag में जोड़ने से revoke और investigation कठिन होते हैं।

ब्रोकर क्रेडेंशियल को एजेंट की मेमोरी से बाहर रखता है

Broker interface को «token दो» से «यह परिभाषित action करो» बनाता है। Agent non-secret parameters वाला request देता है। Broker authority जांचता है, अपनी सीमा में credential निकालता है, outgoing protocol में inject करता है, operation चलाता है और केवल जरूरी result लौटाता है।

HTTP API request ऐसा हो सकता है:

{
  "credential": "staging-release-api",
  "method": "POST",
  "url": "https://api.example.invalid/v1/releases",
  "headers": {"content-type": "application/json"},
  "body": {"commit": "8a31c2e", "channel": "candidate"}
}

Authorization के बाद broker bearer, basic या custom authentication header जोड़ता है। Agent-visible response status, चुने headers और body रख सकता है, credential नहीं:

{
  "status": 201,
  "headers": {"content-type": "application/json"},
  "body": {"release_id": "rel_1042", "state": "queued"}
}

यह redaction से स्पष्ट सीमा है। Redaction secret को पहले untrusted data path में जाने देता है, फिर पहचानने योग्य रूप छिपाता है। Broker disclosure होने ही नहीं देता। Revoke भी प्रभावी होता है: अगला request deny होने पर agent के पास bypass के लिए cached token नहीं होता।

Output फिर भी सावधानी मांगता है। API request headers वापस दिखा सकता है, SSH command environment print कर सकता है और verbose client error में authentication material डाल सकता है। लौटाने से पहले known locations filter करें, diagnostics सीमित करें और failure paths को success जितना जांचें। «Agent credential नहीं पाता» errors और logs पर भी लागू हो।

Brokered SSH को protocol-aware executor चाहिए। Agent named host identity पर command मांगता है। Executor private key भीतर उपयोग करता है, host verify करता है, command चलाकर stdout, stderr और exit status लौटाता है। Agent को temporary private-key file देना disclosure है, भले बाद में cleanup हो।

ब्रोकर हर हानिकारक स्वीकृत कार्रवाई नहीं रोकता

Token को agent से दूर रखना बड़ी विफलता श्रेणी हटाता है, पर requested action सही नहीं बनाता। Authorized DELETE credential leak किए बिना data मिटा सकता है। पूरी तरह सुरक्षित key के साथ SSH command host खराब कर सकता है। Broker authority के उपयोग को नियंत्रित करता है, syntax से business intent नहीं समझता।

Destination control जरूरी है। Agent कोई URL चुने और broker आंख बंद करके credential जोड़े, तो वह attacker host को भेजा जा सकता है। अच्छा HTTP executor credential को सही destinations से बांधता है या सुनिश्चित करता है कि authentication वहीं inject हो। Redirect भी जांचें। SSH में host identity verification execution का भाग हो, optional agent flag नहीं।

Response data खुला रहता है। सुरक्षित credential ग्राहक records, deployment configuration या अन्य secret वाला response authorize कर सकता है। Agent को काम जितना न्यूनतम response चाहिए, पर generic API इसे लागू करना कठिन बनाती है। Broker credential exposure घटाता है, automatic data-loss prevention नहीं देता।

Prompt injection भी बची रहती है। Repository text, issue comments, build output और fetched documentation agent से valid लेकिन unwanted action मंगा सकते हैं। Human approval तभी मदद करता है जब card पर्याप्त detail दिखाए और इंसान पढ़े। High-risk systems को narrower remote credentials, API scopes, protected branches, staging, command allowlist या अलग workflow engine चाहिए हो सकता है।

«हर secret Keychain में रखो और Touch ID मांगो» लोकप्रिय लेकिन अधूरी सलाह है। यह अच्छा storage choice और बहुत व्यापक use decision मिला देती है। Touch ID material जारी करते समय इंसान की मौजूदगी दिखाता है, बाद में approved recipient को copy या misuse से नहीं रोकता। संवेदनशील action की सीमा पर biometric मांगें और token agent को न दें।

ऑडिट में कार्रवाई दिखे और बदलाव पकड़ा जाए

अच्छा record बताता है कि action किसने मांगा, कौन सा process instance था, कौन सा credential alias चुना, destination और operation क्या थे, कौन सी authorization हुई, समय और परिणाम क्या था। उसमें credential नहीं होता। Console transcript अक्सर पर्याप्त नहीं, क्योंकि model text, tool messages, commands और truncated output बिना स्थिर event model के मिले होते हैं।

Session और call events अलग रखें, उनका संबंध बचाएं। Sessions journal process का आना, पहचान, approval, revoke और exit दिखाए। Activity journal हर HTTP या SSH operation और result दिखाए। Investigator तब «क्या run authorized था?» और «उसने क्या किया?» दोनों का उत्तर पाता है।

Encrypted logs at-rest confidentiality देते हैं, पर deletion या reordering न होने का प्रमाण नहीं। Hash chain हर entry को पिछली से जोड़कर बदले, गायब या reordered ciphertext को पकड़ती है। वह हर event record होने का प्रमाण नहीं और पूरे store की deletion नहीं रोकती। वह बचे records की integrity का evidence देती है।

Verification command सरल, automatable result दे। Sallyport एक write-blind encrypted hash-chained audit log से Sessions और Activity बनाता है; verifier बिना decryption key ciphertext पर offline चलता है:

sp audit verify

Success पर checked chain और zero exit status मिलना चाहिए; टूटी link पर failure और nonzero status। इसे incident collection और backup verification में रखें। उसी mutable app का green icon independent evidence नहीं है।

Logs के लिए redaction contract भी तय करें। Values के बदले aliases लिखें। Request body और command output को store, truncate, hash या exclude करने का फैसला लें। Malformed requests और transport errors जांचें, क्योंकि failure log अक्सर ज्यादा raw context रखता है।

पूरे रास्ते को प्रतिकूल परीक्षण से जांचें

Architecture claim तब सार्थक है जब test उसे तोड़ने की कोशिश करे। Disposable credential और endpoint बनाएं, फिर सामान्य काम वाले वही binaries और process boundaries उपयोग करें। Permission dialog का screenshot यह सिद्ध नहीं करता कि memory या descendants में क्या रहता है।

संक्षिप्त test plan:

1. नया agent process शुरू करें और पुराना approval न मिलने की पुष्टि करें। दिखाई process identity दर्ज करें।
2. Low-risk API read, फिर per-call protected write मांगें। Card destination और operation अलग दिखाए।
3. Agent-visible stdout, stderr, environment, transcript, tool payload और crash output में secret और encoded forms खोजें।
4. Session revoke करके parent और existing child से दोबारा कोशिश करें। Network या SSH से पहले दोनों fail हों।
5. Audit record copies बदलें, हटाएं और reorder करें। हर corrupt chain पर offline verification fail हो।

दो छूटने वाले abuse cases जोड़ें। Test endpoint को दूसरे origin पर redirect कराएं और authentication को follow न करने दें। Endpoint सभी headers echo करके verbose error दे; response agent तक जाने से पहले broker credential हटाए।

SSH में unknown host key, changed key, interactive password prompt और environment print करने वाली command आजमाएं। हर decision का owner तय करें। Stateless helper दूसरा credential cache न बनाए और जरूरत से अधिक environment inherit न करे।

Pass criteria observable हों। «Secret protected» test नहीं होता। «Byte sequence और उसका base64 रूप agent-visible file, process environment, tool response या log में कभी नहीं आता» test होता है। «Revoke works» की जगह मांगें कि revoked process और उसके existing children का हर call socket खुलने से पहले fail हो।

एजेंट के अधिकार के अनुसार नियंत्रण चुनें

Keychain अकेला पर्याप्त हो सकता है जब सामान्य app कम प्रभाव वाला credential निकाले, code path सीमित हो, user हर operation सीधे शुरू करे और threat model app को disclosure स्वीकार करे। मजबूत design में भी वह समझदार storage layer है। Mature encrypted store को घर में बनी secret file से बदलना लाभ नहीं देता।

Autonomous tool operation चुनता, untrusted project code चलाता, arbitrary children बनाता या लगातार निगरानी के बिना काम करता हो, तो उत्तर बदलता है। Agent को credential bytes के बजाय action capabilities दें। हर नए process run को authenticate करें, sensitive keys के लिए per-call confirmation रखें, credentials को intended protocols और destinations से बांधें और revoke से future use तुरंत रोकें।

Design चुनने से पहले सबसे मजबूत claim लिखें। Disk encryption को storage control चाहिए; केवल इस signed process को operations देने के लिए identity और session चाहिए; token दिए बिना API call के लिए broker चाहिए; और बचे audit records में बदलाव पकड़ने के लिए integrity evidence चाहिए। हर claim का test और owner अलग है।

हर claim के साथ residual risk लिखें। Broker remote write वापस नहीं करता, session पहले लौटे data को नहीं हटाता, signing harmless instructions सिद्ध नहीं करती और hash chain पूरे log store के बचने का प्रमाण नहीं है। इससे review एक control को दूसरे काम का credit नहीं देता।

Migration एक साथ जरूरी नहीं। Deployment tokens, infrastructure API keys और shared systems वाली SSH identities से शुरू करें। Read interface को छोटे actions से बदलें, पुरानी environment variables और helpers हटाएं, और test credential से old paths के fail होने का प्रमाण लें।

Operations की जिम्मेदारी भी तय करें: vault कौन unlock करता, process कौन approve करता, per-use check कौन लगाता, session कौन revoke करता और audit chain कौन verify करता है। Agent अजीब चले तो पहले session revoke करें, audit बचाकर verify करें और memory तक पहुंचे हर संभावित credential को rotate करें।

Sallyport macOS पर यही model अपनाता है: agents HTTP और SSH actions के लिए उसके sp mcp server से जुड़ते हैं, जबकि API और SSH keys encrypted in-process vault में रहती हैं। Fixed ladder में absolute vault gate, हर नए agent process की default authorization और चुनी key के हर use पर optional approval है।

इसे general policy engine या interception proxy न समझें। सीमित broker credential custody के बारे में मजबूत दावा कर सकता है क्योंकि वह defined execution paths का मालिक है। बाहर के actions को अपने controls चाहिए और remote services को scopes, environment separation और account-level revocation लागू करने चाहिए।

अंतिम review question सीधा है: approval के बाद क्या autonomous process credential को print, copy या स्वतंत्र रूप से reuse कर सकता है? हां, तो Keychain ने storage बचाया, use को सीमित नहीं किया। Keychain से उसका अच्छा काम लें और authority boundary उस executor पर रखें जो action चलाकर record करता है।