LLM பாதுகாப்பு என்றால் என்ன? OWASP Top 10 பாதுகாப்பு அபாயங்களைக் குறைப்பது எப்படி

தாக்குதல் நடத்துபவரின் அறிவுறுத்தல்களைக் கட்டளைகளாகக் கருதும்படி AI-ஐ ஏமாற்றும் தாக்குதலான ப்ராம்ப்ட் இன்ஜெக்ஷன் (prompt injection), 2023 முதல் வெளியான ஒவ்வொரு பதிப்பிலும் LLM பயன்பாடுகளுக்கான OWASP Top 10 பட்டியலில் முதலிடத்தில் உள்ளது.

AI பாதுகாப்புத் துறையில் ஒருமித்த கருத்துக்கு மிக நெருக்கமாக வரும் ஒன்று இந்தப் பட்டியல்தான். பாதுகாப்பு வல்லுநர்களின் ஒரு சிறிய குழுவாகத் தொடங்கிய இந்தத் திட்டம், இப்போது 18-க்கும் மேற்பட்ட நாடுகளைச் சேர்ந்த 600-க்கும் மேற்பட்ட பங்களிப்பு நிபுணர்களின் உதவியைப் பெறுகிறது.

AI எப்படிப் பேச்சால் ஏமாற்றப்பட்டு இணங்க வைக்கப்படுகிறது என்பது குறித்த வழிகாட்டியை வெளியிடும் ஒரு AI நிறுவனம் நாங்கள்; எனவே இந்தச் சிக்கல் தீர்ந்துவிட்டதாகப் பாசாங்கு செய்யப் போவதில்லை. OWASP திட்டத்தின் இணைத் தலைவரான Wilson, தற்போதைய தற்காப்பு முறைகள் குறித்து மிகத் தெளிவாகவே கூறினார்: "...வெளிப்படையாகச் சொன்னால், நாம் 99% நிலையை எட்டியிருப்பதாக நான் நினைக்கவில்லை."

2026 பதிப்பும் இதே தொனியில்தான் தொடங்குகிறது. "ஏமாற்ற முடியாத ஒரு மாடலை உருவாக்க முயற்சிப்பதை நிறுத்துங்கள்" என்றும், ஏமாற்றப்பட்ட மாடல் முக்கியமான எதையும் சேதப்படுத்த முடியாதபடி அதைச் சுற்றியுள்ள அமைப்பை வடிவமைக்குமாறும் திட்டத் தலைவர் நமக்கு அறிவுறுத்துகிறார்.

OWASP-இன் 2026 பட்டியலில் உள்ள 10 அபாயங்கள் அனைத்தையும் இதே கண்ணோட்டத்துடன் அணுகுகிறோம்.

LLM பாதுகாப்பு என்றால் என்ன?

LLM பாதுகாப்பு என்பது AI மாடல்களையும் அவற்றைப் பயன்படுத்தும் பயன்பாடுகளையும் தாக்குதல்கள் மற்றும் தவறான பயன்பாட்டிலிருந்து பாதுகாப்பதாகும். மாடல் எவற்றுடன் இணைக்கப்பட்டுள்ளது என்பதைப் பொறுத்து அபாயமும் அதிகரிக்கிறது: அது படிக்கக்கூடிய கோப்புகள் மற்றும் தரவு, அது பயன்படுத்தக்கூடிய மின்னஞ்சல், தேடல் அல்லது நிறுவனத் தரவுத்தளம் போன்ற கருவிகள்.

முறையாகப் பாதுகாக்கப்பட்ட மென்பொருளில், ஒரு நிரல் பின்பற்றும் அறிவுறுத்தல்களுக்கும் அது செயலாக்கும் தகவலுக்கும் இடையே உறுதியான எல்லைக்கோடு இருக்கும். ஆனால் LLM-களில் அந்த எல்லைக்கோடு இல்லை.

மாடல் படிக்கும் அனைத்தும் ஒரே நீண்ட உரைத் தொடராகவே வந்து சேர்கின்றன: டெவலப்பரின் அறிவுறுத்தல்கள், உங்கள் கேள்வி, அது தேடிப் பார்த்த ஒரு வலைப்பக்கம். பேசுவது யார் என்பதை—அது டெவலப்பரா, பயனரா, அல்லது ஒரு சிக்கலைப் பற்றிச் சிந்தித்துக்கொண்டிருக்கும் மாடலேதானா என்பதை—AI மாடல்கள் கவனத்தில் வைத்துக்கொள்ள வேண்டும்.

ஆனால், உரை எப்படி ஒலிக்கிறது என்பதை வைத்தே பேசுவது யார் என்பதை மாடல்கள் பெரும்பாலும் ஊகிக்கின்றன என்று ஆய்வாளர்கள் Jasmine Cui மற்றும் Charles Ye கண்டறிந்தனர். எனவே, மாடலின் சொந்தப் பகுத்தறிதலைப் போல ஒலிக்கும் ஒன்றைத் தாக்குதல் நடத்துபவர் எழுதினால், அந்த யோசனை தனக்குத்தானே தோன்றியதாக மாடல் நம்பக்கூடும். யார் பொறுப்பில் இருக்கிறார்கள் என்பதை மாடல் அறிந்திருப்பதைச் சார்ந்திருக்கும் எந்தவொரு பாதுகாப்பு அமைப்புக்கும் இது ஒரு சிக்கல்.

