EPFL மற்றும் Swisscom ஆகியவற்றின் கூட்டு முயற்சியான CAPMAS, டெவலப்பர்கள் AI child agents-களுக்கு macaroons மூலம் குறுகிய வரம்பிற்குட்பட்ட அனுமதிகளை (narrowly scoped permissions) வழங்க அனுமதிக்கிறது. இது token-handling தாமதத்தை (latency) 30 மடங்கு குறைக்கிறது மற்றும் முழு பயனர் JWT-களை ஏஜெண்டுகளின் அணுகலுக்கு அப்பாற்பட்டதாக வைக்கிறது.

இந்த மாற்றம் ஏன் முக்கியமானது

ஒரு LLM கீழ்நிலை கருவிகளை (downstream tools) ஒருங்கிணைக்கும்போது, பயனர்கள் உள்நுழைந்த அதே JWT-ஐ உருவாக்கப்பட்ட “child” ஏஜெண்டிற்கு குழுக்கள் பெரும்பாலும் வழங்குகின்றன. JWT என்பது பயனர் கொண்டுள்ள ஒவ்வொரு அனுமதியையும் (HR தரவு, திட்டக் கோப்புகள், நிர்வாக உரிமைகள் போன்றவை) பட்டியலிடும் ஒரு கையொப்பமிடப்பட்ட பிளாப் (signed blob) ஆகும். ஒருவேளை மாடல் ஒரு அழிவுகரமான கட்டளையைத் தவறாக உருவாக்கினால் (hallucinates), அந்த child ஏஜென்ட் பயனரின் முழு அதிகாரத்துடன் அதைச் செயல்படுத்த முடியும். ஒரு சிறிய தவறு கூட ஒரு முழு நிறுவனத்தின் தரவையும் வெளிப்படுத்தக்கூடும்.

தற்போதைய மாற்று வழிமுறையின் குறைபாடுகள்

RFC 8693 token-exchange முறையைப் பயன்படுத்தி தேவைக்கேற்ப ஒரு குறுகிய டோக்கனை உருவாக்குவது, IAM அமைப்பிற்கு பலமுறை தொடர்புகொள்ள வேண்டிய சூழலை (round-trips) உருவாக்குகிறது, நெட்வொர்க் போக்குவரத்தை அதிகரிக்கிறது மற்றும் குறிப்பிடத்தக்க தாமதத்தை (latency) ஏற்படுத்துகிறது. குறுகிய காலத்திற்குப் பல ஏஜெண்டுகளை உருவாக்கும் குழுக்கள், இந்த கூடுதல் சுமை (overhead) பெரும் இடையூறாக இருப்பதை விரைவில் உணர்கிறார்கள்.

CAPMAS எவ்வாறு செயல்படுகிறது

CAPMAS அனுமதி வழங்குவதை இரண்டு நிலைகளாகப் பிரிக்கிறது:

  1. IAM-side encoding – IAM சேவை ஒரு என்கோடரை (encoder) இயக்குகிறது, இது ஒரு இயற்கை மொழி கோரிக்கையை (உதாரணமாக, “finance folder-இல் உள்ள கோப்புகளைப் பட்டியலிடு”) பொருந்தக்கூடிய சில சலுகைகளாக (privileges) மாற்றுகிறது.
  2. Macaroon creation – அந்தச் சலுகைகள் ஒரு macaroon-க்குள் caveats-களாக மாறுகின்றன. macaroon என்பது ஒரு நெகிழ்வான டோக்கன் வடிவமாகும், இது கீழ்நிலை ஏஜெண்டுகள் கூடுதல் கட்டுப்பாடுகளைச் சேர்க்க அனுமதிக்கிறது, ஆனால் ஏற்கனவே உள்ளவற்றை நீக்க அனுமதிக்காது.

ஒரு ஏஜென்ட் macaroon-ஐப் பெறும்போது, அது அதன் வரம்பைக் குறைக்க முடியும் (உதாரணமாக, ஒரு கோப்புப் பட்டியல் கோரிக்கையை ஒரு துணை-இயக்குனருக்கு (sub-directory) மட்டும் கட்டுப்படுத்துவது), ஆனால் அதை விரிவுபடுத்த முடியாது. ஒவ்வொரு கட்டத்திலும் (hop), IAM சேவை அனைத்து caveats-களின் வெட்டுப்புள்ளியை (intersection) சரிபார்க்கிறது, இதன் மூலம் எந்த ஏஜென்ட்டும் அசல் அனுமதியைத் தாண்டாது என்பதை உறுதி செய்கிறது.

