SpaceXAI-യുടെ Grok Build AI കോഡിംഗ് ടൂൾ, ഉപയോക്താക്കളുടെ മുഴുവൻ റിപ്പോസിറ്ററികളും (repositories) Google Cloud സ്റ്റോറേജിലേക്ക് അപ്‌ലോഡ് ചെയ്യുന്നതായി ഗവേഷകർ കണ്ടെത്തിയതിനെത്തുടർന്ന് വലിയ വിമർശന നേരിടുന്നു. AI അസിസ്റ്റന്റുകൾ എത്രത്തോളം സ്വകാര്യ വിവരങ്ങൾ (proprietary data) ശേഖരിക്കാനും സൂക്ഷിക്കാനും സാധ്യതയുണ്ട് എന്നതിനെക്കുറിച്ച് ഈ സംഭവം വലിയ ആശങ്കയുണ്ടാക്കി.

അമിതമായ ഡാറ്റാ ശേഖരണവും സുരക്ഷാ ഭീഷണികളും

Grok Build കമാൻഡ്-ലൈൻ ഇന്റർഫേസ് (CLI), മുഴുവൻ കോഡ്ബേസുകളും (codebases) പാക്ക് ചെയ്ത് ക്ലൗഡിലേക്ക് അയക്കുന്നതായി Cereblab-ന്റെ വിശകലനം കാണിച്ചു. ഇതിലും ഗൗരവകരമായ കാര്യം, ഒഴിവാക്കാൻ (ignore) നിർദ്ദേശിച്ചിരുന്ന ഫയലുകൾ പോലും ഈ ടൂൾ തുറക്കുകയും, ഡെവലപ്പർമാർ git ഹിസ്റ്ററിയിൽ നിന്ന് നീക്കം ചെയ്ത രഹസ്യ വിവരങ്ങൾ (secrets) വീണ്ടെടുക്കുകയും ചെയ്തു എന്നതാണ്.

ഇത്തരത്തിലുള്ള അമിതമായ ഡാറ്റാ ശേഖരണം Claude Code പോലുള്ള എതിരാളികളേക്കാൾ വളരെ കൂടുതലാണ്. ഇത്തരത്തിലുള്ള ശേഖരണം സോഴ്‌സ് കോഡ്, ഇൻഫ്രാസ്ട്രക്ചർ ഡയഗ്രമുകൾ, സുരക്ഷാ വീഴ്ചകൾ (vulnerabilities), ക്രെഡൻഷ്യലുകൾ എന്നിവ റിമോട്ട് സെർവറുകളിലേക്ക് ചോരാൻ കാരണമായേക്കാമെന്ന് കിംഗ്സ് കോളേജ് ലണ്ടനിലെ സെക്യൂരിറ്റി ഗവേഷകനായ ഡോ. ലൂക്കാസ് ഒലെജ്നിക് മുന്നറിയിപ്പ് നൽകി.

SpaceXAI-യുടെയും ഇലോൺ മസ്കിന്റെയും പ്രതികരണം

SpaceXAI അപ്‌ലോഡ് ഫീച്ചർ നിർത്തിവെച്ചു. Grok-ന്റെ സെർവറുകളിൽ ഇപ്പോൾ ഒരു disable_codebase_upload: true ഫ്ലാഗ് കാണാൻ സാധിക്കുന്നുണ്ട്, ഇത് ഓട്ടോമാറ്റിക് അപ്‌ലോഡ് ഇനി നടക്കില്ലെന്ന് സ്ഥിരീകരിക്കുന്നു.

നേരത്തെ അപ്‌ലോഡ് ചെയ്ത എല്ലാ ഡാറ്റയും "പൂർണ്ണമായും നീക്കം ചെയ്യുമെന്ന്" ഇലോൺ മസ്ക് X-ൽ കുറിച്ചു. എന്നാൽ "ഡിബഗ്ഗിംഗ് ആവശ്യങ്ങൾക്കായി" (debugging issues) ഡാറ്റ സൂക്ഷിക്കാൻ SpaceXAI-യെ അനുവദിക്കണമെന്നും അദ്ദേഹം ഉപയോക്താക്കളോട് അഭ്യർത്ഥിച്ചു; ഈ അഭ്യർത്ഥന വൈരുദ്ധ്യപരമായാണ് പലരും കാണുന്നത്.

