റീഡ്-ഓൺലി മാത്രം പോരാ: AI ഏജന്റുകൾക്കായി ഗാർഡ്‌റെയിലുകൾ (Guardrails)

സീനിയർ എഞ്ചിനീയർമാർ AI ഏജന്റുകളെ സുരക്ഷിതമായി നിലനിർത്താൻ പലപ്പോഴും ഒരു കാര്യം പറയാറുണ്ട്: അവർക്ക് റീഡ്-ഓൺലി (read-only) ആക്സസ് നൽകുക.

ഇത് സുരക്ഷിതമായി തോന്നാം. ഒന്നും നശിപ്പിക്കാതെ തന്നെ സ്ലോ ക്വറികൾ (slow queries) പരിശോധിക്കാനോ സ്കീമകൾ (schemas) സംഗ്രഹിക്കാനോ ഏജന്റിന് സാധിക്കും.

എന്നാൽ റീഡ്-ഓൺലി എന്നത് ഒരു സുരക്ഷാ മാതൃകയല്ല. അതൊരു പരിമിതി മാത്രമാണ്.

നിങ്ങളുടെ ഏജന്റിന് പ്രയോജനപ്രദമായ എന്തെങ്കിലും ജോലി ചെയ്യേണ്ടി വരുന്ന നിമിഷം, റീഡ്-ഓൺലി അത് തടയുന്നു. ഒരു മോശം ഇൻഡക്സോ (index) അല്ലെങ്കിൽ കേടുപാടുള്ള ഒരു റോവോ (corrupted row) ഏജന്റ് കണ്ടെത്തിയാൽ, അത് പരിഹരിക്കാൻ ഏജന്റിന് കഴിയില്ല. തീ പിടിച്ച സ്ഥലത്തേക്ക് വിരൽ ചൂണ്ടുന്നതല്ലാതെ, അത് അണയ്ക്കാൻ സഹായിക്കാൻ കഴിയാത്ത ഒരു അസിസ്റ്റന്റിനെപ്പോലെയായി അത് മാറും.

പലപ്പോഴും ടീമുകൾ ഇതിൽ നിന്ന് പിന്മാറുകയും ഏജന്റിന് റൈറ്റ് ആക്സസ് (write access) നൽകുകയും ചെയ്യുന്നു. അവിടെയാണ് യഥാർത്ഥ അപകടം തുടങ്ങുന്നത്.

"ഏജന്റ് എഴുതണോ വേണ്ടയോ" എന്നതല്ല യഥാർത്ഥ ചോദ്യം. "ആ എഴുത്തുകളെ നിങ്ങൾ എങ്ങനെ നിയന്ത്രിക്കുന്നു" എന്നതാണ് യഥാർത്ഥ ചോദ്യം.

നിർദ്ദേശങ്ങൾ (instructions) ഉപയോഗിച്ച് എഴുത്തുകളെ നിയന്ത്രിക്കാൻ ശ്രമിക്കരുത്. "ഒരിക്കലും ഒരു ടേബിൾ ഡ്രോപ്പ് ചെയ്യരുത്" (never drop a table) എന്നിങ്ങനെയുള്ള നിയമങ്ങൾ സിസ്റ്റം പ്രോംപ്റ്റിൽ (system prompt) ഉൾപ്പെടുത്തരുത്.

പ്രോംപ്റ്റ് ഇൻജക്ഷൻ (Prompt injection) ഇത്തരം നിയമങ്ങളെ ഉപയോഗശൂന്യമാക്കുന്നു. ഒരു അറ്റാക്കർക്ക് ഡാറ്റയിലെ ഒരു വരിയോ കമന്റോ ഉപയോഗിച്ച് നിങ്ങളുടെ നിയമങ്ങൾ അവഗണിക്കാൻ ഏജന്റിനെ പ്രേരിപ്പിക്കാൻ കഴിയും. ഗാർഡ്‌റെയിൽ ഏജന്റിനൊപ്പം ഒരേ വിൻഡോയിൽ തന്നെയാണെങ്കിൽ, ഏജന്റിന് അതിനെ മറികടക്കാൻ സാധിക്കും.

നിയന്ത്രണമില്ലാത്ത എഴുത്തുകളും (ungoverned writes) മധ്യസ്ഥതയുള്ള എഴുത്തുകളും (mediated writes) തമ്മിൽ വേർതിരിക്കേണ്ടതുണ്ട്.

