ഗവേഷകർ കണ്ടെത്തിയിരിക്കുന്നത് എൻക്രിപ്റ്റ് ചെയ്ത റീസണിംഗ് ട്രേസുകൾ (encrypted reasoning traces)—ഒരു പ്രൊവൈഡർ ഉപയോക്താവിന്റെ ഉപകരണത്തിലേക്ക് അയക്കുന്ന ചെറിയ പാക്കറ്റുകൾ—അതേ സർവീസിലെ തന്നെ ഒരു ദുർബലമായ മോഡലിന് ഡീക്രിപ്റ്റ് ചെയ്യാൻ കഴിയുമെന്നാണ്. ഇത് നൂറുകണക്കിന് ക്രെഡൻഷ്യലുകളും സ്വകാര്യ വിവരങ്ങളും വെളിപ്പെടുത്തുന്നു. Stealing Reasoning Traces from Proprietary LLM APIs എന്ന പേപ്പറിലുൾപ്പെട്ട ഈ കണ്ടെത്തൽ, Anthropic, OpenAI, Google എന്നിവർ തങ്ങളുടെ AI ചാറ്റുകൾ സുഗമമാക്കാൻ ഉപയോഗിക്കുന്ന ഒരു സൗകര്യത്തിന് ഭീഷണിയാകുന്നു.
Why the encrypted blocks exist
നിങ്ങൾ ഒരു ലാർജ് ലാംഗ്വേജ് മോഡലുമായി (LLM) സംസാരിക്കുമ്പോൾ, ആ സേവനം ഒരു "റീസണിംഗ് ട്രേസ്" (reasoning trace) നിർമ്മിക്കുന്നു: അതായത് ഉത്തരത്തിലേക്ക് നയിച്ച ഇന്റേണൽ പ്രോംപ്റ്റുകൾ, ടൂൾ കോളുകൾ, ചെയിൻ-ഓഫ്-തോട്ട് (chain-of-thought) ഘട്ടങ്ങൾ എന്നിവയുടെ ശൃംഖല. ഈ ശൃംഖല നഷ്ടപ്പെടാതെ തന്നെ വലിയൊരു മോഡലിൽ നിന്ന് കുറഞ്ഞ ചിലവുള്ള ഒരു മോഡലിലേക്ക് മാറാൻ നിങ്ങളെ അനുവദിക്കുന്നതിനായി, പ്രൊവൈഡർമാർ ഈ ട്രേസ് എൻക്രിപ്റ്റ് ചെയ്ത് നിങ്ങളുടെ ഉപകരണത്തിലേക്ക് അയക്കുകയും അടുത്ത അഭ്യർത്ഥനയോടൊപ്പം അത് തിരികെ അയക്കാൻ നിങ്ങളിൽ നിന്ന് പ്രതീക്ഷിക്കുകയും ചെയ്യുന്നു. സെഷനുകൾക്കും മോഡലുകൾക്കും ഇടയിലുള്ള തുടർച്ച ഉറപ്പാക്കുമ്പോൾ തന്നെ ട്രേസ് സ്വകാര്യമായി സൂക്ഷിക്കാനാണ് ഈ എൻക്രിപ്ഷൻ ലക്ഷ്യമിടുന്നത്.
How the attack works
ഗവേഷകർ മൂന്ന് ഘട്ടങ്ങളുള്ള ഒരു എക്സ്പ്ലോയിറ്റ് (exploit) തെളിയിച്ചു, ഇതിന് ശക്തമായ മോഡലിനെ തന്നെ ഹാക്ക് ചെയ്യേണ്ടതില്ല:
- Capture: സാധാരണ സംഭാഷണത്തിനിടയിൽ ഒരു ശക്തമായ മോഡൽ നിർമ്മിക്കുന്ന എൻക്രിപ്റ്റ് ചെയ്ത റീസണിംഗ് ബ്ലോക്ക് പിടിച്ചെടുക്കുക.
- Feed: അതേ പ്രൊവൈഡറുടെ തന്നെ ഒരു ദുർബലമായ മോഡലിലേക്ക് ആ ബ്ലോക്ക് നൽകി അത് "വായിക്കാൻ" ആവശ്യപ്പെടുക.
- ദുർബലമായ മോഡലിന് അതേ ഡീക്രിപ്ഷൻ കീകൾ ഉള്ളതിനാൽ, അത് ഡീക്രിപ്റ്റ് ചെയ്ത ഉള്ളടക്കം പ്ലെയിൻ ടെക്സ്റ്റ് ആയി outputs ചെയ്യുന്നു.
ദുർബലമായ മോഡൽ ഒരു ഡീക്രിപ്ഷൻ ഒറാക്കിൾ (decryption oracle) ആയി പ്രവർത്തിക്കുന്നു. ആക്രമണകാരികൾ ശക്തമായ മോഡലിന്റെ ഇന്റേണൽ ഭാഗങ്ങളിൽ തൊട്ടിട്ടില്ല; അവർ പ്രൊവൈഡറുടെ സ്വന്തം API അവർക്കെതിരെ തന്നെ ഉപയോഗിക്കുകയായിരുന്നു.
What the researchers recovered
- 182 credentials – ട്രേസിൽ ഉൾപ്പെട്ടിരുന്ന API കീകൾ, ടോക്കണുകൾ, മറ്റ് രഹസ്യങ്ങൾ.
- 367 pieces of private information – ചാറ്റിനിടെ ഉപയോക്താക്കൾ നൽകിയ പേരുകൾ, ഇമെയിലുകൾ, വിലാസങ്ങൾ തുടങ്ങിയവ.
- Prompt-injection payloads – എൻക്രിപ്റ്റ് ചെയ്ത ബ്ലോക്കിനുള്ളിൽ ഒളിപ്പിച്ചു വെച്ചിരിക്കുന്ന ദോഷകരമായ നിർദ്ദേശങ്ങൾ, ഇവ പിന്നീട് ട്രേസ് വീണ്ടും ഉപയോഗിക്കുമ്പോൾ പ്രവർത്തിപ്പിക്കപ്പെടാം.
- Safety-filter bypasses – പ്ലെയിൻ ടെക്സ്റ്റ് ആയി പരിശോധിച്ചിരുന്നെങ്കിൽ തടയപ്പെടുമായിരുന്ന ഘട്ടങ്ങൾ ഡീക്രിപ്റ്റ് ചെയ്ത ട്രേസിൽ വെളിപ്പെട്ടു, ഇത് അപകടകരമായ ഉള്ളടക്കങ്ങൾ കടന്നുപോകാൻ അനുവദിക്കുന്നു.
ക്രിപ്റ്റോഗ്രാഫിക് അൽഗോരിതത്തിലെ പോരായ്മയല്ല ഇത് എന്ന് പേപ്പർ ഊന്നിപ്പറയുന്നു; എൻക്രിപ്ഷൻ തന്നെ ശരിയാണ്. ഉപയോക്തൃ അനുഭവം മെച്ചപ്പെടുത്തുന്നതിനായി പ്രൊവൈഡറുടെ പക്കലുള്ള ഏത് മോഡലിനും ഈ ബ്ലോക്ക് ഡീക്രിപ്റ്റ് ചെയ്യാൻ അനുമതി നൽകുന്ന ഡിസൈൻ തീരുമാനത്തിൽ നിന്നാണ് ഈ സുരക്ഷാ വീഴ്ച ഉണ്ടാകുന്നത്.
The trade-off at the heart of the issue
ഡെവലപ്പർമാരും ഉപയോക്താക്കളും തുടർച്ചയ്ക്ക് (continuity) പ്രാധാന്യം നൽകുന്നതുകൊണ്ടാണ് പ്രൊവൈഡർമാർ തങ്ങളുടെ API-കളിൽ ഈ "മോഡൽ-സ്വിച്ചിംഗ്" ശേഷി ഉൾപ്പെടുത്തിയത്. എൻക്രിപ്ഷൻ ഒരു പ്രത്യേക മോഡൽ ഇൻസ്റ്റൻസുമായി അല്ലെങ്കിൽ സെഷനുമായി മാത്രം ബന്ധപ്പെട്ടിരുന്നെങ്കിൽ, ഈ സുഗമമായ കൈമാറ്റം തടസ്സപ്പെടുകയും ഡെവലപ്പർമാർക്ക് സ്റ്റേറ്റ് മാനേജ്മെന്റ് (state management) സ്വയം നിർമ്മിക്കേണ്ടി വരികയും ചെയ്യും. ഫ്ലെക്സിബിലിറ്റിക്ക് വേണ്ടി സുരക്ഷ മനഃപൂർവ്വം ബലികഴിച്ചതാണെന്ന് പേപ്പർ വാദിക്കുന്നു.
What developers should do now
- എൻക്രിപ്റ്റ് ചെയ്ത ട്രേസുകളെ ക്ലിയർ-ടെക്സ്റ്റ് (clear-text) ആയി പരിഗണിക്കുക. ഇവ സൂക്ഷിക്കുന്ന ഏതൊരു ലോഗ്, കാഷെ അല്ലെങ്കിൽ മോണിറ്ററിംഗ് സിസ്റ്റവും ഒരു ആക്രമണകാരിക്ക് വായിക്കാൻ കഴിയുമെന്ന് കരുതുക.
- ട്രേസുകൾ പബ്ലിക് റിപ്പോസിറ്ററികളിൽ സേവ് ചെയ്യുന്നത് ഒഴിവാക്കുക. ഒരു ചെറിയ ബ്ലോക്ക് പോലും ഡസൻ കണക്കിന് രഹസ്യങ്ങൾ വെളിപ്പെടുത്തിയേക്കാം.
- കർശനമായ നിയന്ത്രണങ്ങൾക്കായി പ്ലാൻ ചെയ്യുക. പ്രൊവൈഡർമാർ സുരക്ഷ കർശനമാക്കിയേക്കാം, ഇത് മൾട്ടി-മോഡൽ ഏജന്റുകൾ നിർമ്മിക്കുന്ന രീതിയെ മാറ്റിയേക്കാം.
- വ്യക്തമായ സ്റ്റേറ്റ് കൈമാറ്റങ്ങളിലേക്ക് (explicit state hand-offs) മാറുക. ഒളിഞ്ഞിരിക്കുന്ന റീസണിംഗിനെ ആശ്രയിക്കുന്നതിന് പകരം, എൻക്രിപ്ഷൻ ഇല്ലാതെ മോഡലുകൾക്കിടയിൽ സുരക്ഷിതമായി കൈമാറാൻ കഴിയുന്ന ഘടനാപരമായ ഡാറ്റ (JSON, XML, മുതലായവ) ഔട്ട്പുട്ട് ചെയ്യാൻ ഏജന്റുകളെ രൂപകൽപ്പന ചെയ്യുക.
- നിങ്ങളുടെ പ്രോംപ്റ്റുകൾ ഓഡിറ്റ് ചെയ്യുക. റീസണിംഗ് ശൃംഖലയിൽ ഉൾപ്പെടുന്ന ഏതെങ്കിലും സെൻസിറ്റീവ് ഡാറ്റ ഉണ്ടോ എന്ന് പരിശോധിക്കുകയും റിക്വസ്റ്റ് അയക്കുന്നതിന് മുമ്പ് അത് നീക്കം ചെയ്യുകയും ചെയ്യുക.
What to watch from the big providers
ഈ പേപ്പർ പുറത്തുവരുന്നത് Anthropic, OpenAI, Google എന്നിവരെ തങ്ങളുടെ API-കളിൽ ഉൾപ്പെടുത്തിയിട്ടുള്ള ഡീക്രിപ്ഷൻ പോളിസി പുനഃപരിശോധിക്കാൻ പ്രേരിപ്പിക്കും.
The broader implication
ഈ കണ്ടെത്തൽ ഒരു ക്ലാസിക് സുരക്ഷാ പ്രതിസന്ധിയെ അടിവരയിടുന്നു: സൗകര്യം പലപ്പോഴും ഒരു ബാക്ക്ഡോർ (backdoor) തുറക്കുന്നു. ഉപയോക്താവിന്റേതായ ഒരു ബ്ലോക്ക് ഡീക്രിപ്റ്റ് ചെയ്യാൻ ഏത് മോഡലിനും അനുമതി നൽകുന്നതിലൂടെ, പ്രൊവൈഡർമാർ ആക്രമണകാരികൾക്ക് സെൻസിറ്റീവ് ഡാറ്റയിലേക്ക് എളുപ്പത്തിൽ പ്രവേശിക്കാനുള്ള ഒരു വഴി തുറന്നു നൽകിയിരിക്കുകയാണ്. ഇതിനുള്ള പരിഹാരം AI സംയോജനങ്ങളെ (integrations) അല്പം സങ്കീർണ്ണമാക്കിയേക്കാം, എന്നാൽ എൻക്രിപ്റ്റ് ചെയ്ത ഡാറ്റ എൻക്രിപ്റ്റ് ചെയ്ത നിലയിൽ തന്നെയായിരിക്കണം എന്ന പ്രതീക്ഷയും ഇത് വീണ്ടെടുക്കും.
Takeaway: എൻക്രിപ്റ്റ് ചെയ്ത റീസണിംഗ് ട്രേസുകൾ ഒരു സുരക്ഷാ അതിർവരമ്പല്ല; അവ നിങ്ങൾക്ക് വിപരീതമായി ഉപയോഗിക്കാവുന്ന ഒരു സൗകര്യപ്രദമായ കുറുക്കുവഴിയാണ്. അവയെ പ്ലെയിൻ ടെക്സ്റ്റ് ആയി പരിഗണിക്കുക, ലോഗുകളിൽ നിന്ന് അവ നീക്കം ചെയ്യുക, കൂടാതെ അതിന്റെ യഥാർത്ഥ മോഡലിന് മാത്രമേ സ്വന്തം ചിന്തകൾ വായിക്കാൻ കഴിയൂ എന്ന ഭാവിയിലേക്ക് നിങ്ങളുടെ ഏജന്റുകളെ പുനർരൂപകൽപ്പന ചെയ്യുക.