Authentication என்பது நீங்கள் யார் என்பதைச் சரிபார்க்கிறது; authorization என்பது நீங்கள் என்ன செய்யலாம் என்பதைத் தீர்மானிக்கிறது. பெருகிவரும் எண்ணிக்கையிலான AI-ஆல் இயங்கும் செயலிகள், பயனர் உள்நுழையும் போது ஒருமுறை மட்டும் அடையாளத்தைச் சரிபார்க்கின்றன, பின்னர் அந்த அமர்வு (session) முழுவதும் எந்தவொரு வளத்தையும் (resource) கையாள அந்த ஏஜென்ட்டிற்கு (agent) அனுமதி அளிக்கின்றன. இது நடைமுறையில் அதற்கு ஒரு "எந்தக் கட்டுப்பாடும் இல்லாத அதிகாரத்தை" (blank check) வழங்குவதற்குச் சமம். இத்தகைய வடிவமைப்பு, தற்செயலான தரவு கசிவுகள், தேவையற்ற மின்னஞ்சல்கள் அல்லது அழிவுகரமான தரவுத்தள மேம்படுத்தல்கள் (database updates) போன்றவற்றுக்கு வழிவகுக்கிறது, மேலும் ஒரு AI உதவியாளர் மில்லி விநாடி தாமதத்தில் (millisecond latency) பல கருவிகளைப் பயன்படுத்தும் போது இந்த ஆபத்து அதிகரிக்கிறது.

இந்தத் தவறு ஏன் மீண்டும் மீண்டும் நிகழ்கிறது

பெரும்பாலான AI மேம்பாட்டாளர்கள் லாகின் திரையை மட்டுமே ஒரே ஒரு பாதுகாப்பு நுழைவாயிலாகக் கருதுகின்றனர். குறியீடு (code) கடவுச்சொல் அல்லது டோக்கனைப் பெற்று, அந்த அமர்வை “authenticated” என்று அடையாளப்படுத்துகிறது, பின்னர் அதன் பிறகு வரும் எந்தவொரு கோரிக்கையும் பாதுகாப்பானது என்று assumption செய்கிறது. ஒரு பாரம்பரிய இணையச் செயலியில் (web app), ஒரு மனிதப் பயனரின் மெதுவான கிளிக்குகள் இயற்கையான வேகக் கட்டுப்பாட்டை (throttling point) வழங்குகின்றன; ஒரு மனிதன் “delete” பொத்தானை அழுத்துவதற்கு முன் சற்றுத் தயங்குவான். ஆனால், ஒரு AI ஏஜென்ட், சில விநாடிகளில் டஜன் கணக்கான கருவி அழைப்புகளை (tool calls) மேற்கொள்ள முடியும். ஒரு தளம் “பயனர் உள்நுழைந்துள்ளாரா?” என்று மட்டும் கேட்டால், ஒவ்வொரு அழைப்பும் அதே கட்டுப்பாடற்ற அதிகாரத்தைப் பெறுகிறது.

இதன் மூலக் காரணம் வசதி (convenience). குறியீடு பல டோக்கன்கள் அல்லது ஸ்கோப்களை (scopes) நிர்வகிக்க வேண்டிய அவசியமில்லாமல் இருக்க வேண்டும் என்பதற்காக, குழுக்கள் பெரும்பாலும் முழு பயன்பாட்டிற்கும் ஒரே ஒரு நீண்டகால சேவை கணக்கை (long-lived service account) வழங்குகின்றன. அந்த கணக்கிற்கு பொதுவாக அனைத்துத் திட்டங்களிலும் (projects) படிக்க, எழுத மற்றும் நீக்க போன்ற பரந்த அனுமதிகள் இருக்கும். ஒரு AI உதவியாளர் அந்த அமர்வுக்குள் இயங்கும்போது, தற்போதைய பணிக்குத் தேவையா இல்லையா என்பதைப் பொருட்படுத்தாமல், அது தானாகவே அந்த உரிமைகளைப் பெறுகிறது.

