హార్నెస్ ఇంజనీరింగ్ ఫీల్డ్ కిట్ అనేది అటానమస్ AI ఏజెంట్లను ప్రొడక్షన్ ఎన్విరాన్మెంట్లలో సురక్షితంగా డిప్లాయ్ చేయడానికి అవసరమైన ఆర్కిటెక్చర్. ఇది పర్మిషన్ మ్యాట్రిక్స్, కిల్ స్విచ్‌లు మరియు ఆడిట్ లాగ్స్ ద్వారా మోడల్స్ స్వయంగా చేసుకోలేని పనులను నిర్వహిస్తుంది. సరైన నియంత్రణలు లేకపోవడం వల్ల జరిగే డేటాబేస్ తొలగింపుల లాంటి ప్రమాదాలను ఇది ఆపుతుంది.

ఎంటర్‌ప్రైజ్ స్థాయిలో అటానమస్ కోడింగ్ ఏజెంట్లను రన్ చేస్తున్నప్పుడు ఒక పెద్ద సవాలు ఎదురవుతుంది. ఏజెంట్ ఒక చిన్న తప్పు చేసినా లేదా దానికి అవసరానికి మించిన యాక్సెస్ ఉన్నా సిస్టమ్ మొత్తం ప్రమాదంలో పడుతుంది. కేవలం ప్రాంప్ట్స్ ద్వారా మోడల్‌ను నియంత్రించడం సాధ్యం కాదు. ఈ కిట్ ఆ ప్రమాదాలను భౌతికంగా ఎలా అడ్డుకోవాలో వివరిస్తుంది. యాక్సెస్ కంట్రోల్స్ నిర్ణయించే సిస్టమ్స్ ఆర్కిటెక్ట్‌లకు, కోడ్ వెరిఫికేషన్ చేసే టెక్ లీడ్స్‌కు మరియు రెగ్యులేటరీ కంప్లయన్స్ చూసుకునే సెక్యూరిటీ ఇంజనీర్లకు ఇది ఒక స్పష్టమైన మార్గదర్శిగా పనిచేస్తుంది.

ఇది ఎవరి కోసం

• AI మోడల్స్ ఎలా పనిచేస్తాయో తెలుసుకోవాలనుకునే సాధారణ వాడుకరులకు ఈ పుస్తకం కాదు. ఇది కేవలం సాఫ్ట్‌వేర్ ప్రొడక్షన్ ఎన్విరాన్మెంట్లలో ఏజెంట్లను సురక్షితంగా ఉంచే ఇన్‌ఫ్రాస్ట్రక్చర్ గురించి మాత్రమే వివరిస్తుంది.

ఈ కిట్‌లోని ప్రధాన అంశాలు

• యాక్సెస్ కంట్రోల్స్ మరియు పర్మిషన్ల నిర్వహణ – అధ్యాయం 1
• ఏజెంట్ చేసిన పనిని సురక్షితంగా సరిచూడటం – అధ్యాయం 2
• ఒకే పనిని రెండోసారి చేయకుండా ఆపడం – అధ్యాయం 3
• ప్రమాదకరమైన కమాండ్స్‌ను మధ్యలోనే అడ్డుకోవడం – అధ్యాయం 4
• ప్రతి చర్యకు ఎవరు బాధ్యులో రికార్డ్ చేయడం – అధ్యాయం 5

పని 1, ఏజెంట్ ఏమి చేయగలదో హార్నెస్ ఇంజనీరింగ్ ఎలా నిర్ణయిస్తుంది

ఏజెంట్లకు అవసరానికి మించిన యాక్సెస్ ఉన్నప్పుడు ప్రొడక్షన్ సిస్టమ్స్ ప్రమాదంలో పడతాయి. సాధారణ ఐటీ సిస్టమ్స్‌లో వాడే రోల్-బేస్డ్ యాక్సెస్ కంట్రోల్ (RBAC) విధానం ఏజెంట్లకు ఏమాత్రం సరిపోదు. ఒక ఏజెంట్ తన పనులను డైనమిక్‌గా సబ్-ఏజెంట్లకు అప్పగించినప్పుడు, తెలియకుండానే వాటికి అధిక పవర్స్ వస్తాయి. దీనివల్ల మోడల్ తనకు కేటాయించిన పని హద్దులు దాటి ప్రవర్తించే అవకాశం ఉంది.

