પ્રમાણીકરણ (Authentication) એ તમે કોણ છો તે તપાસે છે; અધિકૃતિકરણ (Authorization) એ તમે શું કરી શકો છો તે નક્કી કરે છે. AI-સંચાલિત એપ્લિકેશન્સની વધતી જતી સંખ્યા લોગિન વખતે યુઝરની ઓળખ એકવાર ચકાસે છે અને પછી બાકીના સત્ર (session) માટે અન્ડરલાઇંગ એજન્ટને કોઈપણ રિસોર્સ પર કામ કરવાની છૂટ આપે છે, જે અસરકારક રીતે તેને "બ્લેન્ક ચેક" આપવા સમાન છે. આ ડિઝાઇન અજાણતામાં ડેટા લીક, બિનજરૂરી ઈમેલ અથવા વિનાશક ડેટાબેઝ અપડેટ્સના દ્વાર ખોલી શકે છે, અને જ્યારે એક AI આસિસ્ટન્ટ મિલિસેકન્ડ લેટન્સી સાથે મલ્ટિપલ ટૂલ્સનો ઉપયોગ કરી શકે છે, ત્યારે આ જોખમ સતત વધતું જાય છે.

આ ભૂલ વારંવાર કેમ થાય છે

મોટાભાગના AI ડેવલપર્સ લોગિન સ્ક્રીનને એકમાત્ર સુરક્ષા ગેટ તરીકે જુએ છે. કોડ પાસવર્ડ અથવા ટોકન માંગે છે, સત્રને “authenticated” તરીકે માર્ક કરે છે, અને પછી માની લે છે કે તે પછીની દરેક વિનંતી સુરક્ષિત છે. પરંપરાગત વેબ એપમાં, માનવ યુઝરના ધીમા ક્લિક્સ કુદરતી રીતે નિયંત્રણ (throttling) રાખે છે; કોઈ પણ વ્યક્તિ “delete” દબાવતા પહેલા થોભશે. જોકે, એક AI એજન્ટ સેકન્ડોમાં ડઝનબંધ ટૂલ કોલ્સ કરી શકે છે. જો પ્લેટફોર્મ ફક્ત “શું યુઝર લોગિન થયેલ છે?” એટલું જ પૂછતું હોય, તો દરેક કોલને તે જ અનિયંત્રિત વિશેષાધિકાર મળે છે.

તેનું મૂળ કારણ સુવિધા છે. ટીમો ઘણીવાર આખી એપ્લિકેશન માટે એક જ લાંબા સમય સુધી ચાલતું (long-lived) સર્વિસ એકાઉન્ટ પ્રોવિઝન કરે છે જેથી કોડને મલ્ટિપલ ટોકન્સ અથવા સ્કોપ્સ મેનેજ કરવા ન પડે. તે એકાઉન્ટમાં સામાન્ય રીતે તમામ પ્રોજેક્ટ્સમાં વ્યાપક પરમિશન હોય છે—read, write, delete. જ્યારે AI આસિસ્ટન્ટ તે સત્રમાં ચાલે છે, ત્યારે તે આપમેળે તે અધિકારો મેળવી લે છે, પછી ભલે વર્તમાન કાર્ય માટે તેની ખરેખર જરૂર હોય કે નહીં.

શું જોખમમાં છે

  • ડેટા એક્સપોઝર – યુઝર લોગિન કર્યા પછી કોઈપણ ફાઇલ વાંચી શકતો એજન્ટ અજાણતામાં ગોપનીય દસ્તાવેજોને એવા જવાબમાં લાવી શકે છે જે પાછળથી સંસ્થાની બહાર શેર કરવામાં આવે છે.
  • અનિચ્છનીય ક્રિયાઓ – સપોર્ટ એન્જિનિયરનો AI હેલ્પર પ્રોડક્શન ડેટાબેઝ સામે સીધી SQL ક્વેરી ચલાવી શકે છે, માત્ર એટલા માટે કારણ કે એન્જિનિયરનું સત્ર હજુ સક્રિય છે, ભલે તે ક્વેરી જે ટિકિટ પર કામ ચાલી રહ્યું છે તેની સાથે સંબંધિત ન હોય.
  • નિયમનકારી પાલન (Regulatory compliance) – ઘણા ડેટા-પ્રોટેક્શન નિયમોમાં એ જરૂરી છે કે એક્સેસ ફક્ત જરૂરી લઘુત્તમ મર્યાદા સુધી જ મર્યાદિત હોવો જોઈએ. એક બ્લેન્કેટ પરમિશન મોડેલ તે સિદ્ધાંતોનું ઉલ્લંઘન કરી શકે છે અને ઓડિટ અથવા દંડનું કારણ બની શકે છે.
  • ઓપરેશનલ ખર્ચ – રેકોર્ડ્સને ડિલીટ અથવા મોડિફાય કરતી ભૂલો ટીમોને ફેરફારોને રોલબેક કરવા, મૂળ કારણોની તપાસ કરવા અને યુઝર્સ સાથે વિશ્વાસ ફરીથી કેળવવા માટે મજબૂર કરે છે—આ બધું સમય અને પૈસાનો બગાડ કરે છે.

