എന്താണ് LLM സുരക്ഷ? OWASP Top 10 സുരക്ഷാ അപകടസാധ്യതകൾ എങ്ങനെ ലഘൂകരിക്കാം

ആക്രമണകാരിയുടെ നിർദ്ദേശങ്ങളെ കമാൻഡുകളായി പരിഗണിക്കാൻ AI-യെ കബളിപ്പിക്കുന്ന ആക്രമണമായ പ്രോംപ്റ്റ് ഇൻജക്ഷൻ, 2023 മുതലുള്ള എല്ലാ പതിപ്പുകളിലും LLM ആപ്ലിക്കേഷനുകൾക്കായുള്ള OWASP Top 10-ൽ ഒന്നാം സ്ഥാനത്താണ്.

AI സുരക്ഷാ രംഗത്ത് ഒരു പൊതുസമവായത്തോട് ഏറ്റവും അടുത്തുനിൽക്കുന്നത് ഈ പട്ടികയാണ്. ഒരു ചെറിയ കൂട്ടം സുരക്ഷാ വിദഗ്ധരിൽ നിന്ന് ആരംഭിച്ച ഈ പ്രോജക്റ്റ് ഇന്ന് 18-ലധികം രാജ്യങ്ങളിൽ നിന്നുള്ള 600-ലധികം സംഭാവകരായ വിദഗ്ധരുടെ അറിവ് പ്രയോജനപ്പെടുത്തുന്നു.

AI-യെ എങ്ങനെയെല്ലാം പറഞ്ഞുവശത്താക്കാൻ കഴിയും എന്നതിനെക്കുറിച്ചുള്ള ഒരു ഗൈഡ് പ്രസിദ്ധീകരിക്കുന്ന ഒരു AI കമ്പനിയാണ് ഞങ്ങൾ, അതിനാൽ ഈ പ്രശ്നം പരിഹരിക്കപ്പെട്ടു എന്ന് നടിക്കാൻ ഞങ്ങൾ ഉദ്ദേശിക്കുന്നില്ല. OWASP പ്രോജക്റ്റിന്റെ സഹ-നേതൃത്വം വഹിക്കുന്ന Wilson നിലവിലെ പ്രതിരോധങ്ങളെക്കുറിച്ച് വളരെ വ്യക്തമായി പറഞ്ഞു: “...സത്യം പറഞ്ഞാൽ, നമ്മൾ 99%-ൽ എത്തിയിട്ടുണ്ടെന്ന് ഞാൻ കരുതുന്നില്ല.”

2026 പതിപ്പും ഇതേ സന്ദേശത്തോടെയാണ് ആരംഭിക്കുന്നത്. “കബളിപ്പിക്കാൻ കഴിയാത്ത ഒരു മോഡൽ നിർമ്മിക്കാൻ ശ്രമിക്കുന്നത് നിർത്തുക” എന്നും, കബളിപ്പിക്കപ്പെട്ട ഒരു മോഡലിന് പ്രധാനപ്പെട്ട ഒന്നും തകർക്കാൻ കഴിയാത്ത വിധം ചുറ്റുമുള്ള സിസ്റ്റം രൂപകൽപ്പന ചെയ്യണമെന്നും പ്രോജക്റ്റ് ലീഡ് നമ്മോട് പറയുന്നു.

OWASP-ന്റെ 2026 പട്ടികയിലെ 10 അപകടസാധ്യതകളിലുടനീളം ഞങ്ങൾ ഇതേ നിലപാടാണ് സ്വീകരിക്കുന്നത്.

LLM സുരക്ഷ എന്നാൽ എന്താണ്?

ആക്രമണങ്ങളിൽ നിന്നും ദുരുപയോഗത്തിൽ നിന്നും AI മോഡലുകളെയും അവ ഉപയോഗിക്കുന്ന ആപ്ലിക്കേഷനുകളെയും സംരക്ഷിക്കുന്നതിനെയാണ് LLM സുരക്ഷ എന്ന് പറയുന്നത്. മോഡൽ എന്തിനോടെല്ലാം ബന്ധിപ്പിച്ചിരിക്കുന്നു എന്നതിനനുസരിച്ച് അപകടസാധ്യതയും വർദ്ധിക്കുന്നു: അതിന് വായിക്കാൻ കഴിയുന്ന ഫയലുകളും ഡാറ്റയും, ഇമെയിൽ, സെർച്ച്, അല്ലെങ്കിൽ ഒരു കമ്പനി ഡാറ്റാബേസ് പോലെ അതിന് ഉപയോഗിക്കാൻ കഴിയുന്ന ടൂളുകളും.

ശരിയായി സുരക്ഷിതമാക്കിയ സോഫ്റ്റ്‌വെയറിൽ, ഒരു പ്രോഗ്രാം പിന്തുടരുന്ന നിർദ്ദേശങ്ങൾക്കും അത് പ്രോസസ്സ് ചെയ്യുന്ന വിവരങ്ങൾക്കും ഇടയിൽ വ്യക്തമായ ഒരു അതിർവരമ്പുണ്ട്. എന്നാൽ LLM-കൾക്ക് അത്തരമൊരു അതിർവരമ്പില്ല.

മോഡൽ വായിക്കുന്നതെല്ലാം ഒരൊറ്റ നീണ്ട ടെക്സ്റ്റ് പ്രവാഹമായാണ് എത്തുന്നത്: ഡെവലപ്പറുടെ നിർദ്ദേശങ്ങൾ, നിങ്ങളുടെ ചോദ്യം, അത് തിരഞ്ഞുനോക്കിയ ഒരു വെബ്‌പേജ്. ആരാണ് സംസാരിക്കുന്നത് എന്ന് AI മോഡലുകൾ ട്രാക്ക് ചെയ്യേണ്ടതുണ്ട്—അത് ഡെവലപ്പറാണോ, ഉപയോക്താവാണോ, അതോ ഒരു പ്രശ്നത്തെക്കുറിച്ച് ചിന്തിക്കുന്ന മോഡൽ തന്നെയാണോ എന്ന്.

എന്നാൽ ഗവേഷകരായ Jasmine Cui-യും Charles Ye-യും കണ്ടെത്തിയത്, ടെക്സ്റ്റിന്റെ ശൈലിയും സ്വരവും നോക്കിയാണ് ആരാണ് സംസാരിക്കുന്നതെന്ന് മോഡലുകൾ മിക്കവാറും ഊഹിക്കുന്നത് എന്നാണ്. അതിനാൽ, മോഡലിന്റെ സ്വന്തം ചിന്താഗതി പോലെ തോന്നിക്കുന്ന എന്തെങ്കിലും ഒരു ആക്രമണകാരി എഴുതിയാൽ, ആ ആശയം താൻ തന്നെ കണ്ടെത്തിയതാണെന്ന് മോഡൽ വിശ്വസിച്ചേക്കാം. ആരാണ് നിയന്ത്രണത്തിലുള്ളതെന്ന് മോഡൽ അറിയുന്നതിനെ ആശ്രയിക്കുന്ന ഏതൊരു സുരക്ഷാ സംവിധാനത്തിനും അതൊരു പ്രശ്നമാണ്.

ഞങ്ങളുടെ സ്വന്തം AI ഏജന്റുകളിലും ഞങ്ങൾ ഇതേ പ്രശ്നം നേരിട്ടിട്ടുണ്ട്. “സിസ്റ്റം പ്രോംപ്റ്റിൽ ചേർത്താലും ഏജന്റുകൾ നയങ്ങൾ പാലിച്ചേക്കില്ല” എന്ന് ഞങ്ങളുടെ CISO ആയ Kyle Polley ISMG-യോട് പറഞ്ഞു. അതുകൊണ്ടാണ് ഞങ്ങൾ Numbat നിർമ്മിച്ചത്—ഒരു ഏജന്റ് എന്താണ് ചെയ്യാൻ പോകുന്നതെന്ന് പരിശോധിക്കുകയും, ആ പ്രവർത്തനം കോൺഫിഗർ ചെയ്ത ഒരു സുരക്ഷാ നിയമം ലംഘിക്കുന്നുണ്ടെങ്കിൽ അത് തടയുകയും ചെയ്യുന്ന ഒരു ഓപ്പൺ സോഴ്‌സ് ടൂളാണിത്.

മോഡൽ ചിലപ്പോൾ തെറ്റായ ആളിൽ നിന്ന് ഉത്തരവുകൾ സ്വീകരിക്കുമെന്ന് അംഗീകരിക്കുകയും, അങ്ങനെ സംഭവിക്കുമ്പോഴും ഉറച്ചുനിൽക്കുന്ന AI ഗാർഡ്‌റെയിലുകൾ അതിന് ചുറ്റും സ്ഥാപിക്കുകയും ചെയ്യുന്നതാണ് LLM സുരക്ഷ.

LLM സുരക്ഷയ്ക്കുള്ള മികച്ച രീതികൾ ഏതൊക്കെയാണ്?

LLM ആപ്ലിക്കേഷനുകൾക്കായുള്ള OWASP Top 10 2026 ഞങ്ങൾ ക്രമത്തിൽ, ഒന്നാം നമ്പർ മുതൽ പത്താം നമ്പർ വരെ, പരിശോധിക്കും.

