𝗧𝗵𝗲 𝗧𝗵𝗶𝗻𝗴 𝗬𝗼𝘂 𝗩𝗲𝗿𝗶𝗳𝗶𝗲𝗱 𝗜𝘀 𝗡𝗼𝘁 𝗧𝗵𝗲 𝗧𝗵𝗶𝗻𝗴 𝗧𝗵𝗮𝘁 𝗥𝘂𝗻𝘀
તાજેતરમાં એક નવા સાધને (tool) ધ્યાન ખેંચ્યું છે. તે curl જેવી કમાન્ડ્સની આગળ રહે છે અને સ્ક્રિપ્ટ ચાલતા પહેલા તમને બતાવે છે. તે જોખમી ભાગોને હાઇલાઇટ કરે છે. આ સાધન ઉપયોગી છે, પરંતુ તે મુખ્ય સમસ્યાને ચૂકી જાય છે.
સમસ્યા એ નથી કે બાઇટ્સ (bytes) હાનિકારક લાગે છે કે નહીં. સમસ્યા એ છે કે એક URL આજે એક સ્ક્રિપ્ટ આપી શકે છે અને આવતીકાલે બીજી અલગ સ્ક્રિપ્ટ આપી શકે છે. તમારી ચકાસણી માત્ર એક ચોક્કસ ક્ષણ માટે જ લાગુ પડે છે.
સિસ્ટમ નિષ્ણાતો આને TOCTOU કહે છે. તેનો અર્થ 'time-of-check to time-of-use' થાય છે. તમે એક ફાઇલ તપાસો છો, અને પછી તમે તેને ખોલતા પહેલા કોઈ તેને બદલી નાખે છે. તમારી ચકાસણી સાચી હતી, પરંતુ તે એવી વસ્તુ વિશે સાચી હતી જે હવે અસ્તિત્વમાં નથી.
AI એજન્ટ્સ આ જોખમને ઘણું વધારે બનાવે છે. એજન્ટ્સ સતત ચકાસણી કરે છે.
- એક એજન્ટ URL ને પિંગ કરે છે અને સફળ પ્રતિસાદને સુરક્ષાના સંકેત તરીકે ગણે છે.
- એક એજન્ટ પ્રોફાઇલ વાંચે છે અને ઘોષણાને હકીકત તરીકે ગણે છે.
- એક એજન્ટ સિગ્નેચર જુએ છે અને માની લે છે કે જે બાઇટ્સ તે ચલાવવા જઈ રહ્યો છે તે જ છે જેના પર સહી કરવામાં આવી હતી.
દરેક ચકાસણી કોઈ ક્ષણ અથવા ચેનલ પર વિશ્વાસ સ્થાપિત કરે છે. ત્યારબાદ એજન્ટ એવી વસ્તુ પર કામ કરે છે જે ચકાસણીમાં ક્યારેય આવરી લેવામાં આવી ન હતી.
ઉદાહરણ તરીકે, એક એજન્ટ ટૂલ મેનિફેસ્ટ (tool manifest) ને વેલિડેટ કરી શકે છે અને પરિણામને કેશ (cache) કરી શકે છે. જો એજન્ટ ટૂલને કોલ કરે તે પહેલા એન્ડપોઈન્ટ (endpoint) બદલાઈ જાય, તો એજન્ટ ખોટું વર્ઝન ચલાવે છે. વેલિડેશન સફળ રહ્યું, પરંતુ તે એવા મેનિફેસ્ટ માટે સફળ રહ્યું જેનો એજન્ટ હવે ઉપયોગ કરતો નથી.
વધુ સખત રીતે સ્કેન કરીને આને સુધારવાનો પ્રયાસ કરવો કામ નથી આવતો. વધુ નિયમો માત્ર સમયની વિન્ડોને સાંકડી કરે છે, તેને બંધ કરતા નથી. તમારી સ્કેનિંગ અને એક્ઝિક્યુશન વચ્ચેના મિલીસેકન્ડ્સમાં પણ પ્રોડ્યુસર હજુ પણ અલગ આર્ટિફેક્ટ (artifact) આપી શકે છે.
આને સુધારવા માટે, ક્ષણની ચકાસણી કરવાનું બંધ કરો. આર્ટિફેક્ટની ચકાસણી કરવાનું શરૂ કરો.
તમારા નિર્ણયોને fetch ને બદલે એક અપરિવર્તનીય (immutable) ઓબ્જેક્ટ સાથે જોડો.
- URL ને મંજૂરી આપશો નહીં.
- ચોક્કસ કન્ટેન્ટ હેશ (content hash) ને મંજૂરી આપો.
- તેનાથી પણ સારું, એવા હેશને મંજૂરી આપો જેના પર વિશ્વાસપાત્ર કી (key) દ્વારા સહી કરવામાં આવી હોય.
આ પ્રશ્નને "શું આ ટેક્સ્ટ ડરામણું છે?" માંથી બદલીને "શું આ એ જ ચોક્કસ આર્ટિફેક્ટ છે જેના માટે કીએ ખાતરી આપી હતી?" માં ફેરવે છે. જો હેશ મેચ ન થાય, તો તમે તેને નકારી દો છો. તેમાં કોઈ દલીલ નથી.
આ અભિગમ વેરિફિકેશનને પોર્ટેબલ (portable) પણ બનાવે છે. ત્રીજી વ્યક્તિ પરિણામની જાતે ચકાસણી કરવા માટે સમાન હેશ અને સિગ્નેચર લઈ શકે છે. આ ઓબ્જેક્ટનો ગુણધર્મ છે, તમારા સમયનો ગુણધર્મ નથી.
કોઈપણ વેરિફિકેશનનું પરીક્ષણ કરવા માટે આ બે પ્રશ્નોનો ઉપયોગ કરો:
- Is the check bound to the exact artifact used, or to a moment and a promise?
- Can a stranger re-run the check and reach the same verdict?
If the answer to the first is a moment, the check has an expiry date. If the answer to the second is no, you do not have verification. You have testimony.
Most current agent verification is just testimony. "The handshake succeeded" or "the scan was clean" are true statements about a moment, but they do not attach to the bytes that actually run.
Agents act thousands of times without human oversight. If you do not pin trust to artifacts, the whole chain inherits the weakest, oldest check.
You do not need new technology to fix this. Content addressing and digital signatures are decades old. You simply need to point them at the right thing: the exact bytes that execute, not the request that fetched them.
Before you trust a check, find out what it attaches to. If it attaches to a moment, it has already expired.
Source: https://dev.to/anp2network/the-thing-you-verified-is-not-the-thing-that-runs-hnl
Optional learning community: https://t.me/GyaanSetuAi