When an AI agent claims it finished a task, skepticism is the only sane response. A log entry that reads “Task completed

ஒரு AI ஏஜென்ட் ஒரு பணியை முடித்துவிட்டதாகக் கூறும்போது, சந்தேகம் கொள்வதே அறிவுப்பூர்வமான செயலாகும். “Task completed at 14:32” என்று இருக்கும் ஒரு லாக் பதிவு வெறும் உரைத் தொடர் மட்டுமே. அந்த ஏஜென்ட் அமைதியாக செயலிழந்திருக்கலாம், ஒரு வெற்றுப் படிவத்தைச் சமர்ப்பித்திருக்கலாம், காலியான தேடல் முடிவுகளில் சுழற்சியில் சிக்கியிருக்கலாம் அல்லது ஒரு முழுமையான பணிப்பாய்வை (workflow) கற்பனை செய்திருக்கலாம் (hallucinated). உங்கள் கட்டமைப்பு வெவ்வேறு இயந்திரங்கள், கிளவுட் பிராந்தியங்கள் அல்லது IP முகவரிகளில் இயங்கும் பல ஏஜென்ட்களைக் கொண்டிருந்தால், இந்தப் பிரச்சனை மிக வேகமாகப் பெருகும். ஏஜென்ட் A தனது பணியைச் செய்ததற்கான ஆதாரத்தைக் காட்டாதவரை, ஏஜென்ட் B ஏஜென்ட் A-ன் அறிக்கையை நம்ப வேண்டிய அவசியம் இல்லை.

ஒவ்வொரு நம்பகமான சரிபார்ப்பு அமைப்பும் மூன்று அடுக்குகளைக் கொண்டு கட்டமைக்கப்பட்டுள்ளது. Evidence (சான்று) என்பது மூலப் பொருள்—ஸ்கிரீன்ஷாட், API பதில் அல்லது HTML Dump போன்றது. Attestation (உறுதிப்படுத்துதல்) என்பது அந்தச் சான்றை ஒரு குறிப்பிட்ட ஏஜென்ட் மற்றும் ஒரு குறிப்பிட்ட பணி ID-உடன் இணைக்கும் ஒரு கையொப்பமிடப்பட்ட அல்லது கிரிப்டோகிராஃபிக் கோரிக்கை ஆகும். Verification (சரிபார்ப்பு) என்பது அந்தச் சான்று உண்மையில் அசல் இலக்கை நிறைவு செய்கிறதா என்பதை உறுதிப்படுத்தும் செயல்முறையாகும், அது வெறும் கோப்பு இருப்பதை மட்டும் உறுதிப்படுத்துவதல்ல. உறுதிப்படுத்துதல் (Attestation) இல்லாத சான்று, ஒரு பணியிலிருந்து மற்றொரு பணிக்குத் திருட்டுத்தனமாகப் பயன்படுத்தப்படலாம் (replayed). சரிபார்ப்பு (Verification) இல்லாத உறுதிப்படுத்துதல், தரவு உண்மையானது என்று சொல்லுமே தவிர, நீங்கள் கேட்ட கேள்விக்கு அது பதிலளிக்கிறதா இல்லையா என்பதைச் சொல்லாது.

காட்சிச் சான்று: ஸ்கிரீன்ஷாட்கள் மற்றும் OCR

ஒரு ஏஜென்ட் உலாவியை (browser) இயக்கினால் அல்லது ஒரு கிராஃபிக்கல் இடைமுகத்துடன் (graphical interface) தொடர்பு கொண்டால், எளிமையான சான்று ஒரு புகைப்படம் ஆகும். செயல் முடிந்த பிறகு ஏஜென்ட் ஒரு முழுப் பக்க ஸ்கிரீன்ஷாட்டைப் பிடித்து, காணக்கூடிய உரையைத் பிரித்தெடுக்க OCR-ஐ இயக்கி, அந்தப் படம் மற்றும் பிரித்தெடுக்கப்பட்ட உரைகளைச் சான்றாகச் சமர்ப்பிக்கிறது.

இந்த முறை சமூக ஊடகப் பதிவுகள், படிவச் சமர்ப்பிப்புகள் அல்லது செக்அவுட் (checkout) செயல்முறைகளுக்குப் பொருந்தும். ஒரு நிறுவனத்தின் LinkedIn பக்கத்தில் வாராந்திரத் தகவலைப் பதிவிடப் பணிக்கப்பட்ட ஒரு ஏஜென்ட்டை கற்பனை செய்து பாருங்கள். ஸ்கிரீன்ஷாட், சர்வரால் உருவாக்கப்பட்ட நேர முத்திரை (timestamp) மற்றும் URL-இல் இணைக்கப்பட்ட பதிவின் ID ஆகியவற்றுடன் நேரடிப் பதிவைக் காட்டுகிறது. அந்தத் தளத்திற்குரிய அடையாளங்களுடன் (platform-specific markers) துல்லியமான தலைப்பு மற்றும் உடல் உரை பக்கத்தில் தோன்றுகிறதா என்பதை OCR உறுதிப்படுத்த முடியும்.