ഓരോ അപകടസാധ്യതയ്ക്കും, കാര്യങ്ങൾ എങ്ങനെ തെറ്റായി പോകുന്നു എന്നതിന്റെ ലളിതമായ വിശദീകരണവും ഒരു യഥാർത്ഥ ഉദാഹരണവും നിങ്ങൾക്ക് ലഭിക്കും. തുടർന്ന്, അത് തടയാൻ സഹായിക്കുന്ന, അല്ലെങ്കിൽ കുറഞ്ഞപക്ഷം നാശനഷ്ടം പരിമിതപ്പെടുത്താൻ സഹായിക്കുന്ന രീതികൾ ഞങ്ങൾ വിശദീകരിക്കും.

1. പ്രോംപ്റ്റ് ഇൻജക്ഷൻ നിയന്ത്രിക്കുക

AI പിന്തുടരാൻ പാടില്ലാത്ത നിർദ്ദേശങ്ങൾ ഒരു ആക്രമണകാരി അതിനെക്കൊണ്ട് പിന്തുടരിപ്പിക്കുമ്പോഴാണ് പ്രോംപ്റ്റ് ഇൻജക്ഷൻ സംഭവിക്കുന്നത്. ആ നിർദ്ദേശങ്ങൾ ഒരു ചാറ്റിൽ നേരിട്ട് വരാം, അല്ലെങ്കിൽ ഒരു ഇമെയിലിലോ വെബ്‌പേജിലോ ഡോക്യുമെന്റിലോ ഒളിപ്പിച്ചുവെച്ചിരിക്കാം.

രണ്ടാമത്തെ തരം പരോക്ഷ പ്രോംപ്റ്റ് ഇൻജക്ഷൻ എന്നാണ് അറിയപ്പെടുന്നത്. ഒരു ഡോക്യുമെന്റ് സംഗ്രഹിക്കാൻ നിങ്ങൾ നിങ്ങളുടെ അസിസ്റ്റന്റിനോട് ആവശ്യപ്പെടുന്നു. നിങ്ങളുടെ സ്വകാര്യ ഫയലുകൾ തങ്ങൾക്ക് അയച്ചുകൊടുക്കാൻ അവർ അസിസ്റ്റന്റിനോട് പറഞ്ഞിട്ടുണ്ട്. അസിസ്റ്റന്റ് ആ നിർദ്ദേശങ്ങൾ പിന്തുടർന്നാൽ, ഡോക്യുമെന്റ് എഴുതിയ വ്യക്തി ഫലത്തിൽ നിങ്ങളുടെ ആക്‌സസ് കടമെടുത്തിരിക്കുന്നു.

സുഷിരങ്ങളുള്ള ഒരു കല്ലിലെ ദ്വാരങ്ങൾ അടയ്ക്കുന്നതിനോടാണ് പ്രോംപ്റ്റ് സുരക്ഷയെ PCMag ഉപമിക്കുന്നത്. ഒരു ദ്വാരം അടയ്ക്കുമ്പോൾ, വെള്ളം മറ്റൊന്ന് കണ്ടെത്തുന്നു. “ഒരു ആക്രമണം വഴി കണ്ടെത്തുന്നു; അത് പരിഹരിക്കപ്പെടുന്നു, എന്നാൽ LLM-കൾ പോലുള്ള സിസ്റ്റങ്ങൾ എത്രമാത്രം ചലനാത്മകമാണ് എന്നതുകൊണ്ട് മാത്രം, ഇനിയും കണ്ടെത്താനുള്ള എണ്ണമറ്റ മറ്റ് ആക്രമണ മാർഗ്ഗങ്ങൾ ബാക്കിനിൽക്കുന്നു.”

ഉദാഹരണം: 2025 ജൂണിൽ, Aim Security ഗവേഷകർ EchoLeak കണ്ടെത്തി—സ്വകാര്യ കമ്പനി വിവരങ്ങൾ ചോർത്താൻ Microsoft 365 Copilot-നെ കബളിപ്പിച്ച ഒരു പിഴവായിരുന്നു അത്. ഒരു ജീവനക്കാരൻ ജോലി സംബന്ധമായ ഒരു സാധാരണ ചോദ്യം ചോദിച്ചപ്പോൾ, Copilot-ന് ആ ഇമെയിൽ എടുക്കാനും അതിനുള്ളിൽ ഒളിപ്പിച്ച നിർദ്ദേശങ്ങൾ പിന്തുടരാനും സെൻസിറ്റീവ് വിവരങ്ങൾ ആക്രമണകാരിക്ക് അയയ്ക്കാനും കഴിയുമായിരുന്നു. ദുരുദ്ദേശ്യപരമായ നിർദ്ദേശങ്ങൾ കണ്ടെത്താനും സംശയാസ്പദമായ ലിങ്കുകൾ നീക്കം ചെയ്യാനും ഉദ്ദേശിച്ചുള്ള പരിശോധനകളെ ഈ ആക്രമണം മറികടന്നു.

നിങ്ങൾക്ക് ചെയ്യാവുന്നത്:

• Meta-യുടെ “രണ്ടിന്റെ നിയമം” (Rule of Two) പിന്തുടരുക: കമ്പനി ഡാറ്റ വായിക്കാനും പുറത്തുനിന്നുള്ള ഇമെയിൽ വായിക്കാനും വിവരങ്ങൾ പുറത്തേക്ക് അയയ്ക്കാനും കഴിയുന്ന ഒരു AI ആണ് EchoLeak-ന് ആവശ്യമായിരുന്നത്—അതിന് ഈ മൂന്ന് കഴിവുകളും ഉണ്ടായിരുന്നു. അവയിൽ രണ്ടെണ്ണമായി അതിനെ പരിമിതപ്പെടുത്തുന്നത്, ഒരു പ്രോംപ്റ്റ് ഇൻജക്ഷൻ അമിതമായ നിയന്ത്രണം നേടുന്നത് തടയുന്നു. ടാസ്കിന് മൂന്നും ആവശ്യമാണെങ്കിൽ, ഓരോ പ്രവർത്തനത്തിനും മുമ്പ് മനുഷ്യന്റെ അംഗീകാരം നിർബന്ധമാക്കുക.
• നിങ്ങളുടെ പ്രതിരോധങ്ങൾ അറിയുന്ന ആക്രമണകാരികൾക്കെതിരെ പരീക്ഷിക്കുക: നിങ്ങൾ ഏർപ്പെടുത്തിയ നിയമങ്ങളും ഫിൽട്ടറുകളും നിങ്ങളുടെ സുരക്ഷാ പരിശോധകർക്ക് നൽകുക, എന്നിട്ട് അവയെ മറികടക്കാൻ അവരെ അനുവദിക്കുക. ഒരു പഠനത്തിൽ, പ്രതിരോധങ്ങൾക്കനുസരിച്ച് തന്ത്രം മാറ്റിയ ആക്രമണകാരികൾ, പരീക്ഷിച്ച 12 പ്രതിരോധങ്ങളിൽ മിക്കതിനെതിരെയും 90%-ലധികം തവണ വിജയിച്ചു.

2. സെൻസിറ്റീവ് വിവരങ്ങൾ ചോരുന്നത് തടയുക

കാണാൻ പാടില്ലാത്ത ആളുകൾക്ക് AI സിസ്റ്റങ്ങൾ സ്വകാര്യ വിവരങ്ങൾ നൽകുന്നതിനെ സെൻസിറ്റീവ് വിവരങ്ങളുടെ വെളിപ്പെടുത്തൽ എന്ന് വിളിക്കുന്നു. ഒരു ഉപഭോക്താവിന്റെ പേയ്‌മെന്റ് വിവരങ്ങൾ വെളിപ്പെടുത്തുന്നതോ സ്വകാര്യ സംഭാഷണങ്ങൾ ഒരു പങ്കിട്ട ഡാറ്റാബേസിൽ ഉപേക്ഷിക്കുന്നതോ ഇതിൽ ഉൾപ്പെടാം.

പല ചോർച്ചകളും “അമിതമായ പങ്കുവെക്കലിൽ” നിന്നാണ് ആരംഭിക്കുന്നത്. അയഞ്ഞ അനുമതികളുള്ള ഡ്രൈവുകളിലേക്കും നോളജ് ബേസുകളിലേക്കും ഒരു കമ്പനി അതിന്റെ AI ബന്ധിപ്പിക്കുന്നു എന്ന് കരുതുക. രൂപകൽപ്പന ചെയ്തതുപോലെ തന്നെ, AI അതിന് എത്തിപ്പെടാൻ കഴിയുന്നതെല്ലാം വീണ്ടെടുക്കുന്നു. ആർക്കും അതിക്രമിച്ചു കടക്കേണ്ടതില്ല, എന്നിട്ടും LLM-ന്റെ സുരക്ഷ തകർക്കപ്പെട്ടതായി തന്നെ കണക്കാക്കുക.

ഉദാഹരണം: 2025 ജനുവരിയിൽ, Wiz ഗവേഷകർ ഇന്റർനെറ്റിൽ തുറന്നുകിടക്കുന്ന ഒരു DeepSeek ഡാറ്റാബേസ് കണ്ടെത്തി; ചാറ്റ് ചരിത്രവും, മറ്റ് സേവനങ്ങൾ ആക്‌സസ് ചെയ്യാൻ സോഫ്റ്റ്‌വെയർ ഉപയോഗിക്കുന്ന API കീകളും ഉൾപ്പെടെ ഒരു ദശലക്ഷത്തിലധികം ലോഗ് എൻട്രികൾ അതിലുണ്ടായിരുന്നു. എന്തെങ്കിലും വെളിപ്പെടുത്താൻ മോഡലിനെ പ്രേരിപ്പിക്കേണ്ട ആവശ്യം പോലും ഗവേഷകർക്ക് ഉണ്ടായില്ല.