எங்கள் சொந்த AI ஏஜென்ட்களிலும் இதே சிக்கலை நாங்கள் சந்தித்திருக்கிறோம். ஏஜென்ட்கள் "சிஸ்டம் ப்ராம்ப்ட்டில் சேர்த்தாலும் கொள்கைகளைப் பின்பற்றாமல் போகக்கூடும்" என்று எங்கள் CISO Kyle Polley ISMG-இடம் கூறினார். அதனால்தான், ஒரு ஏஜென்ட் என்ன செய்யவிருக்கிறது என்பதைச் சரிபார்த்து, அந்தச் செயல் உள்ளமைக்கப்பட்ட பாதுகாப்பு விதியை மீறினால் அதைத் தடுக்கக்கூடிய Numbat என்ற ஓப்பன் சோர்ஸ் கருவியை நாங்கள் உருவாக்கினோம்.

LLM பாதுகாப்பு என்பது, மாடல் சில நேரங்களில் தவறான நபரிடமிருந்து கட்டளைகளை ஏற்கும் என்பதை ஏற்றுக்கொள்வதும், அப்படி நடக்கும்போதும் உறுதியாக நிற்கும் AI பாதுகாப்பு வரம்புகளை அதைச் சுற்றி அமைப்பதும் ஆகும்.

LLM பாதுகாப்புக்கான சிறந்த நடைமுறைகள் யாவை?

LLM பயன்பாடுகளுக்கான OWASP Top 10 2026 பட்டியலை, எண் 1 முதல் எண் 10 வரை வரிசையாகப் பார்ப்போம்.

ஒவ்வொரு அபாயத்துக்கும், விஷயங்கள் எப்படித் தவறாகப் போகின்றன என்பதற்கான எளிய விளக்கத்தையும் ஒரு நிஜ உலக உதாரணத்தையும் தருகிறோம். பின்னர், அதைத் தடுக்க உதவும் அல்லது குறைந்தபட்சம் சேதத்தைக் கட்டுப்படுத்தும் நடைமுறைகளைப் பார்ப்போம்.

1. ப்ராம்ப்ட் இன்ஜெக்ஷனைக் கட்டுப்படுத்துங்கள்

AI பின்பற்றக்கூடாத அறிவுறுத்தல்களை, தாக்குதல் நடத்துபவர் அதைப் பின்பற்ற வைக்கும்போது ப்ராம்ப்ட் இன்ஜெக்ஷன் நிகழ்கிறது. அந்த அறிவுறுத்தல்கள் நேரடியாக அரட்டையில் வரலாம், அல்லது மின்னஞ்சல், வலைப்பக்கம் அல்லது ஆவணத்தில் மறைத்து வைக்கப்படலாம்.

இரண்டாவது வகை மறைமுக ப்ராம்ப்ட் இன்ஜெக்ஷன் என்று அழைக்கப்படுகிறது. ஒரு ஆவணத்தைச் சுருக்கித் தருமாறு உங்கள் உதவியாளரிடம் கேட்கிறீர்கள். ஆனால் உங்கள் தனிப்பட்ட கோப்புகளைத் தங்களுக்கு அனுப்புமாறு அவர்கள் அந்த உதவியாளரிடம் கூறியிருக்கிறார்கள். உதவியாளர் அந்த அறிவுறுத்தல்களைப் பின்பற்றினால், ஆவணத்தை எழுதியவர் உங்கள் அணுகலை நடைமுறையில் இரவல் வாங்கிவிட்டார் என்றே பொருள்.

PCMag ப்ராம்ப்ட் பாதுகாப்பை, நுண்துளைகள் நிறைந்த கல்லில் உள்ள ஓட்டைகளை அடைப்பதோடு ஒப்பிடுகிறது. ஒரு துளையை அடைத்தால், தண்ணீர் இன்னொரு வழியைக் கண்டுபிடித்துவிடுகிறது. “ஒரு தாக்குதல் உள்ளே நுழைய வழி கண்டுபிடிக்கிறது; அது சரிசெய்யப்படுகிறது, ஆனால் LLM-கள் போன்ற அமைப்புகள் எவ்வளவு மாறும் தன்மை கொண்டவை என்பதாலேயே, கண்டறியப்பட வேண்டிய எண்ணற்ற பிற தாக்குதல் வழிகள் இன்னும் மீதமிருக்கின்றன.”

உதாரணம்: ஜூன் 2025-இல், Aim Security ஆய்வாளர்கள் EchoLeak என்ற குறைபாட்டைக் கண்டறிந்தனர்; இது Microsoft 365 Copilot-ஐ ஏமாற்றி, நிறுவனத்தின் தனிப்பட்ட தகவல்களைக் கசியவிடச் செய்தது. ஒரு ஊழியர் வழக்கமான பணி தொடர்பான கேள்வியைக் கேட்டபோது, Copilot அந்த மின்னஞ்சலை எடுத்து, அதற்குள் மறைத்து வைக்கப்பட்ட அறிவுறுத்தல்களைப் பின்பற்றி, உணர்திறன் மிக்க தகவல்களைத் தாக்குதல் நடத்துபவருக்கு அனுப்ப முடிந்தது. தீங்கிழைக்கும் அறிவுறுத்தல்களைப் பிடிக்கவும் சந்தேகத்துக்குரிய இணைப்புகளை அகற்றவும் வடிவமைக்கப்பட்ட சோதனைகளை இந்தத் தாக்குதல் தாண்டிச் சென்றது.

