Agent அனுமதியளித்தல் என்பதன் பொருள்
Agent அனுமதியளித்தல் என்பது ஒரு AI agent என்ன செய்ய அனுமதிக்கப்பட்டுள்ளது என்பதைப் பற்றிய தீர்மானம்: அது எந்த routes-ஐ அழைக்கலாம், எந்த data-வைப் படிக்கலாம், எந்த actions-ஐ எடுக்கலாம், மேலும் எந்த அளவில் எடுக்கலாம் என்பதைக் குறிக்கும். இது agent identity-யிலிருந்து வேறுபட்டது, ஏனெனில் agent, அல்லது operator-இன் agent, யார் request செய்கிறார் என்பதை நிறுவுவது identity-யின் பொருள்.
இவை இரண்டும் பெரும்பாலும் ஒன்றாக வருவதால், இரண்டையும் குழப்புவது எளிது. ஒரு signed request அதை அனுப்பியது யார் என்பதைச் சொல்கிறது. ஆனால் அந்த sender account-ஐ மாற்ற, order இட, அல்லது data export செய்ய அனுமதிக்கப்பட வேண்டுமா என்பதைச் சொல்லாது. Identity என்பது evidence; அனுமதியளித்தல் என்பது policy. signed AI agent requests என்ன நிரூபிக்கின்றன, மற்றும் என்ன நிரூபிக்கவில்லை என்ற எங்கள் post இந்த வேறுபாட்டை விரிக்கிறது.
இந்த வேறுபாடு ஏன் முக்கியம்
மனித users-க்காக Applications ஏற்கனவே authentication-ஐ authorization-இலிருந்து பிரிக்கின்றன: login செய்வது நீங்கள் யார் என்பதை நிரூபிக்கிறது, roles மற்றும் permissions நீங்கள் என்ன செய்யலாம் என்பதைத் தீர்மானிக்கின்றன. Agents-க்கும் அதே பிரிப்பு தேவை, ஆனால் கூடுதல் கவனத்துடன்:
- Identity வலுவாக இருந்தாலும் permission இல்லாமல் இருக்கலாம். சரியாக valid ஆன HTTP message signature கொண்ட ஒரு crawler-க்கு write endpoint-ஐ அழைக்கும் இயல்பான உரிமை இல்லை.
- வலுவான identity இல்லாமலும் permission இருக்கலாம். ஒரு customer's API key-ஐ பயன்படுத்தும் agent, அந்த key மூலம் authorization பெறுகிறது, அந்த key-ஐ எந்த agent software வைத்திருக்கிறது என்பது தெரியாவிட்டாலும்.
- Agent-க்குப் பின்னுள்ள நபர் முக்கியம். ஒரு agent யாருக்காக செயல்படுகிறதோ, அந்த நபர் அதற்கு authority அளித்தாரா என்பதே கேள்வி ஆகிறது (பார்க்க delegated authority).
இவற்றை ஒரே check-ஆக இணைத்தால் இரண்டு failure mode-கள் உருவாகும்: மனித login இல்லாததால் legitimate automation-ஐ தடுக்குவது, அல்லது நன்றாக அடையாளம் காணப்பட்ட agent-ஐ அது எப்போதும் செய்யவேண்டும் என்பதல்லாத actions-க்கு நம்புவது.
அனுமதியளித்தல் பொதுவாக எவ்வாறு வெளிப்படுத்தப்படுகிறது
பெரும்பாலான applications ஏற்கனவே உள்ள mechanisms-ஐ பயன்படுத்தி agents-ஐ அனுமதிக்கின்றன:
- Credentials மற்றும் scopes. API keys அல்லது scopes வரம்பிடப்பட்ட OAuth 2.0 tokens, integration-க்கு தேவையானவற்றிற்கே மட்டும்.
- MCP servers இதே model-ஐ பயன்படுத்துகின்றன: MCP authorization specification பாதுகாக்கப்பட்ட server-ஐ OAuth 2.1 resource server-ஆகக் கருதுகிறது.
- Route-நிலை policy. தெரிந்த agents-க்கு read-only routes திறந்திருப்பது; write routes account-க்கு இணைக்கப்பட்ட credential-ஐக் கோருவது.
- Risk tiers. குறைந்த தாக்கம் உள்ள actions பரவலாக அனுமதிக்கப்படுகின்றன, அதிக தாக்கம் உள்ள actions அதிக வலுவான credentials, உறுதிப்படுத்தல் அல்லது review தேவைப்படுகின்றன.
- Rate limits மற்றும் quotas operator-க்கு, credential-க்கு, அல்லது route-க்கு ஒன்றாக.
Agent identity evidence இந்த முடிவுகளில் ஒரு input-ஆக செயல்படுகிறது. நடைமுறை அணுகுமுறைக்காக, humans மற்றும் AI agents-க்கான app-level policies வடிவமைத்தல் என்பதைப் பார்க்கவும். இது verified operator-ஐ anonymous client-இலிருந்து வேறுபடச் செய்துகொள்ள உதவுகிறது, ஆனால் permission என்பது இன்னும் உங்கள் policy-யிலிருந்தே வருகிறது.
பொதுவான தவறான புரிதல்கள்
- "Verified agent என்றால் அனுமதிக்கப்பட்டது." Verification ஒரு request-ஐ attribute செய்கிறது. அந்த attributed party என்ன செய்யலாம் என்பதை உங்கள் policy இன்னும் தீர்மானிக்கிறது.
- "மனிதனாக நிரூபிக்கப்படாவிட்டால் agents-ஐ தடுக்க வேண்டும்." பல agents legitmate participants. ஒவ்வொரு actor வகையும் route-by-route என்ன செய்ய அனுமதிக்கப்பட வேண்டும் என்பதே மேலான கேள்வி.
- "நடத்தை மூலம் authorization-ஐ infer செய்யலாம்." நடத்தை எந்த actor வகை உள்ளது என்பதற்கான confidence-ஐ உயர்த்தவோ குறைக்கவோ முடியும். அது தனியாக permission வழங்கக் கூடாது.
Proof of Actor இதை எவ்வாறு கையாளுகிறது
Proof of Actor evidence கேள்விக்குப் பதில் அளிக்கிறது: எந்த வகையான actor உள்ளது, எந்த basis-இல் (verified, declared, inferred, அல்லது unknown), மேலும் என்ன தெரியும், என்ன தெரியாது. இது deliberate-ஆக permission-ஐ தீர்மானிக்காது. ஒரு Agent result, அது verified ஆனாலும் கூட, authorization-ஐ ஒருபோதும் குறிக்காது. Route-இல், உங்கள் application actor result-ஐ அதன் சொந்த credentials, scopes, மற்றும் risk tiers-உடன் இணைத்து ஒவ்வொரு interaction-ஐ allow, adapt, challenge, review, அல்லது limit செய்கிறது, எதையும் enforce செய்வதற்கு முன் outcomes-ஐ சரிபார்க்க observation mode-இல் தொடங்கி.
உங்கள் app-இல் decisions எவ்வாறு பொருந்துகின்றன என்பதை மேலும் அறியவும், APIs மற்றும் MCP servers use case-களைப் பார்க்கவும், அல்லது early access-க்கு apply செய்யவும்.
Sources
- RFC 6749: The OAuth 2.0 Authorization Framework: clients-க்கான scoped tokens
- MCP specification 2026-07-28: Authorization: MCP servers-க்கான OAuth-based authorization
- RFC 9421: HTTP Message Signatures: signed request என்ன நிறுவுகிறது