ഡാറ്റാ ശേഖരണം നിയന്ത്രിക്കുന്നതിനായി /privacy എന്ന CLI കമാൻഡ് ഉപയോഗിക്കാൻ കമ്പനി നിർദ്ദേശിച്ചുവെങ്കിലും, ഇത് ഓരോ സെഷനിലെയും സ്റ്റോറേജ് മാത്രമാണ് നിയന്ത്രിക്കുന്നതെന്നും വിവാദത്തിന് കാരണമായ സിസ്റ്റമാറ്റിക് റിപ്പോസിറ്ററി അപ്‌ലോഡുകളെ ഇത് തടയുന്നില്ലെന്നും Cereblab ചൂണ്ടിക്കാട്ടി.

ഡെവലപ്പർമാർക്കും സംരംഭങ്ങൾക്കും (Enterprises) ഇത് എന്തുകൊണ്ട് പ്രധാനമാണ്

AI അധിഷ്ഠിത കോഡിംഗ് ഏജന്റുകൾ വെറും ഓട്ടോകംപ്ലീറ്റ് (autocomplete) ടൂളുകൾ മാത്രമല്ലെന്നും, അവയ്ക്ക് സ്വയം കോഡ് വായിക്കാനും മാറ്റം വരുത്താനും കമിറ്റ് (commit) ചെയ്യാനും കഴിയുമെന്നും ഈ സംഭവം ഡെവലപ്പർമാരെയും സംരംഭങ്ങളെയും ഓർമ്മിപ്പിക്കുന്നു. ഒരു ഏജന്റ് 'ignore' ഫയലുകളെ മറികടക്കുകയോ നീക്കം ചെയ്ത രഹസ്യ വിവരങ്ങൾ വീണ്ടെടുക്കുകയോ ചെയ്യുമ്പോൾ, "സീറോ ഡാറ്റാ ററ്റൻഷൻ" (zero data retention) എന്ന അവകാശവാദം വെറും UI വാഗ്ദാനങ്ങളിലൂടെയല്ല, മറിച്ച് സാങ്കേതിക പരിശോധനകളിലൂടെ തെളിയിക്കപ്പെടേണ്ടതാണ്.

CTO-മാർക്കും പ്രൊഡക്റ്റ് ഉടമകൾക്കും ഈ സംഭവം താഴെ പറയുന്ന കാര്യങ്ങളുടെ ആവശ്യകത അടിവരയിടുന്നു:

  • യഥാർത്ഥ കോഡ്ബേസുകളിൽ AI ടൂളുകൾ നടത്തുന്ന സ്വതന്ത്ര ഓഡിറ്റുകൾ (Independent audits).
  • ഡാറ്റ കൈകാര്യം ചെയ്യുന്ന രീതി, സൂക്ഷിക്കേണ്ട കാലാവധി, ഡാറ്റ നീക്കം ചെയ്യുമെന്ന ഉറപ്പ് എന്നിവ വ്യക്തമാക്കുന്ന കരാർ വ്യവസ്ഥകൾ (Contractual clauses).
  • ക്രെഡൻഷ്യലുകളോ പേറ്റന്റ് നേടിയ അൽഗോരിതങ്ങളോ അടങ്ങിയ റിപ്പോസിറ്ററികൾക്കായി ഫയൽ-ലെവൽ പെർമിഷനുകൾ നടപ്പിലാക്കുന്ന റൺടൈം സുരക്ഷാ സംവിധാനങ്ങൾ (Runtime safeguards).

