# Proof के साथ action gateway के पीछे credentials rotate करें

समाप्त होने वाले API token या SSH identity को बदलना एक साधारण काम होना चाहिए। यह तब खतरनाक बन जाता है जब हर agent, shell profile, repository secret और local tool अपनी अलग copy रखता हो। ऐसे setup में आप एक credential rotate नहीं करते। आप अनजानी संख्या में copies ढूंढते हैं, उम्मीद करते हैं कि सब मिल गईं, और उन जगहों का काम तोड़ देते हैं जिन्हें किसी ने test करने के बारे में सोचा ही नहीं था।

Action gateway इस काम को बदल देता है। Gateway credential अपने पास रखता है, बाहरी request चलाता है और result agent को लौटाता है। तब rotation के लिए secret रखने की एक जगह, controlled cutover और ऐसा evidence होता है जो agent session को इस्तेमाल की गई identity से अलग दिखाता है। Incident के समय यह separation सबसे ज्यादा मायने रखता है। उस समय लोग अक्सर «इस process ने request भेजी» और «इस process के पास token था» को एक ही बात समझ लेते हैं।

मैंने teams को rotation complete कहते देखा है क्योंकि secret manager में नई value दिखाई देने लगी थी। फिर किसी account की `authorized_keys` file में पुरानी deploy key बची रही, या किसी भूले हुए local environment variable ने expired API token को चालू रखा। Rotation तभी पूरी होती है जब replacement intended action path पर काम साबित कर दे और retired identity दोबारा authenticate न कर सके।

## Rotation identity बदलना है, string नहीं

Credential rotation में एक authenticating identity को दूसरी identity से बदला जाता है और यह साबित किया जाता है कि access सही तरीके से स्थानांतरित हुआ। किसी field में नया token paste करना इस बदलाव का केवल एक हिस्सा है।

अपने notes और tools में इन चार चीजों को अलग रखें:

- External identity: API token, client secret, SSH key pair या provider द्वारा स्वीकार की गई service account credential।
- Credential record: encrypted entry जिसमें identity और उसके इस्तेमाल की जानकारी रहती है।
- Authorization target: API account, repository, machine account, host या network endpoint जो उसे स्वीकार करता है।
- Agent session: वह खास process जिसने action मांगा।

लोग अक्सर पहली और चौथी चीज को मिला देते हैं। इससे incident reports गलत बनती हैं। Agent session ने gateway के जरिए endpoint को call किया हो सकता है, लेकिन उसे bearer token पढ़ने की जरूरत नहीं थी। दूसरी ओर, leaked token का इस्तेमाल ऐसे process ने किया हो सकता है जो आपके agent journal में कभी दिखता ही नहीं। ये अलग investigations हैं और इनके containment steps भी अलग हैं।

Expiry के मामले में भी यही फर्क लागू होता है। Provider किसी तय समय पर token expire कर सकता है, जबकि आपका gateway record stored data के रूप में बिल्कुल ठीक रह सकता है। Record अपने आप expire नहीं होता। Provider के उसे reject करने से पहले external identity बदलें, नई identity validate करें और पुरानी को retire करें।

NIST Special Publication 800-57, Part 1 cryptoperiod को केवल calendar reminder नहीं मानता। उसमें cryptoperiod को exposure, use और compromise के risk से जोड़ा गया है। API और SSH credentials के लिए भी यही सही सोच है। Broad write access देने वाले, बार-बार इस्तेमाल होने वाले या जिनके owner साफ नहीं हैं, ऐसे token की planned life उस narrowly scoped identity से छोटी होनी चाहिए जो एक read-only task के लिए है। इसे हर शुक्रवार strings बदलने की रस्म न बनाएं, जबकि scope जरूरत से ज्यादा व्यापक ही रहे।

एक साफ rotation statement कुछ ऐसा होना चाहिए: «इस request के लिए build agent के session ने credential record deploy-api-prod इस्तेमाल किया। यह record provider token ID के अंत में 4K2 से बदलकर P9M हो गया। नई credential से expected action पूरा होने के बाद पुराना token revoke किया गया।» इसमें token खुद नहीं होना चाहिए।

## Expiry से पहले secret को एक जगह रखें

जब credentials agent prompts, repository files, shell variables और copied configuration में पड़े हों, तब rotation को controlled नहीं बनाया जा सकता। Consolidation पहले करें, चाहे expiry date कितनी भी पास क्यों न हो।

