మీ AI-ఆధారిత అసిస్టెంట్ దాదాపు 99% సమయం తన సూచనలను పాటిస్తుంది, కానీ ఆ మిగిలిన 1% లోనే దాడి చేసేవారు అవకాశం వెతుక్కుంటారు. ఒక హానికరమైన వినియోగదారు ఒక精心 రూపొందించిన (crafted) ప్రాంప్ట్ను పంపడం ద్వారా, మోడల్ చేయకూడని ఫంక్షన్లను పిలిచేలా చేయవచ్చు, తద్వారా డేటాను దొంగిలించడం లేదా ప్రత్యేక అధికారాలు కలిగిన చర్యలను (privileged actions) నిర్వహించడం చేయవచ్చు. దీనికి పరిష్కారం మరింత మర్యాదపూర్వకమైన పదజాలాన్ని ఉపయోగించడం కాదు—ఈ లోపాన్ని ఒక అథరైజేషన్ (authorization) సమస్యగా పరిగణించి, మోడల్ పరిధి నుండి ప్రమాదకరమైన టూల్స్ను తొలగించడం.
ప్రాంప్ట్ ఇంజెక్షన్ అనేది కేవలం పదజాలం (wording) సమస్య మాత్రమే ఎందుకు కాదు
డెవలపర్లు తరచుగా అలెర్టింగ్స్, నంబర్ల ద్వారా నియమాలు లేదా "అడ్మిన్ ఫంక్షన్లను పిలవవద్దు" వంటి నిబంధనలతో ఏజెంట్లను బలోపేతం చేయడానికి ప్రయత్నిస్తారు. ఈ రక్షణ చర్యలు "X చేయవద్దు" అని చెప్పే వాక్యాన్ని మోడల్ పాటిస్తుందని భావిస్తాయి. వాస్తవానికి, అభ్యర్థనను తిరిగి ఫ్రేమ్ చేయడం (re-phrasing), వేరే పాత్రను పోషించడం (role-playing) లేదా అదనపు సందర్భాన్ని (context) జోడించడం ద్వారా మోడల్ను ఆ సూచనను విస్మరించేలా ప్రేరేపించవచ్చు. ఇంగ్లీష్ భాషా సరిహద్దులు చర్చించదగినవి; కానీ దాడి చేసేవారి ప్రాంప్ట్ పరిమితి లేనిది మరియు దానిని పరీక్షించడానికి ఎటువంటి ఖర్చు ఉండదు.
అసలైన బలహీనత ఏజెంట్కు అందే టూల్ లిస్ట్లో ఉంది. ప్రాంప్ట్ స్కీమాలో అడ్మిన్ హక్కులను ఇచ్చే ఫంక్షన్ ఉన్నప్పుడు, ఆ శక్తిని ఉపయోగించడానికి మోడల్కు ఒక మ్యాప్ దొరికినట్లవుతుంది. ప్రాంప్ట్లో "కస్టమర్ల కోసం దీనిని ఉపయోగించవద్దు" అని ఉన్నప్పటికీ, ఆ ఫంక్షన్ దాని ఎగ్జిక్యూషన్ ఎన్విరాన్మెంట్లో ఉన్నందున, మోడల్ను దానిని పిలిచేలా ఒప్పించవచ్చు. కాబట్టి ఈ సమస్య ఒక అథరైజేషన్ గ్యాప్ (authorization gap): వ్యవస్థ, ఆ అధికారాలు లేని వినియోగదారునికి ప్రత్యేక సామర్థ్యాలను (privileged capabilities) బహిర్గతం చేస్తోంది.
ఎక్స్పోజర్ను పరిమితం చేయడం ద్వారా ఏజెంట్లను సురక్షితం చేయడం
ఈ గ్యాప్ను మూసివేయడానికి అత్యంత సులభమైన మార్గం, మోడల్కు అది ఉపయోగించడానికి అధికారం లేని టూల్స్ను ఇవ్వడం ఆపివేయడం. టూల్ లిస్ట్ను ఒక API కీలా భావించండి: కీ లేకపోతే, కాల్ జరగదు. ప్రస్తుత సందర్భంలో (context) లేని ఫంక్షన్ను ఏ తెలివైన పదజాలంతోనైనా పిలవలేరు.
తప్పు పద్ధతి
Prompt: “You are an assistant. Do not use the adminDeleteUser function for regular customers.”
మోడల్ తన టూల్బాక్స్లో adminDeleteUserను ఇంకా చూస్తుంది మరియు దానిని పిలిచేలా మోడల్ను మోసం చేయవచ్చు.
సరైన పద్ధతి
Prompt schema for a regular customer: { “functions”: [ “searchCatalog”, “placeOrder” ] }
adminDeleteUser ఎప్పుడూ కనిపించదు, కాబట్టి మోడల్కు దానిని పిలివడానికి ఎటువంటి మార్గం ఉండదు.
డెవలపర్ల కోసం మూడు ఆచరణాత్మక నియమాలు
- ప్రతి అభ్యర్థనకు తగినట్లుగా టూల్ లిస్ట్లను నిర్మించండి – అథెంటికేట్ చేయబడిన వినియోగదారు యొక్క అనుమతుల (permissions) ఆధారంగా ఫంక్షన్ క్యాటలాగ్ను డైనమిక్గా రూపొందించండి. కస్టమర్కు వారికి అవసరమైన ఫంక్షన్లు మాత్రమే కనిపిస్తాయి; అడ్మిన్కు పూర్తి సెట్ కనిపిస్తుంది.
- ఫెయిల్ క్లోజ్డ్ (Fail closed) – వినియోగదారు యొక్క గుర్తింపును ధృవీకరించలేకపోతే, సాధారణ "అన్ని టూల్స్ అందుబాటులో ఉన్నాయి" అనే బదులు ఖాళీ జాబితాను (empty list) తిరిగి ఇవ్వండి. దీనివల్ల అథెంటికేట్ చేయని అభ్యర్థన ఎప్పుడూ ఊహించని శక్తిని పొందదు.
- షేర్డ్ స్టేట్ను (shared state) నివారించండి – టూల్ నిర్వచనాలను క్యాషింగ్ (caching) చేసేటప్పుడు, వినియోగదారుకు సంబంధించిన డేటాను ఎప్పుడూ షేర్డ్ ఆబ్జెక్ట్పై రాయకండి. ఒక వినియోగదారు యొక్క అనుమతులు మరొకరి అభ్యర్థనలోకి ప్రవహించకుండా ఉండటానికి copy-on-write లేదా per-session కాపీలను ఉపయోగించండి.
ఒక సాధారణ వినియోగదారుకు చూపబడే స్కీమా, అడ్మిన్కు చూపబడే దానితో సమానంగా ఉంటే, భద్రతా సరిహద్దు ఇంకా ప్రాంప్ట్ టెక్స్ట్పైనే ఆధారపడి ఉంటుంది, మరియు ప్రాంప్ట్లు నమ్మదగిన భద్రతా యంత్రాంగం కాదు.
ఇది మనల్ని ఇక్కడికి ఎలా చేర్చింది
డెవలపర్లు లార్జ్ లాంగ్వేజ్ మోడల్స్ (LLMs)ను బాహ్య APIలను పిలవడానికి, కోడ్ను రన్ చేయడానికి లేదా డేటాబేస్లను సవరించడానికి అవసరమైన ప్రొడక్షన్ వర్క్ఫ్లోలలో ఉపయోగించడం ప్రారంభించినప్పుడు ప్రాంప్ట్ ఇంజెక్షన్ సమస్య బయటపడింది. మోడల్ యొక్క "రీజనింగ్" (reasoning) అందుబాటులో ఉన్న టూల్స్ జాబితాతో పాటు ప్రాంప్ట్ ద్వారా నడపబడుతుంది. ప్రారంభ ప్రోటోటైప్లు "నాన్-అడ్మిన్ల కోసం రికార్డులను తొలగించవద్దు" వంటి సహజ భాషా నియమాన్ని మోడల్ పాటిస్తుందని భావించాయి. కొన్ని అదనపు వాక్యాలతో ఆ నియమాలను దాటవేసి, అదే డిలీట్ ఫంక్షన్ను పిలిచేలా మోడల్ను ప్రేరేపించవచ్చని దాడి చేసేవారు త్వరగా నిరూపించారు.
కమ్యూనిటీ యొక్క మొదటి ప్రతిస్పందన ప్రాంప్ట్ భాషను కఠినతరం చేయడం, "X ఎప్పుడూ చేయవద్దు" వంటి నిబంధనలను జోడించడం లేదా అనుమానాస్పద టోకెన్లను తొలగించే regex ఫిల్టర్లను ఉపయోగించడం. ఆ చర్యలు ప్రమాదవశాత్తు జరిగే దుర్వినియోగాన్ని తగ్గించాయి కానీ, అభ్యర్థనను తిరిగి ఫ్రేమ్ చేయగల పట్టుదల గల ప్రత్యర్థిని ఆపలేకపోయాయి. అసలు కారణం—అనధికారిక వినియోగదారునికి ప్రత్యేక అధికారాలు కలిగిన ఫంక్షన్లను బహిర్గతం చేయడం—అదే విధంగానే ఉంది.
ఎవరు గెలుస్తారు, ఎవరు ఓడిపోతారు
ప్రతి అభ్యర్థనకు టూల్ స్కోపింగ్ను (per-request tool scoping) అనుసరించే సంస్థలు స్పష్టమైన, అమలు చేయదగిన సరిహద్దును పొందుతాయి. ఒకే ఒక తప్పు ప్రాంప్ట్ అడ్మిన్ సామర్థ్యాలను అన్లాక్ చేస్తుందనే భయం లేకుండా వారి ఏజెంట్లను పెద్ద ఎత్తున ఉపయోగించవచ్చు. కంప్లయన్స్ టీమ్లు కూడా ఆడిట్ ట్రైల్ను అభినందిస్తాయి: మోడల్కు పంపబడిన ఫంక్షన్ల జాబితా అనేది లాగ్ చేయబడిన మరియు సమీక్షించబడిన ఒక ఖచ్చితమైన ఆధారంగా ఉంటుంది.
ప్రాంప్ట్-ఓన్లీ గార్డ్స్పై (prompt-only guards) ఆధారపడే డెవలపర్లు నిరంతరం సవాళ్లను ఎదుర్కొంటారు. వారి ఏజెంట్లు టెస్టింగ్లో పని చేస్తున్నట్లు అనిపించవచ్చు కానీ, వాస్తవ ప్రపంచంలో డేటా బ్రీచ్లు, అనధికారిక లావాదేవీలు లేదా కంప్లయన్స్ ఉల్లంఘనలకు దారితీసేలా ప్రభావితం కావచ్చు. బ్రీచ్ వల్ల కలిగే నష్టం, డైనమిక్ టూల్ లిస్ట్ను నిర్మించడానికి చేసే ప్రయత్నం కంటే చాలా ఎక్కువగా ఉంటుంది.
ప్రతివాదన: “మెరుగైన ప్రాంప్ట్లు సరిపోతాయి”
కొందరు వాదిస్తున్నట్లుగా, తగినంత ఇన్స్ట్రక్షన్ ఇంజనీరింగ్—లేయర్డ్ ప్రాంప్ట్లు, సిస్టమ్ మెసేజ్లు మరియు హ్యూమన్ ఫీడ్బ్యాక్ నుండి రీఇన్ఫోర్స్మెంట్ లెర్నింగ్ (RLHF) ద్వారా—మోడల్ “చేయకూడదు” (do not) అనే నిబంధనలను పాటించేలా చేయవచ్చు. కానీ వాస్తవానికి, లాంగ్వేజ్ మోడల్స్ అనేవి ప్రాబబిలిస్టిక్ జనరేటర్లు; అవి అత్యంత సంభావ్యమైన కొనసాగింపును (most likely continuation) పరిగణనలోకి తీసుకుంటాయి, కఠినమైన సెక్యూరిటీ రూల్ను కాదు. ఫైన్-ట్యూన్ చేసిన గార్డ్రైల్స్ ఉన్నప్పటికీ, ఒక కొత్త రకమైన వాక్యం (novel phrasing) సులభంగా లోపలికి రావచ్చు, ముఖ్యంగా దాడి చేసే వ్యక్తి (attacker) ఎటువంటి ఖర్చు లేకుండా అనంతంగా ప్రయత్నిస్తున్నప్పుడు. గార్డ్రైల్స్ నాయిస్ను తగ్గించడానికి ఉపయోగపడతాయి కానీ, అవి మాత్రమే రక్షణ కోసం ఏకైక మార్గంగా ఉండకూడదు.
తదుపరి గమనించవలసినవి
- టూల్ స్కోపింగ్ను ఫస్ట్-క్లాస్ APIగా ప్రదర్శించే ఫ్రేమ్వర్క్లు – వినియోగదారుని సామర్థ్యాలను (per-user capabilities) ప్రకటించడానికి మరియు ప్రాంప్ట్ రూపొందించబడక ముందే ఫంక్షన్ జాబితాను ఆటోమేటిక్గా తొలగించడానికి (prune) అనుమతించే కొత్త లైబ్రరీలను ఆశించవచ్చు.
- స్టాండర్డైజ్డ్ “ఫంక్షన్ మేనిఫెస్ట్లు” – పబ్లిక్ మరియు ప్రివిలేజ్డ్ ఫంక్షన్లను వేరు చేసే JSON స్కీమాను పరిశ్రమల సమూహాలు నిర్వచించవచ్చు, దీనివల్ల రిక్వెస్ట్-స్పెసిఫిక్ మేనిఫెస్ట్లను రూపొందించడం సులభతరం అవుతుంది.
- రన్టైమ్ ఎన్ఫోర్స్మెంట్ – కొన్ని ప్లాట్ఫారమ్లు సాండ్బాక్స్డ్ ఎగ్జిక్యూషన్తో ప్రయోగాలు చేస్తున్నాయి, ఇది ప్రాంప్ట్ స్కోపింగ్కు అదనంగా, పిలవబడిన ఫంక్షన్తో కాల్ చేసే వ్యక్తి యొక్క టోకెన్ను తనిఖీ చేసి రెండవ రక్షణ పొరను జోడిస్తుంది.
దీని సారాంశం స్పష్టంగా ఉంది: ప్రాంప్ట్ ఇంజెక్షన్ను ఒక అథరైజేషన్ లోపంగా (authorization flaw) పరిగణించండి. మోడల్ టూల్బాక్స్ నుండి అనధికారిక సాధనాలను తొలగించడం ద్వారా, తెలివిగా రూపొందించిన ప్రాంప్ట్ ద్వారా దాడి చేసే అవకాశాన్ని (attack surface) మీరు అరికట్టవచ్చు. ప్రాంప్ట్లు ప్రవర్తనను నడిపించగలవు; కానీ అవి సరైన యాక్సెస్ కంట్రోల్కు ప్రత్యామ్నాయం కాలేవు.