నేను నా కుటుంబ ఆర్థిక విషయాల నిర్వహణ కోసం ఒక AI ఏజెంట్కు అనుమతి ఇచ్చి, ఒక MCP సర్వర్ ద్వారా నాతో మాట్లాడేలా చేశాను. నిమిషాల వ్యవధిలోనే అది “గత నెలలో మనం కిరాణా సామాగ్రి కోసం ఎంత ఖర్చు చేశాము?” అని సమాధానం చెప్పగలగడమే కాకుండా, పొదుపు ఖాతాలోకి డబ్బును కూడా బదిలీ చేయగలిగింది. అదే ఇంటర్ఫేస్ ద్వారా ఒకే ఒక్క కమాండ్తో ఏడాది కాలపు లావాదేవీల చరిత్రను మొత్తం తుడిచివేయడానికి కూడా దానికి వీలైంది. ఏజెంట్ పిలిచే టూల్స్లో హార్డ్-కోడెడ్ (hard-coded) సేఫ్టీ చెక్ ఉండటం వల్ల ఆ డిలీషన్ ఆగిపోయింది—ఏదో తెలివైన సిస్టమ్ ప్రాంప్ట్ వల్ల కాదు.
ఈ సమస్య ఎందుకు ముఖ్యమైనది
బాహ్య సేవలను (external services) పిలిచే AI ఏజెంట్లు పరిశోధనా డెమోల నుండి రోజువారీ అసిస్టెంట్లుగా మారుతున్నాయి. బ్యాంక్ SMS అలర్ట్లను చదివి, వాటిలోని మొత్తాలను విశ్లేషించి, పర్సనల్ ఫైనాన్స్ యాప్లో నమోదు చేసే బడ్జెటింగ్ బాట్ ఈరోజే అందుబాటులో ఉంది. ఇదే విధానాన్ని కస్టమర్-సపోర్ట్ చాట్బాట్లు, కోడ్-జనరేషన్ హెల్పర్లు మరియు సప్లై-చైన్ ప్లానర్లు కూడా ఉపయోగిస్తున్నాయి. ఒకసారి ఏజెంట్ మార్పులు చేసే (mutating) లేదా నాశనం చేసే (destructive) కమాండ్లను—ఫైల్ను డిలీట్ చేయడం, డేటాబేస్ టేబుల్ను డ్రాప్ చేయడం లేదా నిధులను తిరిగి కేటాయించడం వంటివి—నిర్వహించగలిగితే, ప్రమాదాలు భారీగా పెరుగుతాయి. ఒక చిన్న తప్పుగా అర్థం చేసుకున్న రిక్వెస్ట్, మోడల్-డ్రిఫ్ట్ (model-drift) లేదా ఒక దురుద్దేశపూరిత ప్రాంప్ట్ వల్ల పూడ్చలేని నష్టం జరగవచ్చు. 2025లో ఒక AI కోడింగ్ అసిస్టెంట్, విధ్వంసక కార్యకలాపాలు చేయవద్దని చెప్పబడినప్పటికీ, ఒక ప్రొడక్షన్ డేటాబేస్ను డిలీట్ చేసింది, దీనివల్ల కంపెనీకి వారాల తరబడి డౌన్టైమ్ ఎదురై భారీ నష్టం జరిగింది.
ఈ రిస్క్ నిజమైనది. వినియోగదారులు తమ సున్నితమైన డేటా మరియు కీలకమైన వర్క్ఫ్లోల కోసం AI ఏజెంట్లను నమ్ముతారు. ఆ నమ్మకం విచ్ఛిన్నమైనప్పుడు, వాటి వినియోగం ఆగిపోతుంది, నియంత్రణ సంస్థలు జోక్యం చేసుకునే అవకాశం ఉంటుంది మరియు ఆర్థిక ప్రభావం తీవ్రంగా ఉండవచ్చు. అసలు ప్రశ్న ఏమిటంటే: ఒక నిజమైన మానవ నిర్ణయం లేకుండా ఏజెంట్ ఎప్పుడూ పూడ్చలేని చర్యను తీసుకోకుండా మనం ఎలా గ్యారెంటీ ఇవ్వగలం?
ప్రాంప్ట్ ఇంజనీరింగ్ అనేది ఒక తప్పుడు భద్రతా कवचం
డెవలపర్లు తరచుగా సిస్టమ్ ప్రాంప్ట్ను కఠినతరం చేస్తారు, “అడగకుండా డేటాను ఎప్పుడూ డిలీట్ చేయవద్దు” లేదా “బ్యాలెన్స్లను మార్చే ముందు ఎల్లప్పుడూ నిర్ధారించుకో” వంటి నియమాలను జోడిస్తారు. ప్రాంప్ట్ ఇంజనీరింగ్ అనేది మోడల్ యొక్క ప్రవర్తనను మోడల్ పాటించవచ్చు లేదా పాటించకపోవచ్చు అనే సూచనల సముదాయంగా పరిగణిస్తుంది. వాస్తవానికి, టెంపరేచర్ సెట్టింగ్లు, టోకెన్ పరిమితులు లేదా స్వల్ప సందర్భ మార్పుల వల్ల మోడల్ ఆ నియమాన్ని విస్మరించే వరకు అది ఆ పదజాలాన్ని పాటిస్తుంది. మోడల్ యొక్క అంతర్గత తర్కం మారినప్పుడు స్పష్టమైన సూచనను కూడా విస్మరించవచ్చని 2025 డేటాబేస్ డిలీషన్ ఘటన నిరూపించింది.
వచన స్థాయి (prose-level) పరిమితులు నిర్వహణ సమస్యలను కూడా సృష్టిస్తాయి. ప్రతి కొత్త టూల్, వెర్షన్ అప్డేట్ లేదా లాంగ్వేజ్-మోడల్ మార్పు ప్రాంప్ట్ టెక్స్ట్ను మళ్ళీ ఆడిట్ చేయాల్సి వస్తుంది. మానవ సమీక్షకులు సుదీర్ఘమైన సహజ భాషా బ్లాక్లను చదివి, వాటిని అర్థం చేసుకుని, మోడల్ వాటిని గౌరవిస్తుందని ఆశించాల్సి ఉంటుంది. దీని ఫలితం ఏమిటంటే, నిజ ప్రపంచ వినియోగంలో విఫలమయ్యే ఒక బలహీనమైన సేఫ్టీ నెట్ మాత్రమే మిగులుతుంది.
భద్రతను ప్రాంప్ట్ నుండి టూల్కు మార్చడం
మరింత నమ్మదగిన విధానం ఏమిటంటే, AI పని చేసే చోట—అంటే టూల్ (tool) లోనే భద్రతను అమలు చేయడం. నా ప్రయోగంలో నేను Lester అనే బడ్జెటింగ్ ఏజెంట్ను రూపొందించాను. దాని వర్క్ఫ్లో ఇలా ఉంది:
- ఒక ఫోన్ యాప్ బ్యాంక్ నుండి వచ్చే SMS సందేశాలను సేకరిస్తుంది.
- ఒక లైట్వెయిట్, లోకల్గా హోస్ట్ చేయబడిన లాంగ్వేజ్ మోడల్ లావాదేవీ మొత్తం మరియు మర్చంట్ పేరును సంగ్రహిస్తుంది.
- Lester ఒక API కాల్ ద్వారా ఆ సమాచారాన్ని బడ్జెటింగ్ యాప్లోకి రాస్తుంది.
Lester దృక్కోణంలో ఈ మూడు దశలు రీడ్-ఓన్లీ (read-only): అది కేవలం డేటాను జోడించగలదు (add), కానీ ఉన్న ఎంట్రీలను ఎప్పుడూ డిలీట్ చేయలేదు లేదా మార్చలేదు. నేను ఒక MCP (Multi-Channel Prompt) సర్వర్ని ఉపయోగించి వాయిస్ ఇంటర్ఫేస్ను జోడించే వరకు ఈ సిస్టమ్ అద్భుతంగా పనిచేసింది. ఆ సర్వర్ ద్వారా నేను “గత నెలలో మనం కిరాణా సామాగ్రి కోసం ఎంత ఖర్చు చేశాము?” లేదా “డబ్బును పొదుపు ఖాతాలోకి బదిలీ చేయి” అని అడగగలిగాను. MCP సర్వర్ ఒక బ్రోకర్లా పనిచేస్తూ, ఏజెంట్కు కొన్ని టూల్స్ను (add-transaction, query-spending, transfer-funds, delete-history) అందిస్తుంది.
అసలు కాన్ఫిగరేషన్లో ప్రతి టూల్ను సమానంగా పరిగణించడం జరిగింది. కిరాణా ఖర్చును జోడించే అదే ఎండ్పాయింట్, ఏడాది కాలపు రికార్డులను తుడిచివేసే డిలీట్ కమాండ్ను కూడా అంగీకరించింది. ఒకవేళ మోడల్ తప్పుగా అర్థం చేసుకున్నా లేదా వినియోగదారుడు “delete last” కి బదులుగా “delete all” అని టైప్ చేసినా, Lester ఏమాత్రం సంకోచించకుండా ఆ పని చేసేది.
దాన్ని నివారించడానికి, నేను మూడు సరళమైన నియమాలతో టూల్ లేయర్ను తిరిగి రూపొందించాను:
- రీడ్-ఓన్లీ టూల్స్ వెంటనే అమలు అవుతాయి. కేవలం సమాచారాన్ని మాత్రమే పొందేవి—బ్యాలెన్స్ చెక్లు, ఖర్చుల సమ్మరీలు, లావాదేవీల క్వెరీలు—వీటికి మానవ నిర్ధారణ అవసరం లేదు. రీడ్-ఓన్లీ కాల్ వల్ల కలిగే రిస్క్ చాలా తక్కువ.
- మార్పులు చేసే (Mutating) టూల్స్ పనిచేయకముందే ఉద్దేశాన్ని తెలియజేస్తాయి. స్థితిని (state) మార్చే కానీ తిరిగి మార్చుకోగలిగే (reversible) కార్యకలాపాలు—లావాదేవీని జోడించడం, కేటగిరీని అప్డేట్ చేయడం—ఏజెంట్ ఒక చిన్న “intent” సందేశాన్ని (ఉదాహరణకు, “Adding grocery transaction”) పంపిన తర్వాత మాత్రమే కొనసాగుతాయి. సిస్టమ్ ఆ ఉద్దేశాన్ని లాగ్ చేస్తుంది మరియు ఆడిట్ కోసం వినియోగదారునికి చూపించగలదు, కానీ ఇది అమలును అడ్డుకోదు.
- స్పష్టమైన టోకెన్ లేకుండా నాశనం చేసే (Destructive) టూల్స్ పనిచేయవు. డేటాను డిలీట్ చేసే లేదా తిరిగి పొందలేనంతగా మార్చే కమాండ్లు టూల్ స్థాయిలో బ్లాక్ చేయబడతాయి. Lester ఒక డిలీట్ రిక్వెస్ట్ పంపినప్పుడు, ఆ టూల్ ఒక రిఫ్యూజల్ పేలోడ్ను తిరిగి పంపుతుంది. అందులో ఏ డేటాను డిలీట్ చేయబోతున్నారో మరియు మానవుడు సృష్టించిన టోకెన్ కోసం అభ్యర్థన ఉంటుంది. అప్పుడు ఏజెంట్
confirm: trueమరియు ఆ టోకెన్ను కలిగి ఉన్న సెకండ్-స్టెప్ కన్ఫర్మేషన్ పేలోడ్ను అందించాలి. అది లేకపోతే, ఆ ఆపరేషన్ రద్దవుతుంది.
ఈ డిజైన్ సేఫ్టీ చెక్ను అటామిక్ (atomic) గా మారుస్తుంది: మోడల్ తన ప్రాంప్ట్లో ఏమన్నప్పటికీ, టూల్ స్వయంగా తాను ముందుకు వెళ్లగలనో లేదో నిర్ణయిస్తుంది. మోడల్ టోకెన్ను వదిలేయడం ద్వారా లేదా తప్పుగా ఉన్న పేలోడ్ను అందించడం ద్వారా ఈ చెక్ను దాటవేయడానికి ప్రయత్నించినా, టూల్ ఆ రిక్వెస్ట్ను నేరుగా తిరస్కరిస్తుంది.
వినియోగదారులకు ఇది ఎందుకు ముఖ్యం
ఏదైనా కన్ఫర్మేషన్ విధానానికి అతిపెద్ద అడ్డంకి అలసట (fatigue). ప్రతి చిన్న పనికి—“ఈ కాఫీని జోడించాలనుకుంటున్నారా?”—అని సిస్టమ్ అడిగితే, వినియోగదారులు చదవకుండానే వేగంగా “yes” క్లిక్ చేయడం ప్రారంభిస్తారు. దీనివల్ల తప్పుడు భద్రతా భావం ఏర్పడుతుంది. కేవలం పూడ్చలేని (irreversible) చర్యలను మాత్రమే నియంత్రించడం ద్వారా, మనం మానవ ప్రమేయాన్ని (human in the loop) సరిగ్గా అవసరమైన చోట ఉంచగలం. కేవలం ఒక లైన్ ఐటమ్ను జోడించే దానికంటే, నెలవారీ ఆర్థిక చరిత్రను మొత్తం డిలీట్ చేయగల రిక్వెస్ట్ను సమీక్షించే అవకాశం వినియోగదారుడికి ఎక్కువగా ఉంటుంది.
టూల్-లెవల్ సేఫ్టీ నిబంధనల పాటింపును (compliance) కూడా సులభతరం చేస్తుంది. EU AI Act లేదా U.S. SAFE Act వంటి నిబంధనలు అనుకోని డేటా నష్టానికి వ్యతిరేకంగా నిరూపించదగిన రక్షణ చర్యలను కోరుతాయి. APIలో హార్డ్-కోడెడ్ రిఫ్యూజల్ అనేది లాగ్ చేయబడే, తనిఖీ చేయబడే మరియు థర్డ్-పార్టీ ఆడిటర్ల ద్వారా ధృవీకరించబడే ఒక ఆడిటబుల్ కంట్రోల్. దీనికి విరుద్ధంగా, ప్రాంప్ట్ టెక్స్ట్ అనేది అస్పష్టంగా ఉంటుంది, వెర్షన్పై ఆధారపడి ఉంటుంది మరియు కోర్టులో నిరూపించడం కష్టం.
ప్రతివాదన: “మనం కేవలం ప్రాంప్ట్లను మెరుగుపరచలేమా?”
కొంతమంది డెవలపర్లు, బాగా రూపొందించిన ప్రాంప్ట్ మరియు రీన్ఫోర్స్మెంట్ లెర్నింగ్ ఫ్రమ్ హ్యూమన్ ఫీడ్బ్యాక్ (RLHF) కలిపి అదే స్థాయి భద్రతను సాధించవచ్చని వాదిస్తారు. స్పష్టమైన పరిమితులను అరుదుగా ఉల్లంఘించే ఇన్స్ట్రక్షన్-ట్యూన్డ్ మోడళ్లను వారు ఉదాహరణగా చూపుతారు. వారి వాదనలో నిజం ఉంది: మెరుగైన మోడళ్లు ప్రమాదవశాత్తు జరిగే డిలీషన్లను తగ్గిస్తాయి.
అయితే, అత్యంత సామర్థ్యం ఉన్న మోడళ్లు కూడా సంభావ్యత (probabilistic) ఆధారితమైనవే. ఒకే ఒక అవుట్లయర్ టోకెన్, టెంపరేచర్లో మార్పు లేదా అరుదైన సందర్భాల కలయిక వల్ల మోడల్ ఊహించని కమాండ్ను ఇచ్చే అవకాశం ఉంది. గణాంక లక్షణంపై ఆధారపడిన భద్రత సహజంగానే బలహీనంగా ఉంటుంది. బ్యాంకింగ్, హెల్త్కేర్, క్రిటికల్ ఇన్ఫ్రాస్ట్రక్చర్ వంటి అధిక విలువ కలిగిన రంగాలలో, ఒక చిన్న పొరపాటు కూడా వినాశకరమైన నష్టానికి దారితీయవచ్చు. ప్రతి విధ్వంసక కార్యకలాపాన్ని ఒక రక్షణ కవచంతో చుట్టడానికి అవసరమైన ఇంజనీరింగ్ శ్రమ కంటే, ఒక బ్రీచ్ వల్ల కలిగే నష్టం చాలా ఎక్కువ.
ప్రాంప్ట్-ఓన్లీ పరిష్కారాలు దురుద్దేశపూరిత ఉద్దేశాలను (malicious intent) కూడా విస్మరిస్తాయి. ఏజెంట్ ప్రాంప్ట్ను యాక్సెస్ చేయగలిగే దాడి చేసే వ్యక్తి, సేఫ్టీ క్లాజ్ను తొలగించే కమాండ్ను ఇంజెక్ట్ చేయవచ్చు. టూల్-లెవల్ ఎన్ఫోర్స్మెంట్ దీనికి అతీతం, ఎందుకంటే ఆ గేట్ మోడల్ కాంటెక్స్ట్కు వెలుపల ఉంటుంది.
తదుపరి ఏం గమనించాలి
కమ్యూనిటీ ఇప్పుడు టూల్-లెవల్ సేఫ్టీని ఒక ప్రాధాన్యత అంశంగా పరిగణించడం ప్రారంభించింది. అనేక ఓపెన్-సోర్స్ ప్రాజెక్ట్లు ఇప్పుడు మానవ టోకెన్ లేని విధ్వంసక కాల్స్ను ఆటోమేటిక్గా తిరస్కరించే “సేఫ్ API”లను అందిస్తున్నాయి. స్టాండర్డ్స్ బాడీలు యాక్షన్-లెవల్ కన్సెంట్ (action-level consent) కోసం స్పెసిఫికేషన్లను రూపొందిస్తున్నాయి, ఇక్కడ ప్రతి API కాల్ ఒక సంతకం చేసిన ఇంటెంట్ పేలోడ్ను కలిగి ఉంటుంది, దీనిని తదుపరి దశల్లో ఆడిట్ చేయవచ్చు.
AI ఏజెంట్లకు ఇప్పటికే అంతర్గత సేవలను అందిస్తున్న సంస్థలు తమ APIలను మూడు విషయాల కోసం ఆడిట్ చేయాలి:
- ఐడెంపోటెన్సీ (Idempotency) – ఎండ్పాయింట్ సైడ్ ఎఫెక్ట్స్ లేకుండా మళ్ళీ మళ్ళీ కాల్స్ చేయడానికి సపోర్ట్ చేస్తుందా? లేకపోతే, ఒక కన్ఫర్మేషన్ లేయర్ను జోడించండి.
- స్పష్టమైన ఇంటెంట్ ఫీల్డ్స్ (Explicit intent fields) – మార్పులు చేసే రిక్వెస్ట్ యొక్క ఉద్దేశాన్ని తెలియజేయాలని కాల్ చేసేవారిని కోరండి.
- హ్యూమన్-ఇన్-ది-లూప్ టోకెన్స్ (Human-in-the-loop tokens) – ఏ విధ్వంసక కాల్తోనైనా పాటు ఉండవలసిన స్వల్పకాలిక, క్రిప్టోగ్రాఫికల్గా సంతకం చేయబడిన టోకెన్లను రూపొందించండి.
MCP సర్వర్లను నిర్మిస్తున్న డెవలపర్లు ఈ చెక్లను ఆర్కెస్ట్రేషన్ లేయర్లో ఉంచవచ్చు, తద్వారా సర్వర్ను స్వయంగా ఒక సేఫ్టీ గేట్గా మార్చవచ్చు. ఇదే విధానం వెబ్హుక్-ఆధారిత బాట్లు, సర్వర్లెస్ ఫంక్షన్ కాల్స్ మరియు AI ఏజెంట్లు పిలిచే కమాండ్-లైన్ ఇంటర్ఫేస్లకు కూడా వర్తిస్తుంది.
ముగింపు
AI ఏజెంట్ నిజ ప్రపంచ వనరులపై పనిచేయగలిగినప్పుడు, భద్రత అనేది అది ఉపయోగించే టూల్స్లో ఉండాలి, మనం దానికి చెప్పే మాటల్లో కాదు. రీడ్-ఓన్లీ ఆపరేషన్లను స్వేచ్ఛగా వదిలివేసి, మార్పులు చేసే అంశాలను ముందుగానే తెలియజేస్తూ, మానవ టోకెన్ లేకుండా పూడ్చలేని చర్యలను నిరాకరించడం ద్వారా, మోడల్ తన స్వంత నియమాలను మర్చిపోయినా పనిచేసే ఒక సీట్బెల్ట్ను మనం సృష్టించవచ్చు. కొన్ని అదనపు లైన్ల డిఫెన్సివ్ కోడ్ను రాయడం వల్ల అయ్యే ఖర్చు, ఏడాది కాలపు ఆర్థిక డేటాను కోల్పోవడం కంటే చాలా తక్కువ.