ऐसी inventory से शुरू करें जो केवल storage नहीं, use को follow करे। हर team से पूछें कि agent कौन-सी external calls और SSH destinations कर सकता है। हर जवाब के लिए provider account या host account, credential type, owner, intended action, scope, expiry behavior और credential के दूसरी जगह दिखने की जानकारी लिखें। आखिरी field में असली परेशानी शुरू होती है।

Repository scan साफ गलतियां पकड़ सकता है, लेकिन absence साबित नहीं कर सकता। Environment variable names, configuration keys, deployment templates, copied private key paths और ऐसे documentation देखें जिसमें लोगों को agent configuration में token paste करने को कहा गया हो। Agent की tool definitions भी जांचें। अगर कोई tool `token`, `api_key`, `authorization` या raw private key content को argument के रूप में स्वीकार करता है, तो दूसरा system duplicate रखता हो तब भी agent secret अपने साथ ले जा सकता है।

HTTP के लिए intended shape सरल है: agent action और सामान्य request data देता है, जबकि gateway stored credential चुनता है और request भेजते समय authorization material जोड़ता है। Agent tool call में conceptually यह हो सकता है:

```json
{
  "credential": "deploy-api-prod",
  "method": "POST",
  "url": "https://api.example.internal/releases",
  "headers": {"Content-Type": "application/json"},
  "body": {"revision": "a81c2f"}
}
```

इसमें bearer token नहीं होना चाहिए, चाहे field का नाम कितना भी अच्छा क्यों न रखा गया हो। Tool result में authorization header लौटाना भी उलटी दिशा में वही गलती है। उसे बाद में chat transcript में redact करने के बजाय action boundary पर ही रोकें।

SSH के लिए agent को named credential record और destination के जरिए connection मांगना चाहिए। उसे private key blob, temporary private key file या `~/.ssh` खोजने का निर्देश नहीं मिलना चाहिए। Agent की working directory में private key caches, editor history, archives और कभी-कभी commit में भी बची रह सकती है। मैंने ऐसी files काफी साफ की हैं कि «temporary» शब्द का security में कोई अर्थ नहीं लगता।

Sallyport API keys और SSH keys को macOS app के encrypted vault में रखता है, फिर secret को agent के सामने लाए बिना HTTP और SSH actions चलाता है। इससे बदलने के लिए एक single record मिलता है, लेकिन move से पहले मौजूद पुरानी copies ढूंढकर हटाने की जरूरत खत्म नहीं होती।

## हर credential का एक owner और एक purpose रखें

Credential के कई legitimate users हो सकते हैं, फिर भी उसका एक जवाबदेह owner और एक स्पष्ट purpose होना चाहिए। Shared ownership अक्सर ऐसा विनम्र नाम है जिसका अर्थ होता है कि expiry, scope या retirement की जांच कोई नहीं कर रहा।

Records के नाम ऐसे रखें कि operator secret material देखे बिना authorization boundary पहचान सके। `billing-write-prod`, `token-final-2` से ज्यादा जानकारी देता है। `github-deploy-repo-a`, `automation-key` से बेहतर है। Target पर असर पड़ता हो तो environment शामिल करें, और जब credential किसी service function की हो तो उसमें व्यक्ति का नाम न डालें। लोग चले जाते हैं, service purpose समझ में आता रहना चाहिए।

Records की संख्या घटाने के लिए unrelated targets को एक shared token के पीछे न रखें। यह shortcut लोकप्रिय है क्योंकि एक renewal आसान लगता है। इससे तीन समस्याएं होती हैं:

1. आपको पता नहीं चलता कि rotation किस target की वजह से करनी पड़ी।
2. एक use के लिए scope बढ़ाने से बाकी सभी uses का access बढ़ जाता है।
3. Incident के दौरान identity revoke करने पर असंबंधित काम भी रुक जाता है।

एक record closely related actions के set को support कर सकता है, अगर provider account, scope और owner वास्तव में एक ही हों। इसे default नहीं, explicit decision मानें। Build publisher और support export job को अलग permissions चाहिए, तो दोनों एक ही API call करें तब भी उनकी identities अलग होनी चाहिए।