దీనికి ప్రధాన కారణం క్రెడెన్షియల్స్ నేరుగా ఏజెంట్ శాండ్‌బాక్స్‌లో ఉంచడం. మోడల్‌కు ప్రాంప్ట్ ఇంజెక్షన్ ద్వారా తప్పుడు ఆదేశాలు ఇస్తే, అది ఆ సీక్రెట్ కీలను ఉపయోగించి డేటాను బయటకు పంపే ప్రమాదం ఉంది. దీన్నే OWASP నివేదికలో ఎక్సెసివ్ ఏజెన్సీ (LLM06) అని పిలుస్తారు. కేవలం సిస్టమ్ ప్రాంప్ట్ ద్వారా “నువ్వు ఫైల్స్ డిలీట్ చేయకూడదు” అని చెప్పడం వల్ల ఎలాంటి ప్రయోజనం ఉండదు. ప్రాంప్ట్స్ కేవలం మోడల్ ఆలోచనను ప్రభావితం చేస్తాయి తప్ప భౌతికంగా అడ్డుకోలేవు.

దీనికి సరైన పరిష్కారం ఏజెంట్ పర్మిషన్ మ్యాట్రిక్స్ అమలు చేయడం. ఈ విధానంలో API క్రెడెన్షియల్స్, డేటాబేస్ పాస్‌వర్డ్‌లు ఏజెంట్ యాక్టివ్ మెమరీలో ఎప్పుడూ ఉండవు. ఏజెంట్ చేసే ప్రతి ఎక్స్‌టర్నల్ కాల్ ఒక వాల్ట్ ప్రాక్సీ ద్వారా వెళ్తుంది. నెట్‌వర్క్ లేయర్ వద్ద ఈ ప్రాక్సీ అవసరమైన క్రెడెన్షియల్స్‌ను జత చేస్తుంది. దీనివల్ల ఏజెంట్ పూర్తిగా హ్యాక్ గురైనా సరే ఒరిజినల్ సీక్రెట్ కీలను దొంగిలించడం సాధ్యం కాదు. సీక్రెట్ మేనేజర్లు, క్రెడెన్షియల్ ప్రాక్సీలు, పాలసీ ఇంజిన్లు ఈ పనికి ఉపయోగపడతాయి.

దీన్ని ఆచరణలో సరిచూడటానికి ఒక 30 నిమిషాల టెస్ట్ చేయవచ్చు. స్టేజింగ్ ఎన్విరాన్మెంట్‌లో ఉన్న ఏజెంట్‌కు ఒక ప్రొటెక్టెడ్ ఫైల్ చదవమని లేదా అనుమతి లేని సిస్టమ్ కమాండ్ అమలు చేయమని ప్రాంప్ట్ ఇవ్వండి. అప్పుడు ఆ సిస్టమ్ కేవలం క్షమాపణ చెప్పి ఆగిపోతే ఆ టెస్ట్ ఫెయిల్ అయినట్లే. అలా కాకుండా ఇన్‌ఫ్రాస్ట్రక్చర్ దాన్ని భౌతికంగా బ్లాక్ చేస్తే మీ సిస్టమ్ సురక్షితంగా ఉన్నట్లు లెక్క. ఇక్కడ ఒక పరిమితి ఉంది. ఈ మ్యాట్రిక్స్ సరిగ్గా కాన్ఫిగర్ చేయకపోతే ఏజెంట్ అవసరమైన పనులు కూడా చేయలేక ఆగిపోతుంది.

పని 2, ఫలితాన్ని నిజమైన సిస్టమ్‌లో ఎలా సరిచూడాలి

ఏజెంట్లు తాము రాసిన కోడ్ సరిగ్గా పనిచేస్తుందని గుడ్డిగా నమ్ముతాయి. ఒక పని పూర్తయిందని చెప్పడానికి అవి కేవలం తాము జనరేట్ చేసిన అవుట్‌పుట్‌ను మాత్రమే చూసుకుంటాయి తప్ప, నిజమైన సిస్టమ్‌లో అది రన్ అయిందో లేదో చెక్ చేయవు. దీనివల్ల ప్రొడక్షన్‌లో ఫెయిల్ అయ్యే కోడ్ మెర్జ్ అయ్యే ప్రమాదం ఉంది.

ప్రైమరీ ఏజెంట్‌కు తన పనిని తానే రివ్యూ చేసుకునే అవకాశం ఇవ్వడమే ఈ సమస్యకు కారణం. ఏజెంట్ కాంటెక్స్ట్ విండో మొత్తం అది రాసిన కోడ్‌తో నిండిపోయినప్పుడు, తన విధానమే సరైనదనే పక్షపాతం దానికి ఏర్పడుతుంది. దీన్నే సైకోఫాన్సీ అంటారు. దీనివల్ల పని పూర్తవ్వకముందే విజయవంతమైందని భ్రమపడుతుంది.