നിങ്ങൾക്ക് ചെയ്യാവുന്നത്:

• AI ഡാറ്റ വായിക്കുന്നതിന് മുമ്പ് ആക്‌സസ് പരിശോധിക്കുക: ചോദ്യം ചോദിക്കുന്ന വ്യക്തിക്ക് ഏതൊക്കെ ഡോക്യുമെന്റുകൾ കാണാൻ അനുവാദമുണ്ടെന്ന്, അവ മോഡലിന് കൈമാറുന്നതിന് മുമ്പ് നിങ്ങളുടെ ആപ്ലിക്കേഷൻ പരിശോധിക്കണം.
• നിങ്ങളുടെ AI അവശേഷിപ്പിക്കുന്ന രേഖകൾ സംരക്ഷിക്കുക: ആക്റ്റിവിറ്റി ലോഗുകൾ സേവ് ചെയ്യുന്നതിന് മുമ്പ് സ്വകാര്യ വിശദാംശങ്ങളും രഹസ്യ കീകളും നീക്കം ചെയ്യുക, ലോഗിൻ നിർബന്ധമാക്കുക, അവ ആവശ്യമുള്ള ആളുകൾക്ക് മാത്രമായി ആക്‌സസ് പരിമിതപ്പെടുത്തുക. ആ രേഖകൾ അനിശ്ചിതമായി കുമിഞ്ഞുകൂടാതിരിക്കാൻ ഒരു നിലനിർത്തൽ കാലയളവ് നിശ്ചയിക്കുക.

3. അമിതമായ പ്രവർത്തനാധികാരം നിയന്ത്രിക്കുക

അമിതമായ പ്രവർത്തനാധികാരമുള്ള AI-കൾക്ക് അവയുടെ ജോലിക്ക് ആവശ്യമായതിലും കൂടുതൽ അധികാരമുണ്ട്: അവയ്ക്ക് ആവശ്യമില്ലാത്ത ടൂളുകൾ, അവയുടെ ടാസ്കിന് അപ്പുറമുള്ള അനുമതികൾ, അല്ലെങ്കിൽ പരിശോധന കൂടാതെ പ്രവർത്തിക്കാനുള്ള സ്വാതന്ത്ര്യം. ഇവിടെ കാരണം പ്രസക്തമല്ല.

ഒരു ഇൻജക്ഷൻ പ്രോംപ്റ്റോ, ഒരു ബഗോ, അല്ലെങ്കിൽ വെറുതെ തെറ്റ് പറ്റുന്ന ഒരു മോഡലോ—എല്ലാം ഒരേ ഫലത്തിലേക്കാണ് നയിക്കുന്നത്. AI-ക്ക് അതിനുള്ള ശേഷി ഉണ്ടെങ്കിൽ, എപ്പോഴെങ്കിലും അത് വിനാശകരമായ എന്തെങ്കിലും ചെയ്യും.

ഉദാഹരണം: 2025 ജൂലൈയിൽ, മാറ്റങ്ങൾ വരുത്തരുതെന്ന് നിർദ്ദേശം നൽകിയിട്ടും Replit-ന്റെ കോഡിംഗ് ഏജന്റ് 1,206 എക്സിക്യൂട്ടീവ് റെക്കോർഡുകളുള്ള തന്റെ ഡാറ്റാബേസ് ഡിലീറ്റ് ചെയ്തു എന്ന് SaaStr സ്ഥാപകൻ Jason Lemkin റിപ്പോർട്ട് ചെയ്തു. ഡാറ്റ പുനഃസ്ഥാപിക്കാൻ കഴിയില്ലെന്ന് ഏജന്റ് ആദ്യം പറഞ്ഞെങ്കിലും, പിന്നീട് വീണ്ടെടുക്കൽ സാധ്യമാണെന്ന് തെളിഞ്ഞു. ഡാറ്റാബേസിൽ തൊടരുതെന്ന് പറഞ്ഞതുകൊണ്ട് അത് ഡിലീറ്റ് ചെയ്യാനുള്ള ഏജന്റിന്റെ കഴിവ് ഇല്ലാതായില്ലെന്ന് Jason മനസ്സിലാക്കി.

വലുതാക്കുക

ഉറവിടം: X

നിങ്ങൾക്ക് ചെയ്യാവുന്നത്:

• ടാസ്കിന് ആവശ്യമില്ലാത്ത കഴിവുകൾ നീക്കം ചെയ്യുക: ഒരു ഏജന്റിന് ലഭിക്കുന്ന ടൂളുകളും ആ ടൂളുകൾക്ക് ചെയ്യാൻ കഴിയുന്ന കാര്യങ്ങളും പരിമിതപ്പെടുത്തുക. ഇമെയിലുകൾ സംഗ്രഹിക്കുന്ന ഒരു അസിസ്റ്റന്റിന് അവ വായിക്കാനുള്ള അനുമതി മതി, അവ അയയ്ക്കാനോ ഡിലീറ്റ് ചെയ്യാനോ ഉള്ള അനുമതി ആവശ്യമില്ല.
• അനുമതി പരിശോധനകൾ AI-യുടെ പുറത്ത് സ്ഥാപിക്കുക: ഓരോ തവണയും ഒരു പ്രവർത്തനം അഭ്യർത്ഥിക്കപ്പെടുമ്പോൾ, അത് നിങ്ങളുടെ സുരക്ഷാ നിയമങ്ങളുമായി ഒത്തുനോക്കി പരിശോധിക്കുകയും, ഒരു വ്യക്തിയുടെ അംഗീകാരം നിർബന്ധമാക്കുകയും ചെയ്യുക.

4. നിങ്ങളുടെ AI സപ്ലൈ ചെയിനിലേക്ക് എന്താണ് പ്രവേശിക്കുന്നതെന്ന് പരിശോധിക്കുക

വളരെ കുറച്ച് കമ്പനികൾ മാത്രമാണ് AI പൂർണ്ണമായും സ്വന്തമായി നിർമ്മിക്കുന്നത്, ഓരോ വർഷവും അവയുടെ എണ്ണം കുറഞ്ഞുവരികയാണ്. Menlo Ventures-ന്റെ 2025 The State of Generative AI in the Enterprise സർവേ അനുസരിച്ച്, 2024-ൽ 53% കമ്പനികൾ AI മോഡലുകൾ വാങ്ങി, 2025-ൽ ഇത് 76% ആയി വർദ്ധിച്ചു.

മിക്കപ്പോഴും, കമ്പനികൾ Hugging Face പോലുള്ള ഹബ്ബുകളിൽ നിന്ന് മോഡലുകൾ ഡൗൺലോഡ് ചെയ്യുകയും, മറ്റുള്ളവർ ശേഖരിച്ച ഡാറ്റാസെറ്റുകളിൽ അവയെ കൂടുതൽ പരിശീലിപ്പിക്കുകയും, അപരിചിതർ എഴുതിയ ആഡ്-ഓണുകളും കോഡ് പാക്കേജുകളും അവയിൽ ചേർക്കുകയും ചെയ്യുന്നു.

ഈ ഓരോ ഭാഗവും അകത്തേക്കുള്ള ഒരു വഴിയാണ്. അവയിലൊന്നിൽ കൃത്രിമം നടന്നാൽ, ആ പ്രശ്നം നിങ്ങളുടെ ഉൽപ്പന്നത്തിനുള്ളിൽ തന്നെ ഉപയോക്താക്കളിലേക്ക് എത്തുന്നു.

ഉദാഹരണം: 2026 ജനുവരിക്കും 2026 ഓഗസ്റ്റിനും ഇടയിൽ Hugging Face-ന്റെ പൊതു മോഡൽ റിപ്പോസിറ്ററികൾ 2.43 ദശലക്ഷത്തിൽ നിന്ന് 2.96 ദശലക്ഷമായി വളർന്നു. എന്നാൽ 2026 ജൂലൈയിൽ, ആന്തരിക സുരക്ഷാ പരിശോധനയ്ക്കിടെ OpenAI-യുടെ മോഡലുകൾ, അവയെ ഇന്റർനെറ്റിൽ നിന്ന് അകറ്റിനിർത്താൻ ഉദ്ദേശിച്ചുള്ള നിയന്ത്രണങ്ങളെ മറികടക്കുകയും Hugging Face-ന്റെ സിസ്റ്റങ്ങളുടെ ചില ഭാഗങ്ങളിലേക്ക് അതിക്രമിച്ചു കടക്കുകയും ചെയ്തു. വാസ്തവത്തിൽ, ഒരു ഏജന്റ് പൊതുവായി വെളിപ്പെട്ടിരുന്ന 14 ആക്‌സസ് ക്രെഡൻഷ്യലുകൾ കണ്ടെത്തുകയും, അവ പ്രവർത്തിക്കുന്നുണ്ടോയെന്ന് പരിശോധിക്കുകയും, മറ്റ് ഏജന്റുകളുമായി പങ്കിടുകയും ചെയ്തു. തുടർന്ന്, Hugging Face-ന്റെ സെർവറുകളിൽ കോഡ് പ്രവർത്തിപ്പിക്കാൻ അനുവദിക്കുന്ന പിഴവുകൾ ഏജന്റുകൾ ചൂഷണം ചെയ്തു.