SSH में भी यही discipline चाहिए। एक host group के deployment account से जुड़ी SSH key को production database access की key न बनाएं, केवल इसलिए कि दोनों SSH इस्तेमाल करते हैं। जहां संभव हो server side पर restrictions लगाएं: dedicated account, constrained command, network में संभव हो तो source restriction और स्पष्ट authorized key comment। Comment access लागू नहीं करता, लेकिन दबाव के समय `authorized_keys` review करने पर बची हुई पुरानी key दिखाई दे जाती है।

OpenSSH का `authorized_keys` manual `command=`, `restrict` और `from=` जैसे options बताता है। ये options तभी उपयोगी हैं जब automation के exact command path को test किया जाए। मैंने देखा है कि अच्छी नीयत से लगाया गया `restrict` deployment job के जरूरी port forwarding को तोड़ देता है। Planned rotation में ऐसी गलती मिलना आधी रात को मिलने से बेहतर है। हर restriction अंधाधुंध न लगाएं, केवल वही लगाएं जो नामित action से मेल खाती हो।

## तय समाप्ति वाले overlap window का इस्तेमाल करें

पुरानी और नई credentials को साथ केवल उतनी देर active रखें जितनी replacement validate करने और failed cutover से recover करने के लिए जरूरी हो। Overlap safety device है, स्थायी operating mode नहीं।

कुछ providers कई API tokens या active client credentials की अनुमति देते हैं। पहले replacement बनाएं, ऐसा identifier लिखें जिसे सुरक्षित रूप से रखा जा सके और उसे gateway record में load करें। फिर उसी route से harmless action चलाएं जिसका agent सामान्य काम में इस्तेमाल करेगा। Read endpoint, test project में draft creation या caller identity लौटाने वाली request उपयोगी हो सकती है, बशर्ते action required scope और target account की जांच करे।

सिर्फ generic «token valid» endpoint पर निर्भर न रहें, अगर agent सामान्यतः releases publish करता या tickets बदलता है। Token valid हो सकता है, लेकिन उसमें write scope न हो, वह sandbox account की ओर point करता हो या gateway गलत header type जोड़ रहा हो। Harmless object के साथ वास्तविक method, URL family, account और payload shape test करें।

Test करने से पहले पुरानी credential के revocation time को तय करें। अगर आप वह समय बता नहीं सकते, तो आपके पास overlap window नहीं है। आपने एक और permanent credential बना दी है।

व्यावहारिक क्रम यह है:

1. Required scope और ज्ञात expiration policy के साथ नई provider credential बनाएं।
2. एकमात्र gateway record अपडेट करें और पिछली credential को केवल घोषित overlap तक रखें।
3. Authorized agent session या operator-controlled test session से एक सीमित action चलाएं।
4. Provider पर result verify करें और action journal में expected session और destination देखें।
5. पुरानी provider credential revoke या remove करें, फिर सीमित action एक बार और चलाएं।

Revocation के बाद का अंतिम test केवल औपचारिकता नहीं है। यह वह शर्मनाक स्थिति पकड़ता है जिसमें test चुपचाप पुराने token का इस्तेमाल कर रहा था, क्योंकि environment variable, proxy configuration या किसी दूसरे credential record को प्राथमिकता मिल गई थी। ऐसा failure लोग जितना मानते हैं, उससे ज्यादा होता है।

जिस provider में केवल एक active API credential की अनुमति हो, वहां वास्तविक overlap संभव नहीं है। Change window तय करें, switch से पहले baseline action capture करें, gateway में secret बदलें, तुरंत narrow test चलाएं और account owner को उपलब्ध रखें ताकि provider reject करे तो replacement जारी की जा सके। नए token को पहले से agent configuration में रखकर overlap की कमी को «solve» न करें।

## Agent जिस path का वास्तविक इस्तेमाल करता है, उसे validate करें

Rotation test में gateway, credential selection, request construction, remote authorization और result handling सभी शामिल होने चाहिए। हर component को अलग-अलग test करने से वही gaps बच जाते हैं जहां credential mistakes छिपती हैं।

HTTP में test request इतनी specific रखें कि provider logs में पहचानी जा सके। API support करे तो idempotency token इस्तेमाल करें, या साफ label वाला disposable object बनाएं। जांचें कि provider intended account या principal दिखा रहा है। फिर confirm करें कि action journal में credentials छापे बिना matching call, target, outcome और session reference दर्ज है।