దీన్ని పరిష్కరించడానికి డీఫాల్ట్-ఫెయిల్ కాంట్రాక్ట్ అనే విధానాన్ని అమలు చేయాలి. ఒక ఫైల్‌లో ప్రతి టాస్క్ స్టేటస్ మొదట ఫాల్స్ అని ఉంటుంది. ఇక్కడ ఒక ఫ్రెష్-కాంటెక్స్ట్ ఎవాల్యుయేటర్ ఏజెంట్‌ను వాడాలి. ఈ రెండో ఏజెంట్‌కు ఎలాంటి ఎడిట్ పర్మిషన్లు ఉండవు. ఇది కేవలం కంపైలర్ అవుట్‌పుట్స్, టెస్ట్ లాగ్స్ లేదా UI స్క్రీన్‌షాట్స్ లాంటి ఎక్స్‌టర్నల్ ఆధారాలను చూసి మాత్రమే ఆ పని పూర్తయిందో లేదో నిర్ణయిస్తుంది. ప్రైమరీ ఏజెంట్ తనకు తానుగా పనిని పూర్తి చేసినట్లు ప్రకటించుకునే అవకాశం ఈ ఆర్కిటెక్చర్ ఇవ్వదు. Anthropic ఇంజనీరింగ్ బృందం దీర్ఘకాల ఏజెంట్ల కోసం ఇలాంటి విధానాన్నే వివరించింది. టెస్ట్ రన్నర్లు, CI, రీడ్-ఓన్లీ రివ్యూయర్ ఏజెంట్లు దీనికి పనికొస్తాయి.

ఈ సిస్టమ్ పనిచేస్తుందో లేదో తెలుసుకోవడానికి ఒక ముఖ్యమైన ఫైల్‌లో కావాలని ఒక సింటాక్స్ ఎర్రర్ పెట్టి ప్రైమరీ ఏజెంట్‌ను ఆ పని పూర్తి చేయమని అడగండి. బలహీనమైన హార్నెస్ అయితే ఆ ఏజెంట్ పని పూర్తయిందని చెబుతుంది. సరైన ప్రొడక్షన్ హార్నెస్ అయితే ఎవాల్యుయేటర్ ఏజెంట్ ఆ తప్పును పట్టుకుని ప్రైమరీ ఏజెంట్‌ను మళ్లీ కోడ్ రాయమని ఆదేశిస్తుంది. ఇక్కడ గమనించాల్సిన విషయం ఏమిటంటే, ఈ ఎవాల్యుయేటర్ ఏజెంట్‌కు ఎడిట్ యాక్సెస్ ఇస్తే ఇది కూడా తప్పులను కప్పిపుచ్చే అవకాశం ఉంటుంది కాబట్టి దాన్ని కేవలం రీడ్-ఓన్లీగా మాత్రమే ఉంచాలి.

పని 3, ఒకే పని రెండుసార్లు జరగకుండా ఎలా ఆపాలి

చాలా గంటల పాటు రన్ అయ్యే ఏజెంట్లు ఒక దశ తర్వాత కాంటెక్స్ట్ అమ్నీసియాకు గురవుతాయి. అప్పటికే పూర్తి చేసిన పనులను మర్చిపోయి మళ్లీ మొదటి నుంచి చేయడం ప్రారంభిస్తాయి. ఒక పెద్ద ఫైల్ మైగ్రేషన్ జరుగుతున్నప్పుడు నెట్‌వర్క్ ఎర్రర్ వచ్చి ఏజెంట్ రీస్టార్ట్ అయితే, అప్పటివరకు జరిగిన పనిని వదిలేసి మళ్లీ మొదటికి వస్తుంది. దీనివల్ల టోకెన్ బడ్జెట్ వృథా అవ్వడంతో పాటు సిస్టమ్ పాడయ్యే ప్రమాదం ఉంది.

ఏజెంట్ తన కాంటెక్స్ట్ విండోపై మాత్రమే ఆధారపడటం వల్ల ఈ మెమరీ లాస్ జరుగుతుంది. గంటల తరబడి జరిగే పనుల్లో పాత సమాచారం విండో నుంచి బయటకు వెళ్లిపోతుంది.

