संज्ञांचा अर्थ
request path मध्ये असलेली कोणतीही check कधी कधी उत्तर देण्यात अपयशी ठरू शकते: dependency timeout होते, signal गायब असतो, key मिळवता येत नाही. Fail open म्हणजे check अस्तित्वातच नसल्याप्रमाणे request पुढे जाते. Fail closed म्हणजे request अधिक कडक मार्ग घेते: ती नाकारली जाते, आव्हान दिले जाते किंवा आधीपासून असलेल्या अधिक मजबूत control कडे पाठवली जाते.
साधारणपणे यापैकी कोणतेही नेहमीच बरोबर नसते. योग्य निवड route काय करते आणि चुकीच्या निर्णयाची किंमत किती आहे यावर अवलंबून असते.
actor checks साठी ते का महत्त्वाचे आहे
actor checks request ला संदर्भ देतात: interaction मानवी वाटतो का, AI-assisted आहे का, agent-driven आहे का, किंवा unknown आहे का. तो संदर्भ उपलब्ध नसल्यास, application ला तरीही प्रतिसाद द्यावा लागतो. दोन failure pattern सामान्य आहेत:
- चुकीने fail closed होणे. timeout किंवा हरवलेला signal संशयास्पद मानला जातो, आणि outage दरम्यान खरे user अडवले जातात.
- संवेदनशील कृतींवर चुकीने fail open होणे. हरवलेला result शांतपणे human म्हणून धरला जातो, आणि उच्च-परिणामाची कृती अपेक्षितपेक्षा कमी तपासणीसह पुढे जाते.
दोन्हीही निवड सूचकपणे सोडून दिल्यामुळे घडतात. उपाय म्हणजे ती निवड स्पष्टपणे, प्रत्येक route साठी, करणे. humans आणि AI agents साठी app-level policies कशा डिझाइन करायच्या या आमच्या लेखात failure behavior per-route policy मध्ये कसे बसते ते दाखवले आहे.
कसे निवडायचे
व्यावहारिक पद्धत म्हणजे routes ना risk tier मध्ये विभागणे:
- कमी परिणाम (public pages, documentation, read-only catalog routes): fail open. हरवलेल्या actor result मुळे काहीही बदलू नये.
- मध्यम परिणाम (signups, form submissions, खर्च असलेले searches): साधारणपणे logging सह fail open, किंवा standard rate limit सारखे सौम्य adaptation लागू करा.
- उच्च परिणाम (account बदल, data exports, परत न करता येणाऱ्या कृती): re-authentication किंवा confirmation सारख्या तुमच्या विद्यमान अधिक मजबूत control कडे fail closed करा. उद्देश block करणे नाही, तर तुम्ही तरीही वापरणार असलेल्या check कडे परत जाणे हा आहे.
मग संबंधित प्रकरणांसाठी तेच वर्तन ठरवा:
- Timeout: तपासणीने वेळेत उत्तर दिले नाही.
- Missing telemetry: integration चालली नाही किंवा signal अनुपस्थित होता.
- Unknown: तपासणी चालली, पण evidence ने निष्कर्षाला पाठिंबा दिला नाही.
- Stale evidence: result पूर्वीचा आहे आणि अधिक संवेदनशील कृतीसाठी पुन्हा वापरू नये.
सामान्य गैरसमज
- "Fail closed अधिक सुरक्षित आहे." त्यामुळे legitimate user वर खर्च येतो. कमी-परिणामाच्या routes साठी incident दरम्यान fail closed केल्याने टाळलेल्या जोखमीपेक्षा जास्त नुकसान होऊ शकते.
- "Unknown म्हणजे failure." Unknown हा वैध result आहे. त्यासाठी स्वतंत्र, स्पष्ट handling हवी, जी तुमच्या timeout handling शी जुळेलच असे नाही.
- "हरवलेला result म्हणजे human." evidence नसल्यामुळे actor class कधीही infer करू नका.
Proof of Actor याबाबत कसे वागते
Proof of Actor कधीही timeout किंवा Unknown result ला Human म्हणून नियुक्त करत नाही, आणि ते install केल्याने काहीही block होत नाही: teams observation mode मधून सुरुवात करतात. प्रत्येक route आणि risk tier साठी fail-open किंवा fail-closed वर्तन application owner निवडतो, आणि ते तुमच्या स्वतःच्या code मध्ये Route द्वारे लागू केले जाते. त्यामुळे enforcement predictable राहते आणि कोणतीही policy live होण्यापूर्वी तुम्ही outcomes तपासू शकता.
routing decisions कशा बसतात ते वाचा, किंवा early access साठी अर्ज करा.