നിങ്ങളുടെ ഏജന്റ് തെറ്റായ രീതിയിൽ പ്രവർത്തിച്ചാൽ, അത് ചെയ്തത് ഏതാണെന്ന് നിങ്ങൾക്ക് അറിയാമോ?
ഒരു ഏജന്റ് തൊടാൻ പാടില്ലാത്ത ഒരു റെക്കോർഡ് ഡിലീറ്റ് ചെയ്യുന്നു. അത് തെറ്റായ ടെനന്റിന് (tenant) ഒരു സന്ദേശം അയക്കുന്നു. അത് ഒരു ലൂപ്പിൽ ഒരു API വിളിക്കുകയും നിങ്ങളുടെ ബില്ല് കുത്തനെ കൂട്ടുകയും ചെയ്യുന്നു.
ഒരു പ്രശ്നം (incident) സംഭവിച്ച് പത്ത് മിനിറ്റ് കഴിയുമ്പോൾ, നിങ്ങൾ ഒരു ചോദ്യം ചോദിക്കുന്നു: ഇത് ചെയ്തത് ഏത് ഏജന്റാണ്?
നിങ്ങൾക്ക് അത് അറിയില്ലെങ്കിൽ, നിങ്ങൾക്ക് അത് പരിഹരിക്കാൻ കഴിയില്ല. നിങ്ങൾക്ക് ബിൽഡ് (build) നിർത്താൻ കഴിയില്ല. നിങ്ങൾക്ക് പിശക് ഓഡിറ്റ് ചെയ്യാൻ കഴിയില്ല. നിങ്ങൾക്ക് ആ തെറ്റിൽ നിന്ന് പഠിക്കാൻ കഴിയില്ല.
ഇതൊരു ഐഡന്റിറ്റി (identity) പ്രശ്നമാണ്.
ഏജന്റുകളുടെ പ്രവർത്തനങ്ങളെ മറച്ചുവെക്കുന്ന മൂന്ന് രീതികൾ മിക്ക ടീമുകളും നേരിടുന്നുണ്ട്:
- ഷെയർഡ് സർവീസ് അക്കൗണ്ടുകൾ (Shared service accounts): പത്ത് ഏജന്റുകൾ ഒരേ ക്രെഡൻഷ്യലുകൾ (credentials) ഉപയോഗിക്കുന്നു. നിങ്ങളുടെ ലോഗുകളിൽ (logs) എല്ലാ പ്രവർത്തനങ്ങളും ഒരേപോലെ തോന്നും.
- ഹ്യൂമൻ ക്രെഡൻഷ്യലുകൾ (Human credentials): ഏജന്റ് നിങ്ങളുടെ ലോഗിൻ ഉപയോഗിക്കുന്നു. ലോഗുകളിൽ നിങ്ങളുടെ പേര് കാണിക്കുന്നു, ഏജന്റിന്റെ പേരല്ല. ഇത് വലിയൊരു സുരക്ഷാ ഭീഷണി ഉണ്ടാക്കുന്നു.
- സൈലന്റ് ഡ്രിഫ്റ്റ് (Silent drift): രണ്ട് വ്യത്യസ്ത ബിൽഡുകൾ ഒരേ പേര് ഉപയോഗിക്കുന്നു. ഒന്ന് പുതിയ മോഡലോ പുതിയ പ്രോംപ്റ്റോ ഉപയോഗിക്കുന്നുണ്ടാകാം, പക്ഷേ ലോഗുകളിൽ ഒരേ ഐഡന്റിറ്റി തന്നെ കാണിക്കുന്നു.
ഇത് പരിഹരിക്കാൻ, ഈ ഘട്ടങ്ങൾ പിന്തുടരുക:
ഓരോ ഏജന്റിനും സ്വന്തമായി ഒരു ഐഡന്റിറ്റി നൽകുക. ഹ്യൂമൻ ക്രെഡൻഷ്യലുകൾ ഉപയോഗിക്കരുത്. ഷെയർഡ് അക്കൗണ്ടുകൾ ഉപയോഗിക്കരുത്. ഏജന്റ് സ്വയം ഓതന്റിക്കേറ്റ് (authenticate) ചെയ്യണം.
ഓരോ പ്രവർത്തനത്തിലും ആറ് പ്രത്യേക ഫീൽഡുകൾ രേഖപ്പെടുത്തുക:
- Accountable party: ഈ ഏജന്റിന് ആരാണ് ഉത്തരവാദി?
- Operational owner: ഇത് ദിവസേന പരിപാലിക്കുന്നത് ആരാണ്?
- Tenant: ഇത് ഏത് ഉപഭോക്താവിനുള്ളതാണ്?
- Agent-type-id: ഇത് ഏത് പ്രത്യേക ബിൽഡ് ആണ്?
- Agent-instance-id: ഇത് ഏത് പ്രത്യേക റൺ (run) ആണ്?
- Trace context: കോൾ ചെയിനിൽ (call chain) ഇത് എവിടെയാണ്?
വേർഷനിംഗിനായി (versioning) ഹാഷുകൾ (hashes) ഉപയോഗിക്കുക. നിങ്ങളുടെ ഏജന്റിന് "support-agent-v2" എന്ന് പേര് നൽകരുത്. നിങ്ങൾ സിസ്റ്റം പ്രോംപ്റ്റ് മാറ്റിയാലും പേര് മാറില്ല, പക്ഷേ പെരുമാറ്റം മാറും. പകരം, ഒരു കണ്ടന്റ് ഹാഷ് (content hash) ഉപയോഗിക്കുക. കണ്ടെയ്നർ ഇമേജ്, പ്രോംപ്റ്റ്, മോഡൽ, കോൺഫിഗറേഷൻ എന്നിവയെ അടിസ്ഥാനമാക്കി ഒരു ഹാഷ് നിർമ്മിക്കുക. ഒരു വരി കോഡ് മാറ്റിയാൽ പോലും ഐഡി മാറും. ഇത് സൈലന്റ് ഡ്രിഫ്റ്റിനെ ദൃശ്യമാക്കുന്നു.
ലിനിയേജ് (lineage) രേഖപ്പെടുത്തുക. ഏജന്റുകൾ സബ്-ഏജന്റുകളെ (sub-agents) സൃഷ്ടിക്കുന്നു. ഏത് പാരന്റ് ഏജന്റാണ് സബ്-ഏജന്റിനെ ആരംഭിച്ചതെന്ന് നിങ്ങൾ രേഖപ്പെടുത്തണം. പാരന്റ് ഏജന്റ് സബ്-ഏജന്റിന് നൽകിയ പ്രോംപ്റ്റും നിങ്ങൾ രേഖപ്പെടുത്തണം. ഇൻജക്റ്റഡ് ഇൻസ്ട്രക്ഷനുകളോ (injected instructions) പോയിസൺഡ് ഡാറ്റയോ (poisoned data) കണ്ടെത്താനുള്ള ഏക വഴി ഇതാണ്.
ഐഡന്റിറ്റി നിങ്ങളുടെ റിക്കവറി സർഫേസ് (recovery surface) ആണ്. ഇത് ഒരു കിൽ സ്വിച്ച് (kill switch) ഉപയോഗിക്കാനും ഒരു ഓഡിറ്റ് ട്രയൽ (audit trail) നിർമ്മിക്കാനും നിങ്ങളെ അനുവദിക്കുന്നു. ഒരു പ്രശ്നം ഉണ്ടാകുന്നതിന് മുമ്പ് തന്നെ നിങ്ങൾ ഇത് സജ്ജീകരിക്കണം. ഒരു പ്രതിസന്ധി ഘട്ടത്തിൽ ഐഡന്റിറ്റി ചേർക്കുന്നത് വളരെ വൈകിപ്പോയിരിക്കും.
ഇപ്പോൾ തന്നെ നിങ്ങളുടെ ലോഗുകൾ പരിശോധിക്കുക. ഒരു മണിക്കൂർ മുമ്പുള്ള ഒരു പ്രവർത്തനം നോക്കുക. ആ പ്രവർത്തനം ചെയ്ത പ്രത്യേക ബിൽഡ് ഏതാണെന്ന് നിങ്ങൾക്ക് പറയാൻ കഴിയുമോ? ഇല്ലെങ്കിൽ, നിങ്ങൾ പരിഹരിക്കേണ്ട ഒരു വിടവ് (gap) അവിടെയുണ്ട്.
Source: https://dev.to/brennhill/when-your-agent-does-something-bad-can-you-tell-which-agent-did-it-37a2
Optional learning community: https://t.me/GyaanSetuAi