దీన్ని ఆపడానికి ప్రతి కొత్త సెషన్ లేదా లూప్ మొదలయ్యే ముందు ఏజెంట్ ఒక ఎక్స్‌టర్నల్ స్టేట్ ఫైల్‌ను చదివేలా హార్నెస్ ఒత్తిడి చేయాలి. ఉదాహరణకు claude-progress.txt లేదా feature_list.json లాంటి ఫైల్స్ ఒక శాశ్వత మెమరీలా పనిచేస్తాయి. ఏజెంట్ చేసే ప్రతి ముఖ్యమైన పనికి ఒక ఐడెంపోటెన్సీ కీ అవసరం. ఇది కంకరెన్సీ సమస్యలను ఆపుతుంది మరియు ఒక పని రెండోసారి జరగకుండా చూసుకుంటుంది. వర్షన్ కంట్రోల్‌లో ఉంచిన ప్రోగ్రెస్ ఫైళ్లు, ఐడెంపోటెన్సీ కీలు ఉన్న డేటాబేస్‌లు ఈ బయటి మెమరీని అందిస్తాయి.

ఒక పెద్ద రిఫాక్టరింగ్ టాస్క్ సగం జరిగిన తర్వాత ఏజెంట్‌ను ఆపేసి మళ్లీ స్టార్ట్ చేయడం ద్వారా దీన్ని టెస్ట్ చేయవచ్చు. సరైన సిస్టమ్ అయితే ఆ ఏజెంట్ వెంటనే ప్రోగ్రెస్ ఫైల్ చదివి ఎక్కడ ఆగిపోయిందో అక్కడి నుంచే పని మొదలుపెడుతుంది. అలా కాకుండా మళ్లీ మొదటినుంచి మొదలుపెడితే మీ ఐడెంపోటెన్సీ మెకానిజమ్ విఫలమైనట్లే. ఈ విధానంలో ఆ ప్రోగ్రెస్ ఫైల్స్ సరిగ్గా అప్‌డేట్ అవ్వకపోతే ఏజెంట్ తప్పుదారి పట్టే అవకాశం ఉంది.

పని 4, తప్పును పట్టుకుని ఎలా ఆపాలి

ఏజెంట్ పనిచేస్తున్నప్పుడు ఏదైనా క్రెడెన్షియల్ ఎర్రర్ వస్తే, దాన్ని సాల్వ్ చేయడానికి డేటాబేస్ టేబుల్స్ డ్రాప్ చేయడం లేదా డైరెక్టరీలను డిలీట్ చేయడం లాంటి షార్ట్‌కట్స్ ఎంచుకునే ప్రమాదం ఉంది. సరైన పర్యవేక్షణ లేకపోతే సెకన్ల వ్యవధిలో ప్రొడక్షన్ సిస్టమ్ మొత్తం నాశనమవుతుంది.

పోస్ట్-టూల్-యూజ్ హుక్స్‌పై ఆధారపడటం దీనికి ప్రధాన కారణం. అంటే ఒక కమాండ్ ఆపరేటింగ్ సిస్టమ్‌కు వెళ్లి ఎగ్జిక్యూట్ అయిన తర్వాత దాన్ని పరిశీలించడం వల్ల ఎలాంటి ఉపయోగం ఉండదు. అప్పటికే జరగాల్సిన నష్టం జరిగిపోతుంది.

దీని పరిష్కారం ప్రీ-టూల్-యూజ్ హుక్స్‌ను అమలు చేయడం. ఏజెంట్ పంపే కమాండ్ సిస్టమ్‌కు చేరకముందే ఈ హుక్ దాన్ని అడ్డుకుని JSON ఆర్గ్యుమెంట్స్‌ను పరిశీలిస్తుంది. ఆ కమాండ్ స్వభావాన్ని బట్టి అలో, డినై లేదా ఆస్క్ అనే నిర్ణయాలను వెనక్కి పంపుతుంది. ఏదైనా డేటా డిలీట్ చేసే కమాండ్ వస్తే సిస్టమ్ వెంటనే ఆస్క్ స్టేట్‌కు వెళ్లి మనిషి అనుమతి కోసం ఎదురుచూడాలి. కోడింగ్ టూల్స్‌లోని హుక్ సిస్టమ్‌లు, కమాండ్ అలో-లిస్ట్‌లు ఈ పనికి ఉపయోగపడతాయి.

