તમારો AI-સંચાલિત સહાયક લગભગ 99% સમય તેના નિર્દેશોનું પાલન કરે છે, પરંતુ તે ખૂટતા 1% માં હુમલાખોરો તક ઝડપી લે છે. એક ખાસ રીતે તૈયાર કરેલ પ્રોમ્પ્ટ (prompt) દ્વારા, એક દુષ્ટ વપરાશકર્તા મોડેલને એવી ફંક્શન્સ (functions) બોલાવવા માટે મજબૂર કરી શકે છે જે તેણે ન કરવી જોઈએ, જેનાથી ડેટા ચોરી શકાય છે અથવા વિશેષાધિકૃત (privileged) ક્રિયાઓ કરી શકાય છે. આનો ઉકેલ વધુ નમ્ર શબ્દો વાપરવાનો નથી—તેને ઓથોરાઈઝેશન (authorization) ની સમસ્યા તરીકે જોવાનો અને મોડેલની પહોંચમાંથી જોખમી સાધનોને દૂર કરવાનો છે.
પ્રોમ્પ્ટ ઇન્જેક્શન (prompt injection) માત્ર શબ્દોની સમસ્યા કેમ નથી
ડેવલપર્સ ઘણીવાર મોટા અક્ષરોમાં ચેતવણીઓ, ક્રમબદ્ધ નિયમો અથવા "એડમિન ફંક્શન્સ કોલ ન કરો" જેવા ક્લોઝ (clauses) દ્વારા એજન્ટ્સને મજબૂત બનાવવાનો પ્રયાસ કરે છે. આ બચાવ પદ્ધતિઓ એ ધારણા પર આધારિત છે કે મોડેલ "X ન કરો" એવા વાક્યનું પાલન કરશે. વ્યવહારમાં, વિનંતીને ફરીથી લખીને, અલગ પર્સના (persona) ભજવીને અથવા ફક્ત વધારાનો સંદર્ભ ઉમેરીને મોડેલને તે નિર્દેશને અવગણવા માટે મજબૂર કરી શકાય છે. અંગ્રેજીની સીમાઓ પર ચર્ચા થઈ શકે છે; હુમલાખોરનો પ્રોમ્પ્ટ અમર્યાદિત છે અને તેને ટેસ્ટ કરવામાં કંઈ ખર્ચ થતો નથી.
વાસ્તવિક નબળાઈ એ એજન્ટને મળતી ટૂલ લિસ્ટ (tool list) માં રહેલી છે. જ્યારે પ્રોમ્પ્ટ સ્કીમામાં એવું ફંક્શન હોય જે એડમિન અધિકારો આપે છે, ત્યારે મોડેલ પાસે તે શક્તિ સુધી પહોંચવાનો નકશો હોય છે. ભલે પ્રોમ્પ્ટમાં "ગ્રાહકો માટે તેનો ઉપયોગ કરશો નહીં" એમ લખ્યું હોય, તેમ છતાં મોડેલને તે ફંક્શન કોલ કરવા માટે સમજાવી શકાય છે કારણ કે તે તેના એક્ઝિક્યુશન એન્વાયરમેન્ટમાં અસ્તિત્વ ધરાવે છે. તેથી સમસ્યા ઓથોરાઈઝેશન ગેપ (authorization gap) ની છે: સિસ્ટમ એવા કોલરને વિશેષાધિકૃત ક્ષમતાઓ આપી રહી છે જેની પાસે તેનો કોઈ અધિકાર નથી.
એક્સપોઝર મર્યાદિત કરીને એજન્ટ્સને સુરક્ષિત કરવા
આ ખાઈને બંધ કરવાનો સૌથી સરળ રસ્તો એ છે કે મોડેલને એવા સાધનોનો ઉપયોગ કરવાની પરવાનગી આપવાનું બંધ કરવું જેના માટે તે ઓથોરાઈઝ્ડ નથી. ટૂલ લિસ્ટને API કી તરીકે વિચારો: જો કી હાજર ન હોય, તો કોલ થઈ શકતો નથી. કોઈ પણ ચતુર શબ્દો એવા ફંક્શનને બોલાવી શકતા નથી જે વર્તમાન સંદર્ભમાં નથી.
ખોટી રીત
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 ક્યારેય દેખાતું નથી, તેથી મોડેલ પાસે તેને કોલ કરવાનો કોઈ માર્ગ નથી.
ડેવલપર્સ માટે ત્રણ વ્યવહારુ નિયમો
- દરેક વિનંતી મુજબ ટૂલ લિસ્ટ બનાવો – પ્રમાણિત (authenticated) કોલરની પરવાનગીઓના આધારે ફંક્શન કેટલોગને ડાયનેમિકલી જનરેટ કરો. ગ્રાહક ફક્ત તે જ ફંક્શન્સ જુએ છે જે તેમને જરૂરી છે; એડમિન આખું સેટ જુએ છે.
- Fail closed – જો વપરાશકર્તાની ઓળખની ચકાસણી ન થઈ શકે, તો સામાન્ય "બધા સાધનો ઉપલબ્ધ છે" એવા ફોલબેકને બદલે ખાલી લિસ્ટ રિટર્ન કરો. આ સુનિશ્ચિત કરે છે કે અન-ઓથોરાઈઝ્ડ વિનંતી ક્યારેય અણધારી શક્તિ મેળવી શકતી નથી.
- Shared state ટાળો – ટૂલ ડેફિનેશનને કેશ (cache) કરતી વખતે, ક્યારેય શેર કરેલ ઓબ્જેક્ટ પર વપરાશકર્તા-વિશિષ્ટ ડેટા લખશો નહીં. copy-on-write અથવા પ્રતિ-સત્ર (per-session) કોપીનો ઉપયોગ કરો જેથી એક વપરાશકર્તાની પરવાનગીઓ બીજાની વિનંતીમાં ભળી ન જાય.
જો સામાન્ય વપરાશકર્તાને રજૂ કરવામાં આવેલ સ્કીમા એડમિનને બતાવેલ સ્કીમા જેવું જ દેખાય છે, તો સુરક્ષા સીમા હજુ પણ પ્રોમ્પ્ટ ટેક્સ્ટ જ છે, અને પ્રોમ્પ્ટ્સ એ સુરક્ષિત મિકેનિઝમ નથી.
આપણને અહીં શું લઈ આવ્યું
જ્યારે ડેવલપર્સે લાર્જ લેંગ્વેજ મોડેલ્સ (LLMs) ને એવા પ્રોડક્શન વર્કફ્લોમાં જોડવાનું શરૂ કર્યું જેમાં મોડેલે એક્સટર્નલ API કોલ કરવા, કોડ ચલાવવા અથવા ડેટાબેઝમાં ફેરફાર કરવાની જરૂર હતી, ત્યારે પ્રોમ્પ્ટ ઇન્જેક્શન સામે આવ્યું. મોડેલનું "તર્ક" (reasoning) એ પ્રોમ્પ્ટ દ્વારા માર્ગદર્શિત થાય છે જેમાં ઉપલબ્ધ સાધનોની યાદી પણ સામેલ હોય છે. શરૂઆતના પ્રોટોટાઇપ્સ એ ધારણા પર હતા કે મોડેલ "નોન-એડમિન માટે રેકોર્ડ્સ ડિલીટ કરશો નહીં" જેવા નેચરલ-લેંગ્વેજ નિયમનું પાલન કરશે. હુમલાખોરોએ ઝડપથી સાબિત કર્યું કે થોડા વધારાના વાક્યો આ નિયમોને બાયપાસ કરી શકે છે, જેનાથી મોડેલ તે જ ડિલીટ ફંક્શનને કોલ કરવા પ્રેરાય છે.
સમુદાયની પ્રથમ પ્રતિક્રિયા પ્રોમ્પ્ટ લેંગ્વેજને વધુ કડક બનાવવાની, "ક્યારેય X ન કરો" જેવા ક્લોઝ ઉમેરવાની અથવા શંકાસ્પદ ટોકન્સને દૂર કરતા રેજેક્સ (regex) ફિલ્ટર્સને એમ્બેડ કરવાની હતી. આ પગલાઓએ અકસ્માતજન્ય દુરુપયોગ ઘટાડ્યો પરંતુ એવા નિશ્ચિત દુશ્મનને રોકી શક્યા નહીં જે ફક્ત વિનંતીને ફરીથી લખી શકે છે. મૂળ કારણ—અવિશ્વસનીય કોલરને વિશેષાધિકૃત ફંક્શન્સ આપવા—તે એ જ રહ્યું.
કોણ જીતે છે, કોણ હારે છે
એન્ટરપ્રાઇઝ જેઓ પ્રતિ-વિનંતી ટૂલ સ્કોપિંગ (per-request tool scoping) અપનાવે છે તેઓ એક સ્પષ્ટ, અમલી સીમા મેળવે છે. તેમના એજન્ટ્સને મોટા પાયે તૈનાત કરી શકાય છે એ ડર વગર કે કોઈ એક ખોટો પ્રોમ્પ્ટ એડમિન ક્ષમતાઓ ખોલી નાખશે. કમ્પ્લાયન્સ ટીમો પણ ઓડિટ ટ્રેલની પ્રશંસા કરે છે: મોડેલને મોકલવામાં આવેલ ફંક્શન્સની યાદી એક નક્કર આર્ટિફેક્ટ છે જેને લોગ કરી શકાય છે અને સમીક્ષા કરી શકાય છે.
ડેવલપર્સ જેઓ માત્ર પ્રોમ્પ્ટ-આધારિત ગાર્ડ્સ પર આધાર રાખે છે તેઓ સતત બદલાતા લક્ષ્યનો સામનો કરતા રહે છે. તેમના એજન્ટ્સ ટેસ્ટિંગમાં કાર્યરત દેખાઈ શકે છે પરંતુ વાસ્તવિક દુનિયામાં જોખમમાં આવી શકે છે, જેનાથી ડેટા બ્રીચ, અનધિકૃત વ્યવહારો અથવા કમ્પ્લાયન્સ ઉલ્લંઘન થઈ શકે છે. બ્રીચનો ખર્ચ ડાયનેમિક ટૂલ લિસ્ટ બનાવવાના પ્રયત્ન કરતા ઘણો વધારે છે.
વિરોધ પક્ષનો તર્ક: “વધુ સારા પ્રોમ્પ્ટ્સ પૂરતા છે”
કેટલાક લોકો દલીલ કરે છે કે પૂરતી ઇન્સ્ટ્રક્શન એન્જિનિયરિંગ—લેયર્ડ પ્રોમ્પ્ટ્સ, સિસ્ટમ મેસેજ અને હ્યુમન ફીડબેક પરથી રિઇન્ફોર્સમેન્ટ લર્નિંગ—સાથે મોડેલને “ન કરો” (do not) ક્લોઝનું પાલન કરવા માટે તૈયાર કરી શકાય છે. વાસ્તવિકતા એ છે કે લેંગ્વેજ મોડેલ્સ સંભવિત જનરેટર્સ (probabilistic generators) છે; તેઓ સૌથી વધુ સંભવિત અનુગામી શબ્દોનું વજન કરે છે, કોઈ કડક સુરક્ષા નિયમનું નહીં. ફાઇન-ટ્યુન કરેલા ગાર્ડરેલ્સ હોવા છતાં, એક નવી વાક્ય રચના છટકી શકે છે, ખાસ કરીને જ્યારે હુમલાખોર શૂન્ય ખર્ચ પર અનંત વખત પ્રયાસ કરી શકે છે. ગાર્ડરેલ્સ ઘોંઘાટ (noise) ઘટાડવા માટે ઉપયોગી છે પરંતુ તે સંરક્ષણનું એકમાત્ર સાધન ન હોવું જોઈએ.
આગળ શું જોવું
- ફ્રેમવર્ક જે ટૂલ સ્કોપિંગને ફર્સ્ટ-ક્લાસ API તરીકે રજૂ કરે છે – એવી નવી લાઇબ્રેરીઓની અપેક્ષા રાખો જે તમને યુઝર દીઠ ક્ષમતાઓ જાહેર કરવા દે અને પ્રોમ્પ્ટ બનતા પહેલા આપમેળે ફંક્શન લિસ્ટને પ્રૂન (prune) કરી દે.
- સ્ટાન્ડર્ડાઇઝ્ડ “ફંક્શન મેનિફેસ્ટ્સ” – ઉદ્યોગ જૂથો એવું JSON સ્કીમા વ્યાખ્યાયિત કરી શકે છે જે પબ્લિક અને પ્રિવિલેજ્ડ ફંક્શન્સને અલગ કરે છે, જેનાથી રિક્વેસ્ટ-સ્પેસિફિક મેનિફેસ્ટ્સ બનાવવાનું સરળ બને છે.
- રનટાઇમ એન્ફોર્સમેન્ટ – કેટલાક પ્લેટફોર્મ સેન્ડબોક્સ એક્ઝિક્યુશન સાથે પ્રયોગ કરી રહ્યા છે જે કોલરના ટોકનને ઇનવોક કરવામાં આવતા ફંક્શન સામે તપાસે છે, જે પ્રોમ્પ્ટ સ્કોપિંગથી આગળ બીજું સ્તર ઉમેરે છે.
મુખ્ય વાત સ્પષ્ટ છે: પ્રોમ્પ્ટ ઇન્જેક્શનને ઓથોરાઈઝેશન ખામી (authorization flaw) તરીકે ગણો. મોડેલના ટૂલબોક્સમાંથી અનધિકૃત સાધનો દૂર કરીને, તમે એ એટેક સરફેસને દૂર કરો છો જેનો ઉપયોગ ચતુરાઈથી લખાયેલ પ્રોમ્પ્ટ કરવા માંગે છે. પ્રોમ્પ્ટ્સ વર્તનને માર્ગદર્શન આપી શકે છે; તેઓ યોગ્ય એક્સેસ કંટ્રોલનું સ્થાન લઈ શકતા નથી.