# AI coding agents के लिए credential inventory worksheet

AI coding agents को विरासत में मिले credentials का ढेर और “सावधान रहना” जैसी अस्पष्ट हिदायत नहीं मिलनी चाहिए। Agent के API call करने, service deploy करने या SSH connection खोलने से पहले किसी record में यह स्पष्ट होना चाहिए कि credential किस तक पहुंचता है, इसकी जिम्मेदारी किसकी है और टीम इसे कैसे बंद करेगी।

Credential inventory worksheet तब तक प्रशासनिक काम लगती है, जब तक agent operator के keyboard से दूर रहते हुए बीस calls नहीं कर देता। उस समय यह एक ज्ञात capability revoke करने और पूरे engineering संगठन को बंद करने के बीच का अंतर बन जाती है, क्योंकि किसी को token पहचान में नहीं आता। मैंने टीमों को तब पता लगाते देखा है कि उनकी “staging” automation में production write token था, जब automated change गलत जगह पहुंच चुका था।

## Inventory में secret string नहीं, authority दर्ज करें

Worksheet authority दर्ज करती है। इसमें API token, private SSH material, password, recovery code या इनका encrypted export नहीं होना चाहिए। यदि worksheet किसी चीज को authenticate कर सकती है, तो वह कमजोर access controls वाला नया secret store बन गई है।

Identifier और credential को अलग समझें। API token के आखिरी चार characters rotation के समय सही entry खोजने में मदद करते हैं, लेकिन यह नहीं बताते कि token project delete कर सकता है या नहीं। SSH public-key fingerprint identity की पहचान करता है, लेकिन यह नहीं बताता कि कौन सा Unix account खुलेगा, port forwarding की अनुमति है या नहीं, अथवा कौन से hosts उस key पर भरोसा करते हैं।

हर independently revocable authority के लिए एक row रखें। एक provider account में read-only production reporting token, staging deploy token, break-glass administrator token और webhook signing secret के लिए अलग rows हो सकती हैं। इन्हें मिलाने पर अलग-अलग risk और rotation requirements गायब हो जाती हैं। यही नियम SSH पर भी लागू होता है। “Git और servers” को एक cell में न लिखें। Source-control write identity और host login identity के परिणाम अलग होते हैं।

NIST SP 800-57 Part 1 cryptographic key management को lifecycle की तरह देखता है: generation, distribution, storage, use, replacement और destruction सभी नियंत्रित होने चाहिए। यही अनुशासन credentials पर भी लागू होता है। “हमने token बना लिया” वाली सूची inventory नहीं, केवल ऐसी याददाश्त है जो जरूरत के समय विफल होगी।

## हर credential का एक जवाबदेह owner रखें

हर row में एक named owner होना चाहिए जो बता सके कि यह authority अभी भी जरूरी है या नहीं। Owner को secret manager चलाना या agent integration लिखना जरूरी नहीं, लेकिन उसे संबंधित system की पर्याप्त समझ होनी चाहिए।

“platform”, “dev team”, “shared” या inactive employee का नाम owner के रूप में न लिखें। Group process चला सकता है, लेकिन incident responder को रात 2 बजे किसे फोन करना है, यह group name नहीं बताता। Primary owner और जरूरत पड़ने पर revoke या replace करने वाला backup owner दर्ज करें।

इन चार भूमिकाओं को अलग रखें:

- System owner तय करता है कि access उचित है या नहीं।
- Credential custodian material को create, store, revoke और rotate कर सकता है।
- Agent operator agent run शुरू या supervise करता है।
- Incident contact तत्काल समस्या संभालता है।

छोटी टीम में एक व्यक्ति कई भूमिकाएं निभा सकता है, फिर भी worksheet में भूमिकाएं अलग नाम से लिखें।