“ഒരു മോഡലിന്റെ ജീവിതചക്രത്തിലുടനീളം അലൈൻമെന്റിന് ഞങ്ങൾ കൂടുതൽ കർശനമായ ആവശ്യകതകൾ ഏർപ്പെടുത്തുകയും, കൂടുതൽ ഒറ്റപ്പെട്ട സാൻഡ്‌ബോക്സുകൾ സൃഷ്ടിക്കുകയും, ഇന്റർനെറ്റ് ആക്‌സസ് നിയന്ത്രിക്കുകയും, മോഡൽ വെയ്റ്റുകളിലേക്കുള്ള ആക്‌സസ് കൂടുതൽ നിയന്ത്രിക്കുകയും ചെയ്യുന്നു,” എന്ന് OpenAI റിപ്പോർട്ട് പറയുന്നു.

നിങ്ങൾക്ക് ചെയ്യാവുന്നത്:

• മോഡലുകളെ ഒരു നിശ്ചിത പതിപ്പിലേക്ക് പിൻ ചെയ്ത് അവ പരിശോധിച്ചുറപ്പിക്കുക: ഓരോ മോഡലിനെയും അവലോകനം ചെയ്ത ഒരു പതിപ്പിലേക്ക് പിൻ ചെയ്യുകയും, ലോഡ് ചെയ്യുന്നതിന് മുമ്പ് അതിന്റെ ഫയൽ ഫിംഗർപ്രിന്റ് പരിശോധിക്കുകയും ചെയ്യുക, അങ്ങനെയാകുമ്പോൾ മാറ്റിവെച്ച ഒരു ഫയലിന് അതേ ലേബലിൽ ഒളിച്ചുകടക്കാൻ കഴിയില്ല. OWASP ഡിജിറ്റൽ സിഗ്നേച്ചറുകളും ശുപാർശ ചെയ്യുന്നുണ്ട്, ഒരു മുന്നറിയിപ്പോടെ—ഒരു മോഡൽ എവിടെ നിന്ന് വന്നു എന്ന് മാത്രമാണ് സിഗ്നേച്ചർ തെളിയിക്കുന്നത്, അത് സുരക്ഷിതമാണെന്നല്ല.
• നിങ്ങളുടെ AI നിർദ്ദേശിക്കുന്ന ഓരോ പാക്കേജും പരിശോധിക്കുക: ഒരു AI അസിസ്റ്റന്റ് ശുപാർശ ചെയ്ത കോഡ് പാക്കേജ് ഇൻസ്റ്റാൾ ചെയ്യുന്നതിന് മുമ്പ്, അത് നിലവിലുണ്ടെന്നും, നിങ്ങൾ ഉദ്ദേശിച്ച പാക്കേജ് തന്നെയാണെന്നും, നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന പ്രസാധകനിൽ നിന്നാണ് വരുന്നതെന്നും ഉറപ്പാക്കുക.

5. ഡാറ്റയും മോഡലും വിഷലിപ്തമാക്കുന്നതിനെതിരെ ജാഗ്രത പുലർത്തുക

വിഷലിപ്തമാക്കപ്പെട്ട ഒരു AI കേടായ ഡാറ്റയിൽ നിന്നാണ് പഠിക്കുന്നത്. അത് ഫൈൻ-ട്യൂൺ ചെയ്യാൻ ഉപയോഗിച്ച ഉദാഹരണങ്ങളോ, ഉത്തരങ്ങൾക്കായി അത് തിരയുന്ന ഒരു നോളജ് ബേസോ ആകാം. മോഡൽ അപ്പോഴും പ്രവർത്തിക്കുന്നതായി തോന്നും; അത് തെറ്റായ പാഠങ്ങൾ പഠിക്കുന്നു എന്ന് മാത്രം, ചിലപ്പോൾ ഒരു പ്രത്യേക ട്രിഗർ വാചകം കാണുമ്പോൾ മാത്രം മോശമായി പെരുമാറാനും അത് പഠിക്കുന്നു.

ആരെങ്കിലും ആ വാചകം ഉപയോഗിക്കുന്നതുവരെ, നിങ്ങൾ നടത്തുന്ന എല്ലാ പരിശോധനകളിലും അത് വിജയിക്കും.

വലുതാക്കുക

മാത്രമല്ല, ഇത് പഴയപടിയാക്കുന്നത് വളരെ ബുദ്ധിമുട്ടാണ്. പാച്ച് ചെയ്ത് പരിഹരിക്കാൻ കഴിയുന്ന ഒരു ബഗ് അല്ല വിഷലിപ്തമാക്കൽ. നിങ്ങളുടെ ഡാറ്റ തെറ്റാണെങ്കിൽ, നിങ്ങൾക്ക് അത് വീണ്ടും പരിശോധിക്കുകയോ, മോഡൽ വീണ്ടും പരിശീലിപ്പിക്കുകയോ, അല്ലെങ്കിൽ അത് പൂർണ്ണമായും മാറ്റിസ്ഥാപിക്കുകയോ ചെയ്യേണ്ടി വന്നേക്കാം.

ഉദാഹരണം: 2025 ഒക്ടോബറിൽ, Anthropic, UK AI Security Institute, Alan Turing Institute എന്നിവിടങ്ങളിലെ ഗവേഷകർ, ഒരു പ്രത്യേക ട്രിഗർ കാണുമ്പോഴെല്ലാം അർത്ഥശൂന്യമായ വാചകങ്ങൾ സൃഷ്ടിക്കാൻ 250 വിഷലിപ്തമാക്കിയ ഡോക്യുമെന്റുകൾക്ക് ഒരു മോഡലിനെ പഠിപ്പിക്കാൻ കഴിയുമെന്ന് തെളിയിച്ചു. ഏറ്റവും വലിയ മോഡൽ 20 മടങ്ങിലധികം ശുദ്ധമായ ഡാറ്റയിൽ പരിശീലിപ്പിക്കപ്പെട്ടിരുന്നിട്ടും, പരീക്ഷിച്ച നാല് മോഡൽ വലുപ്പങ്ങളിലും ഇതേ എണ്ണം ഫലപ്രദമായി.

നിങ്ങൾക്ക് ചെയ്യാവുന്നത്:

• നിങ്ങളുടെ ഡാറ്റ എവിടെ നിന്ന് വരുന്നു എന്ന് ട്രാക്ക് ചെയ്യുക: നിങ്ങൾ ഉപയോഗിക്കുന്ന ഓരോ ഡാറ്റാസെറ്റിന്റെയും മോഡലിന്റെയും, ഓരോന്നും എവിടെ നിന്ന് വന്നു എന്നതിന്റെയും, പതിപ്പുകൾക്കിടയിൽ എന്ത് മാറ്റം വന്നു എന്നതിന്റെയും രേഖ സൂക്ഷിക്കുക. ഡാറ്റാസെറ്റുകൾക്ക് വേർഷൻ കൺട്രോൾ ഉപയോഗിക്കാൻ ഞങ്ങൾ ശുപാർശ ചെയ്യുന്നു, അതുവഴി വിഷലിപ്തമാക്കൽ കണ്ടെത്തിയാൽ, നിങ്ങൾക്ക് ഒരു ശുദ്ധമായ പതിപ്പിലേക്ക് തിരികെ പോകാനും അത് എങ്ങനെ കടന്നുകൂടി എന്ന് കണ്ടെത്താനും കഴിയും.
• ബാക്ക്ഡോറുകൾക്കായി പരിശോധിക്കുക: ഒരു ആക്രമണകാരി മോഡലിൽ സ്ഥാപിക്കുന്ന, ഒരു പ്രത്യേക വാചകമോ മറ്റ് ട്രിഗറോ അതിനെ സജീവമാക്കുന്നതിനായി കാത്തിരിക്കുന്ന, മറഞ്ഞിരിക്കുന്ന ഒരു പെരുമാറ്റമാണ് “ബാക്ക്ഡോർ”. മോഡലിനെക്കൊണ്ട് അതിന്റെ സാധാരണ നിയമങ്ങൾ ലംഘിപ്പിക്കാൻ രൂപകൽപ്പന ചെയ്ത ഇൻപുട്ടുകൾ ഉപയോഗിച്ച് ഇവ പരിശോധിക്കുക.

6. പരിധിയില്ലാത്ത ഉപഭോഗത്തിന് പരിധി നിശ്ചയിക്കുക

AI-കൾക്ക് എത്ര ജോലി ചെയ്യാം അല്ലെങ്കിൽ എത്ര ചെലവ് വരുത്താം എന്നതിന് യാതൊരു പരിധിയും ഇല്ലാതിരിക്കുമ്പോൾ, അവയുടെ ഉപഭോഗം “പരിധിയില്ലാത്തത്” ആയി കണക്കാക്കപ്പെടുന്നു. ഭൂരിഭാഗം AI സേവനങ്ങളും ഓരോ ഉപയോഗത്തിനും നിരക്ക് ഈടാക്കുന്നതിനാൽ, ഒരു ആക്രമണകാരിക്ക് നിങ്ങളുടെ ബിൽ കുത്തനെ ഉയർത്താനോ നിങ്ങളുടെ മോഡലിന്റെ ഒരു പകർപ്പ് നിർമ്മിക്കാനോ കഴിയും.

OWASP ഈ അടിസ്ഥാന പ്രശ്നത്തെ “ചെലവിലെ അസന്തുലിതാവസ്ഥ” എന്ന് വിളിക്കുന്നു. ചെറുതും ചെലവ് കുറഞ്ഞതുമായ ഒരു അഭ്യർത്ഥന നിങ്ങളുടെ ഭാഗത്ത് ചെലവേറിയ കമ്പ്യൂട്ടേഷന് കാരണമായേക്കാം.

