உங்கள் AI-ஆல் இயக்கப்படும் உதவியாளர் தனது அறிவுறுத்தல்களை 99% நேரங்களில் சரியாகப் பின்பற்றுகிறது, ஆனால் அந்த விடுபட்ட 1% தான் தாக்குதல்காரர்கள் தாக்கும் இடம். ஒரு நுணுக்கமான ப்ராம்ப்ட்டை (prompt) வழங்குவதன் மூலம், ஒரு தீய பயனர் மாடலைத் தான் செய்யக்கூடாத செயல்பாடுகளைச் செய்யத் தூண்ட முடியும், இதன் மூலம் தரவுகளைத் திருடவோ அல்லது முன்னுரிமை பெற்ற செயல்பாடுகளைச் செய்யவோ முடியும். இதற்கான தீர்வு இன்னும் மென்மையான வார்த்தைகளைப் பயன்படுத்துவதல்ல—இந்தக் குறையை ஒரு அங்கீகாரப் பிரச்சினையாக (authorization issue) கருதி, ஆபத்தான கருவிகளை மாடலின் அணுகலில் இருந்து நீக்குவதே ஆகும்.
ப்ராம்ப்ட் இன்ஜெக்ஷன் ஏன் வெறும் வார்த்தை சார்ந்த பிரச்சனை மட்டுமல்ல
டெவலப்பர்கள் பெரும்பாலும் பெரிய எழுத்துக்களில் எச்சரிக்கைகள், எண் வரிசைப்படுத்தப்பட்ட விதிகள் அல்லது "நிர்வாக செயல்பாடுகளை அழைக்க வேண்டாம்" போன்ற நிபந்தனைகளைப் பயன்படுத்தி ஏஜெண்டுகளைப் பாதுகாப்பதாக நினைக்கிறார்கள். இத்தகைய பாதுகாப்பு முறைகள், "X செய்ய வேண்டாம்" என்று சொல்லும் ஒரு வாக்கியத்தை மாடல் கீழ்ப்படியும் என்று கருதுகின்றன. நடைமுறையில், கோரிக்கையை மாற்றி அமைப்பதன் மூலமோ, வேறு ஒரு பாத்திரத்தை (persona) ஏற்று நடித்தாலோ அல்லது கூடுதல் சூழலைச் சேர்ப்பதன் மூலமோ அந்த அறிவுறுத்தலைப் புறக்கணிக்க மாடலைத் தூண்ட முடியும். ஆங்கில மொழி எல்லை என்பது நெகிழ்வானது; ஆனால் தாக்குதல்காரரின் ப்ராம்ப்ட் எல்லையற்றது மற்றும் அதைச் சோதிப்பதற்குச் செலவும் இல்லை.
உண்மையான பாதிப்பு ஏஜென்ட் பெறும் கருவிப் பட்டியலில் (tool list) உள்ளது. ப்ராம்ப்ட் ஸ்கீமாவில் (prompt schema) நிர்வாக உரிமைகளை வழங்கும் ஒரு செயல்பாடு (function) இருக்கும்போது, அந்த அதிகாரத்தை அடைவதற்கான வழி மாடலுக்குத் தெரிந்துவிடுகிறது. "வாடிக்கையாளர்களுக்கு இதைப் பயன்படுத்த வேண்டாம்" என்று ப்ராம்ப்ட்டில் கூறப்பட்டாலும், அந்தச் செயல்பாடு அதன் இயக்கச் சூழலில் (execution environment) இருப்பதால், மாடலை அதைச் செய்யத் தூண்ட முடியும். எனவே, இது ஒரு அங்கீகார இடைவெளி (authorization gap): உரிமையற்ற ஒரு பயனருக்குத் தகுதியுள்ள அதிகாரங்களை இந்த அமைப்பு வெளிப்படுத்துகிறது.
வெளிப்பாட்டைக் குறைப்பதன் மூலம் ஏஜெண்டுகளைப் பாதுகாத்தல்
இந்த இடைவெளியைக் குறைப்பதற்கான எளிய வழி, மாடலுக்கு அது பயன்படுத்த அதிகாரம் இல்லாத கருவிகளை வழங்குவதை நிறுத்துவதாகும். கருவிப் பட்டியலை ஒரு API key போலக் கருதவும்: அந்தச் சாவி இல்லையென்றால், அந்த அழைப்பு (call) நடக்க முடியாது. தற்போதைய சூழலில் இல்லாத ஒரு செயல்பாட்டை எந்தச் சிறந்த வார்த்தையாலும் வரவழைக்க முடியாது.
தவறான வழி
Prompt: “You are an assistant. Do not use the adminDeleteUser function for regular customers.”
மாடல் தனது கருவிப்பெட்டியில் adminDeleteUser என்பதை இன்னும் பார்க்கிறது, எனவே அதைச் செய்யத் தூண்டப்படலாம்.
சரியான வழி
Prompt schema for a regular customer: { “functions”: [ “searchCatalog”, “placeOrder” ] }
adminDeleteUser என்பது ஒருபோதும் தோன்றாது, எனவே மாடலுக்கு அதை அழைப்பதற்கான வழி இல்லை.
டெவலப்பர்களுக்கான மூன்று நடைமுறை விதிகள்
- ஒவ்வொரு கோரிக்கைக்கும் ஏற்ப கருவிப் பட்டியல்களை உருவாக்குங்கள் – அங்கீகரிக்கப்பட்ட பயனரின் அனுமதிகளின் அடிப்படையில், செயல்பாடுகளின் பட்டியலைத் (function catalog) தேவைக்கேற்ப உருவாக்கவும். ஒரு வாடிக்கையாளர் தனக்குத் தேவையான செயல்பாடுகளை மட்டுமே பார்ப்பார்; ஒரு நிர்வாகி முழுத் தொகுப்பையும் பார்ப்பார்.
- Fail closed (பாதுகாப்பாக மூடுதல்) – பயனரின் அடையாளம் சரிபார்க்கப்பட முடியாதபோது, "அனைத்து கருவிகளும் கிடைக்கும்" என்ற பொதுவான பதிலைத் தருவதற்குப் பதிலாக, ஒரு காலியான பட்டியலைத் திருப்பிக் கொடுக்கவும். இது அங்கீகரிக்கப்படாத கோரிக்கை எதிர்பாராத அதிகாரத்தைப் பெறுவதைத் தவிர்க்கிறது.
- பகிரப்பட்ட நிலையைத் (shared state) தவிர்க்கவும் – கருவி வரையறைகளை (tool definitions) சேமித்து வைக்கும்போது (caching), பயனர் சார்ந்த தரவுகளை ஒரு பகிரப்பட்ட பொருளின் (shared object) மீது எழுத வேண்டாம். ஒரு பயனரின் அனுமதிகள் மற்றொரு பயனரின் கோரிக்கையில் கலக்காமல் இருக்க, copy-on-write அல்லது ஒவ்வொரு அமர்வுக்கும் (per-session) தனித்தனி நகல்களைப் பயன்படுத்தவும்.
ஒரு சாதாரண பயனருக்குக் காட்டப்படும் ஸ்கீமாவும், நிர்வாகிக்குக் காட்டப்படும் ஸ்கீமாவும் ஒரே மாதிரியாக இருந்தால், பாதுகாப்பு எல்லை இன்னும் ப்ராம்ப்ட் உரையாகவே இருக்கும், மேலும் ப்ராம்ப்ட்கள் ஒரு நம்பகமான பாதுகாப்பு வழிமுறை அல்ல.
இது எப்படி நிகழ்ந்தது
டெவலப்பர்கள் பெரிய மொழி மாதிரிகளை (LLMs) வெளிப்புற API-களை அழைக்கவோ, குறியீடுகளை இயக்கவோ அல்லது தரவுத்தளங்களை மாற்றியமைக்கவோ தேவைப்படும் உற்பத்திப் பணிப்பாய்வுகளில் (production workflows) இணைக்கத் தொடங்கியபோது ப்ராம்ப்ட் இன்ஜெக்ஷன் உருவானது. மாடலின் "சிந்தனைத் திறன்" (reasoning) என்பது கிடைக்கக்கூடிய கருவிகளின் பட்டியலை உள்ளடக்கிய ஒரு ப்ராம்ப்ட் மூலம் வழிநடத்தப்படுகிறது. ஆரம்பகால முன்மாதிரிகள், "நிர்வாகிகள் அல்லாதவர்களுக்காகப் பதிவுகளை நீக்க வேண்டாம்" போன்ற இயற்கை மொழி விதியைப் மாடல் பின்பற்றும் என்று கருதின. ஆனால், சில கூடுதல் வாக்கியங்கள் அந்த விதிகளைத் தாண்டி, அதே நீக்கும் செயல்பாட்டை (delete function) அழைக்க மாடலைத் தூண்டும் என்று தாக்குதல்காரர்கள் விரைவாக நிரூபித்தனர்.
சமூகத்தின் முதல் எதிர்வினை, ப்ராம்ப்ட் மொழியை இறுக்கமாக்குவது, "X செய்ய வேண்டாம்" போன்ற நிபந்தனைகளைச் சேர்ப்பது அல்லது சந்தேகத்திற்கிடமான டோக்கன்களை நீக்கும் regex வடிகட்டிகளைப் பயன்படுத்துவது ஆகியவற்றாக இருந்தது. அந்த நடவடிக்கைகள் தற்செயலான தவறான பயன்பாட்டைக் குறைத்தன, ஆனால் கோரிக்கையை மாற்றி அமைக்கும் ஒரு விடாமுயற்சியுள்ள எதிரியைத் தடுக்கவில்லை. அடிப்படையான காரணம்—அதிகாரம் இல்லாத பயனருக்கு முன்னுரிமை பெற்ற செயல்பாடுகளை வெளிப்படுத்துவது—தொடர்ந்தது.
யார் வெற்றி பெறுகிறார்கள், யார் பாதிக்கப்படுகிறார்கள்
ஒவ்வொரு கோரிக்கைக்கும் ஏற்ப கருவி வரம்புகளை (per-request tool scoping) பின்பற்றும் நிறுவனங்கள் ஒரு தெளிவான, நடைமுறைப்படுத்தக்கூடிய எல்லையைப் பெறுகின்றன. ஒரு தவறான ப்ராம்ப்ட் நிர்வாக அதிகாரங்களைத் திறந்துவிடும் என்ற பயமின்றி, அவர்களின் ஏஜெண்டுகளைப் பெரிய அளவில் பயன்படுத்த முடியும். தணிக்கைப் பதிவுகளையும் (audit trail) இணக்கக் குழுக்கள் (compliance teams) பாராட்டுகின்றன: மாடலுக்கு அனுப்பப்படும் செயல்பாடுகளின் பட்டியல் ஒரு உறுதியான ஆவணமாகும், அதைத் தணிக்கை செய்து ஆய்வு செய்யலாம்.
ப்ராம்ப்ட் மட்டுமே பாதுகாப்பாக இருக்கும் என்று நம்பும் டெவலப்பர்கள் தொடர்ந்து சவால்களைச் சந்திக்க நேரிடும். அவர்களின் ஏஜெண்டுகள் சோதனையில் சரியாகத் தோன்றலாம், ஆனால் நிஜ உலகில் அவை ஊடுருவப்படலாம், இது தரவுத் திருட்டு, அங்கீகரிக்கப்படாத பரிவர்த்தனைகள் அல்லது இணக்க விதிமீறல்களுக்கு வழிவகுக்கும். ஒரு பாதுகாப்பு மீறலின் பாதிப்பு, ஒரு மாறும் கருவிப் பட்டியலை உருவாக்குவதற்கான முயற்சியை விடப் பல மடங்கு அதிகம்.
எதிர் வாதம்: “சிறந்த ப்ராம்ப்ட்கள் போதுமானவை”
போதுமான அறிவுறுத்தல் பொறியியல் (instruction engineering)—அடுக்குமுறைத் தூண்டுதல்கள் (layered prompts), அமைப்புச் செய்திகள் (system messages) மற்றும் மனித பின்னூட்டத்திலிருந்து வலுவூட்டல் கற்றல் (reinforcement learning from human feedback)—மூலமாக, ஒரு மாடல் “செய்யக்கூடாது” (do not) என்ற நிபந்தனைகளை மதிக்கும்படி செய்ய முடியும் என்று சிலர் வாதிடுகின்றனர். உண்மை என்னவென்றால், மொழி மாதிரிகள் (language models) நிகழ்தகவு அடிப்படையிலான உருவாக்கிகள் (probabilistic generators); அவை ஒரு கடினமான பாதுகாப்பு விதியைப் பின்பற்றுவதற்குப் பதிலாக, மிகவும் சாத்தியமான தொடர்ச்சியை மட்டுமே கணக்கிடுகின்றன. நுணுக்கமாகச் செதுக்கப்பட்ட பாதுகாப்பு வளையங்கள் (guardrails) இருந்தாலும், ஒரு புதிய வகை வாக்கிய அமைப்பு மூலம் பாதுகாப்பு மீறல்கள் நிகழக்கூடும், குறிப்பாகத் தாக்குபவர் எந்தச் செலவும் இன்றித் தொடர்ந்து முயற்சிகளைச் செய்து கொண்டே இருக்கும்போது இது சாத்தியமாகும். பாதுகாப்பு வளையங்கள் தேவையற்ற இடையூறுகளைக் குறைக்கப் பயனுள்ளவை, ஆனால் அவை மட்டுமே பாதுகாப்பிற்கான ஒரே அரணாக இருக்கக்கூடாது.
அடுத்து கவனிக்க வேண்டியவை
- கருவி வரம்பை (tool scoping) ஒரு முதன்மையான API ஆக வெளிப்படுத்தும் கட்டமைப்புகள் (Frameworks) – பயனருக்குத் தேவையான திறன்களை மட்டும் அறிவிக்கவும், தூண்டுதல் (prompt) உருவாக்கப்படுவதற்கு முன்பே செயல்பாடுகளின் பட்டியலைத் தானாகவே சுருக்கும் (prune) புதிய நூலகங்களை (libraries) எதிர்பார்க்கலாம்.
- தரப்படுத்தப்பட்ட “செயல்பாட்டுப் பட்டியல்கள்” (function manifests) – பொதுவான மற்றும் சிறப்பு அதிகாரங்களைக் கொண்ட செயல்பாடுகளைப் பிரிக்கும் ஒரு JSON schema-வை தொழில்முறை குழுக்கள் வரையறுக்கலாம், இது கோரிக்கைக்குத் தேவையான பட்டியல்களை உருவாக்குவதை எளிதாக்கும்.
- இயக்கநேர அமலாக்கம் (Runtime enforcement) – சில தளங்கள், தூண்டுதல் வரம்பிற்கு (prompt scoping) அப்பால் ஒரு கூடுதல் பாதுகாப்பைச் சேர்க்க, அழைப்பவரின் டோக்கனை (token) அழைக்கப்படும் செயல்பாட்டுடன் ஒப்பிட்டுச் சரிபார்க்கும் சாண்ட்பாக்ஸ் (sandboxed) முறையில் இயங்கும் செயல்பாடுகளைச் சோதித்து வருகின்றன.
இதிலிருந்து நாம் அறிந்துகொள்ள வேண்டியது தெளிவானது: 'ப்ராம்ப்ட் இன்ஜெக்ஷன்' (prompt injection)-ஐ ஒரு அங்கீகாரக் குறைபாடாக (authorization flaw) கருதுங்கள். மாடலின் கருவிப்பெட்டியிலிருந்து (toolbox) அங்கீகரிக்கப்படாத கருவிகளை நீக்குவதன் மூலம், புத்திசாலித்தனமாகத் திட்டமிடப்பட்ட தூண்டுதல்கள் மூலம் தாக்கமடையக்கூடிய இடங்களை (attack surface) நீங்கள் தவிர்க்கலாம். தூண்டுதல்கள் நடத்தையை வழிநடத்தலாம்; ஆனால் அவை முறையான அணுகல் கட்டுப்பாட்டை (access control) மாற்றீடு செய்ய முடியாது.