Review date को secret rotation date से अलग रखें। Token तकनीकी रूप से valid रह सकता है, जबकि उसका business purpose खत्म हो चुका हो। Review पूछता है कि access रहना चाहिए या नहीं; rotation उस material को बदलता है जो पुराना या उजागर हो सकता है। एक काम करने से दूसरा पूरा नहीं होता।

## अनुमत actions को verbs और targets के रूप में लिखें

“Production access” permission description नहीं है। Worksheet में verbs, target resources और ऐसी सीमाएं चाहिए जिन्हें reviewer जांच सके। यह रूप इस्तेमाल करें:

`verb + target + boundary + forbidden action`

उदाहरण:

- `GET /v1/projects/acme/builds in staging; no production tenant requests`
- `POST deployment revisions for service catalog-api; no rollback or deletion`
- `SSH as deploy on build host group; run approved release command only; no interactive shell`
- `Create issue comments in repository alpha; no merge, branch deletion, or settings changes`

Provider का व्यापक “write” label पर्याप्त नहीं है। Deployment revision बनाना और deployment हटाना दोनों write permission हैं, लेकिन उनका blast radius बहुत अलग है। Record करें कि action read, create, modify, delete, execute या administrative change है। Execute पर विशेष ध्यान दें। Cloud job शुरू करना, service credential rotate करना, payment operation trigger करना या remote shell चलाना request log में साधारण दिख सकता है, लेकिन परिणाम महंगा या अपरिवर्तनीय हो सकता है।

“Use only when appropriate” और “normal deployment work” जैसी अस्पष्ट भाषा सीमा तय नहीं करती। यदि action context पर निर्भर है तो named environment, repository, host group, account या change type लिखें। General administrator token देकर prompt पर भरोसा करना गलत है। Prompt access control नहीं है, और बाद की tool calls वही व्यापक authority ले सकती हैं।

## Environments के लिए अलग rows और अलग परिणाम रखें

Staging और production credentials को केवल इसलिए एक row में न मिलाएं कि वे एक ही API call करते हैं। Target account, data exposure, approval requirement और revocation urgency अलग हो सकते हैं। Environment को केवल label न मानें। Provider account या tenant, endpoint या host group, data classification और cross-environment access दर्ज करें। “Prod” कई accounts, regions या customer partitions वाले संगठन में बहुत अस्पष्ट है।

उदाहरण:

`production / tenant 4821 / customer account data / endpoint api.example.internal`

यदि internal hostname खुद sensitive है, तो उसे ऐसे worksheet में न लिखें जिसे बहुत लोग पढ़ सकते हैं। Target को अधिकृत टीम के लिए पर्याप्त सटीक नाम दें।

Agent response में कौन सा data पा सकता है, उसके लिए अलग field रखें। Endpoint call करने की अनुमति और response देखने की अनुमति जुड़े हुए, लेकिन अलग risks हैं। Read request source code, customer contacts, invoices, access metadata या पुराने configuration value में छिपा secret लौटा सकती है।

यदि provider environments को अलग नहीं कर सकता, तो documentation से समस्या छिपाने की कोशिश न करें। Credential को cross-environment mark करें, approval level बढ़ाएं और तय करें कि agent को इसका उपयोग करना भी चाहिए या नहीं। कभी-कभी सही उत्तर “नहीं” होता है।

## SSH access को API access से अधिक विवरण चाहिए

SSH connection एक साथ कई तरह की authority दे सकता है। Login account, accepted hosts, command restrictions, forwarding permissions और agent forwarding setting सभी महत्वपूर्ण हैं।

हर SSH row में public-key fingerprint, private material location, login account, host या host group और exact intended command दर्ज करें। Private key sheet में copy न करें। Public key file पर यह command चलाएं:

```text
ssh-keygen -lf ~/.ssh/id_agent_deploy.pub
```

परिणाम कुछ ऐसा होगा:

```text
256 SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz0123456789abcd agent-deploy (ED25519)
```