പ്രധാന കാര്യങ്ങൾ

  • അപ്രതീക്ഷിതമായ ഡാറ്റാ ശേഖരണം (Unintended Data Scoping): നിയന്ത്രിത ഫയലുകളും നീക്കം ചെയ്ത രഹസ്യ വിവരങ്ങളും ഉൾപ്പെടെയുള്ള മുഴുവൻ റിപ്പോസിറ്ററികളും Grok Build Google Cloud-ലേക്ക് അപ്‌ലോഡ് ചെയ്തു.
  • പരിഹാര നടപടികൾ (Mitigation Status): SpaceXAI ഓട്ടോമാറ്റിക് അപ്‌ലോഡ് നിർത്തിവെക്കുകയും ശേഖരിച്ച ഡാറ്റ ഇല്ലാതാക്കുമെന്ന് ഉറപ്പുനൽകുകയും ചെയ്തു.
  • സുരക്ഷാ പ്രത്യാഘാതങ്ങൾ (Security Implications): AI കോഡിംഗ് ഏജന്റുകളിൽ അമിതമായി ഡാറ്റ ശേഖരിക്കുന്നത് സ്വകാര്യ ലോജിക്കും ക്രെഡൻഷ്യലുകളും ചോരാൻ കാരണമായേക്കാമെന്ന അപകടത്തെ ഈ സംഭവം എടുത്തുകാണിക്കുന്നു.

SpaceXAI-യുടെ Grok Build ടൂൾ, ഉപയോക്താക്കളുടെ മുഴുവൻ കോഡ്ബേസുകളും നിശബ്ദമായി Google Cloud-ലേക്ക് അപ്‌ലോഡ് ചെയ്യുന്നതായും, അതുവഴി സ്വകാര്യ സോഴ്‌സ് ഫയലുകളും നീക്കം ചെയ്ത രഹസ്യ വിവരങ്ങളും വെളിപ്പെടുത്തുന്നതായും കണ്ടെത്തി.

എന്താണ് സംഭവിച്ചത്

Cereblab, Grok Build CLI-യുടെ നെറ്റ്‌വർക്ക് ട്രാഫിക് ഒരു Google Cloud ബക്കറ്റിലേക്ക് (bucket) പോകുന്നത് കണ്ടെത്തി. ഇത് മുഴുവൻ git റിപ്പോസിറ്ററികളും അപ്‌ലോഡിനായി ഓട്ടോമാറ്റിക്കായി പാക്ക് ചെയ്യുന്നതായും കണ്ടെത്തി. ചുരുക്കത്തിൽ, ഒഴിവാക്കാൻ നിർദ്ദേശിച്ചിരുന്ന ഡാറ്റയാണ് അസിസ്റ്റന്റ് ശേഖരിച്ചത്.

സുരക്ഷാ വീഴ്ച എങ്ങനെ കണ്ടെത്തി

ഗവേഷകർ പേലോഡുകൾ (payloads) പരിശോധിച്ചപ്പോൾ, അപ്‌ലോഡ് ഫ്ലാഗ് ഡിഫോൾട്ടായി തന്നെ പ്രവർത്തനസജ്ജമാണെന്നും ആഗോളതലത്തിൽ ഇത് ഒഴിവാക്കാനുള്ള (global opt-out) സംവിധാനം ഇല്ലെന്നും കണ്ടെത്തി. ഇത്തരത്തിലുള്ള "അമിതമായ ഡാറ്റാ ശേഖരണം" ബിസിനസ് ലോജിക്കും, ഇൻഫ്രാസ്ട്രക്ചർ വിവരങ്ങളും, ഓതന്റിക്കേഷൻ ടോക്കണുകളും ചോരാൻ കാരണമായേക്കാമെന്ന് ഡോ. ലൂക്കാസ് ഒലെജ്നിക് മുന്നറിയിപ്പ് നൽകി. മറ്റ് AI കോഡിംഗ് അസിസ്റ്റന്റുകളുമായി (Claude Code ഒരു ഉദാഹരണമായി എടുത്താൽ) താരതമ്യം ചെയ്യുമ്പോൾ, Grok Build-ന്റെ പ്രവർത്തനം വളരെ കൂടുതൽ കടന്നുകയറ്റുന്നതാണ് (invasive).

