MCP ఒక స్థిరమైన “Enterprise-Managed Authorization” స్పెసిఫికేషన్ను విడుదల చేసింది; OAuth client-credentials డ్రాఫ్ట్ మరియు రెండు ఓపెన్ ప్రతిపాదనలతో సహా మిగిలిన machine-to-machine identity డ్రాఫ్ట్లు ఇంకా పూర్తి కాలేదు. Model Context Protocolతో స్వయంప్రతిపత్తి కలిగిన ఏజెంట్లను (autonomous agents) నడపాలని ప్రయత్నించే ఎవరికైనా, ప్రస్తుత ప్రోటోకాల్ ఒక మానవ వినియోగదారుని ధృవీకరించగలదు కానీ, ఒక unattended process అది అని చెప్పుకుంటున్న వ్యక్తి/వస్తువు అని నిరూపించడానికి సిద్ధంగా ఉన్న మార్గం లేదు.
రోడ్మ్యాప్ ఎందుకు ముఖ్యమో
Model Context Protocol (MCP) రోడ్మ్యాప్లో ఏజెంట్ ఐడెంటిటీ మరియు సెక్యూరిటీని అత్యంత ప్రాధాన్యత కలిగిన అంశాలుగా పేర్కొన్నారు. విడుదల కోసం నాలుగు అంశాలను నిర్ణయించారు: human-centric browser flow, సర్వీసుల కోసం OAuth client-credentials flow, DPoP-ఆధారిత token binding, మరియు workload-identity federation mechanism. వీటిలో మొదటిది—Enterprise-Managed Authorization—మాత్రమే స్థిరమైన (stable) స్థితికి చేరుకుంది.
ఈ స్థిరమైన స్పెసిఫికేషన్ వాస్తవానికి ఏం చేస్తుంది
Enterprise-Managed Authorization ద్వారా IT అడ్మిన్లు ప్రతి ఉద్యోగి ప్రతి కనెక్షన్ను ఆమోదించాల్సిన అవసరం లేకుండా, ఒకే కన్సోల్ నుండి సర్వర్ యాక్సెస్ను అనుమతించవచ్చు. ఈ ఫ్లో బ్రౌజర్ రీడైరెక్ట్ మరియు యూజర్ లాగిన్ను ఉపయోగిస్తుంది, తద్వారా లాప్టాప్ వద్ద ఉన్న వ్యక్తి అథెంటికేట్ చేయవచ్చు మరియు ఆ తర్వాత సర్వర్ ఆ యూజర్ సెషన్ను నమ్ముతుంది.
దీని పరిమితి స్పష్టంగా ఉంది: ఈ ప్రక్రియకు కీబోర్డ్ వద్ద ఒక మనిషి ఉండాలి. రాత్రంతా నడిచే, డేటాను ప్రాసెస్ చేసే లేదా అలర్ట్లకు స్పందించే ఏజెంట్కు లాగిన్ బటన్ను క్లిక్ చేయడానికి ఎవరూ ఉండరు. పర్యవసానంగా, unattended agents పై ఆధారపడే ఏ డిప్లాయ్మెంట్ అయినా, ప్రస్తుతం MCP హామీ ఇస్తున్న ఏకైక స్పెసిఫికేషన్ను ఉపయోగించలేదు.
డ్రాఫ్ట్ ఆప్షన్లు మరియు వాటి లోపాలు
ఏజెంట్లకు వాటి స్వంత ఐడెంటిటీని అందించడానికి రెండు డ్రాఫ్ట్ ఎక్స్టెన్షన్లు లక్ష్యంగా పెట్టుకున్నాయి:
- SEP-1932 (DPoP) – టోకెన్లను public-private key pairతో అనుసంధానిస్తుంది, దీనివల్ల దొంగిలించబడిన టోకెన్లు పనికిరాకుండా పోతాయి.
- SEP-1933 (Workload Identity Federation) – క్లౌడ్ ప్లాట్ఫారమ్లలో ఇప్పటికే ఉన్న ఐడెంటిటీలను ఏజెంట్లు పొందేలా చేస్తుంది.
ఇవి రెండూ ఓపెన్ pull requests రూపంలో ఉన్నాయి; వీటిలో ఏదీ అధికారిక స్పెసిఫికేషన్లో ఇంకా విలీనం (merge) కాలేదు. ఈలోగా, డాక్యుమెంట్ చేయబడిన మరో ఏకైక ఆప్షన్ ముందే రిజిస్టర్ చేయబడిన secrets అవసరమయ్యే OAuth client-credentials flow. ఏజెంట్ చదవగలిగే చోట ఆ secrets ని నిల్వ చేయడం వల్ల ఒక క్లాసిక్ అటాక్ సర్ఫేస్ ఏర్పడుతుంది: ఒకవేళ ఆ సీక్రెట్ లీక్ అయితే, ఏ అటాకర్ అయినా ఏజెంట్లా నటించగలరు (impersonate).
నేటి ప్రొడక్షన్ కోసం ఆచరణాత్మక దశలు
ప్రోటోకాల్ ఇంకా నేటివ్ ఏజెంట్ ఐడెంటిటీని అందించనందున, టీమ్లు ఐడెంటిటీ మేనేజ్మెంట్ను MCP వెలుపల ఉంచడం ద్వారా ఏజెంట్లను సురక్షితంగా ఉంచుకోవచ్చు:
- Workload layer వద్ద ధృవీకరించదగిన ఐడెంటిటీలను జారీ చేయండి. SPIRE వంటి సిస్టమ్లు హోస్ట్ యొక్క trust rootకి అనుసంధానించబడిన స్వల్పకాలిక సర్టిఫికేట్లను రూపొందిస్తాయి, తద్వారా static secrets అవసరం ఉండదు.
- Gateway వద్ద క్రెడెన్షియల్స్ను ముగించండి (Terminate). ఒక ఫ్రంట్-ఎండ్ సర్వీస్ API కీ లేదా టోకెన్ను కలిగి ఉండి, ఏజెంట్ తరపున రిక్వెస్ట్లను ఫార్వార్డ్ చేస్తుంది, తద్వారా సీక్రెట్ రన్టైమ్ ఎన్విరాన్మెంట్ వెలుపల ఉంటుంది.
- టోకెన్ కంటెంట్ ఆధారంగా కాకుండా, ధృవీకరించబడిన ఐడెంటిటీ ఆధారంగా అథరైజ్ చేయండి. అథెంటికేషన్ (ఎవరు పిలుస్తున్నారు) మరియు అథరైజేషన్ (వారు ఏమి చేయవచ్చు)లను వేరు చేయండి, తద్వారా అథెంటికేషన్ పద్ధతి మారినప్పటికీ పాలసీని అమలు చేయవచ్చు.
తదుపరి ఏం గమనించాలి
DPoP binding మరియు workload-identity federation అనే రెండు ఓపెన్ pull requests మాత్రమే MCPలో నిజమైన machine-to-machine identity స్టాండర్డ్కు ఏకైక మార్గాలు. కమ్యూనిటీ వీటిని విలీనం చేస్తే, ఏజెంట్లు సీక్రెట్లను బహిర్గతం చేయకుండానే ప్రైవేట్ కీని కలిగి ఉన్నట్లు లేదా క్లౌడ్ ద్వారా జారీ చేయబడిన ఐడెంటిటీలను పొందినట్లు నిరూపించగలవు. అప్పటి వరకు, ఏ ప్రొడక్షన్ డిప్లాయ్మెంట్ అయినా బాహ్య ఐడెంటిటీ ఫ్రేమ్వర్క్లపై ఆధారపడాలి లేదా static credentials యొక్క రిస్క్ను అంగీకరించాలి.
దీని సారాంశం స్పష్టంగా ఉంది: MCP ప్రస్తుతం ఒక రిక్వెస్ట్ వెనుక ఉన్న వ్యక్తిని అథెంటికేట్ చేయగలదు, కానీ రిక్వెస్ట్ చేసే సాఫ్ట్వేర్ను ఇంకా అథెంటికేట్ చేయలేదు. సురక్షితమైన స్వయంప్రతిపత్తి కలిగిన ఏజెంట్లు కావాలనుకునే టీమ్లు స్పెసిఫికేషన్ కోసం వేచి చూడకూడదు; వారు ఈరోజే workload layer వద్ద ఐడెంటిటీని నిర్మించాలి మరియు పెండింగ్లో ఉన్న DPoP మరియు federation ప్రతిపాదనలను గమనిస్తూ ఉండాలి.