Provider behavior अलग से देखने के लिए generic shell test उपयोगी है, लेकिन यह उतना साबित नहीं करता जितना लोग समझते हैं:

```sh
curl -sS -D /tmp/headers.txt \
  -H "Authorization: Bearer $NEW_TOKEN" \
  https://api.example.internal/v1/whoami
```

आमतौर पर `/tmp/headers.txt` में `200` status और body में service account की पहचान दिखेगी। इससे पता चलता है कि provider token स्वीकार करता है। यह साबित नहीं होता कि action gateway वही header जोड़ता है, सही record चुनता है या agent को `$NEW_TOKEN` देखने से रोकता है। इसे केवल operator के नियंत्रण में चलाएं और पूरा होने पर shell से variable हटा दें। असली token को ticket या saved terminal recording में कभी paste न करें।

SSH के लिए वही hostname, user और command shape test करें जिसकी automation को जरूरत है। यह public-key check server authorization की जांच में मदद करता है और output में private material नहीं दिखाता:

```sh
ssh -o BatchMode=yes -o IdentitiesOnly=yes \
  deploy@host.example.internal 'id \u0026\u0026 test -w /srv/releases \u0026\u0026 echo write-ok'
```

`BatchMode=yes` authentication failure पर interactive password का इंतजार करने के बजाय command को fail करता है। `IdentitiesOnly=yes` SSH client को agent में loaded हर unrelated key आजमाने से रोकता है। सफल `ssh deploy@host` login को deployment action के काम करने का proof न मानें। Remote account shell स्वीकार कर सकता है, लेकिन job में इस्तेमाल command, directory या forced-command restriction को reject कर सकता है।

OpenSSH का `ssh` manual बताता है कि `IdentitiesOnly` client द्वारा दी जाने वाली identities को सीमित करता है। यह developer machines पर मिलने वाले false green result को पकड़ता है: local agent authentication agent में रखी personal key से सफल हो जाता है, जबकि नई automation key production में fail होती। Gateway design में equivalent check gateway के SSH path से करें, जहां चुनी गई stored key स्पष्ट हो।

Success के साथ failure भी test करें। जानबूझकर unauthorized method वाली request या intended account की permission से बाहर SSH command आजमाएं। Remote system पर साफ denial और accurate journal entry दिखनी चाहिए। अगर supposedly narrow credential किसी unrelated action में सफल हो जाती है, तो rotation रोकें और पुरानी identity retire करने से पहले scope घटाएं।

## पुरानी public keys बची रहें तो SSH rotation server पर fail होती है

Vault में SSH private key बदलने से पुरानी key revoke नहीं होती। Server पुरानी identity तब तक स्वीकार करता रहता है जब तक उसकी public key को भरोसा करने वाले हर authorization source से हटाया न जाए।

SSH inventory कठिन है क्योंकि public keys कई जगह हो सकती हैं: `~/.ssh/authorized_keys`, identity management service, cloud instance metadata setting, configuration management template या provider का deploy-key interface। बदलाव से पहले authoritative source खोजें। अगर configuration management `authorized_keys` दोबारा लिखता है, तो emergency manual deletion अगली run में वापस आ सकती है।

Approved tooling से replacement identity बनाएं और उसका private half केवल gateway boundary पर रखें। नई public half को पुरानी के साथ install करें। हर entry में purpose और rotation date बताने वाला comment दें, फिर intended route से test करें। काम करने के बाद source of truth से पुरानी public entry हटाएं और confirm करें कि server उसे reject करता है।

Private key उजागर किए बिना public key fingerprint देख सकते हैं:

```sh
ssh-keygen -lf deploy-release-ed25519.pub
# 256 SHA256:exampleFingerprint deploy-release-2025 (ED25519)
```

Output का sample fingerprint से ज्यादा महत्व bit length, fingerprint, comment और key type का है। Actual fingerprint change record में रखें। Public key के आसपास के authorization options को अस्पष्ट screenshot में न रखें। Exact server-side rule को reviewed configuration में copy करें ताकि दूसरा operator देख सके कि उसमें forced command या source constraint है या नहीं।

फिर पुरानी key की आखिरी controlled copy नष्ट करने से पहले उससे negative test करें। Removal के बाद server को उसे reject करना चाहिए। अगर पुरानी private key न होने के कारण test नहीं कर सकते, तो authoritative authorized-key source और provider audit records देखें। Record में यह limitation लिखें। Revocation test करने का दिखावा करने से incomplete check को ईमानदारी से दर्ज करना बेहतर है।

