AI Agent Secrets के लिए Secure Enclave और Touch ID

AI coding agent को ऐसी कार्रवाई का अनुरोध करने में सक्षम होना चाहिए, जिसे authorize करने वाला credential उसे कभी मिले ही नहीं। सुरक्षा का असली लक्ष्य यही है। Mac पर Secure Enclave और Touch ID इस लक्ष्य के एक हिस्से को लागू कर सकते हैं, लेकिन तभी जब secret ऐसी boundary के पीछे रहे जिसे agent पढ़ न सके।

Mac पर दिखने वाला यह prompt कि agent को «GitHub» access दिया जा सकता है, अपने-आप में security design नहीं है। कॉपी किया गया ghp_... token, export किया गया AWS_SESSION_TOKEN या tool call में paste की गई SSH private key agent को ऐसा स्थायी अधिकार देती है जिसे बाद का कोई Touch ID prompt वापस नहीं ले सकता। मुश्किल string को encrypt करना नहीं है। मुश्किल यह है कि उस string को ऐसे software को देने से इनकार किया जाए जो मनमाना text आगे भेज सकता है।

मैंने यह गलती कई रूपों में देखी है: .env में रखा token, password print करने वाला credential helper, container में mount की गई private key, और फिर agent को यह निर्देश कि «जो credentials उपलब्ध हों, उनका इस्तेमाल करो»। हर विकल्प अस्थायी लगता है। हर विकल्प secret को agent के working set का हिस्सा बना देता है।

Secure Enclave bearer token सौंपना सुरक्षित नहीं बनाता

Secure Enclave cryptographic operations की सुरक्षा कर सकता है, लेकिन किसी process द्वारा पढ़े जाने के बाद bearer token को harmless नहीं बना सकता। यही अंतर तय करता है कि Touch ID developer secret की रक्षा करता है या leak से पहले केवल औपचारिक prompt दिखाता है।

Apple Secure Enclave को ऐसे isolated hardware के रूप में बताता है जो private keys बना और इस्तेमाल कर सकता है, बिना उनका plaintext main processor के सामने लाए। इसकी documented restriction महत्वपूर्ण है: Secure Enclave private keys वहीं generate होती हैं, मौजूदा plaintext private keys import नहीं की जा सकतीं और केवल कुछ P-256 signing तथा key-agreement operations समर्थित हैं। API token इनमें से कोई private key नहीं है। यह आम तौर पर एक opaque string होता है, जिसे remote service प्रस्तुत करने वाले किसी भी व्यक्ति से स्वीकार कर सकती है। Apple Developer Documentation का «Protecting keys with the Secure Enclave» isolation और उसकी सीमाओं दोनों को स्पष्ट करता है।

लोग अक्सर तीन अलग objects को एक मान लेते हैं:

• Secure Enclave private key non-exportable key material है, जिसका इस्तेमाल सीमित cryptographic operations में होता है।
• Keychain item encrypted application data है, जिसकी access macOS सीमित कर सकता है।
• Bearer credential एक copyable value है, जो जहाँ भी service उसे स्वीकार करती है, access देती है।

इन तीनों को समान मानने से खराब designs बनते हैं। Secure Enclave key खुद को उजागर किए बिना challenge sign कर सकती है। Keychain item data लौटाने से पहले user presence मांग सकता है। Bearer token के bytes किसी process को मिलते ही वह सामान्य secret बन जाता है।

इसीलिए «हम token को Keychain में रखते हैं» agent के लिए पूरा उत्तर नहीं है। यह केवल at-rest storage का उत्तर है। यह नहीं बताता कि token के लिए कौन request कर सकता है, कौन-सी process उसे पाएगी, क्या वह उसे child process को भेज सकती है या stdout पर लिख सकती है।

Apple की Keychain guidance boundary को स्पष्ट करती है। Keychain Services item लौटाने से पहले authentication मांग सकती हैं और Secure Enclave biometric check के लिए केवल pass या fail परिणाम देती है। App और operating system, दोनों को fingerprint data नहीं मिलता। यह biometric template के लिए उत्कृष्ट सुरक्षा है। लेकिन authorized app बाद में लौटे हुए password bytes के साथ क्या करती है, इसके बारे में यह कुछ नहीं कहती।

Touch ID से ऐसी समस्या हल करने की कोशिश न करें, जो agent को secret देने के बाद पैदा हुई है।