இதில் உள்ள ஆபத்து வெளிப்படையானது: ஸ்கிரீன்ஷாட்களைப் போலியாக உருவாக்க முடியும். ஒரு ஊடுருவப்பட்ட ஏஜென்ட் (compromised agent), ஒரு போலி வலைப்பக்கத்தை உள்ளூரிலேயே (locally) உருவாக்கி, அதை ஸ்கிரீன்ஷாட் எடுத்து, வெற்றி பெற்றதாக அறிவிக்கலாம். இதைத் தவிர்க்க, கணிக்க முடியாத மாறும் தன்மை கொண்ட உரை அடையாளங்களை (dynamic text markers) அவசியமாக்குங்கள். ஒரு தளம் வழங்கும் உறுதிப்படுத்தல் ID, சர்வரிலிருந்து வரும் நேர முத்திரை அல்லது சரிபார்ப்பாளர் பணியின் வழிமுறைகளுடன் இணைக்கும் ஒரு தனித்துவமான nonce ஆகியவை நங்கூரங்களாகச் செயல்படலாம். OCR வெளியீடு அந்தத் குறிப்பிட்ட பணிக்குத் தொடர்புடைய எதிர்பார்க்கப்படும் உறுதிப்படுத்தல் ID-யைக் கொண்டிருக்கவில்லை என்றால், அந்தச் சான்று தோல்வியடைகிறது.

இருப்பினும், ஸ்கிரீன்ஷாட்கள் அதிக அளவு தரவை எடுத்துக்கொள்ளும். அவை இணையப் பயன்பாடு (bandwidth) மற்றும் சேமிப்பகத்தை (storage) அதிகம் பயன்படுத்துகின்றன, மேலும் தளங்கள் அவற்றின் வடிவமைப்பை மாற்றும்போது அவை வேலை செய்யாமல் போகலாம். UI மட்டுமே ஒரே வழி இருக்கும்போது அவற்றைப் பயன்படுத்துங்கள், ஆனால் அவற்றை ஒரு கோட்டையாகக் கருதாமல் ஒரு அடிப்படை அளவுகோலாக மட்டுமே கருதுங்கள்.

கையொப்பமிடப்பட்ட API ரசீதுகள் (Signed API Receipts)

ஏஜென்ட் ஒரு பேக்எண்ட் API மூலம் செயல்படும்போது, படங்களைத் தவிர்க்கவும். கையொப்பமிடப்பட்ட ரசீதை (signed receipt) கோரவும்.

ஒரு தானியங்கிப் பதிவு அல்லது தரவு சேகரிப்பிற்குப் பிறகு (data scrape), தளம் பொதுவாக ஒரு கட்டமைக்கப்பட்ட பேலோடை (structured payload) வழங்கும். அந்த JSON-இல் ஒரு ID, நேர முத்திரை, நிலைத் புலங்கள் (status fields) மற்றும் சில நேரங்களில் ரேட்-லிமிட் ஹெடர்கள் (rate-limit headers) இருக்கும். ஏஜென்ட் இந்த முழு பேலோட்டையும் ஒரு தனிப்பட்ட சாவியைக் (private key) கொண்டு கையொப்பமிட்டு, கையொப்பமிடப்பட்ட பிளாப்பிற்குள் (signed blob) பணி ID-யைச் சேர்த்து, அந்தத் தொகுப்பைப் சமர்ப்பிக்கிறது. சரிபார்ப்பாளர் ஏஜென்ட்டின் பொதுச் சாவியைப் (public key) பயன்படுத்தி கையொப்பத்தைச் சரிபார்த்து, செயல் வெற்றி பெற்றதா என்பதை உறுதிப்படுத்த ரசீதை ஆய்வு செய்கிறார்.

இதில் உள்ள பலவீனமான புள்ளி 'சாவி பாதுகாப்பு' (key custody) ஆகும். ஏஜென்ட் இயங்கும் அதே இயந்திரத்தில் அதன் தனிப்பட்ட சாவியை வைத்திருந்தால், ஒரு பிராம்ப்ட் இன்ஜெக்ஷன் (prompt injection), மால்வேர் அல்லது கன்டெய்னர் எஸ்கேப் மூலம் அந்தச் சாவியைப் பிரித்தெடுத்து, நடக்காத பணிகளுக்காகப் போலி ரசீதுகளை உருவாக்க முடியும். ஏஜென்ட்டின் சூழலில் (environment) நீண்ட காலம் நீடிக்கக்கூடிய சாவிகளைப் பயன்படுத்த வேண்டாம். அதற்குப் பதிலாக, குறுகிய காலத்திற்கு மட்டுமே செல்லுபடியாகும், பணி சார்ந்த சான்றுகளை (task-scoped credentials) வழங்கும் ஒரு சாவி மேலாண்மை அமைப்பைப் (key management system) பயன்படுத்தவும். ஒவ்வொரு பணிக்கும் சாவிகளை மாற்றவும் (rotate). ஏஜென்ட் ஒரு ஐந்து நிமிட காலத்திற்கு ஒரு பாதுகாப்பான என்கிளேவ் (enclave) அல்லது KMS-லிருந்து கையொப்பமிடும் சாவியைப் பெற வேண்டியிருந்தால், பாதுகாப்பு மீறலின் பாதிப்பு (blast radius) குறைவாகவே இருக்கும்.

இந்த முறை அதிக அளவிலான, ஹெடலெஸ் ஆட்டோமேஷனுக்கு (headless automation) மிகவும் சிறந்தது: விளம்பரச் செலவு அறிக்கைகளை ஒத்திசைத்தல் (syncing), சமூக ஊடக API மூலம் பதிவிடுதல் அல்லது கட்டமைக்கப்பட்ட JSON-ஐத் தரும் எண்ட்-பாயிண்டுகளைத் தரவு சேகரித்தல் (scraping). இது ஸ்கிரீன்ஷாட்களை விட இலகுவானது மற்றும் நிரலாக்க ரீதியாக (programmatically) சரிபார்ப்பது மிகவும் எளிதானது.

தொடர்ச்சியான பணிகளுக்கான ஆதாரச் சங்கிலிகள் (Proof Chains for Continuous Work)

சில பணிகள் ஒரு தனி...