SpaceXAI-യുടെ പ്രതികരണം

റിപ്പോർട്ട് പുറത്തുവന്നതിന് പിന്നാലെ, SpaceXAI ഒരു അപ്‌ഡേറ്റ് പുറത്തിറക്കി. ഇത് disable_codebase_upload: true എന്ന ഫ്ലാഗ് നൽകിക്കൊണ്ട് ഫീച്ചർ പ്രവർത്തനരഹിതമാക്കി. അപ്‌ലോഡ് ചെയ്ത എല്ലാ ഡാറ്റയും "പൂർണ്ണമായും നീക്കം ചെയ്യുമെന്ന്" ഇലോൺ മസ്ക് X-ൽ പ്രഖ്യാപിക്കുകയും "സ്വകാര്യതാ ക്രമീകരണങ്ങൾ എപ്പോഴും മാനിക്കപ്പെടുന്നു" എന്ന് ആവർത്തിക്കുകയും ചെയ്തു. എന്നാൽ "ഡിബഗ്ഗിംഗ് ആവശ്യങ്ങൾക്കായി" ഡാറ്റ സൂക്ഷിക്കാൻ അദ്ദേഹം ഉപയോക്താക്കളോട് ആവശ്യപ്പെട്ടത് പലരും വൈരുദ്ധ്യപരമായി കാണുന്നു.

ഡാറ്റാ ശേഖരണം നിയന്ത്രിക്കാൻ /privacy എന്ന CLI കമാൻഡ് കമ്പനി നിർദ്ദേശിച്ചുവെങ്കിലും, ഇത് ഓരോ സെഷനിലെയും സ്റ്റോറേജ് മാത്രമാണ് നിയന്ത്രിക്കുന്നതെന്നും സിസ്റ്റമാറ്റിക് റിപ്പോസിറ്ററി അപ്‌ലോഡുകളെ ഇത് തടയുന്നില്ലെന്നും ഗവേഷകർ ചൂണ്ടിക്കാട്ടി.

ഡെവലപ്പർമാർക്കും സംരംഭങ്ങൾക്കും ഇത് എന്തുകൊണ്ട് പ്രധാനമാണ്

AI അധിഷ്ഠിത കോഡിംഗ് ഏജന്റുകൾ വെറും ഓട്ടോകംപ്ലീറ്റിൽ നിന്ന് കോഡ് വായിക്കാനും മാറ്റം വരുത്താനും കമിറ്റ് ചെയ്യാനും കഴിയുന്ന സ്വയംഭരണാധികാരമുള്ള (autonomous) ടൂളുകളായി മാറിക്കൊണ്ടിരിക്കുകയാണ്. ഒരു ഏജന്റിന് ലോക്കൽ 'ignore' ഫയലുകളെ മറികടക്കാനോ നീക്കം ചെയ്ത രഹസ്യ വിവരങ്ങൾ വീണ്ടെടുക്കാനോ കഴിയുമെങ്കിൽ, "സീറോ ഡാറ്റാ ററ്റൻഷൻ" എന്ന വാഗ്ദാനം വെറും UI സെറ്റിംഗുകൾ കൊണ്ട് മാത്രം മതിയല്ല, മറിച്ച് സാങ്കേതിക പരിശോധനകളിലൂടെ ഉറപ്പുവരുത്തേണ്ടതുണ്ട്. CTO-മാരും പ്രൊഡക്റ്റ് ഉടമകളും ചെയ്യേണ്ടത്:

  • യഥാർത്ഥ കോഡ്ബേസുകളിൽ (codebases) AI ടൂളുകളുടെ പ്രവർത്തനം പരിശോധിക്കുന്നതിനായി സ്വതന്ത്ര ഓഡിറ്റുകൾ ഏർപ്പെടുത്തുക.
  • ഡാറ്റ കൈകാര്യം ചെയ്യുന്ന രീതി, സൂക്ഷിക്കേണ്ട കാലാവധി, ഡാറ്റ നീക്കം ചെയ്യുമെന്ന ഉറപ്പ് എന്നിവ വ്യക്തമാക്കുന്ന കൃത്യമായ കരാറുകളിൽ ഒപ്പുവെക്കുക.
  • സെൻസിറ്റീവ് ആയ റിപ്പോസിറ്ററികൾക്കായി (repositories) ഫയൽ തലത്തിലുള്ള അനുമതികൾ (file-level permissions) നടപ്പിലാക്കുന്ന റൺടൈം സുരക്ഷാ സംവിധാനങ്ങൾ (runtime safeguards) ഏർപ്പെടുത്തുക.