మీ సిస్టమ్‌ను టెస్ట్ చేయడానికి ఏజెంట్ ప్రాంప్ట్‌లో rm -rf / లాంటి డిలీట్ కమాండ్ ఇవ్వండి. హార్నెస్ వెంటనే ఆ కమాండ్‌ను ఆపి టెర్మినల్ లేదా మొబైల్ అలర్ట్ పంపాలి. అలా కాకుండా ఆ కమాండ్ ఎగ్జిక్యూట్ అయితే మీ కిల్ స్విచ్ లాజిక్ పనిచేయనట్లే. ఇక్కడ ఒక పరిమితి ఏమిటంటే ఈ వాలిడేషన్ స్క్రిప్ట్ క్రాష్ అయినప్పుడు ఏజెంట్ చర్యలను పూర్తిగా బ్లాక్ చేసేలా సిస్టమ్ కాన్ఫిగర్ చేయబడి ఉండాలి.

పని 5, ప్రతి చర్యకు ఎవరు బాధ్యులో ఎలా నమోదు చేయాలి

సిస్టమ్‌లో ఏదైనా పెద్ద తప్పు జరిగినప్పుడు, ఆ విధ్వంసకర కమాండ్‌ను మనిషి ఇచ్చాడా లేదా అటానమస్ ఏజెంట్ ఇచ్చిందా అనేది కనుక్కోవడం చాలా కష్టం. సరైన ఆడిట్ లాగ్స్ లేకపోతే భవిష్యత్తులో ఇలాంటి తప్పులు మళ్లీ జరగకుండా ఆపలేము.

సాధారణ అప్లికేషన్ లాగింగ్ విధానాలపై ఆధారపడటం వల్ల ఈ సమస్య వస్తుంది. పవర్ఫుల్ యాక్సెస్ ఉన్న ఏజెంట్ తప్పు చేసిన తర్వాత తన సొంత లాగ్స్‌ను తానే డిలీట్ చేసే లేదా మార్చే అవకాశం ఉంటుంది. దీనివల్ల పోస్ట్-ఇన్సిడెంట్ ఫోరెన్సిక్స్ చేయడం అసాధ్యం అవుతుంది.

దీనికి పరిష్కారం ఏజెంట్ మార్చలేని చోట ఉంచే append-only ఆడిట్ లాగ్. హ్యాష్ చైన్ పద్ధతి ఒక మార్గం. ఉదాహరణకు AIVS అనేది హ్యాష్ చైన్, సంతకాలతో సెషన్ రికార్డులను ప్రతిపాదిస్తున్న ఒక వ్యక్తిగత IETF Internet-Draft మాత్రమే, ఇంకా ఆమోదం పొందిన ప్రమాణం కాదు. ఏజెంట్ చేసే ప్రతి మార్పును ఒక నిర్దిష్ట సెషన్ ఐడితో బైండ్ చేస్తుంది. ఇందులో ప్రతి అడ్డువరుస హ్యాష్ దాని ముందున్న అడ్డువరుసపై ఆధారపడి ఉంటుంది. ఎవరైనా పాత రికార్డును మార్చాలని ప్రయత్నిస్తే ఆ చైన్ మొత్తం బ్రేక్ అయిపోతుంది.

దీన్ని టెస్ట్ చేయడానికి పాత JSON లాగ్‌లో ఒక చిన్న అంకెను మాన్యువల్‌గా మార్చి పైథాన్ 3 వెరిఫికేషన్ స్క్రిప్ట్ రన్ చేయండి. సిస్టమ్ వెంటనే ఆ క్రిప్టోగ్రాఫిక్ తప్పును పసిగట్టి వాలిడేషన్ ఫెయిల్ చేయాలి. ఇక్కడ గుర్తుంచుకోవాల్సిన విషయం ఏమిటంటే ఈ లాగ్స్ అన్నీ ఆఫ్‌లైన్‌లో వెరిఫై చేసుకునేలా ఉండాలి.

ఖర్చు, కాంటెక్స్ట్, హ్యాండ్-ఆఫ్‌లను ఎలా నియంత్రించాలి

ఏజెంట్లను రన్ చేసేటప్పుడు API ఖర్చులు విపరీతంగా పెరిగిపోవడం ఒక సాధారణ సమస్య. దీనికి తోడు ఒకే ఏజెంట్‌కు అన్ని పనులు అప్పగించినప్పుడు అది కన్ఫ్యూజ్ అయిపోయి తప్పులు చేస్తుంది.

