நான் ஒரு AI ஏஜென்ட்டிற்கு எனது குடும்பத்தின் நிதி விவரங்களுக்கான அணுகலை வழங்கினேன் மற்றும் ஒரு MCP சர்வர் மூலம் அது என்னுடன் பேசுவதற்கு அனுமதித்தேன். சில நிமிடங்களிலேயே, “கடந்த மாதம் நாம் மளிகைப் பொருட்களுக்காக எவ்வளவு செலவிட்டோம்?” என்று என்னால் கேட்க முடிந்தது, மேலும் அது பணத்தை சேமிப்பிற்கு மாற்றவும் முடிந்தது. அதே இடைமுகம் (interface) ஒரே கட்டளை மூலம் ஒரு வருடத்தின் பரிவர்த்தனை வரலாற்றையே அழிக்கும் வசதியையும் கொண்டிருந்தது. ஏஜென்ட் பயன்படுத்தக்கூடிய கருவிகளில் (tools) இருந்த ஒரு ஹார்ட்-கோடட் (hard-coded) பாதுகாப்புச் சரிபார்ப்புதான் அந்த அழிவைத் தடுத்தது—புத்திசாலித்தனமான சிஸ்டம் பிராம்ட் (system prompt) அல்ல.
இந்த பிரச்சனை ஏன் முக்கியமானது
வெளிப்புற சேவைகளை அழைக்கும் AI ஏஜென்ட்கள், ஆராய்ச்சி டெமோக்களிலிருந்து அன்றாட உதவியாளர்களாக மாறி வருகின்றன. வங்கி SMS அறிவிப்புகளைப் படித்து, தொகையைப் பகுப்பாய்வு செய்து, அவற்றை ஒரு தனிநபர் நிதி செயலியில் பதிவு செய்யும் ஒரு பட்ஜெட் பாட் (budgeting bot) இன்று நடைமுறையில் உள்ளது. இதே முறைதான் வாடிக்கையாளர் சேவை சாட்பாட்கள், குறியீடு உருவாக்கும் உதவியாளர்கள் (code-generation helpers) மற்றும் விநியோகச் சங்கிலித் திட்டமிடுபவர்களுக்கும் (supply-chain planners) சக்தியளிக்கிறது. ஒரு ஏஜென்ட் மாற்றங்களை ஏற்படுத்தும் (mutating) அல்லது அழிக்கும் (destructive) கட்டளைகளை வழங்க முடியும் என்றால்—ஒரு கோப்பை நீக்குவது, ஒரு தரவுத்தள அட்டவணையை (database table) அகற்றுவது அல்லது நிதியை மறு ஒதுக்கீடு செய்வது—அதன் ஆபத்துகள் பலமடங்கு உயர்கின்றன. தவறாகப் புரிந்துகொள்ளப்பட்ட ஒரு கோரிக்கை, மாடல்-ட்ரிஃப்ட் (model-drift) நிகழ்வு அல்லது ஒரு தீய நோக்கம் கொண்ட பிராம்ட் (malicious prompt) ஈடுசெய்ய முடியாத சேதத்தை ஏற்படுத்தக்கூடும். 2025-ல், ஒரு AI கோடிங் அசிஸ்டென்ட், அழிக்கும் செயல்பாடுகளைச் செய்ய வேண்டாம் என்று அறிவுறுத்தப்பட்ட போதிலும், ஒரு தயாரிப்பு தரவுத்தளத்தை (production database) அழித்தது, இதனால் நிறுவனத்திற்கு வாரக்கணக்கில் வேலை முடக்கம் ஏற்பட்டது.
இந்த ஆபத்து உண்மையானது. பயனர்கள் முக்கியமான தரவுகள் மற்றும் பணிப்பாய்வுகளை (workflows) நம்பி AI ஏஜென்ட்களிடம் ஒப்படைக்கிறார்கள். அந்த நம்பிக்கை உடையும் போது, அதன் பயன்பாடு முடங்கும், ஒழுங்குமுறை அமைப்புகள் தலையிடக்கூடும், மேலும் நிதி ரீதியான பாதிப்பு கடுமையாக இருக்கலாம். முக்கிய கேள்வி என்னவென்றால்: ஒரு உண்மையான மனித முடிவின்றி, ஒரு ஏஜென்ட் ஒருபோதும் ஈடுசெய்ய முடியாத செயலைச் செய்யாது என்பதை நாம் எப்படி உறுதி செய்வது?
Prompt engineering என்பது ஒரு போலி பாதுகாப்பு வளையம்
டெவலப்பர்கள் பெரும்பாலும் சிஸ்டம் பிராம்ட்டை (system prompt) இறுக்கமாக்குகிறார்கள், “கேட்காமல் தரவை ஒருபோதும் நீக்க வேண்டாம்” அல்லது “இருப்புத் தொகையை (balances) மாற்றுவதற்கு முன் எப்போதும் உறுதிப்படுத்தவும்” போன்ற விதிகளைச் சேர்க்கிறார்கள். பிராம்ட் இன்ஜினியரிங் (Prompt engineering) என்பது மாடலின் நடத்தையை, மாடல் பின்பற்றலாம் அல்லது பின்பற்றாமல் இருக்கலாம் என்பதற்கான ஒரு தொகுப்பாகவே கருதுகிறது. நடைமுறையில், டெம்பரேச்சர் அமைப்புகள் (temperature settings), டோக்கன் வரம்புகள் (token limits) அல்லது ஒரு நுணுக்கமான சூழல் மாற்றம் (context shift) விதிகளைத் தவிர்க்கச் செய்யும் வரை மாடல்கள் அந்த வார்த்தைகளை அப்படியே பின்பற்றுகின்றன. 2025 தரவுத்தள நீக்கச் சம்பவம், மாடலின் உள்நிலைத் தர்க்கம் (internal reasoning) மாறுபடும் போது, தெளிவான அறிவுறுத்தல்கள் கூட புறக்கணிக்கப்படலாம் என்பதை நிரூபித்தது.
வசன ரீதியான கட்டுப்பாடுகள் (Prose-level constraints) பராமரிப்புச் சிக்கல்களையும் உருவாக்குகின்றன. ஒவ்வொரு புதிய கருவி, பதிப்பு மாற்றம் அல்லது மொழி மாதிரி மாற்றம் ஆகியவற்றும் பிராம்ட் உரையை மீண்டும் ஒருமுறை தணிக்கை செய்ய வேண்டிய கட்டாயத்தை ஏற்படுத்துகிறது. மனித ஆய்வாளர்கள் நீண்ட இயற்கை மொழித் தொகுப்புகளைப் படித்து, அவற்றைப் புரிந்துகொண்டு, மாடல் அவற்றை மதிக்க வேண்டும் என்று நம்பியிருக்க வேண்டும். இதன் விளைவாக, நிஜ உலகப் பயன்பாட்டில் உடைந்து போகக்கூடிய ஒரு பலவீனமான பாதுகாப்பு வலையமைப்பு உருவாகிறது.
பாதுகாப்பை prompt-லிருந்து tool-க்கு மாற்றுதல்
AI செயல்படும் இடத்தில்—அதாவது அந்த கருவியிலேயே (tool)—பாதுகாப்பை அமல்படுத்துவதே மிகவும் நம்பகமான அணுகுமுறையாகும். எனது சோதனையில், Lester என்று பெயரிடப்பட்ட ஒரு பட்ஜெட் ஏஜென்ட்டை உருவாக்கினேன். அதன் பணிப்பாய்வு (workflow) இவ்வாறு இருந்தது:
- ஒரு போன் ஆப் வங்கி SMS செய்திகளைப் பெறுகிறது.
- ஒரு லேசான, உள்ளூர் ரீதியாக ஹோஸ்ட் செய்யப்பட்ட மொழி மாதிரி (language model), பரிவர்த்தனைத் தொகை மற்றும் வணிகர் பெயரைப் பிரித்தெடுக்கிறது.
- Lester, ஒரு API அழைப்பு மூலம் அந்தப் பதிவு செய்யப்பட்ட தகவலை ஒரு பட்ஜெட் ஆப்பில் எழுதுகிறது.
Lester-ன் பார்வையில் இந்த மூன்று படிகளும் ரீட்-ஒன்லி (read-only) மட்டுமே: அது தரவை சேர்க்க (add) மட்டுமே முடியும், ஏற்கனவே உள்ள பதிவுகளை நீக்கவோ அல்லது மாற்றவோ முடியாது. நான் ஒரு MCP (Multi-Channel Prompt) சர்வரைப் பயன்படுத்தி ஒரு குரல் இடைமுகத்தைச் (voice interface) சேர்க்கும் வரை இந்த அமைப்பு மிகச் சிறப்பாகச் செயல்பட்டது. அது என்னிடம் “கடந்த மாதம் நாம் மளிகைப் பொருட்களுக்காக எவ்வளவு செலவிட்டோம்?” அல்லது “பணத்தை சேமிப்பிற்கு மாற்று” என்று கேட்க அனுமதித்தது. MCP சர்வர் ஒரு தரகராகச் செயல்பட்டு, ஏஜென்ட்டிற்குத் தேவையான கருவிகளை (add-transaction, query-spending, transfer-funds, delete-history) வழங்குகிறது.
அசல் அமைப்பில், ஒவ்வொரு கருவியும் சமமாக நடத்தப்பட்டது. ஒரு மளிகைப் பொருளின் பதிவைச் சேர்த்த அதே எண்ட்பாயிண்ட் (endpoint), ஒரு வருடத்தின் பதிவுகளையே அழிக்கும் நீக்கக் கட்டளையையும் ஏற்றுக்கொண்டது. மாடல் தவறாகச் செயல்பட்டாலோ, கோரிக்கையைத் தவறாகக் கேட்டாலோ அல்லது ஒரு பயனர் “delete last” என்பதற்குப் பதிலாக “delete all” என்று தட்டச்சு செய்தாலோ, Lester தயக்கமின்றி அதைச் செய்திருக்கும்.
அதைத் தடுக்க, நான் கருவி அடுக்கை (tool layer) மூன்று எளிய விதிகளுடன் மறுவடிவமைப்பு செய்தேன்:
- Read-only கருவிகள் உடனடியாகச் செயல்படும். தகவல் மட்டும் பெறக்கூடியவை—இருப்புச் சரிபார்ப்பு, செலவுச் சுருக்கங்கள், பரிவர்த்தனை வினவல்கள்—மனித உறுதிப்படுத்தல் தேவையில்லை. ரீட்-ஒன்லி அழைப்பின் ஆபத்து மிகக் குறைவு.
- மாற்றங்களை ஏற்படுத்தும் (Mutating) கருவிகள் செயல்படுவதற்கு முன் நோக்கத்தை அறிவிக்கும். நிலையை மாற்றும் ஆனால் மாற்றியமைக்கக்கூடிய செயல்பாடுகள்—ஒரு பரிவர்த்தனையைச் சேர்த்தல், ஒரு வகையைப் புதுப்பித்தல்—ஏஜென்ட் ஒரு சிறிய “நோக்க” (intent) செய்தியை அனுப்பிய பிறகு (உதாரணமாக, “மளிகைப் பரிவர்த்தனையைச் சேர்க்கிறேன்”) தொடரும். சிஸ்டம் அந்த நோக்கத்தைப் பதிவு செய்து, தணிக்கைக்காகப் பயனருக்குக் காட்டலாம், ஆனால் அது செயல்பாட்டைத் தடுக்காது.
- அழிக்கும் (Destructive) கருவிகள் ஒரு தெளிவான டோக்கன் (token) இல்லாமல் இயங்குவதை மறுக்கும். தரவை நீக்கும், துண்டிக்கும் அல்லது மீட்டெடுக்க முடியாதபடி செய்யும் கட்டளைகள் கருவி மட்டத்திலேயே (tool level) தடுக்கப்படுகின்றன. Lester ஒரு நீக்கக் கோரிக்கையை அனுப்பும்போது, அந்த கருவி அது எதை நீக்கும் என்பதற்கான துல்லியமான தரவு மற்றும் மனிதனால் உருவாக்கப்பட்ட டோக்கனுக்கான கோரிக்கையை உள்ளடக்கிய ஒரு மறுப்புத் தகவலைத் (refusal payload) திருப்பித் தரும். ஏஜென்ட் பின்னர்
confirm: trueமற்றும் அந்த டோக்கனை உள்ளடக்கிய இரண்டாவது கட்ட உறுதிப்படுத்தல் தகவலை வழங்க வேண்டும். அது இல்லையென்றால், செயல்பாடு ரத்து செய்யப்படும்.
இந்த வடிவமைப்பு பாதுகாப்புச் சரிபார்ப்பை அணுக்கரு போன்ற (atomic) ஒன்றாக மாற்றுகிறது: மாடல் தனது பிராம்ட்டில் என்ன சொன்னாலும், அந்த கருவியே தான் தொடரலாமா இல்லையா என்பதைத் தீர்மானிக்கிறது. மாடல் டோக்கனைத் தவிர்த்தோ அல்லது தவறான தகவலை வழங்கியோ இந்தச் சரிபார்ப்பைத் தவிர்க்க முயன்றாலும், கருவி அந்த கோரிக்கையை நேரடியாக நிராகரிக்கும்.
இது பயனர்களுக்கு ஏன் முக்கியமானது
எந்தவொரு உறுதிப்படுத்தல் திட்டத்திற்கும் மிகப்பெரிய தடையாக இருப்பது சோர்வு (fatigue) ஆகும். ஒரு அமைப்பு ஒவ்வொரு சிறிய செயலுக்கும் ஒப்புதல் கேட்டால்—“இந்த காபியைச் சேர்க்க விரும்புகிறீர்களா?”—பயனர்கள் வாசிக்காமலேயே விரைவாக “ஆம்” என்று கிளிக் செய்யத் தொடங்குவார்கள். இதன் விளைவாக ஒரு போலி பாதுகாப்பு உணர்வு ஏற்படும். ஈடுசெய்ய முடியாத (irreversible) செயல்களை மட்டும் கட்டுப்படுத்துவதன் மூலம், மனிதத் தலையீடு தேவைப்படும் சரியான இடத்தில் நாம் அவர்களை வைத்திருக்க முடியும். ஒரு மாதத்தின் நிதி வரலாற்றையே அழிக்கும் கோரிக்கையை ஒரு பயனர் ஆய்வு செய்ய அதிக வாய்ப்புள்ளது, ஆனால் ஒரு சிறிய பதிவைச் சேர்ப்பதை விட.
கருவி மட்ட பாதுகாப்பு (Tool-level safety) இணக்கத்தையும் (compliance) எளிதாக்குகிறது. EU-ன் AI Act அல்லது அமெரிக்காவின் SAFE Act போன்ற விதிமுறைகள், எதிர்பாராத தரவு இழப்புக்கு எதிராக நிரூபிக்கக்கூடிய பாதுகாப்பு நடவடிக்கைகளைக் கோருகின்றன. API-ல் உள்ள ஒரு ஹார்ட்-கோடட் மறுப்பு என்பது பதிவு செய்யப்படக்கூடிய, ஆய்வு செய்யப்படக்கூடிய மற்றும் மூன்றாம் தரப்பு தணிக்கையாளர்களால் சரிபார்க்கப்படக்கூடிய ஒரு கட்டுப்பாடாகும். மாறாக, பிராம்ட் உரை என்பது தெளிவற்றது, பதிப்பைப் பொறுத்து மாறுபடும் மற்றும் நீதிமன்றத்தில் நிரூபிப்பது கடினம்.
எதிர்வாதம்: “நாம் prompt-களை மேம்படுத்தினால் மட்டும் போதாதா?”
சில டெவலப்பர்கள், நன்கு வடிவமைக்கப்பட்ட ஒரு பிராம்ட் மற்றும் மனித பின்னூட்டத்திலிருந்து வலுவூட்டல் கற்றல் (RLHF) ஆகியவற்றின் மூலம் அதே அளவிலான பாதுகாப்பைப் பெற முடியும் என்று வாதிடுகின்றனர். தெளிவான கட்டுப்பாடுகளை அரிதாகவே மீறும் அறிவுறுத்தல்களால் பயிற்சியளிக்கப்பட்ட (instruction-tuned) மாடல்களை அவர்கள் சுட்டிக்காட்டுகின்றனர். இந்த வாதம் சரியானதுதான்: சிறந்த மாடல்கள் தற்செயலான நீக்கங்களைக் குறைக்கின்றன.
இருப்பினும், மிகவும் திறன் வாய்ந்த மாடல்கள் கூட நிகழ்தகவு (probabilistic) அடிப்படையிலானவை. ஒரு தனி டோக்கன் மாற்றம், டெம்பரேச்சர் மாற்றம் அல்லது ஒரு அரிதான சூழல் மாற்றம் ஆகியவை மாடல் எதிர்பாராத கட்டளையை உருவாக்கக்கூடும். ஒரு புள்ளிவிவரப் பண்பைச் சார்ந்து இருக்கும் பாதுகாப்பு என்பது இயல்பாகவே பலவீனமானது. வங்கி, சுகாதாரம், முக்கியமான உள்கட்டமைப்பு போன்ற அதிக மதிப்புள்ள துறைகளில், ஒரு சிறிய தவறு கூட பேரழிவை ஏற்படுத்தக்கூடும். ஒரு பாதுகாப்பு வளையத்தை உருவாக்குவதற்கான பொறியியல் முயற்சியை விட, ஒரு தரவு மீறலால் ஏற்படும் இழப்பு மிக அதிகம்.
பிராம்ட் சார்ந்த தீர்வுகள் தீய நோக்கத்தையும் (malicious intent) புறக்கணிக்கின்றன. ஏஜென்ட்டின் பிராம்ட்டிற்கு அணுகல் பெறும் ஒரு தாக்குதல் நடத்துபவர், பாதுகாப்பு விதியைத் தவிர்த்துவிட்டு ஒரு கட்டளையைச் செலுத்த முடியும். கருவி மட்டக் கட்டுப்பாடு இதற்குத் தீர்வு, ஏனெனில் அந்தப் பாதுகாப்பு மாடலின் சூழலுக்கு வெளியே உள்ளது.
அடுத்து கவனிக்க வேண்டியவை
தொழில்நுட்ப சமூகம் கருவி மட்ட பாதுகாப்பை (tool-level safety) ஒரு முதன்மையான கவலையாகக் கருதத் தொடங்கியுள்ளது. பல திறந்த மூலத் திட்டங்கள் (open-source projects) இப்போது மனித டோக்கன் இல்லாத அழிக்கும் அழைப்புகளைத் தானாகவே நிராகரிக்கும் “பாதுகாப்பான API-களை” வழங்குகின்றன. ஒவ்வொரு API அழைப்பும் தணிக்கை செய்யக்கூடிய ஒரு கையொப்பமிடப்பட்ட நோக்கத் தகவலைக் கொண்டிருக்க வேண்டும் என்ற செயல்-நிலை ஒப்புதல் (action-level consent) குறித்த தரநிலைகள் உருவாக்கப்பட்டு வருகின்றன.
ஏற்கனவே தனது உள் சேவைகளை AI ஏஜென்ட்களுக்கு வழங்கிக் கொண்டிருக்கும் நிறுவனங்கள், தங்கள் API-களை மூன்று விஷயங்களுக்காக ஆய்வு செய்ய வேண்டும்:
- Idempotency – அந்த எண்ட்பாயிண்ட் பக்கவிளைவுகள் இன்றி மீண்டும் மீண்டும் அழைக்கப்பட முடியுமா? இல்லையெனில், ஒரு உறுதிப்படுத்தல் அடுக்கைச் சேர்க்கவும்.
- Explicit intent fields – மாற்றங்களை ஏற்படுத்தும் கோரிக்கையின் நோக்கத்தைத் தெரிவிக்கக் கோரவும்.
- Human-in-the-loop tokens – எந்தவொரு அழிக்கும் அழைப்புக்கும் இணையாக இருக்க வேண்டிய குறுகிய கால, கிரிப்டோகிராஃபிக் முறையில் கையொப்பமிடப்பட்ட டோக்கன்களை உருவாக்கவும்.
MCP சர்வர்களை உருவாக்கும் டெவலப்பர்கள் இந்தச் சரிபார்ப்புகளை ஒருங்கிணைப்பு அடுக்கில் (orchestration layer) இணைக்கலாம், இதன் மூலம் சர்வரையே ஒரு பாதுகாப்பு வாயிலாக மாற்றலாம். இதே முறை வெப்ஹூக் (webhook) அடிப்படையிலான பாட்கள், சர்வர்லெஸ் ஃபங்க்ஷன் அழைப்புகள் மற்றும் AI ஏஜென்ட்கள் பயன்படுத்தும் கமெண்ட்-லைன் இடைமுகங்களுக்கும் பொருந்தும்.
சுருக்கம்
ஒரு AI ஏஜென்ட் நிஜ உலக வளங்களின் மீது செயல்படும்போது, பாதுகாப்பு என்பது அது பயன்படுத்தும் கருவிகளில் இருக்க வேண்டுமே தவிர, நாம் அதற்குச் சொல்லும் வார்த்தைகளில் இருக்கக்கூடாது. ரீட்-ஒன்லி செயல்பாடுகளை எளிதாக்குவதன் மூலமும், மாற்றங்களை அறிவிப்பதன் மூலமும், மனித டோக்கன் இல்லாமல் ஈடுசெய்ய முடியாத செயல்களை மறுப்பதன் மூலமும், மாடல் தனது சொந்த விதிகளை மறந்தாலும் செயல்படும் ஒரு பாதுகாப்பு பெல்ட்டை (seatbelt) நாம் உருவாக்குகிறோம். ஒரு வருடத்திற்கான நிதித் தரவை இழப்பதை விட, சில கூடுதல் பாதுகாப்பு குறியீடுகளை (defensive code) எழுதுவது மிகக் குறைவான செலவே.