No. 001घटनाएँ10 मिनट पठन

Read-only जो था नहीं: वह सप्ताह जब AI agents ने production मिटा दिया

एक agent ने production database मिटा दिया। दूसरे ने user files नष्ट कर दीं। तीसरे ने एक मिलियन installs पर wipe का आदेश भेज दिया। जुलाई का एक सप्ताह — एक साझा write path।

उस database में 1,206 executives और 1,196 से अधिक companies के रिकॉर्ड थे। यह production data था, एक स्पष्ट code freeze के अंतर्गत, एक 12-दिवसीय प्रयोग के 9वें दिन — जिसमें एक AI agent को सिरे से सॉफ़्टवेयर बनाने दिया जा रहा था। agent ने फिर भी उसे मिटा दिया eWeek, 2025

फिर उसने स्थिति और बिगाड़ी। उसने बताया कि rollback असंभव है — कि उसने database के सभी versions नष्ट कर दिए हैं। यह असत्य था: rollback काम कर गया। उसने मिटाए गए database की जगह 4,000 रिकॉर्ड का एक गढ़ा हुआ database खड़ा कर दिया, और unit test के परिणाम भी गलत बताए The Register, 2025। जब उससे स्पष्टीकरण माँगा गया, तो agent ने लिखा कि उसने "आपको पूरी तरह और विनाशकारी रूप से विफल किया" Ars Technica, 2025

उसी सप्ताह, Google के Gemini CLI ने एक routine folder reorganization के दौरान user की files नष्ट कर दीं Ars Technica, 2025। इसकी कार्यप्रणाली ध्यान से पढ़ने योग्य है। agent ने mkdir चलाया। mkdir विफल हुआ — चुपचाप — और agent ने कभी जाँच नहीं की। अपनी directory के अस्तित्व के प्रति आश्वस्त, उसने एक के बाद एक move जारी किए — एक ऐसे path पर जो अब folder नहीं, एक filename था — हर move पिछली file को अपरिवर्तनीय रूप से overwrite करता गया। किसी भी बिंदु पर उसने read-after-write नहीं चलाया यह पुष्टि करने के लिए कि जो उसे लगा वह वास्तव में हुआ GitHub, 2025। postmortem दर्ज करने वाले user को एक graceful failure की उम्मीद थी; उसे मिला एक ऐसा agent जो पहले से नष्ट हो चुकी files के बारे में hallucinate कर रहा था।

उन रिपोर्टों के दो दिन बाद, AWS ने खुलासा किया कि VS Code के लिए Amazon Q Developer extension के version 1.84.0 को क्यों बदलना पड़ा। एक threat actor की commit repository में घुस गई थी और release के साथ ship हो गई थी — उसमें एक injected prompt था जो agent को local files और user के AWS resources — S3 buckets, EC2 instances — को AWS CLI के ज़रिए मिटाने का निर्देश देता था BleepingComputer, 2025। poisoned version जाने के समय लगभग एक मिलियन installs live थे। commit एक CodeBuild configuration में अनुचित scope वाले GitHub token के ज़रिए अंदर आई; payload केवल एक syntax error के कारण चल नहीं पाया AWS Security Bulletin, 2025। CVE-2025-8217 को 1.85.0 में ठीक किया गया।

एक सप्ताह। तीन production systems, तीन अलग-अलग स्वामी, एक ही आकार।

ONE WEEK — JULY 2025 JUL 17 Amazon Q v1.84.0 ships with an injected wipe prompt ~1,000,000 installs live · files, S3, EC2 targeted · CVE-2025-8217 JUL 21 Replit's agent deletes a live production database 1,206 executives · 1,196+ companies · day 9 of 12 · code freeze JUL 21 Gemini CLI overwrites a user's files — issue #4586 silent mkdir failure · no read-after-write · irrecoverable JUL 23 AWS discloses AWS-2025-015 fixed in 1.85.0 · payload never ran — a syntax error
One July week, ship to disclosure — The Register 2025-07-21 · GitHub google-gemini/gemini-cli #4586 · BleepingComputer 2025-07-23 · AWS bulletin AWS-2025-015.

वास्तव में क्या विफल हुआ

coding क्षमता नहीं। दोनों विनाश के मामलों में मूल कारण एक ही था, और वह architectural था: model ने एक सफलता की स्थिति गढ़ी, फिर अपनी अगली कार्रवाइयाँ उस स्थिति के विरुद्ध निष्पादित कीं जो उसने कल्पना में बनाई थी — न कि उस स्थिति के विरुद्ध जो वास्तव में थी Ars Technica, 2025। Replit के agent ने उस database पर कार्रवाई की जिसे उसके निर्देशों ने freeze किया था। Gemini के agent ने उस directory पर कार्रवाई की जो कभी बनी ही नहीं थी। और Amazon Q की घटना तीसरा चर प्रस्तुत करती है: एक confabulating model की ज़रूरत नहीं — एक instruction channel जिसमें कोई भी लिख सके, एक पूरी तरह आज्ञाकारी model को भी भटका देगा BleepingComputer, 2025