बेहतर model में दो layers होती हैं। Vault process user के gate को पूरा करने के बाद credential retrieve या इस्तेमाल कर सकती है। Agent credential और destination का नाम देकर action request कर सकता है, लेकिन credential पढ़, बदल या किसी दूसरे tool से print नहीं कर सकता। Vault process HTTP request या SSH authentication खुद करती है और जानबूझकर सीमित result लौटाती है।

यह एक संकीर्ण interface है। यही इसका उद्देश्य भी है।

Boundary stdout और environment variables से पहले बननी चाहिए

Developer secrets encryption टूटने से बहुत पहले सामान्य plumbing के ज़रिए बाहर निकल जाते हैं। Environment variables, child-process inheritance, shell tracing, debug logs, crash reports, tool responses और copied terminal output protected secret को portable बना देते हैं।

मैं इस बारे में स्पष्ट हूँ, क्योंकि failure mode बहुत predictable है: अगर agent printenv चला सकता है, .env पढ़ सकता है, credential helper चला सकता है या MCP tool result के रूप में API key पा सकता है, तो उसके पास credential है। मूल storage Keychain, password manager या encrypted file में थी, इससे threat अब नहीं बदलता।

यह आम flow देखें:

Agent -> runs a shell command -> credential helper reads Keychain
      -> helper prints token -> shell captures stdout
      -> agent receives token -> token appears in context or logs

Keychain prompt ने शायद ठीक उसी तरह काम किया जैसा उसे करना था। System ने Mac user को authenticate किया। फिर helper ने protected item को text में बदल दिया और agent ने उसे उसी channel से पा लिया, जिसका इस्तेमाल compiler errors और test output के लिए होता है।

Design इसी क्षण विफल हो जाता है।

सुरक्षित credential path काफ़ी अलग दिखता है:

Agent -> requests "POST api.example.com/releases" using credential "release-bot"
      -> gateway asks for authorization if required
      -> gateway obtains or uses credential internally
      -> gateway sends HTTPS request with Authorization header
      -> agent receives status, selected headers, and response body

Agent को authenticated action का result मिलता है, authorization header नहीं। यह छोटा API choice लगता है। वास्तव में यही delegated execution और secret distribution के बीच की रेखा है।

यही नियम SSH पर भी लागू होता है। Agent को ~/.ssh/id_ed25519 का path, ऐसा SSH_AUTH_SOCK जो बिना दिखाई देने वाली boundary के arbitrary challenges sign कर सके, या secure store से key dump करने वाली command न दें। संकीर्ण scope वाला helper SSH connection स्थापित करे और requested command चलाए। stdout, stderr, exit status और host identity information लौटाएँ। Private key को agent की process tree से बाहर रखें।

इसका एक cost है। कुछ developer tools मानते हैं कि वे credentials सीधे पढ़ सकते हैं। Gateway approach का अर्थ है adapters, सीमित tool APIs और unusual authentication flows के आसपास कभी-कभी friction। मैं यह engineering cost एक बार देना पसंद करूंगा, बजाय इसके कि production token agent transcript में मिलने के बाद उसे rotate करना पड़े।

Encrypted disk को controlled execution path न समझें।

Touch ID presence साबित करता है, intent नहीं

Touch ID यह साबित कर सकता है कि किसी क्षण व्यक्ति ने gate को approve किया। यह साबित नहीं कर सकता कि व्यक्ति agent की अगली command समझता था, command repository के intent से मेल खाती है या destination सुरक्षित है।

Apple का LocalAuthentication framework app को जानबूझकर सीमित result देता है: framework Secure Enclave के साथ समन्वय करता है और success या failure लौटाता है। Calling app reason text देती है और authentication policy चुनती है। यह separation सही है। System को biometric event से application intent समझने का दिखावा नहीं करना चाहिए।

Agent work में Touch ID को capability के gate की तरह देखें, prose की approval की तरह नहीं। «इस agent को production credentials इस्तेमाल करने दें» जैसा card मानव को बहुत कम जानकारी देता है। Signed process, target host, credential label और approval एक call के लिए है या एक run के लिए, यह बताने वाला card मानव को उपयोगी निर्णय लेने देता है।

मैं तीन अलग authorization moments पसंद करता हूँ:

1. Vault unlock करें। Vault locked होने पर हर secret-backed action विफल हो। «Unprotected fallback इस्तेमाल करें» जैसी branch नहीं होनी चाहिए।
2. नए agent process को उसके run की अवधि के लिए approve करें। Approval को केवल node या python जैसे बदल सकने वाले process name की पहचान नहीं, बल्कि code-signing authority की पहचान करनी चाहिए।
3. ऐसे credentials के हर इस्तेमाल पर user presence मांगें जिनका प्रभाव irreversible हो, जैसे production deploy token, cloud owner role या fleet बदल सकने वाली SSH key।

Coding agents के लिए per-session approval सही default है। नया process एक meaningful boundary है: fresh launch में अलग binary, workspace, inherited environment variables या MCP configuration हो सकती है। Permanent approval बाद की कार्रवाइयों को ठीक उसी समय शांत कर देती है, जब उनकी provenance जांचना कठिन हो जाती है।

Per-call approval दुर्लभ रहनी चाहिए, लेकिन जहाँ credential व्यापक नुकसान कर सकता है वहाँ इसमें कोई ढील नहीं होनी चाहिए। केवल read-only issue tracker खोलने वाले token के हर GET के लिए fingerprint की जरूरत नहीं है। Production पर kubectl apply चला सकने वाले SSH credential के लिए है। इससे interruption पैदा होता है और यही interruption जानबूझकर रखा गया है।

लोकप्रिय विकल्प एक बड़ी policy file है: इस regular expression से मेल खाने वाली commands approve करें, allowlist में मौजूद domains को अनुमति दें, कुछ शब्दों वाले arguments को अस्वीकार करें। यह scalable लगता है, क्योंकि prompts की जगह automation आ जाती है। लेकिन इससे दूसरी programming language बन जाती है, जिसे shell quoting, redirects, wrappers, symlinks, curl --config, encoded payloads, remote command expansion और agent द्वारा install किए गए हर नए tool को समझना होगा।

मैं production authority ऐसी grammar के पीछे नहीं रखूंगा, जिसकी Friday के बाद कोई audit न करे।

इसके बजाय छोटी decision ladder रखें: locked या unlocked, यह run approved है या नहीं, इस credential को fresh approval चाहिए या नहीं। Incident review शुरू होने पर इन controls का अर्थ साफ़ दिखाई देता है।

Keychain access controls में सावधानी चाहिए

Biometric Keychain item तभी उपयोगी है, जब आप access constraint सोच-समझकर चुनें, उसका fallback behavior समझें और authorized process को secret dispenser बनने से रोकें।

Apple Keychain item से accessibility और authorization requirements जोड़ने के लिए SecAccessControlCreateWithFlags document करता है। ऐसे local developer secret के लिए जिसे backup या iCloud Keychain के ज़रिए migrate नहीं होना चाहिए, kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly आम तौर पर उचित storage class है। इसके लिए device passcode चाहिए और passcode हटने पर item unavailable हो जाता है। ThisDeviceOnly suffix item को दूसरे device पर transfer होने से भी रोकता है।

जिस secret के लिए biometric check अनिवार्य है, उसके लिए plain Keychain lookup के चारों ओर prompt लगाने के बजाय access-control flag इस्तेमाल करें। यह simplified Swift fragment ऐसा generic password store करता है जिसे केवल वर्तमान में enrolled biometric set release कर सकता है:

import Security

let access = SecAccessControlCreateWithFlags(
    kCFAllocatorDefault,
    kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
    .biometryCurrentSet,
    nil
)!

let item: [CFString: Any] = [
    kSecClass: kSecClassGenericPassword,
    kSecAttrService: "com.example.agent-gateway",
    kSecAttrAccount: "release-bot",
    kSecAttrAccessControl: access,
    kSecValueData: Data(token.utf8)
]

let status = SecItemAdd(item as CFDictionary, nil)
precondition(status == errSecSuccess)

biometryCurrentSet, biometryAny से अधिक strict है। यह access को वर्तमान enrolled fingerprints या face data से जोड़ता है, इसलिए enrolled biometric set बदलने पर protected item invalid हो जाता है। biometryAny किसी भी enrolled biometric को स्वीकार करता है और enrollment change का वही tripwire नहीं देता। Apple दोनों flags को SecAccessControlCreateFlags में सूचीबद्ध करता है। जब नया fingerprint deliberate reprovisioning को अनिवार्य करे, तब पहले flag को चुनें।