`SHA256:` value रखें। Comment तभी रखें जब वह role पहचानने में मदद करे। Comment security control नहीं है।

`authorized_keys` restrictions देखें और यह न मानें कि deploy account अपने-आप सीमित है। OpenSSH के `command=`, `no-port-forwarding`, `no-agent-forwarding` और `no-pty` जैसे options automation identity को constrained command runner बना सकते हैं। ये unrestricted administrator account में login करने वाले credential को सुरक्षित नहीं कर सकते।

Entry में लिखा जा सकता है: “login `deploy`, release group A के hosts, forced command `/usr/local/bin/release-catalog`, no port forwarding, no PTY, no agent forwarding।” Emergency interactive shell चाहिए तो अलग human-operated identity बनाएं। Agent identity को चुपचाप reuse न करें।

Host verification भी record का हिस्सा है। लिखें कि agent-side integration host identity कैसे जांचता है, known-host entries कहां रहती हैं और legitimate host replacement के बाद उन्हें कौन update करता है। Host verification बंद करके rebuild पूरा करना valid credential को गलत machine तक भेज सकता है।

## उपयोगी worksheet कठिन सवालों के जवाब मांगती है

इस template को controlled document, ticket system या inventory database में डालें। जो columns team maintain नहीं कर सकती उन्हें हटाएं, लेकिन authority, scope और recovery वाले fields न हटाएं।

| Field | क्या दर्ज करें |
|---|---|
| Credential ID | Stable internal ID, non-secret token suffix या SSH fingerprint |
| Channel | HTTP API या SSH |
| System and purpose | Provider या host service और agent task |
| Environment and target | Account, tenant, host group, repository या endpoint boundary |
| Permitted actions | Verbs, targets, limits और forbidden actions |
| Response data | Agent द्वारा प्राप्त या output में उजागर किया जा सकने वाला data |
| Owner and backup | Named system owner और authorized backup |
| Custodian | Material create, revoke और rotate करने वाला व्यक्ति या team |
| Storage location | Vault reference या managed location, secret value कभी नहीं |
| Agent path | Named agent integration, tool call या approved execution route |
| Approval level | None, per session या every use, कारण सहित |
| Rotation plan | Trigger, date या interval, जिम्मेदार व्यक्ति और replacement test |
| Revocation method | Exact console role, command या runbook reference |
| Evidence | Audit location, last review date और reviewer |

`agent path` यह स्पष्ट करता है कि agent इस credential का प्रभाव कैसे पाता है। “Coding shell में environment variable” उत्तर है, लेकिन इससे सावधान होना चाहिए क्योंकि process इसे print, transmit या persist कर सकता है। “Action gateway request करता है और response लौटाता है” कम exposure वाला design है।

`revocation method` किसी दूसरे व्यक्ति द्वारा चलाया जा सके। “Sam से पूछें” method नहीं है। “Provider project settings में token disable करें, फिर active agent session revoke करें” method है। इसे row जोड़ते समय ही test करें।

सिर्फ active या inactive status पर्याप्त नहीं है। `last used`, `last reviewed` और `planned retirement` भी रखें। Unused credential harmless नहीं होता। Project खत्म होने के बाद उसे revoke करना अक्सर भूल जाता है।

## Rotation plan में replacement और proof दोनों रखें

Rotation तभी पूरी है जब पुराना credential disable हो और replacement वास्तविक agent path से intended action कर चुका हो। नया token बनाकर storage में डालना और पुराने को बाद में हटाने का वादा करना दोनों identities को जीवित रखता है।

Rotation plan में ये पांच बातें हों:

1. Rotation शुरू करने वाली घटना, जैसे expiry, staff departure, suspected exposure या scope change।
2. Replacement बनाने वाला व्यक्ति और बदली हुई authority approve करने वाला व्यक्ति।
3. वह स्थान जहां नया material रखा जाएगा और agent तक नहीं पहुंचेगा।
4. छोटा test action जो replacement के काम करने का प्रमाण दे।
5. वह exact point जब पुराना material revoke होगा और evidence record होगा।