நீங்கள் என்ன செய்யலாம்:

• Meta-வின் “இரண்டின் விதி”-யைப் பின்பற்றுங்கள்: EchoLeak செயல்பட, நிறுவனத் தரவைப் படிக்கவும், வெளி மின்னஞ்சல்களைப் படிக்கவும், தகவலை வெளியே அனுப்பவும் கூடிய AI தேவைப்பட்டது—அதற்கு இந்த மூன்று திறன்களும் இருந்தன. இவற்றில் இரண்டு திறன்களுக்கு மட்டும் அதை வரம்பிடுவது, ப்ராம்ப்ட் இன்ஜெக்ஷன் அளவுக்கு அதிகமான கட்டுப்பாட்டைப் பெறுவதைத் தடுக்கிறது. பணிக்கு மூன்றும் தேவைப்பட்டால், ஒவ்வொரு செயலுக்கும் முன் மனித ஒப்புதலைக் கட்டாயமாக்குங்கள்.
• உங்கள் தற்காப்புகளை அறிந்த தாக்குதல் நடத்துபவர்களுக்கு எதிராகச் சோதியுங்கள்: நீங்கள் அமைத்துள்ள விதிகளையும் வடிகட்டிகளையும் உங்கள் பாதுகாப்புச் சோதனையாளர்களிடம் கொடுத்து, அவற்றைத் தாண்டிச் செல்ல அவர்களை அனுமதியுங்கள். ஒரு ஆய்வில், சோதிக்கப்பட்ட 12 தற்காப்பு முறைகளில் பெரும்பாலானவற்றுக்கு எதிராக, தற்காப்புகளுக்கு ஏற்பத் தங்களை மாற்றிக்கொண்ட தாக்குதல் நடத்துபவர்கள் 90%-க்கும் அதிகமான முறை வெற்றி பெற்றனர்.

2. உணர்திறன் மிக்க தகவல்கள் கசிவதைத் தடுங்கள்

பார்க்கக்கூடாத நபர்களுக்கு AI அமைப்புகள் தனிப்பட்ட தகவல்களை வழங்கும்போது, அது உணர்திறன் மிக்க தகவல் வெளிப்படுத்தல் எனப்படுகிறது. இது ஒரு வாடிக்கையாளரின் கட்டண விவரங்களை வெளிப்படுத்துவதாகவோ, தனிப்பட்ட உரையாடல்களைப் பகிரப்பட்ட தரவுத்தளத்தில் விட்டுவைப்பதாகவோ இருக்கலாம்.

பல கசிவுகள் “அதிகப்படியான பகிர்வில்” தொடங்குகின்றன. ஒரு நிறுவனம் தனது AI-ஐ, தளர்வான அனுமதிகளைக் கொண்ட டிரைவ்கள் மற்றும் அறிவுத் தளங்களுடன் இணைக்கிறது என்று வைத்துக்கொள்வோம். வடிவமைக்கப்பட்டபடியே, AI தன்னால் அணுக முடிந்த அனைத்தையும் மீட்டெடுக்கிறது. யாரும் உள்ளே ஊடுருவ வேண்டியதில்லை; ஆனால் LLM ஏற்கெனவே ஊடுருவப்பட்டதாகவே கருதுங்கள்.

உதாரணம்: ஜனவரி 2025-இல், இணையத்தில் திறந்த நிலையில் இருந்த DeepSeek தரவுத்தளம் ஒன்றை Wiz ஆய்வாளர்கள் கண்டறிந்தனர்; அதில் அரட்டை வரலாறு, API கீகள் (பிற சேவைகளை அணுக மென்பொருள் பயன்படுத்துபவை) உட்பட பத்து லட்சத்துக்கும் மேற்பட்ட பதிவுகள் இருந்தன. எதையும் வெளிப்படுத்துமாறு மாடலை வற்புறுத்த வேண்டிய அவசியம் ஆய்வாளர்களுக்கு ஏற்படவில்லை.

நீங்கள் என்ன செய்யலாம்:

• AI தரவைப் படிப்பதற்கு முன் அணுகலைச் சரிபாருங்கள்: கேள்வி கேட்கும் நபர் எந்த ஆவணங்களைப் பார்க்க அனுமதிக்கப்பட்டுள்ளார் என்பதை, அவற்றை மாடலுக்கு அனுப்புவதற்கு முன்பே உங்கள் பயன்பாடு சரிபார்க்க வேண்டும்.
• உங்கள் AI விட்டுச்செல்லும் பதிவுகளைப் பாதுகாருங்கள்: செயல்பாட்டுப் பதிவுகளைச் சேமிப்பதற்கு முன் தனிப்பட்ட விவரங்களையும் ரகசியக் கீகளையும் அகற்றுங்கள், உள்நுழைவைக் கட்டாயமாக்குங்கள், தேவைப்படுபவர்களுக்கு மட்டுமே அணுகலை வரம்பிடுங்கள். அந்தப் பதிவுகள் காலவரையின்றிக் குவிந்துவிடாமல் இருக்க, ஒரு தக்கவைப்புக் காலத்தை அமையுங்கள்.