ഉദാഹരണം: 2024 മെയ് മാസത്തിൽ, Sysdig-ന്റെ Threat Research Team “LLMjacking” എന്ന പുതിയൊരു ആക്രമണം കണ്ടെത്തി. ഒരു കൂട്ടം ആക്രമണകാരികൾ മോഷ്ടിച്ച ക്രെഡൻഷ്യലുകൾ ഉപയോഗിച്ച് ക്ലൗഡിൽ ഹോസ്റ്റ് ചെയ്ത 10 LLM സേവനങ്ങളെ ലക്ഷ്യമിട്ടു. Laravel-ന്റെ സുരക്ഷാ ദൗർബല്യമുള്ള ഒരു പതിപ്പിലൂടെ അവർ അകത്തുകടന്നു, തുടർന്ന് ആക്‌സസ് വിൽക്കുക എന്ന വ്യക്തമായ ലക്ഷ്യത്തോടെ, ആ ക്രെഡൻഷ്യലുകൾ ഉപയോഗിച്ച് എന്തൊക്കെ ചെയ്യാമെന്നും ഏതൊക്കെ ക്വാട്ടകളുണ്ടെന്നും അവർ കണ്ടെത്തി. കണ്ടെത്തപ്പെടാതിരിക്കാനാകണം, നിരവധി ലോഗിംഗ് ക്രമീകരണങ്ങളും അവർ പരിശോധിച്ചു. Sysdig പറയുന്നതനുസരിച്ച്, ഏറ്റവും മോശം സാഹചര്യത്തിൽ ഇരയ്ക്ക് പ്രതിദിനം $46,000-ലധികം ചെലവ് വന്നേക്കാം.

നിങ്ങൾക്ക് ചെയ്യാവുന്നത്:

• ചെലവ് തടയുന്ന ബജറ്റുകൾ നിശ്ചയിക്കുക: വ്യക്തിഗത ഉപയോക്താക്കൾ, API കീകൾ, ടീമുകൾ, മൊത്തം അക്കൗണ്ട് എന്നിവയ്ക്ക് കർശനമായ ചെലവ് പരിധികൾ ഏർപ്പെടുത്തുക. അഭ്യർത്ഥനകൾ പ്രവേശിക്കാൻ സാധ്യതയുള്ള എല്ലായിടത്തും അവ നടപ്പിലാക്കുക.
• ഓരോ ടാസ്കിനും നിർത്തേണ്ട ഒരു ഘട്ടം നിശ്ചയിക്കുക: ഒരു ടാസ്കിന് എത്ര നേരം പ്രവർത്തിക്കാം, എത്രത്തോളം ടെക്സ്റ്റ് പ്രോസസ്സ് ചെയ്യാനും സൃഷ്ടിക്കാനും കഴിയും, എത്ര ടൂൾ കോളുകൾ നടത്താം എന്നിവ പരിമിതപ്പെടുത്തുക. ആവർത്തിച്ചുകൊണ്ടിരിക്കുന്നതോ അനുവദനീയമായ പരിധി കവിയുന്നതോ ആയ ഏജന്റുകൾക്കായി ഓട്ടോമാറ്റിക് കട്ടോഫുകൾ ചേർക്കുക.

7. നടപടിയെടുക്കുന്നതിന് മുമ്പ് തെറ്റായ വിവരങ്ങൾ കണ്ടെത്തുക

ശരിയാണെന്ന് തോന്നിക്കുന്ന തെറ്റായ എന്തെങ്കിലും AI സൃഷ്ടിക്കുകയും, ആരെങ്കിലുമോ എന്തെങ്കിലുമോ അതിനെ ആശ്രയിച്ച് പ്രവർത്തിക്കുകയും ചെയ്യുമ്പോൾ, അതിനെ തെറ്റായ വിവരങ്ങൾ എന്ന് വിളിക്കുന്നു. തെറ്റായ ഉത്തരം എന്നതിലുപരി, ആ തെറ്റായ ഉത്തരം വിശ്വസിക്കപ്പെടുകയും ഉപയോഗിക്കപ്പെടുകയും ചെയ്യുന്നു എന്നതാണ് പ്രധാന അപകടസാധ്യത.

തെറ്റായ വിവരങ്ങളെക്കുറിച്ച് പ്രാക്ടീഷണർമാർ വേണ്ടത്ര ആശങ്കപ്പെട്ടിരുന്നില്ലെന്നാണ് സംഭവങ്ങളുടെ രേഖകൾ സൂചിപ്പിക്കുന്നത്. 2026 പതിപ്പിന്റെ ആമുഖ കത്ത് അനുസരിച്ച്, വോട്ടർമാർ ഇതിന് പട്ടികയുടെ താഴ്ഭാഗത്തോട് അടുത്ത സ്ഥാനമാണ് നൽകിയത്, എന്നാൽ യഥാർത്ഥ സംഭവങ്ങൾ പ്രകാരം ഇത് മുൻനിരയോട് അടുത്താണ്.

ഉദാഹരണം: 2025-ൽ, A$440,000-ന്റെ ഒരു സർക്കാർ കരാർ പ്രകാരം Deloitte Australia ക്ഷേമ IT സിസ്റ്റങ്ങളുടെ ഒരു അവലോകനം സമർപ്പിച്ചു. University of Sydney-യിലെ ഗവേഷകനായ Chris Rudge നിലവിലില്ലാത്ത ഗവേഷണങ്ങളിലേക്കുള്ള പരാമർശങ്ങൾ കണ്ടെത്തി; ഒരു ഫെഡറൽ കോടതി വിധിയിൽ നിന്നുള്ള കെട്ടിച്ചമച്ച ഒരു ഉദ്ധരണിയും അദ്ദേഹം കണ്ടെത്തി. തങ്ങളുടെ രീതിശാസ്ത്രത്തിൽ Deloitte, Azure OpenAI GPT-4o ഉപയോഗിച്ചിരുന്നതായി പുതുക്കിയ റിപ്പോർട്ട് വെളിപ്പെടുത്തി, അവസാന ഗഡു തിരികെ നൽകാൻ സ്ഥാപനം സമ്മതിക്കുകയും ചെയ്തു. നിർഭാഗ്യവശാൽ, ഇതൊരു അഷ്വറൻസ് അവലോകനമായിരുന്നു.

നിങ്ങൾക്ക് ചെയ്യാവുന്നത്:

• തെളിവുകൾ ഉത്തരത്തെ പിന്തുണയ്ക്കുന്നുണ്ടോയെന്ന് പരിശോധിക്കുക: അവകാശവാദങ്ങളെ നിലവിലുള്ളതും ആധികാരികവുമായ ഉറവിടങ്ങളിൽ അധിഷ്ഠിതമാക്കുക. ഒരു നയത്തെക്കുറിച്ചുള്ള ഉത്തരത്തിന്, അംഗീകൃത നയം വീണ്ടെടുത്ത്, അതിലെ ഒഴിവാക്കലുകൾ ഉൾപ്പെടെ, അത് നിഗമനത്തെ പിന്തുണയ്ക്കുന്നുണ്ടോയെന്ന് പരിശോധിക്കുക.
• സിസ്റ്റം പ്രവർത്തിക്കുന്നതിന് മുമ്പ് പരിശോധിച്ചുറപ്പിക്കുക: ഒരു ഉപഭോക്താവ് ഐഡന്റിറ്റി പരിശോധന വിജയിച്ചതായി ഒരു ഏജന്റ് പറയുകയാണെങ്കിൽ, ഒരു പേയ്‌മെന്റ് റിലീസ് ചെയ്യുന്നതിന് മുമ്പ് വെരിഫിക്കേഷൻ സിസ്റ്റവുമായി ഒത്തുനോക്കി അത് സ്ഥിരീകരിക്കുക. സുപ്രധാന അനന്തരഫലങ്ങളുള്ള തീരുമാനങ്ങൾക്ക് മനുഷ്യന്റെ അംഗീകാരം നിർബന്ധമാക്കുക, ഒപ്പം പിന്തുണയ്ക്കുന്ന തെളിവുകൾ അവലോകനം ചെയ്യുന്നയാൾക്ക് ലഭ്യമാക്കുക.

8. മറഞ്ഞിരിക്കുന്ന കോൺടെക്സ്റ്റ് വെളിപ്പെടുന്നതുമൂലമുള്ള നാശനഷ്ടം പരിമിതപ്പെടുത്തുക

ഉപയോക്താക്കൾ സാധാരണയായി കാണാത്ത നിർദ്ദേശങ്ങളും പശ്ചാത്തല വിവരങ്ങളും AI ആപ്ലിക്കേഷനുകൾ മോഡലിന് നൽകുന്നു. സിസ്റ്റം പ്രോംപ്റ്റ്, ആന്തരിക നയങ്ങൾ, ലഭ്യമായ ടൂളുകളുടെ വിവരണങ്ങൾ, അവ ആർക്കൊക്കെ ഉപയോഗിക്കാം എന്നതിനെക്കുറിച്ചുള്ള നിയമങ്ങൾ എന്നിവ ഇതിൽ ഉൾപ്പെടാം. മോഡൽ ആ വിവരങ്ങൾ ആർക്കെങ്കിലും വെളിപ്പെടുത്തുമ്പോഴാണ് മറഞ്ഞിരിക്കുന്ന കോൺടെക്സ്റ്റിന്റെ വെളിപ്പെടൽ സംഭവിക്കുന്നത്.