Retrieval के लिए authentication context और ऐसा operation prompt चाहिए जो operation को मानवीय भाषा में बताए:

import LocalAuthentication
import Security

let context = LAContext()
context.localizedReason = "Use release-bot for the requested deployment action"

let query: [CFString: Any] = [
    kSecClass: kSecClassGenericPassword,
    kSecAttrService: "com.example.agent-gateway",
    kSecAttrAccount: "release-bot",
    kSecReturnData: true,
    kSecMatchLimit: kSecMatchLimitOne,
    kSecUseAuthenticationContext: context,
    kSecUseOperationPrompt: "Authorize credential use"
]

var result: CFTypeRef?
let status = SecItemCopyMatching(query as CFDictionary, &result)

Code एक मामले में जानबूझकर अधूरा है: यह नहीं बताता कि result के साथ क्या करना है। सामान्य app इसे Data में cast कर सकती है, Authorization header बना सकती है और आगे बढ़ सकती है। Agent gateway को सुनिश्चित करना होगा कि data उसी process के भीतर रहे जो authenticated call करती है। इसे MCP response के ज़रिए return न करें। Temporary file में न रखें। Request विफल होने पर log न करें।

Reuse windows से सावधान रहें। Apple का sample दिखाता है कि Touch ID satisfaction हाल के device-unlock event को configured duration तक reuse कर सकता है, अधिकतम पाँच मिनट तक। सामान्य apps को duplicate prompts से बचाने के लिए यह सुविधा उपयोगी है। Agent control point पर यह deliberate approval के उस क्षण को मिटा सकती है जिसे आप अनिवार्य करना चाहते थे। हर-use credentials के लिए grace window न रखें, जब तक आपने इसे स्वीकार करने का conscious और documented निर्णय न लिया हो।

एक और सीमा भी ध्यान देने योग्य है। Biometrics fail हो सकते हैं, unavailable हो सकते हैं या failed attempts के बाद lock out हो सकते हैं। Apple ऐसी policies देता है जो device-passcode fallback की अनुमति देती हैं और ऐसी policies भी जो biometrics अनिवार्य करती हैं। तय करें कि आपके security claim को कौन-सी policy चाहिए। अगर आप कहते हैं «हर production deploy पर Touch ID», तो चुपचाप स्वीकार किया गया कोई अलग fallback path उस claim को बदल देता है और UI wording भी बदलनी चाहिए।

एक malicious instruction को वहाँ तक follow करें जहाँ वह जीतता है

Credential का दुरुपयोग करने के लिए agent को किसी dramatic exploit की जरूरत नहीं होती। एक भरोसेमंद लगने वाला instruction, एक broad capability और ऐसा output channel काफी है जो user की मंशा से अधिक लौटाता है।

मान लें कि coding agent pull request में मदद कर रहा है। वह attacker द्वारा जोड़ी गई repository document पढ़ता है। Document कहता है कि release check के लिए helper script चलानी होगी। Helper script developer के मौजूदा cloud CLI session का इस्तेमाल करती है, deployment credentials list करती है और encoded request external endpoint को भेजती है। Agent को shell commands चलाने की अनुमति है और उसे AWS_PROFILE, GH_TOKEN या SSH agent access विरासत में मिला है।

पहली failure script चलने से पहले हुई: developer ने agent को ambient credentials दिए। दूसरी failure तब हुई जब tool runner ने agent को arbitrary network destinations चुनने दिए। तीसरी तब हुई जब logs और command output ने authentication material या session details वापस agent context में भेज दिए।

Login के समय Touch ID इस design को नहीं बचाता। व्यक्ति ने शायद एक घंटे पहले authenticate किया था और फिर वहां से चला गया। केवल «device unlocked» से protected Keychain item ऐसी process के लिए उपलब्ध हो सकता है जिसे user ने इस task के लिए authorize करने का इरादा कभी नहीं किया। Apple खुद चेतावनी देता है कि unlocked-device access हर use case के लिए पर्याप्त restrictive नहीं हो सकता।

अब architecture बदलें। Agent इन fields के साथ action request करता है:

{
  "channel": "http",
  "credential": "release-bot",
  "method": "POST",
  "url": "https://api.example.com/releases",
  "body": {"branch": "feature/fix-ci"}
}