செயல்திறன் எண்கள் எதைக் கூறுகின்றனவோ அவை

  • Speed – CAPMAS ஒரு அனுமதி கோரிக்கையை 20 ms-க்கும் குறைவான நேரத்தில் செயலாக்குகிறது, இது RFC 8693 பரிமாற்றத்தை விட சுமார் 30 மடங்கு வேகமானது.
  • Accuracy – கருவிகளின் பெரிய பட்டியலைக் கொண்ட ஒரு பெஞ்ச்மார்க்கில் (benchmark), ஒரு சாதாரண LLM தனக்குத் தேவையான சலுகைகளில் 53 %-ஐத் தவறவிட்டது. CAPMAS 90.9 % துல்லியத்தை எட்டியது, அதன் தவறவிடும் விகிதம் (miss rate) வெறும் 2.1 % மட்டுமே.
  • Bandwidth – macaroon இறுதி caveats தொகுப்பை மட்டுமே சுமந்து செல்வதால், பரிமாறப்படும் தரவு ஒரு முழு token-exchange முறைக்குத் தேவைப்படும் தரவின் ஒரு சிறிய பகுதி மட்டுமே.

ஒரு நடைமுறைப் பயன்பாட்டு முறை (Pragmatic adoption workflow)

  1. Pre-filter the request – எந்த ஒரு ஒருங்கிணைப்பாளர் (orchestrator) கருவிப் பட்டியலைத் தொடங்குவதற்கு முன்பே, பயனரின் இயற்கை மொழி நோக்கத்தை (natural-language intent) ஒரு top-k அனுமதிக்கப்பட்ட பட்டியலாக (allowlist) மாற்றவும்.
  2. Seal the allowlist – அந்த அனுமதிக்கப்பட்ட பட்டியலை ஒரு macaroon-ஆக என்கோட் செய்யவும், அதை child ஏஜென்ட் விரிவுபடுத்த முடியாது.
  3. Verify at the service – கோரிக்கையை ஏற்றுக்கொள்வதற்கு முன், அனைத்து caveats-களின் வெட்டுப்புள்ளியைக் கணக்கிடுமாறு இலக்குச் சேவையிடம் (target service) IAM-ஐக் கேட்கச் செய்யவும்.

இந்த நிலைகள், “குழந்தைக்கு வீட்டின் முழு சாவியையும் கொடுப்பது” போன்ற முறையை மாற்றி, “ஒருமுறை மட்டுமே பயன்படுத்தக்கூடிய, வரையறுக்கப்பட்ட வரம்பு கொண்ட சாவியை வழங்குவது” போன்ற மாதிரியைப் பயன்படுத்துகின்றன.

CAPMAS எதைச் சரிசெய்யாது

இந்த கட்டமைப்பானது prompt-injection தாக்குதல்களைத் தடுப்பதில்லை; இதில் தாக்குபவர் தீய கட்டளைகளைச் செலுத்த LLM-ன் prompt-ஐக் கையாளுகிறார். இதன் பாதுகாப்பு, நேர்மையான ஆனால் ஆர்வமுள்ள ஏஜெண்டுகள் (honest-but-curious agents) மற்றும் முழு JWT-ஐப் பயன்படுத்திச் செயல்படக்கூடிய நம்பகமற்ற LLM-களைப் பாதுகாக்கிறது. Prompt சார்ந்த அச்சுறுத்தல்களைக் கையாள, குழுக்கள் இன்னும் தனித்தனித் தடுப்பு முறைகளை—input sanitisation, sandboxing அல்லது model-level guardrails—பயன்படுத்த வேண்டியது அவசியம்.

இதனால் பயனடைபவர்கள்

  • Enterprise developers - உள்நிலை API-களைப் பயன்படுத்தும் AI சார்ந்த உதவியாளர்களை உருவாக்கும் டெவலப்பர்கள்.
  • Security teams - ஒரு மாடல் ஊடுருவப்பட்டால் (compromised model) ஏற்படும் பாதிப்பின் பரப்பளவைக் (blast radius) குறைக்க விரும்பும் பாதுகாப்புத் குழுக்கள்.
  • Product owners - அதிகப்படியான ஏஜெண்டுகளை உருவாக்கும்போது, விரைவான மற்றும் நம்பகமான அனுமதிச் சரிபார்ப்புகள் தேவைப்படும் தயாரிப்பு உரிமையாளர்கள்.

அடுத்து என்ன

CAPMAS என்பது முன்மொழியப்பட்ட ஒரு வடிவமைப்பு (proposed design).

Takeaway: முழு பயனர் JWT-களுக்குப் பதிலாக குறுகிய வரம்பிற்குட்பட்ட macaroons-களைப் பயன்படுத்துவது, பாரம்பரிய token-exchange முறைகளின் தாமதத் தொகையைச் செலுத்தாமல், AI ஏஜெண்டுகளை நேர்மையாக வைத்திருக்க டெவலப்பர்களுக்கு ஒரு வழியை வழங்குகிறது. இருப்பினும், prompt-injection பாதுகாப்பிற்கான தேவை ஒரு சவாலாகவே தொடர்கிறது.