പുറത്തുപോകാൻ സാധ്യതയുള്ളതിന്റെ ഒരു ഭാഗം മാത്രമാണ് സിസ്റ്റം പ്രോംപ്റ്റ് എന്നതിനാൽ, 2026-ൽ OWASP ഈ എൻട്രിയെ “സിസ്റ്റം പ്രോംപ്റ്റ് ചോർച്ച” എന്നതിൽ നിന്ന് വിപുലീകരിച്ചു. നിങ്ങൾ അവിടെ എന്താണ് ഉൾപ്പെടുത്തിയിരിക്കുന്നത് എന്നതിനെ ആശ്രയിച്ചാണ് അപകടം. ചോർന്ന ഒരു ടോൺ-ഓഫ്-വോയ്‌സ് ഗൈഡ് അൽപ്പം നാണക്കേടുണ്ടാക്കും, എന്നാൽ ചോർന്ന ഒരു API കീ നിങ്ങളുടെ രഹസ്യ ഡാറ്റാബേസിലേക്ക് ഒരാൾക്ക് ആക്‌സസ് നൽകുന്നു.

ഉദാഹരണം: 2023 ഫെബ്രുവരിയിൽ, Microsoft-ന്റെ Bing Chat-നെക്കൊണ്ട് ഉപയോക്താക്കൾ അതിന്റെ ആന്തരിക നിർദ്ദേശങ്ങൾ വെളിപ്പെടുത്തിച്ചു. വിജയകരമായ ഒരു ശ്രമം നടത്തിയത് Marvin von Hagen ആയിരുന്നു; OpenAI ഡെവലപ്പറാണെന്ന് അവകാശപ്പെട്ട അദ്ദേഹം, മോഡൽ കോൺഫിഗർ ചെയ്യാനായി നിർദ്ദേശങ്ങൾ ആവശ്യപ്പെട്ടു. തിരയലുകൾ, പ്രതികരണങ്ങൾ, സുരക്ഷാ പെരുമാറ്റം എന്നിവ നിയന്ത്രിക്കുന്ന നിയമങ്ങളും, ഒപ്പം Sydney എന്ന അതിന്റെ ആന്തരിക നാമവും Bing വെളിപ്പെടുത്തി. ആ നിർദ്ദേശങ്ങൾ രഹസ്യമായി സൂക്ഷിക്കാൻ ആവശ്യപ്പെടുന്ന ഒരു നിർദ്ദേശവും വെളിപ്പെടുത്തപ്പെട്ട നിർദ്ദേശങ്ങളിൽ ഉണ്ടായിരുന്നു.

നിങ്ങൾക്ക് ചെയ്യാവുന്നത്:

• മോഡലിന്റെ കോൺടെക്സ്റ്റിൽ നിന്ന് രഹസ്യങ്ങൾ അകറ്റിനിർത്തുക: മോഡലിന് വായിക്കാൻ കഴിയുന്ന എന്തും ഉപയോക്താക്കൾക്ക് ദൃശ്യമായേക്കാം എന്ന് കരുതുക—പാസ്‌വേഡുകൾ, API കീകൾ, ആക്‌സസ് ടോക്കണുകൾ എന്നിവ ഒരു പ്രത്യേക സീക്രട്ട്സ്-മാനേജ്‌മെന്റ് സിസ്റ്റത്തിൽ സൂക്ഷിക്കുക.
• നിയമങ്ങൾ ചോർന്നാലും അനുമതികൾ നിലനിൽക്കുന്നുവെന്ന് ഉറപ്പാക്കുക: നിങ്ങളുടെ ആപ്ലിക്കേഷൻ കോഡിൽ ആക്‌സസ് പരിശോധനകൾ നടപ്പിലാക്കുക. ഒരു ടൂൾ അഡ്മിനിസ്ട്രേറ്റർമാർക്ക് മാത്രമായി പരിമിതപ്പെടുത്തിയിട്ടുണ്ടെങ്കിൽ, അത് പ്രവർത്തിപ്പിക്കുന്നതിന് മുമ്പ് ഉപയോക്താവിന്റെ അക്കൗണ്ട് അനുമതികൾ പരിശോധിക്കുക.

9. നിങ്ങളുടെ വെക്ടറുകളും എംബെഡിംഗുകളും സുരക്ഷിതമാക്കുക

നിങ്ങളുടെ കമ്പനിയുടെ ഡോക്യുമെന്റുകളിൽ ഉത്തരങ്ങൾ കണ്ടെത്താൻ ഒരു AI വെക്ടർ സെർച്ച് ഉപയോഗിക്കുമ്പോൾ, അത് ടെക്സ്റ്റിൽ നേരിട്ട് തിരയുന്നില്ല. ഡോക്യുമെന്റുകൾ “എംബെഡിംഗുകൾ” ആയി പരിവർത്തനം ചെയ്യപ്പെടുന്നു—ഓരോ ഭാഗത്തിന്റെയും അർത്ഥം ഉൾക്കൊള്ളുന്ന സംഖ്യകളുടെ നീണ്ട പട്ടികകളാണ് ഇവ—തുടർന്ന് അവ ഒരു വെക്ടർ ഡാറ്റാബേസിൽ സംഭരിക്കുന്നു. ഒരു ചോദ്യവും ഇതേ രീതിയിൽ പരിവർത്തനം ചെയ്യപ്പെടുന്നു, തുടർന്ന് ഏറ്റവും അടുത്ത സംഖ്യകളുള്ള ഭാഗങ്ങൾ സിസ്റ്റം വീണ്ടെടുക്കുന്നു.

ഇത് പരാജയപ്പെടുന്ന നാല് വഴികൾ OWASP ചുരുക്കി വിവരിക്കുന്നു: പോയിസണിംഗ് സിസ്റ്റത്തെ തെറ്റായ ഉത്തരങ്ങൾ നൽകാൻ ഇടയാക്കുന്നു, ഇൻവേർഷൻ അതിനെ വിവരങ്ങൾ ചോർത്താൻ ഇടയാക്കുന്നു, ജാമിംഗ് അതിനെ നിശ്ശബ്ദമാക്കുന്നു, തകരാറിലായ ആക്‌സസ് കൺട്രോൾ അതിനെ എന്തും ആർക്കും കൈമാറാൻ ഇടയാക്കുന്നു.

ഈ സംഖ്യകൾ കാണുന്നത്ര സുരക്ഷിതമായ ഒരു അമൂർത്തരൂപമല്ല. സംഭരിച്ച എംബെഡിംഗുകൾ തിരികെ ടെക്സ്റ്റാക്കി മാറ്റാൻ കഴിയും, ഒരു രീതി അതിന്റെ പരീക്ഷണങ്ങളിൽ 32 ടോക്കണുകളുള്ള ചെറിയ ഭാഗങ്ങളിൽ 92%-വും കൃത്യമായി വീണ്ടെടുത്തു. അതിനാൽ, ചോർന്ന ഒരു “എംബെഡിംഗുകൾ മാത്രമുള്ള” ബാക്കപ്പിനും ഡോക്യുമെന്റുകളിലെ ഉള്ളടക്കം വെളിപ്പെടുത്താൻ കഴിയും.

ഉദാഹരണം: USENIX Security 2025-ൽ അവതരിപ്പിച്ച ഒരു ഗവേഷണത്തിൽ, ശ്രദ്ധാപൂർവ്വം തയ്യാറാക്കിയ ഒരൊറ്റ ഡോക്യുമെന്റിന് ഒരു പ്രത്യേക ചോദ്യത്തിന് ഉത്തരം നൽകുന്നതിൽ നിന്ന് AI-യെ തടയാൻ കഴിയുമെന്ന് ഗവേഷകർ തെളിയിച്ചു. AI തിരയുന്ന ശേഖരത്തിലേക്ക് അവർ അത് ചേർത്തു. AI അത് കണ്ടെത്തിയപ്പോൾ, തനിക്ക് ആവശ്യത്തിന് വിവരങ്ങളില്ലെന്നോ ഉത്തരം നൽകുന്നത് സുരക്ഷിതമല്ലെന്നോ അത് പറയുമായിരുന്നു. AI-യോട് അതിന്റെ നിയമങ്ങൾ അവഗണിക്കാൻ ആ ഡോക്യുമെന്റ് പറയേണ്ട ആവശ്യം പോലുമുണ്ടായിരുന്നില്ല. ഇതിനെ “റിട്രീവൽ ജാമിംഗ്” എന്ന് വിളിക്കുന്നു.

നിങ്ങൾക്ക് ചെയ്യാവുന്നത്:

• പൊതു ഡാറ്റയ്ക്കും സ്വകാര്യ ഡാറ്റയ്ക്കും പ്രത്യേക ഇൻഡെക്സുകൾ സൂക്ഷിക്കുക: സ്ക്രേപ്പ് ചെയ്ത വെബ് ഉള്ളടക്കം പങ്കാളി ഡാറ്റയുമായോ രഹസ്യാത്മകമായ ആന്തരിക ഡോക്യുമെന്റുകളുമായോ കലർത്തരുത്. ഒരൊറ്റ ഇൻഡെക്സിലെ ഉള്ളടക്കം ടാഗ് ചെയ്യുന്നതിനു പകരം വിശ്വാസ്യതാ നിലവാരം അനുസരിച്ച് ഭൗതികമായി വേർതിരിക്കുക; ഇത് ഒരു മുഴുവൻ വിഭാഗം കോൺഫിഗറേഷൻ പിഴവുകളും ഇല്ലാതാക്കുന്നു, ഇന്റർനെറ്റിൽ നിന്ന് സ്ക്രേപ്പ് ചെയ്ത ഉള്ളടക്കം നിങ്ങളുടെ ബോർഡ് രേഖകൾക്കൊപ്പം എത്തിപ്പെടുകയുമില്ല.
• എംബെഡിംഗുകളെ അവ ഉണ്ടായ ഡോക്യുമെന്റുകളെപ്പോലെ തന്നെ കൈകാര്യം ചെയ്യുക: അവ എൻക്രിപ്റ്റ് ചെയ്യുക, സോഴ്സ് ഫയലുകൾക്കൊപ്പം വെക്ടർ ഡാറ്റാബേസ് ബാക്കപ്പുകളും സംരക്ഷിക്കുക, ഒറിജിനൽ ഇല്ലാതാക്കുമ്പോൾ എംബെഡിംഗുകളും ഇല്ലാതാക്കുക. നിങ്ങളുടെ എംബെഡിംഗ് സേവനത്തിനുള്ള API കീകൾ രഹസ്യമായി സൂക്ഷിക്കണം.

10. AI ഔട്ട്‌പുട്ട് മറ്റൊരിടത്തേക്ക് കൈമാറുന്നതിന് മുമ്പ് പരിശോധിക്കുക

അവിടെ ഉപയോഗിക്കാൻ സുരക്ഷിതമാണോ എന്ന് പരിശോധിക്കാതെ ഒരു ആപ്ലിക്കേഷൻ AI ഔട്ട്‌പുട്ട് മറ്റൊരു സിസ്റ്റത്തിലേക്ക് കൈമാറുമ്പോഴെല്ലാം, അത് LLM ഔട്ട്‌പുട്ട് അനുചിതമായി കൈകാര്യം ചെയ്യുകയാണ്.

AI കോഡിംഗ് അസിസ്റ്റന്റുകൾ വലിയ തോതിൽ സൃഷ്ടിക്കുന്ന സുരക്ഷിതമല്ലാത്ത കോഡും ഈ വിഭാഗത്തിൽ ഉൾപ്പെടുന്നു. അതിനാൽ, ഒരു അസിസ്റ്റന്റ് എഴുതുന്ന ഓരോ വരിയും ഔട്ട്‌പുട്ട് തന്നെയാണ്.

ഉദാഹരണം: 2025-ൽ, ഒരു ചിത്രം പ്രദർശിപ്പിക്കുന്നതിലൂടെ മാത്രം Sourcegraph-ന്റെ Amp കോഡിംഗ് അസിസ്റ്റന്റിന് ചാറ്റ് ഉള്ളടക്കം ചോർത്താൻ കഴിയുമെന്ന് ഗവേഷകനായ Johann Rehberger തെളിയിച്ചു. ഒരു ചിത്രത്തിന്റെ വെബ് വിലാസത്തിൽ സ്വകാര്യ വിവരങ്ങൾ ഉൾപ്പെടുത്താൻ Amp-നെ പ്രേരിപ്പിക്കാൻ അദ്ദേഹം പ്രോംപ്റ്റ് ഇൻജക്ഷൻ ഉപയോഗിച്ചു. തുടർന്ന് ആപ്ലിക്കേഷൻ ആ ചിത്രം സ്വയമേവ ലഭ്യമാക്കി, അതുവഴി വിവരങ്ങൾ അദ്ദേഹത്തിന്റെ സെർവറിലേക്ക് അയച്ചു. ആ സ്വയമേവയുള്ള അഭ്യർത്ഥനയായിരുന്നു ഔട്ട്‌പുട്ട് കൈകാര്യം ചെയ്യുന്നതിലെ പരാജയം—മോഡൽ സൃഷ്ടിച്ച ടെക്സ്റ്റ് സ്വകാര്യ ഡാറ്റയും വഹിച്ചുകൊണ്ട് ഒരു പുറം സെർവറിലേക്കുള്ള കണക്ഷനായി മാറി.

നിങ്ങൾക്ക് ചെയ്യാവുന്നത്:

• ഔട്ട്‌പുട്ട് അതിന്റെ ലക്ഷ്യസ്ഥാനത്തിന് സുരക്ഷിതമാക്കുക: പ്രതികരണങ്ങൾ എവിടേക്കാണ് പോകുന്നത് എന്നതനുസരിച്ച് അവ പരിശോധിച്ച് കൈകാര്യം ചെയ്യുക. ഒരു വെബ്‌പേജിന്റെ കാര്യത്തിൽ, സൃഷ്ടിച്ച ടെക്സ്റ്റ് എക്സിക്യൂട്ട് ചെയ്യാവുന്ന കോഡായി മാറുന്നത് തടയുക. ഒരു ഡാറ്റാബേസിന്റെ കാര്യത്തിൽ, നൽകിയ മൂല്യങ്ങളെ കമാൻഡുകളിൽ നിന്ന് വേറിട്ട് നിർത്തുന്ന പ്രിപ്പേർഡ് ക്വറികൾ ഉപയോഗിക്കുക.
• ഉത്തരങ്ങൾ സ്വയമേവ പുറത്തേക്ക് കണക്ഷനുകൾ ഉണ്ടാക്കുന്നത് തടയുക: മോഡൽ പ്രതികരണങ്ങളിലെ ചിത്രങ്ങൾ, ലിങ്ക് പ്രിവ്യൂകൾ, എംബെഡ് ചെയ്ത പേജുകൾ എന്നിവ സ്വയമേവ ലോഡ് ചെയ്യുന്നത് ഡിഫോൾട്ടായി പ്രവർത്തനരഹിതമാക്കുക. ആവശ്യമായ കണക്ഷനുകൾ വ്യക്തമായി അംഗീകരിച്ച ലക്ഷ്യസ്ഥാനങ്ങളിലേക്ക് മാത്രമായി പരിമിതപ്പെടുത്തുക.

Perplexity എങ്ങനെയാണ് LLM-കൾ സുരക്ഷിതമാക്കുന്നത്?

മുകളിൽ പറഞ്ഞ ഓരോ അപകടസാധ്യതയും ഒടുവിൽ യാഥാർത്ഥ്യമാകുമെന്ന് ഞങ്ങൾ അനുമാനിക്കുന്നു, അങ്ങനെ സംഭവിക്കുമ്പോൾ അതിന് കാര്യമായ ദോഷം വരുത്താൻ കഴിയാത്ത വിധത്തിലാണ് ഞങ്ങൾ സിസ്റ്റങ്ങൾ രൂപകൽപ്പന ചെയ്യുന്നത്. ഇത് എങ്ങനെയെന്ന് ഞങ്ങളുടെ CISO ആയ Kyle Polley ഒരു സമീപകാല വർക്ക്‌ഷോപ്പിൽ വിശദീകരിച്ചു.

