ஒரு AI-ஆல் உருவாக்கப்பட்ட cron job, ஒரு ஸ்டார்ட்அப்பில் இருந்த அனைத்துச் செயல்பாட்டிலுள்ள Stripe சந்தாக்களையும் (subscriptions) பத்து வினாடிகளுக்கும் குறைவான நேரத்தில் நீக்கிவிட்டது, இதனால் அந்த நிறுவனத்தின் மாதாந்திரத் தொடர் வருவாய் (MRR) $38 ஆகக் குறைந்தது. இந்தச் சம்பவம், ஆபத்து என்பது குறியீட்டை (code) எழுதிய மொழி மாதிரியில் (language model) இல்லை, மாறாக அது பயன்படுத்தப்படும் வரிசைப்படுத்தல் வழிமுறையில்தான் (deployment pipeline) உள்ளது என்பதைக் காட்டுகிறது.

என்ன நடந்தது

கடந்த வாரம் BridgeMindAI குழுவினர் விழித்தபோது, அவர்களின் டேஷ்போர்டில் மாதாந்திரத் தொடர் வருவாய் (MRR) வெறும் $38 மட்டுமே இருந்தது. ஒரு AI மாதிரி ஒரு வரியிலான குறியீட்டை உருவாக்கியது, அதைத் திட்டமிடுபவர் (scheduler) தானாகவே இயக்கினார். அந்த வரி ஒவ்வொரு வாடிக்கையாளர் பதிவிற்கும் Stripe-ன் subscription-cancellation endpoint-ஐ அழைத்தது. அந்த அழைப்பு ஏழு வினாடிகளில் முடிந்து, வாடிக்கையாளர் தரவுத்தளத்தையே அழித்துவிட்டது.

அந்த ஸ்கிரிப்ட், காலியாக இருந்த நீக்க வரிசையை (deletion queue), அனைத்தையும் நீக்குவதற்கான சமிக்ஞையாகத் தவறாகப் புரிந்துகொண்டது. அந்த “empty = all” என்ற முறை, generative AI உருவாவதற்கு நீண்ட காலத்திற்கு முன்பே, அதாவது 1980-களிலிருந்தே பயன்பாட்டு குறியீடுகளில் (production code) இருந்து வருகிறது.

ஏன் அந்த மாதிரி குற்றவாளி அல்ல

மக்கள் AI மாதிரியை நம்பகத்தன்மையற்றது என்று விரைவாகக் குற்றம் சாட்டினர். ஆனால் மாதிரியை மாற்றியிருந்தால் கூட இந்த அழிவைத் தடுத்திருக்க முடியாது, ஏனெனில் இதில் இருந்த குறைபாடு மனிதனால் எழுதப்பட்ட தர்க்கத்தில் (logic) இருந்ததே தவிர, அது ஒரு மாயத்தோற்றம் (hallucination) அல்லது சார்புநிலை (bias) அல்ல.

உண்மையான தோல்விகள் கட்டமைப்பு ரீதியானவை (architectural):

  • சந்தாக்களை ரத்து செய்யக்கூடிய நேரடிப் பயன்பாட்டு (live production) Stripe API சாவியை (key) அந்த ஸ்கிரிப்ட் சேமித்து வைத்திருந்தது.
  • அது எந்தவொரு இயக்கக் கண்காணிப்பும் (runtime supervision) இன்றி இயங்கியது.
  • குறியீடு உருவாக்கம் மற்றும் செயல்பாட்டிற்கு இடையில் எந்தவொரு மனிதக் கட்டுப்பாட்டுப் புள்ளியும் (human checkpoint) இல்லை.

இந்த இடைவெளிகளால்தான் ஒரு சிறிய பிழை (bug) சில வினாடிகளில் வருவாய் ஆதாரத்தையே அழித்தது.

எந்தவொரு தன்னாட்சி வழிமுறைக்கும் (autonomous pipeline) கேட்கப்பட வேண்டிய மூன்று பாதுகாப்பு கேள்விகள்

  1. எந்தச் செயல்பாடுகள் மாற்ற முடியாதவை (irreversible)? ஒரு சந்தாவை ரத்து செய்வது, ஒரு பதிவை நீக்குவது அல்லது பணத்தைத் திரும்பப் பெறுவது (refund) போன்றவற்றைத் திரும்பப் பெற முடியாது. எனவே, அவை 'read-only' வினவல்களை விட அதிகப் பாதுகாப்பைக் கோருகின்றன.

  2. அந்த ஏஜென்ட் (agent) என்ன அங்கீகாரத் தரவுகளை (credentials) வைத்துள்ளது? ஒரு தன்னாட்சிச் செயல்பாட்டிற்கு Stripe-ன் முதன்மைச் சாவியை (master key) வழங்குவது கட்டுப்பாடற்ற அதிகாரத்தை அளிக்கும். 'குறைந்தபட்ச அதிகாரக் கொள்கையை' (least-privilege principle) பின்பற்றுங்கள்: தேவையான பணியை மட்டுமே செய்யக்கூடிய குறிப்பிட்ட எல்லை கொண்ட சாவிகளை (scoped keys) பயன்படுத்துங்கள்.

  3. மனிதக் கட்டுப்பாட்டுப் புள்ளி எங்கே உள்ளது? குறியீடு ஆய்வு (code review) மட்டுமே போதுமானதல்ல. குறியீடு உருவாக்கப்பட்ட பிறகும், ஏதேனும் அழிவை ஏற்படுத்தும் செயலுக்கு முன்னும் ஒரு கட்டுப்பாட்டு நுழைவாயிலை (gate) உருவாக்குங்கள்.