• നിയന്ത്രണമില്ലാത്ത എഴുത്തുകൾ (Ungoverned writes): ഏജന്റ് ഒരു കമാൻഡ് പ്രവർത്തിപ്പിക്കാൻ തീരുമാനിക്കുന്നു, ഡാറ്റാബേസ് അത് നടപ്പിലാക്കുകയും ചെയ്യുന്നു. ഏജന്റിന്റെ സ്വന്തം വിവേചനാധികാരം മാത്രമാണ് ഇവിടെ ഏക നിയന്ത്രണം. • മധ്യസ്ഥതയുള്ള എഴുത്തുകൾ (Mediated writes): കമാൻഡ് ഏജന്റിന് പുറത്തുള്ള ഒരു ചെക്ക്പോയിന്റിലൂടെ കടന്നുപോകുന്നു. ഏജന്റും ഡാറ്റാബേസും തമ്മിലുള്ള ഡാറ്റ പാതയിൽ (data path) ഈ ചെക്ക്പോയിന്റ് സ്ഥിതി ചെയ്യുന്നു.

ഒരു മധ്യസ്ഥതയുള്ള എഴുത്ത് (mediated write) ഇപ്രകാരമാണ് പ്രവർത്തിക്കുന്നത്:

  • ഏജന്റ് ഒരു സ്റ്റേറ്റ്‌മെന്റ് നിർദ്ദേശിക്കുന്നു.
  • ഒരു പ്രോക്സി (proxy) അല്ലെങ്കിൽ കൺട്രോൾ പ്ലെയിൻ (control plane) ആ സ്റ്റേറ്റ്‌മെന്റ് വിശകലനം ചെയ്യുന്നു.
  • പ്രോക്സി റിസ്ക് തരംതിരിക്കുന്നു.
  • അത് അനുവദിക്കണോ അതോ ഒരു മനുഷ്യന്റെ അനുമതി തേടണോ എന്ന് പ്രോക്സി തീരുമാനിക്കുന്നു.

ഈ സമീപനം നിങ്ങളെ പ്രോംപ്റ്റ് ഇൻജക്ഷനിൽ നിന്ന് സംരക്ഷിക്കുന്നു. ഒരു ദുരുദ്ദേശ്യപരമായ നിർദ്ദേശം ഏജന്റിനെക്കൊണ്ട് ഒരു DROP TABLE കമാൻഡ് എഴുതിപ്പിക്കാൻ പ്രേരിപ്പിച്ചേക്കാം, എന്നാൽ അതിന് പ്രോക്സിയെ കബളിപ്പിക്കാൻ കഴിയില്ല. പ്രോക്സി ഏജന്റിന്റെ ഉദ്ദേശ്യം വായിക്കുന്നില്ല; അത് യഥാർത്ഥ SQL കമാൻഡ് മാത്രമേ പരിശോധിക്കുന്നുള്ളൂ.

സുരക്ഷിതമായിരിക്കാൻ ഈ ഘടന ഉപയോഗിക്കുക:

  • സുരക്ഷിതമായ റീഡുകൾ (reads) ഓട്ടോമാറ്റിക്കായി അനുവദിക്കുക. ജോലി വേഗത്തിലാക്കാൻ ഏജന്റുകളെ SELECT ക്വറികൾ സ്വതന്ത്രമായി പ്രവർത്തിപ്പിക്കാൻ അനുവദിക്കുക.
  • റിസ്കുള്ള എഴുത്തുകൾ നിയന്ത്രിക്കുക. DELETE, UPDATE അല്ലെങ്കിൽ സ്കീമ മാറ്റങ്ങൾക്കായി മനുഷ്യന്റെ അനുമതി ആവശ്യമാക്കുക.
  • എല്ലാം ലോഗ് ചെയ്യുക. ആര് മാറ്റം നിർദ്ദേശിച്ചു എന്നും ആര് അത് അംഗീകരിച്ചു എന്നും മാറ്റം വരുത്താനാവാത്ത (immutable) ഒരു റെക്കോർഡ് സൂക്ഷിക്കുക.

സുരക്ഷയ്ക്കായി റീഡ് റെപ്ലിക്കകളെ (read replicas) മാത്രം ആശ്രയിക്കരുത്. റെപ്ലിക്കകൾ പരിശോധനയ്ക്ക് സഹായിക്കും, എന്നാൽ അവയ്ക്ക് പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ കഴിയില്ല. ഒരു പ്രൊഡക്ഷൻ പ്രശ്നം പരിഹരിക്കാൻ, നിങ്ങൾ പ്രൈമറി ഡാറ്റാബേസിലേക്ക് (primary database) എഴുതണം.

മധ്യസ്ഥത (Mediation) നിങ്ങളുടെ ഡാറ്റ സുരക്ഷിതമായി നിലനിർത്തുന്നതോടൊപ്പം ഏജന്റിനെ പ്രയോജനപ്രദമായി ഉപയോഗിക്കാനും അനുവദിക്കുന്നു.

Source: https://dev.to/maxime_dalessandro_28171d/read-only-isnt-enough-guardrails-for-ai-agents-that-change-your-database-2e5h

Optional learning community: https://t.me/GyaanSetuAi