సోమవారం ఉదయం 9:12కి, ఒక కల్పిత రిటైలర్ వద్ద కస్టమర్లు ఆర్డర్లు విఫలమవుతున్నాయని ఫిర్యాదు చేయడం మొదలుపెడతారు.
ప్లాట్ఫారమ్ టీమ్కు సపోర్ట్ క్యూ మరియు క్లౌడ్ వాతావరణానికి అనుసంధానించబడిన ఒక AI ఆపరేషన్స్ ఏజెంట్ ఉంది. ఒక ఇంజనీర్ దానికి ఒక చిన్న సూచన ఇస్తాడు:
చెకౌట్ ఎందుకు విఫలమవుతుందో కనుక్కొని సమస్యను పరిష్కరించండి.
ఏజెంట్ ఇన్సిడెంట్ టికెట్ను చదివి, అప్లికేషన్ లాగ్లను వెతికి, ఇటీవలి డిప్లాయ్మెంట్లను పోల్చి, పేమెంట్ సర్వీస్ ఆరోగ్యాన్ని తనిఖీ చేస్తుంది. అది గడువు ముగిసిన సర్టిఫికేట్ను కనుగొని, దానికి బదులుగా కొత్తదాన్ని జనరేట్ చేసి, కాన్ఫిగరేషన్ను అప్డేట్ చేసి, మార్పును డిప్లాయ్ చేస్తుంది.
చెకౌట్ పన్నెండు నిమిషాల్లో కోలుకుంటుంది. టీమ్ ఆశ్చర్యపోతుంది.
అప్పుడు సెక్యూరిటీ లీడ్ ఇలా అడుగుతారు:
- ప్రొడక్షన్ను ఏ గుర్తింపు మార్చింది?
- ఏజెంట్కు పరిశోధించే అనుమతి మాత్రమే ఉందా, లేక డిప్లాయ్ చేసే అనుమతి కూడా ఉందా?
- అది ఎవరి అధికారాన్ని ఉపయోగించింది?
- తప్పు సర్టిఫికేట్ను మార్చి ఉంటే, ఏం జరిగిందో టీమ్ నిరూపించగలదా?
ఆడిట్ లాగ్లో ఒకే ఒక సమాధానం ఉంది: platform-automation-service.
ఆ అకౌంట్ను డిప్లాయ్మెంట్ పైప్లైన్లు, మెయింటెనెన్స్ స్క్రిప్ట్లు మరియు రెండు పాత ఆటోమేషన్ టూల్స్ కూడా ఉపయోగిస్తాయి. దాని క్రెడెన్షియల్ ఒక ఆమోదించబడిన అకౌంట్ ఈ కాల్ చేసిందని రుజువు చేస్తుంది. ఏ సిస్టమ్ ఆ చర్యను ఎంచుకుంది, ఎవరు ఈ పనిని ప్రారంభించారు, ఏ ఫలితం ఆమోదించబడింది, లేదా ఆ అధికారం ఎప్పుడు ముగిసి ఉండాలో అది వెల్లడించదు.
ఏజెంట్ అంతరాయాన్ని పరిష్కరించింది. అది ఒక పాత ఆర్కిటెక్చరల్ బలహీనతను కూడా బయటపెట్టింది: ఒక క్రెడెన్షియల్ గుర్తింపు, అధికారం మరియు జవాబుదారీతనానికి ప్రత్యామ్నాయంగా మారింది.
ఏజెంట్లు సెక్యూరిటీ ప్రశ్నను మారుస్తాయి
అప్లికేషన్లకు ఎప్పుడూ క్రెడెన్షియల్స్ అవసరం. ఒక సర్వీస్ మరో సర్వీస్ను కాల్ చేయడానికి టోకెన్ను ఉపయోగించవచ్చు. ఒక డిప్లాయ్మెంట్ పైప్లైన్ క్లౌడ్ వనరులను అప్డేట్ చేయడానికి సర్వీస్ అకౌంట్ను ఉపయోగించవచ్చు. ఒక షెడ్యూల్డ్ జాబ్ డేటాబేస్ నుండి చదవడానికి సర్టిఫికేట్ను ఉపయోగించవచ్చు.
ఈ పద్ధతులు అసురక్షితం కాదు. ఒకే దీర్ఘకాలిక క్రెడెన్షియల్ అనేక వ్యక్తులు మరియు ప్రయోజనాలకు ప్రత్యామ్నాయంగా మారినప్పుడు సమస్య మొదలవుతుంది.
సంప్రదాయ ఆటోమేషన్ సాధారణంగా పరిమితంగా ఉంటుంది. ఒక పైప్లైన్ ముందుగా రాసిన కోడ్ను అనుసరిస్తుంది. ఒక బ్యాకప్ జాబ్ తెలిసిన క్రమాన్ని రన్ చేస్తుంది. ఒక AI ఏజెంట్ తక్కువ ఊహించదగినది: అది ఒక లక్ష్యాన్ని అందుకుని, తన వాతావరణాన్ని పరిశీలించి, టూల్స్ను ఎంచుకుని, తాను కనుగొన్నదాని ప్రకారం తన తదుపరి అడుగును మారుస్తుంది.
మోడల్ డిటర్మినిస్టిక్గా ఉండకపోవచ్చు, కానీ దాని టూల్ కాల్స్కు నిజమైన పరిణామాలు ఉంటాయి.
ఒక సంప్రదాయ స్క్రిప్ట్ కోసం, మనం తరచుగా ఇలా అడుగుతాం:
ఈ ప్రాసెస్ APIని కాల్ చేయగలదా?
ఒక ఏజెంట్ కోసం, అది మొదటి ప్రశ్న మాత్రమే. మనం ఇలా కూడా అడగాలి:
ఇది APIని ఎందుకు కాల్ చేస్తోంది, ఏ అధికారాన్ని ఉపయోగిస్తోంది, మరియు ఈ చర్య ఆమోదించబడిన పనిలోనే ఇంకా ఉందా?
ఒక API కీ ఆ ప్రశ్నలకు తనంతట తానుగా సమాధానం చెప్పలేదు.
క్రెడెన్షియల్ మనం అనుకున్నదానికన్నా తక్కువే రుజువు చేస్తుంది
ప్రామాణీకరణ సమయంలో ఉపయోగించే ఆధారం క్రెడెన్షియల్. ఒక అభ్యర్థన ఎవరు చేస్తున్నారో రుజువు చేయడంలో అది సర్వీస్కు సహాయపడవచ్చు. కానీ ఆ అభ్యర్థనను ఎందుకు అనుమతించారో అది స్వయంగా వివరించదు.
ఐదు ఆలోచనలు వేర్వేరుగా ఉండాలి:
- గుర్తింపు (Identity): అభ్యర్థన చేస్తున్నది ఏ వ్యక్తి లేదా వ్యవస్థ.
- ప్రమాణీకరణ (Authentication): ఆ క్లెయిమ్ను సిస్టమ్ ఎలా ధృవీకరిస్తుంది.
- అనుమతి (Authorization): ధృవీకరించబడిన వ్యక్తి లేదా వ్యవస్థ ఏమి చేయవచ్చు.
- అప్పగింత (Delegation): ఒక వ్యక్తి లేదా వ్యవస్థ మరొకరి తరపున, నిర్దిష్ట ప్రయోజనం మరియు కాలానికి ఏమి చేయడానికి అనుమతించబడింది.
- జవాబుదారీతనం (Accountability): అభ్యర్థన, నిర్ణయం, పాలసీ, చర్య మరియు ఫలితాన్ని సంస్థ తిరిగి నిర్మించగలదా.
చెల్లుబాటు అయ్యే టోకెన్ ఒక అభ్యర్థన ప్రామాణీకరించబడిన వ్యక్తి నుండి వచ్చిందని రుజువు చేయగలదు. అది వినియోగదారుడి ప్రస్తుత ఉద్దేశానికి ఆ అభ్యర్థన సరిపోతుందని రుజువు చేయదు. ఒక ఇంజనీర్కు డిప్లాయ్ చేసే అనుమతి ఉండవచ్చు, కానీ ఆ ఇంజనీర్ ఇన్వోక్ చేసే ప్రతి ఏజెంట్కు అదే శక్తి వారసత్వంగా రావాలని దాని అర్థం కాదు.
అందుకే “ఏజెంట్ ప్రామాణీకరించబడింది” అనేది పూర్తి సెక్యూరిటీ నిర్ధారణ కాదు.
ఒక చర్యలో నాలుగు గుర్తింపులు ఉండవచ్చు
చెకౌట్ ఇన్సిడెంట్లో, ఒక క్లౌడ్ API కాల్లో కనీసం నాలుగు గుర్తింపులు పాలుపంచుకోవచ్చు.
| గుర్తింపు | అది దేనిని సూచిస్తుంది | అది ఏ ప్రశ్నకు సమాధానం ఇస్తుంది |
|---|---|---|
| మానవుడు | పనిని అభ్యర్థించిన లేదా ఆమోదించిన ఇంజనీర్ | ఈ పనిని ఎవరు అడిగారు? |
| ఏజెంట్ | తదుపరి చర్యను ఎంచుకునే సాఫ్ట్వేర్ | ఏ స్వయంచాలక వ్యవస్థ దీన్ని ఎంచుకుంది? |
| వర్క్లోడ్ | కాల్ చేస్తున్న ప్రాసెస్, కంటైనర్ లేదా పాడ్ | ఏ డిప్లాయ్ చేయబడిన రన్టైమ్ దీన్ని పంపింది? |
| టార్గెట్ | కాల్ను స్వీకరించే సర్వీస్ లేదా వనరు | దీన్ని ఏ సిస్టమ్ అమలు చేసింది? |
ఈ గుర్తింపులు అతివ్యాప్తి చెందవచ్చు. స్థిర ప్రవర్తన కలిగిన చిన్న అంతర్గత ఏజెంట్ ఇప్పటికే ఉన్న వర్క్లోడ్ గుర్తింపును సహేతుకంగా ఉపయోగించవచ్చు. కానీ ఏజెంట్లు డైనమిక్గా సృష్టించబడినప్పుడు, వేర్వేరు వినియోగదారుల తరపున పనిచేసినప్పుడు, అనేక టూల్స్ను కాల్ చేసినప్పుడు లేదా ఒకే పని కోసం మాత్రమే ఉన్నప్పుడు మోడల్ను నియంత్రించడం కష్టమవుతుంది.
ఒక పైప్లైన్ మరియు ఒక ఆపరేషన్స్ ఏజెంట్ ఒకే ప్రిన్సిపల్ను ఉపయోగిస్తే, ముందుగా నిర్ణయించిన ఆటోమేషన్ను మోడల్-నిర్దేశిత నిర్ణయం నుండి ఆడిట్ ట్రయిల్ నమ్మదగినంతగా వేరు చేయలేదు. ఇరవై ఏజెంట్లు ఒకే కీని పంచుకుంటే, రాజీపడిన ఒక ఏజెంట్ను డిజేబుల్ చేయడం ఇరవైంటినీ దెబ్బతీయవచ్చు. ఒక ఏజెంట్ ఒక వ్యక్తి టోకెన్ను ఉపయోగిస్తే, దాని పరిధి ఆ వ్యక్తి పూర్తి యాక్సెస్కు నిశ్శబ్దంగా విస్తరించవచ్చు.
ఏజెంట్కు కేవలం ఒక పేరు ఇవ్వడానికి గుర్తింపును సృష్టించడం ముఖ్యం కాదు. దాని యాక్సెస్ను వేరు చేయగలిగేలా, నియంత్రించగలిగేలా మరియు ట్రేస్ చేయగలిగేలా చేయడమే ముఖ్యం.
క్లౌడ్ మార్కెట్ అదే దిశలో కదులుతోంది
గత సంవత్సరంలో, అనేక ప్లాట్ఫారమ్లు ఏజెంట్లను ఒక షేర్డ్ సీక్రెట్ యొక్క అనామక వినియోగదారులుగా కాకుండా కనిపించే యాక్టర్లుగా పరిగణించే నియంత్రణలను ప్రవేశపెట్టాయి.
మైక్రోసాఫ్ట్ యొక్క Entra Agent ID ఏజెంట్ గుర్తింపులను మానవ మరియు సంప్రదాయ అప్లికేషన్ గుర్తింపుల నుండి వేరు చేస్తుంది. ఇది ఏజెంట్కు నేరుగా కేటాయించిన యాక్సెస్ను మరియు వినియోగదారు అప్పగించిన అధికారాన్ని సపోర్ట్ చేస్తుంది, సపోర్టెడ్ ప్రామాణీకరణను ఏజెంట్ యాక్టివిటీగా రికార్డ్ చేస్తూ.
గూగుల్ క్లౌడ్ SPIFFE-ఆధారిత Agent Identityను ఏజెంట్-అవేర్ IAM పాలసీలు మరియు గేట్వే ఎన్ఫోర్స్మెంట్తో ప్రకటించింది. 6 మే 2026 నాటికి, కోర్ రన్టైమ్ గుర్తింపు మరియు IAM Allow మరియు Deny సపోర్ట్ సాధారణంగా అందుబాటులోకి వచ్చాయి; సంబంధిత గేట్వే మరియు కాంటెక్స్చువల్ నియంత్రణలు కొన్ని ఇంకా ప్రివ్యూలో ఉన్నాయి లేదా ప్లాన్ చేయబడ్డాయి.
AWS వేరే మార్గాన్ని తీసుకుంది. Amazon Bedrock AgentCore అక్టోబర్ 2025లో సాధారణంగా అందుబాటులోకి వచ్చింది. AgentCore Policy మార్చి 2026లో సాధారణ లభ్యతను చేరుకుంది మరియు ఏజెంట్ యొక్క రీజనింగ్ లూప్ వెలుపల గేట్వే టూల్ కాల్స్ను మూల్యాంకనం చేస్తుంది. మేనేజ్డ్ AWS MCP సర్వర్ కూడా IAM నియంత్రణలను ఉపయోగిస్తుంది మరియు సర్వర్ యాక్టివిటీలోకి ప్రత్యేక విజిబిలిటీని అందిస్తుంది.
ఈ సర్వీసులు వేర్వేరుగా ఉన్నాయి, మరియు వాటి ఫీచర్ స్టేటస్లు మారతాయి. వాటి పంచుకున్న దిశ వాటి ప్రొడక్ట్ పేర్ల కన్నా ముఖ్యమైనది:
ఏజెంట్కు గుర్తించదగిన గుర్తింపును ఇవ్వండి, దాని అధికారాన్ని పరిమితం చేయండి, మరియు ప్రతిపాదిత చర్య నిజమైన ఆపరేషన్గా మారడానికి ముందు పాలసీని అమలు చేయండి.
ఈ సర్వీసులు ఉపయోగకరమైన బిల్డింగ్ బ్లాక్లు. నిర్దిష్ట పని కోసం ఏజెంట్ను ఏమి చేయడానికి అనుమతించాలో డిజైన్ చేయాల్సిన అవసరాన్ని ఏదీ తొలగించదు.
కష్టతరమైన సమస్య అధికార చలనం (authority drift)
ఇన్సిడెంట్కు తిరిగి వెళ్దాం. చెకౌట్ వైఫల్యాలను పరిశోధించమని ఇంజనీర్ ఏజెంట్ను అడుగుతాడు. ఏజెంట్ లాగ్లను చదివి గడువు ముగిసిన సర్టిఫికేట్ను కనుగొంటుంది.
అప్పుడు అది ఒక సర్టిఫికేట్ టూల్ను కాల్ చేస్తుంది. ఆ టూల్ ఒక డిప్లాయ్మెంట్ సర్వీస్ను కాల్ చేస్తుంది. డిప్లాయ్మెంట్ సర్వీస్ రోలౌట్ను వేరే ఏజెంట్ను ధృవీకరించమని అడుగుతుంది. ప్రతి భాగానికి చెల్లుబాటు అయ్యే గుర్తింపు ఉండవచ్చు, మరియు ప్రతి కాల్ను విస్తృత యాక్సెస్ పాలసీ అనుమతించవచ్చు.
కానీ “పరిశోధించు” అనే దానిలో “ప్రొడక్షన్ సర్టిఫికేట్ను మార్చి దాన్ని డిప్లాయ్ చేయడం” కూడా ఉంటుందని నిర్ణయం ఎక్కడ తీసుకోబడింది?
పని టూల్స్, ఏజెంట్లు మరియు సర్వీసుల గుండా కదులుతున్నప్పుడు అధికారం చలించవచ్చు (drift). అసలు అభ్యర్థనకు, తుది పర్యవసానానికి మధ్య సంబంధం బలహీనపడుతున్నప్పటికీ ప్రామాణీకరణ చెల్లుబాటులోనే ఉంటుంది.
ఇది యాక్సెస్ అనుమతి (access authorization) మరియు చర్య అనుమతి (action authorization) మధ్య వ్యత్యాసాన్ని బయటపెడుతుంది.
యాక్సెస్ అనుమతి ఇలా అడుగుతుంది:
ఈ ఏజెంట్ డిప్లాయ్మెంట్ APIని కాల్ చేయగలదా?
చర్య అనుమతి ఇలా అడుగుతుంది:
ఈ ఏజెంట్ ఈ డిప్లాయ్మెంట్ను, ఈ వనరుపై, ఈ పని కోసం, ఇప్పటికీ చెల్లుబాటు అయ్యే అధికారాన్ని ఉపయోగించి చేయగలదా?
ఒక ప్రత్యేక ఏజెంట్ గుర్తింపు విజిబిలిటీని మెరుగుపరుస్తుంది మరియు పాలసీని అమలు చేయడం సులభతరం చేస్తుంది. అది ఒక్కటే ఈ అంతరాన్ని మూసివేయదు.
ఇది ఇంకా అభివృద్ధి చెందుతున్న రంగం. NIST ఫిబ్రవరి 2026లో తన AI Agent Standards Initiativeను ప్రారంభించింది మరియు ఏజెంట్ ప్రామాణీకరణ మరియు గుర్తింపు మౌలిక సదుపాయాలపై పరిశోధన చేస్తోంది. దాని నేషనల్ సైబర్సెక్యూరిటీ సెంటర్ ఆఫ్ ఎక్సలెన్స్ ప్రత్యేకంగా సాఫ్ట్వేర్ మరియు AI ఏజెంట్లు తీసుకునే యాక్సెస్ మరియు చర్యల కోసం స్టాండర్డ్స్-ఆధారిత గుర్తింపు మరియు అనుమతిను అన్వేషిస్తోంది. ఈ సమీక్ష నాటికి, ఆ పని ఇంకా పురోగతిలో ఉంది తప్ప స్థిరపడిన ఆర్కిటెక్చర్ ప్రమాణం కాదు.
పర్యవసానానికి ముందు వెంటనే పాలసీని ఉంచండి
“ప్రమాదకరమైన మార్పును అనుమతి లేకుండా ఎప్పుడూ చేయవద్దు” వంటి ప్రాంప్ట్ మోడల్ ప్రవర్తనను ప్రభావితం చేయవచ్చు. అది అనుమతి నియంత్రణ కాదు. మోడల్ ప్రాంప్ట్లను వ్యాఖ్యానిస్తుంది; అనుమతులను ఒక ప్రత్యేక వ్యవస్థ అమలు చేయాలి.
బలమైన నియంత్రణ పాయింట్ సాధారణంగా ఒక ముఖ్యమైన టూల్ లేదా API అమలయ్యే ముందు ఉన్న సరిహద్దు.
సురక్షితమైన ఫ్లోకు నాలుగు గేట్లు ఉన్నాయి:
- అభ్యర్థనను గుర్తించండి. వ్యక్తి, ఏజెంట్, రన్నింగ్ వర్క్లోడ్, పని, సమయం మరియు ఉద్దేశించిన ఫలితాన్ని రికార్డ్ చేయండి.
- అప్పగింతను పరిమితం చేయండి. ఆ పని కోసం అవసరమైన వనరులు, చర్యలు మరియు వ్యవధిని మాత్రమే ఏజెంట్కు ఇవ్వండి.
- మోడల్ వెలుపల నిర్ణయించండి. ప్రతిపాదిత టార్గెట్, చర్య, వాతావరణం, రిస్క్ మరియు ఆమోద నియమాలను ఒక బాహ్య పాలసీ సర్వీస్లో మూల్యాంకనం చేయండి.
- అమలు చేసి రుజువు చేయండి. ఆమోదించిన ఆపరేషన్ కోసం స్వల్పకాలిక క్రెడెన్షియల్ను జారీ చేయండి, అమలు సమయంలో మళ్లీ పాలసీని అమలు చేయండి, మరియు ఫలితాన్ని రికార్డ్ చేయండి.
ముఖ్యమైన సరిహద్దు ప్రతిపాదన మరియు అమలు మధ్య ఉంటుంది:
మోడల్ ప్రతిపాదించగలదు. అది తన సొంత ప్రతిపాదనను ఆమోదించలేకపోవాలి, తన సొంత అధికారాన్ని ముద్రించలేకపోవాలి లేదా ఎన్ఫోర్స్మెంట్ పాయింట్ను దాటవేయలేకపోవాలి.
మానవ ఆమోదం అర్థవంతంగా ఉండాలి
ఆమోద బటన్ను జోడించడం తప్పుడు నమ్మకాన్ని సృష్టించగలదు. ప్రాంప్ట్లు తరచుగా, అస్పష్టంగా లేదా అర్థం చేసుకోవడం కష్టంగా ఉన్నప్పుడు వ్యక్తులు చాలా త్వరగా ఆమోదిస్తారు.
“ఏజెంట్ను కొనసాగనివ్వండి” అనేది సమాచారంతో కూడిన నిర్ణయం కాదు. ఉపయోగకరమైన ఆమోదం అసలు పర్యవసానాన్ని చూపిస్తుంది:
ప్రొడక్షన్లో
payment-internalసర్టిఫికేట్ను మార్చండి,checkout-1842రివిజన్ను డిప్లాయ్ చేయండి, పది నిమిషాలు పర్యవేక్షించండి మరియు పేమెంట్ ఎర్రర్లు అంగీకరించిన థ్రెషోల్డ్ను దాటితే రోల్బ్యాక్ చేయండి.
ఆమోదం రిస్క్-ఆధారితంగా కూడా ఉండాలి. ఒక ఆపరేషన్స్ ఏజెంట్ అంతరాయం లేకుండా హెల్త్ మెట్రిక్లను చదవవచ్చు. ఆమోదించిన రన్బుక్ కింద అది విఫలమైన డెవలప్మెంట్ వర్క్లోడ్ను రీస్టార్ట్ చేయవచ్చు. ప్రొడక్షన్ సర్టిఫికేట్ మార్పు, డేటాబేస్ పర్మిషన్ అప్డేట్ లేదా డిలీషన్ బలమైన సరిహద్దును దాటాలి.
వినియోగదారు అభ్యర్థించినప్పటికీ కొన్ని చర్యలు నిషేధించబడాలి. ఒక ఏజెంట్ తనకు తానుగా పర్మిషన్లను ఇచ్చుకోవడం, తన ఆడిట్ ట్రయిల్ను డిజేబుల్ చేయడం లేదా తన సొంత చర్యలను మూల్యాంకనం చేసే పాలసీని తిరిగి రాయడం చేయలేకపోవాలి.
సిస్టమ్ ప్రశ్నను ఒక నిర్దిష్టమైన, అర్థమయ్యే నిర్ణయానికి తగ్గించిన తర్వాతే మానవ ప్రమేయం అత్యంత ఉపయోగకరంగా ఉంటుంది.
వర్క్లోడ్కు ఇప్పటికీ బలమైన క్రెడెన్షియల్ అవసరం
ఏజెంట్ గుర్తింపు వర్క్లోడ్ గుర్తింపును భర్తీ చేయదు. ఏజెంట్ ఇప్పటికీ ఒక ప్రాసెస్, కంటైనర్ లేదా పాడ్గా రన్ అవుతుంది, మరియు ఆ రన్టైమ్కు ప్రామాణీకరించడానికి ఒక సురక్షితమైన మార్గం అవసరం.
బేరర్ టోకెన్లు టికెట్ల మాదిరిగా పనిచేస్తాయి: చెల్లుబాటు అయ్యే కాపీని కలిగి ఉన్న ఎవరైనా దాన్ని సమర్పించవచ్చు. Kubernetes వెర్షన్ 1.35లో బీటాలో ప్రవేశపెట్టి వెర్షన్ 1.37లో సాధారణ లభ్యతకు చేరుకున్న Pod Certificates ద్వారా ఈ లేయర్ను బలపరుస్తోంది. ప్రతి పీర్కు పూర్తి బేరర్ క్రెడెన్షియల్ను పంపడం కంటే, అవి స్వాధీనత రుజువు మరియు ప్లాట్ఫారమ్-నిర్వహణ రొటేషన్ను సపోర్ట్ చేస్తాయి.
ఇది సార్వత్రిక సమాధానం కాదు. అప్లికేషన్లు రొటేట్ చేయబడిన మెటీరియల్ను ఉపయోగించాలి, మరియు సంస్థలకు ఇప్పటికీ సర్టిఫికేట్ సైనర్ మరియు జాగ్రత్తగా డిజైన్ చేసిన ట్రస్ట్ మోడల్ అవసరం. వ్యవస్థల అంతటా కాపీ చేయబడిన స్టాటిక్ సీక్రెట్ల కంటే స్వల్పకాలిక, వర్క్లోడ్-నిర్దిష్ట క్రెడెన్షియల్స్కు ప్రాధాన్యత ఇవ్వడమే శాశ్వత సూత్రం.
ఏజెంట్ యొక్క లాజికల్ గుర్తింపు మరియు దాని రన్టైమ్ గుర్తింపు ఒకే షేర్డ్ అకౌంట్గా కుప్పకూలకుండా ఆడిట్ ట్రయిల్లో అనుసంధానించబడి ఉండాలి.
ఫ్యాషన్గా ఉన్న సమస్యను మొదట పరిష్కరించవద్దు
ఏజెంట్ అథరైజేషన్ ప్రాథమిక సెక్యూరిటీ నుండి దృష్టి మరల్చకూడదు. Mandiant యొక్క 2025 దర్యాప్తుల ఆధారంగా రూపొందించిన M-Trends 2026 నివేదిక, ఎక్స్ప్లాయిట్లు 32 శాతంతో అత్యంత సాధారణ ప్రారంభ ఇన్ఫెక్షన్ వెక్టర్గా ఉన్నాయని చెబుతుంది. దాడిచేసేవారు తమ పనిలో కొంత భాగాన్ని వేగవంతం చేయడానికి AIని ఉపయోగిస్తున్నప్పటికీ, విజయవంతమైన చొరబాట్లలో అత్యధిక భాగం ఇప్పటికీ ప్రాథమిక మానవ మరియు సిస్టమాటిక్ వైఫల్యాల నుండే వచ్చాయని కూడా ఇది చెబుతుంది.
ఇంటర్నెట్కు తెరిచి ఉన్న సిస్టమ్లను అన్ప్యాచ్డ్గా వదిలేసి లేదా రిపోజిటరీలలో దీర్ఘకాలిక సీక్రెట్లను ఉంచుతూ అధునాతన ఏజెంట్ గుర్తింపులను సృష్టించే సంస్థ అత్యవసరమైన సమస్యకు ముందు కొత్త సమస్యను పరిష్కరించినట్టే. ప్యాచింగ్, హార్డెనింగ్, మానిటరింగ్ మరియు రికవరీ టెస్టింగ్ను కొనసాగించండి—మరియు చర్యలను వేరు చేయడం లేదా నియంత్రించడం అసాధ్యం చేసే గుర్తింపుల ద్వారా స్వయంచాలక యాక్సెస్ను జోడించవద్దు.
సంఘటనను పరిమిత అధికారం చుట్టూ పునర్నిర్మించండి
ఇప్పుడు సోమవారం ఉదయాన్ని మళ్లీ ప్లే చేద్దాం.
చెకౌట్ వైఫల్యాలను పరిశోధించమని ఇంజనీర్ ఆపరేషన్స్ ఏజెంట్ను అడుగుతాడు. ప్లాట్ఫారమ్ ఆ పనిని రికార్డ్ చేసి చెకౌట్ లాగ్లు, మెట్రిక్లు మరియు డిప్లాయ్మెంట్ డేటాకు స్వల్పకాలిక, రీడ్-ఓన్లీ యాక్సెస్ను మంజూరు చేస్తుంది.
ఏజెంట్ గడువు ముగిసిన సర్టిఫికేట్ను కనుగొంటుంది. దాని పరిశోధన అధికారం ప్రొడక్షన్ను మార్చలేనందున, అది టార్గెట్, డిప్లాయ్మెంట్, వాలిడేషన్ చెక్లు మరియు రోల్బ్యాక్ కండిషన్తో ఒక ప్రతిపాదనను సృష్టిస్తుంది.
ఒక బాహ్య పాలసీ సర్వీస్ టార్గెట్, ఆపరేషన్ మరియు ఆమోద అవసరాన్ని తనిఖీ చేస్తుంది. ఇంజనీర్ ఖచ్చితమైన మార్పును ఆమోదిస్తాడు, మరియు ఒక ఎగ్జిక్యూషన్ సర్వీస్ ఆ ఆపరేషన్ మరియు వనరుకు మాత్రమే పరిమితమైన తాత్కాలిక క్రెడెన్షియల్ను పొందుతుంది. అమలుకు ముందు వెంటనే పాలసీని మళ్లీ తనిఖీ చేస్తారు.
తుది రికార్డు ఇంజనీర్, ఏజెంట్, రన్నింగ్ వర్క్లోడ్, పాలసీ వెర్షన్, ఆమోదించిన చర్య, మార్చిన వనరు, వాలిడేషన్ ఫలితం మరియు గడువు సమయాన్ని అనుసంధానిస్తుంది.
ఏజెంట్ ఇప్పటికీ అంతరాయాన్ని త్వరగా పరిష్కరిస్తుంది. తేడా ఏమిటంటే, వేగం ఇక వివరించలేని శక్తి ఉన్న అకౌంట్పై ఆధారపడదు.
ఏజెంట్కు క్లౌడ్ యాక్సెస్ ఇచ్చే ముందు పది ప్రశ్నలు
- ఏజెంట్ను దాని వినియోగదారు, రన్టైమ్ మరియు ఇతర ఆటోమేషన్ నుండి మనం వేరు చేయగలమా?
- ఏజెంట్ గుర్తింపును ఎవరు సొంతం చేసుకుని స్పాన్సర్ చేస్తారు?
- ఏజెంట్ స్వతంత్రంగా వ్యవహరిస్తోందా లేదా అప్పగించిన మానవ అధికారాన్ని ఉపయోగిస్తోందా?
- ఆ అప్పగింత వినియోగదారు పూర్తి యాక్సెస్ కంటే ఇరుకైనదిగా ఉండగలదా?
- క్రెడెన్షియల్స్ స్వల్పకాలికమైనవి, వనరు-పరిధి కలిగినవి మరియు ఆడియెన్స్-బౌండ్గా ఉన్నాయా?
- ఏ చర్యలు రీడ్-ఓన్లీ, ముందుగా-ఆమోదించబడినవి, ఆమోదం-అవసరమైనవి లేదా నిషేధించబడినవి?
- పాలసీ మోడల్ వెలుపల మరియు అమలుకు వెంటనే ముందు అమలు చేయబడుతోందా?
- మరో టూల్ లేదా ఏజెంట్ అదే పాలసీ సరిహద్దును దాటవేయగలదా?
- అభ్యర్థన, నిర్ణయం, చర్య మరియు ఫలితాన్ని ఆడిట్ ట్రయిల్ అనుసంధానించగలదా?
- పని పూర్తయినప్పుడు అధికారాన్ని స్వయంచాలకంగా ఏది ముగిస్తుంది?
సమాధానాలు “ఏజెంట్ మన ఆటోమేషన్ అకౌంట్ను ఉపయోగిస్తుంది” అనే దానికి తగ్గిపోతే, డిజైన్ ఇంకా పూర్తి కాలేదు.
ముందుకు తీసుకెళ్లాల్సిన సూత్రం
AI ఏజెంట్లు ఒక పాత క్లౌడ్-సెక్యూరిటీ బలహీనతను విస్మరించడం కష్టతరం చేస్తున్నాయి. స్వయంచాలక టూల్ ఎంపిక షేర్డ్ క్రెడెన్షియల్స్ మరియు విస్తృత సర్వీస్ అకౌంట్ల లోపల దాగి ఉన్న అధికారాన్ని ఉపయోగించడానికి మరిన్ని మార్గాలను సృష్టిస్తుంది.
ఒక ప్రత్యేక గుర్తింపు కేవలం మొదటి అడుగు మాత్రమే.
పూర్తి సరిహద్దు వ్యక్తిని, ఏజెంట్ను, రన్నింగ్ వర్క్లోడ్ను, అప్పగించిన ప్రయోజనాన్ని, ప్రతిపాదిత చర్యను, పాలసీ నిర్ణయాన్ని మరియు తుది పర్యవసానాన్ని అనుసంధానించాలి.
ఏజెంట్ ఒక పనిని చేయగలదా అని అడగడానికి ముందు, మూడు పదునైన ప్రశ్నలు అడగండి:
ఇది ఎవరి అధికారాన్ని ఉపయోగిస్తోంది? ఆ అధికారం సరిగ్గా ఏమి అనుమతిస్తుంది? ఆ చర్య నిజం కావడానికి ముందు ఆ నిర్ణయం ఎక్కడ అమలు చేయబడుతుంది?
మోడల్ యొక్క ఫ్లూయెన్సీ కాదు—ఆ సమాధానాలే—ఒక ఏజెంట్ ప్రొడక్షన్లో ఉండాలో లేదో నిర్ణయిస్తాయి.
రిఫరెన్సులు మరియు మరింత చదవడానికి
ఈ ప్రాథమిక మూలాలు ఆర్టికల్ వెనుక ఉన్న ప్లాట్ఫారమ్ వివరాలు, స్టాండర్డ్స్ పని మరియు సెక్యూరిటీ ఆధారాలలోకి ఒక మార్గాన్ని అందిస్తాయి. అమలుకు ముందు ప్రొడక్ట్ స్థితులను మళ్లీ తనిఖీ చేయాలి.
- What are agent identities — Microsoft Entra Agent ID — ఏజెంట్ గుర్తింపు, స్వతంత్ర యాక్సెస్, అప్పగించిన యాక్సెస్ మరియు మానవ, అప్లికేషన్ గుర్తింపుల నుండి తేడాను వివరిస్తుంది. చివరిసారిగా 15 జూన్ 2026న అప్డేట్ చేయబడింది.
- What’s new in IAM: Security, governance, and runtime defense — Google Cloud — Agent Identity, ఏజెంట్-అవేర్ IAM పాలసీ, గేట్వే ఎన్ఫోర్స్మెంట్ మరియు సంబంధిత నియంత్రణల మే 2026 లభ్యత స్థితులను జాబితా చేస్తుంది. 6 మే 2026న ప్రచురించబడింది.
- Introducing Amazon Bedrock AgentCore — AWS — AgentCore యొక్క రన్టైమ్, గుర్తింపు మరియు గేట్వే సామర్థ్యాలను పరిచయం చేస్తుంది; 13 అక్టోబర్ 2025న సాధారణ లభ్యత కోసం అప్డేట్ చేయబడింది.
- AgentCore policy controls and evaluations — AWS — ఏజెంట్ రీజనింగ్ లూప్ వెలుపల మరియు గేట్వే టూల్ అమలుకు ముందు పాలసీ అమలును వివరిస్తుంది. 2 డిసెంబర్ 2025న ప్రచురించబడింది; Policy 3 మార్చి 2026న సాధారణ లభ్యతను చేరుకుంది.
- The AWS MCP Server is now generally available — AWS — IAM-ఆధారిత ఏజెంట్ యాక్సెస్, మానవ మరియు సర్వర్ పర్మిషన్ల విభజన, శాండ్బాక్స్డ్ అమలు మరియు ఆడిట్ విజిబిలిటీని కవర్ చేస్తుంది. 6 మే 2026న ప్రచురించబడింది.
- Kubernetes v1.35 release — నేటివ్ కీ జనరేషన్ మరియు ఆటోమేటెడ్ రొటేషన్తో Pod Certificates బీటాలో ఉన్నట్టు ప్రకటిస్తుంది. 17 డిసెంబర్ 2025న ప్రచురించబడింది.
- Kubernetes v1.37: Pod Certificates and Cluster Trust Bundles — బేరర్-టోకెన్ పరిమితులు, ప్రూఫ్-ఆఫ్-పొసెషన్ క్రెడెన్షియల్స్, సాధారణ లభ్యత మరియు అమలు జాగ్రత్తలను వివరిస్తుంది. 28 ఆగస్టు 2026న ప్రచురించబడింది.
- NIST AI Agent Standards Initiative — సురక్షితమైన, ఇంటర్ఆపరబుల్ ఏజెంట్ స్టాండర్డ్స్ మరియు గుర్తింపు మౌలిక సదుపాయాలపై NIST పనిని ట్రాక్ చేస్తుంది. 17 ఫిబ్రవరి 2026న సృష్టించబడింది; 14 ఆగస్టు 2026న అప్డేట్ చేయబడింది.
- Software and AI Agent Identity and Authorization — NIST NCCoE — సాఫ్ట్వేర్ మరియు AI ఏజెంట్లు తీసుకునే యాక్సెస్ మరియు చర్యలను గుర్తించడం మరియు అనుమతించడం కోసం స్టాండర్డ్స్-ఆధారిత విధానాలను అన్వేషిస్తుంది. స్థితి 11 సెప్టెంబర్ 2026న సమీక్షించబడింది.
- M-Trends 2026 — Mandiant — 2025 దర్యాప్తుల నుండి ఎక్స్ప్లాయిటేషన్, దాడిచేసేవారి హ్యాండ్ఆఫ్ వేగం మరియు గమనించిన చొరబాట్లలో AI పాత్ర గురించి ఆధారాలను అందిస్తుంది. 11 సెప్టెంబర్ 2026న సమీక్షించబడింది.