இதில் உள்ள ஆபத்துகள் என்ன

  • தரவு வெளிப்பாடு (Data exposure) – பயனர் உள்நுழைந்த பிறகு எந்தவொரு கோப்பையும் படிக்கக்கூடிய ஒரு ஏஜென்ட், ரகசிய ஆவணங்களை எதிர்பாராமல் ஒரு பதிலில் கொண்டு வரலாம், அது பின்னர் நிறுவனத்திற்கு வெளியே பகிரப்படக்கூடும்.
  • எதிர்பாராத செயல்கள் (Unintended actions) – ஒரு சப்போர்ட் இன்ஜினியரின் AI உதவியாளர், அந்த இன்ஜினியரின் அமர்வு (session) இன்னும் செயல்பாட்டில் இருப்பதால், கையாளப்படும் டிக்கெட்டுடன் தொடர்பில்லாத ஒரு SQL வினாவையும் (query) தயாரிப்பு தரவுத்தளங்களுக்கு (production databases) எதிராகச் செயல்படுத்தக்கூடும்.
  • ஒழுங்குமுறை இணக்கம் (Regulatory compliance) – பல தரவுப் பாதுகாப்பு விதிகள், அணுகல் என்பது தேவையான குறைந்தபட்ச அளவிலேயே இருக்க வேண்டும் என்று கூறுகின்றன. ஒரு பொதுவான அனுமதி மாதிரி (blanket permission model) அந்தத் தத்துவங்களை மீறக்கூடும் மற்றும் தணிக்கைகள் அல்லது அபராதங்களைத் தூண்டக்கூடும்.
  • செயல்பாட்டுச் செலவு (Operational cost) – பதிவுகளை நீக்கும் அல்லது மாற்றும் தவறுகள், குழுக்களை மாற்றங்களைச் சரிசெய்யவும் (roll back), மூலக் காரணங்களை ஆராயவும் மற்றும் பயனர்களிடம் நம்பிக்கையை மீண்டும் கட்டியெழுப்பவும் கட்டாயப்படுத்துகின்றன—இவை அனைத்தும் நேரம் மற்றும் பணத்தை வீணடிக்கின்றன.

விடுபட்ட படி: ஒவ்வொரு செயலுக்கான அனுமதி (per-action authorization)

அனுமதி என்பது முறையின் முன் நுழைவாயிலில் மட்டுமல்லாமல், அமைப்பிற்குள் இருக்கும் ஒவ்வொரு “கதவிலும்” மதிப்பீடு செய்யப்பட வேண்டும். கேள்வி “இது யார்?” என்பதிலிருந்து “இந்த குறிப்பிட்ட வளத்தின் மீது இந்த குறிப்பிட்ட செயல் இப்போது நடக்கலாமா?” என்று மாற வேண்டும். அந்தச் சரிபார்ப்பைச் செயல்படுத்துவதற்கு முழுமையான மறுவடிவமைப்பு தேவையில்லை; ஒரு ஒற்றை அமர்வு கொடியிலிருந்து (single session flag), குறுகிய கால அளவிலான, ஸ்கோப் செய்யப்பட்ட டோக்கன்களுக்கு (short-lived, scoped tokens) மாறுவது மட்டுமே போதுமானது.

இது நடைமுறையில் எவ்வாறு செயல்படுகிறது

  1. வரையறுக்கப்பட்ட ஸ்கோப் கொண்ட டோக்கனை கோருதல் – AI ஏஜென்ட் ஒரு கருவியைப் பயன்படுத்த வேண்டியிருக்கும் போது, முதலில் தேவையான துல்லியமான அனுமதிகளைக் பட்டியலிடும் ஒரு டோக்கனைப் பெறுகிறது (உதாரணமாக, read:ticket, execute:sql_query).
  2. ஒவ்வொரு அழைப்பிற்கும் டோக்கனைச் சரிபார்த்தல் – கருவி இயங்குவதற்கு முன், அந்த டோக்கனில் தேவையான ஸ்கோப் உள்ளதா என்பதையும், டோக்கன் காலாவதியாகவில்லை என்பதையும் சேவை சரிபார்க்கிறது.
  3. வளத்தை ஸ்கோப்புடன் பொருத்துதல் – கோரிக்கை ஒரு குறிப்பிட்ட திட்டம் அல்லது தரவுத்தளத்தை இலக்காகக் கொண்டிருந்தால், டோக்கன் அந்த அடையாளத்திற்கு (identifier) வெளிப்படையாக அணுகலை வழங்க வேண்டும்.
  4. நிராகரித்தல் அல்லது அனுமதித்தல் – ஏதேனும் ஒரு சரிபார்ப்பு தோல்வியடைந்தால், அந்த அழைப்பு மறுக்கப்படும் மற்றும் ஏஜென்ட் பயனருக்குத் தெரிவிக்கக்கூடிய ஒரு பிழைச் செய்தியைப் பெறும்.