ખૂટતું પગલું: દરેક ક્રિયા માટેનું અધિકૃતિકરણ (per-action authorization)

અધિકૃતિકરણ માત્ર મુખ્ય પ્રવેશદ્વાર પર જ નહીં, પરંતુ સિસ્ટમની અંદરના દરેક “દરવાજા” પર ચકાસવામાં આવવું જોઈએ. પ્રશ્ન “આ કોણ છે?” માંથી બદલાઈને “શું આ ચોક્કસ રિસોર્સ પર અત્યારે આ ચોક્કસ ક્રિયા થઈ શકે છે?” એવો થવો જોઈએ. આ ચેક લાગુ કરવા માટે સંપૂર્ણ રીડિઝાઇનની જરૂર નથી; તેના માટે ફક્ત સિંગલ સેશન ફ્લેગને બદલે ટૂંકા ગાળાના, સ્કોપ્ડ ટોકન્સ (short-lived, scoped tokens) તરફ વળવાની જરૂર છે.

વ્યવહારમાં તે કેવી રીતે કામ કરે છે

  1. ચોક્કસ સ્કોપ સાથે ટોકન માટે વિનંતી કરો – જ્યારે AI એજન્ટને ટૂલ કોલ કરવાની જરૂર હોય, ત્યારે તે પહેલાં એવું ટોકન મેળવે છે જેમાં જરૂરી પરમિશનની યાદી હોય (દા.ત., read:ticket, execute:sql_query).
  2. દરેક કોલ માટે ટોકન વેલિડેટ કરો – ટૂલ ચલાવતા પહેલા, સર્વિસ તપાસે છે કે ટોકનમાં જરૂરી સ્કોપ સામેલ છે અને ટોકન એક્સપાયર તો નથી થઈ ગયું ને.
  3. રિસોર્સને સ્કોપ સાથે મેચ કરો – જો વિનંતી કોઈ ચોક્કસ પ્રોજેક્ટ અથવા ડેટાબેઝને લક્ષ્ય બનાવે છે, તો ટોકને તે આઈડેન્ટિફાયર માટે સ્પષ્ટપણે એક્સેસ આપવો જોઈએ.
  4. અસ્વીકાર અથવા મંજૂરી – જો કોઈ પણ ચેક નિષ્ફળ જાય, તો કોલ નકારવામાં આવે છે અને એજન્ટને એરર મળે છે જે તે યુઝરને બતાવી શકે છે.

કોડનો તફાવત સ્પષ્ટ છે. એક “ખરાબ” અભિગમ આવો હોઈ શકે છે:

if session.is_authenticated():
    tool.run(params)

એક “સારો” અભિગમ ચેકને વિસ્તૃત કરે છે:

token = get_scoped_token(user, required_scope)
if token.is_valid() and token.allows(required_scope, resource_id):
    tool.run(params)
else:
    raise PermissionError

બીજો પેટર્ન થોડી લાઈનો ઉમેરે છે પરંતુ દરેક ઓપરેશન માટે સિસ્ટમને સાચો પ્રશ્ન પૂછવા માટે મજબૂર કરે છે.

તેને સરળ બનાવતા સ્ટાન્ડર્ડ્સ

OAuth 2.0 સ્કોપ્સ પહેલેથી જ ટોકન શું કરી શકે છે તેના પર મર્યાદા લાવવા માટે વ્યાપકપણે અપનાવવામાં આવેલી રીત પૂરી પાડે છે. project:1234:write અથવા email:send જેવા સ્કોપ્સને એન્કોડ કરતા ટૂંકા ગાળાના એક્સેસ ટોકન્સ ઇશ્યૂ કરીને, ડેવલપર્સ વેરિફિકેશન સ્ટેપ કરવા માટે હાલની લાઇબ્રેરીઓ પર ભરોસો રાખી શકે છે.