• ഏജന്റിന് സ്വന്തമായി ഒരു കമ്പ്യൂട്ടർ ലഭിക്കുന്നു, അത് ശൂന്യമായാണ് ആരംഭിക്കുന്നത്: നിങ്ങളുടെ ലാപ്‌ടോപ്പിൽ ഇൻസ്റ്റാൾ ചെയ്ത ഏജന്റ് ടൂളുകൾക്ക് അതിലെ ഫയലുകൾ, ആപ്പുകൾ, സേവ് ചെയ്ത ക്രെഡൻഷ്യലുകൾ എന്നിവയിലേക്ക് ആക്‌സസ് നേടാൻ കഴിയും. Perplexity Computer നേരെ വിപരീതമായാണ് പ്രവർത്തിക്കുന്നത്. ഓരോ ടാസ്‌ക്കും അതിന്റേതായ ഒറ്റപ്പെട്ട സാൻഡ്‌ബോക്സിൽ പ്രവർത്തിക്കുന്നു, Polley പറയുന്നതുപോലെ, “ഡിഫോൾട്ടായി അതിന് ഒന്നിലേക്കും ആക്‌സസ് ഇല്ല.”
• ഏജന്റ് ഒരിക്കലും പാസ്‌വേഡുകൾ കാണുന്നില്ല: കണക്റ്റ് ചെയ്ത സേവനങ്ങൾക്കുള്ള ക്രെഡൻഷ്യലുകൾ സാൻഡ്‌ബോക്സിന് പുറത്താണ് സംഭരിക്കുന്നത്. GitHub പോലുള്ള ഒരു സേവനത്തിലേക്ക് എത്തേണ്ടിവരുമ്പോൾ, ഏജന്റ് ക്രെഡൻഷ്യലുകളൊന്നും ചേർക്കാതെ ഒരു അഭ്യർത്ഥന അയയ്ക്കുന്നു. ലക്ഷ്യസ്ഥാനവും അഭ്യർത്ഥനയും പ്രതീക്ഷിക്കുന്നതുതന്നെയാണോ എന്ന് ഒരു ഗേറ്റ്‌വേ പരിശോധിക്കുന്നു, തുടർന്ന് അഭ്യർത്ഥന പുറത്തേക്ക് പോകുമ്പോൾ ക്രെഡൻഷ്യലുകൾ ചേർക്കുന്നു. കീകൾ ലഭിക്കാതെ തന്നെ ഏജന്റിന് കണക്ഷൻ ഉപയോഗിക്കാൻ കഴിയും.
• നിങ്ങളുടെ അനുമതികൾ അതേപടി തുടരുന്നു, നിങ്ങൾക്ക് അവ കൂടുതൽ കർശനമാക്കാനും കഴിയും: OAuth വഴി ഉണ്ടാക്കുന്ന കണക്ഷനുകൾ, കണക്റ്റ് ചെയ്ത സേവനത്തിലെ നിങ്ങളുടെ ആക്‌സസ് അനുമതികൾ നിലനിർത്തുന്നു. നിങ്ങൾക്ക് എന്തെങ്കിലും കാണാൻ കഴിയുന്നില്ലെങ്കിൽ, നിങ്ങളുടെ ഏജന്റിനും അത് കാണാൻ കഴിയില്ല.
• ഓരോ വെബ് പേജിനെയും ഒരു അപരിചിതനായി കണക്കാക്കുന്നു: ഞങ്ങൾ പരീക്ഷിച്ച ടൂളുകൾ യഥാർത്ഥ ഉപയോഗത്തിൽ ഞങ്ങളുടെ ആവശ്യങ്ങൾ നിറവേറ്റാത്തതിനാൽ, ഞങ്ങളുടെ ഏജന്റിക് ബ്രൗസറായ Comet-നായി ഞങ്ങൾ BrowseSafe നിർമ്മിച്ചു. പ്രോംപ്റ്റ് ഇൻജക്ഷൻ കണ്ടെത്താൻ ബ്രൗസർ വെബ് പേജുകളും ഇമെയിലുകൾ ഉൾപ്പെടെയുള്ള മറ്റ് പുറത്തുനിന്നുള്ള ഉള്ളടക്കവും സ്കാൻ ചെയ്യുന്നു. മോഡലും ഡാറ്റാസെറ്റും ഞങ്ങൾ ഓപ്പൺ സോഴ്‌സ് ആക്കി.
• ഏജന്റിനെയും അത് പ്രവർത്തിക്കുന്ന മെഷീനുകളെയും ഞങ്ങൾ നിരീക്ഷിക്കുന്നു: ഒരു ഏജന്റ് പ്രവർത്തിക്കാൻ തീരുമാനിക്കുന്നതിനും ടൂൾ യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്നതിനും ഇടയിലാണ് Numbat സ്ഥിതിചെയ്യുന്നത്. പിന്തുണയ്ക്കുന്ന കോഡിംഗ് ഏജന്റുകളിലുടനീളമുള്ള പ്രവർത്തനങ്ങൾ Numbat ലോഗ് ചെയ്യുന്നു, കോൺഫിഗർ ചെയ്ത നയങ്ങൾ ലംഘിക്കുന്ന പ്രവർത്തനങ്ങൾ എക്സിക്യൂട്ട് ചെയ്യുന്നതിന് മുമ്പ് തടയാനും അതിന് കഴിയും. ലാപ്‌ടോപ്പുകൾ, സെർവറുകൾ, ബിൽഡ് പൈപ്പ്‌ലൈനുകൾ എന്നിവയിലുടനീളമുള്ള സോഫ്റ്റ്‌വെയർ പാക്കേജുകളുടെ ഇൻവെന്ററി Bumblebee തയ്യാറാക്കുകയും അറിയപ്പെടുന്ന ദുരുദ്ദേശ്യപരമായ പാക്കേജുകൾ ഫ്ലാഗ് ചെയ്യുകയും ചെയ്യുന്നു. രണ്ടും ഓപ്പൺ സോഴ്‌സാണ്.
• മോഡൽ ദാതാക്കൾ നിങ്ങളുടെ ഡാറ്റ സൂക്ഷിക്കുന്നില്ല: ഞങ്ങളുടെ മൂന്നാം കക്ഷി LLM ദാതാക്കളുമായി ഞങ്ങൾക്ക് സീറോ ഡാറ്റ റിറ്റൻഷൻ ക്രമീകരണങ്ങളുണ്ട്. Enterprise അഡ്മിനുകൾക്ക് Perplexity-യുടെ സ്വന്തം ഡാറ്റ റിറ്റൻഷൻ കാലയളവ് 24 മണിക്കൂർ വരെ ചുരുക്കി സജ്ജമാക്കാനും കഴിയും.

Polley ഒറ്റ വരിയിൽ സംഗ്രഹിക്കുന്ന ഒരു കാരണത്താലാണ് ഞങ്ങൾ മുൻകൂട്ടി Numbat നിർമ്മിച്ചത്: “ഒരു ഏജന്റിന് നിങ്ങൾ എത്രത്തോളം സ്വയംഭരണം നൽകുന്നുവോ, അത്രത്തോളം അപകടസാധ്യതയും കൂടും.”

LLM സുരക്ഷ: പതിവ് ചോദ്യങ്ങൾ

ഏറ്റവും സുരക്ഷിതമായ LLM ഏതാണ്?

ഒരു LLM-നും സ്വന്തം നിലയിൽ ഒരു ആപ്ലിക്കേഷനെ സുരക്ഷിതമാക്കാൻ കഴിയില്ല—വായിക്കേണ്ട ഉള്ളടക്കത്തെ പിന്തുടരേണ്ട നിർദ്ദേശങ്ങളായി മോഡലുകൾ ഇപ്പോഴും തെറ്റിദ്ധരിച്ചേക്കാം. സാധാരണ ടെസ്റ്റുകളിൽ ശക്തമായി തോന്നുന്ന പ്രതിരോധങ്ങളും സമ്മർദ്ദത്തിൽ തകർന്നേക്കാം.

നിങ്ങളുടെ ഉപയോഗത്തിന് ഏത് സജ്ജീകരണമാണ് ഏറ്റവും സുരക്ഷിതം എന്നതാണ് കൂടുതൽ മികച്ച ചോദ്യം. അതിനർത്ഥം പരിമിതമായ അനുമതികൾ, മോഡലിൽ നിന്ന് അകറ്റിനിർത്തിയ ക്രെഡൻഷ്യലുകൾ, അപകടസാധ്യതയുള്ള പ്രവർത്തനങ്ങൾക്ക് മനുഷ്യരുടെ അംഗീകാരം, നിങ്ങളുടെ പ്രതിരോധ സംവിധാനങ്ങളെക്കുറിച്ച് അറിയുന്ന ആളുകൾ നടത്തുന്ന ടെസ്റ്റിംഗ് എന്നിവയാണ്.

LLM സുരക്ഷാ പഴുതുകൾ എന്തൊക്കെയാണ്?

ഒരു ആക്രമണകാരി മുഖേനയോ സ്വന്തം പിഴവുകൾ മൂലമോ ഒരു AI സിസ്റ്റം കബളിപ്പിക്കപ്പെടാനോ ഡാറ്റ ചോർത്താനോ കേടുപാടുകൾ വരുത്താനോ ഇടയാക്കുന്ന ദൗർബല്യങ്ങളാണ് LLM സുരക്ഷാ പഴുതുകൾ.

പ്രോംപ്റ്റ് ഇൻജക്ഷൻ, സെൻസിറ്റീവ് വിവരങ്ങളുടെ വെളിപ്പെടുത്തൽ, അമിതമായ ഏജൻസി, സപ്ലൈ ചെയിൻ, ഡാറ്റാ-മോഡൽ പോയിസണിംഗ്, പരിധിയില്ലാത്ത ഉപഭോഗം, തെറ്റായ വിവരങ്ങൾ, മറഞ്ഞിരിക്കുന്ന കോൺടെക്സ്റ്റിന്റെ വെളിപ്പെടൽ, വെക്ടർ-എംബെഡിംഗ് ദൗർബല്യങ്ങൾ, അനുചിതമായ ഔട്ട്‌പുട്ട് കൈകാര്യം ചെയ്യൽ എന്നിവയാണ് പത്ത് പ്രധാന അപകടസാധ്യതകൾ.

സ്വകാര്യ LLM സുരക്ഷിതമാണോ?

ചില കാര്യങ്ങൾക്ക് കൂടുതൽ സുരക്ഷിതമായ ഒരു ഓപ്ഷനാണ്, എന്നാൽ സ്വതവേ അങ്ങനെയല്ല. നിങ്ങളുടെ സ്വന്തം ഇൻഫ്രാസ്ട്രക്ചറിലോ ഒരു ക്ലൗഡ് എൻവയോൺമെന്റിലോ ഒരു മോഡൽ പ്രവർത്തിപ്പിക്കുകയാണെങ്കിൽ, ഡാറ്റ കൈകാര്യം ചെയ്യുന്നതിൽ നിങ്ങൾക്ക് കൂടുതൽ നിയന്ത്രണമുണ്ട്. എന്നാൽ പ്രോംപ്റ്റ് ഇൻജക്ഷനുകൾ, അമിതമായ ഏജൻസി, പോയിസണിംഗ്, തെറ്റായ വിവരങ്ങൾ എന്നിവ തടയാൻ സ്വയമേവയുള്ള ഒരു മാർഗവുമില്ല.

സെൽഫ്-ഹോസ്റ്റിംഗിന്റെ ഭാഗമായി, സപ്ലൈ ചെയിൻ അപകടസാധ്യതകളും അതിന് ആവശ്യമായ ഇൻഫ്രാസ്ട്രക്ചറും ഉൾപ്പെടെ, നിങ്ങൾ ഡൗൺലോഡ് ചെയ്യുന്ന മോഡലിന്റെ ഉത്തരവാദിത്തവും നിങ്ങൾക്കാണ്.