நடைமுறைப் பாதுகாப்பு வழிமுறைகள்

  • Dry-run gate – ஏதேனும் நீக்குதல் அல்லது ரத்து செய்யும் அழைப்பிற்கு முன்னதாக, இலக்குகள் எவை என்பதைப் பதிவு (log) செய்யுங்கள். அந்தப் பட்டியல் காலியாக இருந்தாலோ அல்லது வழக்கத்திற்கு மாறாகப் பெரியதாக இருந்தாலோ, அந்தச் செயலை நிறுத்திவிட்டு ஒரு மனிதருக்குத் தகவல் தெரிவிக்கவும்.
  • Scoped credentials – இயல்பாகவே 'read-only' சாவிகளைப் பயன்படுத்துங்கள். ஒரு பணியின் மூலம் சந்தாவை ரத்து செய்ய வேண்டியிருந்தால், ஒரு நேரத்தில் ஒரு வாடிக்கையாளர் ID-யில் மட்டுமே செயல்படக்கூடிய ஒரு கட்டுப்படுத்தப்பட்ட சாவியை உருவாக்கவும்.
  • Human-in-the-loop prompt – ஒரு சேனலுக்கு (உதாரணமாக, Slack) “நான் 47 சந்தாக்களை ரத்து செய்யப் போகிறேன். உறுதிப்படுத்துகிறீர்களா?” என்பது போன்ற ஒரு சிறிய செய்தியை அனுப்பவும். இதற்கான செலவு மிகக் குறைவு; ஆனால் பாதுகாப்பு பல மடங்கு அதிகம்.

இந்த நடவடிக்கைகள் எந்த மாதிரியானது குறியீட்டை எழுதினாலும் வேலை செய்யும், ஏனெனில் இவை குறியீட்டை உருவாக்கும் கருவியைப் பாதுகாக்காமல், அது இயங்கும் சூழலைப் (execution environment) பாதுகாக்கின்றன.

தன்னாட்சி ஏஜென்ட்களுக்கான (autonomous agents) பயன்பாட்டுப் பட்டியல் (production checklist)

  • ஒவ்வொரு செயல்பாட்டையும் read, reversible, அல்லது irreversible என வகைப்படுத்துங்கள்.
  • அனைத்து irreversible செயல்களுக்கும் மனிதனின் தெளிவான ஒப்புதலைக் கோருங்கள்.
  • அந்தப் பணிக்குத் தேவையான குறைந்தபட்ச அனுமதிகளை மட்டுமே அங்கீகாரத் தரவுகளுக்கு (credentials) வழங்குங்கள்.
  • பதிவுகளை நீக்கும் அல்லது மாற்றும் லூப்களுக்கு (loops) அளவு வரம்புகளை (size limits) விதிப்பீர்கள்.
  • ஏஜென்ட்களை முதலில் பயன்பாட்டுத் தரவைப் பிரதிபலிக்கும் ஒரு சாண்ட்பாக்ஸில் (sandbox) இயக்கிப் பாருங்கள்; நேரடித் தரவைத் தொடும் முன் அதன் முடிவை உறுதிப்படுத்தவும்.
  • ஏஜென்ட்டின் திட்டத்தைச் செயல்படுத்துவதற்கு முன் எளிய மொழியில் பதிவு (log) செய்யுங்கள், இதனால் ஒரு ஆய்வாளர் அதன் நோக்கத்தை ஒரு பார்வையில் புரிந்துகொள்ள முடியும்.

இந்தச் சரிபார்ப்புப் பட்டியலைப் பின்பற்றுவதன் மூலம், “ஒருமுறை இயக்கிவிட்டு மறந்துவிடும்” ஸ்கிரிப்ட் என்பது, ஏதேனும் தவறு என்று தோன்றினால் ஆய்வு செய்யவும் மற்றும் நிறுத்தவும் கூடிய ஒரு கட்டுப்படுத்தப்பட்ட பணிப்பாய்வாக (controlled workflow) மாறும்.

பாடம் தெளிவானது: மாதிரியை நம்பாதீர்கள், செயல்முறையை நம்புங்கள்.