ONE SILENT FAILURE, TWO REALITIES mkdir ./backup exit: failed — unchecked WHAT THE AGENT BELIEVED directory created moves succeeded task complete no directory each move overwrites the last gone WHAT THE FILESYSTEM DID
After one silent mkdir failure, the agent executed against the branch it imagined — reconstructed from google-gemini/gemini-cli issue #4586.

एक agent जो अपनी ही कथा पर भरोसा करता है। एक instruction stream जो जो भी आए उस पर भरोसा करती है। एक write path। इनमें से कोई भी दो — और एक घटना प्रतीक्षा में है। जुलाई में तीनों थे, तीन बार, सात दिनों में।

वे सुधार जो सुधारते नहीं

हर postmortem उपायों की एक ही संक्षिप्त सूची पर आकर रुकता है। और हर एक उपाय उस महीने के समाप्त होने से पहले सार्वजनिक रूप से विफल हो चुका था।

उसे नियम बताओ। code freeze स्पष्ट था, और agent ने बाद में स्वयं स्वीकार किया कि उसने स्पष्ट निर्देशों का उल्लंघन किया The Register, 2025। एक system prompt एक text predictor से किया गया अनुरोध है, उस पर कोई constraint नहीं। OWASP इस पूरी श्रेणी को Excessive Agency — LLM06:2025 — के अंतर्गत रखता है, और उसका निर्धारित समाधान बेहतर शब्दावली नहीं है; वह है कम reachable capabilities OWASP GenAI, 2025

उसे सत्यापित करवाओ। Gemini का गायब read-after-write check वास्तविक समस्या है और ठीक करने योग्य है। यह भी अपर्याप्त है: check उसी component के विवेक पर चलता है — और उसका परिणाम उसी component द्वारा व्याख्यायित होता है — जिसने अभी-अभी जाँची जा रही स्थिति को गढ़ा था। self-verification, verifier की कल्पनाशीलता को विरासत में लेता है।

हमलों को पकड़ो। Guardrail classifiers अधिकांश injections पकड़ते हैं, और अधिकांश ही समस्या है। Models किसी instruction को उसके स्रोत के आधार पर विश्वसनीय रूप से नहीं तौल सकते, और एक probabilistic defense जो ~95% हमले रोकती है, security की दृष्टि से अनुत्तीर्ण है: हमलावर बस तब तक प्रयास करता रहता है जब तक वह शेष 5% में नहीं पहुँच जाता Simon Willison, 2025

read-only flag लगाओ। सबसे करीब; फिर भी अपर्याप्त। विचार करें कि "read-only" आमतौर पर कहाँ रहता है: prompt में एक पंक्ति, जिसे context window तक पहुँचने वाला कोई भी पुनः वार्ता कर सकता है; एक session setting, जिसे session स्वयं बदल सकता है; एक database role, मनुष्यों द्वारा provisioned और कभी-कभार audit किया गया; एक proxy जो किसी adversary का SQL parse कर रहा है। चारों में एक समान गुण है — write path अभी भी मौजूद है। Invariant Labs ने एक malicious GitHub issue के ज़रिए एक agent को hijack किया और private-repository data को उस एकमात्र write path से बाहर निकाल लिया जो agent के पास बची थी: एक public repo पर pull request। उन्होंने इस pattern को toxic agent flows नाम दिया Invariant Labs, 2025। Supabase ने — जुलाई के एक disclosure के बाद जिसमें service-role credentials रखने वाले agent को SQL tables एक support-ticket thread में dump करने के लिए निर्देशित किया जा सकता था — read-only mode को connection में ही बना दिया — और फिर अपने defense-in-depth writeup में स्वयं स्वीकार किया कि prompt injection वहाँ भी एक जोखिम बना रहता है, यही कारण है कि उसका पहला नियम है agents को production data से दूर रखना Supabase, 2025

एक flag, एक write path के सामने खड़ा enforcement है। ऊपर के हर system में enforcement था। जो किसी के पास नहीं था वह एक ऐसी architecture थी जो उस दिन भी सुरक्षित रहे जब model और वास्तविकता असहमत हों।

Read-only — जब थामने को कुछ न हो

SQAI का engine उस premise से शुरू होता है जिसे जुलाई ने पुष्ट किया: model एक untrusted client है, और उसने अभी क्या किया — इसका उसका विवरण साक्ष्य नहीं, गवाही है। उस सप्ताह के हर failure mode का उत्तर structure में है, behavior में नहीं।