SSH key को उसी path की file overwrite करके और किसी अनजान client को restart करके rotate न करें। Long-running processes connections खुली रख सकते हैं, SSH agents पुरानी identity दे सकते हैं और helper file descriptor cache कर सकता है। Stateless action helper इस ambiguity को घटाता है क्योंकि हर connection ज्ञात selection से शुरू होती है। महत्वपूर्ण property observable behavior है, कोई पसंदीदा implementation language नहीं।

## Authorization और rotation को अलग रखें

Agent को action चलाने की अनुमति और हर call में किसी खास credential के इस्तेमाल की अनुमति अलग बातें हैं। इन्हें एक ही control मानने से या तो approval fatigue पैदा होती है या sensitive identities जरूरत से ज्यादा खुली रहती हैं।

Session control पूछता है: «क्या यह अभी शुरू हुआ agent process इस run के दौरान actions कर सकता है?» यह किसी नए process को external access मिलने से पहले पकड़ने में मदद करता है। Per-call control पूछता है: «क्या इस खास credential का अभी इस्तेमाल किया जा सकता है?» Payment action, production release या ऐसी credential के लिए यह उचित है जिसके हर इस्तेमाल पर human judgment जरूरी हो।

सिर्फ इसलिए हर harmless status read के लिए human approval न मांगें कि credential rotation ने सबको चिंतित कर दिया है। लोग बार-बार आने वाले समान prompts को पढ़े बिना approve कर देते हैं। जिन identities के हर action पर judgment चाहिए, उनके लिए frequent approval रखें और बाकी के लिए साफ सीमाओं वाला session approval रखें। Rotation को operators को warnings पर click करते रहने की आदत नहीं बनानी चाहिए।

Sallyport का decision ladder vault gate को absolute रखता है, फिर default रूप से नए agent process को उसके session के लिए authorize करता है। साथ ही चुनी हुई credential के हर इस्तेमाल पर approval मांगने का विकल्प रहता है। Rotation के दौरान operator test session को अनुमति दे सकता है और cutover settled होने तक नई production credential पर explicit confirmation मांग सकता है।

Vault gate की भूमिका अलग है। Locked vault actions को deny करता है, भले agent session को पहले कुछ करने की permission मिली हो। Suspected leak या अचानक गलत व्यवहार करने वाले change के समय operator को इससे hard stop मिलता है। यह provider credential revoke नहीं करता। Access lock करने के बाद भी, अगर किसी ने credential copy की हो सकती है, तो external identity revoke या disable करें।

किसने exceptional production test approve किया और क्यों, इसका छोटा record रखें। Approval notes को diary न बनाएं। Session identity, समय, credential record, target और change reference approval को rotation event से जोड़ने के लिए पर्याप्त हैं।

## Audit evidence को दो अलग सवालों का जवाब देना चाहिए

अच्छा rotation record «agent ने क्या किया?» और «क्या हम record पर भरोसा कर सकते हैं?» दोनों सवालों का जवाब देता है। साधारण application log अक्सर किसी ने files edit की हों, line delete की हो या routine calls को incident के साथ मिला दिया हो तो इनमें से किसी का भी अच्छा जवाब नहीं देता।

पहले सवाल के लिए operational fields चाहिए: session identity, जहां उपलब्ध हो code-signing authority या process identity, समय, action type, target, credential record name, outcome और provider-side request reference। Journal में bearer tokens, passwords, private keys या secret-bearing request headers नहीं रखने चाहिए। Credentials वाले logs पढ़ने वाला हर व्यक्ति एक और credential holder बन जाता है।

दूसरा सवाल integrity का है। Append-only लिख देना पर्याप्त नहीं है, अगर administrator कल का log बदल सकता है। Hash chain हर entry को पिछली entry पर निर्भर बनाती है, इसलिए verifier chain check करके removal या alteration पकड़ सकता है। इससे यह साबित नहीं होता कि कोई action कभी हुआ ही नहीं और न ही false input सच बनता है। लेकिन original record के रूप में चुपचाप किए गए edits को पेश करना कठिन हो जाता है।