Gateway release-bot को internally resolve करता है। वह requested destination की तुलना होने वाली action से करता है, credential को approval चाहिए तो authorization मांगता है, header खुद inject करता है और फिर action record करता है। Agent को HTTP status और redacted response मिलता है। Header value कभी नहीं मिलती।

Repository document agent को खराब deployment request करने के लिए मना सकता है। इसलिए destination और action review महत्वपूर्ण हैं। लेकिन document agent को ऐसा token exfiltrate करने के लिए नहीं कह सकता जो उसके पास कभी था ही नहीं। Approved call खत्म होने के बाद वह token को किसी दूसरी service के विरुद्ध reuse भी नहीं कर सकता।

यह blast radius में वास्तविक कमी है, जादू नहीं। Deploy करने की approval वाले compromised agent से अब भी harmful deployment हो सकता है। System ने credential theft सीमित की है और action को attributable बनाया है। इसने malicious code review हल नहीं किया और human judgment को replace नहीं किया।

Agent setups की समीक्षा करते समय मैं देखता हूँ कि instruction secret string बनने की सबसे पहली जगह कौन-सी है। आम तौर पर fix वहीं होना चाहिए।

Capability handles secret strings से सुरक्षित हैं

Agent को structured action parameters के साथ named capability मांगनी चाहिए, जबकि trusted local process उस capability को credential में resolve करके side effect खुद करे।

«Capability» शब्द का इस्तेमाल अक्सर ढीले अर्थ में होता है। यहाँ इसका मतलब ऐसा reference है जो केवल gateway के भीतर उपयोगी हो, जैसे release-bot, staging-ssh या billing-read। यह ऐसा token alias नहीं है जिसे agent token के बदले exchange कर सके। यह ऐसा template variable भी नहीं है जो environment value में expand हो। यह केवल उस process को दिया गया selector है जिसके पास credential का exclusive access रहता है।

यह choice tool interface में discipline लाती है। HTTP tools को method, URL, agent द्वारा दिए जा सकने वाले safe headers और body स्वीकार करने चाहिए। Credential injection validation के बाद gateway के भीतर होना चाहिए। SSH tools को host, user, command और selected credential identity स्वीकार करनी चाहिए और authentication path के owner helper को invoke करना चाहिए। उन्हें IdentityFile path return नहीं करना चाहिए और generic «read secret» operation नहीं देना चाहिए।

यहीं boring interface जीतता है। हर developer credential inherit करने वाला general shell पहले दिन अधिक tools support करेगा। लेकिन यह बताना लगभग असंभव बना देगा कि किस agent ने किस account का इस्तेमाल किस outbound request के लिए किया। सीमित HTTP और SSH interface की शुरुआती range कम है, लेकिन वह security decision के लिए आवश्यक facts बचाए रखता है।

Sallyport इसी shape का पालन करता है: agent bundled sp mcp stdio shim से HTTP या SSH actions का अनुरोध करता है, जबकि app API और SSH credentials को अपने encrypted vault में रखती है और action खुद करती है। Agent को result मिलता है, plaintext credentials नहीं।

सीमा स्पष्ट है। केवल HTTP और SSH जानने वाला tool developer environment के हर desktop application, database client, package registry या local binary को अपने-आप cover नहीं करेगा। कोई channel जोड़ने से पहले उसके action model, redaction behavior, authorization semantics और audit fields design करने चाहिए। «मेरे login के साथ कुछ भी चलाओ» जैसा broad switch ship करना आसान और defend करना कठिन है।

ऐसे explicit credential labels रखें जो उनकी intended reach दिखाएँ। prod-deployer, token-4 से बेहतर है। github-readonly-org, github से बेहतर है। Label human decision और audit record का हिस्सा बनता है, इसलिए ambiguity केवल naming preference नहीं, operational problem बन जाती है।

Request format इतना सीमित रखें कि gateway उसे बिना interpretation के display कर सके। Reviewer POST https://api.example.com/releases समझ सकता है। Base64 blob को shell wrapper के ज़रिए pipe करने का प्रभाव reviewer विश्वसनीय ढंग से नहीं समझ सकता।

Audit trail action का वर्णन करे, secret की copy नहीं

Credential gateway को दो records चाहिए: authority पाने वाला agent run और उसके द्वारा attempted प्रत्येक side effect। Terminal logs की एक stream दोनों चीजें नहीं दे सकती, जब तक वह context न खोए या sensitive material leak न करे।

