Read-Only மட்டுமே போதுமானதல்ல: AI ஏஜெண்டுகளுக்கான பாதுகாப்பு வேலிகள் (Guardrails)

AI ஏஜெண்டுகளைப் பாதுகாப்பாக வைத்திருக்க மூத்த பொறியாளர்கள் (Senior engineers) பெரும்பாலும் ஒரு விஷயத்தைச் சொல்வார்கள்: அவற்றுக்கு 'read-only' அணுகலை வழங்கவும்.

இது பாதுகாப்பானது போலத் தோன்றுகிறது. ஏஜெண்ட் எதையும் சிதைக்காமல், மெதுவான வினவல்களை (slow queries) ஆராயலாம் அல்லது ஸ்கீமாக்களை (schemas) சுருக்கமாகக் கூறலாம்.

ஆனால் read-only என்பது ஒரு பாதுகாப்பு மாதிரி (safety model) அல்ல. அது ஒரு வரம்பு (limitation) மட்டுமே.

உங்கள் ஏஜெண்ட் பயனுள்ள வேலையைச் செய்ய வேண்டிய தருணத்தில், read-only அதைத் தடுத்துவிடுகிறது. ஒரு ஏஜெண்ட் தவறான இன்டெக்ஸ் (index) அல்லது சிதைந்த வரிசையைக் (corrupted row) கண்டறிந்தால், அதைச் சரிசெய்ய முடியாது. இது ஒரு தீயைக் காட்டிவிட்டு, அதை அணைக்கத் தண்ணீர் குழாயைத் தூக்க முடியாத ஒரு உதவியாளரைப் போன்றது.

குழுக்கள் பெரும்பாலும் கைவிட்டு, ஏஜெண்டிற்கு 'write access' வழங்கத் தொடங்கிவிடுகின்றன. அப்போதே உண்மையான ஆபத்து தொடங்குகிறது.

உண்மையான கேள்வி "ஏஜெண்ட் எழுதலாமா?" என்பது அல்ல. உண்மையான கேள்வி "அந்த எழுத்துக்களை (writes) நீங்கள் எவ்வாறு கட்டுப்படுத்துகிறீர்கள் (govern)" என்பதுதான்.

அறிவுறுத்தல்கள் (instructions) மூலம் எழுத்துக்களைக் கட்டுப்படுத்த முயற்சிக்காதீர்கள். "எப்போதும் ஒரு அட்டவணையை (table) நீக்க வேண்டாம்" என்பது போன்ற விதிகளை சிஸ்டம் பிராம்ப்ட்டில் (system prompt) வைக்காதீர்கள்.

'Prompt injection' இத்தகைய விதிகளைப் பயனற்றதாக்கிவிடுகிறது. ஒரு தாக்குதல் நடத்துபவர் (attacker), தரவின் ஒரு வரிசையையோ அல்லது ஒரு கருத்தையோ (comment) பயன்படுத்தி, உங்கள் விதிகளை ஏஜெண்ட் புறக்கணிக்கச் செய்யலாம். பாதுகாப்பு வேலிகள் (guardrails) ஏஜெண்டின் அதே விண்டோவில் இருந்தால், ஏஜெண்ட் விவாதத்தின் மூலம் அதைத் தவிர்க்க முடியும்.

கட்டுப்பாடற்ற எழுத்துக்களுக்கும் (ungoverned writes) மற்றும் இடைத்தரகர் மூலம் கட்டுப்படுத்தப்படும் எழுத்துக்களுக்கும் (mediated writes) இடையே ஒரு வேறுபாடு தேவை.

• கட்டுப்பாடற்ற எழுத்துக்கள் (Ungoverned writes): ஏஜெண்ட் ஒரு கட்டளையை இயக்கத் தீர்மானிக்கிறது, மேலும் தரவுத்தளம் (database) அதைச் செயல்படுத்துகிறது. ஏஜெண்டின் சொந்தத் தீர்ப்பே இங்கு ஒரே கட்டுப்பாடு. • இடைத்தரகர் மூலம் கட்டுப்படுத்தப்படும் எழுத்துக்கள் (Mediated writes): கட்டளை ஏஜெண்டிற்கு வெளியே உள்ள ஒரு சோதனைப் புள்ளியின் (checkpoint) வழியாகச் செல்கிறது. இந்தச் சோதனைப் புள்ளி ஏஜெண்ட் மற்றும் தரவுத்தளத்திற்கு இடையிலான தரவுப் பாதையில் (data path) அமைகிறது.

ஒரு mediated write இவ்வாறு செயல்படுகிறது:

  • ஏஜெண்ட் ஒரு அறிக்கையை முன்மொழிகிறது.
  • ஒரு proxy அல்லது control plane அந்த அறிக்கையை ஆய்வு செய்கிறது (parses).
  • proxy அபாயத்தை வகைப்படுத்துகிறது.
  • அதை அனுமதிக்கலாமா அல்லது ஒரு மனிதரிடம் அனுமதி கேட்கலாமா என்பதை proxy தீர்மானிக்கிறது.

இந்த அணுகுமுறை உங்களைப் 'prompt injection'-லிருந்து பாதுகாக்கிறது. ஒரு தீய அறிவுறுத்தல் ஏஜெண்டைத் தவறாக வழிநடத்தி DROP TABLE கட்டளையை எழுதச் செய்யலாம், ஆனால் அது proxy-யைத் ஏமாற்ற முடியாது. proxy ஏஜெண்டின் நோக்கத்தைப் (intent) படிப்பதில்லை; அது உண்மையான SQL கட்டளையை மட்டுமே பார்க்கிறது.

பாதுகாப்பாக இருக்க இந்த அமைப்பைப் பயன்படுத்தவும்:

  • பாதுகாப்பான வாசிப்புகளை (reads) தானாகவே அனுமதிக்கவும். வேலையை விரைவாக வைத்திருக்க, ஏஜெண்டுகள் SELECT வினவல்களைத் தடையின்றி இயக்க அனுமதிக்கவும்.
  • அபாயகரமான எழுத்துக்களுக்குத் தடை விதிக்கவும். DELETE, UPDATE அல்லது ஸ்கீமா மாற்றங்களுக்கு மனித அனுமதி தேவைப்பட வேண்டும்.
  • அனைத்தையும் பதிவு செய்யவும் (Log). மாற்றத்தை முன்மொழிந்தவர் யார் மற்றும் அதை அங்கீகரித்தவர் யார் என்பதற்கான மாற்ற முடியாத (immutable) பதிவை வைத்திருக்கவும்.

பாதுகாப்பிற்காக read replicas-களை மட்டும் நம்பியிருக்க வேண்டாம். Replicas ஆய்வுக்கு உதவுகின்றன, ஆனால் அவை சரிசெய்தல்களைச் செய்ய முடியாது. ஒரு production சிக்கலைச் சரிசெய்ய, நீங்கள் முதன்மைத் தரவுத்தளத்தில் (primary database) எழுத வேண்டும்.

Mediation முறை உங்கள் தரவைப் பாதுகாப்பாக வைத்திருக்கும் அதே வேளையில், ஏஜெண்டையும் பயனுள்ளதாக மாற்ற அனுமதிக்கிறது.

Source: https://dev.to/maxime_dalessandro_28171d/read-only-isnt-enough-guardrails-for-ai-agents-that-change-your-database-2e5h

Optional learning community: https://t.me/GyaanSetuAi