ഈ ലംഘനം AI സൗകര്യവും സുരക്ഷയും തമ്മിലുള്ള വിട്ടുവീഴ്ചയെക്കുറിച്ച് (trade-off) വലിയൊരു ചോദ്യം ഉയർത്തുന്നു. മോഡൽ മെച്ചപ്പെടുത്തുന്നതിനായി ഉപയോഗ വിവരങ്ങൾ (usage metrics) ശേഖരിക്കാനാണ് അപ്‌ലോഡ് ഫീച്ചർ ഉപയോഗിച്ചിരുന്നതെന്ന് SpaceXAI അവകാശപ്പെടുന്നു; കൂടാതെ അവർ ആ ഫീച്ചർ നിർത്തലാക്കുകയും നിലവിലുള്ള അപ്‌ലോഡുകൾ നീക്കം ചെയ്യുമെന്ന് വാഗ്ദാനം ചെയ്യുകയും ചെയ്തു. എന്നാൽ, യഥാർത്ഥ ഡിസൈനിൽ സുതാര്യമായ ഒരു 'ഒപ്റ്റ്-ഔട്ട്' (opt-out) സംവിധാനം ഉണ്ടായിരുന്നില്ലെന്നും, സംഭവം നടന്നതിന് ശേഷമുള്ള പ്രൈവസി കമാൻഡ് ക്ലൗഡിലുള്ള ഡാറ്റയെ മുൻകാലപരമായി സംരക്ഷിക്കുന്നില്ലെന്നും വിമർശകർ ചൂണ്ടിക്കാട്ടുന്നു.

SpaceXAI-യുടെ മറുവാദം

മോഡൽ മെച്ചപ്പെടുത്തുന്നതിനായി ഉപയോഗ വിവരങ്ങൾ ശേഖരിക്കാനാണ് അപ്‌ലോഡ് ഫീച്ചർ ഉദ്ദേശിച്ചതെന്ന് SpaceXAI വാദിക്കുന്നു. ഫീച്ചർ വേഗത്തിൽ നിർത്തലാക്കിയതും നിലവിലുള്ള അപ്‌ലോഡുകൾ നീക്കം ചെയ്യുമെന്ന വാഗ്ദാനവും ഉത്തരവാദിത്തപരമായ പ്രതികരണത്തിന്റെ തെളിവായി അവർ ചൂണ്ടിക്കാട്ടുന്നു. എന്നാൽ തുടക്കത്തിലെ ഡിസൈനിൽ വ്യക്തമായ ഒരു ഒപ്റ്റ്-ഔട്ട് സംവിധാനം ഉണ്ടായിരുന്നില്ലെന്നും, ക്ലൗഡിൽ നേരത്തെ തന്നെ സംഭരിച്ച ഡാറ്റയെ സംരക്ഷിക്കുന്നതിൽ പ്രൈവസി കമാൻഡ് പരാജയപ്പെടുന്നുവെന്നും വിമർശകർ മറുപടി നൽകുന്നു.

പ്രധാന പാഠം

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