3. அளவுக்கு மீறிய செயல் அதிகாரத்தைக் கட்டுப்படுத்துங்கள்

அளவுக்கு மீறிய செயல் அதிகாரம் கொண்ட AI-கள், அவற்றின் பணிக்குத் தேவையானதைவிட அதிக அதிகாரத்தைக் கொண்டுள்ளன: தேவையில்லாத கருவிகள், பணிக்கு அப்பாற்பட்ட அனுமதிகள், அல்லது சரிபார்க்காமலேயே செயல்படும் சுதந்திரம். இங்கே காரணம் முக்கியமல்ல.

ஒரு இன்ஜெக்ஷன் ப்ராம்ப்ட், ஒரு பிழை, அல்லது வெறுமனே தவறு செய்யும் ஒரு மாடல்—இவை அனைத்தும் ஒரே விளைவுக்கே இட்டுச் செல்கின்றன. AI-க்கு அதற்கான திறன் இருந்தால், அது இறுதியில் ஏதாவது அழிவுகரமான செயலைச் செய்யும்.

உதாரணம்: ஜூலை 2025-இல், SaaStr நிறுவனர் Jason Lemkin, மாற்றங்கள் எதுவும் செய்யக்கூடாது என்ற அறிவுறுத்தல்கள் இருந்தபோதிலும் Replit-இன் கோடிங் ஏஜென்ட் 1,206 நிர்வாகிகளின் பதிவுகளைக் கொண்ட தனது தரவுத்தளத்தை நீக்கிவிட்டதாகத் தெரிவித்தார். தரவை மீட்டெடுக்க முடியாது என்று ஏஜென்ட் முதலில் கூறியது; ஆனால் பின்னர் மீட்டெடுப்பு சாத்தியம் என்று தெரியவந்தது. தரவுத்தளத்தைத் தொடாமல் விடுமாறு அதனிடம் சொன்னது, அதை நீக்கும் அதன் திறனை அகற்றவில்லை என்பதை 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-இன் சர்வர்களில் குறியீட்டை இயக்க அனுமதிக்கும் குறைபாடுகளை அந்த ஏஜென்ட்கள் தொடர்ந்து பயன்படுத்திக்கொண்டன.

“ஒரு மாடலின் வாழ்க்கைச் சுழற்சி முழுவதும் சீரமைப்பு (alignment) தொடர்பான கடுமையான தேவைகளை விதிக்கிறோம்; மேலும், கூடுதலாகத் தனிமைப்படுத்தப்பட்ட சாண்ட்பாக்ஸ்களை உருவாக்குகிறோம், இணைய அணுகலைக் கட்டுப்படுத்துகிறோம், மாடல் வெயிட்களுக்கான அணுகலை மேலும் இறுக்கமாகக் கட்டுப்படுத்துகிறோம்,” என்கிறது OpenAI அறிக்கை.

நீங்கள் என்ன செய்யலாம்:

• மாடல்களைத் துல்லியமான பதிப்பில் நிலைநிறுத்தி அவற்றைச் சரிபாருங்கள்: ஒவ்வொரு மாடலையும் மதிப்பாய்வு செய்யப்பட்ட ஒரு பதிப்பில் நிலைநிறுத்தி, அதை ஏற்றுவதற்கு முன் அதன் கோப்புக் கைரேகையை (fingerprint) சரிபாருங்கள்; இதனால், மாற்றப்பட்ட ஒரு கோப்பு அதே லேபிளின் கீழ் நுழைந்துவிட முடியாது. OWASP டிஜிட்டல் கையொப்பங்களையும் பரிந்துரைக்கிறது, ஓர் எச்சரிக்கையுடன்—ஒரு கையொப்பம், மாடல் எங்கிருந்து வந்தது என்பதை நிரூபிக்கிறதே தவிர, அது பாதுகாப்பானது என்பதை அல்ல.
• உங்கள் AI பரிந்துரைக்கும் ஒவ்வொரு தொகுப்பையும் சரிபாருங்கள்: AI உதவியாளர் பரிந்துரைத்த குறியீட்டுத் தொகுப்பை நிறுவுவதற்கு முன், அது உண்மையில் இருக்கிறதா, நீங்கள் நினைத்த தொகுப்புதானா, நீங்கள் எதிர்பார்க்கும் வெளியீட்டாளரிடமிருந்து வருகிறதா என்பதை உறுதிப்படுத்துங்கள்.

5. தரவு மற்றும் மாடல் நச்சூட்டலுக்கு எதிராகத் தற்காத்துக்கொள்ளுங்கள்

நச்சூட்டப்பட்ட AI, சிதைக்கப்பட்ட தரவிலிருந்து கற்றுக்கொள்கிறது. அது, மாடல் ஃபைன்-ட்யூன் செய்யப்பட்ட உதாரணங்களாக இருக்கலாம், அல்லது பதில்களுக்காக அது தேடும் அறிவுத் தளமாக இருக்கலாம். மாடல் இன்னும் சரியாக வேலை செய்வதுபோலவே தோன்றும்; அது தவறான பாடங்களைக் கற்றுக்கொள்கிறது, அவ்வளவுதான். சில நேரங்களில், ஒரு குறிப்பிட்ட தூண்டுதல் சொற்றொடரைப் பார்க்கும்போது மட்டும் தவறாக நடந்துகொள்ளவும் அது கற்றுக்கொள்கிறது.