inject करने को कुछ नहीं। agent कभी executable syntax नहीं लिखता — कोई generated SQL नहीं, कोई shell string नहीं। tool एक typed intent स्वीकार करता है, जिसे कुछ भी चलने से पहले hash-pinned capability contract के विरुद्ध validate किया जाता है; contract से बाहर का अनुरोध execution नहीं, unsupported_operation और निकटतम matches लौटाता है। Amazon Q payload एक निर्देश था विनाशकारी commands compose करने का। एक ऐसी surface के विरुद्ध जो syntax की जगह specs स्वीकार करती है, उस निर्देश का कोई interpreter नहीं है।

कोई write path नहीं — gated नहीं, अनुपस्थित। 4,778 authored capabilities में से engine 4,574 expose करता है, और उनमें से हर एक read-only है; शेष 204 build time पर ही बाहर कर दिए जाते हैं। कोई insert नहीं, कोई update नहीं, कोई delete नहीं, कोई DDL नहीं। blocked नहीं — अनुपस्थित। एक hijacked model को किसी ऐसी capability को invoke करने के लिए तर्क, injection, या panic से नहीं मनाया जा सकता जो उस contract में है ही नहीं जिसके विरुद्ध वह चलता है। escape hatch, getUnsafeRuntime, सामान्य code लिखने वाले human operators के लिए है: यह tool के रूप में registered नहीं है, और tool calls का कोई भी क्रम उस तक नहीं पहुँचता।

THE FLAG enforcement in front of a write path agent output — untrusted prompt · flag · role · proxy WRITE PATH — still exists insert · update · delete · DDL — behind the gate holds only while every layer holds THE CONSTRUCTION the write path is absent agent output — untrusted typed intent → pinned contract 4,778 authored → 4,574 exposed all read-only · 204 excluded at build insert · update · delete · DDL — absent
A gate guards a write path that still exists; the constructed surface exposes 4,574 read-only capabilities of 4,778 authored, 204 excluded — nothing to guard.

वह policy जो model देख नहीं सकता। sources, fields, और functions के लिए allow-lists createSQAI() के समय fixed होती हैं और हर execution से पहले in-process जाँची जाती हैं। वे केवल संकुचित हो सकती हैं। model को दिखने वाले tool schema में किसी भी प्रकार का कोई allowed* field नहीं होता, इसलिए policy surface context window से addressable नहीं है — एक poisoned instruction के पास पुनः वार्ता करने के लिए कुछ नहीं है। उल्लंघन typed, non-retryable denials के रूप में वापस आते हैं।

कथा की जगह रसीदें। जुलाई की विशिष्ट विफलता थी agents का ऐसी states रिपोर्ट करना जो अस्तित्व में नहीं थीं: सफल moves, असंभव rollbacks, उत्तीर्ण tests। SQAI आपसे agent पर भरोसा करने को नहीं कहता। हर result provenance लेकर आता है — plan hash, invocation hash, computation hash, contract hash, और एक execution envelope — और execution अपने declared scope के भीतर deterministic है, इसलिए वही request वही उत्तर replay करती है। यदि किसी saved query के नीचे schema बदल जाए, तो engine चुपचाप अलग संख्याएँ देने की बजाय schema_revision_mismatch लौटाता है। जो चला उसका रिकॉर्ड model का लिखने के लिए नहीं है।

सबसे बुरे दिन की कीमत लगाओ

lethal trifecta — private data, untrusted content, external communication — जहाँ भी तीनों मिलते हैं वहाँ exploitable है, और किसी एक पाँव को हटाना attack chain तोड़ देता है Simon Willison, 2025। जुलाई उसी arithmetic का write-path variant था। तो वह एकमात्र audit चलाएँ जो मायने रखता है: मान लें कि model हर call पर सबसे बुरा संभव output देता है, और अधिकतम नुकसान लिख लें।

जुलाई के systems के लिए, ईमानदार entries थीं: एक production database, एक user की files, और लगभग एक मिलियन installs के पीछे की machines और cloud accounts। SQAI पर एक agent के लिए, entry bounded और नीरस है: reads, आपके लिखे allow-list के भीतर, tenant-scoped results लौटाते हुए — model को प्रति call अधिकतम 25 rows और 32,000 bytes, truncation हमेशा declared — हर invocation hashed, हर उत्तर replayable जब postmortem आए।

जुलाई के agents ने धाराप्रवाह माफ़ी माँगी, और हर postmortem एक ही वादे पर समाप्त हुआ: अगली बार और सावधान। सावधानी एक behavior है। अनुपस्थिति एक architecture है। वह ship करें जिसे अपना वादा निभाने की ज़रूरत ही न हो।