குறியீட்டில் உள்ள வேறுபாடு மிகவும் எளிமையானது. ஒரு “தவறான” அணுகுமுறை இவ்வாறு இருக்கலாம்:

if session.is_authenticated():
    tool.run(params)

ஒரு “நல்ல” அணுகுமுறை சரிபார்ப்பை விரிவுபடுத்துகிறது:

token = get_scoped_token(user, required_scope)
if token.is_valid() and token.allows(required_scope, resource_id):
    tool.run(params)
else:
    raise PermissionError

இரண்டாவது முறை சில வரிகளைச் சேர்க்கிறது, ஆனால் ஒவ்வொரு செயல்பாட்டிற்கும் சரியான கேள்வியைக் கேட்க அமைப்பைத் தூண்டுகிறது.

எளிதாக்கும் தரநிலைகள்

OAuth 2.0 ஸ்கோப்கள் ஏற்கனவே ஒரு டோக்கன் என்ன செய்ய முடியும் என்பதைக் கட்டுப்படுத்த பரவலாகப் பயன்படுத்தப்படும் வழியை வழங்குகின்றன. project:1234:write அல்லது email:send போன்ற ஸ்கோப்களைக் கொண்ட குறுகிய கால அணுகல் டோக்கன்களை வழங்குவதன் மூலம், சரிபார்ப்புப் படிநிலையைச் செய்ய மேம்பாட்டாளர்கள் ஏற்கனவே உள்ள நூலகங்களை (libraries) நம்பியிருக்கலாம்.

புதிய Rich Authorization Requests (RFC 9396) இந்த யோசனையை மேலும் விரிவுபடுத்துகிறது, இது ஒரு நிலையான பட்டியலை முன்கூட்டியே வரையறுப்பதற்குப் பதிலாக, இயக்க நேரத்தில் (runtime) நுணுக்கமான அனுமதிகளைக் கோர ஒரு கிளையன்ட்டை அனுமதிக்கிறது. பயனர் நோக்கத்தின் அடிப்படையில் ஒரு AI பணிப்பாய்வு (workflow) திறன்களை உடனுக்குடன் சேர்க்கவோ அல்லது நீக்கவோ தேவைப்படும் போது இந்த நெகிழ்வுத்தன்மை பயனுள்ளதாக இருக்கும்.

எதிர்வாதம்: எளிமை மற்றும் பாதுகாப்பு