யாராவது அந்தச் சொற்றொடரைப் பயன்படுத்தும் வரை, நீங்கள் வைக்கும் ஒவ்வொரு சோதனையிலும் அது தேறிவிடும்.

விரிவாக்கு

மேலும், இதைச் சரிசெய்வது மிகவும் கடினம். நச்சூட்டல் என்பது பேட்ச் செய்து சரிசெய்யக்கூடிய ஒரு பிழை அல்ல. உங்கள் தரவு தவறாக இருந்தால், அதை மீண்டும் சரிபார்க்கவோ, மாடலை மீண்டும் பயிற்றுவிக்கவோ, அல்லது அதை முழுமையாக மாற்றவோ வேண்டியிருக்கலாம்.

உதாரணம்: அக்டோபர் 2025-இல், Anthropic, UK AI Security Institute, Alan Turing Institute ஆகியவற்றின் ஆய்வாளர்கள், ஒரு குறிப்பிட்ட தூண்டுதலை எதிர்கொள்ளும்போதெல்லாம் அர்த்தமற்ற உளறலை உருவாக்க ஒரு மாடலுக்குக் கற்பிக்க 250 நச்சூட்டப்பட்ட ஆவணங்களே போதும் என்று காட்டினர். சோதிக்கப்பட்ட நான்கு மாடல் அளவுகளிலும் இதே எண்ணிக்கை வேலை செய்தது—மிகப்பெரிய மாடல் 20 மடங்குக்கும் அதிகமான சுத்தமான தரவில் பயிற்றுவிக்கப்பட்டிருந்தும் கூட.

நீங்கள் என்ன செய்யலாம்:

• உங்கள் தரவு எங்கிருந்து வருகிறது என்பதைக் கண்காணியுங்கள்: நீங்கள் பயன்படுத்தும் ஒவ்வொரு தரவுத்தொகுப்பு மற்றும் மாடல், ஒவ்வொன்றும் எங்கிருந்து வந்தது, பதிப்புகளுக்கு இடையே என்ன மாறியது என்பதைப் பதிவுசெய்து வையுங்கள். தரவுத்தொகுப்புகளுக்குப் பதிப்புக் கட்டுப்பாட்டை (version control) பரிந்துரைக்கிறோம்; இதனால் நச்சூட்டல் கண்டறியப்பட்டால், சுத்தமான பதிப்புக்குத் திரும்பிச் சென்று, அது எப்படி உள்ளே நுழைந்தது என்பதைக் கண்டறிய முடியும்.
• பின்கதவுகள் உள்ளனவா என்று சோதியுங்கள்: “பின்கதவு” (backdoor) என்பது, தாக்குதல் நடத்துபவர் ஒரு மாடலில் பதிக்கும் மறைவான நடத்தையாகும்; அதைச் செயல்படுத்தும் ஒரு குறிப்பிட்ட சொற்றொடருக்காகவோ பிற தூண்டுதலுக்காகவோ அது காத்திருக்கும். மாடல் அதன் வழக்கமான விதிகளை மீறும்படி வடிவமைக்கப்பட்ட உள்ளீடுகளைக் கொண்டு இவற்றைச் சோதியுங்கள்.

6. வரம்பற்ற நுகர்வுக்கு உச்சவரம்பு விதியுங்கள்

AI-கள் எவ்வளவு வேலை செய்யலாம், அல்லது அவற்றுக்கு எவ்வளவு செலவாகலாம் என்பதற்கு எந்த வரம்பும் இல்லாதபோது, அவற்றின் நுகர்வு “வரம்பற்றது” என்று கருதப்படுகிறது. பெரும்பாலான AI சேவைகள் பயன்பாட்டுக்கு ஏற்பக் கட்டணம் வசூலிக்கின்றன; எனவே, தாக்குதல் நடத்துபவர் உங்கள் கட்டணத்தைப் பெருமளவில் உயர்த்தலாம் அல்லது உங்கள் மாடலின் நகலை உருவாக்கலாம்.

OWASP இந்த அடிப்படைச் சிக்கலை “செலவுச் சமச்சீரின்மை” (cost asymmetry) என்று அழைக்கிறது. சுருக்கமான, மலிவான ஒரு கோரிக்கை, உங்கள் தரப்பில் விலையுயர்ந்த கணக்கீட்டைத் தூண்டக்கூடும்.

உதாரணம்: மே 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-வைப் பயன்படுத்தியது வெளிப்படுத்தப்பட்டது; இறுதித் தவணையைத் திருப்பிச் செலுத்தவும் அந்த நிறுவனம் ஒப்புக்கொண்டது. துரதிர்ஷ்டவசமாக, இது ஓர் உறுதிப்பாட்டு மதிப்பாய்வு (assurance review) ஆகும்.

நீங்கள் என்ன செய்யலாம்:

• பதிலைச் சான்றுகள் ஆதரிக்கின்றனவா என்று சரிபாருங்கள்: கூற்றுகளை நடப்பில் உள்ள, அதிகாரப்பூர்வமான ஆதாரங்களின் அடிப்படையில் அமையுங்கள். ஒரு கொள்கை தொடர்பான பதிலுக்கு, அங்கீகரிக்கப்பட்ட கொள்கையை மீட்டெடுத்து, அதன் விதிவிலக்குகள் உட்பட, அது முடிவை ஆதரிக்கிறதா என்று சரிபாருங்கள்.
• அமைப்பு செயல்படுவதற்கு முன் சரிபாருங்கள்: ஒரு வாடிக்கையாளர் அடையாளச் சரிபார்ப்பில் தேறிவிட்டதாக ஒரு ஏஜென்ட் கூறினால், பணத்தை விடுவிப்பதற்கு முன் சரிபார்ப்பு அமைப்பிடம் அதை உறுதிப்படுத்துங்கள். முக்கிய விளைவுகளை ஏற்படுத்தும் முடிவுகளுக்கு மனித ஒப்புதலைக் கட்டாயமாக்குங்கள்; அதற்கான ஆதாரங்கள் மதிப்பாய்வாளருக்குக் கிடைக்கும்படி செய்யுங்கள்.

8. மறைக்கப்பட்ட சூழல் தகவல் வெளிப்படுவதால் ஏற்படும் சேதத்தைக் கட்டுப்படுத்துங்கள்

AI பயன்பாடுகள், பயனர்கள் வழக்கமாகப் பார்க்காத அறிவுறுத்தல்களையும் பின்னணித் தகவல்களையும் மாடலுக்கு வழங்குகின்றன. இதில் சிஸ்டம் ப்ராம்ப்ட், உள் கொள்கைகள், கிடைக்கக்கூடிய கருவிகளின் விளக்கங்கள், அவற்றை யார் பயன்படுத்தலாம் என்பது குறித்த விதிகள் ஆகியவை அடங்கலாம். மாடல் அந்தத் தகவலை யாரோ ஒருவருக்கு வெளிப்படுத்தும்போது, மறைக்கப்பட்ட சூழல் தகவல் வெளிப்படுதல் நிகழ்கிறது.

வெளியே கசியக்கூடியவற்றில் சிஸ்டம் ப்ராம்ப்ட் ஒரு பகுதி மட்டுமே என்பதால், 2026-இல் OWASP இந்தப் பிரிவை “சிஸ்டம் ப்ராம்ப்ட் கசிவு” என்பதிலிருந்து விரிவுபடுத்தியது. அபாயம், நீங்கள் அங்கே எதை வைத்திருக்கிறீர்கள் என்பதைப் பொறுத்தது. கசிந்த குரல் தொனி வழிகாட்டி சற்றுச் சங்கடத்தை ஏற்படுத்தும்; ஆனால் கசிந்த API கீ, உங்கள் ரகசியத் தரவுத்தளத்துக்கான அணுகலை ஒருவருக்கு வழங்கிவிடும்.

உதாரணம்: பிப்ரவரி 2023-இல், பயனர்கள் Microsoft-இன் Bing Chat-ஐ அதன் உள் அறிவுறுத்தல்களை வெளிப்படுத்த வைத்தனர். வெற்றிகரமான முயற்சிகளில் ஒன்றை மேற்கொண்டவர் Marvin von Hagen; அவர் தன்னை ஒரு OpenAI டெவலப்பர் என்று கூறிக்கொண்டு, மாடலை உள்ளமைப்பதற்காக அந்த அறிவுறுத்தல்களைக் கேட்டார். Bing தனது தேடல்கள், பதில்கள், பாதுகாப்பு நடத்தை ஆகியவற்றை நிர்வகிக்கும் விதிகளையும், Sydney என்ற தனது உள் பெயரையும் வெளிப்படுத்தியது. வெளிப்படுத்தப்பட்ட அறிவுறுத்தல்களில், அந்த அறிவுறுத்தல்களை ரகசியமாக வைத்திருக்கச் சொல்லும் ஒன்றும் இருந்தது.

நீங்கள் என்ன செய்யலாம்:

• ரகசியங்களை மாடலின் சூழலுக்கு வெளியே வைத்திருங்கள்: மாடலால் படிக்கக்கூடிய எதுவும் பயனர்களுக்குத் தெரியவரக்கூடும் என்றே கருதுங்கள்—கடவுச்சொற்கள், 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-ஐத் தூண்ட அவர் ப்ராம்ப்ட் இன்ஜெக்ஷனைப் பயன்படுத்தினார். பின்னர் அந்தப் பயன்பாடு தானாகவே அந்தப் படத்தைப் பெற்றது, அதன் மூலம் அந்தத் தகவல் அவருடைய சர்வருக்கு அனுப்பப்பட்டது. வெளியீட்டைக் கையாள்வதில் நடந்த தோல்வி அந்தத் தானியங்கி கோரிக்கைதான்—மாடல் உருவாக்கிய உரை, தனிப்பட்ட தரவைச் சுமந்துகொண்டு ஒரு வெளிச் சர்வருடனான இணைப்பாக மாறியது.

நீங்கள் என்ன செய்யலாம்:

• வெளியீட்டை அது சென்றடையும் இடத்திற்கு ஏற்றவாறு பாதுகாப்பானதாக்குங்கள்: பதில்கள் எங்கு செல்லும் என்பதைப் பொறுத்து அவற்றைச் சரிபார்த்துக் கையாளுங்கள். ஒரு வலைப்பக்கத்திற்கு என்றால், உருவாக்கப்பட்ட உரை இயக்கக்கூடிய குறியீடாக மாறுவதைத் தடுங்கள். ஒரு தரவுத்தளத்திற்கு என்றால், வழங்கப்பட்ட மதிப்புகளைக் கட்டளைகளிலிருந்து தனியாக வைத்திருக்கும் முன்தயாரிக்கப்பட்ட வினவல்களை (prepared queries) பயன்படுத்துங்கள்.
• பதில்கள் தானாக வெளி இணைப்புகளை ஏற்படுத்துவதைத் தடுங்கள்: மாடல் பதில்களில் படங்கள், இணைப்பு முன்னோட்டங்கள், உட்பொதிக்கப்பட்ட பக்கங்கள் ஆகியவை தானாக ஏற்றப்படுவதை இயல்புநிலையாகவே முடக்குங்கள். தேவையான இணைப்புகளை வெளிப்படையாக அங்கீகரிக்கப்பட்ட இலக்குகளுக்கு மட்டுமே கட்டுப்படுத்துங்கள்.

Perplexity எப்படி LLM-களைப் பாதுகாக்கிறது?

மேலே உள்ள ஒவ்வொரு அபாயமும் என்றாவது ஒரு நாள் நிகழ்ந்தே தீரும் என்று நாங்கள் கருதுகிறோம்; அப்படி நிகழும்போது அதனால் பெரிய பாதிப்பு ஏற்படாதபடி வடிவமைக்கிறோம். இதை எப்படிச் செய்கிறோம் என்பதை எங்கள் CISO, Kyle Polley, ஒரு சமீபத்திய பயிலரங்கில் விளக்கினார்.

• ஏஜென்ட்டுக்கு அதற்கென சொந்தக் கணினி கிடைக்கிறது, அது வெறுமையாகவே தொடங்குகிறது: உங்கள் லேப்டாப்பில் நிறுவப்பட்ட ஏஜென்ட் கருவிகள் அதிலுள்ள கோப்புகள், ஆப்ஸ், சேமிக்கப்பட்ட உள்நுழைவுச் சான்றுகள் ஆகியவற்றை அணுகக்கூடும். Perplexity Computer இதற்கு நேர்மாறாகச் செயல்படுகிறது. ஒவ்வொரு பணியும் அதற்கெனத் தனிமைப்படுத்தப்பட்ட சாண்ட்பாக்ஸில் இயங்குகிறது; Polley கூறுவது போல, “இயல்பாக அதற்கு எதற்குமே அணுகல் இல்லை.”
• ஏஜென்ட் கடவுச்சொற்களைப் பார்ப்பதே இல்லை: இணைக்கப்பட்ட சேவைகளுக்கான உள்நுழைவுச் சான்றுகள் சாண்ட்பாக்ஸுக்கு வெளியே சேமிக்கப்படுகின்றன. GitHub போன்ற ஒரு சேவையை அணுக வேண்டியிருக்கும்போது, ஏஜென்ட் எந்தச் சான்றுகளும் இணைக்கப்படாத ஒரு கோரிக்கையை அனுப்புகிறது. இலக்கும் கோரிக்கையும் எதிர்பார்த்தபடியே உள்ளனவா என்பதை ஒரு கேட்வே சரிபார்த்து, கோரிக்கை வெளியே செல்லும் வழியில் சான்றுகளைச் சேர்க்கிறது. இதனால், விசைகளைப் பெறாமலேயே ஏஜென்ட் அந்த இணைப்பைப் பயன்படுத்த முடிகிறது.
• உங்கள் அனுமதிகள் அப்படியே தொடர்கின்றன, அவற்றை நீங்கள் மேலும் இறுக்கலாம்: OAuth மூலம் ஏற்படுத்தப்படும் இணைப்புகள், இணைக்கப்பட்ட சேவையில் உங்களுக்குள்ள அணுகல் அனுமதிகளை அப்படியே தக்கவைக்கின்றன. உங்களால் ஒன்றைப் பார்க்க முடியாவிட்டால், உங்கள் ஏஜென்ட்டாலும் அதைப் பார்க்க முடியாது.
• ஒவ்வொரு வலைப்பக்கமும் அந்நியராகவே கருதப்படுகிறது: நாங்கள் சோதித்த கருவிகள் நடைமுறைப் பயன்பாட்டில் எங்கள் தேவைகளைப் பூர்த்தி செய்யாததால், எங்கள் ஏஜென்டிக் உலாவியான Comet-க்காக BrowseSafe-ஐ உருவாக்கினோம். மின்னஞ்சல்கள் உட்பட வலைப்பக்கங்களையும் பிற வெளி உள்ளடக்கங்களையும் ப்ராம்ப்ட் இன்ஜெக்ஷனுக்காக இந்த உலாவி ஸ்கேன் செய்கிறது. மாடல், தரவுத்தொகுப்பு இரண்டையும் நாங்கள் ஓப்பன் சோர்ஸ் ஆக்கியுள்ளோம்.
• ஏஜென்ட்டையும் அது இயங்கும் கணினிகளையும் நாங்கள் கண்காணிக்கிறோம்: ஒரு செயலைச் செய்ய ஏஜென்ட் முடிவெடுப்பதற்கும் கருவி உண்மையில் இயங்குவதற்கும் இடையில் Numbat அமைந்துள்ளது. ஆதரிக்கப்படும் கோடிங் ஏஜென்ட்டுகள் முழுவதிலும் உள்ள செயல்பாடுகளை Numbat பதிவுசெய்கிறது, மேலும் உள்ளமைக்கப்பட்ட கொள்கைகளை மீறும் செயல்களை அவை இயங்குவதற்கு முன்பே தடுக்க முடியும். லேப்டாப்கள், சர்வர்கள், பில்ட் பைப்லைன்கள் முழுவதிலும் உள்ள மென்பொருள் தொகுப்புகளை Bumblebee பட்டியலிட்டு, ஏற்கெனவே அறியப்பட்ட தீங்கிழைக்கும் தொகுப்புகளைக் கொடியிட்டுக் காட்டுகிறது. இவை இரண்டும் ஓப்பன் சோர்ஸ்.
• மாடல் வழங்குநர்கள் உங்கள் தரவை வைத்துக்கொள்வதில்லை: எங்கள் மூன்றாம் தரப்பு LLM வழங்குநர்களுடன் பூஜ்ஜியத் தரவுத் தக்கவைப்பு ஒப்பந்தங்கள் எங்களிடம் உள்ளன. Enterprise நிர்வாகிகள் Perplexity-இன் சொந்தத் தரவுத் தக்கவைப்புக் காலத்தையும் 24 மணிநேரமாகக் குறைக்கலாம்.