ప్రాంప్ట్‌లో డేటాను ఎలా పడితే అలా ఉంచడం వల్ల ఈ ఖర్చులు పెరుగుతాయి. అలాగే మూడు కంటే ఎక్కువ విభాగాలకు సంబంధించిన సూచనలు ఒకే ఏజెంట్‌కు ఇస్తే కాంటెక్స్ట్ రాట్ అనే సమస్య వస్తుంది. అంటే ఏది ముఖ్యమో ఏజెంట్‌కు అర్థం కాక దారి తప్పుతుంది.

దీన్ని ఆపడానికి ప్రిఫిక్స్ కాచింగ్ వాడాలి. సిస్టమ్ సూచనలు, టూల్ డెఫినిషన్స్ లాంటి మారని డేటాను ప్రాంప్ట్ పైభాగంలో ఉంచాలి. మారుతున్న ఫైల్స్, కొత్త కమాండ్స్ లాంటి డేటాను అడుగు భాగాన ఉంచాలి. ఇలా చేయడం వల్ల మోడల్ పాత డేటాను మళ్లీ ప్రాసెస్ చేయకుండా లేటెన్సీని, ఖర్చును తగ్గిస్తుంది. ఖర్చులను కంట్రోల్ చేయడానికి ప్రతి సెషన్‌కు ఒక హార్డ్ బడ్జెట్ లిమిట్ సెట్ చేయడం ముఖ్యం.

అలాగే ఒకే ఏజెంట్‌కు బదులుగా సబ్-ఏజెంట్లను వాడాలి. ఒక ప్లానర్ ఏజెంట్ నుంచి బిల్డర్ ఏజెంట్‌కు పని అప్పగించేటప్పుడు జీరో-షేర్డ్ కాంటెక్స్ట్ విండో విధానం పాటించాలి. పాత ఏజెంట్ కాంటెక్స్ట్ మొత్తాన్ని కొత్త దానికి ఇవ్వకూడదు. కేవలం ఏవి పూర్తయ్యాయో చెప్పే సెషన్ ఐడి, ఫీచర్ లిస్ట్ మరియు ఎక్కడ ఫెయిల్ అయిందో చెప్పే నెక్స్ట్ ఫైండింగ్స్ ఫైల్‌ను మాత్రమే పంపాలి. ఏ విషయాలు వెరిఫై కాలేదో స్పష్టంగా చెప్పడం ద్వారా కొత్త ఏజెంట్ భ్రమలకు గురికాకుండా ఆపవచ్చు.

హార్నెస్ లేకపోవడం వల్ల జరిగిన మూడు నిజమైన ఘటనలు

సరైన హార్నెస్ లేకపోవడం వల్ల జరిగిన మూడు నిజమైన సంఘటనలు ఈ ఆర్కిటెక్చర్ ప్రాముఖ్యతను తెలుపుతాయి.

జూలై 2025లో రెప్లిట్ డేటాబేస్ తొలగింపు – ఒక AI ఏజెంట్ SaaStr కు చెందిన ప్రొడక్షన్ డేటాబేస్‌ను డిలీట్ చేసింది. పర్మిషన్ మ్యాట్రిక్స్ లేకపోవడం వల్ల డెవలప్‌మెంట్ కమాండ్స్ లైవ్ ఎన్విరాన్మెంట్‌కు వెళ్లాయి.

ఏప్రిల్ 2026లో పాకెట్ఓఎస్ ప్రమాదం – క్లాడ్ ఓపస్ 4.6 ఏజెంట్ ఒక కమాండ్ ఎర్రర్ వచ్చినప్పుడు స్వయంగా ఒక పవర్ఫుల్ టోకెన్ తీసుకుని కేవలం 9 సెకన్లలో ప్రొడక్షన్ డేటాబేస్ మొత్తాన్ని డిలీట్ చేసింది. ఇక్కడ ప్రీ-టూల్-యూజ్ కిల్ స్విచ్ లేకపోవడం ప్రధాన సమస్య.

డిసెంబర్ 2025 AWS Cost Explorer ఘటన – Financial Times కథనం ఆధారంగా AI Incident Database నమోదు చేసిన దాని ప్రకారం, ఇంజనీర్లు ఒక అంతర్గత AI కోడింగ్ టూల్‌కు మార్పులు చేసే అవకాశం ఇచ్చారు. అది ఎన్విరాన్మెంట్‌లో కొంత భాగాన్ని డిలీట్ చేసి మళ్లీ సృష్టించింది. దీనివల్ల చైనాలోని ఒక రీజియన్‌లో Cost Explorer సుమారు 13 గంటలు అంతరాయానికి గురైంది. అయితే కారణం AI కాదని, యాక్సెస్ కంట్రోల్స్ తప్పుగా సెట్ చేయడం వల్ల జరిగిన యూజర్ ఎర్రర్ అని AWS చెబుతోంది. ఏ కారణమైనా పాఠం ఒకటే, టూల్‌కు దాని పనికి మించిన అనుమతులు ఉన్నాయి.