HTTP credential के लिए intended scope वाला harmless endpoint call करें। SSH के लिए approved host group पर forced deployment status command चलाएं, general shell login से test न करें।

```text
Credential ID: api-catalog-deploy-prod-01
Replacement ID suffix: ...7KQ2
Test: POST /deployments/validate for catalog-api revision 8f3c
Expected: HTTP 200 with validation status accepted
Old credential revoked: provider audit event recorded
Reviewer: production service owner
```

ऐसा rotation schedule न बनाएं जिसे team निभा नहीं सकती। बार-बार exceptions inventory को अविश्वसनीय बना देते हैं। Provider expiry का उपयोग करें, event-driven triggers रखें और risk के अनुसार review cadence तय करें। Exposure का संदेह हो और service सह सके तो पहले revoke करें। Logs सुरक्षित रखें, credential बदलें और फिर जांच करें।

## Agent approval call के परिणाम के अनुसार हो

Agent run में script से अलग lifecycle होता है। कोई व्यक्ति इसे शुरू करके चला जाता है और लौटने पर देखता है कि कई external calls हो चुकी हैं। इसलिए worksheet में यह भी लिखें कि human authorization कब जरूरी है।

Trusted, identified local process और low-to-moderate consequences वाले contained run के लिए per-session approval ठीक है। High-impact operations, जैसे publish, deploy, production data बदलना, sensitive response पाना या external commitment बनाना, हर उपयोग पर approval मांगें। Scope approval का विकल्प नहीं है। पहले permissions सीमित करें, फिर approval से बचा हुआ risk संभालें।

Sallyport API और SSH credentials को Mac के encrypted vault में रखता है और नए agent process या चुने हुए credential के हर उपयोग पर authorization मांग सकता है। Agent को secret नहीं, परिणाम मिलते हैं।

High-consequence row को उपयोग के बाद अपेक्षित audit evidence से जोड़ें। Session identifier या run journal location, call-level activity record, target, timestamp, outcome और approving person दर्ज करें। यदि evidence यह नहीं बता सकता कि कौन सा credential किस result के लिए इस्तेमाल हुआ, तो integration दी गई authority के लिए बहुत opaque है।

## खराब run के बाद audit records जवाब देते हैं

Inventory preventive work है। Audit records बताते हैं कि agent ने वास्तव में क्या करने की कोशिश की, क्या सफल हुआ और कौन सी authority ने इसे संभव बनाया। दोनों कामों को न मिलाएं। Worksheet call होने का प्रमाण नहीं देती और log permission के उचित होने का प्रमाण नहीं देता।

एक inventory row पर incident drill करें। Operator owner खोजे, credential revoke करे, current agent access रोके, last successful call पहचाने और audit trail में बदलाव न होने की पुष्टि करे। समय ही नहीं, confusion भी मापें।

जब कई लोग logs देख या export कर सकते हों, tamper evidence जरूरी है। Hash-chained log unauthorized बदलावों का पता लगाने में मदद करता है, लेकिन वह खराब request को समझदार नहीं बनाता और authorized व्यक्ति को गलत call करने से नहीं रोकता। ये अलग controls हैं।

Audit retention का निर्णय inventory record के साथ रखें, खासकर जब response में sensitive output हो। जांच के लिए पर्याप्त context रखें, लेकिन full customer payload हमेशा के लिए न रखें। जहां संभव हो request metadata और result status रखें।

सबसे पहले उस credential row को पूरा करें जिसका उपयोग agent आज production change करने के लिए कर सकता है। Target स्पष्ट लिखें, permitted verb concrete बनाएं, revoke instruction ऐसा लिखें जिसे दूसरा व्यक्ति चला सके और replacement path test करें। यदि उस row में अनुमान हैं, तो बाकी inventory केवल सजावट है।