Numbat-ஐ நாங்கள் முன்கூட்டியே உருவாக்கினோம்; அதற்கான காரணத்தை Polley ஒரே வரியில் சுருக்கமாகச் சொல்கிறார்: “ஒரு ஏஜென்ட்டுக்கு எவ்வளவு அதிகத் தன்னாட்சியை வழங்குகிறீர்களோ, அவ்வளவு அதிகமாக அபாயமும் இருக்கும்.”

LLM பாதுகாப்பு குறித்து அடிக்கடி கேட்கப்படும் கேள்விகள்

மிகவும் பாதுகாப்பான LLM எது?

எந்த LLM-உம் தானாகவே ஒரு பயன்பாட்டைப் பாதுகாப்பானதாக்கிவிடாது—தாங்கள் படிக்க வேண்டிய உள்ளடக்கத்தை, பின்பற்ற வேண்டிய வழிமுறைகளாக மாடல்கள் இன்னும் தவறாகப் புரிந்துகொள்ளக்கூடும். நிலையான சோதனைகளில் வலுவாகத் தோன்றும் பாதுகாப்பு அரண்களும் அழுத்தத்தின் கீழ் தகர்ந்துவிடக்கூடும்.

உங்கள் பயன்பாட்டுச் சூழலுக்கு எந்த அமைப்பு முறை மிகவும் பாதுகாப்பானது என்பதே சிறந்த கேள்வி. அதாவது, வரையறுக்கப்பட்ட அனுமதிகள், மாடலிடமிருந்து விலக்கி வைக்கப்பட்ட உள்நுழைவுச் சான்றுகள், அபாயகரமான செயல்களுக்கு மனித ஒப்புதல், உங்கள் பாதுகாப்பு அரண்களை நன்கு அறிந்தவர்களால் செய்யப்படும் சோதனை ஆகியவை.

LLM பாதுகாப்புக் குறைபாடுகள் என்றால் என்ன?

LLM பாதுகாப்புக் குறைபாடுகள் என்பவை, தாக்குதல் நடத்துபவர் மூலமாகவோ அல்லது அதன் சொந்தத் தவறுகளாலோ, ஒரு AI அமைப்பு ஏமாற்றப்படவோ, தரவைக் கசியவிடவோ, சேதம் விளைவிக்கவோ வழிவகுக்கும் பலவீனங்கள் ஆகும்.

பத்து முக்கிய அபாயங்கள்: ப்ராம்ப்ட் இன்ஜெக்ஷன், முக்கியமான தகவல்கள் வெளிப்படுதல், அளவுக்கு மீறிய செயலுரிமை, விநியோகச் சங்கிலி, தரவு மற்றும் மாடல் நச்சூட்டல், வரம்பற்ற நுகர்வு, தவறான தகவல், மறைக்கப்பட்ட சூழல் வெளிப்பாடு, வெக்டர் மற்றும் எம்பெடிங் பலவீனங்கள், முறையற்ற வெளியீட்டுக் கையாளுதல்.

தனிப்பட்ட LLM பாதுகாப்பானதா?

சில விஷயங்களுக்குப் பாதுகாப்பான தேர்வுதான், ஆனால் இயல்பாகவே அல்ல. உங்கள் சொந்த உள்கட்டமைப்பிலோ கிளவுட் சூழலிலோ ஒரு மாடலை இயக்கினால், தரவுக் கையாளுதலின் மீது உங்களுக்கு அதிகக் கட்டுப்பாடு கிடைக்கும். ஆனால் ப்ராம்ப்ட் இன்ஜெக்ஷன்கள், அளவுக்கு மீறிய செயலுரிமை, நச்சூட்டல், தவறான தகவல் ஆகியவற்றைத் தானாகத் தடுக்க எந்த வழியும் இல்லை.

சுய-ஹோஸ்டிங்கின் ஒரு பகுதியாக, நீங்கள் பதிவிறக்கும் மாடலுக்கும் நீங்களே பொறுப்பு; அதன் விநியோகச் சங்கிலி அபாயங்களும் அதற்குத் தேவையான உள்கட்டமைப்பும் இதில் அடங்கும்.