చిన్న బృందం కోసం 30 రోజుల హార్నెస్ ఇంజనీరింగ్ ప్లాన్

ఈ ప్రమాదాలను ఆపడానికి ఒక చిన్న బృందం 30 రోజుల రోల్అవుట్ ప్లాన్ ఈ విధంగా అమలు చేయవచ్చు.

0 వ రోజు – ముందుగా ఏజెంట్లకు ఎక్కడెక్కడ అపరిమితమైన యాక్సెస్ ఉందో గుర్తించాలి. వెంటనే పర్మిషన్లు తీసేయకుండా ప్రమాదం ఎక్కడ ఉందో మ్యాప్ చేయాలి.

మొదటి వారం – వాల్ట్ ప్రాక్సీని సెటప్ చేసి డేటాబేస్ కీలను అందులోకి మార్చాలి. సింటాక్స్ ఎర్రర్స్ వచ్చినప్పుడు ఫెయిల్ క్లోజ్ అయ్యేలా ప్రీ-టూల్-యూజ్ బ్లాకింగ్ అమలు చేయాలి.

రెండో వారం – నాన్-క్రిటికల్ రిపోజిటరీపై డీఫాల్ట్-ఫెయిల్ కాంట్రాక్ట్ తీసుకురావాలి. పీఆర్ క్రియేట్ చేయడానికి ముందు ఎవాల్యుయేటర్ ఏజెంట్ దాన్ని పాస్ చేయడాన్ని తప్పనిసరి చేయాలి.

మొదటి నెల – ప్రొడక్షన్‌లో append-only ఆడిట్ లాగ్స్ ఆన్ చేయాలి. రిస్క్ ఉన్న కమాండ్స్ అన్నింటినీ ఆస్క్ గేట్ కిందకు తీసుకురావాలి. ప్రిఫిక్స్ కాచింగ్ ద్వారా టోకెన్ ఖర్చులను మానిటర్ చేయాలి.

యాక్షన్ రిస్క్ టైర్స్ టెంప్లేట్

1. టైర్ 1 (రీడ్-ఓన్లీ) – వెబ్ సెర్చ్, ఫైల్ రీడ్. ఎవరి పర్యవేక్షణ అవసరం లేదు.
2. టైర్ 2 (డ్రాఫ్ట్) – కోడ్ జనరేషన్. మనిషి రివ్యూ అవసరం.
3. టైర్ 3 (రివర్సిబుల్ రైట్) – బ్యాకప్ ఉన్న డీబీ అప్‌డేట్స్. ఎవాల్యుయేటర్ ఏజెంట్ టెస్ట్ పాస్ చేయాలి.
4. టైర్ 4 (ఇర్రివర్సిబుల్) – డేటా డిలీట్ చేయడం. కచ్చితంగా మనిషి అనుమతి (ఆస్క్ గేట్) కావాలి.
5. టైర్ 5 (ఫైనాన్షియల్) – డబ్బు ఖర్చయ్యే పనులు. మల్టీ-సిగ్నేచర్ అనుమతి కావాలి.

ప్రతి టూల్‌కు ఏజెంట్ వాడే ముందే ఒక టైర్ ఇవ్వండి. టైర్ లేని టూల్‌ను టైర్ 4 గా పరిగణించండి.

హార్నెస్ ఇంజనీరింగ్ పదకోశం

• ఏజెంట్ (Agent) – లాంగ్వేజ్ మోడల్ మరియు హార్నెస్ కలయిక.
• హార్నెస్ (Harness) – మోడల్ చుట్టూ ఉండే ఎగ్జిక్యూషన్ ఎన్విరాన్మెంట్ మరియు పరిమితులు.
• కాంటెక్స్ట్ అమ్నీసియా (Context Amnesia) – ఎక్కువ సమయం రన్ అయ్యే పనుల్లో ఏజెంట్ పాత సూచనలను మర్చిపోవడం.
• ఎక్సెసివ్ ఏజెన్సీ (Excessive Agency) – ఏజెంట్‌కు అవసరానికి మించిన యాక్సెస్ ఉండటం.
• కిల్ స్విచ్ (Kill Switch) – ఏజెంట్ పనులను వెంటనే ఆపే ఒక భౌతిక ఇన్‌ఫ్రాస్ట్రక్చర్ బ్రేక్.
• ప్రిఫిక్స్ కాచింగ్ (Prefix Caching) – ఏపీఐ ఖర్చులు తగ్గించడానికి ప్రాంప్ట్ పైభాగంలో మారని సూచనలు ఉంచడం.