यहीं अलग session और activity journals उपयोगी होते हैं। Session journal बताता है कि किस agent process को authority मिली और किसी ने उस run को revoke किया या नहीं। Activity journal बताता है कि उसके दौरान कौन-से individual HTTP या SSH actions हुए। अगर API token 14:00 बजे rotate हुआ, तो cutover से पहले और बाद में record इस्तेमाल करने वाली calls देख सकते हैं, बिना हर session approval को हर request का proof माने।

Sallyport दोनों views encrypted, write-blind audit log से बनाता है और `sp audit verify` से vault key के बिना offline chain verify कर सकता है। Sensitive rotation से पहले और बाद में verification चलाएं और उसका result change record के साथ रखें। Successful verification बताता है कि recorded chain internally consistent है, लेकिन actual destinations और outcomes की review की जगह नहीं लेता।

High-risk rotation के लिए एक compact entry में यह evidence रखें:

- Credential क्यों बदली और authorization target का owner कौन है।
- पुरानी और नई provider credentials के safe identifiers और planned overlap end।
- Narrow validation action और उसका provider-side result।
- Validation में शामिल agent session और activity references।
- पुरानी identity के revocation का proof या documented limitation।

यह record बाद के investigator को normal planned change और unexplained new credential में फर्क करने देता है। इससे यह भी पता चल जाता है कि महीनों बीतने से पहले revocation check छूट गया था।

## Suspected leak को replacement से पहले containment मानें

जब शक हो कि agent ने secret देखा या export किया है, तो पहले access रोकें। Exposed token को disable किए बिना replacement token बनाना उस व्यक्ति के लिए पुराना रास्ता खुला छोड़ देता है जिसने उसे copy किया हो।

तुरंत local containment चाहिए तो action gateway lock करें, ऐसे active agent sessions revoke करें जिन्हें अब चलना नहीं चाहिए और provider credential disable या revoke करें। Cleanup jobs context मिटाने से पहले संबंधित session और activity evidence सुरक्षित रखें। फिर केवल जरूरी काम के scope वाली नई identity जारी करें।

Value leak होने का perfect proof मिलने का इंतजार न करें। Agent transcript, shell history, repository commit, build log या pasted chat में token मिलना exposure मानने के लिए पर्याप्त है। SSH private key के मामले में matching public key को हर trusted source से हटाएं और automation द्वारा artifacts लिखने वाली जगहों में private material की copies खोजें। पुरानी public key को authorized रखते हुए private key rotate करना containment नहीं है।

Service लौटने के बाद पता लगाएं कि secret boundary के बाहर कैसे गया। सामान्य कारण बहुत साधारण होते हैं: tool parameter ने raw credentials स्वीकार कीं, debug log ने request headers छाप दिए, developer ने local environment file agent workspace में copy कर दी या fallback client ने gateway को bypass कर दिया। Incident बंद करने से पहले उस route को ठीक करें। वरना replacement अगली leak की अपनी countdown शुरू कर देगा।

## Expiry work को scheduled operational test बनाएं

Calendar reminder को repeatable test, ownership check और revocation decision शुरू करना चाहिए। उसे किसी से उस configuration file में नया token paste करने की घबराई हुई request नहीं बनना चाहिए जो पिछली बार काम कर गई थी।

Provider expiry date से पहले हर credential record review करें। Confirm करें कि named owner अभी भी external account का owner है, documented purpose अभी मौजूद है, scopes action से मेल खाते हैं और चुने हुए agent sessions को अभी भी access चाहिए। इनमें से किसी का जवाब «नहीं» हो तो identity rotate करने के बजाय retire करें।

जरूरी identities के लिए narrow validation action पहले rehearse करें, ताकि provider account changes, नई SSH restrictions या बदली हुई API permissions समय रहते मिल सकें। Rehearsal का record actual rotation से अलग रखें, ताकि कोई पुराने successful test को आज के replacement के काम करने का proof न समझे।

सबसे असुविधाजनक test ही सबसे अधिक defects पकड़ता है: पुरानी credential revoke करने के बाद agent पर निर्भर exact action दोबारा चलाएं और verify करें कि journal इसे intended session और record से जोड़ता है। अगर test fail होता है, तो आपके पास owner, evidence और ज्ञात rollback path वाला contained failure है। यह उस स्थिति से कहीं बेहतर है जिसमें autonomous deployment के बीच expired credential का पता चलता है।