A2A Protocol Auth: ஏன் இந்த விவரக்குறிப்பு (Spec) மிகக் குறைவாக உள்ளது மற்றும் இதில் உள்ள ஓட்டைகள் எங்கே உள்ளன?

A2A (Agent2Agent) புரோட்டோகால், AI ஏஜென்ட் தொடர்புகளுக்கான தரநிலையாக மாறிவருகிறது. கூகுள் இதை 2025 இல் அறிவித்தது மற்றும் தற்போது Linux Foundation இதை நிர்வகித்து வருகிறது.

இந்த விவரக்குறிப்பின் (spec) அங்கீகாரம் (authentication) பகுதியை நான் பார்த்தபோது, அங்கு கிட்டத்தட்ட எதுவுமே இல்லை என்பதைக் கண்டேன். இது ஒரு புதிய அங்கீகார முறையை வரையறுப்பதில்லை. மாறாக, OAuth2, OpenID Connect அல்லது mTLS போன்ற ஏற்கனவே உள்ள தரநிலைகளைப் பயன்படுத்துமாறு மட்டுமே கூறுகிறது.

இந்தத் தளர்வான தன்மை திட்டமிட்டே செய்யப்பட்டுள்ளது. A2A கட்டமைப்பை (frame) வரையறுக்கிறது, ஆனால் அதன் உள்ளடக்கங்களை மற்ற தரநிலைகளிடம் ஒப்படைக்கிறது. நீங்கள் கவனமாக இல்லையென்றால், இது பாதுகாப்பு ஓட்டைகளை (security holes) உருவாக்கும்.

A2A எவ்வாறு செயல்படுகிறது ஒரு ஏஜென்ட் மற்றொரு ஏஜென்ட்டிடம் ஒரு பணியை ஒப்படைப்பதற்கான புரோட்டோகால் தான் A2A. இது HTTP வழியாக JSON-RPC ஐப் பயன்படுத்துகிறது.

• கிளையன்ட் ஏஜென்ட் (Client Agent): கோரிக்கையை அனுப்பும் ஏஜென்ட். • ரிமோட் ஏஜென்ட் (Remote Agent): பணியைப் பெறும் ஏஜென்ட். • ஏஜென்ட் கார்டு (Agent Card): ரிமோட் ஏஜென்ட் தனது திறன்கள் மற்றும் அங்கீகாரத் தேவைகளைப் பட்டியலிடும் ஒரு JSON கோப்பு.

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

பாதுகாப்பு ஓட்டைகள் A2A பல முக்கியமான பணிகளைச் செயல்படுத்துபவரிடமே (implementer) விட்டுவிடுகிறது. இவற்றை நீங்கள் சரியாகக் கையாளவில்லை என்றால், உங்கள் ஏஜென்ட்கள் ஆபத்திற்கு உள்ளாகும்.

  • கார்டு முறைகேடு (Card Tampering): ஏஜென்ட் கார்டில் கையொப்பமிடுவது விருப்பத்தேர்வு (MAY) மட்டுமே. நீங்கள் அதில் கையொப்பமிடவில்லை என்றால், ஒரு தாக்குதல் நடத்துபவர் (attacker) உங்கள் ஏஜென்ட்டை ஒரு தீங்கிழைக்கும் சர்வருக்குத் திருப்ப முடியும்.
  • ரீப்ளே அட்டாக்ஸ் (Replay Attacks): டோக்கன்களை ஒரு குறிப்பிட்ட கிளையன்ட்டுடன் இணைப்பதற்கான வழிமுறை A2A-வில் இல்லை. யாராவது ஒரு bearer token-ஐத் திருடிவிட்டால், அவர்கள் உங்கள் ஏஜென்ட் போலச் செயல்பட முடியும்.
  • அதிகார உயர்வு (Privilege Escalation): அங்கீகாரம் (Authorization) என்பது வெளிப்புற உள்கட்டமைப்பிற்கு விடப்பட்டுள்ளது. நீங்கள் ஒவ்வொரு திறனுக்கும் (per-skill) சரிபார்ப்புகளைச் செயல்படுத்தவில்லை என்றால், ஒரு "read-only" ஏஜென்ட் "write" அணுகலைப் பெறக்கூடும்.
  • அடையாளச் சங்கிலி (Identity Chaining): ஒரு பயனரின் அடையாளம் ஏஜென்ட்களின் சங்கிலி வழியாக எவ்வாறு நகர்கிறது என்பதை A2A கையாளுவதில்லை.

இதை எவ்வாறு பாதுகாப்பாக உருவாக்குவது? விவரக்குறிப்பை (spec) மட்டும் நம்பியிருக்க வேண்டாம். விருப்பத்தேர்வு விதிகளையும் (optional rules) நீங்கள் கட்டாய விதிகளாக (mandatory rules) மாற்ற வேண்டும்.

• உங்கள் ஏஜென்ட் கார்டுகளில் எப்போதும் கையொப்பமிடுங்கள். JWS மற்றும் JCS ஐப் பயன்படுத்துங்கள். • ஏஜென்ட்-டு-ஏஜென்ட் பாதைகளுக்கு mTLS ஐப் பயன்படுத்துங்கள். இது டோக்கன் திருடப்படுவதன் மூலம் உங்கள் அமைப்பு பாதிக்கப்படுவதைத் தடுக்கிறது. • உங்கள் API Gateway-இல் ஒவ்வொரு திறனுக்கான அங்கீகாரத்தையும் (per-skill authorization) கட்டாயமாக்குங்கள். • ரீப்ளே அட்டாக்ஸைத் தடுக்க sender-constrained tokens (DPoP போன்றவற்றை) பயன்படுத்துங்கள்.

A2A என்பது குழாய் அமைப்பு (plumbing) போன்றது. அதன் வழியாக நீங்கள் பாயும் நீரைப் பொறுத்தே பாதுகாப்பு அமையும். இடைவெளிகளை நிரப்ப SPIFFE அல்லது Identity Chaining போன்ற நிரூபிக்கப்பட்ட தரநிலைகளைப் பயன்படுத்துங்கள்.

Source: https://dev.to/kanywst/a2a-protocol-auth-taken-apart-why-the-spec-is-thin-and-where-that-leaves-holes-22ii

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