નવા Rich Authorization Requests (RFC 9396) આ વિચારને વિસ્તૃત કરે છે, જે ક્લાયન્ટને સ્ટેટિક લિસ્ટને અગાઉથી વ્યાખ્યાયિત કરવાને બદલે રનટાઇમ પર ગ્રેન્યુલર પરમિશનની વિનંતી કરવાની મંજૂરી આપે છે. જ્યારે AI વર્કફ્લો યુઝરના ઈરાદાના આધારે ક્ષમતાઓને તરત જ ઉમેરવા અથવા ઘટાડવાની જરૂર હોય ત્યારે આ લવચીકતા ઉપયોગી છે.

વિરોધ પક્ષનો તર્ક: સરળતા વિરુદ્ધ સુરક્ષા

કેટલીક ટીમો દલીલ કરે છે કે દરેક ક્રિયા માટેના ચેક (per-action checks) લેટન્સી અને કોડની જટિલતા વધારે છે, ખાસ કરીને જ્યારે AI આસિસ્ટન્ટે ઝડપથી અને સતત ઘણા ટૂલ્સનો ઉપયોગ કરવાનો હોય. તેઓ નિર્દેશ કરે છે કે સિંગલ સેશન ટોકન દરેક કોલ માટે નવું ટોકન મેળવવાનો અને તેને વેલિડેટ કરવાનો વધારાનો બોજ ટાળે છે. જોકે, આનો નુકસાન એ છે કે તેનાથી દુરુપયોગનું જોખમ ઘણું વધી જાય છે. આધુનિક ટોકન-વેલિડેશન સેવાઓ માઇક્રોસેકન્ડમાં કામ કરવા માટે ડિઝાઇન કરવામાં આવી છે, અને 'પ્રિન્સિપલ ઓફ લીસ્ટ પ્રિવિલેજ' (least privilege) ના સિદ્ધાંત સાથે બાંધછોડ કર્યા વિના વધારાના નેટવર્ક રાઉન્ડ-ટ્રિપને બેચ અથવા કેશ કરી શકાય છે. એવા વાતાવરણમાં જ્યાં ડેટાની અખંડિતતા અને પાલન (compliance) અનિવાર્ય છે, ત્યાં જોખમમાં થતો ઘટાડો પ્રદર્શનના નજીવા ખર્ચ કરતા વધુ મહત્વનો છે.

આગળ શું ધ્યાન રાખવું

  • AI SDKs માં સ્કોપ્ડ ટોકન્સનો સ્વીકાર – મુખ્ય AI પ્લેટફોર્મ ટૂલકિટ્સના અપડેટ્સ પર નજર રાખો; ઘણા પ્લેટફોર્મ્સ OAuth-આધારિત સ્કોપ્સ માટે હેલ્પર ફંક્શન્સ આપવાનું શરૂ કરી રહ્યા છે.
  • Policy-as-code ફ્રેમવર્ક – ઉભરતા સોલ્યુશન્સ ટીમોને ડિક્લેરેટિવ ફાઇલમાં ઓથોરાઈઝેશન નિયમો જાહેર કરવાની મંજૂરી આપે છે, જે રનટાઇમ પર આપમેળે લાગુ પડે છે.
  • દરેક ક્રિયાના નિર્ણયો દર્શાવતા ઓડિટ લોગ્સ – જેમ જેમ વધુ પ્લેટફોર્મ્સ દરેક ઓથોરાઈઝેશન ચેક રેકોર્ડ કરશે, તેમ સંસ્થાઓને કઈ AI ક્રિયાઓને મંજૂરી આપવામાં આવી રહી છે અથવા બ્લોક કરવામાં આવી રહી છે તેની સ્પષ્ટતા મળશે, જે ભવિષ્યના પોલિસી ફેરફારોમાં મદદરૂપ થશે.

મુખ્ય વાત

લોગ-ઇન થયેલ સેશનને બધું જ કરવાની પરવાનગી માનવું એ અનિચ્છનીય પરિણામોનું કારણ બની શકે છે. ઓથોરાઈઝેશનનો નિર્ણય લોગિનના સમયથી બદલીને દરેક વ્યક્તિગત ટૂલ કોલ સુધી લઈ જઈને—અને ટૂંકા ગાળાના, સ્કોપ્ડ ટોકન્સનો ઉપયોગ કરીને—AI એપ્લિકેશન્સ ડેટાનું રક્ષણ કરવા, નિયમોનું પાલન કરવા અને ખર્ચાળ ભૂલો ટાળવા સાથે ઓટોનોમસ એજન્ટ્સની સુવિધા જાળવી રાખી શકે છે. જ્યારે પણ કોઈ ક્રિયા કરવાનો પ્રયાસ કરવામાં આવે ત્યારે યોગ્ય પ્રશ્ન પૂછતી સિસ્ટમ માટે કોડની વધારાની લાઈનો એક નાની કિંમત છે.