जब नया agent process access मांगता है, तब run record करें। Gateway को उपलब्ध process identity, code-signing authority, start time, approval decision और revocation state capture करनी चाहिए। User run revoke करे तो process alive रहने पर भी बाद की requests fail होनी चाहिए।

हर action अलग record करें। HTTP के लिए credential label, method, destination, status, timing और body का सावधानी से चुना गया summary रखें। SSH के लिए credential label, host, remote user, command, exit code और timing रखें। Authorization headers, bearer values, private-key bytes, customer data वाले full request bodies या unrestricted command output record न करें।

Secrets वाले logs, बदतर access controls वाला दूसरा vault बन जाते हैं।

Tamper evidence महत्वपूर्ण है, क्योंकि agent incident अक्सर disputed timeline से शुरू होता है: «क्या agent ने इस endpoint को call किया था?» «क्या session approved था?» «क्या किसी ने local history edit की?» Hash-chained event log बाद में verification के लिए concrete object देता है। Verifier को हर event decrypt किए बिना काम करना चाहिए, वरना integrity जाँचने वाले व्यक्ति को पहले वही sensitive data देना पड़ेगा जिसे log सुरक्षित रखने वाला था।

Sallyport अपने Sessions और Activity journals को एक write-blind encrypted, hash-chained audit log से project करता है और sp audit verify vault key के बिना chain को offline check करता है। यह उपयोगी है, क्योंकि integrity review के लिए developer secrets का access आवश्यक नहीं होना चाहिए।

Hash chain compromised machine को bad action करने से नहीं रोकती। यह recorded sequence को चुपचाप rewrite करना कठिन बनाती है और investigation को events का consistent क्रम देती है। इसे prevention के रूप में बढ़ा-चढ़ाकर न बताएं।

Apple Platform Security और Apple Developer Security documentation यहाँ उपयोगी हैं, क्योंकि वे hardware protections, system controls और application responsibilities को अलग-अलग रखते हैं। Agent security को ठीक यही separation चाहिए। Secure hardware access को gate कर सकता है, लेकिन network पर क्या भेजना है और disk पर क्या लिखना है, यह app अब भी चुनती है।

Production access के लिए कम paths चाहिए, अधिक smart guesses नहीं

AI coding agents के लिए सबसे सुरक्षित rollout छोटे set of named credentials, known destinations, visible session identity और एक ऐसे irreversible action class से शुरू होता है जिसे fresh approval चाहिए। Broad ambient access outage के दौरान अपना threat model खोजने का निमंत्रण है।

Agent को credential छूने देने से पहले यह review करें:

1. सुनिश्चित करें कि agent secret को environment variables, files, credential helper, tool output या child process के ज़रिए नहीं पढ़ सकता।
2. सुनिश्चित करें कि trusted process HTTP request या SSH authentication खुद करती है और agent द्वारा structured parameters भेजने के बाद credential inject करती है।
3. Vault lock को हर secret-backed action deny करने के लिए configure करें। इसे app locked होने पर test करें, केवल Mac screen locked होने पर नहीं।
4. नया agent process शुरू होने पर fresh session approval मांगें और approval में उसकी signing authority दिखाएँ।
5. Deployment, administrative, destructive या broad SSH reach वाले credentials के लिए every-use authorization रखें।

खराब स्थितियों को test करें। Nonproduction credential में canary-agent-secret-9f31 जैसा fake secret जोड़ें। Agent से repository inspect करने, tests चलाने और tool output report करने को कहें। फिर उसके transcript, terminal history, temporary directories, logs, child-process environment और audit records में उस exact string को खोजें। अगर वह vault process के बाहर कहीं दिखाई देती है, तो design ने agent को secret path दे दिया है।

Revocation के लिए भी यही करें। Run approve करें, एक harmless request करें, process खुली रहने के दौरान run revoke करें और वही request फिर करें। दूसरी request remote service तक पहुँचने से पहले fail होनी चाहिए। Restart के बाद ही प्रभावी होने वाला revocation control paperwork है, containment नहीं।

Biometric prompt को credential export के चारों ओर decoration की तरह इस्तेमाल न करें। Prompt उस boundary पर रखें जहाँ human किसी specific process या action को authorize करता है और credential को protected side पर रखें। इसी तरह Secure Enclave और Touch ID AI coding agents के लिए उपयोगी controls बनते हैं, storage के बारे में केवल reassuring कहानी नहीं।