சில குழுக்கள் ஒவ்வொரு செயலுக்கான சரிபார்ப்புகளும் (per-action checks) தாமதத்தையும் (latency) குறியீட்டுச் சிக்கலையும் (code complexity) ஏற்படுத்தும் என்று வாதிடுகின்றனர், குறிப்பாக AI உதவியாளர் பல கருவிகளைத் தொடர்ச்சியாக விரைவாக அழைக்க வேண்டியிருக்கும் போது. ஒவ்வொரு அழைப்பிற்கும் புதிய டோக்கனைப் பெறுவதற்கும் சரிபார்ப்பதற்கும் ஆகும் கூடுதல் சுமையைத் தவிர்க்க, ஒரு ஒற்றை செஷன் டோக்கன் (session token) போதுமானது என்று அவர்கள் சுட்டிக்காட்டுகின்றனர். இருப்பினும், இதன் விளைவாகத் தவறான பயன்பாட்டிற்கான (misuse) வாய்ப்பு மிக அதிகமாக அதிகரிக்கிறது. நவீன டோக்கன்-சரிபார்ப்பு சேவைகள் மைக்ரோசெகண்டுகளில் செயல்படும் வகையில் வடிவமைக்கப்பட்டுள்ளன, மேலும் 'குறைந்தபட்ச அதிகாரக் கொள்கையை' (principle of least privilege) விட்டுக்கொடுக்காமல், கூடுதல் நெட்வொர்க் சுழற்சிகளை (network round-trip) தொகுப்பாகவோ (batch) அல்லது சேமிப்பகமாகவோ (cache) மாற்ற முடியும். தரவுத் துல்லியம் (data integrity) மற்றும் இணக்கம் (compliance) ஆகியவை சமரசத்திற்கு அப்பாற்பட்ட சூழல்களில், சிறிய அளவிலான செயல்திறன் இழப்பை விட, அபாயத்தைக் குறைப்பதே முக்கியமானது.

அடுத்து கவனிக்க வேண்டியவை

  • AI SDK-களில் ஸ்கோப் செய்யப்பட்ட டோக்கன்களின் (scoped tokens) பயன்பாடு – முக்கிய AI பிளாட்ஃபார்ம் டூல் kits-களின் புதுப்பிப்புகளைக் கவனித்துக் கொண்டே இருங்கள்; பல நிறுவனங்கள் OAuth-அடிப்படையிலான ஸ்கோப்பிற்கான (scopes) உதவியாளர் செயல்பாடுகளை (helper functions) அறிமுகப்படுத்தத் தொடங்கியுள்ளன.
  • Policy-as-code கட்டமைப்புகள் – வளர்ந்து வரும் தீர்வுகள், குழுக்கள் அங்கீகார விதிகளை (authorization rules) ஒரு அறிவிப்பு கோப்பில் (declarative file) வரையறுக்கவும், அவற்றை இயங்கும் நேரத்தில் (runtime) தானாகவே நடைமுறைப்படுத்தவும் அனுமதிக்கின்றன.
  • ஒவ்வொரு செயலுக்கான முடிவுகளையும் வெளிப்படுத்தும் தணிக்கை பதிவுகள் (Audit logs) – அதிகப்படியான பிளாட்ஃபார்ம்கள் ஒவ்வொரு அங்கீகாரச் சரிபார்ப்பையும் பதிவு செய்யும்போது, எந்த AI செயல்கள் அனுமதிக்கப்படுகின்றன அல்லது தடுக்கப்படுகின்றன என்பதை நிறுவனங்கள் தெளிவாக அறிய முடியும், இது எதிர்காலக் கொள்கை மாற்றங்களுக்கு உதவும்.

முக்கியக் கருத்து

ஒரு லாக்-இன் செய்யப்பட்ட செஷனை (logged-in session) எதையும் செய்வதற்கான அனுமதியாகக் கருதுவது, எதிர்பாராத விளைவுகளுக்கு வழிவகுக்கும். அங்கீகார முடிவை (authorization decision) லாக்-இன் செய்யும் தருணத்திலிருந்து ஒவ்வொரு தனிப்பட்ட கருவி அழைப்பிற்கும் மாற்றுவதன் மூலமும், குறுகிய கால ஸ்கோப் செய்யப்பட்ட டோக்கன்களைப் பயன்படுத்துவதன் மூலமும், AI செயலிகள் தரவைப் பாதுகாத்து, விதிமுறைகளுக்கு இணங்கி, விலையுயர்ந்த தவறுகளைத் தவிர்ப்பதோடு, தன்னாட்சி முகவர்களின் (autonomous agents) வசதியையும் தக்க வைத்துக் கொள்ள முடியும். ஒவ்வொரு முறை ஒரு செயல் முயற்சிக்கப்படும் போதும் சரியான கேள்வியைக் கேட்கும் ஒரு அமைப்பிற்காக, கூடுதல் குறியீட்டு வரிகள் (extra lines of code) என்பது மிகச்சிறிய விலையே.