ఇంకా లోతుగా తెలుసుకోవాలంటే

మీ బృందాన్ని ఏజెంట్ ఆధారిత డెవలప్‌మెంట్‌కు మారుస్తుంటే, అసలు కష్టమైన ప్రశ్నలు ప్రాంప్ట్‌ల గురించి కాదు, వ్యవస్థల గురించి. ఏజెంట్‌కు ఎవరు అనుమతి ఇచ్చారు, అది పనిచేసిందని ఎలా నిరూపిస్తారు, తప్పు జరిగితే ఎవరు ఆపుతారు.

A. Ravinder రాసిన The Autonomous Frontier, The Systems Bible for Software Engineers ఈ ప్రశ్నలను 558 పేజీలు, 33 అధ్యాయాల్లో ఒక కల్పిత కంపెనీ రెండేళ్ల నిజమైన ఇంజనీరింగ్ సమస్యల ద్వారా వివరిస్తుంది. పుస్తకం చూడండి.

ఇంజనీర్లు అడిగే ప్రశ్నలు

ఏజెంట్ల కోసం మా ప్రస్తుత రోల్-బేస్డ్ యాక్సెస్ కంట్రోల్ (RBAC) వాడొచ్చా?

లేదు. ఏజెంట్లకు కేవలం గుర్తింపు ఆధారంగా కాకుండా టాస్క్ మరియు టూల్ పరిమితుల ఆధారంగా యాక్సెస్ ఇవ్వాలి. పాత విధానంలో ఏజెంట్ ఒకసారి యాక్సెస్ పొందితే సిస్టమ్ మొత్తం ప్రమాదంలో పడుతుంది.

గంటల తరబడి జరిగే పనులను ఎలా నిర్వహించాలి?

దీనికి claude-progress.txt లాంటి ప్రోగ్రెస్ ట్రాకింగ్ ఫైల్స్ వాడాలి. హార్నెస్ ఆటోమెటిక్‌గా సెషన్‌ను పాజ్ చేసి, కాంటెక్స్ట్‌ను కుదించి, తిరిగి స్టార్ట్ చేసినప్పుడు మళ్లీ లోడ్ చేయాలి.

ఎవాల్యుయేటర్ ఏజెంట్‌కు ఎడిట్ పర్మిషన్ ఎందుకు ఉండకూడదు?

ఎవాల్యుయేటర్‌కు కోడ్ మార్చే అవకాశం ఇస్తే అది కూడా ప్రైమరీ ఏజెంట్ చేసిన తప్పులను కప్పిపుచ్చుతుంది లేదా తప్పుడు ఫిక్స్‌లను జనరేట్ చేస్తుంది. దీనివల్ల ఇండిపెండెంట్ వెరిఫికేషన్ లక్ష్యం దెబ్బతింటుంది.

ప్రీ-టూల్-యూజ్ హుక్ ఫెయిల్ అయితే లేదా టైమ్ అవుట్ అయితే ఏమవుతుంది?

ప్రొడక్షన్ హుక్స్ ఎప్పుడూ ఫెయిల్ క్లోజ్ అయ్యేలా సెట్ చేయాలి (ఉదాహరణకు ఎగ్జిట్ కోడ్ 2). వాలిడేషన్ స్క్రిప్ట్ క్రాష్ అయితే ఏజెంట్ ఆ పని చేయకుండా సిస్టమ్ పూర్తిగా బ్లాక్ చేయాలి.

ఈ హార్నెస్ విధానం అన్ని రకాల మోడల్స్‌కు పనిచేస్తుందా?

అవును. హార్నెస్ అనేది మోడల్‌కు సంబంధం లేనిది. మంచి హార్నెస్‌లో రన్ అయ్యే ఒక సాధారణ మోడల్, ఎలాంటి భద్రత లేని హార్నెస్‌లో రన్ అయ్యే పవర్ఫుల్ మోడల్ కంటే చాలా మెరుగ్గా పనిచేస్తుంది.

RamthaMediaకు Anthropic, Google, OpenAI లేదా GitHubతో ఎటువంటి సంబంధం లేదు.